Blogs

Developer

Ardu-IMU v1.5 firmware for v1 and v2 hardware released

Posted by Doug Weibel on February 12, 2010 at 6:30am


New download firmware has just been added to the repository http://code.google.com/p/ardu-imu/downloads/list


The v1.5 firmware includes:

  • ADC oversampling which increases the effective resolution of the gyros and accelerometers
  • Drift correction gain de-weighting and speed filtering
  • Support for binary output messages as well as human readable
  • Support for both hardware types
  • Ground and Air start modes
  • Other improvements and bug fixes
I would like to give praise to Jose Julio for his excellent work on the first two items. I would also like to give Andrew Matthews an award! - "The Big Juicy Bug Squashing Award" for finding a very difficult to find bug in the gps parser. That crazy bug would cause ArduIMU to crash, but only after several hours. Not easy to find a bug when you have to watch all night to see it once.

The binary output messages and air start modes have been added to support use of Ardu_IMU with ArduPilot. Complementary ArduPilot firmware will be coming soon. Interested alpha testers can PM me.

The Labview viewer software is still messed up. If someone with Labview would like to fix it please let me know and I'll tell you what needs to be done.
Tags: ardu-imu, ardupilot
E-mail me when people leave their comments –
Follow

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

Join diydrones

Comments

  • Developer
    Doug Weibel June 12, 2010 at 11:20am
    Hi Yves - No it is correct. Arduino lets you define a pin for input and then define a state that the pin will float to if left unconnected. The pin is used for input and the input signal is generated by ArduPilot. The second state is just to condition the pin.
  • Yves Gohy June 12, 2010 at 3:45am
    Hello, I noticed this.

    pinMode(GROUNDSTART_PIN,INPUT); // Remove Before Fly flag (pin 6 on ArduPilot)
    digitalWrite(GROUNDSTART_PIN,HIGH);

    This would not it this? pinMode(GROUNDSTART_PIN,OUTPUT);
  • Kyle Anderson February 13, 2010 at 2:58pm
    Doug,
    Thanks for working and releasing this! I think I finally got all my hardware straight and I'm looking forward to the Ardupilot firmware to go with it!
  • Developer
    Jason Short February 12, 2010 at 9:31pm
    I didn't know about the fix, but Chris Barnes let me know and the 2.5 code now has a pretty solid parser. I will also add Doug's buffer overflow check. I think that's always a good idea.
  • Developer
    Jordi Muñoz February 12, 2010 at 8:26pm
    Hello Jason,

    Thomas is correct, i was notified about that issue and i corrected it. But i don't what happen, maybe is some kind of regenerative bug LOL. I guess it get lost in the repertory and could be erased with a newer version of the uBlox parser.
  • Developer
    Doug Weibel February 12, 2010 at 8:06pm
    The weather and my schedule have been conspiring against me. Mark Colwell and Ryan Beall may flight test it this weekend. I will do so next week.
  • Rana February 12, 2010 at 7:04pm
    Excellent Doug !
    I just placed order for one ArduIMU Flat and Ardustation.
    Has someone flight tested 1.5 ?
  • Developer
    Jason Short February 12, 2010 at 6:19pm
    Hey Doug,
    I had to rework that GPS parser a lot for 2.5. Check it out.

    Checksumming has an issue:
    if((ck_a=UBX_ck_a)&&(ck_b=UBX_ck_a)) // Verify the received checksum with the generated checksum..

    Should be:
    if((ck_a == UBX_ck_a) && (ck_b == UBX_ck_b)){ // Verify the received checksum with the generated checksum..

    I also had to check if I had a god fix before parsing the data. The uBox was outputting the last known good location over and over. That was messing me up and causing issue with the GPS light functionality.
  • Developer
    Doug Weibel February 12, 2010 at 3:15pm
    Hey Dave,

    You didn't see much activity in the repository but Jose, Andrew and I worked for quite a while to find the bug in the gps parser and for a long time we thought it was a problem in the DMC algorithm code, so lots of changes were made. I don't remember that one in particular or what the corresponding change would be.

    All of the angles should have a range of -180 to 180. I think we had an error in an earlier revision that had a range of 0-360 on one or more, but you really want -180 to 180 for the range.
  • Developer
    Doug Weibel February 12, 2010 at 12:43pm
    I wish I had time to actually test my drones. Work, work, work + family. As my father would say - "no rest for the wicked" ;)
This reply was deleted.