ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

I haven't looked at the bag data, but just a few things I note looking at your data and configuration.

  1. Linear acceleration I'd set them all to false for your IMU. The filter does not have active bias correction, so unless you have a velocity reference (e.g., wheel encoder or visual odometry), the integration of acceleration data will cause your state estimate to start running away rapidly. It'll snap back whenever it gets a GPS measurement, but the state estimate will get progressively worse.
  2. Change your IMU message frame_id to imu_link. Also, what units are your IMU velocities and the static_transform_publisher in? ROS uses radians, and those look suspiciously like degrees.
  3. If your IMU is mounted as you say, then I'd expect this. Keep in mind that tf and tf2 assume that the order is X Y Z yaw pitch roll, though I believe they are applied extrinsically with roll, then pitch, then yaw. Experiment with values here and look at the frame in rviz to confirm.

    <node pkg="tf2_ros" type="static_transform_publisher" name="transform" args="0 0 0 -1.5707963268 0 -1.5707963268  base_link imu_link" />
    
  4. Get rid of the leading slash in your GPS message.
  5. Did you define a base_link->gps transform? You're going to need one, if you gave your GPS message a frame_id. There is a bug at the time of this writing, though, so I suggest making the transform the identity (all zeros) for now.

I haven't looked at the bag data, but just a few things I note looking at your data and configuration.

  1. Linear acceleration acceleration: I'd set them all to false for your IMU. The filter does not have active bias correction, so unless you have a velocity reference (e.g., wheel encoder or visual odometry), the integration of acceleration data will cause your state estimate to start running away rapidly. It'll snap back whenever it gets a GPS measurement, but the state estimate will get progressively worse.
  2. Change your IMU message frame_id to imu_link. Also, what units are your IMU velocities and the static_transform_publisher in? ROS uses radians, and those look suspiciously like degrees.
  3. If your IMU is mounted as you say, then I'd expect this. Keep in mind that tf and tf2 assume that the order is X Y Z yaw pitch roll, though I believe they are applied extrinsically with roll, then pitch, then yaw. Experiment with values here and look at the frame in rviz to confirm.

    <node pkg="tf2_ros" type="static_transform_publisher" name="transform" args="0 0 0 -1.5707963268 0 -1.5707963268  base_link imu_link" />
    
  4. Get rid of the leading slash in your GPS message.
  5. Did you define a base_link->gps transform? You're going to need one, if you gave your GPS message a frame_id. There is a bug at the time of this writing, though, so I suggest making the transform the identity (all zeros) for now.

I haven't looked at the bag data, but just a few things I note looking at your data and configuration.

  1. Linear acceleration: I'd set them all to false for your IMU. The filter does not have active bias correction, so unless you have a velocity reference (e.g., wheel encoder or visual odometry), the integration of acceleration data will cause your state estimate to start running away rapidly. It'll snap back whenever it gets a GPS measurement, but the state estimate will get progressively worse.
  2. Change your IMU message frame_id to imu_link. Also, what units are your IMU velocities and the static_transform_publisher in? ROS uses radians, and those look suspiciously like degrees.
  3. If your IMU is mounted as you say, then I'd expect this. Keep in mind that tf and tf2 assume that the order is X Y Z yaw pitch roll, though I believe they are applied extrinsically with roll, then pitch, then yaw. Experiment with values here and look at the frame in rviz to confirm.

    <node pkg="tf2_ros" type="static_transform_publisher" name="transform" args="0 0 0 -1.5707963268 0 -1.5707963268  base_link imu_link" />
    
  4. Get rid of the leading slash in your GPS message.
  5. Did you define a base_link->gps transform? You're going to need one, if you gave your GPS message a frame_id. There is a bug at the time of this writing, though, so I suggest making the transform the identity (all zeros) for now.now. Also, get rid of the leading slash in your GPS frame ('/gps').