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
