# Correct tf-order for odom frame in cartographer

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:

<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>

<visual>
<origin rpy="0 0 0" xyz="0 0 0"/>
</visual>
<!--JOINT: Odometry-->
<!--joint name="map_to_odom" type="fixed">
<origin rpy="0 0 0" xyz="0.5 -0.3 0"/>
</joint-->

<visual>
<origin rpy="0 0 0" xyz="0 0 0"/>
</visual>
<!--JOINT: Base-->
<!--joint name="odom_to_base" type="fixed">
<origin rpy="0 0 0" xyz="-0.5 0.3 0"/>
</joint-->

<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>
<!--JOINT: Safety Scanner 1-->
<joint name="base_to_scan_1" type="fixed">
<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">
<origin rpy="3.1416 0 -0.7853975" xyz="0.956 -0.556 0.18"/>
</joint>
<!--JOINT: Odometry-->
<joint name="base_to_odom" type="fixed">
<origin rpy="0 0 0" xyz="0.5 -0.3 0"/>
</joint>

<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>

<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>

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

</robot>


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

edit retag close merge delete

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.

( 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.

( 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.

( 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>


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.

( 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)...

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

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

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