Posted by Paul Mather on December 16, 2009 at 7:30pm
For those NMEA GPS users out there who don't want to be left out of the wonderful product that is ArduIMU, I've modified/combined the NMEA parsing routine in ArudPilot 2.3.1 with the latest ArduIMU firmware from Doug Weibel - ArduIMUV2 DCM V10. Additionally, I'm using the $50 I2C compass from Sparkfun (HMC6352) and have added a routine to pull this data from the compass and include it in the text output as "HDG." I've also added "SAT" for satellites and "HOP" for HDOP in the text output.Download Here: http://www.happykillmore.com/software/RemzibiOSD/HK_ArduIMU_NMEA.zipTo disable the compass code, simply change PRINT_COMPASS 1 to PRINT_COMPASS 0Please also note that 3 Hz is about the fastest you should set your GPS when going throught the ArduIMU. Any faster and the serial port won't be able to keep up (this statement assumes 38,400 baud and only getting GPGGA and GPRMC from the GPS).You'll need to copy the TwoWire.h and TwoWire.cpp files included in the zip to the arduino-0017\hardware\libraries\Wire folder if you're planning on using the Compass routine.
Ha! Now THAT makes sense (I don't bet against many on this site). I bought the 6352 knowing it didn't have tilt compensation (save $$), so am running a UGV on mostly flat ground. Honeywell does make a tilt-compensated compass, the HMC6343 (Sparkfun sells that too), but not quite the same specs as the 6352 (2 degree heading accuracy vice .5) and $150 a pop.
Good luck!!
Great work Happy! This is something I was considering doing as well. I was thinking that the compass could be used to augment the yaw. It seems the tilt-compensated compass http://www.sparkfun.com/commerce/product_info.php?products_id=8656 might be a better option. But, why not use the HMC6352 and do the tilt compensation with ArduIMU? That seems reasonable to me. Do you guys have experience that would say that is still not going to get us an accurate heading?
Thanks for the link. I'll have to do some more testing to see if I'm having and real (or just imagined) throughput issues.... I can't be sure the compass will be useful in flight. The project I'm working on right now is a ground based vehicle. I'm considering making a 2 axis gimbal based on the ArduIMU values to keep the compass flat. If you read the spec sheet, you'll see that for every 1 degree of tilt, you can have 2 degrees of error in your compass heading. That's pretty much horrible for a plane.
Hey guys,
Awesome work Happy - have a couple of ArduIMU boards but no uBlox, but just playing right now and hadn't crossed the NAV data bridge yet. Thanks.
Not sure you air boys care about bearing accuracy/smoothing as much as us UGV guys (we have smaller mission areas), but a buddy of mine pointed something out to me that works nicely - if you'd like to get a little better performance out of your HMC6352, you can program it into Continuous mode, and set up the update rate and the number of summed measurements to match up with your GPS data rate. See the datasheet @ http://www.sparkfun.com/datasheets/Components/HMC6352.pdf for details but, for example, you can program your GPS for 4Hz update, then set the compass up with a 20Hz continuous update rate, no time delay between readings, and sum across 5 measurements. This also saves time as you don't have to query for data, it's just waiting for you on the I2C bus. You may want to tweak this for whatever configuration you need, as the example settings do not account for the processing lag you describe - not seeing it here , and am configured differently (no ArduIMU, minimizing serial processing, all serial strings programmed into flash vice sram, v1 shield, and Locosys 20031). Also, the HMC6352 reads in 10ths of a degree, but it's of no use unless your waypoint bearing calcs use it. Account for needed delays before trying to 'talk' to the compass though - at least with a v1 Shield, it takes a while for the capacitors on the 3.3v circuit to light up, therefore the compass doesn't get powered immediately.
Just wondering, do you need to calibrate your compass prior to takeoff?
Thanks again for the code.
Doug, it would be fantastic if you could include the NMEA code in your next release (please, please, please :)). I know uBlox is the way to go, but not everyone has the budget to spend over $100 on a GPS unit.
I did a bit of testing from 1Hz to 5Hz and at 4 I started having problems. Watching the plane move on my ArduIMUTest software everything was slowing down and GPS lat & long updates were hit or miss. My testing also did not include any of the analog or digital raw data. Only Pitch, Roll,, Yaw and GPS data (plus the compass). If anything else gets turned on I suspect 2Hz may be the max for NMEA...
@Happy, I haven't had a chance to look at what you did, but your warning about the gps update rate is waranted. I found that if you turn on all the serial output options in the code you are already slowing down the main loop and degrading IMU performance.
Also, Jose Julio has been digging in to the ublox gps that we are using and is finding that although advertised as 4 Hz, is really only capable of 2 Hz. This is not a problem for ArduIMU, but something to be aware of.
Comments
Good luck!!
Awesome work Happy - have a couple of ArduIMU boards but no uBlox, but just playing right now and hadn't crossed the NAV data bridge yet. Thanks.
Not sure you air boys care about bearing accuracy/smoothing as much as us UGV guys (we have smaller mission areas), but a buddy of mine pointed something out to me that works nicely - if you'd like to get a little better performance out of your HMC6352, you can program it into Continuous mode, and set up the update rate and the number of summed measurements to match up with your GPS data rate. See the datasheet @ http://www.sparkfun.com/datasheets/Components/HMC6352.pdf for details but, for example, you can program your GPS for 4Hz update, then set the compass up with a 20Hz continuous update rate, no time delay between readings, and sum across 5 measurements. This also saves time as you don't have to query for data, it's just waiting for you on the I2C bus. You may want to tweak this for whatever configuration you need, as the example settings do not account for the processing lag you describe - not seeing it here , and am configured differently (no ArduIMU, minimizing serial processing, all serial strings programmed into flash vice sram, v1 shield, and Locosys 20031). Also, the HMC6352 reads in 10ths of a degree, but it's of no use unless your waypoint bearing calcs use it. Account for needed delays before trying to 'talk' to the compass though - at least with a v1 Shield, it takes a while for the capacitors on the 3.3v circuit to light up, therefore the compass doesn't get powered immediately.
Just wondering, do you need to calibrate your compass prior to takeoff?
Thanks again for the code.
I did a bit of testing from 1Hz to 5Hz and at 4 I started having problems. Watching the plane move on my ArduIMUTest software everything was slowing down and GPS lat & long updates were hit or miss. My testing also did not include any of the analog or digital raw data. Only Pitch, Roll,, Yaw and GPS data (plus the compass). If anything else gets turned on I suspect 2Hz may be the max for NMEA...
Also, Jose Julio has been digging in to the ublox gps that we are using and is finding that although advertised as 4 Hz, is really only capable of 2 Hz. This is not a problem for ArduIMU, but something to be aware of.
-
1
-
2
-
3
of 3 Next