Well, chalk up another one to the limitations of sims. Today's return-to-launch (RTL) testing was a mixed bag. When the Superstar was heading off away from us and I enabled the autopilot, it nicely turned back, but when it got overhead it went into a death spiral and I had to disable the autopilot to recover. This happened multiple times, despite it working fine in the sim. Perhaps this was due to the wind (10-12 mph) or the airframe, but the software should be doing a better job regardless.
I think we need to work harder on our "circle overhead" algorithm and otherwise put a little more AI in our navigation routines. This is pretty normal for this stage of development and we'll get there. Meanwhile, it was nice to fly on another beautiful day in the Bay Area.
Strangely, I think I'm seeing the same thing happen to me in real life. Occasionally when I turn on the ardupilot, it will just turn the rudder completely one direction and it will lose altitude pretty fast (because it also spools down the throttle! need to move that up a bit since my plane is a bit heavy) Letting it go as long as possible proves that it turns more than 180* before I have to recover it - it seems to be locking itself into turning one direction forever. Will do some more tests today.
Chris,
As you said earlier, simulations have their limits. Unless you have a bug, there is probably something missing in your simulations. Do you include the internal dynamics of the computations that go on inside the GPS?Based on tests that I ran on the GPS receivers that I have used, it is clear that there is filtering going on inside the GPS on the navigation information, so that what comes out of the receiver has a delayed, dynamic response to the motion of the plane.
In any case, there are other effects as well that are hard to capture in a simulation. Its been my experience that my actual flights never behaved like my simulations. Once my "GentleNav" was reliable and stable, I abandoned simulations.
One thing I did notice in general, that was predicted by both theory and simulations, was that yaw control tended to be less stable traveling into a moderate wind. That is because of the difference between GPS speed and air speed increased the effective yaw feedback gain. As the plane makes a slight change in direction with respect to the wind, it makes a large change in direction of course over ground. In the limit as the windspeed approaches the airspeed, small changes in the direction of the plane can cause the course over ground to swing by plus or minus 90 degrees.
Stability also depends on air speed, as the plane gains speed, depending on your control, it can definitely go into an ever tightening spiral. This happened to me a lot in the early phases of development. The approach I took to solving it was to back off on the feedback gains and airspeed. What I have right now is very stable and reliable.
Of course, all of my experience is with gyros, accelerometers, and GPS, so it might not shed much light on your approach.
But back to your hypothesis that holding the rudder at 15 degrees forever is the problem. You may be onto something. The answers to the following questions might help me judge whether or not that is the problem. How many circles do you get before you get the spiral? How long does it take? Is there any other way to find out whether the rudder is staying within the 15 degree limit? What would you say is the diameter of the initial part of the turning circle right after the plane passes through the return point?
In any case, if you think that you do not have any problems with bugs in your code, you might try limiting the rudder throw to a smaller number, say half of what you are using.
Bill
plane.in - This website is for sale! - plane Resources and Information.
This website is for sale! plane.in is your first and best source for all of the information you’re looking for. From general topics to more of what y…
Well, we do have travel limits on the rudder throw (15 degrees) so that shouldn't be it, unless there's a bug in the code. I'm just wondering if holding the rudder over at 15 degrees pretty much forever while it circles is actually too much for a prolonged period of time and overcomes our stabilization, leading to a spiral.
Anyway, more testing will reveal the answer. And yes, we are using Atan2 (see GPS_Navigation tab)
Chris,
Perhaps you have a bug, I hope you find it, it would be a shame to create a series of way points if they are not needed.
Are you saying that the rudder is throwing more than you intended? The last step I always include in my rudder calculations is a throw limit.
It may be that VoiceOfReason was on to something, there may be a bug when you get very close to the return point.
Also, you do have to use a four quadrant arctan calculation that treats X and Y separately instead of using the ratio, otherwise you will produce a two quadrant result and will have problems for sure. I assume that you are computing ATAN2?
Bill
Bill
That (steer toward origin, limited turn rate) makes sense and is what we intended. It may be that we have a bug that is breaking our 15 degree steer limit at waypoint crossover. Or it may be that we need to do more than just limit the rudder throw, but also limit the actual turn rate by monitoring the GPS track data. More testing will confirm...
Chris,
I can't help you with your problem, but I have a couple of general comments on the subject:
1. ATAN2(X,Y) is recommended over ATAN(Y/X), it works in all 4 quadrants. I use a CORDIC implementation, its very fast and accurate.
2. I have been using RTL with circling afterward without any problems, using GPS and gyro to estimate yaw angle and bearing to launch. The algorithm is very simple: steer toward the origin, with limited turn rate. Once the plane goes past the origin, it eventually settles on a perfectly circular path. It did have some trouble with stability with earlier versions of the algorithm that included cross-track error, but once I eliminated the use of cross-track error, it worked just fine.
3. The effective steering gain of a simple steer to waypoint algorithm increases as the plane approaches a waypoint, which will trigger instability if the stability is marginal.
Bill Premerlani
I haven't looked at the code, but check that you don't divide by zero or your ATAN function doesn't blow up when your current lat/long = home lat/long (or very close to it).
Well, the autopilot works fine with the FMA in other situations, such as going to a waypoint (heading back to launch). So there's no problem coordinating turns, and steering with the rudder while the ailerons are auto-stabalized works great. (We test that by turning on the FMA and just flying around in RC mode with the rudder and throttle, exactly as ArduPilot does--it works fine).
I think this is just a code problem. We're working on it.
Comments
The formula is:
and my algorithm is taken from here.As you said earlier, simulations have their limits. Unless you have a bug, there is probably something missing in your simulations. Do you include the internal dynamics of the computations that go on inside the GPS?Based on tests that I ran on the GPS receivers that I have used, it is clear that there is filtering going on inside the GPS on the navigation information, so that what comes out of the receiver has a delayed, dynamic response to the motion of the plane.
In any case, there are other effects as well that are hard to capture in a simulation. Its been my experience that my actual flights never behaved like my simulations. Once my "GentleNav" was reliable and stable, I abandoned simulations.
One thing I did notice in general, that was predicted by both theory and simulations, was that yaw control tended to be less stable traveling into a moderate wind. That is because of the difference between GPS speed and air speed increased the effective yaw feedback gain. As the plane makes a slight change in direction with respect to the wind, it makes a large change in direction of course over ground. In the limit as the windspeed approaches the airspeed, small changes in the direction of the plane can cause the course over ground to swing by plus or minus 90 degrees.
Stability also depends on air speed, as the plane gains speed, depending on your control, it can definitely go into an ever tightening spiral. This happened to me a lot in the early phases of development. The approach I took to solving it was to back off on the feedback gains and airspeed. What I have right now is very stable and reliable.
Of course, all of my experience is with gyros, accelerometers, and GPS, so it might not shed much light on your approach.
But back to your hypothesis that holding the rudder at 15 degrees forever is the problem. You may be onto something. The answers to the following questions might help me judge whether or not that is the problem. How many circles do you get before you get the spiral? How long does it take? Is there any other way to find out whether the rudder is staying within the 15 degree limit? What would you say is the diameter of the initial part of the turning circle right after the plane passes through the return point?
In any case, if you think that you do not have any problems with bugs in your code, you might try limiting the rudder throw to a smaller number, say half of what you are using.
Bill
Anyway, more testing will reveal the answer. And yes, we are using Atan2 (see GPS_Navigation tab)
Perhaps you have a bug, I hope you find it, it would be a shame to create a series of way points if they are not needed.
Are you saying that the rudder is throwing more than you intended? The last step I always include in my rudder calculations is a throw limit.
It may be that VoiceOfReason was on to something, there may be a bug when you get very close to the return point.
Also, you do have to use a four quadrant arctan calculation that treats X and Y separately instead of using the ratio, otherwise you will produce a two quadrant result and will have problems for sure. I assume that you are computing ATAN2?
Bill
Bill
That (steer toward origin, limited turn rate) makes sense and is what we intended. It may be that we have a bug that is breaking our 15 degree steer limit at waypoint crossover. Or it may be that we need to do more than just limit the rudder throw, but also limit the actual turn rate by monitoring the GPS track data. More testing will confirm...
I can't help you with your problem, but I have a couple of general comments on the subject:
1. ATAN2(X,Y) is recommended over ATAN(Y/X), it works in all 4 quadrants. I use a CORDIC implementation, its very fast and accurate.
2. I have been using RTL with circling afterward without any problems, using GPS and gyro to estimate yaw angle and bearing to launch. The algorithm is very simple: steer toward the origin, with limited turn rate. Once the plane goes past the origin, it eventually settles on a perfectly circular path. It did have some trouble with stability with earlier versions of the algorithm that included cross-track error, but once I eliminated the use of cross-track error, it worked just fine.
3. The effective steering gain of a simple steer to waypoint algorithm increases as the plane approaches a waypoint, which will trigger instability if the stability is marginal.
Bill Premerlani
I think this is just a code problem. We're working on it.
-
1
-
2
-
3
of 3 Next