Blogs

APM 2.0 AHRS Testing

Posted by David Gitz on July 9, 2013 at 8:00pm

3689534890?profile=original

So after demonstrating the "magic" of the APM at one of our meetings at the UIC Robotics Lab, we found that there really wasn't much concrete information regarding how stable the AHRS of the APM is over time.  We also knew that since our application was in an indoor (no GPS) environment, we didn't quite know how all that would affect the AHRS (yaw angle specifically).  And since we have some fancy robots, we decided to perform some real testing of the board.

Not surprisingly, we found that the APM is indeed a very robust system.  The image is probably the best representation of what we found:

It's definitely not a perfect system, as you can tell the Yaw would fluctuate by up to +/- 5 Degrees.  But for most people and most applications this would be completely acceptable.  For much more information and results you can view the wiki page here:

https://code.google.com/p/icarus-uav-system/wiki/APM_Tester

Tags: apm, testing, validation, verification
E-mail me when people leave their comments –
Follow

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • David Gitz July 11, 2013 at 9:27am

    @ Andrew: Thanks for all the questions and information.  The initial calibration was done using whatever calibration procedures the APM does on its own upon powerup, to simulate a normal usage scenario.  As far as the compass settings, I am unsure as I didn't know there were other options.  You definitely pose a lot of good questions.  We will not be able to test the APM again for a while as it is my only one and I am in the process of getting it ready to fly.  But when we have some downtime I will definitely get back to you.  Maybe you would like to collaborate on this with us, to help get a better experiment setup and better analysis?  

  • Developer
    Andrew Tridgell July 10, 2013 at 3:42pm

    another question, how did you have the compass setup for this test? Did you pre-learn the offsets, and then disable learning, or was learning active?

    If you get a tlog we could process it to learn offsets more accurately, then fix them for subsequent runs.

    Cheers, Tridge

  • Developer
    Andrew Tridgell July 10, 2013 at 3:40pm

    Fantastic, thanks David! As I maintain the AHRS code at the moment, this posting really was a delight to see.

    Did you do a full 3D accel calibration btw, or just levelling? Given the good results I'm guessing you did a 3D calibration, but it would be interesting to know for sure.

    Also, if you do another run then adding a telemetry radio and getting a tlog would be very useful. That will allow you to plot the APMs internal estimate of the attitude error, along with the values for the gyro drift correction along each axis. For example, here is a graph of the gyro drift correction (in degrees/second) for a recent flight in my Tiger60:

    3692768907?profile=originalnotice how the graph is quite granular? That is because the drift correction in APM is a "accumulate and apply average" system, which differs from the original DCM work that Bill Premerlani did (our AHRS is based on Bills original papers, with a few mods like these ones)

    It would also allow you to graph the error estimate for the attitude. For example, here is the error estimate for that same flight:

    3692768983?profile=originalI was doing aerobatics (rolls, loops etc) for this flight, and as you can see it did get quite a large error estimate at some points.

    The main thing this sort of setup can't tell us is how well the GPS velocity based accelerometer correction is working. That is a really key part of the AHRS system and so far the only method we have of evaluating it is in the SITL simulator.

    Cheers, Tridge

  • David Gitz July 10, 2013 at 5:50am

    All - Thanks for the feedback.  Phill and dionh, unfortunately we were not able to compare against the PUMA.  We would like to do that in the future but due to the sensors and how they work on the PUMA robot we thought that would mis-represent the performance of the APM, since the sensors could be higher precision than the APM or much lower.  Plus for timeliness as well, the longer it was on the PUMA the less time I have to (try to) fly it!  

  • dionh July 10, 2013 at 5:16am

    I agree with Phil Wat are you comparing it against? How does the reference signal look like?

  • Developer
    Olivier ADLER July 10, 2013 at 2:48am

    Very interesting test. I would be curious to see the performance of other flight controllers like DJI, zero UAV, Mikrokopter in the same test conditions.

    For the yaw error, i suspect that the metallic parts around the APM (robot arms, large metalic closet) could have affected Yaw (compass deviation).

    Olivier

  • Phill Scott July 10, 2013 at 1:45am

    Thanks for posting this up.  It's really useful and not something most could do - so it is of real benefit to the community in my eyes.

    I would have liked to see the same data from the PUMA arm, as I think your error should really be the delta between the APM and the PUMA arm.  OK, the PUMA arm should be very good, but still, that's what your measured error really is.

    Please could you point out which log your 'not so good' run came from?

    Thanks,

    Phill

  • Developer
    John Arne Birkeland July 10, 2013 at 1:32am

    Very cool! I need one of those PUMA arms myself just for the fun of it.. :)

    Is there any chance you could test the new 3.0 firmware next? It would be very interesting to get a 2.9/3.0 comparison. Not sure if there will be a big difference since most of the new inertia stuff is related to GPS and loitering, but would be very interesting to see.

This reply was deleted.