The Greatest Puzzle of All Time - Path Wobble

In the link below are the logs as well as the KML path (Google Earth) files showing two ‘missions’ on the same Flight Plan.

One is 99% perfect except for one waypoint ‘Oops’, and the other is just not acceptable at all.

The hardware is exactly the same in both ‘missions’.

Nobody to date has been able to work out why the one has wobble and the other one not.


DropBox Files

Hardware or environmental reasons. The PID gains for steering are too high - reduce the P or FF values.

They both osciallte, but one is slightly aggrevated - probably because of hardware or environmental reasons.

1 Like

Thanks Nathan,
But why is one perfect and the other one terrible while using the same settings and in the same conditions?
That is the answer I’m looking for here.

What changed between 185 and 186 to create such a dramatic different result?

Oh yes, and there were no hardware changes either.

The Puzzle … What changed??

The EKF and environment. The computer did the exact same math, but with a different assumed “zero” from the accelerometers and gyroscopes from boot. The INS parameters are different because of a different physical state during boot. The difference is very slim, but it obviously had a bad effect because of the unstable PID’s.

What can I do to resolve this Nathan?
Did I do something wrong on 000186 compared to 000185?

Lower your ATC_STR_RAT_P

You didn’t change anything – I get that.


You might have given me a very important clue!

185 was booted on land, and 186 was booted on the water, could this have made a difference?


Some interesting info here -

Do increase a period. :wink: I need to read up on that type of controller - I may need it in my work soon - but from what I understand about it either a period or damping should be increased. Most likely period, my guess would be around 1.5x times.


I looked back on your other threads, and I think I might have given you some bad advice above here – looking at your STER data shows me that your desired and actual turn rates match very closely in both logs. Don’t change your P and FF values yet.

Seeing the desired lateral acceleration osciallate means that the navigation controller is the one that is causing oscillations now. Your L1 settings -


Probably need to be tested and optimized. Try increasing the period and decreasing the damping slightly. If I remember correctly, we had you increase your TURN_MAX_G from previous missions so that you could turn sharply on corners. Unfortunately that probably allowed the navigation controller more authority during straight runs - and now its settings are causing some oscillations.

That is really interesting, I will certainly try that.
Thank you once again for your efforts Nathan.
I think I need to go to a local dam and camp for a few days so I can test as soon as I get the info.
Where in the world are you from? I am in Durban South Africa

Iowa - Central United States.

I don’t know if you can, but the single best thing that saves me time tuning is a good telemetry radio (RFD900 or something similar). That allows me to make parameter changes in the middle of a mission to see the outcomes. Most of the parameter changes here do not affect hardware, and they do not require a re-boot to see the effects. They are live, so you can try them as you go. It might save you a lot of time.

Ok, so there is an 8 hour difference.

That is good advice, I need to get the RFD900 as I have been looking at it for a while now.

It still boggles my mind that the controller is actually instructing the craft to start the wobble without any change from the ‘environment’.

The rover isn’t “self-learning,” so it doesn’t surprise me that it can be unstable at times. Sometimes the smallest things can throw it off when it’s very close to being unstable.

It’s difficult for the same parameters to work on all vehicles. Some are tiny RC cars while others are houseboats. It’s crazy what ardupilot can control once the tuning is complete.

For what it’s worth, these are the parameters compared from log to log. All of the INS parameters are changed on boot, so that’s why they change. BRD_SAFETYOPTION and RC4_DZ were probably changed by you, but the rest change every boot.

1 Like

I don’t know if booting up on the water is the way to go.

1 Like

Could it be that the code is not tilt compensating the compass? A slight roll in the boat will give a compass change of a few degrees which will cause the rudder to try to correct this imaginary course deviation introducing a wobble into an otherwise straight path.

Put the boat on land and introduce roll and see if your yaw changes.

1 Like

The craft is doing EXACTLY what the controller is telling it to do.

It is at this 3:55:45 to 3:56:00 point that we need to determine what changed in the controller code to tell the craft to start wobbling.

And then again at 3:57:15 what changed back to normal again to tell it to go straight again.

If the craft is heading in the right direction, the only thing that could possibly change when there is no wind, current or chop, is the compass going nuts IMHO.

Do you have the compass readings at that time?
What happens to the compass if you roll the boat on the bench?

If the software allow you change the smoothing of the compass readings, You probably only need to act on compass changes once per second so smoothing over 10 or 20 readings (assuming read rate is once per 100ms) should still give you enough info to not oversteer on gentle turns.

Not sure if ardu pilot uses the gyro and compass for yaw control, if so, adjusting PID only on the yaw control might not be enough but would help.