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" <[email protected]>
Sent: Saturday, July 09, 2011 4:05 PM
To: "Open Source GPS-related discussion and support"
<[email protected]>
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" <[email protected]>
Sent: Tuesday, June 21, 2011 8:45 AM
To: "Open Source GPS-related discussion and support"
<[email protected]>
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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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
