IMU Consistency Issues

[pbo...@clearpathrobotics.com]

Hello sig-drivers,

Motivated by answers.ros.org/question/200480/imu-message-definition/, I've looked into sorting out some inconsistencies with IMU data reporting in ROS. I compared the performance of a UM6 and a GX3 we had in house.

--------

GX3 Results (using https://github.com/ros-drivers/microstrain_3dmgx2_imu): 

 - reference orientation respected (x-forward, y-left, z-up) is with the sensor upside down, x +ve pointed towards magnetic north in the reference orientation. (see image: http://www.designworldonline.com/uploads/ImageGallery/microstrain.jpg)

- angular_velocity reported correctly, +/- rotations correspond appropriately with right-handed conventions

- linear_acceleration:

    - z reported correctly (+ve when sensor is z-up)

    - x reported incorrectly  (-ve when sensor is x-up)

    - y reported incorrectly  (-ve when sensor is y-up)

- orientation:

    - z reported correctly 

    - x reported incorrectly (+ve x rotation results in -ve x orientation)

    - y reported incorrectly (+ve y rotation results in -ve y orientation)

Other than that, it behaves as expected. When the sensor is rolled on its side, the angular_velocities are still reported in the body frame of the sensor. However, since the orientation is reported incorrectly, it would be impossible for a client to transform the angular_velocity data out of the body frame and into a fixed frame.

---------

UM6 Results:

The reference orientation is with the sensor upside down, cable pointing down (http://www.chrobotics.com/shop/images/284/UM6+angle+scaled.JPG). However, in the ROS driver we are flipping it right side up by swapping x with y, and z = -z. 

- reference orientation not respected (driver transforms internally x = y, y =x, z = -z to make the sensor right side up)

- angular_velocity reported correctly

- linear_acceleration not in SI units

- orientation reported correctly

[pbo...@clearpathrobotics.com]

Following from http://answers.ros.org/question/172672/microstrain_3dmgx2_imu-confirmity-to-ros-spec/, there are probably some inconsistencies with the way different Microstrain devices (GX2, GX3-xx) behave. Would any one be able to confirm these results? I used a 3DM-GX3-25 for testing.

I think this makes the case for a REP amendment, or a whole separate IMU REP to clarify certain issues:

- sticking to the manufacturer's reference frame vs transforming so that sensor is right side up, very common since sensors are typically designed to be mounted upside down on aircraft

- acceleration vector positive and in SI, on axis pointed upwards (i.e. in reference orientation, should be +9.807.. on linear_acceleration.z)

[Tom Moore]

+1 for an IMU REP. 

Also, if the outcome of the REP is that orientation data is reported in some world-fixed frame, and angular velocity/linear acceleration is reported in the sensor's body frame, then I think that the sensor_msgs/Imu message ought to be updated with a second frame_id. We can either assume that the header's frame_id refers to the world frame and add a sensor_frame_id, or we can assume that the header's frame_id refers to the sensor frame and add a world_frame_id. Thoughts?

[Alex Brown]

Hi guys,

 

Re Mike’s earlier message,  I agree that the driver seems the most logical place to perform any transformation from non-ROS conforming sensors to ROS standards.  Having the driver conform to the sensor manufacturer’s spec and have ROS users add a subsequent transformation just seems more complex. If there is a driver designed for a specific sensor with the correct transformation built in, then the job is done.

 

Paul mentioned that sensors are commonly installed upside down; but in my 30 years in commercial aircraft avionics design I saw very little of that (accels, rate gyros, vertical gyros, IMUs, INS), actually I can think of none.  Perhaps in the military it happens when they have to shoehorn equipment into small places.  Such an installation would require a transform.  But if there is a common need for such an alternate installation, perhaps it could be provided for in the driver as a parameter selection.

 

Alex

 

From: Tom Moore

Sent: Monday, January 19, 2015 11:54 AM

To: ros-sig...@googlegroups.com

Subject: [ros-sig-drivers] Re: IMU Consistency Issues

 

+1 for an IMU REP. 

 

Also, if the outcome of the REP is that orientation data is reported in some world-fixed frame, and angular velocity/linear acceleration is reported in the sensor's body frame, then I think that the sensor_msgs/Imu message ought to be updated with a second frame_id. We can either assume that the header's frame_id refers to the world frame and add a sensor_frame_id, or we can assume that the header's frame_id refers to the sensor frame and add a world_frame_id. Thoughts?

On Monday, 19 January 2015 13:53:29 UTC-5, pbo...@clearpathrobotics.com wrote:

--
You received this message because you are subscribed to the Google Groups "ROS Drivers Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-drive...@googlegroups.com.
To post to this group, send email to ros-sig...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-drivers/84d41a5e-3996-4faa-b6e1-2c359cb39419%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tom Moore]

I suppose I don't feel strongly one way or another. Part of me really likes the idea of all driver nodes producing data that conforms to the same standard, and the other part of me likes the idea of the drawings on the IMU matching what the user sees. One thing I think we should consider is the case of an IMU whose default output isn't right-handed. In that case, we'd have to violate the IMU's drawings anyway, as we can't work with left-handed data. Maybe if we're willing to do that for any IMU in isolation, we might as well be willing to do it for all of them, and just make them all conform to the same standard.

[Chad Rockey]

The short summary is that the IMU drivers absolutely have to follow ROS's standards or they don't do anyone any favors.  A significant part of shared ROS resources is that they are interchangeable.  It shouldn't matter which IMU you have publishing, if someone across the world receives a sensor_msgs/Imu in the same frame as a sensor_msgs/Image, then they should be able to run experiments with visual odometry for instance, even if you gave them different bag files containing data from different Imus and different cameras, it should all just work.

That being said:

The accelerations and angular velocities are not reported and transformed in a global frame, they are reported in the frame of the sensor.

The orientation is a more complicated matter, please see my earlier statements on this:

http://answers.ros.org/question/50870/what-frame-is-sensor_msgsimuorientation-relative-to/

Re: updating the message to add a frame, please see the ros answers link above and:

It's difficult but possible to adjust message definitions in between ROS distributions.  Adding fields is the only proven method, but you still invalidate all bag files that currently exist that contain that message.

Re: Incorrect coordinate frames

There really should only be two different IMU coordinate frames: right handed and left handed.  Anything else is ultimately user error or an inconsistent device.  ROS uses right handed coordinate frames.  The IMU should output according to its native frames.  So if your IMU has its x axis not aligned with the x axis of the robot, you won't be able to interpret that data without transformation.  However, this doesn't mean that the driver should try to handle what happens if the IMU changes mounts or isn't aligned right.  That should be reflected within changes in the transform between the IMUs mounted frame and the vehicle's frame.

I've released a tool that will allow you to transform IMU data from the mounted frame_id to your /base_link or whichever frame you want to view the data in:

https://github.com/ros-perception/imu_pipeline/blob/indigo-devel/src/imu_transformer.cpp

If microstrain outputs data incorrectly between different models that use the same communication protocol, then the drivers will need patched to handle each sensor individually.  This would be a good case for a pull request to patch up the driver and sensor that are misbehaving.

To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-drivers/0ffd62d8-9656-4878-9499-18cd5cabcd0b%40googlegroups.com.

[Mike Purvis]

The whole point of having ROS distributions is being able to introduce breaking changes in these types of things— I could be persuaded to vote for a world_frame_id to be added to sensor_msgs/Imu for Jade, such that:

• angular_velocity and linear_acceleration are published in the header.frame_id frame, and
  
• orientation publishes the orientation of header.frame_id relative to world_frame_id.

If world_frame_id is null, then the sensor is without any absolute reference and publishing only inertial data (though in reality, even those devices which don't have or use magnetometer data still probably publish roll and pitch relative to a flat X-Y plane).

The counterargument from my perspective is— what would we put in that field? None of the Clearpath platforms supply a "world" frame, so maybe that should be specified to the consuming nodes by a channel other than bundled with the message. Does the IMU meaningfully know anything about it, or is it always just going to be passed through from a parameter? If so, maybe this isn't work the hassle of a change.

Chad, I think Paul's argument is that a device can "follow the ROS standard" by publishing right-handed data in (say) an NED frame, and then it's the user/integrator's responsibility to supply a frame which accounts for the needed transform. I'm not necessarily agreeing with that, but the devices are still interchangeable— perhaps even moreso, since you can follow the drawings on them when mounting, instead of relying on the driver author's interpretation of which part of the device is "forward" or "up".

Mike

To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-drivers/CALRt%2BqY5HDvsaAFApcoUGsbfQTodkS4RKKa%3D%2BuaSVeuDUpjqNw%40mail.gmail.com.

[Chad Rockey]

There's a lot of bagged data out there now and bag migration is unfortunately very painful to convert all of that data over.  My opinion is that the message shouldn't be updated unless absolutely necessary and the issues with the world frame id are resolved.  It's easy to do a distro change because runtime systems are not affected.  Those working from logged data though have a completely different and terrible experience.  I'd honestly support a WorldReferenceIMU message more than changing the current one - other than adding comments which don't affect the md5 sum and could clear up issues working between the two.

I agree with Mike's proposal for how the data would be published, though.  I'm just not clear about what the right way to use the world frame would be, especially as it's a gravity field and not a Euclidean tf frame.  Certainly beyond a certain distance (achievable by some ROS robot if none other than robonaut, :) ), the tf paradigm breaks down and it doesn't make sense.  I guess it's really an issue for the geographic_info SIG more so than ROS drivers.  We would also need to settle the ENU or NED, but that is arguably strongly domain based and is why ROS hasn't easily settled on a standard so as to not alienate land vs air or attempt to maintain a dual standard.

I guess I'm not 100% clear on if Paul and I disagree at all then.  The driver should output data in the standard frame of the device.  Two IMUs that are mounted with aligned X, Y, and Z axes would ideally output identical data.  Uses the native axes helps you ensure that the data is accurate and not aliased or inaccurate at publish time.  If the driver varies from this, I would consider that driver flawed and recommend a pull request/fork.  Maybe discussion about this issue is complicated in that IMUs imply three frames: device (header), world (ENU, NED, gravity non-yaw referenced), and then vehicle (base_link) orientation/motion that actually moves the device frame through the world frame.

To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-drivers/CACsJT9NCwmJzLZgZJTNhpyubYsKeCqONKHP9aYS56_STqC-iXQ%40mail.gmail.com.

[Jack O'Quin]

+1 to creating an IMU REP.

I am inexperienced at working with inertial measurement units. I recently found a need to write an IMU driver, and find most of this discussion over my head. Chad's answers.ros.org link on orientation was very helpful. The REP should include much of that discussion.

We should take advantage of my ignorance: if I can understand our final documentation it will probably suffice for other "dumb users", too. :-)

[Eric Perko]

On Tue, Jan 20, 2015 at 12:40 AM, Chad Rockey <chadr...@gmail.com> wrote:

There's a lot of bagged data out there now and bag migration is unfortunately very painful to convert all of that data over.  My opinion is that the message shouldn't be updated unless absolutely necessary and the issues with the world frame id are resolved.  It's easy to do a distro change because runtime systems are not affected.  Those working from logged data though have a completely different and terrible experience.  I'd honestly support a WorldReferenceIMU message more than changing the current one - other than adding comments which don't affect the md5 sum and could clear up issues working between the two.

I'm against making another IMU message alongside the current one - I think this will just promote confusion as to which IMU message should be used. As painful as bag migrations are, I'd prefer that over having multiple message types that basically mean the same thing (except really, sensor_msgs/Imu would then be a poor version of WorldReferenceIMU, since the latter contains all fields in sensor_msgs/Imu plus frames for describing what the measurements are relative to). As an alternative, should we split sensor_msgs/Imu into 3 different stamped messages and deprecate the merged one? I like this from a standpoint of avoiding those cases where you have a sensor that cannot fill all of sensor_msgs/Imu fields, you simply don't publish that message (e.g. orientation for devices that only have gyros and accelerometers, but where the gyros aren't good enough to get absolute orientation via measuring Earth's rotation).

 

To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-drivers/CALRt%2BqbG5umKyw3RksxPV3Nq0JsgS0%3Dq%3DxgoFWsnktOXFTOKpQ%40mail.gmail.com.

[Tully Foote]

A few quick comments.

First, there more costs to splitting the messages into multiple submessages which are transfered in parallel. It's more book keeping and more synchronization. Unless there's a blocked use case keeping it as a single message is probably better. I have heard of issues with the overall size of the message for arduino scale devices.

For the 2nd frame_id I'm not sure that should be embedded in the sensor driver's configuration and then into the message. What the world frame_id is system dependent and does not change the information that the IMU measures. If we do change the orientation reference frame it will always reference to the inertial frame, nothing else, thus it is up to the system integrator to choose what frame they consider the closest proxy to the inertial frame. And it's actually potentially application specific. I see this as the equivalent of the fixed_frame in the advanced TF API, where the system is told, use this coordinate frame as the inertial one at query time.

And I'll reiterate Chad's point that interoperability is of maximum importance. You should be able to simply swap out one sensor for another one, whether you need a lower cost solution or a higher precision solution it should not change the interface.

It is possible to change messages between distros, but changes to any core message need to make a very strong case, because if you change a core message you break hundreds or thousands of packages.

Tully

To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-drivers/CAOtrKv%3DZkbvqxBQGd8RdHHHDQvybUOiuJiwsZjwLg-Ct8Cy%2BEg%40mail.gmail.com.

[pbo...@clearpathrobotics.com]

I've created a sensor_msgs::Imu transform in tf2 https://github.com/ros/geometry_experimental/pull/78

After some pondering on the topic, what really differentiates an ENU and NED Imu?

- the IMU's 'zero' orientation is different:

                - ENU Imu is zero'ed when x-east, y-north, z-up

                - NED Imu is zero'ed when x-north, y-easy, z-down

As far as I can tell, the rest is standard across both types:

- angular_velocity is relative to the device axes

- in the 'zero' orientation, the acceleration vector points in the +z direction.

So for both types of device, a base_link->imu_link transform should take care of the configuration, since base_link is assumed to be ENU. If I've written the transforms correctly, then IMU data from a device mounted in a non-standard orientation can be post-processed using tf2 to act as an IMU in the base_link frame (ignoring for a minute the linear<->angular acceleration problem).

I still think the above is important to standardize in a REP, however adding a 'world_frame' parameter might not be, unless I've missed something.

[pbo...@clearpathrobotics.com]

act as an *ENU* IMU in the base_link frame

[Alex Brown]

Hi guys,

 

I’d like to release my driver for the UM7 soon, so I want to confirm that we agree on basic operation. Hence, the following attempts to define what the sensors actually do to see if we agree on that much. I have two specific questions at the end which I’d appreciate a reply to.

 

    Please excuse the “for Dummies” wording, but when I try to sort something out in my head, I try to do it with enough detail that an inexperienced person could understand”

 

    First accelerometers:   There are 3 accelerometers measuring accel along the X,Y and Z axes.  They do not always measure accel of the vehicle relative to the Earth.  The only time that these will measure all zeros for a non-accelerating vehicle is if the vehicle is so far from a gravitational source that gravity is negligible relative to the vehicles normal motions.  One Earth, gravity is the main force measured.

 

    So, for a vehicle that is stationary on the Earth with X and Y axes tangent to the Earth, the X and Y axes will read zero g’s and the Z axis will read +1 g.  If the vehicle tilts (pitch) nose up (negative direction about the Y axis),  the X accelerometer will read positive (forward) acceleration and the Z axis will read reduced positive g’s until at 90 degree nose up, X will be at + 1 g and Z at 0 g’s.  The Y axis remains at zero throughout.

 

    The roll axis responds similarly, if the the  vehicle rolls 90 degrees to the right (positive direction about the X axis), the Y accelerometer will read + 1 g and the Z will read zero.  X will be unchanged.

 

    Accelerometer response does not change regardless of the direction the vehicle is pointed at the start.

 

    Angular rate is easier since it has no response to gravity or any other outside influence.  It simply measures the rate of change of the vehicle’s attitude.  It responds the same regardless of the attitude, the acceleration or direction of the vehicle.

 

    It gets more complicated when the IMU starts computing additional data from these sensors.  The most common computed data is vehicle attitude (roll, pitch & yaw).  These are estimated by integrating the angular rate signals.   (note:  these calculations are often done with a Kalman filter to get optimized results, but I’ll describe them in terms of integrators). Simple integrators (with no initialization) would supply attitudes relative to the original orientation of the vehicle and would tend to drift with time; hence, gravity is used as a reference to determine the direction of the Z axis and the integrated gyros are corrected so that the X and Y axes will be parallel to the Earth.  The X and Y axes will still be of arbitrary yaw direction (i.e. the original direction of the vehicle when integration began plus any drift that has occurred).

 

    The X and Y accelerometers are used to determine the gravity vector and have the disadvantage that they measure not only gravity but also actual acceleration of the vehicle.  Hence, if the vehicle accelerates for some time, the gyros may erect to the wrong orientation (i.e. the Z axis is not aligned with gravity).

 

    For most operation this is not a problem since vehicles seldom hold sustained acceleration over a long period of time; and the time constant of the gravity correction can be set long enough to filter out most of this error.

 

    However there are two cases where continuous acceleration can occur.  An aircraft making a continuous banked turn in a circular pattern is normally controlled to maintain the Y axis acceleration at zero for comfort.  Hence, in a 30 degree bank turn,  the gravity vector will appear to be at 30 degrees of roll attitude and after the above correction takes place the roll attitude will appear to be zero.  There are tricks that can be done to reduce this effect, but they usually leave the roll attitude susceptible to long term drift.

 

    A similar effect can be seen in a ground based robot that remains level to the Earth, but turns in a continuous circle.  In this case, the Y axis will see a continuous acceleration value and cause the roll axis attitude to adjust to an erroneous value.

 

    Up until now,  the direction of the vehicle about the Z axis has no effect on any of the above signals.  However, the yaw signal (integrated angular rate about Z) is not constrained and will inevitable drift to completely erroneous values.  Hence, IMUs commonly include a magnetometer which can determine the direction of magnetic North.  The integration of yaw is slaved to the magnetometer (usually optionally) to prevent drift (under optimal magnetic environments maybe).

 

    The one issue that isn’t clear to me is that if we are using an ENU system and the X axis is aligned with East, does the yaw or heading signal read 0 or 270 degrees (-pi/2) when the vehicle is actually pointed East.  That is, does North retain the heading value of 0 degrees; or does 0 degrees mean that the X axis is pointing East?

 

    Paul suggests the latter: X axis pointing East reads zero degrees of yaw.  At http://answers.ros.org/question/9968/gps-track-angle-course-over-ground/  , Michael Carroll says the same.  I have found other non-ROS sources that say the same.   I can live with that if you all agree.  (I’m going to miss North and this will probably leave a permanent kink in my brain ;-)

 

    Another question that I’ve forgotten up until now, am I correct in assuming that all angular readings should be in the range +/- PI?

 

Thanks,

Alex

 

From: pbo...@clearpathrobotics.com

Sent: Thursday, January 22, 2015 8:47 AM

To: ros-sig...@googlegroups.com

Subject: Re: [ros-sig-drivers] Re: IMU Consistency Issues

 

act as an *ENU* IMU in the base_link frame

On Thursday, January 22, 2015 at 11:46:12 AM UTC-5, pbo...@clearpathrobotics.com wrote:

[Chad Rockey]

That's pretty close.

An accelerometer will report all zeros in free fall.

The methods and corrections of integrations are up to you and your application.  As you mentioned, vehicles have to compensate for the angular effects of moment arms on the accelerometer using the gyro reading.

Yes, the closest thing we have to a standard at this point defines East as zero yaw.  Since sky goes from the ground to the sky, the angles also increment opposite that of compass heading.

Finally, sensor msgs Imu does not use Euler angles at all.  It uses quaternions to avoid angle application order issues as well as avoiding gimbal lock singularities.

Side note: Kalman filters for Imus are incredibly verbose implementations.  Depending on your accuracy required and computation available, I recommend looking at some of the alternate fusing algorithms provided in the hobby airplane or quadrotor community.  Google's android also includes a simple and effective apache v2 license algorithm you could try:

https://github.com/cozybit/aosp-frameworks-base/blob/master/services/sensorservice/Fusion.cpp

--

You received this message because you are subscribed to the Google Groups "ROS Drivers Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-drive...@googlegroups.com.
To post to this group, send email to ros-sig...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-drivers/F6427ED240AE435280AF1A254EE85C30%40DDT3.

[Mike Purvis]

Per recent changes to REP-0103, the ENU convention is explicitly called out: http://www.ros.org/reps/rep-0103.html#coordinate-frame-conventions

We're been satisfied with using imu_filter_madgwick in conjunction with raw gyro/accel/mag data. The main downside is that it's a GPL implementation, preventing the library from being linked into a single process with other relevant parts of the system.

To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-drivers/CALRt%2BqYz%3DbnemDjYZj99CvihESbruXEEkC0cz-npisoMj7fO4g%40mail.gmail.com.

[pbo...@clearpathrobotics.com]

Can I suggest that since the UM7 is an NED sensor, the driver should provide the data as-is? If it works similarly to the UM6, that means the compass heading will be 0 when pointing north (for NED). It would then be up to the receiver of the data to transform it into the desired orientation using tf. To comply with REP-0103, the default frame_id for the IMU data would then be imu_link_ned.

For integration with postprocessing by imu_filter_madgwick, it would be helpful to break out the mag data in a similar way that the UM6 does, on the /imu/mag topic. That way users could choose whether to use the UM7's internal EKF, or an external one. I don't know if CHR has improved it for the UM7, but with the UM6 the internal EKF is broken for any non-standard starting orientations.

[pbo...@clearpathrobotics.com]

Also I was mistaken, in the 'zero' orientation, i.e. where the device axes are tangent to earth (so for NED, x-north, y-east, z-down), the acceleration vector would still point 'up', so (0,0,-9.81) for an NED device.

But this is all based on what I have coming out of the UM6, so I guess it'll be the same for a UM7.

[Alex Brown]

Thanks guys,

 

    I’m in agreement with Tully’s comment   “And I'll reiterate Chad's point that interoperability is of maximum importance. You should be able to simply swap out one sensor for another one, whether you need a lower cost solution or a higher precision solution it should not change the interface.”

which, I think, was also mentioned by Mike.  The only way to achieve this is if everyone publishes to the same rules.  Hence, I’m going to go with the transform to make it as much like REP-103 as possible and with zero yaw pointing East.

 

    I’ll also retain the imu/rpy Euler angle message which Mike has in his UM6 driver.  It may be susceptible to gimble lock, but for those of us who operate in a 2D environment with no possibility of gimble lock, it is an easy access to the yaw angle.

 

   The Kalman filter I was referring to is included in the UM7 sensor’s software, it is not added as postprocessing.   Hence, it has no impact on the software running under ROS.

 

    And by the way,  I qualified my statement as “The only time that these will measure all zeros for a non-accelerating vehicle...”  and a vehicle in free-fall is continuously accelerating toward the source of gravity. :-)

 

Thanks again,

Alex

 

From: pbo...@clearpathrobotics.com

 

 

Sent: Friday, January 23, 2015 11:16 AM

To: ros-sig...@googlegroups.com

Subject: Re: [ros-sig-drivers] Re: IMU Consistency Issues

Can I suggest that since the UM7 is an NED sensor, the driver should provide the data as-is? If it works similarly to the UM6, that means the compass heading will be 0 when pointing north (for NED). It would then be up to the receiver of the data to transform it into the desired orientation using tf. To comply with REP-0103, the default frame_id for the IMU data would then be imu_link_ned.

 

For integration with postprocessing by imu_filter_madgwick, it would be helpful to break out the mag data in a similar way that the UM6 does, on the /imu/mag topic. That way users could choose whether to use the UM7's internal EKF, or an external one. I don't know if CHR has improved it for the UM7, but with the UM6 the internal EKF is broken for any non-standard starting orientations.

On Friday, January 23, 2015 at 1:34:39 PM UTC-5, Mike Purvis wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-drivers/1fcc66d2-dbf4-4051-80ba-9b8707bc361b%40googlegroups.com.

[Alex Brown]

The last message I left (Jan 23) said I would modify my UM7 driver to provide zero yaw pointing East.  I was thinking of this as rotating the quaternion pose 90 degrees from North  After a bit of thought, I realized that my knowledge of matrices, linear math, and quaternions was not up to this change.  So, I spent a few days studying and finally came up with an implementation using the tf/LinearMath library which seemed to work perfectly.  Happiness!

  But last night, about 2 am in bed, it came to me that the rotation isn’t necessary, at least for the UM7.  The UM7 does not actually default to North when in magnetic correction mode.  Mine seems to power up at an angle of about 76 degrees (for reasons unknown to me).  It is subsequently possible to send a “set_mag_ref” command to the sensor, which causes the yaw angle to adjust to zero at the direction existing when the command is sent.  Hence, the operator (or autonomous robot), must aim the robot in the desired direction, be it magnetic East, true East, North or whatever and send the set_mag_ref command. From then on, zero yaw is that direction. So, since the robot can be set to East as easily as North, there is no need to rotate the computed data.

  In retrospect, I probably should have figured this out a lot sooner; but at least I improved my education level.  I’ll include this technique in the wiki instructions.

  Does anyone see any problem with this rationale?

[pbo...@clearpathrobotics.com]

Hi Alex,

That's along the same lines that the UM6 driver is currently setup - leave the data as is coming from the sensor, and postprocess as necessary in other nodes. Making frame transformations in driver just couples everything together and makes it confusing for the robot integrator.

Because the data from the UM6 doesn't actually initialize to north for NED (or any other consistent heading), I've found it useful to use imu_filter_madgwick to do the filtering. Since it operates in ENU, I use an intermediary nodelet to do the transform:

https://github.com/husky/husky_bringup/blob/imu-orientation-fix/launch/um6_config/um6.launch

https://github.com/ros-perception/imu_pipeline/tree/metapackage-refactor

I think this is really the cleanest way without applying transforms in the driver, which wouldn't be sufficient for our use case anyways since the IMU is mounted sideways.

Since we don't actually have a UM7, and I was wondering if you could verify something for me. We have a lot of trouble with sideways-mounted UM6s, where the internal EKF would initialize incorrectly and go into a strange drift. Would you please be able to check if the UM7 orientation output is stable when the sensor is powered on sideways?

Regards,

Paul

[Alex Brown]

Hi Paul,

 

    By sideways,  I assume you mean an orientation where the circuit board is perpendicular to the ground.  So, I oriented the sensor in a 90 degree right wing down (for us aero types) position, applied power to the sensor  and used the CHR Serial Interface software to monitor the 3 euler angles.

Roll attitude came up as 90 degrees,  pitch attitude was about zero and yaw was at drifting in the negative direction until I issued a zero gyros command and it stopped drifting (well, back to the usual very slow drift).  This looked almost normal, except I rotated the sensor in all 3 axes.  If I rotate the sensor about its “usual” Y axis (now pointed vertical, the yaw direction moved appropriately.  If I rotate it about the usual Z axis (now pointed horizontal and in the direction I would usually consider forward), pitch attitude changes appropriately.  But if I rotate about the X axis (the usual roll axis) the roll attitude varies + and – about the 90 degree initial value.  Seems a little strange, but probably usable.  The signals did remain stable over a 20 minute time.

 

    The acceleration signals are also stable and react appropriately except that Y and Z are swapped.  Rate gyro signals also look OK except pitch and yaw are swapped.  It looks to me (in a very fast look) like the signals would be usable with some transformations (and maybe sign changes).

 

Alex

 

    

From: pbo...@clearpathrobotics.com

Sent: Thursday, January 29, 2015 11:19 AM

To: ros-sig...@googlegroups.com

Subject: [ros-sig-drivers] Re: IMU Consistency Issues

Hi Alex,

 

That's along the same lines that the UM6 driver is currently setup - leave the data as is coming from the sensor, and postprocess as necessary in other nodes. Making frame transformations in driver just couples everything together and makes it confusing for the robot integrator.

 

Because the data from the UM6 doesn't actually initialize to north for NED (or any other consistent heading), I've found it useful to use imu_filter_madgwick to do the filtering. Since it operates in ENU, I use an intermediary nodelet to do the transform:

https://github.com/husky/husky_bringup/blob/imu-orientation-fix/launch/um6_config/um6.launch

https://github.com/ros-perception/imu_pipeline/tree/metapackage-refactor

 

I think this is really the cleanest way without applying transforms in the driver, which wouldn't be sufficient for our use case anyways since the IMU is mounted sideways.

 

Since we don't actually have a UM7, and I was wondering if you could verify something for me. We have a lot of trouble with sideways-mounted UM6s, where the internal EKF would initialize incorrectly and go into a strange drift. Would you please be able to check if the UM7 orientation output is stable when the sensor is powered on sideways?

 

Regards,

Paul

On Thursday, January 29, 2015 at 12:34:06 PM UTC-5, Alex Brown wrote:

--

You received this message because you are subscribed to the Google Groups "ROS Drivers Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-drive...@googlegroups.com.
To post to this group, send email to ros-sig...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-drivers/c5d842d9-40a3-42e1-9ea5-555bad8bb315%40googlegroups.com.

[pbo...@clearpathrobotics.com]

Hi Alex,

The instability was probably an Euler angle thing. Sounds like the issue I was seeing with the orientation being totally unusable in UM6 may have been fixed for UM7, thanks a lot for checking. Looking forward to your driver release!

Paul

[pbo...@clearpathrobotics.com]

Hi everyone, 

I've written up a draft for an IMU REP here (https://github.com/paulbovbel/imu_rep_draft/blob/master/imu_rep_draft.rst). I'm very keen on getting your comments, concerns, and fixes, feel free to put them here or do a pull/issue on github. After that's resolved, I'll see about taking the process further.

Thanks,

Paul

[Martin Günther]

On Wed, 4 Feb 2015 13:56:04 -0800 (PST)
pbo...@clearpathrobotics.com wrote:

> Hi everyone,
>
> I've written up a draft for an IMU REP here
> (https://github.com/paulbovbel/imu_rep_draft/blob/master/imu_rep_draft.rst).
> I'm very keen on getting your comments, concerns, and fixes, feel
> free to put them here or do a pull/issue on github. After that's
> resolved, I'll see about taking the process further.
>
> Thanks,
> Paul

Hi Paul,

thanks for your work, looks really good already!

I've opened a couple of PRs and issues:

https://github.com/paulbovbel/imu_rep_draft/pull/1
https://github.com/paulbovbel/imu_rep_draft/issues/2
https://github.com/paulbovbel/imu_rep_draft/issues/3
https://github.com/paulbovbel/imu_rep_draft/issues/4

Looking forward to a lively discussion on GitHub!

Best wishes,
Martin

[Alex Brown]

Hi Paul,

 

    Good start on a needed document.

 

    I’ve attached a copy with my comments on it.  Excuse me if I got a bit carried away.  I’m not adamant about all these; the ones I care about should be apparent.   I wasn’t sure what formats you guys use (I’m mostly Windows ;-), so I chose a simple fomat (RTF).

 

Alex

 

From: pbo...@clearpathrobotics.com

Sent: Wednesday, February 04, 2015 1:56 PM

To: ros-sig...@googlegroups.com

Subject: Re: [ros-sig-drivers] Re: IMU Consistency Issues

 

Hi everyone, 

 

I've written up a draft for an IMU REP here (https://github.com/paulbovbel/imu_rep_draft/blob/master/imu_rep_draft.rst). I'm very keen on getting your comments, concerns, and fixes, feel free to put them here or do a pull/issue on github. After that's resolved, I'll see about taking the process further.

 

Thanks,

Paul

On Sunday, February 1, 2015 at 2:10:46 PM UTC-5, pbo...@clearpathrobotics.com wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-drivers/72469a1f-22a4-4839-a531-4fcee63dedda%40googlegroups.com.

[Tully Foote]

Thanks for taking the initiative Paul it looks like this will become a good rep. After integrating the feedback from this list including possibly iterating, it would be great to turn it into a pull-request on the main repo and announce it for comments to all ros users.

Tully

To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-drivers/0E1464BB24154B1CAA2B99D12B45DF32%40DDT3.

[pbo...@clearpathrobotics.com]

Hi Alex,

Thanks for the extensive feedback. I've created a pull that contains my edits wrt your comments, and attached a commented rtf doc. In the spirit of more-openness for others participating, can you add any further comments/edits as pulls on github?

In response to:

The previous paragraph raises the basic philosophical difference as to whether the driver should report data in accord with REP 103, or in accord with the conventions of the sensor manufacturer. I'm voting on the side of making driver output standard across all sensors with the driver striving to make interchangability possible without changes to the users' code.

This is exactly what I'm trying to reconcile with this REP. My belief is that for the most part, manufacturer conventions don't have to conflict with REP 103 as long as the transforms are setup correctly. For example, I've updated the um6 driver to report in NED, which is the main issue with manu-spec IMU reporting. This data should then be published in /imu_link_ned here. The naming will be a change for Jade. 

By applying a transform using tf2 and transforming the data into base_link using imu_transformer, the data is now ENU. This is the great thing about ROS's transforms - whether dealing with optical data (z forward x right ), ENU, or NED, we're always a transform away from making everything useable in a different context (as long as it's right handed). These transforms are traditionally done client side, since this way the ROS device driver publishes expectedly 'raw' data, that matches up with spec sheets and etc. I'm against modifying data on the driver side unless it breaks the consistency of tf(2). Hopefully once the transform is pulled into tf2, and is actually used by clients, intermediary nodes like imu_transformer won't be necessary.

Paul

[pbo...@clearpathrobotics.com]

Alex's comments also led to a significant refactoring of some sections, as well as a new parameters section, so if anyone would like to re-review, I would welcome it.

[pbo...@clearpathrobotics.com]

Will do Tully. Would you be able to assign me a REP number for the pull?

[Alex Brown]

Hi all,

 

In a previous email, I suggested numerous changes to Paul's document attempting to clarify the way that I believe a driver should perform.  It now seems clear that Paul and I have quite different approaches.  Paul suggests that the driver should publish data that retains the orientation specified by the manufacturer (i.e. NED like, or ENU like) and leave any necessary transformations up to the user.  I believe that the driver should convert the IMU data received from the sensor into REP-103 conforming data (ENU) as closely as possible.

 

Either of these approaches can work, but I think that we should decide which which way to go before getting into  the details of the proposed REP.

 

One goal of "std-msgs" is to provide interchangeability between data sources.  In the best of worlds, it should be possible to replace one IMU/driver combination with another and user software would still operate properly.  This can only occur if there is a single definition for the message content.  Paul states that the user software can use transforms to correct the data as required.  This is true, but requires every user to provide these transforms and to change them if a new IMU is desired.  If the driver makes the tranformations, it only has to be done once (by the driver writer) and will be transparent to the users.

 

Paul points out that if it is necessary to mount the IMU sensor in a non-standard orientation, a transform will be required anyway.  This is true, but with IMU sensors being such a small size (about 1 inch square for the UM6 and UM7 that we are using), it should be quite uncommon that it is necessary to use a non-std mounting.  If so, the user can add the transform. As an alternative, if we could agree that only a couple alternative mounting orientations are needed (e.g. 90 degrees nose up, or 90 degrees right wing down), it might be relatively easy to make these transformations in the driver; selectable by parameter.

 

Alex

 

From: pbo...@clearpathrobotics.com

Sent: Friday, February 06, 2015 2:49 PM

To: ros-sig...@googlegroups.com

Subject: Re: [ros-sig-drivers] Re: IMU Consistency Issues

Alex's comments also led to a significant refactoring of some sections, as well as a new parameters section, so if anyone would like to re-review, I would welcome it.

To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-drivers/5ecd3f47-18ca-41d7-a3cf-fdff5a01c064%40googlegroups.com.

[Mike Purvis]

Alex— I was originally strongly in the "always convert it to ENU" camp, but I've softened on that, hence the provision for the _ned suffix frame made in REP-103. The argument for officially blessing this is compelling: the data which comes out matches the axes printed on the device itself. This is important particularly for not baffling a novice ROS user. OTOH, the use case of swapping one IMU for another applies pretty exclusively to advanced users, who are more likely to be aware of the implications.

As long as drivers doing this publish the data in the imu_link_ned frame rather than imu_link, that feels to me like a sufficient hint to the integrator that they need to provide not just base_link -> imu_link, but also imu_link -> imu_link_ned.

Maybe this is excessively magical, but perhaps tf2_ros could have some specific checks for these situations and ROS_WARN accordingly. For example, attempting to transform the imu_link_ned frame to base_link, where that frame doesn't exist, but imu_link does, it could indicate to the user that the IMU is providing NED data and suggest the necessary transform to add (such a thing could be generalized to also be aware of the _optical suffix).

To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-drivers/D7DFB462751D492EA874B1837423774E%40DDT3.

[Alex Brown]

Mike,

 

    I would hope that the driver wiki page would explain the transformation to ROS coordinates.  And as a recent (still?) novice,  having to add transforms to get something to work isn’t exactly making it easier.    On the other hand,  I’d have no objection to making both topics available.  Some drivers (like the kinect) have no problems providing data in every format you can dream of.  Still seems like one format should be the ROS standard.

 

    I actually consider the standardized messages a bit limiting.  Imu.h implies that the only data needed from an IMU is Orientation, accels and rate gyros.  There is other useful data supplied; at a minimum, the magnetometer (maybe even rpy?).  It would be nice if it was possible to combine messages so that they could be sent in a single topic.  Another thing I miss (from the autopilot business) is validity, or health, info associated with each signal.  The UM7 (and I think, the UM6) provides health data for the accels, the gyros and the magnetometer; but there is no way to indicate health in the imu message.  This info would allow for graceful degradation in the event of a partial IMU failure.  Someone, I think it was Paul, said that a –1 in the first cell of the covariance matrix implied that the data was invalid.  I thought it only meant the covariance was “not reported”.

 

    By the way, as a semi-novice, what is the _optical suffix?  another frame?

 

Alex

 

From: Mike Purvis

Sent: Saturday, February 07, 2015 9:28 AM

To: ros-sig...@googlegroups.com

Subject: Re: [ros-sig-drivers] Re: IMU Consistency Issues

 

Alex— I was originally strongly in the "always convert it to ENU" camp, but I've softened on that, hence the provision for the _ned suffix frame made in REP-103. The argument for officially blessing this is compelling: the data which comes out matches the axes printed on the device itself. This is important particularly for not baffling a novice ROS user. OTOH, the use case of swapping one IMU for another applies pretty exclusively to advanced users, who are more likely to be aware of the implications.

 

As long as drivers doing this publish the data in the imu_link_ned frame rather than imu_link, that feels to me like a sufficient hint to the integrator that they need to provide not just base_link -> imu_link, but also imu_link -> imu_link_ned.

 

Maybe this is excessively magical, but perhaps tf2_ros could have some specific checks for these situations and ROS_WARN accordingly. For example, attempting to transform the imu_link_ned frame to base_link, where that frame doesn't exist, but imu_link does, it could indicate to the user that the IMU is providing NED data and suggest the necessary transform to add (such a thing could be generalized to also be aware of the _optical suffix).

On 7 February 2015 at 12:04, Alex Brown <rbi...@cox.net> wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-drivers/D7DFB462751D492EA874B1837423774E%40DDT3.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "ROS Drivers Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-drive...@googlegroups.com.
To post to this group, send email to ros-sig...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-drivers/CACsJT9MXfgDC4uEWEdp-9iWofuBLa-jmehhGZiKaeUbVf%3Dn_Mw%40mail.gmail.com.

[Paul Bovbel]

The issue with internal driver transformations is something that frustrated me while debugging issues and integrating several different IMUs recently. Once the driver makes internal transformations for convenience, all bets are off as far as compatibility and interoperability. If not using the manufacturer's spec for the body axes, there will inevitably be confusion about which side is the front, etc. Having to go on the ROS wiki and hope that there's a diagram of the modified body axes is a stretch.

On the other hand, configuring the transform tree appropriately actually makes it much easier to swap sensors, and yes, that includes alternative mounting configurations. Simply pull up the TF tree in rviz, make sure the imu_link transform is oriented the same way as is printed on the sensor, and the TF system will take care of everything for you. Transforming data before consumption into a 'working frame' such as base_link, odom, etc. is a very typical way for ROS nodes to operate.

As far as changing message types, I would agree that there are improvements to be made to the current partial amalgamation of data in sensor_msgs/Imu, however I couldn't think of a strong enough case to do it. Syncing messages across different topics is not great (if a different topic is provided for mag, accel, gyro etc), and neither is checking for unreported data in one big message by querying for '-1', and it's hard to make a case for switching wholesale to one or the other, when the cost for message changes is so high in terms of backward compatibility.

Looking at the UM7 datasheets, there could be several ways to handle the health data. I assume you're discussing the boolean flag that goes high when there is a fault in gyro, mag, or accel. This data should certainly go into the sensor `/diagnostics`. I'm not sure if any downstream consumers would handle it correctly, but it may make sense to not report that data field and place the -1 in the covariance matrix for that cycle only, or to not publish at all until all flags are low again.

[Mike Purvis]

The value of having standardized messages is well worth their modest cost. If you need to send metadata alongside the main data message, you can do so in a device-specific topic, or if it's really just intended for human consumption, the standard /diagnostics scheme (as Paul suggests). Chad Rockey's pointgrey_camera_driver which I maintain does this— it supplies the standard suite of image topics, but also some additional technical data in device-specific messages.

My impression is that ROS messages in general are minimalist, with an expectation that you will synchronize multiple topics if you need multiple kinds of data for your processing.

Something to note about the IMU message which could perhaps be made more clear in the REP draft is that I don't think the angular_velocity field is meant to be for raw gyro data. It's meant to be for the angular velocity as reported by the device— it's for the output of the same EKF which produces the orientation estimate, and is therefore corrected for drift and so-on.

Putting unprocessed gyro and accelerometer data into a sensor_msgs/Imu should be reserved for situations where the topic name clearly calls out that this has been done (eg, /imu/data_raw).

M.

To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-drivers/3e334e87-7fc1-4ec9-a070-1265a3d276e2%40googlegroups.com.

[Tully Foote]

On Fri, Feb 6, 2015 at 3:22 PM, <pbo...@clearpathrobotics.com> wrote:

Will do Tully. Would you be able to assign me a REP number for the pull?

It looks like you should use 145.
 

To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-drivers/d45fee2f-941d-4eab-b65f-56bdb78d6f38%40googlegroups.com.

[Martin Günther]

Hi Mike,

On Sat, 7 Feb 2015 15:38:08 -0500
Mike Purvis <mpu...@clearpathrobotics.com> wrote:

> Something to note about the IMU message which could perhaps be made
> more clear in the REP draft is that I don't think the
> angular_velocity field is meant to be for raw gyro data. It's meant

> to be for the angular velocity *as reported by the device*— it's for

> the output of the same EKF which produces the orientation estimate,
> and is therefore corrected for drift and so-on.

That's assuming the robot in question actually has sensors that allow
correcting for drift (accelerometers/magnetometers).

On our old robots, all we had was a single gyro that measured angular
velocity around the yaw axis. We represented this by filling in the yaw
component of the angular_velocity and orientation fields and setting
the roll and pitch covariances to `std::numeric_limits<double>::max`,
without correcting for drift. This was happily processed by
robot_pose_ekf.

As pointed out here [1], this works because robot_pose_ekf only uses
the change in orientation and doesn't assume that the orientation is
already corrected for drift. The advantage is that it works for all
types of IMU, but we don't get all we can out of our sensors.

The REP should allow this kind of usage of the Imu msg. I think it
already does.

> Putting unprocessed gyro and accelerometer data into a sensor_msgs/Imu
> should be reserved for situations where the topic name clearly calls
> out that this has been done (eg, /imu/data_raw).

Encoding any kind of information in the topic name doesn't sound like a
good idea. Ideally, we would have a field in the Imu msg that specifies
the orientation type, but we don't. For now, we need to tell the
consuming nodes via a parameter what kind of orientation is provided
(drift corrected (on which axes?) or not at all), if they need this
information.

Best,
Martin

[1]:
http://answers.ros.org/question/50870/what-frame-is-sensor_msgsimuorientation-relative-to/

[Martin Günther]

Hi Mike,

On Sat, 7 Feb 2015 15:38:08 -0500
Mike Purvis <mpu...@clearpathrobotics.com> wrote:

> Something to note about the IMU message which could perhaps be made
> more clear in the REP draft is that I don't think the
> angular_velocity field is meant to be for raw gyro data. It's meant

> to be for the angular velocity *as reported by the device*— it's for

> the output of the same EKF which produces the orientation estimate,
> and is therefore corrected for drift and so-on.
>
> Putting unprocessed gyro and accelerometer data into a sensor_msgs/Imu
> should be reserved for situations where the topic name clearly calls
> out that this has been done (eg, /imu/data_raw).

I just re-read your message, and I think I missed your point in my
first reply. The angular_velocity and linear_acceleration fields are
specified relative to the body frame of the IMU, so they aren't
directly affected by drift. This is why imu_filter_madgwick simply
copies the raw gyro/accelerometer readings from the input topic to the
output topic. Of course, it also fills in the orientation field (which
isn't provided on the raw input topic).

My question is: is this the right thing to do? Would it be better to
publish the first derivative of the fused orientation on
angular_velocity? (This is what you seem to be saying.) What to do
about linear_acceleration?

Best,
Martin

[Martin Günther]

Hi Alex and Mike,

On Sat, 7 Feb 2015 10:27:52 -0800
"Alex Brown" <rbi...@cox.net> wrote:

> Someone, I think it was Paul, said that a
> –1 in the first cell of the covariance matrix implied that the data
> was invalid. I thought it only meant the covariance was “not
> reported”.

No, orientation_covariance[0...8] = 0 means "covariance not reported",
and orientation_covariance[0] = -1 means "orientation field is invalid".
Same for the other fields (linear_acceleration, angular_velocity). Also
see:

https://github.com/paulbovbel/imu_rep_draft/issues/4

> By the way, as a semi-novice, what is the _optical suffix?
> another frame?
>
> Alex

Yes, but nothing related with IMUs. It's what camera drivers (e.g.,
openni) do: They have a frame (e.g., camera_link) that follows ROS
conventions (x forward, y left, z up), and then they have a child frame
(e.g., camera_link_optical) that has the same origin as camera_link,
but a different orientation (z forward, x right, y down). The data is
usually published in the camera_link_optical frame, since "x right, y
down" is the usual convention for cameras and image processing. See REP
103, where the _optical suffix for cameras and the _ned suffix for
IMUs are mentioned:

http://www.ros.org/reps/rep-0103.html#coordinate-frame-conventions

> From: Mike Purvis
> Sent: Saturday, February 07, 2015 9:28 AM
> To: ros-sig...@googlegroups.com
> Subject: Re: [ros-sig-drivers] Re: IMU Consistency Issues
>

> Maybe this is excessively magical, but perhaps tf2_ros could have
> some specific checks for these situations and ROS_WARN accordingly.
> For example, attempting to transform the imu_link_ned frame to
> base_link, where that frame doesn't exist, but imu_link does, it
> could indicate to the user that the IMU is providing NED data and
> suggest the necessary transform to add (such a thing could be
> generalized to also be aware of the _optical suffix).

I agree it is excessively magical. :-)

TF shouldn't have a lot of special cases for IMUs and cameras and such;
all it should care about is transformations. Also, it won't help a lot
to hard-code some strings like "*_ned" and "*_optical" into TF, since
most drivers don't comply 100% with this naming (e.g., openni has
"/camera_rgb_link" and "/camera_rgb_optical_frame", whereas according
to REP 103 it should be "/camera_rgb_link" and
"/camera_rgb_link_optical").

Best,
Martin

[Martin Günther]

Dear all,

I still have the feeling that I don't fully understand everyone's
opinions about the ENU/NED conventions, so maybe let's try to tease out
what each proposal would entail in detail. I'll try to give it a start.

We'll start with:
* an IMU, publishing Imu and MagneticField msgs in the frame imu_link
* A tf transform base_link -> imu_link, usually obtained via a robot
URDF + robot_state_publisher, which describes how the IMU is mounted
on the robot. Also, a tf odom_combined -> base_link, usually obtained
via robot_pose_ekf.
* base_link has standard ROS orientation (x forward, y left, z up) wrt.
the robot, the z axes of odom_combined and base_link both point up.

Now, if we power on the IMU while the robot is stationary, the following
should happen:
* If we transform the linear_acceleration vector from imu_link into
base_link, x and y should be around 0, and z around +9.81.
* If we transform the magnetic_field vector into base_link and rotate
the robot by +n degrees around the yaw axis, the magnetic_field
vector (in the base_link frame) should rotate by -n degrees around
yaw. If we transform it into odom_combined and rotate the robot, it
should remain constant.

If you get any other readings, you need to change the base_link ->
imu_link TF until you get this. Note that *this defines where "up" is
with respect to your IMU*, and that it works with arbitrary mounting
positions of the IMU on the robot. Also, I haven't made any assumptions
whether your IMU publishes ENU or NED. Honest question: Is there already
such a distinction when only talking about accelerometers and
magnetometers?

Anyway, on to the orientation field. When the above data is passed into
the sensor fusion stage to provide the orientation, the following
should happen:

Imagine there was a world_frame tf frame that is oriented x east,
y north, z up (ENU). Then the rotation of the tf transform from
world_frame -> imu_link should be identical to the orientation field of
the Imu msg. In reality, there is no tf world_frame; instead, the world
frame is defined implicitly by gravity and magnetic north.

If we want, we can have a secondary tf frame, called "imu_link_ned".
It's a child frame of imu_link, and there is a static tf (yaw rotated
by pi/2 or such, pitch rotated by pi or such, I didn't work that out
yet) from imu_link -> imu_link_ned. The IMU driver (or the sensor
fusion node, if separate) can publish a secondary topic in the
imu_link_ned frame, which can be computed by simply transforming the
original message from "? -> imu_link" into "? -> imu_link_ned".

Comments? Did I get something wrong? Does somebody want to give an
alternative proposal a shot?

Best wishes,
Martin

[Tom Moore]

I still wrestle with this a bit. On the one hand, I like the idea of an abstracted IMU sensor that always provides data in consistent frames. For example, if a given robot manufacturer created their robot to output raw wheel odometry such that the Z-axis was pointing down instead of up, that would violate the ROS spec, and I’d expect the ROS driver to be corrected. The manufacturer would clearly have documented their coordinate frames, so a novice ROS user would have to reconcile the difference between the robot’s documentation and the ROS standard.

However, in both the case above and with IMUs, if we require the driver to provide a transform from its own standard to ENU, then the data should work for anyone, and would also be less confusing for novice users. If you’re writing new software for ROS that consumes this data, you’re likely aware (or should be) of the REPs and the fact that transforms may be required to get the data in the coordinate frame(s) you require. The only thing that makes me a little uncomfortable is that I’m guessing that a robot driver that behaves as described above would not be well-received, even though it seems as though it's behaving in an analogous manner to the IMU REP.

In any case, for robot_localization, I’ll be happy to just have a standard in place that I can point to in the documentation. I think the REP looks really good, Paul. Thanks for putting it together!

> To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-drivers/CACsJT9MXfgDC4uEWEdp-9iWofuBLa-jmehhGZiKaeUbVf%3Dn_Mw%40mail.gmail.com.

[Tully Foote]

Hi Tom,

I think that a driver with your idea of requiring the transform to get to the known coordinate frame could be considered compliant if the REP is written well enough. If we have the ability to transform the messages [1] , it does make sense for the drivers to report the data in their "native" format instead of arbitrarily transforming them before publishing. ENU vs NED is a static transform. The driver could be configured to publish that transformm, from imu_link_ned to imu_link or whatever is packed as the standard link name. The important thing is that the transform tree be connected for the end users and the data accurately stamped. Although we usually mount IMUs axis aligned. We should consider that the system must be robust to any mounting position.

Tully

[1] https://github.com/ros/geometry_experimental/pull/78

To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-drivers/28A4BFCA-4E16-4F0A-8D6C-A35873E5FAD3%40gmail.com.

[Tom Moore]

Hi Tully,

That sounds good to me. I wasn't really advocating for one practice over another, but was just making sure that we were being consistent with our expectations for IMU drivers vs. any other sensor driver. Looks like we're all set there!

-Tom

[Alex Brown]

Hi all,

 

Speaking, perhaps, for much of the amateur community without a Ph.D. in math or Computer Science, and coming from an industry (commercial aircraft avionics/autopilots) where much (or all) of the standard sensor information is standardized by spec,  loading mandatory transform requirements on what should be a simple set of data just makes things much more complicated.  I know people who have built robots using ROS and have pretty much decided that it is just too much trouble.  Too much to learn and the targets keep moving.  Hence, the KISS principle makes a lot of sense if you want to build a larger community.

 

I really don’t see why there is any significant advantage in writing drivers that don’t provide data in a standard format.  Even if there turns out to be a need for some subsequent transformation (like non-standard installation orientation)  leave that work for the few people who have to do it.  For 99% of robots, it is easy to install the sensor in the preferred orientation and just use a standard data output. 

 

And I can’t see why, when we have a standard like REP – 103 that should be easy for driver writers to comply with, that we should publish driver data in other formats and require ALL the users to do the transforms to make it compatible with the rest of the ROS environment that pretty much assumes REP-103 data.  If there is really a need to publish non-REP-103 data, it should be a separate alternative message (like with the “-ned” extension) and the REP-103 message should be the standard.  Actually, it seems like it should be just as easy to perform a subsequent transform on REP compliant data as on the native data; hence, no need for native data at all.

 

Sorry if this seems a bit “rantish”, but I just can’t believe the direction things seem to be going.  But, you guys know the ROS philosophy a lot longer and better than I do.  If you agree on something, I’ll end up going with it too.

 

Alex

 

From: Tully Foote

Sent: Sunday, February 08, 2015 4:31 PM

To: ros-sig...@googlegroups.com

Subject: Re: [ros-sig-drivers] Re: IMU Consistency Issues

 

Hi Tom,

I think that a driver with your idea of requiring the transform to get to the known coordinate frame could be considered compliant if the REP is written well enough. If we have the ability to transform the messages [1] , it does make sense for the drivers to report the data in their "native" format instead of arbitrarily transforming them before publishing. ENU vs NED is a static transform. The driver could be configured to publish that transformm, from imu_link_ned to imu_link or whatever is packed as the standard link name. The important thing is that the transform tree be connected for the end users and the data accurately stamped. Although we usually mount IMUs axis aligned. We should consider that the system must be robust to any mounting position.

 

Tully

[1] https://github.com/ros/geometry_experimental/pull/78

On Sun, Feb 8, 2015 at 6:10 AM, Tom Moore <ayrt...@gmail.com> wrote:

> To unsubscribe from this group and stop receiving emails from it, send an email to mailto:ros-sig-drivers%2Bunsu...@googlegroups.com.

> To post to this group, send email to ros-sig...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-drivers/5ecd3f47-18ca-41d7-a3cf-fdff5a01c064%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups "ROS Drivers Special Interest Group" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to mailto:ros-sig-drivers%2Bunsu...@googlegroups.com.

> To post to this group, send email to ros-sig...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-drivers/D7DFB462751D492EA874B1837423774E%40DDT3.
>
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups "ROS Drivers Special Interest Group" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to mailto:ros-sig-drivers%2Bunsu...@googlegroups.com.

> To post to this group, send email to ros-sig...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-drivers/CACsJT9MXfgDC4uEWEdp-9iWofuBLa-jmehhGZiKaeUbVf%3Dn_Mw%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "ROS Drivers Special Interest Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mailto:ros-sig-drivers%2Bunsu...@googlegroups.com.

To post to this group, send email to ros-sig...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-drivers/28A4BFCA-4E16-4F0A-8D6C-A35873E5FAD3%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "ROS Drivers Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-drive...@googlegroups.com.
To post to this group, send email to ros-sig...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-drivers/CAM7qi7XG2gYhL6Zqg7NfUEuSCQGXrLDGPHa_8SRLKdyc0ioGfQ%40mail.gmail.com.

[Tully Foote]

Hi Alex,

What we're talking about will be entirely REP 103 compliant. What it will suggest is that if you use the _ned suffix the driver should be able to publish the transform from the standard link to the _ned link. (This would probably be a one line argument in the launch file with a static broadcaster, probably default to enabled. Optional so that if the system designer wants to add it to the URDF that's fine too.)

The main philosophy is that you publish the raw data, and enable the user to transform the data into whatever form they want. This is valuable because during every transformation computation is expended and information lost. Providing the user with the raw data gives them the power to make the best use of it. For example transforming and chaining covariance matrices can be very application specific and there's no generic solution except for some degenerate cases. Depending on your application you may want to do high complexity analysis to get a more precise answer or you may choose to us a simpler quicker method which is good enough and saves you bandwidth.

What we're proposing here is exactly the same thing we already do with cameras. The end user should never make assumptions about what coordinate frame data is expressed in and always transform it into the appropriate coordinate frame for their algorithm. And we work hard to give the user/developer full control and not have the system limit what they can do. This obviously is not the simplest solution but we work hard to provide the tools to make working with these systems simpler, such as tf. As long as you have a complete transform tree, you can transform any data into any coordinate frame in a few lines of code. To help with this there are several different transform publishing tools, it's built into the URDF processing tools and there are stand alone tools if you don't want to build up a full URDF.

Tully

To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-drivers/2F45FF0FFCBC4D0CBC67560D5FB35988%40DDT3.

[pbo...@clearpathrobotics.com]

On that note though, Alex does raise good points about making IMUs friendly for people just starting with ROS. I'm not sure how many of these guidelines could belong in the REP, but what are things that would make IMUs easier to use, and still follow the TF conventions?

Let's say assuming we have two differently behaving IMUs such as:

GX4, need to define a static transform

  <node pkg="tf" type="static_transform_publisher" name="tf1"

        args="0 0 0.5 1.5708 0 3.1416 base_link imu_link_ned 10"/>

UM6, need to define a static transform:

  <node pkg="tf" type="static_transform_publisher" name="tf1"

        args="0 0 0.5 0 0 3.1416 0 base_link imu_link_ned 10"/>

I think there is no way to make the IMU-swapping process zero-hassle for users. We could ask drivers to include a launch file such as here, which would provide an imu_link_ned->imu_link transform, however because of the way different sensors define body axes, even that wouldn't be universal.

Would it make sense to ask that drivers include a picture such as the above in their documentation, along with a sample launch file that brings up the transform pictured? This way:

- novice users can mount IMUs on their robot in the 'obvious' orientation above, and use the sample launch file.

- intermediate users can mount IMUs differently, and tweak the transform so that the body axes line up with the TF visualization.

- advanced integrators can mount the IMUs however they want, and work with the raw data directly.

[pbo...@clearpathrobotics.com]

Abandoning independent repo, please make further issues/pulls on https://github.com/paulbovbel/rep/blob/master/rep-0145.rst.

...

[Mike Purvis]

A few suggestions to help make this less overwhelming:

• Move the rationale to the top of the document.
• Add at least one frame diagram to supplement the text (example from Tom's localization tutorials)
• Make the abstract a brief summary of the recommendations, rather than a teaser/introduction. eg, "This REP defines common topics, namespaces, and data output conventions for representing IMU data in ROS. Specifically recommended are use of the sensors_msgs/Imu and sensor_msgs/MagneticField messages on the /imu/data and /imu/mag topics respectively, with either the imu_link or imu_link_ned frame, as appropriate to the format in which the sensor supplies data. This guidance is meant to ensure interoperability of devices and higher-level processing software within the larger ROS ecosystem."
• The "frame conventions" section is unwieldy. Is there a way to give this more of a big-picture perspective, and make it sound less like a heap of if-thens addressing specific cases?

To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-drivers/a2e914bc-3d06-408e-8b57-fa3945ec5285%40googlegroups.com.

[Tully Foote]

Paul that's very different than what I was thinking.

The IMU node should know nothing about base_link. There should be an imu_link which corresponds to the axes drawn on the IMU. It is the responsibility of the robot builder to define that offset the same as how they mount the sensor. They can do it manually with a static transform or as part of the robot model. If they change the sensor they have to change that transform, if the IMU has different axes or a different center.

The imu_link_ned should only be if it's reporting absolute angles based on a world model that's NED, such as compass heading. And the imu_link_ned should be connected to the imu_link with just the rotational offset. The absolute values can be reported in the imu_link_ned frame and all the accelerations and rates

Tully

To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-drivers/45b05338-036f-495a-8773-0c7072794ac5%40googlegroups.com.

[Martin Günther]

Hi all,

On Tue, 10 Feb 2015 11:40:58 -0800
Tully Foote <tfo...@osrfoundation.org> wrote:

> Paul that's very different than what I was thinking.
>
> The IMU node should know nothing about base_link. There should be an
> imu_link which corresponds to the axes drawn on the IMU. It is the
> responsibility of the robot builder to define that offset the same as
> how they mount the sensor. They can do it manually with a static
> transform or as part of the robot model. If they change the sensor
> they have to change that transform, if the IMU has different axes or
> a different center.
>
> The imu_link_ned should only be if it's reporting absolute angles
> based on a world model that's NED, such as compass heading. And the
> imu_link_ned should be connected to the imu_link with just the
> rotational offset. The absolute values can be reported in the
> imu_link_ned frame and all the accelerations and rates
>
> Tully

I agree with Tully: it's the robot builder's responsibility to provide
the proper transform between base_link and imu_link(_ned); this is the
same requirement that holds for all other sensors as well. This
transform might not even be static if the IMU is mounted on a
robot link that can move wrt. the robot base, but TF takes care of this
automatically (like it does for laser scanners and cameras and so on).
For localization, you're usually interested in the orientation of
base_footprint relative to some world fixed frame, so the localization
node needs to transform the IMU messages into base_footprint (like
e.g. robot_pose_ekf does).

However, I didn't get any comments on my mail from Sunday yet; perhaps
it was a bit too long, so let me try to put it into one sentence.
Assuming the robot builder has set up the correct transform
from base_link to imu_link(_ned), the following should hold if you
transform the Imu messages into base_link:

* the yaw of imu_msg.orientation is 0 when the robot points due east and
increases when the robot rotates counter-clockwise
* imu_msg.linear_acceleration.z is positive (around +9.81), x and y are
around 0 when the robot is stationary and level

Correct?

IMO, that's the crucial part still missing from the REP. I guess this
is the ENU convention.

Also, I would remove the sentence "The world frame orientation depends
on the IMU device" from the REP. The world frame orientation should be
fixed (ENU); instead, we can handle NED IMUs by rotating the body frame
(imu_link_ned). A client must be able to interpret the Imu message
without extra information (such as the orientation of the world
frame) that's not contained in the message.

The transformation imu_link -> imu_link_ned should always be this (see
attached picture):

- Rotation: in Quaternion [0.707, 0.707, 0.000, 0.000]
in RPY [3.142, -0.000, 1.571]

Best,
Martin


P.S.: I believe what I wrote above ("transform the Imu msgs into
base_link") isn't quite accurate, since we want to change the *child* of
the transform (the transform before was "world_frame -> imu_link" and
the new one is "world_frame -> base_link"), so what we should really do
is multiply the transform imu_link -> base_link with the
imu_msg.orientation.

[pbo...@clearpathrobotics.com]

I agree with Tully: it's the robot builder's responsibility to provide 
the proper transform between base_link and imu_link(_ned)

Agreed, I was looking at it from the novice-friendly perspective that we need to address. I would certainly include a picture like that, and the sample static transform on ROS Wiki, maybe under tutorials for the driver. I was wondering if there's any place for that kind of recommendation in the REP. 

 

Assuming the robot builder has set up the correct transform 
from base_link to imu_link(_ned), the following should hold if you 
transform the Imu messages into base_link: 

* the yaw of imu_msg.orientation is 0 when the robot points due east and 
  increases when the robot rotates counter-clockwise 
* imu_msg.linear_acceleration.z is positive (around +9.81), x and y are 
  around 0 when the robot is stationary and level 

Correct? 

Yes, that was my intention. I can clarify this in the REP, so that there's no confusion about what exactly ENU means.

 The world frame orientation should be 

fixed (ENU); instead, we can handle NED IMUs by rotating the body frame 

(imu_link_ned)

NED IMUs (and _ned links) have an NED world frame, no other way around it. I'd be happy for a reword-ing type pull, but I think this needs to be specified.

 

P.S.: I believe what I wrote above ("transform the Imu msgs into 
base_link") isn't quite accurate, since we want to change the *child* of 
the transform (the transform before was "world_frame -> imu_link" and 
the new one is "world_frame -> base_link"), so what we should really do 
is multiply the transform imu_link -> base_link with the 
imu_msg.orientation. 

This is actually where the ""The world frame orientation depends on the IMU device" trickiness is. When transforming IMU data, we're not just changing the child frame (imu_link_ned -> base_link), we're also changing the implicit world frame (NED -> ENU)

It's not a straight up:

orientation_quat * transform_orientation

it's actually 

inv(transform_orientation) * orientation_quat * transform_orientation

Implemented here. When transform_orientation is...

- Rotation: in Quaternion [0.707, 0.707, 0.000, 0.000] 
            in RPY [3.142, -0.000, 1.571] 

...this is equivalent to the "axis swap" that's often done to convert NED to ENU data (x y z -> y x -z)