Pidachieved opposite to piddesired?


I am tuning my skid steer rover and I have a question regarding the pidachieved vs the piddesired data I am seeing. I have tuned the steering in acro mode to the point where I am able to steer and control the rover quite well. However in auto mode he rover behaves erratically.

The tuning data below (acro mode) appears to show the pidachieved values head in opposite direction to the piddesired, rather than pidachieved following piddesired. Could this be related to he erratic behavior in auto mode?

As always, any advice is much appreciated.

Kind Regards,


Stephen, I think it could be that you need to reverse the action of one or both of the servo outputs? I do not use Acro, but in manual, I could have my servos acting the opposite of what they should be but not really know it in manual if I have my my corresponding RC channels reversed also. But when I go to automatic, where the RC controls are not acting, the auto steering would be opposite. So, you may need to reverse the servo action and then you may need to reverse your RC action. Here are the parameters I am talking about. (And I hope I am making sense!)

Agreed. You need to reverse the outputs. I remember struggling similarly. Get the flight controller to sync with its own expectation and then use some mixing on your transmitter to match stick direction with the turns.

Additionally, I’ve found acro mode to be nearly useless with a skid steer setup (though it can be useful for tuning). The rover will not perform pivot turns well in acro mode (at least not that I’ve been able to achieve). I use manual mode to control mine when it’s not using flight controller automation.

1 Like

I’ve gotten my skid-steering vehicle to drive quite well in Acro mode but it was a bit of a struggle with very large vehicles perhaps similar to what @Yuri_Rage and @ktrussell regularly drive. They key problem I found with large vehicles was when turning (aka pivot turns) the vehicle would overshoot the target or keep wobbling around after the pilot released the sticks. This was caused by I-term build-up in the steering controller and I found it helped to make the feed-forward slightly larger than required which led to a negative I-term build-up which helped.

If you have an onboard log of it driving in Acro mode I can see if I can provide any suggestions.

I agree with the comments above about the outputs being reversed if Manual and Auto are being used but I would have though that if Acro worked then Auto would as well. Using MP’s motor test feature usually exposes the issue.

1 Like

The problem with acro mode, at least in my observation, is that the vehicle always seems to want forward momentum. I can’t seem to achieve a pure pivot turn. I have excellent control while driving forward or back, but a pure, in place pivot turn never seems to go as I intend (the inside wheel doesn’t reverse like it does in manual mode or even auto mode).

