Hi all , I wanna figure out why our robot can’t achieve stable rolling under ACRO mode. It’s a 6dof underwater robot with 8 thrusters. I am using build-in motor matrix and my own 3D printing frame. It can achieve stable surge, sway and heave. But there are several issues for rolling control:
The robot easily flips over when rolling to larger degree.
The robot sways during rolling.
The robot can’t hold depth while rolling and descends.
The frame has positive buoyancy but i am not sure if the CoB/CoG offset sufficient for the roll stability. Does the issues come from motor allocation matrix, or any suggestions on where to start troubleshooting?
What do you mean by “stable rolling”? A constant rotation rate, a fixed lean angle, self-levelling when no longer controlled, something else…?
How have you configured your ACRO parameters? What kind of control inputs are you sending to the autopilot?
It’s not clear what you mean here - if you give a strong roll rate command in Acro mode then the robot will indeed roll over.
I’m curious what kind of inputs you’re sending to it, and what kind of outputs it is sending to the motors. Have you tried looking at an autopilot log file / do you have one you can share with us?
Is this still in Acro mode? It’s not expected to hold depth.
More generally, roll causing descent with this kind of frame is expected behaviour without asymmetric thrust compensation, which incidentally is a feature we’re currently reviewing for addition to ArduSub. If you share which flight controller board you’re using I can try to build you a firmware for testing with if you’d like, to see if it helps resolve that issue.
Hi Eliot, I’m using Pixhawk 2.4.8 with ArduSub 4.5.7, Vectored_6DOF frame (BlueROV2 Heavy config), controlled via Xbox joystick through QGC.
“stable rolling” means it could hold the degree when I hold the joystic. However, when operating near a side wall, the ROV becomes unstable in roll — it sways and flips over even without strong roll rate input. I still have no log file, but I can share you the latest log file tomorrow.
Acro mode is rate-controlled - holding the roll axis joystick at a fixed deflection will cause the vehicle to try to roll at a fixed rotation rate (i.e. you control the speed, not the angle), though note that there is limiting of the maximum deflection angle that’s on by default, and can be configured using the ACRO_TRAINER parameter.
If you release the joystick it should try to maintain a zero rotation rate, which resists rotation away from the angle it is currently at, though by default it self-levels with zero input (per the trainer configuration). That should roughly maintain the current angle, but a rate controller does not have a position (angle) target, so if there’s a temporary disturbance that it cannot overcome (or that is too fast or slow for it to sense) then it will re-settle at whatever the new angle is afterwards, rather than trying to return to some previous angle.
You can try this firmware, and see whether adjusting the MOT_ASYMMETRY parameter to match the forward vs backward ratio of your thrusters helps to reduce/avoid the coupling between roll and vertical motion:
This is intriguing. I wonder if it’s a hydrodynamics problem, perhaps caused by the interplay between the thrust towards the wall, the water “splashing” back from the wall, the roll thrusters getting different amounts of resistance from that splash-back, and the frame self-levelling due to gravity.
Have you done the automatic thruster reversal detection, and also tried stabilise and depth hold modes (rather than acro)? I’m curious whether perhaps you’ve just misconfigured which of the vertical thrusters is which (or swapped two when plugging them in), in which case the pitch and/or roll control algorithms will have the wrong control authority to what they expect.
