I was wondering if it was possible to create some sort of a virtual compass ( software ) for ardupilot.The point would be to have instantaneous and unlimited access to the heading information in order to have a much faster Heading PID loop and be able to steer the plane directly to the next waypoint without any loitering in a relatively hight bank turn.This brings us back to the thermopile characteristic. If the bank can accurately be determined, then the rate of turn is also known ( RoT=G*tan(Bank)/Airspeed hope I got it right ;-) ). By integrating this value over time we can then extrapolate "heading + error" . Erro can be computed with the gps heading and gps delays can also be taken into account.It's actually a Kalman filter, from two observed parameters RoT (from Bank & Airspeed) and GPS heading, we combine the two and we have a value that benefits from the quick response of the first parameter and the long term accuracy of the GPS.RoT = Rate of TurnI think that this (,if it works, ) would be a substantial step forward. No need for a fast GPS. Even 1 Hz should be enough. As far as the CPU power is concerned, it only adds one tan() one integration at each cycle...Thank you for letting me know if you share my enthusiasm.Dave
You need to be a member of diydrones to add comments!
Hi, this is my first post! have been flying a delta wing for over a year now and have just invested in a second hand electric trainer which along with the ardupilot should make a good platform for some aerial photography and uav fun :)
Love what i'm reading in this thread, give it a couple of weeks or months and i might be in the air and able to help out with some testing.
Hey people I wish that I could start experimenting but I haven't received my ardupilot it's been 2 weeks already ;-(
I also need to find a EM406 GPS and I'm still hoping to find a cheap second hand one from someone who's migrated to the Ublox.
Anyway if someone is willing to start experimenting we can give it a go. I'm warning that the implementation could be more difficult than it looks. But we are doing these things "not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win, and the others, too" J.F.K lol
Sounds like an great idea to me. I was thinking of doing the same thing for throttle control. Have a set cruise throttle setting to control around and use attitude(thermo). When you turn or climb more power is needed,less when descending. Throttle should be steady,not using airspeed. Airspeed is the desired result and should not directly control throttle. That just how I was taught to fly.
That is a subject for another time.
Yeah this sounds like something that could be doable. The only thing I see wrong at face value that would cause you issues is the fact that your GPS is your "slow" update to reality. However this introduces error. The COG from GPS is not your heading. So what you are talking about is a smoother COG from GPS....which sounds logical from your approach. I would have to lay it out to see if its doable but I think the problem isn't the 1Hz being smoothed. Its the fact that Heading (psi) is not the COG. Any time you assume Psi and COG are equal and you have wind you will have poor performance in tracking. I would suggest you use a magnetometer for your slow update to reality. That would get you closer I think. But the best solution is a smoothed magnetometer from gyros (aka full IMU). But yeah the problem with crap navigation is wind vs crab angle vs COG. They all fight
Another thing you can do is add an integrator on heading error to bank angle. This helps "tune/trim" out the crab but still just an adhoc fix. The idea is to know your winds from another filter, know your heading, and apply appropriated crab angle....and jackpot perfect estimated heading control
As it looks like we are migrating to the Ublox GPS, would anyone be interested in selling me one of his "old" EM406 for a good price so that I can start experimenting ?
The point of this is to have a variable that contains the ground heading that is as accurate as it can be at any time constantly updated.
The hardware studied will be a thermopile, an airspeed sensor and a GPS.
We will start with the general principle of how we can mix the readings of these sensors in order to have the best heading information possible then we will go more into depth with the technical details.
II)How to combine the sensor readings to make the most of them.
Based on the knowledge of a system behavior it is sometimes possible to anticipate its behavior. Let’s say that based on your experience your girlfriend is always late by 30 minutes. As an extremely busy man you don’t have any time to waste, obviously you want to have the best estimate of when she comes so you don’t have to wait for too long. In this case, even if you’ve agreed on 20:00 you will come at around 20:30. 20:30 is the best estimate you can have based on your knowledge of the system.
Now, if you know that when the weather is bad she takes an extra 10mins, you will work out your estimate using this new parameter (the weather).
It’s the same thing with your plane equipped with a thermopile, airspeed sensor and GPS.
Let say that we have a very poor GPS that can only give us a new heading value every 10 seconds (a little bit extreme lol). We are in a straight and level flight heading north, we’ve just received the last GPS heading (360°) update and we have to wait almost 10 seconds before we can have a new one. At that same moment the navigation system switches to way point n°2 which is west of the present position. A left turn is initiated. The system needs to know when it has to level off the wings in order to make a heading of 270° (west). If you are only relying on the GPS, you still have 9 seconds to wait before knowing where about you are in the turn. Not very convenient.
Now let’s introduce a new parameter, the RoT (Rate of Turn) which corresponds to the rate at which the plane is turning round the vertical axis. If you were sitting in the plane, it would correspond to the speed at which a perfect compass needle pointing north is moving.
In our example we have a rate of turn of 360° in 30 seconds. It’s now much easier for the system to turn the waypoint 2. We have turn left 90° which corresponds to (90/360)*30= 7.5 seconds. The system knows that after 7.5 seconds in the turn it has to level off(easily manageable). If it had to wait for an extra GPS update it would have overshot.
III)Thermopile attitude and RoT(Rate of Turn)
As we have just discussed, RoT becomes crucial information. I worked out that RoT is determined by the Bank angle and the airspeed as follows: RoT = G*sin(Bank)/Airspeed.
The bank angle can be computed using the thermopile. Airspeed is obtained through the pressure sensor. You see that RoT is relatively easy to compute provided that we have a good enough estimate of the bank angle.
IV)Put it all into equations.
We are going to use the rapid response of the RoT. Rapid because it can almost be instantaneously determined with the thermopile and the airspeed sensor. RoT is obviously not good enough because it only describes the evolution of the turn and using this parameter only would eventually lead to an error that would accumulate over time in the same manner as a gyroscope drifts.
This is when we need to use the GPS to compensate for that drift, in other words, to use the GPS heading (when it is available) to work out this error.
Let’s define a few variables :
dt : The small length of time between each system iteration, between state N and N-1
Hdg : Heading
RoT : Rate of Turn (angular speed)
HdgGPS : Heading given by the GPS
K : A coefficient
Dlay : GPS delay
We are not going to bother defining units, this being a general description.
RoT = ( Hdg(N)-Hdg(N-1) )/dt
We now have :
Hdg(N)=dt*RoT+ Hdg(N-1)+error1
Now let’s deal with the error1. This will be done each time a GPS heading is available.
We could do, for example :
error1=K*(Hdg(N)-HdgGPS) +error1
Now because the GPS has a certain Dlay (Delay)
error1=K*(Hdg(N-ND)-HdgGPS) +error1
ND=Dlay/dt
V)Conclusion
What the system has to do is
1-Thermopile + Airspeed sensor =>( RoT = G*sin(Bank)/Airspeed.)
2-RoT intergration => Heading +error (Hdg(N)=dt*RoT+ Hdg(N-1)+error1)
3-When GPS heading is available we calculate the error1=K*(Hdg(N-ND)-HdgGPS) +error1
This method tries to take advantage of the anticipation provided by the Bank (thermopile) and the airspeed and the accuracy of the GPS.
I'm not quite sure I understand the question, but I'll try to answer.
First, we obviously do have a "virtual compass" in both the hardware and software ArduStations on the ground using the basic heading output from the GPS. And of course as we migrate to the uBlox5 the heading loop in the air becomes 4x faster, which is fast enough for virtually all applications we can think of.
I think you're asking if we can interpolate the heading information at faster than 1Hz with the EM406. Perhaps, but I'm not quite sure how, and as I mentioned, we don't see a need with the uBlox5.
Replies
Love what i'm reading in this thread, give it a couple of weeks or months and i might be in the air and able to help out with some testing.
I also need to find a EM406 GPS and I'm still hoping to find a cheap second hand one from someone who's migrated to the Ublox.
Anyway if someone is willing to start experimenting we can give it a go. I'm warning that the implementation could be more difficult than it looks. But we are doing these things "not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win, and the others, too" J.F.K lol
That is a subject for another time.
Another thing you can do is add an integrator on heading error to bank angle. This helps "tune/trim" out the crab but still just an adhoc fix. The idea is to know your winds from another filter, know your heading, and apply appropriated crab angle....and jackpot perfect estimated heading control
As it looks like we are migrating to the Ublox GPS, would anyone be interested in selling me one of his "old" EM406 for a good price so that I can start experimenting ?
I) Introduction
The point of this is to have a variable that contains the ground heading that is as accurate as it can be at any time constantly updated.
The hardware studied will be a thermopile, an airspeed sensor and a GPS.
We will start with the general principle of how we can mix the readings of these sensors in order to have the best heading information possible then we will go more into depth with the technical details.
II)How to combine the sensor readings to make the most of them.
Based on the knowledge of a system behavior it is sometimes possible to anticipate its behavior. Let’s say that based on your experience your girlfriend is always late by 30 minutes. As an extremely busy man you don’t have any time to waste, obviously you want to have the best estimate of when she comes so you don’t have to wait for too long. In this case, even if you’ve agreed on 20:00 you will come at around 20:30. 20:30 is the best estimate you can have based on your knowledge of the system.
Now, if you know that when the weather is bad she takes an extra 10mins, you will work out your estimate using this new parameter (the weather).
It’s the same thing with your plane equipped with a thermopile, airspeed sensor and GPS.
Let say that we have a very poor GPS that can only give us a new heading value every 10 seconds (a little bit extreme lol). We are in a straight and level flight heading north, we’ve just received the last GPS heading (360°) update and we have to wait almost 10 seconds before we can have a new one. At that same moment the navigation system switches to way point n°2 which is west of the present position. A left turn is initiated. The system needs to know when it has to level off the wings in order to make a heading of 270° (west). If you are only relying on the GPS, you still have 9 seconds to wait before knowing where about you are in the turn. Not very convenient.
Now let’s introduce a new parameter, the RoT (Rate of Turn) which corresponds to the rate at which the plane is turning round the vertical axis. If you were sitting in the plane, it would correspond to the speed at which a perfect compass needle pointing north is moving.
In our example we have a rate of turn of 360° in 30 seconds. It’s now much easier for the system to turn the waypoint 2. We have turn left 90° which corresponds to (90/360)*30= 7.5 seconds. The system knows that after 7.5 seconds in the turn it has to level off(easily manageable). If it had to wait for an extra GPS update it would have overshot.
III)Thermopile attitude and RoT(Rate of Turn)
As we have just discussed, RoT becomes crucial information. I worked out that RoT is determined by the Bank angle and the airspeed as follows: RoT = G*sin(Bank)/Airspeed.
The bank angle can be computed using the thermopile. Airspeed is obtained through the pressure sensor. You see that RoT is relatively easy to compute provided that we have a good enough estimate of the bank angle.
IV)Put it all into equations.
We are going to use the rapid response of the RoT. Rapid because it can almost be instantaneously determined with the thermopile and the airspeed sensor. RoT is obviously not good enough because it only describes the evolution of the turn and using this parameter only would eventually lead to an error that would accumulate over time in the same manner as a gyroscope drifts.
This is when we need to use the GPS to compensate for that drift, in other words, to use the GPS heading (when it is available) to work out this error.
Let’s define a few variables :
dt : The small length of time between each system iteration, between state N and N-1
Hdg : Heading
RoT : Rate of Turn (angular speed)
HdgGPS : Heading given by the GPS
K : A coefficient
Dlay : GPS delay
We are not going to bother defining units, this being a general description.
RoT = ( Hdg(N)-Hdg(N-1) )/dt
We now have :
Hdg(N)=dt*RoT+ Hdg(N-1)+error1
Now let’s deal with the error1. This will be done each time a GPS heading is available.
We could do, for example :
error1=K*(Hdg(N)-HdgGPS) +error1
Now because the GPS has a certain Dlay (Delay)
error1=K*(Hdg(N-ND)-HdgGPS) +error1
ND=Dlay/dt
V)Conclusion
What the system has to do is
1-Thermopile + Airspeed sensor =>( RoT = G*sin(Bank)/Airspeed.)
2-RoT intergration => Heading +error (Hdg(N)=dt*RoT+ Hdg(N-1)+error1)
3-When GPS heading is available we calculate the error1=K*(Hdg(N-ND)-HdgGPS) +error1
This method tries to take advantage of the anticipation provided by the Bank (thermopile) and the airspeed and the accuracy of the GPS.
Thank you for reading.
First, we obviously do have a "virtual compass" in both the hardware and software ArduStations on the ground using the basic heading output from the GPS. And of course as we migrate to the uBlox5 the heading loop in the air becomes 4x faster, which is fast enough for virtually all applications we can think of.
I think you're asking if we can interpolate the heading information at faster than 1Hz with the EM406. Perhaps, but I'm not quite sure how, and as I mentioned, we don't see a need with the uBlox5.