Inclusion of magnetic field strength sensor

[osrf-migration]

Original report (archived issue) by Andrew Symington (Bitbucket: asymingt).

---

What would be really useful to multirotor research is the inclusion of a magnetic field strength sensor to compliment the IMU sensor already in Gazebo. What I propose is the following...

In the world SDF file...

#!xml

<physics>
   <magnetic>0.10 0.7 0.1</magnetic>
</physics>

And, in the model SDF file...

#!xml

<sensor name="HMC5843" type="magnetometer">
  <pose>0.01 0 0.03 0 -0 0</pose>
  <magnetometer>
    <noise>
      <type>gaussian</type>
      <mean>0.0</mean>
      <stddev>0.01</stddev>
    </noise>
  </magnetometer>
</sensor>

The sensor itself would just take the global magnetic field strength vector, and rotate it from the world frame into the current sensor pose.

Thoughts?

[osrf-migration]

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

---

That sounds good to me. If you know the magnetic field orientation at your test site, you can just specify it in the tag that you propose.

A more complicated alternative would be to try to compute the magnetic field based on the spherical_coordinates values. This would require a planetary magnetic field model.

Or we could make a flag so you could choose between a model-based magnetic field and a manual override.

<physics>
   <magnetic_field type="manual">0.10 0.7 0.1</magnetic_field>
</physics>

<physics>
   <magnetic_field type="model">0 0 0</magnetic_field>
</physics>

[osrf-migration]

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

---

Cool idea. Is there a source for magnetic field data?

We should place the <magnetic> tag as a child of <world>, similar to <spherical_coordinates>.

[osrf-migration]

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

---

Google led me to the following:

• Summary of several models from NOAA
• International Geomagnetic Reference Field, also here's a scientific paper documenting the model

[osrf-migration]

Original comment by Andrew Symington (Bitbucket: asymingt).

---

For CRATES I have been using the world Magnetic and Geographical models from GeographicLib: https://bitbucket.org/asymingt/crates/src/ae976a3786cdf5a16cd30c663a7ac3d40b21b841/src/sim/src/plugins/world/Environment.cpp?at=master

My (clunky) solution was to attach a plugin to the world, siphon off the origin spherical coordinates / simulation time and broadcast realistic gravitational and magnetic vectors on the gazbeo transport. There's probably a neater way to do this, though.

I am reluctant to suggest that we go for this degree of realism as the default Gazebo behaviour, because it would also introduce more dependencies and large geoid / parameter files. I think we should rather keep its behaviour along the same lines as gravity, and the more complex stuff can be added as a sensor plugin.

I've forked gazebo master, and I'm coding up what I think is a nice way of doing things. I'll send through a pull request in the next couple of days.

[osrf-migration]

Original comment by Andrew Symington (Bitbucket: asymingt).

---

Also, as a side note, the World Magnetic Model (WMM) seems to be the go-to model for UAV flight control systems: http://www.ngdc.noaa.gov/geomag/WMM/calculators.shtml

Although gravity changes a bit (mostly by latitude because of the shape of the earth) its variation can be easily accounted for by simple calibration procedures when the multicopter is stationary on the ground. As far as I know, the same cannot be done for the magnetic field.

[osrf-migration]

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

---

That's a good point about dependencies and complexity. I think we could make <magnetic_field> a child of <world> and use a plugin from a separate package to provide the WMM model. Thanks!

[osrf-migration]

Original comment by Andrew Symington (Bitbucket: asymingt).

---

Yes, my initial idea was to treat the magnetic field in a similar way to gravity; although, I expect you want to create the sdf element relative to the world tag, rather than the physics tag. Here's my work in progress (!), which seeks to provide basic magnetometer and altimeter support. The code compiles but is untested. https://bitbucket.org/asymingt/gazebo/commits/3c7f6fb82194727c3f6597e5cb6623128ee583af

As you can probably tell, much of the code was lifted from the ImuSensor.cc code.

[osrf-migration]

Original comment by Silvio Traversaro (Bitbucket: traversaro).

---

Probably slightly unrelated, but as a user that simulates an IMU that provides in a single sensors a 3-axis accelerometer, a 3-axis gyroscope and a 3-axis magnetometer I would love the option of having the magnetometer reading available from the existing ImuSensor (just an option, because not all the IMUs are equipped with magnetometers).

On the other hand, it would also be useful to have separate accelerometers and gyroscope sensors (similarly to the proposed magnetometer sensor), as not all the available sensors of this kind are packed into an IMU. [1] This is a bit of a design rebus, for which I currently don't have a solution.

[1] Some examples of standalone accelerometer on real robots :

• PR2 gripper accelerometer https://github.com/PR2/pr2_simulator/issues/85

• CellulARskin taxel with embedded accelerometer http://www.cellularskin.eu/specifications.html

[osrf-migration]

Original comment by Andrew Symington (Bitbucket: asymingt).

---

