Slippery caused overshooting

Pivot turns are perfect for the rover on dry flat surface, however when test after a rain, rover will slip over and cant stop at the right spot, which cause overshooting. This happened for down slope as well. Are there any methods/parameters that can optimize this situation?

If you want good performance with bad traction, you have to tune for that scenario and accept that it will likely be more sluggish on dry ground. I don’t think ArduPilot provides a dynamic control mechanism to account for surface conditions, though you could perhaps get ambitious with some onboard scripting.

First, try decreasing ATC_ACCEL_MAX, ATC_DECEL_MAX, and PIVOT_RATE.

2 Likes

To add a bit more clarity, AP does use layered PID controllers for the pivot turns. Perhaps it is too much detail but it uses a P controller for the higher level angle->desired rate and then a FF+PID for the lower level turn rate control. So this should be able to deal with a some amount of variability in the surface but there will be some limit where it can’t do both well.

I agree with Yuri’s suggestion to reduce the maximum desired pivot rate because that will make everything easier for the controllers.

Maybe post a .bin log of the two cases and maybe I can give some advice on tuning parameters.

Hi Yuri and Randy,
Thanks for the valuable comments!
I tried the parameters and agreed there is a trade off between sluggish movement and overshooting, if we use aggressive config for normal scenario then overshooting maybe not avoidable for slope/wet surface. On the other hand, sluggish costs extra time and battery life especially for rover mower that may have thousands of waypoints, 2 seconds delay each turn accumulated to hours.
Just wondering if we can take advantage of the sensors for an enhanced algorithm, that can recognize each situation and adjust config accordingly.
Btw, for PIVOT RATE, the setting can change the overall turn speed, but the turn is not smooth, it starts with a sudden acceleration, and after the turn, there is about half second delay before heading to the next wp. Are there parameters to control the acceleration and delay?

It sounds like you have some competing issues.

The sudden acceleration should be controllable by decreasing ATC_STR_ACC_MAX.

The delay afterward is a little more complex. In my experience, that delay results from a ATC_STR_ANG_P term that is too low, resulting in an undershot turn and subsequent delay as the control logic overcomes the induced problem.

You most likely need a more aggressive ATC_STR_ANG_P term after the reduction in PIVOT_RATE. However, that could work against you on a slick surface, since the vehicle will tend to build some initial wheel speed while slipping, then turn a bit quickly as traction is gained, and then possibly overshoot as a result of that wheel speed buildup and lack of traction to decelerate combined with the more aggressive P term.

If Randy’s analysis of your logs still fails to provide a happy medium between the two scenarios, you could conceivably have a more aggressive tune for dry surfaces and a less aggressive one for slick ones and then switch between them via an RC channel and Lua script to set the parameters.

If you wanted to get a little fancier, that script could include some logic to switch between parameter sets on the fly if a lack of traction is detected. To detect surface conditions, you could compare throttle setting vs velocity or acceleration and/or watch for turn overshoots by monitoring reported heading vs bearing to waypoints.

1 Like