As such, when driving manually to trim around tight obstacles with the mower (gas powered zero turn mower with a 48" deck), I have less control than with pure manual mode.

As I’ve alluded before, sometimes desired ArduPilot behavior for the wider audience isn’t exactly suited to this unique case, and I don’t find it hindering. I simply make little use of acro mode.

If pure pivot turns are indeed intended in acro mode, I’m happy to provide a brief log of a session contrasting manual vs acro modes.


My 2 cents in case it helps Stephen or others: I have never used Acro mode. I think I flipped to it once or twice but didn’t know what to do with it. LOL. For short manual moves, I use manual. I do use Steering mode a good bit if I am “manually” driving the mower a long distance. The advantage of Steering is that it will stay straight toward a heading even if there is a little misalignment in the left and right outputs that would cause Manual mode to veer off.

I use Steering mode to tune the steering and throttle loops.

I will have to try Acro sometime.

I tuned using acro mode, per the documentation. It’s the only time I’ve ever really used it. Perhaps I’ll give steering mode a shot, since that seems useful the way you describe.

I used Steering for tuning because I think in Randy’s video on tuning, he mentions using Steering or Acro. For some reason, I just chose Steering and never looked back.

Makes perfect sense since both modes put the flight controller’s PID algorithms into the loop. I have a six position flight mode switch and have them programmed with HOLD, MANUAL, AUTO, MANUAL, ACRO, STEERING, in order. I double MANUAL mode so that no matter which way I turn the dial away from AUTO, I’m guaranteed instant manual control.

A Lua script engages the parking brake in hold mode, so I tend to go to manual to stop movement and then apply hold mode if I want to be sure it stays in place. A switch directly to hold mode is too abrupt with simultaneous parking brake engagement (I could and probably should script a reasonable delay for brake actuation).

But perhaps we’re steering this discussion a bit off topic (pun intended).


Personally I never using steering mode but I very often use Acro. Use whichever you find more useful though of course, I suspect you two drive your vehicles around more than I do because I mostly just do short tests and demonstrations.

The big difference between the two modes is that in acro the pilot controls the turn rate while in Steering it is the lateral acceleration. … so given the same steering stick input, Steering will rotate more quickly at low forward speeds compared with high speeds. Acro mode is rotate at the same rate regardles of the vehicle’s forward speed.

Both modes use the same underlying turn rate controller though… it’s just the input to the controller is calculated differently.

@Yuri_Rage, I’ll take that Acro log whenever it’s convenient for you to produce it…

1 Like

Hi guys. I’ve had some success. As suggested I swapped the servo outputs (1 and 3) and reversed the transmitter steering stick on the transmitter and as shown below (in acro mode) the pidachieved followed (more or less, I might still do some more fine tuning) piddesired. And auto mode is now working properly. Very Happy.

Thanks very much for your help. It is very much appreciated.

Kind Regards,



That looks pretty good in my opinion. Happy for your success! I hope you will show us your machine sometime on YouTube or otherwise. I would love to see it and hear all about it.

1 Like

@Tractor_Pilot, nice job. That looks fairly well tuned.

Randy, I emailed you a .bin log where I drove a similar pattern with sharp turns and pivot turns using manual, acro, and steering modes. There’s also a brief section toward the end where I selected Auto mode for comparison. Acro mode behaved a little more nicely than I recall from previous attempts, but it still proves a bit difficult to use close-in to obstacles. Steering mode was slightly easier to control around trees/bushes.

Tip for anyone using a Cube-series flight controller - wrap a piece of masking tape around the outboard edge of the micro-SD card and leave a little flag that will stick out so you have something to grab when you want to remove the card. Far easier to transfer your logs straight from the card than going through Mission Planner.

1 Like


Txs for the logs. In general the vehicle looks pretty well tuned but I noticed a few things (not all necessarily problems, just observations):

  • ARMING_CHECK = 0 <-- I wonder why this is required
  • RC3_DZ = 0 <-- this means the vehicle will always be commanding a speed forward or backwards. I think this should be set to at least 10
  • RC3_MIN = 1493 <-- I guess the vehicle can’t move backwards?
  • MOT_THR_MIN,0 <-- it might be good to set this to take into account the motor deadzone (wiki). If possible use MP’s motor test screen to test the motors in reverse as well as forward.
  • NAVL1_PERIOD = 2 <-- I’m surprised at how low this value is. I’ve almost never seen values under 8 well although it seems to be driving missions OK although the desired turn-rate (from the navigation) is a bit noisy.
  • MOT_STR_THR_MIX = 0.5 (the default) <-- I’ve found on some skid steering rovers it helps to increase the priority of steering over speed. So increasing this to 0.8 or even 1 will make the vehicle slow down if it needs to in order to turn at the desired rate.

EDIT, I think we might have a code problem related to limiting I-term build-up when the motors are saturated. This is a graph of the motor outputs and throttle/speed controller’s I-term. The vehicle cannot reached the target speed of about 1.5m/s because (I think) the motor are fully saturated trying to achieve the speed and turn rate… so we shouldn’t be building up I-term. I’ll add this to the list to be investigated


Hi guys. Here is a youtube video I have just uploaded of some testing I was doing yesterday ( I’m not using RTK GPS in this test)

@rmackay9 I note your comments above about the I term. I found making I zero seemed to help my tuning, although my mixed up servo outputs might have been the problem as well. I will do some more tuning to find out more.


Randy, thank you so much for the quick response.

I disabled the arming checks WAY back when I was first testing GPS yaw because I wanted to be able to drive in manual if I accidentally achieved a completely useless navigation system. I guess I just left it that way. At this point I can probably re-enable a few common sense options here.

For skid steering, I’m using RC1 and RC2, such that all rover steering is controlled by the right stick on the transmitter (pitch and roll channels). SERVO1 and SERVO3 are actual heavy duty servos (not ESCs) connected to the hydrostatic control arms that one would normally push and pull to manually drive from the seat. Not only can I drive in reverse, but I can technically go faster in reverse due to a physical limitation of the servo linkage in the forward direction.

RC3 is completely unused and has no effect The actual engine throttle servo is SERVO4, mapped to RC10 and is independent of navigation, since it’s a hydrostatic system that relies on increased engine RPM predominantly for power rather than vehicle speed, though both are affected to some extent.

In fact, perhaps I should’ve used more engine RPM during this test to avoid the saturation you mentioned. I had the RPM lower than I typically use for mowing, and the mower was likely unable to achieve the desired speed at full SERVO1/3 forward throw. The mower can indeed achieve 1.5m/s (~3.5 mph) with no problem, but my test run was likely power (and thus speed) limited by the low engine RPM. I should’ve cranked it up to “normal” RPM for mowing to give you a good test case - which I can certainly do if you like. But maybe my low RPM error was serendipitous in revealing the I-term buildup error :smiley:

There is very little dead zone between forward and reverse. What little dead zone exists is actually physically present in the linkage between the servo horns and the steering arms, such that the trim values cause the servo position to fall in that physical dead zone with neutral RC transmitter stick, reliably stopping motion. If I understand correctly, accounting for that dead zone might cause snappier transitions between forward and reverse, but I’m uncertain that it’s desirable for this control scheme. I’ll explore it a bit.

EDIT: Now that I think about it, because it’s physically present and not an electronic feature, the “dead zone” manifests anytime the servo reverses direction, which could be anywhere in its throw range. With that in mind, I doubt there’s much to be gained by defining a dead zone around the neutral position…or else I have a conceptual misunderstanding of that parameter.

MOT_STR_THR_MIX is definitely one to check out. I’m excited to change it and discover the effects.

The NAVL1_PERIOD surprised me, too! I think in order to use a value that low, the rest of the tune has to be very precise, which I hope I’ve achieved, though you mentioned a noisy turn rate - I’ll investigate.

I arrived at that low NAVL1_PERIOD value very recently during my exploration of the BendyRuler algorithm for fence avoidance. I discovered that decreasing it caused a desirable aggressive turn back to the waypoint path once the fence was cleared, keeping the margin tight on the back side of the fence. I just kept decreasing it until I saw something I didn’t like (which happened at 1, where the oscillation was just too much).