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.2013-07-22%2021-48_1_start.log
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.
You need to be a member of diydrones to add comments!
Replies
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.