Is there way to feed a velocity signal into your filter, such as from a simulated wheel odometry unit found on ground robots? If not, do you have a sense of what it would take to implement this?
Currently, I have the free-integration algorithm running and producing reasonable-looking outputs using one of your supplied IMU models. I'm guessing extending the free-integration model might be reasonable. Does your open-source INS filter support velocity input?
There indeed odometer output in the simulator. But I did not output this because it is currently not used in our demo algorithms. You can refer to pathgen.py and use the keyword “odo” to see the details. To use the built-in odometer data, you need also add you own odometer error model.
To use the odometer measurement in the free-integration algorithm, you can see code in free_integration.py:
self.vel_b[i, :] = self.vel_b[i-1, :] +\
(accel[i-1, :] + c_bn.dot(g_n)) * self.dt -\
attitude.cross3(gyro[i-1, :], self.vel_b[i-1, :]) * self.dt
When you choose reference frame ref_frame to be 1, this code will be executed to do velocity propagation. Usually we propagate velocity in the navigation frame (e.g. NED frame). To integrate odometer measurement in a future version is one of the reasons why I propagated velocity in the body frame.
For more details on ref_frame, you can refer to the document or comments in the code. For you robot application, ref_frame = 1 should be enough since a robot usually walks around in a limited area.
ref_frame: reference frame used as the navigation frame and the attitude reference.
0: NED (default), with x axis pointing along geographic north,
y axis pointing eastward,
z axis pointing downward.
Position will be expressed in LLA form, and the reference velocity of
the vehicle relative to the ECEF frame will be expressed in the body
frame, and GPS velocity will be expressed in the NED frame.
1: a virtual inertial frame with constant g,
x axis pointing along geographic/magnetic north,
z axis pointing along g,
y axis completing a right-handed coordinate system.
Position and velocity will both be in the [x y z] form in this frame.
**Notice: For this virtual inertial frame, position is indeed the sum of
the initial position in ECEF and the relative position in the virutal
inertial frame. Indeed, two vectors expressed in different frames should
not be added. This is done in this way here just to preserve all useful
information to generate .kml files.
This post is a few months old now, I was wondering if the odometer input has been included in a future version of the software?
We have an upcoming application that requires velocity aiding.