Odometry is the use of data from motion sensors to estimate change in position over time.


You might want to consult Reference Frame.

In F1TENTH and basically ROS in general, the odometry (/odom topic) specifies the position of base_link frame relative to odom frame (the global coordinate frame)

The coordinate frame calledĀ odomĀ is a world-fixed frame. The pose of a mobile platform in theĀ odomĀ frame can drift over time, without any bounds. This drift makes theĀ odomĀ frame useless as a long-term global reference. However, the pose of a robot in theĀ odomĀ frame is guaranteed to be continuous, meaning that the pose of a mobile platform in theĀ odomĀ frame always evolves in a smooth way, without discrete jumps.

In a typical setup theĀ odomĀ frame is computed based on an odometry source, such as wheel odometry, visual odometry or an inertial measurement unit.

TheĀ odomĀ frame is useful as an accurate, short-term local reference, but drift makes it a poor frame for long-term reference.

AHA Moment

So the dead recknoning stuff directly publishes to /odom. What happens you you use slam_toolbox or like a particle filter is not that they overwrite to the /odom topic. Rather, they update the tf2 tree between the map and base_link. This is why when you open up Rviz, the laser scans seem to snap back, because the transforms are constantly updated.

Check out this article, which has some useful information.

In a world when there is no odometry drift, you would only need to publish a transform once between odom frame and map frame.

It is important to note that the odom frame is a local frame of reference and its position and orientation estimates are subject to drift over time due to errors in sensor measurements and the accumulation of noise in the odometry estimate.

For this reason, SLAM algorithms are often used to correct for the drift and obtain a more accurate estimate of the robotā€™s position and orientation in a global reference frame such as the map frame.


    sec: 1681316339
    nanosec: 427119036
  frame_id: odom
child_frame_id: base_link
      x: 7.3203229904174805
      y: 7.190346717834473
      z: 0.4300275146961212
      x: 0.02042497508227825
      y: -0.003127265488728881
      z: 0.9927870631217957
      w: 0.11809687316417694
  covariance: '<array type: double[36]>'
      x: 0.0
      y: 0.0
      z: 0.0
      x: 0.0
      y: 0.0
      z: 0.0
  covariance: '<array type: double[36]>'

Odometry is SUPER important to get right. Else, you will end up with these really bad estimates of the positions, whether you are trying to run SLAM or Localization.

#gap-in-knowledge How does F1TENTH implement odometry? Itā€™s not differential drive, they use some sort of Single Track Model?

At work, I had the Create3 publishing bad odometry information. Everything seemed inverted.

Differential Drive Odometry

For a Differential Drive, these are the equations that it boils down to for how we derive our positions:

d_{center}&={\frac{d_{left} + d_{right}}{2}}\\ [3pt] \phi&={\frac{d_{right}-d_{left}}{d_{baseline}}}\\ [3pt] \theta'&={\theta +\phi}\\ [3pt] x'&= x + d_{center}\cos(\theta)\\ [3pt] y'&= y + d_{center}\sin(\theta)\\ [3pt] \end{aligned}$$ Resources - [Odometry Tutorial](https://ocw.mit.edu/courses/6-186-mobile-autonomous-systems-laboratory-january-iap-2005/resources/odomtutorial/) by MIT - ROS1 custom odometry [code](https://automaticaddison.com/how-to-publish-wheel-odometry-information-over-ros/)