Go Down

Topic: Converting an IMU to an INS for Dead Reckoning (Read 3 times) previous topic - next topic


Let me fill you in on my task.  I am working here at Chico State as an undergrad.  Our current project for my internship is to develop a Semi-Autonomous UGV.  We are using the ArduPilot software as a reference for our autonomous navigation, but it needs much modification.  Our system needs to be able to operate in an environment where GPS reception is to be considered patchy or unreliable.  Because of this, a dead reckoning system must be implemented.  We considered different options, including encoder readings on wheels (problematic because of slip) and using a following wheel-caster.  A wheel caster would work well, but we have strict weight requirements, and decided that an IMU would be a more valuable option, if possible.

We decided on using an IMU to determine vehicle attitude and pose, and using that information, translate it into catesian-coordinate data which the ArduPilot's open-source software can use to navigate with.  We really like the ArduPilot's software, and want to use it, if possible (with minor modifications, of course).  Basically, what we want to do is to step in between the GPS (which feeds directly into the Arduino) and the ArduPilot (which is an Arduino Mega).  We want to fuse GPS readings (currently using a ublox module) with spatial MEMS sensor readings (currently, we have selected the Phidget 3/3/3 precision sensor) for when the GPS is dead.  Whatever filtering (likely going to be Kalman) we do with the information, we then need to output a "corrected" GPS location.  This "corrected" location is what we will be feeding into the AuduPilot, and the ArduPilot's automatic navigation will be free to continue with its duties, regardless of whether or not the GPS has reception.  Basically, the ArduPilot will execute its tasks, deciding how to move based on where it thinks it is and where it needs to go, but where it thinks it is will no longer be a direct input from the GPS module.  I am assuming that once a GPS signal IS periodically picked up, the filter would take this reading to correct the system's "location" and therefore, we would counter the issue of long-term drift which is inevitable with IMU's.

Our system aims to filter the sensory data with a SBC, and then output the corrected GPS location to the Arduino, as I mentioned before.  However, my problem is that I am not sure how much processing power or computational time it would take to filter all this data each time readings are taken (trying to determine if this is something we can do ourselves or of we need to buy a dedicated INS).  We plan to use the SBC for other tasks as well, such as video streaming, so it will not be entirely devoted to the Kalman (or other type) filtering. 

I have been fishing around for Kalman filtering examples (there is TONS of information on theory) over the last few weeks, but all of the mathematic functions seem fairly complex.  Do you guys know of any reference code where a filter has been used to fuse IMU sensory data with a GPS?  Have you heard of any software (open-source or proprietary) that may do this service (the filtering)?  I have found examples where a filter was used to smooth out shaky readings from an IMU alone, but so far nothing that has also incorporated a GPS.

Searching around, I see that there are complete attitude and reference heading systems which incorporate their own filter, but these modules are VERY expensive.  For example, the VN-200 from VectorNav is small, lightweight, and filters the data on-board the chip, but it runs at a $2,500 price tag.  I feel like we can develop a system here that is comparable in precision, but exceptionally cheaper.  The only problem is the filtering at this point, haha.  Any tips/advice/suggestions are MORE than appreciated.  Thank you!!!

Also don't be shy to ask more questions about the project, or any information you may need to better direct your suggestions.

Thanks again!


I looked at Kalman filtering and realised that to do it properly I would be inverting 11x11 matrixes,  which is
unrealistic on the arduino.  So I did it another way.
But there is a long thread on the forum here about kalman filtering, so I guess you should do it their way.

The problem with "dead reckoning" is that trying to measure your motion with accelerometers and gyros
accumulates a large noise error very quickly,  which almost makes it useless.  Measuring position with
reliable wheel encoders is an improvement. 

The thing is,  with outdoors,  you might expect lapses in GPS to be transient as you go past a building
or under a freeway overpass,  and after you have done that the GPS will work again.

But indoors,  you might never get a GPS reading.

I suspect the long term solution to this,  is some kind of indoor re-broadcasting of the GPS signal.


I suspect the long term solution to this,  is some kind of indoor re-broadcasting of the GPS signal.

I think you need to put a bit more thought into what you just suggested. ;)

Your only practical hope is some kind of terrain mapping (LIDAR, Kinect, etc.) and tracking your position relative to your environment. If the area you need to cover is limited it would be possible to employ fiduciary markers on ceilings/etc. and use those as points of reference -- I know I've seen one example of such a product that was designed for indoor robots with an upward facing camera and was fairly inexpensive.

Go Up