deviation from waypoint track

Hi forum,

I came along this beautiful flight analysis Wiki entry from Tridge.
But even by this help I can't resolve my current issue.

My plane is an EasyStar comparable plane without using ailerons.
APM2.5 with V2.73.

Testing waypoint flights without any wind I still got major
deviations. Here my rectangle running it three times. My
analysis is the 250m line between waypoints 41 to 48 on
the second loop. I did this flight several times by playing
with different PID values as proposed in the threads.


The pictures show the deviation to the track and the roll values.


It seems that Roll follows NavRoll quite well.

But NavRoll comes up somehow very late.

The deviation is switching at tick 15 (15*0.2s => 3s) to the negative side.
NavRoll is going much later at tick 89 (89*0.1s => 8.9s) to the negative side.
I would expect that this should be following somehow very much faster.

Attached the paramter setup from the beginning of the log.

Now I need a hint how to analyse further.

thanks in advance
Wolfgang R.

2013-07-22 21-48_1_start.log

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –


  • As the weather wasn't nice to replay such flights I had time to look into

    the code first time.Fortunately my problem seems not to be related

    to GPS things or PID-controller setup but to my route and waypoints.

    The route is very short and the waypoints too close and the waypoint

    radius must be smaller as well. That should give the controller the chance

    to establish a better track.

    Now I understand the page 'Tuning the new L1 controller' better.

    I did not dig into the mathematics and the inner loop of the PID

    controller but one point seems a bit odd to me.

    The waypoint calculation is establishing a new angle to the next

    waypoint only once it is passing the current one. This nav_roll_cd

    value is feed in top level to all calculation cycles up to the next

    waypoint. Its impact is reduced by a smaller getting error angle

    but if it's catched in a 'bad' cycle it still might have too much impact.

    From my feeling this value should be re-sampled and smoothed

    somehow. But maybe the algo can deal with it.

    There is a remark in the code that this is a time consuming calculation

    (3.5ms). This might be as well a reason to do it only once.

    Wolfgang R.

    once it is passing a waypoint.

This reply was deleted.


Laurie J. Troy liked Jasper Kueppers's profile
Apr 1
Timothy Miller liked Joseph Udofia's profile
Mar 18