[FOSS-GPS] Dead Reckoning?

[Tomoji TAKASU]

Dear Danny

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

RTKLIB already uses Kalman filter and you can enable DR with
Options - Rec-Dynamics ON. (It can be enabled only in relative
modes)

As to INS-integration, the performance much depends on the
IMU grade. At least FOG or RLG-class is needed to improve RTK
solutions. Low-cost MEMS is only effective to compensate very
short outage of GPS data. Refer my ION paper too.

http://gpspp.sakura.ne.jp/paper2005/ion2008_paper_ttaka.pdf

> 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?

With Rec-Dynamics ON, it depends on the process noise
parameters of receiver acceleration. If the value larger, the weight
of past estimated velocity decreases.

regards,

*********
Tomoji TAKASU

--------------------------------------------------
From: "Danny Miller" <dannym at austin.rr.com>
Sent: Saturday, July 09, 2011 4:05 PM
To: "Open Source GPS-related discussion and support" 
<foss-gps at lists.osgeo.org>
Subject: Re: [FOSS-GPS] Dead Reckoning?

> 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
>>
>
> _______________________________________________
> 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
>
>
>