[FOSS-GPS] Dead Reckoning?

[Danny Miller]

How much potential is there to improve position with Kalman filtering in 
RTKLib?

I have an Inertial Measurement Unit on the rover with accelerometers and 
a magnetometer compass, and there's tachometers on the wheels.  The 
rover will not move quickly, but compass headings are never exact, and 
tachometer counts will have some slippage on rough ground.  Basically it 
is a fair Dead Reckoning input, but with all the usual problems of DR.

How heavily does RTKLib filter the solution with its history of past 
solutions and estimated velocity?  Or does it largely rely on the 
current solution without filtering a history of past positions and 
velocity estimates?

I saw there is a parameter for a limit on acceleration.  Would a 
parameter limited velocity helpful?  The rover's speed is limited, 
although it can stop immediately upon obstacles.  Of course, with a DR 
input stream, the limits on velocity and acceleration could be versus 
the DR-estimated position, so they could be a much lower correction for 
drift once the starting location is resolved.

Danny

On 6/20/2011 7:34 PM, Tomoji Takasu wrote:
> Dear Danny
>
>> I don't see any way this could be provided as a type of correction 
>> information.  Is it possible?
>
> Basically all is possible because all of the source codes
> are open.
>
> However, I recommend loosely-coupled integration
> implemented outside of RTKLIB.
>
> For tightly-coupled integration, you have to modify the
> filter code deeply. It mignt be hard way.
>
> regards,
>
> Tomoji TAKASU
>
> --------------------------------------------------
> From: "Danny Miller" <dannym at austin.rr.com>
> Sent: Tuesday, June 21, 2011 8:45 AM
> To: "Open Source GPS-related discussion and support" 
> <foss-gps at lists.osgeo.org>
> Subject: [FOSS-GPS] Dead Reckoning?
>
>> I plan on making a rover with an IMU containing XYZ linear 
>> accelerometers, rotational accelerometers, and 3D magnetometer compass.
>> There will also be tachometers on the wheels.
>>
>> This serves to orient the rover with a compass heading, and detect 
>> collisions or loss of traction.  It may also help in short-term 
>> navigation should the RTKlib lose carrier lock.
>>
>> Could this information be integrated as correction information for 
>> RTKlib? The IMU has inherent offset errors and is not accurate over 
>> significant time periods, and tachometers are inaccurate on rough 
>> ground since tires slip.  It can, however, provide guidance for RTK 
>> solutions when the solution is in doubt.  Going from a Fixed solution 
>> to a float that jumps over 2M, the IMU's evidence that no such motion 
>> occurred should be a useful correction.  Now given 30 sec of motion, 
>> assuming it's been moving, the IMU's range of error is such that the 
>> IMU vector from the last known Fixed time could be several meters.   
>> Even still, I would expect that having information on how the rover 
>> is moving would improve the ability to resolve to an accurate solution.
>>
>> I don't see any way this could be provided as a type of correction 
>> information.  Is it possible?
>>
>> Thanks,
>> Danny
>> _______________________________________________
>> This message is sent to you from FOSS-GPS at lists.osgeo.org mailing list.
>> Visit http://lists.osgeo.org/mailman/listinfo/foss-gps to manage your 
>> subscription
>> For more information, check http://wiki.osgeo.org/wiki/FOSS-GPS
>>
>>
>>
>
>
> _______________________________________________
> This message is sent to you from FOSS-GPS at lists.osgeo.org mailing list.
> Visit http://lists.osgeo.org/mailman/listinfo/foss-gps to manage your 
> subscription
> For more information, check http://wiki.osgeo.org/wiki/FOSS-GPS
>