Skid steer issue

Pivot turns work really well on my mower, it stops right on top of the waypoint and performs a perfect pivot turn towards the next waypoint BUT it then pulls away at an angle, sometimes up to 45 degrees, before correcting itself and heading for the next waypoint.

Looking at the graph of the servo outputs (and by watching the mower wheels) it’s pretty clear what is happening. When the pivot turn completes the servo for the reversing wheel is at a much lower value than the one for the forward rotating wheel and it takes a while for it to catch up. This means that the wheel which was going forward in the turn starts moving first, causing the mower to veer off course.

I tried setting WP_PIVOT_DELAY to see if the 2 servos settled after a while but it just puts a delay in before again setting off at an angle.

Presumably this is not the intended behaviour, what’s required is for both servos to return to neutral on completion of the turn and then ramp up together so the mower sets off in a straight line.

So am I missing a parameter somewhere that will re-centre the servos after a pivot turn?

I’ve changed the title of this topic from “pivot turn issue” to “skid steer issue” because the problem still exists when pivot turns are disabled (WP_PIVOT_ANGLE=0).

If the mower makes a sharp turn in Acro mode and then stops the servos don’t return to neutral but settle with an offset in the direction of the turn and remain like this indefinitely.

This offset isn’t enough to make the mower move because it’s below the minimum throttle. However when the mower moves forward again, even if it’s a long time later, one servo has to move further than than other so it lags behind, causing the mower to set off at an angle.

I can see this happening when mowing. The mower makes a nice turn towards the next waypoint then veers off a bit when it sets off resulting in a curved path and missed bits of grass.

That’s an interesting issue. Can you post a full logfile?

SERVO2_TRIM and SERVO3_TRIM would likely be the culprits.

Like Oli says, share a log.

I have a slight trim of 1463 vs the default of 1500 for both the servos to centre the deadband but it seems very unlikely that this would be the cause since the bias follows the direction of the turn and is much larger than the trim.

Are you saying you don’t see this on your mower?

No, there is no turn direction associated bias on my mower either by perception or by log review. The servo outputs always return to the trim values. What I do see is a bit of bias on the initial forward motion after a pivot turn that is clearly influenced by the direction the castered front wheels are pointing. That is a physical effect that is unavoidable but can be mitigated through good tuning.

I think you’re looking at the live tuning graph in Mission Planner in these screenshots. It is often a bit quirky in scaling and should probably not be used to make observations as fine as the ones you probably need. Again, post a log. It is almost pointless to continue discussion without it.

Try to plot the PID achived/desired values for yaw rotation. Do you use any ATC_STR_RAT_I gain in the acro mode tuning?

Thanks for the replies guys.

You hit the nail on the head Sebastian. I did have some ATC_STR_RAT_I which was causing the steering error to build up to the point just before the mower moved. Because there is a large deadband on this mower this resulted in a significant offset between the 2 servos.

Putting ATC_STR_RAT_I to 0 results in both servos always returning to the trim point but I’ve also significantly reduced the deadband in case I do need some. I could do this because I have a processor between the flight controller and the mower so I was able to map the servo output around the deadband.

Thanks again for your advice Sebastian.