Due to some development-related reasons, we replaced the Pixhawk and upgraded the ArduSub firmware from version V3.5.4 to V4.1.1. During ROV testing, we encountered an issue: after updating the ArduSub firmware, the ROV’s response became noticeably faster. In other words, the instantaneous power demand increased significantly. At the same time, during sharp turns or rapid ascents, the back electromotive force (back-EMF) generated also became much greater, which caused the ROV’s power system to trigger protection mechanisms and shut off the power.
I would like to ask if anyone else has encountered this issue, and how you managed to solve it. We’re using T500 thrusters.
Is this happening during manual control, or when the autopilot is running an automated control or stabilisation algorithm?
This comment covers some different approaches to reducing maximum thrust / power usage, although depending on how you’re controlling the vehicle there may also be some other relevant parameters for reducing speed targets and the like.
The issue of overly fast response occurs in all modes, with Manual mode being the most affected. We also tried adjusting the joystick and RC-related parameters, which seemed to mitigate the problem, but this approach directly limits the ROV maximum power output.
I noticed a parameter called MOT_SLEW_UP_TIME in the Parameter list, but I’m not sure whether it would be effective in solving this issue.
I see - you specifically want to reduce how quickly thrust can change (i.e. proportionally decrease response time), not the peak thrust level (and corresponding power usage)?
In that case the motor slew rate parameters could indeed potentially be helpful. That said, I don’t believe they’re commonly used for ArduSub vehicles, so I’m unsure how well they work for it, especially given the hard caps (in the code) of 0.5s maximum slew time in either direction. Those limits may make more sense for aerial vehicles that can stall and/or fall out of the sky if the control response times are too slow.
I’d recommend testing the parameters, and if they seem to help with your problem but not as much as you’d like then you can try making a custom build without the same limits, and/or we can raise an Issue or pull request to relax or remove those hard limits (at least for ArduSub).
