tu-darmstadt-ros-pkg / hector_localization

The hector_localization stack is a collection of packages, that provide the full 6DOF pose of a robot or platform.
83 stars 60 forks source link

Nan tf in message_to_tf #6

Closed ghost closed 10 years ago

ghost commented 10 years ago

I'm using the catkin branch of this repo, on a ROS indigo/Ubuntu trusty system. I'm sending IMU and Odometry information to message_to_tf using the libhector_gazebo_ros_imu and libgazebo_ros_p3d plugins. The base_link -> base_stabilized tf published by message_to_tf switches intermittently between

--
  - 
    header: 
      seq: 0
      stamp: 
        secs: 8
        nsecs: 130000000
      frame_id: base_stabilized
    child_frame_id: base_link
    transform: 
      translation: 
        x: nan
        y: 1.57918518582e-316
        z: 6.95335086244e-310
      rotation: 
        x: -9.66511399003e-05
        y: 0.000187435422708
        z: 1.81158476653e-08
        w: 0.999999977763

---

and

--
  - 
    header: 
      seq: 0
      stamp: 
        secs: 8
        nsecs: 95000000
      frame_id: base_stabilized
    child_frame_id: base_link
    transform: 
      translation: 
        x: 0.0
        y: 0.0
        z: 0.0
      rotation: 
        x: -7.33904804506e-08
        y: 2.31638185891e-08
        z: 1.70000377533e-15
        w: 1.0

---

After some investigation, in the part of imuCallback that creates this transform, the translation is never set. Adding a setOrigin(tf::Vector3(0.0, 0.0, 0.0)) resolves the issue. Does this make sense as a fix?

meyerj commented 10 years ago

Fixed in 6b5c594880b285dc891e8ea4ec4ef4104ea0c6a5.

It was indeed a bug as tf::Transform is not default initialized (other than ROS messages). Additionally, the published pose from an IMU orientation was not initialized correctly if the publish_roll_pitch parameter is set to false.

Thanks for reporting this!

Note that you should not have two input topics to the same message_to_tf node. It would publish the same transforms from different data sources. In the case of libhector_gazebo_ros_imu and libgazebo_ros_p3d the orientation error is calculated differently and message_to_tf would publish slightly different roll/pitch transforms from base_stabilized to base_link depending on the parameter settings.

ghost commented 10 years ago

I see. I was wondering what the slight glitchiness was about. Thanks!