Hi everyone, I’m new to ROV projects and have become deeply fascinated by them. I’ve noticed that the commercially available FIFISH achieves full 6-degree-of-freedom movement using just six
thrusters. I’d like to replicate their thruster layout, but ArduPilot’s ROV configuration only offers six preset layouts, and none of them seem to match this specific setup. The BlueROV2 looks similar, but the thruster mounting orientations are completely different. Does anyone know how we can configure the settings to make this FIFISH-style layout work effectively?
Hi @huang137 -
Welcome to the forums!
Yes, that’s definitely possible! For now, to achieve you’d need to modify the ArduSub firmware and then compile it yourself with the thruster matrix adjusted to match your layout. You then would flash this custom firmware, and selet the custom frame layout.
That’s fairly straightforward to do using the vscode extension in BlueOS, as the required dependencies are all present! It may of course be a bit faster to compile on your computer vs. the Raspberry Pi. This is a frequently discussed topic! This user-created tool may be helpful?
1 Like
Hi tony-white,
Thanks a lot for the detailed reply! I really appreciate the info.
So I took a look at what you mentioned, and honestly… I’m kind of lost 
I’m not a programmer at all, and the idea of modifying firmware and compiling it myself feels a bit overwhelming. I totally get that it’s “straightforward” for someone who knows their way around code, but for me, it’s a different story.
I’m running a Pixhawk on my ROV, and the thruster layout is pretty much like the FIFISH one (6 thrusters in that vector setup — I actually posted a picture in the thread if you want to see what I’m working with). I’ve tried to figure out the matrix thing, but I’m really not sure if I’m doing it right.
So here’s my maybe-too-bold question 
— would it be possible for you (or anyone else here) to compile a custom firmware for me with the right thruster matrix? Or maybe there’s some kind of tool or config file where I can just plug in some numbers and get a working firmware without touching the code?
I totally understand if you’re busy or if this is too much to ask — no pressure at all! But if there’s an easier way, or if someone’s already done something similar, I’d love to hear about it.
Thanks again for your help — really appreciate this community!
I can try to do this next week, but we don’t have that hardware configuration, so I can’t test it (which means the numbers might be wrong if I don’t get them right the first time). I’ve been meaning to write some documentation on how to choose the motion axis contribution factors, so hopefully this helps me to do that.
If it works well we can potentially add it as a supported frame option in the main repository, in which case you’d be able to use normal firmware updates afterwards - otherwise you’ll be stuck on the version you get built until you get another build made.
Note that we normally don’t build firmware for people[1], especially without the code they want compiled, but I see the current difficulties with custom motor configuration as a usability issue, so I’m more ok with doing so.
We also have ongoing plans and work to make a Lua-based dynamic motor configuration option (that wouldn’t require building the firmware to use), but there are some complexities with that, and we don’t have a timeline for when it will be both available and easy to use.
There are quite a few steps, but they’re reasonably well-documented, and we’re happy to help people who are struggling to follow them. ↩︎
Subject: Thank you and looking forward to the firmware build
Hi Eliot,
Thank you so much for your detailed response and for offering to help with this! I really appreciate you taking the time, especially since this isn’t a standard hardware configuration and you won’t be able to test it yourself. Your willingness to assist means a lot.
I completely understand the risks involved, and I’m more than happy to test the firmware once it’s ready. I’ll make sure to provide thorough feedback so that if the numbers need adjustment, we can refine them. It’s also great to hear that this might help you document the motion axis contribution factors — I’m sure that will be incredibly useful for the community.
The idea of potentially adding this as a supported frame option in the main repository is exciting! And I totally understand that you don’t normally build firmware for users, so I’m especially grateful for your flexibility here.
Just to reiterate, the layout I’m aiming for uses the fewest thrusters possible to achieve full 6-DOF control on an ROV. I’m really looking forward to seeing how it performs with the custom configuration you’ll put together.
Thanks again for your time and effort — please let me know if there’s any additional information I can provide to help with the build.
An initial approach:
ardusub-pixhawk-omni6-v0.0.1.apj (1.2 MB)
Motor numbering is as follows:
Assumptions:
- All thrusters lie on a horizontal plane (vertically aligned with the centre of mass / desired control)
- This differs slightly from the example in that it assumes the forward-facing thrusters have no pitch component (whereas the ones in the picture are raised, so may contribute slightly to pitch, although that may also be generally counteracted by the rear fin/spoiler)
- The centre of mass/control lies halfway between thrusters 5 and 6
- The example image likely has its centre of mass further forward, with relatively more pitch action provided by the rear thrusters
- The thrusters lie on two straight lines, that are parallel to the forward axis
- The example image tapers in towards the rear, which could reduce the roll control authority of the rear thrusters compared to the front ones
I’ve currently implemented this as the Custom frame. If it works well I can make it a proper frame, give it a name, and suggest it to the repository more generally.
Feel free to follow up if there are additional details you need to be able to test 
1 Like
Hi tony-white,
Wow, thank you so much! I honestly didn’t expect someone would actually take the time to compile a firmware for me — I really appreciate it 
I’ve downloaded the file and will try it out as soon as I can. The motor numbering diagram is super helpful — I’ll make sure everything is wired correctly before testing.
Also, thanks for explaining your assumptions — it totally makes sense. I understand that the real-world placement might be a bit different from the ideal model, but this gives me a perfect starting point. If I run into any issues during testing (like unexpected pitch or roll movements), I’ll let you know and we can tweak it from there.
Really appreciate you offering to turn this into a proper frame later — that would be awesome for others with a similar setup!
Thanks again for your time and help. This community is amazing 
Best,
Huang
I’ve been reviewing this, and in doing so have improved my understanding of the thrust factors and how best to determine good ones (hooray - this was partly the goal!), and also found a couple of issues with my initial attempt.
In particular:
- I’ve realised the example vehicle’s frame design has a fundamental coupling from the roll thrusters to induced yaw, which needs to be compensated for
- I’ve set the forward thrusters inverse yawing at 50% strength to try to combat that, but that proportion depends on the geometry of your frame, and likely needs to be tuned if you want decent roll control
- This kind of compensation works best if the thrust output is linear, which isn’t how thrusters tend to perform, and ArduSub doesn’t yet properly account for
- I’m working to enable some linearisation to the thruster control outputs, but it doesn’t account for the difference in forward vs reverse thrust that’s common with most thrusters, and may need tuning to match the thruster type’s output profile shape
- I’m unsure how much of a difference that will make, because I haven’t done any calculations or simulations to estimate it. It’s non-zero, but might not be significant for basic vehicle performance
- I had needlessly coupled yaw input commands with roll output, which I’ve now isolated
- I had the pitch factors inverted, which I’ve now corrected
An improved attempt:
ardusub-pixhawk-omni6-v0.0.3.apj (1.2 MB)
1 Like