Add ability to set IMU initial Orientation on boot

[osrf-migration]

Original report (archived issue) by John Hsu (Bitbucket: hsu, GitHub: hsu).

---

Current implementation ImuSensor::SetReferencePose() is inadequate for typical simulation use.

Users desire the ability to specify what ImuSensor::Orientation() returns after the sensor is created in the world.

The reason being some of the existing IMU sensors in the market returns it's own frame orientation in the NED frame upon boot up, and the ability to do this is in simulation is critical. With existing API, the user would have to first rotate IMU to align with NED frame before calling ImuSensor::SetReferencePose.

Proposed solution here is to add

      /// \brief Sets the current reported pose of the IMU
      /// Replaces SetReferencePose.
      /// \param _orientation current IMU reported orientation
      public: void SetReferenceOrientation(
        const ignition::math::Quaterniond &_orientation =
        ignition::math::Quaterniond());

[osrf-migration]

Original comment by DouglasS (Bitbucket: DouglasS).

---

This should definitely be improved. The way IMUs are simulated in Gazebo right now does not match the way most IMUs work in the real world w.r.t. the frame in which they report their rates. While some IMU packages or robots themselves may do some fancy filtering and cleaning up of stuff before sending out data this is not the IMU itself that does this but the robot's/kit's API. For example, Atlas has the ability to report an estimated pose for the pelvis that is gleaned from IMU data but this is not the IMU itself, just something nice provided by the Atlas API.

[osrf-migration]

Original comment by DouglasS (Bitbucket: DouglasS).

---

To clarify on my previous point.

On a real IMU, most of them are set up in such a way that they use a combination of the Earth's gravity and if a magnetometer is available the Earth's magnetic field to orient their local reference frame (usually an NED style frame) in some nominal "world" coordinates.

Based on that, you would typically see this sort of hypothetical scenario: If you create a sim world w/ 2 of the same robot, one facing true north, and one facing true south, the robot facing true south should have a yaw/heading/whatever you want to call it that's 180º separated from the robot facing true north, and if it spins around to face the exact same direction then it should be reporting the same yaw/orientation/heading/whatever, barring difference like simulated noise or whatever. In the current implementation of IMUs in Gazebo, this is not possible without doing some work in code or a plugin or something. So it doesn't reflect accurately how most IMUs actually work.

[osrf-migration]

Original comment by DouglasS (Bitbucket: DouglasS).

---

For posterity, here's a link to the product page (which includes data sheets and user manuals) for a commonly used IMU. We've used older models on past humanoids and Valkyrie is currently using them.

https://www.microstrain.com/inertial/3DM-GX3-25-OEM

[osrf-migration]

Original comment by Jordan Lack (Bitbucket: jordanlack).

---

Doug++

[osrf-migration]

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

---

reference pull request for imu types

[osrf-migration]

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

---

pull request #2316, added ImuSensor::SetWorldToReferencePose which allows user to specify the reference frame orientation in terms of the gazebo world frame.

In conjunction with sdformat pull request, provided transforms needed for a few simple reference frames e.g. NED, NWU, etc..

[osrf-migration]

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

---

stumped by the use case where the IMU uses accelerometer reading to align +/-z with gravity, but leaves heading undetermined. Does the heading align with IMU body X-Y frame? Is there a real world example device that we can model after?

Thanks

[osrf-migration]

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

---

• set version to "all"

[osrf-migration]

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

---

pull request #2339 merged

[osrf-migration]

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

---

• Edited issue description* set component to "sensors"

[osrf-migration]

Original comment by Jordan Lack (Bitbucket: jordanlack).

---

Is there any plan to fix this bug in any upcoming gazebo version @chapulina? It's a pretty critical flaw in the implementation of the simulated IMU that I doubt would take much code to fix.

[osrf-migration]

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

---

As far as I can tell, there's currently no one working on it, so you're free to propose an implementation.

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

I think calling ImuSensor:: SetWorldToReferenceOrientation(ignition::math::Quaternion::Identity); at startup will cause the sensor to report the true world orientation.

I'm looking into changing the behavior

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

in gazebo_ros_imu_sensor, we are proposing to enable reporting the orientation with respect to the world frame based on an xml parameter to allow for migration from legacy behavior (ros-simulation/gazebo_ros_pkgs#1051)

for noetic and foxy, we will warn if the legacy behavior is in use

[altineller]

which is the initial orientation of the default imu data from gazebo plugin? is it NED or NWU?