Posted by Chris Anderson on September 22, 2009 at 12:36pm
At last, the long-awaited ArduIMU is available! You can buy the hardware here (the first batch sold out within minutes, but he's making more quickly). The software is in beta, and you can find it here. It is, as promised, $99, making it the first sub-$100 AHRS in the world!
Proper documentation is coming soon, but here are the highlights:
Features
-3 Axis Accelerometer
-3 Axis Gyroscopes
-Arduino Compatible (Atmega328 onboard)
-Source Code included and Open Source!
-Power LED (Green)
-Status LEDs (Red, Blue, Yellow)
-SPI port available for more sensors.
-GPS port (uBlox ready!)
-Code based on Bill Premerlani's Direction Cosine Matrix
This is actually considered a full Attitude Heading Reference System, because it is IMU hardware plus the software to interpret the sensor readings and convert them into absolute attitude and heading information. The output is a serial ASCII string with raw sensor values and the DCM matrix values. You would use this with an autopilot board to convert those matrix values into commands for the your control surfaces.
The board works without the GPS module, but in that case the yaw readings are unreliable. If you add the GPS, the yaw is corrected. We will be releasing a magnetometer module to do the same thing indoors.
In my IMU experience (I mean success) a -3db bandwidth of 5.13 Hz is fine for the accelerometers. Otherwise, you end up with STUPID problems of vibration sensitivity that apparently U-Nav can't figure out and then in your manual (U-3500) tell people to mount the IMU suspended in a rubber band box. The Kestrel2 uses a 9Hz bandwidth on the accels and I am using about 22Hz. The limited bandwidth is required to absorb airframe vibration and not let the IMU model "blow up" in code.
Gyros, on the other hand (at least the ADXRS610 due to dual sensor structures) are pretty much vibration proof and so a -3db bandwidth of 500 or 800 Hz is fine. I don't know about the LISYAL300 used in the Ardu AHRS, but I assume similar. If the gyro bandwidth were set really small like 5 Hz then I can't imagine how the IMU would have a usable amount of response.
I re-did the UAV DevBoard A/D filter calculation..I didn't subtract right! Looks like -3db @ 5.13 Hz.
Either way it's a simple number to change based on what works best...no big deal.
My thoughts were that if the bandwidth requirement is indeed this relatively low, then
using the Oversampling/Decimation technique to force 12 bit resolution might work,
for let's say, certain 500deg/sec gyros, to get the sub degree resolution you'd like to see. :o)
Again thanks for all your great work, and the whole diydrones team and members!!!
...all these new developments are awesome! Best website on the planet!
So this is a very cool project, and I love the low cost nature of it..but it seems to me that for around $150 we could have the flat board, USE a 12 bit ADC AND add barometric and airspeed sensors and we would have a full on ADAHRS (Air Data Attitude Heading Reference System) that would be ArduPilot compatible, could be a replacement shield, AND could be compatible with the NextGen ArduPilotMega - that might even free up some resources (clock cycles) on the Mega to do some other interesting things - so how about it?? - I'd be willing to kick in some time / dollars for board development and the like. We could even use the forum here to flesh out what we would all like to see done on the calculations side like - how do we compare / treat the data from the GPS vs the airspeed sensor, and the GPS vs. the Baro Altitude, etc., etc.
Regardless, I think the community isn't really screaming Hey! that's wrong...I think what I'm reading is more like...Ummm, what about the hardware I just got working...I can't use any of it other than my GPS (and in cases where people have the EM40x even that, now that the UBlox transition is happening?)
Just my two hundredths of a single unit of US credit backed currency.
@Jordi,
congratulations, great job! BTW it's not impossible to get 12 bit accuracy from 10 bit ADCs by oversampling and decimation. The downside is that to reach 12 bits one needs (at least) 8 times oversampling. That means that sampling rate is 8 times slower unless you speed up ADC sampling. I perused your DCM code. I've a question about acceleration adjustment. From my (poor) understanding of Premerlani's paper, I would have been using ground_speed for computation: why are you using speed_3d instead ? thank you.
The only way to use those gyros is using an external ADC of 12 bits. A 10 bits ADC is not enough for the output of those gyros if you want at least 1 degree of resolution. I proposed to add a SPI 12 ADC to use those sensors but that means bigger size, more problems and higher price, so we decided to make it simple. This is only a learning product for everybody and for me! I hope the community will say" Hey! HEy! that's wrong!! And i will happily correct it. The result will be a communist system, cheap and open source for all! Like ArduPilot.
This IMU is not meant for the current ArduPilot. It is a stand-alone IMU/AHRS at the moment (not an autopilot). It will also the core of our next autopilot, ArduMega, but don't look for that until the end of the year at the earliest. The current ArduPilot will continue to be our thermopile option.
well this is intersting... I have finally gotten the adrupilot to work on my mentor... now onto new things I guess... haha... so is this a daughter board then to the main adruinto autopilot? as in it takes place of the shield? Or is it stand alone? if so where are the servo connections input and output?
Comments
Gyros, on the other hand (at least the ADXRS610 due to dual sensor structures) are pretty much vibration proof and so a -3db bandwidth of 500 or 800 Hz is fine. I don't know about the LISYAL300 used in the Ardu AHRS, but I assume similar. If the gyro bandwidth were set really small like 5 Hz then I can't imagine how the IMU would have a usable amount of response.
I re-did the UAV DevBoard A/D filter calculation..I didn't subtract right! Looks like -3db @ 5.13 Hz.
Either way it's a simple number to change based on what works best...no big deal.
My thoughts were that if the bandwidth requirement is indeed this relatively low, then
using the Oversampling/Decimation technique to force 12 bit resolution might work,
for let's say, certain 500deg/sec gyros, to get the sub degree resolution you'd like to see. :o)
Again thanks for all your great work, and the whole diydrones team and members!!!
...all these new developments are awesome! Best website on the planet!
http://www.atmel.com/dyn/resources/prod_documents/doc8003.pdf
Awesome job Jordi! Code is very clean and readable....love the floating point aspect of port as well!
I believe the ADCs are sampled at 50hz followed by 1st order filtering, fcutoff ( -3db ) @ 0.8 Hz.
In contrast, the UAV DevBoard samples at 500hz with -3db bandwidth @ 4.55 Hz (if my calcs are correct).
Do we have access to real world "telemetry" data for gryo and accel bandwidth (rate of change) requirements?
Do you anticipate any issues regarding DCM lag or slew limiting in an EasyStar?
Thank you for all your efforts, I can only imagine the time that was put into this! :)
Regardless, I think the community isn't really screaming Hey! that's wrong...I think what I'm reading is more like...Ummm, what about the hardware I just got working...I can't use any of it other than my GPS (and in cases where people have the EM40x even that, now that the UBlox transition is happening?)
Just my two hundredths of a single unit of US credit backed currency.
congratulations, great job! BTW it's not impossible to get 12 bit accuracy from 10 bit ADCs by oversampling and decimation. The downside is that to reach 12 bits one needs (at least) 8 times oversampling. That means that sampling rate is 8 times slower unless you speed up ADC sampling. I perused your DCM code. I've a question about acceleration adjustment. From my (poor) understanding of Premerlani's paper, I would have been using ground_speed for computation: why are you using speed_3d instead ? thank you.
The only way to use those gyros is using an external ADC of 12 bits. A 10 bits ADC is not enough for the output of those gyros if you want at least 1 degree of resolution. I proposed to add a SPI 12 ADC to use those sensors but that means bigger size, more problems and higher price, so we decided to make it simple. This is only a learning product for everybody and for me! I hope the community will say" Hey! HEy! that's wrong!! And i will happily correct it. The result will be a communist system, cheap and open source for all! Like ArduPilot.
This IMU is not meant for the current ArduPilot. It is a stand-alone IMU/AHRS at the moment (not an autopilot). It will also the core of our next autopilot, ArduMega, but don't look for that until the end of the year at the earliest. The current ArduPilot will continue to be our thermopile option.
-
2
-
3
-
4
-
5
-
6
of 7 Next