Hi all,
i currently trying to smooth the accelleration/decelleration of all thrusters when used in both manual or auto mode.
I’ve tried to change the parameters as follow:
MOT_SLEW_UP : tried up to 0.5s
MOT_SLEW_DOWN: tried up to 0.5s.
What i discovered is that nothing change. THe motors ramp up /down with the same behavior.
I currently using latest BLueos Version with Pixahawk latest version.
I’ve tried also to downgrade the pixhawk version down to the 4.0 but the behavior is the same.
Update: I’ve tried also with RPI4 + Navigator. BLueos latest version.
Seems that those 2 parameters not changing anything related to the ramp up / ramp down of all thrusters.
Hi @RovBlue -
You’re changing the correct parameter, but unfortunately 0.5 is the highest accepted value. ArduRover, used with the BlueBoat, has the MOT_SLEWRATE parameter that can be set to much higher values, so the vehicle accelerates more gradually and less stress is placed on the system.
In the case of ArduSub, I would not anticipate much of a difference between the default MOT_SLEW_UP/DOWN and your higher value. You could try and force a higher value, like 2 seconds for the parameter, and see if it works - however ArduSub may not handle this correctly!
If you’re trying to make the vehicle less “touchy” and easier to control, you are better off adjusting other parameters, particularly lowering ATC_SLEW_YAW which is measured in cdeg/s. Lowering ATC_ACCEL_Y_MAX would also help, as the table illustrates values!
If you’d like to reduce the overall throttle slew rate, experimenting with MOT_SLEW_UP_TIME may also be worthwhile.
Can you share what motivates you to want to “smooth” the thruster response?
@RovBlue i think you’re right.
We deal with those parameters 3 years ago when we started to think about our power supply but after fed days of playing we found those not working.
I remember we inspected all PWM output channels one by one even with the use of oscilloscope. At the end we had to fine tune the vehicle power supply to let all the things works.
Would be great if @tony-white can confirm them works as expected.
Hi @SubseaLED -
Our software team has confirmed that the MOT_SLEW_UP/DOWN parameters are not used by ArduSub. They suggested that ATC_INPUT_TC in addition to ATC_SLEW_YAW would be the relevant parameters.
If trying to filter Auto modes, _FLTE params in beta and newer are the best bet but could “make things somewhat more unstable though”
@RovBlue that’s quite strange but i’m not surprised if there’s any other value that control the accelleration and decelleration time of all thrusters.
What’s your intention? Are you building any specific vehicle?
I think @tony-white can confirm with the software team but would be good to know what are the real parameter that affect that behavior.
I’m not trying to build a special vehicle, but I would like to smooth the thrusters acceleration as the vehicle is really unmanageable starting from 75% gain and above.
I think if the acceleration /deceleration time can be increased even up to 0.5s will be beneficial. But of course is just my point of view.
So, considering the millions of parameters available on the ardusub, is there any right in charge to smooth the things?
@RovBlue i think the parameter you’re looking for is called Manual_slew_rate.
But seems that this has been hide for some reason.
It was available in the Ardusub 3.5.4.
@tony-white do you know the reason of the above or it is not used anymore from the version 4.0?
Yes, I confirm it is available on the 3.5.4 and works but only for the axial motors. Anyway why this is not present on the latest ardusub?
Anybody from the Bluerobotics staff know the reason or a way to add it?
Most likely it was put into a stable branch but accidentally not added to master, so then wasn’t included in the next major release. That was likely from when ArduSub got merged back into the main ArduPilot codebase, which new versions have since been released from.
@williangalvani managed to find the original implementation for MANUAL_SLEW_RATE, and has cherry-picked the relevant commits into a development branch. That hasn’t been tested at all, so may not work with the current state of the codebase, but you’re welcome to try it out or work from there if you’re willing to build the firmware
Note that while Blue Robotics are the primary maintainers of ArduSub, it is an open source firmware, and external contributions are welcome