Odometry

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

Concepts

• Dead Reckoning
• Visual Odometry

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)

• When you first start up the robot, the base_link frame and the odom frame are in the same position. As the robot moves, the base_link frame moves
• The implementation of the Transformation can be found in vesc_to_odom.cpp: https://github.com/f1tenth/vesc/blob/ros2/vesc_ackermann/src/vesc_to_odom.cpp

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.

Example

header:
  stamp:
    sec: 1681316339
    nanosec: 427119036
  frame_id: odom
child_frame_id: base_link
pose:
  pose:
    position:
      x: 7.3203229904174805
      y: 7.190346717834473
      z: 0.4300275146961212
    orientation:
      x: 0.02042497508227825
      y: -0.003127265488728881
      z: 0.9927870631217957
      w: 0.11809687316417694
  covariance: '<array type: double[36]>'
twist:
  twist:
    linear:
      x: 0.0
      y: 0.0
      z: 0.0
    angular:
      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/)