IMU details

[osrf-migration]

Original report (archived issue) by dan (Bitbucket: dan77062).

---

I understand that the simulated imu has a noise model and I see the parameters for that. However, I don't understand what the topic imu/data/bias is reporting. Also, will the imu model ever use noise with a dc offset? At the moment, it looks like the Gaussians all have mean = 0, so there is not a constant drift.

[osrf-migration]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

Each IMU currently has these noise properties:

  <imu>
                    <angular_velocity>
                        <x>
                            <noise type="gaussian">
                                <mean>0</mean>
                                <stddev>2e-4</stddev>
                                <bias_mean>0.c21418dad948081c655f5360ec77331c9fb2a8e4</bias_mean>
                                <bias_stddev>0.6dbd7bd8b1ac62854f8fac49c0fb99d081a72b90</bias_stddev>
                                <dynamic_bias_stddev>0.6b64ee5c30bcc8843fa43dd05b5d713c5f6762aa</dynamic_bias_stddev>
                                <dynamic_bias_correlation_time>1000.0</dynamic_bias_correlation_time>
                            </noise>
                        </x>
                        <y>
                            <noise type="gaussian">
                                <mean>0</mean>
                                <stddev>2e-4</stddev>
                                <bias_mean>0.c21418dad948081c655f5360ec77331c9fb2a8e4</bias_mean>
                                <bias_stddev>0.6dbd7bd8b1ac62854f8fac49c0fb99d081a72b90</bias_stddev>
                                <dynamic_bias_stddev>0.6b64ee5c30bcc8843fa43dd05b5d713c5f6762aa</dynamic_bias_stddev>
                                <dynamic_bias_correlation_time>1000.0</dynamic_bias_correlation_time>
                            </noise>
                        </y>
                        <z>
                            <noise type="gaussian">
                                <mean>0</mean>
                                <stddev>2e-4</stddev>
                                <bias_mean>0.c21418dad948081c655f5360ec77331c9fb2a8e4</bias_mean>
                                <bias_stddev>0.6dbd7bd8b1ac62854f8fac49c0fb99d081a72b90</bias_stddev>
                                <dynamic_bias_stddev>0.6b64ee5c30bcc8843fa43dd05b5d713c5f6762aa</dynamic_bias_stddev>
                                <dynamic_bias_correlation_time>1000.0</dynamic_bias_correlation_time>
                            </noise>
                        </z>
                    </angular_velocity>
                    <linear_acceleration>
                        <x>
                            <noise type="gaussian">
                                <mean>0</mean>
                                <stddev>1e-2</stddev>
                                <bias_mean>0.1</bias_mean>
                                <bias_stddev>0.001</bias_stddev>
                                <dynamic_bias_stddev>0.002</dynamic_bias_stddev>
                                <dynamic_bias_correlation_time>300.0</dynamic_bias_correlation_time>
                            </noise>
                        </x>
                        <y>
                            <noise type="gaussian">
                                <mean>0</mean>
                                <stddev>1e-2</stddev>
                                <bias_mean>0.1</bias_mean>
                                <bias_stddev>0.001</bias_stddev>
                                <dynamic_bias_stddev>0.002</dynamic_bias_stddev>
                                <dynamic_bias_correlation_time>300.0</dynamic_bias_correlation_time>
                            </noise>
                        </y>
                        <z>
                            <noise type="gaussian">
                                <mean>0</mean>
                                <stddev>1e-2</stddev>
                                <bias_mean>0.1</bias_mean>
                                <bias_stddev>0.001</bias_stddev>
                                <dynamic_bias_stddev>0.002</dynamic_bias_stddev>
                                <dynamic_bias_correlation_time>300.0</dynamic_bias_correlation_time>
                            </noise>
                        </z>
                    </linear_acceleration>
</imu>

Details about the noise properties can be found here.

[osrf-migration]

Original comment by Martin Dlouhy (Bitbucket: robotikacz).

---

I am just curious - observed anybody changes in simulated IMU with transition from Gazebo9 to Ignition? (I did so I wonder it if is related to simulation timing or something else)

[osrf-migration]

Original comment by Martin Dlouhy (Bitbucket: robotikacz).

---

p.s. it looks like it was really related to timing of older simulation (in the new one I am “hitting” virtual wall, so I do not know yet if it is better)

https://robotika.cz/competitions/subtchallenge/virtual-tunnel-circuit/en#190901

[osrf-migration]

Original comment by Neil Johnson (Bitbucket: realdealneil1980).

---

Was the IMU in the simulator based on a real-world sensor? If so, some assumptions had to be made regarding how to take parameters from the datasheet (like angular random walk, velocity random walk, in-run bias stability, bandwidth, etc) to translate those into the mean/stdev terms used in the simulator model. There is one particular term that we believe is correctable in IMUs in general: the bias mean. In general, decent IMUs are factory calibrated to remove (or minimize) the bias mean. We would suggest decreasing it from 0.1 to 0.01, but this is not a number that can be pulled directly from a datasheet, so it is a little tricky to back this up with a real world model.

We have found that making this change results in an IMU that supports some Visual Inertial Odometry algorithms (such as ROVIO), and therefore we believe that it is a valid parameter change to make (since ROVIO works in the real world). ROVIO typically fails if the accel bias mean is 0.1. We believe the bias mean of 0.01 is achievable on most if not all MEMS accelerometers if they are factory calibrated (temperature compensated). We can issue a pull request for this change, but we first wanted to have some discussion in the forum to see if there is agreement.

[osrf-migration]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

