Quest for the perfect flight path...

After some decent results described in my previous post regarding PID tuning for high winds:, I wanted to see what it would take to get the best possible flight path with the least amount of flight planning possible. The end result was a three waypoint 90degree corner, as shown below.



The problem of course is wind... The above path was with no wind whatsoever, as soon as high winds are added the entire thing falls apart completely, as the plane often missed the last waypoint in the downwind turns and has to circle back.


I figured that if I could get a near perfect flight path with just three waypoints on each corner, what if I went back to using a single waypoint, but simply increased the waypoint radius such that the plane had enough room to make a perfect turn. In theory this should at least be flyable in high winds without having to circle back to hit any of the waypoints...


Unfortunately this failed as well, due to what I think is the Xtrack entry angle, and possibly a bug, or at least odd behavior from my understanding.


It appears that the plane always tries to approach the path at the Xtrack entry angle after a turn, but it also always overshoots the track by a similar angle then has to correct itself. I created the following path by starting with a 90degree Xtrack entry angle at waypoint #2, then cutting that in half for each subsequent waypoint until waypoint #5 where it was 11degrees:

I can understand some overshoot after waypoint #2 (90degree entry angle), and even #3 (45degree), but #4 (22.5degree) makes no sense to me. Its such a shallow angle there should be no problem whatsoever straightening out at the track and following it right on, especially with a Xtrack gain of 225 as shown below, but Ardupilot is still pointing the plane *off* the track (based on the green line) until its well past, then it finally corrects and gets it right.



Can anyone explain why the Xtrack entry angle causes the track overshoot after every waypoint, regardless of how low the entry angle is set? Of course the major problem here is that if there is any wind at all this angle needs to be set sufficiently high enough for it to correct for the wind, otherwise the plane is hopelessly lost. 


Something seems strange to me...



Views: 2105

Comment by Squalish on October 27, 2011 at 5:09pm

For an auto-land, at minimum with a flat field you're going to have to be able to tell it "After this point, minimize roll at all costs, but reduce altitude steadily despite missing waypoints".  A landing strip is a more complex extension of that, with a horizontal boundary component that cannot be exceeded.

Comment by The Old Flyer on October 27, 2011 at 6:21pm


Remember, those flights were probably made with the small WP Radius and the higher Xtrack gain.

The airframe is a Telemaster.  We will fly tomorrow. 


Squalish, You are right.  A new navigation schema may be needed for the landing task.

Even if you do get the plane going "straight" in a cross wind, the aircraft heading on touchdown will be off and there is a lot of wing rocking as the plane flies down the "streight" path.

Comment by Mike on October 27, 2011 at 7:24pm

I've gotten Xplane to land the PT60 with 30kt cross winds 90degrees to the runway. I was just about to make a blog post about it actually.

Comment by Michael Oborne on October 29, 2011 at 4:53am

have a look at the mod i did here
this is using ryans method. seewms to work very well, in the sim.

Comment by Mike on October 30, 2011 at 4:29pm

Michael, are you specifically referring to this changeset?


This branch appears to be for Heli HIL only? I assume your changes could be pulled into the arduplane code base relatively easily for testing?

Comment by Michael Oborne on October 30, 2011 at 4:53pm

the 2 you are looking for are

what these 2 do is fix the crosstrack bearing calc. if you have ever noticed that the bearing the plane holds is slightly off the track, this is because the crostrack bearing is calced from when you hit the WP radius to the next wp. ie it could be 50m out at the start of the track.
the other is using ryans atan code and ground speed to coordinate turns.

and also change the nav_bearing to COG instead of plane yaw. as the plane could be pointing any direction. the bit we care about is COG.


ive tested thsi a fair bit and it works well, crosstrack is usauly within 20 ms. you do need to either increase your max bank angle or increase your WP radius to get non nice corners

Comment by Michael Oborne on October 30, 2011 at 4:54pm

OR what i just undid from this commit

in attitude and navigation.pde

Comment by Mike on October 31, 2011 at 8:21am

Thanks Michael, I will work on setting up a build environment and try to test out those changes this week.

Comment by Michael Oborne on October 31, 2011 at 4:27pm

there is only 2 changes made to the code with this one.

static void calc_bearing_error()
/* if(takeoff_complete == true  || g.compass_enabled == true) {
  bearing_error = nav_bearing - dcm.yaw_sensor;
 } else {
  // TODO: we need to use the Yaw gyro for in between GPS reads,
  // maybe as an offset from a saved gryo value.
  bearing_error = nav_bearing - g_gps->ground_course;
// }

 bearing_error = wrap_180(bearing_error);




static void reset_crosstrack()
 crosstrack_bearing  = get_bearing(&prev_WP, &next_WP); // Used for track following


and as you see, i had wind on, and it was quite accurate.

Comment by Mike on October 31, 2011 at 4:43pm

Michael, I'm a little confused now, there appears to be three separate changes, some in GIT and some not? Can I checkout the latest master branch from GIT to test out your changes?


You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service