Is it possible to impose slew rates on servo output, so to limit spikes in current demand due to transients ?
I have a skidsteering boat, and when commanding full left turn while already turning full right (for example) the motors are reversed from full forward to full reverse on one side, and from full reverse to full forwards: if this happens instantaneusly (and in MANUAL mode noone can prevent an operstor to do that), a current spike can be generated. This can lead to damage batteries/ESC or to trigger protection circuit of the battery…
I am wonering if one can impose a macimum slew rate to servo dynamics, so to cut this kind of transient
I can give a try, thanks
But the description reports “Throttle slew rate”, it is not clear if it applies also to YAW input, which is what I am interested in
There is a Turn Rate parameter (deg/s) and a max turn G parameter. The later is what ground rovers use to prevent tipping over on turns. Works great on my crawler. Also look at the MOT_VEC_ANGLEMAX parameter.
Have been wondering about the same thing.
We have tried MOT_SLEWRATE this control the ramping up of ahead / astern commands nicely but unfortunately has no impact on steering / yaw outputs.
As Roberto says turns initiated by the operator(s), or pivot turns commanded in auto mode result in violent application of thrust, I think proportional control is wasted on most operators
Either the ability to limit servo slewrate (on a per output basis) as suggested, This would have more applications than limiting motor outputs.
Or have the MOT_SLEWRATE parameter apply to ALL motor actions would be great.
First, you MUST follow the tuning instructions carefully. Reducing ATC_STR_RAT_FF will have the largest effect on slew rate.
You can set ATC_STR_RAT_SMAX to try and tame the assisted modes if the tuning instructions aren’t quite getting you where you need to be.
You can also reduce ATC_STR_RAT_MAX and ATC_STR_ACC_MAX, but that approach will be most effective once the tune is behaving a little better.
MANUAL mode must be handled separately and entirely by the transmitter. Consider using an aggressive expo curve and/or limiting the max PWM output. You might put that mix on a “rate” switch much like we often do with RC aircraft, such that it can be deselected when out of MANUAL mode.
My opinion: A feature request for a single parameter to reduce servo slew rate in all modes sounds like a Band-Aid request for something that should be handled by proper vehicle design.
OpenTX (and other transmitters too probably) have a slow function to limit the rate the output changes, no matter what the pilot does with the sticks. This is most often used with flaps, but should work with a rover too. Just create a flightmode in the transmitter, which activates with “manual mode” switch and tie the slow function to it.
Yuri,
Note the smilie
We must have different operators
Limiting output speeds is very common practice in marine engineering, throttle / pitch and steering controls will have max slew rates set (either hydraulic proportional flow control or electronic) so no matter how fast the operator moves the controls the system will only respond at a speed that won’t cause mechanical stress/damage.
We have been quite diligent with following the tuning setup, and the general steering along track is very good. The violent motor accelerations are only when a “pivot turn” is activated and to be honest it probably sounds worse than it is.
our normal operation mode is surveying in a “lawnmower” pattern so keeping the turns (Pivot turns) tight at the end of the line is desirable.
I will double check the ATC_STR_RAT_FF, … etc next time I have the boat in the water. MIght be a couple of weeks.
Respectfully disagree, the ability to set a MAX_SLEWRATE for a function (at a low level) to prevent overloading a system, regardless of operating mode, would seem to me a desirable safety feature, I was honestly expecting MOT_SLEWRATE to apply to all motor functions… so still be active for skid steer commands.
Sebastian,
With our skid steer boat application we are only using a logitech xbox USB controller for manual control, so sophisticated flight mode switching and programming is not an option. I do have a handful of expo programmed in for the joystick which does help, until the operator “dumb thumbs” kick in.
MOT_SLEW_RATE applies to throttle control. It makes no sense to unilaterally apply it to steering (though on a skid steered vehicle, it probably should apply to left and right throttle through the steering controller, which it may not, and that would indeed be an oversight).
And again, MANUAL control is just that. Limit the slew rate on the input side.
MOT_SLEW_RATE works beautifully, including in manual mode.
If it was applied to ALL motor functions, skid steering included this would resolve my “problem”
The issue is with controlling the momentum of the drivetrains.
Ok, since I initiated the tread, I tell you what I did…
I modified settings on the trasmitter (Taranis), slowing down lateral input. Problem solved.
Throttle output was already filtered by ardupilot code.
I understand that in recent releases of ardurover code this bug is fixed, and it is possible to filter also the later channel by parameters.
But for the time being I did not want to upgrade the software, risking “collateral damages”
Im on very recent version of rover and i can confirm this bug still exists, its definitely an oversight when using differential thrust. It should apply to the motor slew for any function (for aft or steering) the transmitter settings are the bandaid and the fc parameter works as intended even in manual mode for fwd rev control, but if you quickly turn from left to right it will quick reverse both motors with no limit of slew rate. I have 20 inch air props on my differential thrust boat and can’t let that happen, its a pity the slew rate parameter is only applied to the for aft function instead of to the motor chanel as it should be @rmackay9 are you able to shed any light of the intent of the motor slew rate parameter and see if this was an oversight that it doesn’t limit the actual motor slew and instead only the fwd rev function slew rate?
Recently I tried a configuration for a balance bot with this dual DC ESC:
without any success, and it may be related to this problem.
This ESC is cheap, includes a BEC, comes in several current ranges, and can provide independent outputs (switch for independent/mix). However, it is fixed (not possible to program it). For a balance bot, a pulse of 1500µs would not move the motor (with some dead zone) and more/less would move it forward/backwards up to 2000/1000µs. With two RC signals you get the equivalent to four DIR1/PWM1/DIR2/PWM2, convenient for FC’s with six servo signals.
No matter what ArduRover parameter I tried, it was impossible to stabilize the balance bot in Hold/Manual/Acro. Wheels were moved very strongly as soon as arming the balance not on ground, or arming with it lifted and resting it on ground, even in Hold (no transmitter influence).
I have assembled balance bots with six servo signals: four as inputs for wheel encoders, and two as RC outputs, with an Arduino transforming the RC pulses to DIR/PWM, and this worked. It seemed that using this ESC the Arduino would not be needed, but I couldn’t stabilize the balance bot, not even approach it.
In R/C electric car racing this slew rate limitation is currently done at the transmitter, so that no matter how fast you move the throttle the car does not skid (pulse width change rate is limited). This is not needed for gas cars.
Anyone has used this dual DC ESC with ArduRover? Some other thought to stabilize a balance bot with it?
use a Hbridge motor driver like a L298N, and set ardupilot motor out to BrushedBiPolar. it will give more direct output.
those dual channel RC tank escs are a pain to use. they auto calibrate on every power up so they change the centre point on every startup. I have one in a rc boat and sometimes I have to switch it off and on a few times before it will work.
Obviously this dual DC ESC includes two H bridges, since it can move motors in both directions. A continuity test confirms it.
In fact, I tried it with two different balance bots:
One already with MOT_PWM_TYPE=0, and an Arduino changing RC pulses to DIR’s/PWM’s, so as to substitute the motor controller used and the Arduino. Impossible to stabilize.
Other having MOT_PWM_TYPE=3, so as to substitute the motor controller. Also impossible to stabilize, but the feelings trying it were the same, even the balance bots were different.
Yes! It requires a hardware trick, but the result is incredibly good.
Certainly. I can’t find documentation, but my feeling, after oscilloscope observation, is that the timing is fixed:
1000µs full (almost) on one direction.
1500µs no movement, with dead zone.
2000µs full (almost) on the other direction.
However, perhaps refining the slew rate limitation (pulse width change rate with MOT_PWM_TYPE=0) for both output signals would work for balance bots and other dual motor configurations, as for throttle on the transmitter for R/C electric car racing.