I agree with Silvio. However, strictly speaking, a magnetometer shouldn't fall under the category 'inertial', as it measures only extrinsic forces, whereas IMUs measure intrinsic forces. Collectively, I believe a magnetometer and IMU are bundled into a motion processing unit (MPU), which provides derived values like orientation.

As Silvio mentioned, there are often cases -- particularly when energy is constrained -- where a standalone accelerometer is used. I guess what I am saying, is that IMUs and MPUs are metasensor packages, with magnetometers, gyroscopes and accelerometers being the actual sensors.

Again, maybe a bit pedantic. But, it may be useful to make design decisions that give rise to a logical division between a base sensor and sensor bundles.

[osrf-migration]

Original comment by Silvio Traversaro (Bitbucket: traversaro).

---

+1 for finding a proper terminology for distinguish between IMU and IMU + magnetometer.

In XSens documentation [1][2] I found they use the Attitude Heading Reference System (AHRS) term for IMU + magnetometer. Unfortunately I found it used in other contexts also for referring to simple IMUs, or even referring to units with an integrated GPS. Perhaps there is a relevant standard for this definitions?

[1] : http://www.xsens.com/tags/imu/

[2] : http://www.xsens.com/tags/ahrs/

[osrf-migration]

Original comment by Andrew Symington (Bitbucket: asymingt).

---

An AHRS is a system (sensors + motion processing algorithm) for calculating orientation, normally in the context of flight. I would be reluctant to call the IMU + magnetometer combination an AHRS, because that's only one of the many potential uses of an IMU+MAG combination. For example, a 6DoF kinematic tracking filter goes one more step and integrates specific force (linear acceleration - gravity) through orientation to obtain displacement. Other uses of a IMU+MARG include pedometry, activity detection, vibration monitoring, etc.

Despite the fact that MARG is more frequently used in the literature, I'd be more in favour of MPU, because -- like IMU -- the "unit" suffix suggests that the device is an aggregation of sensors.

One last thing to think about is whether we even need to aggregate sensors into these units. In addition to perhaps being slightly simpler to add, the only distinct advantage that I can see with bundling sensors into these units is the ability to write a SensorPlugin that synthetically generates correlated error perturbations.

This invites an even larger discussion about how spatiotemporal (integral to GNSS performance), temperature (sometimes integral to IMU) and pressure (integral to altimeters) correlated errors should be dealt with in Gazebo. Although, this should probably all go into a different issue on the tracker.

[osrf-migration]

Original comment by Andrew Symington (Bitbucket: asymingt).

---

Another thought I had with this concerns ROS integration. There is a widely-used sensor_msgs package in ROS, which provides common sensor message structures. This package defines separate IMU and MagneticField messages, and it would be in Gazebo's interest to keep the same mapping. It's a bit of a hack, but one could use negative covariance matrix diagonals to indicate the absence of data, zeros when the data is error-free/deterministic, and positive when the statistic is available. The equivalent IMU message on Gazebo's protobuffer transport doesn't yet include covariances, although Gaussian noise perturbations are offered.

[osrf-migration]

Original comment by Andrew Symington (Bitbucket: asymingt).

---

@scpeters, jumping back to the original magnetometer idea...

I think we should keep things simple from the outset. In a similar way to how gravity is dealt with, lets assume that the robots will all experience the same magnetic field, because they are operating over short baselines. This will avoid us needing a world magnetic model, and yet another third party library. I therefore don't think there's the need to declare a manual attribute just quite yet.

So, we'd have this markup in the world:

<physics>
   <magnetic_field>0.10 0.7 0.1</magnetic_field>
</physics>

... and this markup in the model...

<sensor name="HMC5843" type="magnetometer">
  <pose>0.01 0 0.03 0 -0 0</pose>
  <magnetometer>
    <noise>
      <type>gaussian</type>
      <mean>0.0</mean>
      <stddev>0.01</stddev>
    </noise>
  </magnetometer>
</sensor>

The sensor would work in much the same way as how gravity influences an IMU accelerometer. The global magnetic vector should be rotated into the body frame, using the orientation of the sensor.

Are you cool with this? If so, are you able to action it, or should I?

[osrf-migration]

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

---

That looks fine to me. I'm a little swamped right now, so I would be much more able to review a pull request than to submit one of my own. :)

One thing to think about is what the default value of the magnetic_field should be. I assume it shouldn't be 0 0 0.

[osrf-migration]

Original comment by Andrew Symington (Bitbucket: asymingt).

---

For simplicity, I think the unit vector should be 0 1 0 (adopting the RHS coordinate system ENU). This makes the bold assumption that true and magnetic north are aligned, which is actually not the case. One exception to this general rule is that if a nonzero heading R is specified in <spherical_coordinates>, then the magnetic field vector should be rotated by -R about the Z axis. I believe the SI unit for magnetism is the Tesla, but because of the unit magnitude, microTeslas may be more useful.

Given that the earth's magnetic field is approximately 50 microtesla (http://hypertextbook.com/facts/1999/DanielleCaruso.shtml) one of the following two initial values are probably OK.

For microtesla: 0 50 0

For Tesla: 0 0.00005 0

