Follow REP-145

[KristofRobot]

See ros-infrastructure/rep#95

[KristofRobot]

Summary of first analysis and discussion with @PaulBouchier
(1) frame id: we need to use imu_link or imu_link_ned instead of
base_imu_link

(2) data frame: the razor-9dof device driver (Arduino code) currently publishes in NED format, independent of the exact hardware used. However, the REP expects the device data to follow the board markings. The SEN-10736 (https://www.sparkfun.com/products/10736) has board markings indicating an ENU frame. We should consider updating the Arduino device driver code to publish ENU instead.
Need to check this for other hardware supported by the Arduino device driver.

(3) world frame: our current world frame is wrong, since it uses X north, Y west -
which is in fact also against REP 103. We should change X to east, Y to north (i.e. rotation around Z of -90 degrees)

(4) topics: we need to publish on imu/data, imu/data_raw and imu/mag- rather
than just imu as done today.

(5) parameters: support for stddev parameters

[PaulBouchier]

Furthermore, since this driver has only been released for a few months, and in introducing it, topic names and the coordinate frame orientation was changed, the uptake is likely low, so we should make this not-backward-compatible (i.e. breaks existing apps) change in indigo and probably won't cause too many people a problem.

[dkoguciuk]

Hello!

I must admit it gave me a headache when trying to use this package with robot localization - nothing works like it should. After some investigation, I found out differences in world frame between razor_imu_9dof and REP103. Did you fixed any of those? I can also help, but I don't want to waste my time on something, what's already done.

Best!
Daniel

[PaulBouchier]

Hi Daniel,

I would like to understand the specific complaints or issues you ran into. Kristof & I didn't try it with robot_localization, but we did try to make it compliant with the reps and to do things in the standard way.

Specifically, as noted in the wiki page at http://wiki.ros.org/razor_imu_9dof in section 5, it is intended to comply with REP103 (units & coordinate frames, specifically by using the ENU frame). I don't remember if robot_localization predates the changes to REP103 that clarified ENU over NED. Did we miss something?

If it's not compliant in some way I'd like to fix that. Let me know what problems you ran into.

Regards

Paul

[nspo]

I'm also very confused by the coordinate systems while trying to use robot_localization. On the board (SEN 14001, https://www.sparkfun.com/products/14001, see pictures) there's an imprinted coordinate system 1 (x/y/z_board). When watching the /imu topic, a positive value (g) for linear_acceleration x is reported when holding y_board down towards earth, for y when holding x_board up, and a positive z when holding z_board down. But this is not even a right-hand coordinate system!

When checking the angular_velocity values, I get the following right-hand COS:
x_angvel = y_board, y_angvel = x_board, z_angvel = -z_board

Can you tell me what my basic misunderstanding here is? And possibly a tip how to describe the base_imu_link relative to my robot_base so that robot_localization is happy.

Section 5 of http://wiki.ros.org/razor_imu_9dof was also confusing to me as the SEN 14001 board does not have a short edge.

Edit:
When using the following tf, the odom coordinate system has x towards east, y towards north and z up (ENU). Is this what's needed?

rosrun tf static_transform_publisher 0 -0.105 0 0 3.14 0 robot_base base_imu_link 100