• set assignee_account_id to "557058:10b01d41-a2e9-4a41-a907-e6e2f03b6cd5"
• set assignee to "iche033 (Bitbucket: iche033, GitHub: iche033)"

Ian, can you please dig up information about where we go the IMU parameters? Addisu could probably help you as well.

[osrf-migration]

Original comment by Ian Chen (Bitbucket: Ian Chen).

---

The values are the same as the ones from gazebo tutorials. Looks like they are also the same values we used for atlas back in DRC

‌

[osrf-migration]

Original comment by Neil Johnson (Bitbucket: realdealneil1980).

---

The real problem I’m seeing is that the model in gazebo has a nonzero bias mean. While an uncalibrated IMU might indeed have a nonzero bias, any IMU that is intended to be used on a real robot should be factory calibrated so that the bias is identically zero. IMU biases can exist such as “turn-on-turn-off” bias and the bias has some long-term instability (which is characterized by the bias stability term), but the nonzero bias mean on the accelerometer in the gazebo model is not something that can be derived from a datasheet.

Do you know what IMU that was based on? The problem is that datasheets don’t specify these values in the same way they are modeled. IMU’s are typically characterized according to their “angular random walk” and “velocity random walk”, as well as the noise density, and bias stability. I’m not aware of a formula for converting from such parameters into “bias mean” and “bias std dev.”

How is the “bias_mean” term used in the IMU model? That would help us know how to convert from datasheet terms into gazebo model terms.

We would like to have an IMU model that represents the following IMUs:

1. VectorNav VN-100. Price: $800. (Specs: https://www.vectornav.com/products/vn-100/specifications)
2. Analog Devices ADIS16448 IMU. Price: $665. (https://www.analog.com/media/en/technical-documentation/data-sheets/ADIS16448.pdf)
3. Analog Devices ADIS16488 Tactical IMU. Price: $1800. (https://www.analog.com/media/en/technical-documentation/data-sheets/ADIS16488.pdf)

If we can only add one new IMU model, I’d like it to be based on the ADIS16448 because that was used in the EuRoC dataset and can therefore be directly compared with standard data (and most of the VIO methods have been shown to work on that data set).

‌

[osrf-migration]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

We don't have the exact IMU information used to create the simulation model. During the DRC we worked with BDI to create the simulation model. The current IMU model was used by teams to control the Atlas humanoid robot, and by teams during the Space Robotics Challenge to control Valkyrie.

I'll propagate the request for a new IMU model up the chain of command.

[osrf-migration]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

Side note, I believe you could create alternative robot configurations with your preferred IMU and submit them to this repository as new configurations.

[osrf-migration]

Original comment by Neil Johnson (Bitbucket: realdealneil1980).

---

Okay, thanks Nate. We’re going to add one X2 and one X3 with nice IMUs based on existing sensor configurations. I’ll do my best to convert from datasheet parameters to the gazebo IMU model. By the way, I’m following this guide to convert from datasheets to simulated parameters:

https://github.com/ethz-asl/kalibr/wiki/IMU-Noise-Model

I’ll try to write up my method for determining the model parameters.

[osrf-migration]

Original comment by Neil Johnson (Bitbucket: realdealneil1980).

---

FYI: I have now determined what I think are good parameters for modeling the ADIS16448 in the subt simulator. I found this resource:

ethz-asl/kalibr#63

From that, I took the parameters in the datasheet and was able to come up with numbers for the gyro and accel noise stddev:

Gyro: 2.356e-4

Accel: 2.256e-3

These come from taking the gyro and accel noise density terms and converting into radians and m/s^2 respectively.

The above link says that you can’t really come up with bias mean/stddev terms from datasheet parameters, so I stuck with the bias mean and stddev in subt sim for the gyro, but changed the bias mean and stddev for the accel to be just a couple of orders of magnitude worse than the gyro (but not 5 orders of magnitude as the previous model implied). The resulting model is being pushed into a pull request for ssci_x2_sensor_config_9 that will be posted soon.

[osrf-migration]

Original comment by Sophisticated Engineering (Bitbucket: sopheng).

---

I do not have experience with IMU, but would this change of the IMU parameters also be needed for the other robots?

[osrf-migration]

Original comment by Neil Johnson (Bitbucket: realdealneil1980).

---

I asked DARPA in this post: https://community.subtchallenge.com/t/suitability-of-existing-virtual-testbed-vehicles-for-missions/1221/2

They said the following:

“Altered IMU characteristics may be considered if the proposed characteristics can be supported by a datasheet for a commercially-available IMU. Please include a reference for the cost of the IMU. The SubT Credits assigned to configurations using any new sensor models will, in part, be based on costs of a relevant commercially-available IMU.”

If they approve the models with the updated IMUs, then these may get used on other vehicles. But, OSRF and DARPA would have to decide if the existing vehicles in the tech repo would get updated IMU options.

[osrf-migration]

Original comment by Martin Dlouhy (Bitbucket: robotikacz).

---

Note, that models/vehicles are part of the release (I am not sure if they are part of docker images, I hope yes) and the deadline for testbed code freeze is in 5 days:

‌

Upcoming dates and deadlines for Virtual Urban Circuit:
1.      Sensor Configuration Submission Deadline (11DEC)
2.      SubT Virtual Testbed Code Freeze (18DEC)
3.      Team Qualification Deadline (03JAN)

… so there is not much time left and I would suggest to use new submissions for experiments/testing. It would be nice to have option which IMU would you like to have on your robot (cheaper or more expensive, but much more precise), but that will not happen in a week - our proposal is in #293. That way you could use “old configuration” or experiment with new one if it will improve results without complex submission process … maybe Cave Circuit??

[nkoenig]

Closing due to age.