After some decent results described in my previous post regarding PID tuning for high winds: http://www.diydrones.com/profiles/blogs/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...
Comments
You all may already be including this in the discussion, but I don't see any reference to it all all, so...
General aviation (and larger) airplanes now use a technique called "GPSS" to make a smooth transition between flightplan segments. In a nutshell, this is a calculation made before arriving at the waypoint that determines when to start the turn to the next segment. The airplane flies very near to, but absolutely over, the waypoint. Instead, it uses ground speed and track error angle to make a (very) good estimate for when to start a standard rate turn to the next segment's heading. Once the turn is done, heading may have to be adjusted slightly to correct for actual cross track error, but there is no overshoot and/or s-turns to get established on the new segment.
The trick is to anticipate, not react. Could this be incorporated into APM?
i accedently appplied my change to the master git repo, and wasnt meant to, so undid it.
i would probly just make the changes above in navigation.pde and try that.
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?
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);
}
AND
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.
Thanks Michael, I will work on setting up a build environment and try to test out those changes this week.
OR what i just undid from this commit
https://code.google.com/p/ardupilot-mega/source/detail?r=5265e962e5...
in attitude and navigation.pde
the 2 you are looking for are
https://code.google.com/r/meee146-hil/source/detail?r=39f0bda5cc2c2...
https://code.google.com/r/meee146-hil/source/detail?r=5d7954b1d0b6e...
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
Michael, are you specifically referring to this changeset?
https://code.google.com/r/meee146-hil/source/detail?r=39f0bda5cc2c2...
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?
have a look at the mod i did here
https://code.google.com/r/meee146-hil/source/list
this is using ryans method. seewms to work very well, in the sim.
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.
-
1
-
2
-
3
of 3 Next