Inclusion of magnetic field strength sensor #1294
Comments
|
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. |
|
Original comment by Nate Koenig (Bitbucket: Nathan Koenig). Cool idea. Is there a source for magnetic field data? We should place the |
|
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters). Google led me to the following: |
|
Original comment by Andrew Symington (Bitbucket: asymingt). For CRATES I have been using the world Magnetic and Geographical models from GeographicLib: 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. |
|
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: 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. |
|
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters). That's a good point about dependencies and complexity. I think we could make |
|
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. As you can probably tell, much of the code was lifted from the ImuSensor.cc code. |
|
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 :
|
|
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. |
|
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? |
|
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. |
|
Original comment by Andrew Symington (Bitbucket: asymingt). Another thought I had with this concerns ROS integration. There is a widely-used |
|
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? |
|
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 |
|
Original comment by Andrew Symington (Bitbucket: asymingt). For simplicity, I think the unit vector should be 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: For Tesla: |
|
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.
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. |
|
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 -- From what I can tell, hector_quadrotor implements all quadrotor-specific sensors (GPS, IMU, barometric pressure, magnetometer) as |
|
Original comment by Johannes Meyer (Bitbucket: johmeyer). The reason why the plugins in hector_gazebo_plugins are implemented as |
|
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters). @JOHMEYER Thanks for chiming in. It's true that the Regarding the definition of the parameters as a 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. |
|
Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina). Has this been solved by pull request #1788? |
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...
And, in the model SDF file...
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?
The text was updated successfully, but these errors were encountered: