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!

Join diydrones

Email me when people reply –


  • 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.
  • Moderator
    I think that this is a very good idea, I don't like the way the current setup zigzags towards a waypoint.
  • 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.
  • Developer
    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 ?
  • Virtual Compass for ardupilot

    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


    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.
    See related links to what you are looking for.
  • 3D Robotics
    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.
This reply was deleted.


DIY Robocars via Twitter
13 hours ago
DIY Robocars via Twitter
13 hours ago
DIY Robocars via Twitter
13 hours ago
DIY Robocars via Twitter
RT @SmallpixelCar: Test my algorithm on real car https://t.co/idWRxcrmuK
DIY Robocars via Twitter
RT @breadcentric: Evo is coming to town. If you have an #AWS #DeepRacer, you can purchase an extension pack! https://t.co/w60JwI98Hp #Machi…
DIY Robocars via Twitter
DIY Drones via Twitter
RT @chr1sa: My talk on PX4 and FAA certification is coming up at 1:45 PST today on the PX4 Dev Summit livestream. Includes some cool new st…
Jul 7
DIY Drones via Twitter
RT @seesharp: I'm tuned into the PX4 / Dronecode free live conference. Great stuff. Microsoft AirSim talk in 10 minutes. https://t.co/0zbZ2…
Jul 6
DIY Robocars via Twitter
RT @masato_ka: 距離センサを3つとESP32を付けたラジコンカーをDonkeyCarライクにNNで自動走行。3層FC極小モデルをTensorFlow Lite for microcontrollerで動かしてる。機体は借り物でRumiCarって言います。Tenso…
Jul 5
DIY Robocars via Twitter
RT @SmallpixelCar: My car was able to go all the way autonomously until the crosswalk. It was only 100 yards from the target. What should b…
Jul 4
Liam left a comment on Agricultural UAVs
I'm Liam from T-MOTOR. I would like to reach out to see if there is any possibility for us to work together.
We are a propulsion system manufacturer who offers motors, propellers and ESCs for all kinds of drone applications which vary from secur…"
Jun 30
DIY Robocars via Twitter
RT @SmallpixelCar: Smart move. The car used the shadow to guide it through the bridge. This was never in the training samples. But it learn…
Jun 30
DIY Robocars via Twitter
RT @SmallpixelCar: Getting closer to the target. Single camera. Untrained road. https://t.co/Wsr7RwDamj
Jun 29
Richard Cox left a comment on Australia
"Anyone in the DIYDRONES Australian subgroup based in Alice Springs, NT?
I am experimenting with Ardupilot (standard Arduplane), Pixhawk 4 FC in a 4-ch
RC "AXN Floater Jet" foamy plane..."
Jun 29
Omar Sykes left a comment on Australia
"Hi everyone, I am looking for someone who is good at drone building, repair and software in Adelaide. Please give me a call on 0477 319 219."
Jun 29
DIY Robocars via Twitter
RT @RoboticMasters: #donkeycar https://t.co/czuLoVRcA4
Jun 29