Verify orientation of IMU/odometry for robots (ros ticket #3364)

[ahendrix]

The IMU position has moved for the Beta robots. The location is specified in the URDF, but the orientation is unknown. We need to check the orientation of the IMU against against the expected orientation for the odometry system.

PRH may not have the correct orientation, the others do.

trac data:

• Owner: wim
• Reporter: watts
• Reported at: Wed Dec 23 11:59:11 2009
• URL: https://code.ros.org/trac/wg-ros-pkg/ticket/3364

[ahendrix]

[sachinc] The wheel odometry itself does not do anything with the IMU. That happens in robot_pose_ekf. One solution would be to use the accelerometer for an initial calibration of orientation under the assumption that we are on level ground. The other might be to rotate in place slowly and calibrate based on expecting minimal roll and pitch velocities?

[ahendrix]

[sachinc] It turns out the IMU was pitched 180 degrees about the Y axis. I fixed the relevant transform in the urdf.

r29354

[ahendrix]

[wim] The imu should have been mounted the same on alpha and beta robots. The last time I talked to function this was still the case. Did something change, or was the beta urdf not the same as the alpha urdf?

[ahendrix]

[sachinc] The imus are mounted on the same on both robots. However, the specification of the IMU axes was wrong in the urdf.

The X axis of the IMU points backwards, the Y axis to the left of the robot, the Z axis downwards. This was confirmed in two ways:

(a) driving the robot around and looking at the IMU message (b) checking the documentation (which is now attached to this ticket).

[ahendrix]

[wim] Thanks for checking this. We should verify the urdf for alpha robots, it might be wrong too.

[ahendrix]

[hsu] r29365

[ahendrix]

[wim] Thanks!

[ahendrix]

[hsu] r29367 for alpha robots in pr2_defs, please test on hardware

[ahendrix]

[wim] The robot pose ekf is still assuming the original orientation, resulting in the robot driving around upside down. We might have to revert this change temporary.

[ahendrix]

[wim] Before we can roll out this urdf change, this ticket needs to get fixed:

https://code.ros.org/trac/ros-pkg/ticket/3688

[ahendrix]

[wim] Strange things are going on here... How sure are we that the imu has its z axis down? I'm puzzled why the robot pose ekf ever worked because afaik sim had the imu defined with z axis up. We should investigate the hw and sim settings in more detail. John, how is the sim imu currently configured?

[ahendrix]

[hsu] sim imu should be the same as hw. that doesn't say much, the 2dnav_gazebo tests have been failing for a while now.

[ahendrix]

[hsu] just verified independently between Sachin and I that hw imu does have z-downwards and x-backwards.

On the hardware, Sachin and I just verified that odom_combined frame behaves correctly for both old and new urdf before and after r29367. So this is reassuring. torso_lift_imu/data contains frame_id="imu".

In simulation, imu message contains simulated imu pose in the inertial "world" frame (z-up,x-forward). Flipping the imu_link frame downwards does not affect torso_lift_imu/data message (pending fix in #3415). Simulation fills in "/map" as frame_id for torso_lift_imu/data. But odom_combined frame appears to be reversed when imu is z-up and 'imu_link' is z-down.

Wim,

is robot_pose_ekf transforming data in torso_lift_imu/data based on imu_link's orientation? it appears to ignore frame_id inside the message for now. am I mistaken?

John

[ahendrix]

[hsu] closing this ticket, we should move additional discussions over to #3688.

[ahendrix]

[hsu] [https://code.ros.org/trac/ros-pkg/ticket/3688 #3688]