Correct tf-order for odom frame in cartographer

asked 2019-12-16 10:30:37 -0500

BATillmanOtt gravatar image

Hi,

I am currently trying to improve the accuracy of the cartographer_ros by adding an odometry. However, the first result was not very satisfying as the cartographer automatically places the origin of the odom frame directly into the origin of the base_link frame. My first attempt was to create the odom-frame in the robot model and link it to the base_link with the correct frame offset:

image description image description

<robot name="broetje_Prototype_AGV">

  <material name="gray">
    <color rgba="0.7 0.7 0.7 0.5" />
  </material>
  <material name="red">
    <color rgba="1.0 0.0 0.0 1.0" />
  </material>
  <material name="yellow">
    <color rgba="1.0 0.73 0.0 0.5" />
  </material>

  <!--LINK: Map-->
  <!--link name="map">
    <visual>
      <origin rpy="0 0 0" xyz="0 0 0"/>
    </visual>
  </link-->
  <!--JOINT: Odometry-->
  <!--joint name="map_to_odom" type="fixed">
    <parent link="map" />
    <child link="odom" />
    <origin rpy="0 0 0" xyz="0.5 -0.3 0"/>
  </joint-->

  <!--LINK: Odometry-->
  <!--link name="odom">
    <visual>
      <origin rpy="0 0 0" xyz="0 0 0"/>
    </visual>
  </link-->
  <!--JOINT: Base-->
  <!--joint name="odom_to_base" type="fixed">
    <parent link="odom" />
    <child link="base_link" />
    <origin rpy="0 0 0" xyz="-0.5 0.3 0"/>
  </joint-->

  <!--LINK: Base-->
  <link name="base_link">
    <visual>
      <geometry>
        <mesh filename="package://cartographer_ros/meshes/Cobot2019_origin.dae"/>
        <!--box size="1 0.6 0.45"/-->
      </geometry>
      <origin rpy="0 0 0" xyz="0.5 -0.3 0"/>
      <material name="red"/>
    </visual>
  </link>
  <!--JOINT: Safety Scanner 1-->
  <joint name="base_to_scan_1" type="fixed">
    <parent link="base_link" />
    <child link="scan_1" />
    <origin rpy="3.1416 0 2.3561925" xyz="0.055 -0.055 0.18"/>
  </joint>
  <!--JOINT: Safety Scanner 2-->
  <joint name="base_to_scan_2" type="fixed">
    <parent link="base_link" />
    <child link="scan_2" />
    <origin rpy="3.1416 0 -0.7853975" xyz="0.956 -0.556 0.18"/>
  </joint>
  <!--JOINT: Odometry-->
  <joint name="base_to_odom" type="fixed">
    <parent link="base_link" />
    <child link="odom" />
    <origin rpy="0 0 0" xyz="0.5 -0.3 0"/>
  </joint>

  <!--LINK: Safety Scanner 1-->
  <link name="scan_1">
    <visual>
      <geometry>
        <mesh filename="package://cartographer_ros/meshes/sick_scanner_origin.dae"/>
      </geometry>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <material name="yellow"/>
    </visual>
  </link>

  <!--LINK: Safety Scanner 2-->
  <link name="scan_2">
    <visual>
      <geometry>  
        <mesh filename="package://cartographer_ros/meshes/sick_scanner_origin.dae"/>
      </geometry>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <material name="yellow"/>
    </visual>
  </link>

    <!--LINK: Odometry-->
  <link name="odom">
    <visual>
      <origin rpy="0 0 0" xyz="0.5 -0.3 0"/>
    </visual>
  </link>

</robot>

If I proceed as displayed above, base_link or odom starts jumping around while rotating ... (more)

edit retag flag offensive close merge delete

Comments

I'm not into mobile bases (or navigation), but I do know that odom is not a frame that you put in your robot's model (ie: urdf), but it something produced by localisation packages.

You may want to take a look at REP 105: Coordinate Frames for Mobile Platforms for a general overview.

Perhaps another visitor of this forum can provide a more helpful answer.

gvdhoorn gravatar image gvdhoorn  ( 2019-12-16 11:01:16 -0500 )edit

Its OK for odom to start the center of the robot on startup. The odom frame is pretty arbitrary and doesn't matter where it is specifically. The point of the odom -> robot transform is to give you a completely smooth, non-cusping, non-jumping relative motion estimation. This is useful if you want instanteous ground speed or acceleration or to compute distance travelled in a local time horizon.

The reason SLAM / localization makes the map->odom is to correct the fact that the odom->robot transform will naturally drift if you don't correct it to be able to be smooth.

stevemacenski gravatar image stevemacenski  ( 2019-12-16 12:18:08 -0500 )edit

I calculate the odometry for the middle of the vehicle, because the vehicle rotates around this point. If the odometry frame is at the coordinate origin of the vehicle, the representation of the vehicle rotates around this point and not around the centre of the vehicle. So I assume that i have to define the correct position for the odometry in my urdf file.

BATillmanOtt gravatar image BATillmanOtt  ( 2019-12-17 02:39:56 -0500 )edit

No, that's not how this works.

The odom frame is just a TF frame you publish/broadcast. It doesn't (and shouldn't) be part of the URDF and shouldn't be part of your robot model. It's a frame external to your robot. See also REP 105.

I calculate the odometry for the middle of the vehicle, because the vehicle rotates around this point.

I've often seen base_link placed at the centre of rotation for mobile robots.

Also:

  <link name="odom">
    <visual>
      <origin rpy="0 0 0" xyz="0.5 -0.3 0"/>
    </visual>
  </link>

This doesn't really do what I believe you think it does.

The origin there changes the origin of the visual element, not of the link with the name odom. That is probably not what you wanted to do.

gvdhoorn gravatar image gvdhoorn  ( 2019-12-17 02:43:14 -0500 )edit

Thank you very much for your explanation, it really helped. If odometry behaves the way you describe it, I would have to place my base_link in the center of rotation of the vehicle. Currently it is always in the middle of the vehicle, but I plan to make it variable. That would be hard to achieve. There must be a possibility to specify a point for the odometry (similar to an IMU or the laser scanners)...

BATillmanOtt gravatar image BATillmanOtt  ( 2019-12-17 04:28:43 -0500 )edit

That shouldn’t be difficult, rigid body transformations and all...

stevemacenski gravatar image stevemacenski  ( 2019-12-17 11:01:24 -0500 )edit