[osrf-migration]

Original comment by Johannes Meyer (Bitbucket: johmeyer).

---

Just for the record: hector_gazebo_plugins provides a 3D magnetic field sensor simulation as a ROS plugin since 2012. We use it successfully for our quadrotor simulation based on Gazebo: hector_quadrotor.

It should be noted that the magnetic field is not at all parallel to the earth surface except near the equator. The magnetic inclination is about 60 degrees in Europe and in the US and grows to 90 degrees when coming closer to the poles. So the vertical component is even larger than the horizontal one. The angle between true and magnetic north is called declination.

GazeboRosMagnetic in hector_gazebo_plugins has the declination, inclination and magnitude as plugin parameters and uses them to calculate the earth fixed magnetic field vector. I would propose to make these three parameters properties of the world instead of the vector itself as they are easier to lookup in the web or at least it is easier to assign reasonable default values. I usually use the NOAA magnetic field calculator based on their World Magnetic Model (WMM2010).

With respect to terminology the term IMU is often misused for what should be an AHRS in the robotics community. Originally (in the navigation community) an "IMU" (Inertial Measurement Unit) is nothing more than a sensor unit consisting of a (3-axis) gyroscope and a (3-axis) accelerometer and measures angular rates and accelerations (including gravity) in the body frame. With high-grade gyroscopes the angular rate signals can be integrated to a relative orientation, but the MEMS sensors that are affordable and commonly used in robotics applications have too much noise and drift and pure integration would be useless. If combined with an estimator that fuses angular rates and accelerations such a device is called an "ARS" (Attitude Reference System) or "IRS" (Inertial Reference System) that outputs the roll and pitch angle. Only with an additional magnetic field sensor the absolute yaw angle is also observable, making the ARS an "AHRS" (Attitude and Heading Reference System). The acronym "MARG" (Magnetic, Angular Rate, and Gravity) is used for the sensor array within an AHRS. Last but not least, if the system also integrates the measured accelerations and outputs velocities or even position it is usually called an "INS" (Inertial Navigation System). Again, with MEMS sensors pure integration without external aiding (e.g. by GNSS) would be useless as the error would grow too fast. These definitions can be found in many text books about the topic and also at the Xsens web page.

To come back to the original topic of this issue: A magnetic field sensor is an independent sensor and should not be integrated in the IMU sensor plugin.

[osrf-migration]

Original comment by Andrew Symington (Bitbucket: asymingt).

---

I agree with @johmeyer about keeping the distinction between IMU and MAG sensors. We should give a decent default value (inclination and declination) for the magnetic field. Perhaps we can use the WMM2010-derived field strength at the OSRF office -- [5.5645 22.8758 -42.3884] microTesla -- for the time the sensor was added, and use that as a default value? This could easily be changed by a user in the world file. We could even write a short tutorial for the Gazebo wiki.

From what I can tell, hector_quadrotor implements all quadrotor-specific sensors (GPS, IMU, barometric pressure, magnetometer) as ModelPlugin types. I can understand why this is the case for barometric pressure and magnetometer (these sensor types don't yet exist in Gazebo), but not for the GPS and IMU sensors, where a SensorPlugin type exist. Was there a reason for this design choice? Branching off from my comments in Issue #1285, would it not be a good overall design goal to integrate more sensor base types into SDF / Gazebo, with varying levels of complexity encoded as SensorPlugins.

[osrf-migration]

Original comment by Johannes Meyer (Bitbucket: johmeyer).

---

The reason why the plugins in hector_gazebo_plugins are implemented as ModelPlugins and not SensorPlugins is easy: We wanted to use these sensors only in a ROS environment with the precompiled Gazebo libraries, so we did not consider to patch Gazebo/SDF or send a pull request when development has started. The IMU plugin started as a fork of the gazebo_ros_imu plugin in the gazebo_plugins package, which is also implemented as a ModelPlugin and does not use Gazebo's IMUSensor. The fork was necessary as this plugin does not simulate an IMU, but an AHRS (e.g. the acceleration output is without gravity). Barometric pressure, magnetometer and GPS plugins were not yet available in 2012.

[osrf-migration]

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

---

@johmeyer Thanks for chiming in. It's true that the hector_quadrotor plugins predates the GPSSensor implementation in Gazebo. For ROS users, hopefully we can agree on common functionality for the upstream sensor implementations in Gazebo.

Regarding the definition of the parameters as a Vector3 or a sequence of magnitude and angles, I think Gazebo eventually wants the magnetic field as a Vector3. For the sdf parameter, it sounds like the preferred format will depend on the format used by available tools for computing the magnetic field.

It looks like NOAA has a tool that will generate both sets of parameters based on IGRF 11 or WMM 2010:

http://www.ngdc.noaa.gov/geomag-web/#igrfwmm

From my perspective as a Gazebo developer, if that NOAA tool is sufficient, I would prefer the SDF parameter to use a Vector3 format to simplify the Gazebo code. Other opinions welcome.

[osrf-migration]

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

---

Has this been solved by pull request #1788?