Developer

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


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.
E-mail me when people leave their comments –

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

Join diydrones

Comments

  • Developer
    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.
  • 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);
  • Doug,

    Just wanted to mention that reversing the signs for all of my accelerometer inputs brought things back to normal with the cross product being calculated with the vectors swapped from before. And yes, I am using the roll angles as 0 to +/- 179, not 0 to 359. I got myself a little confused there with the roll immediately jumping to 179.
  • 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
    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
    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.
  • Admin
    Jason,

    The error in the checksum calculations was found and discussed around the middle of last year. I am suprised that you did not know about it and that it was not corrected and was continued to be carried forward in the later versions.

    Regards,
    TCIII
  • Developer
    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.
  • Excellent Doug !
    I just placed order for one ArduIMU Flat and Ardustation.
    Has someone flight tested 1.5 ?
  • Developer
    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.
This reply was deleted.