Odometry on an Non X Drive Chassis

Does anyone out there have Odemetry Code I can look at that is not for an X Drive? Preferably If the code is in VexCode V5 Pro, RobotC, or Robotmesh. So I can read it easier. I am doing research for next year, I want to know how to make an Odemetry Code on Non-X Drive Chassis. Help would be appreciated.

This is a good resource for odometry.

I’d look around using the search function on the forums there are lots of posts about odometry, pid, pure pursuit, etc.

Odometry calculations are independent of the type of chassis. You use 3 (or 2 + gyro) tracking wheels and do math with their sensor values. The type of chassis just determines what motion algorithms you can write with odometry


odometry is merely the method used to obtain data, specifically, coordinates and angle of a robot. The method used to get this data will work for any type of drive.

however, with a tank drive, you might be able to get away with a simpler setup.

on a holonomic drive, you need to account for the fact that your robot can move side to side, which is the purpose of the perpendicular tracking wheel. However, an all omni tank drive cannot drive sideways, but it can still drift, which I think should be significant enough to need accounting for. But if you use a setup with traction middle wheels, you might be able to get away with not using a perpendicular tracking wheel, because theoretically, the robot won’t be moving side to side at all. I’m not sure how much this works out in reality, but theoretically it should work. I could see some error building up through small amounts of drift though so it might be best to include the perpendicular wheel if you can.

But as for the parallels wheels, you really only need 2 if you’re using them to gain the heading (angle) of the robot, back when pilons developed this technique, the only other way to track a robot’s rotation were the old gyroscope sensors, which I’ve heard were pretty drifty and unreliable. But now we have inertial sensors, which are pretty good. They can be used in place of the second parallel tracking wheel, which means you only need 1 parallel tracking wheel to measure forward displacement. Be mindful that this wheel does need to be inline with the center of the bot, otherwise turning will cause this wheel to be driven and confuse the robot into thinking it’s moving forwards or backwards.

But yeah, odom is essentially the same on a holonomic vs non holonomic drive, the only difference is what you do with the data it gives you.


Not necessarily, you can account for it not being centered with a little bit of math. This is shown by this equation from the pilons document


You can get deltaTheta from the inertial sensor and deltaR from the one tracking wheel. Then you just need to add the offset amount (s_R) to the radius of the tracking wheel’s arc. This will then use the center of the robot as the tracking center instead of the wheel position.

Even if you didn’t add the offset, the position tracking system would still work. It would just track using the wheel’s position as the tracking center instead of the robot’s center.


ah interesting I didn’t realize you could do that. Good thing to know.

1 Like

This is all good information. This really helps. The just one more thing, that is incorporating Odometry and PID together. How do you do that. It would also help to see some code that . Send me an message any code you have on Odometry with PID, in them so I can see how its constructed.

From one programmer to another.

If your odometry works, your robot knows where it is on the field. In auton, you know where you want your robot to be. With this information, you can find your error from the target position, but instead of just using encoder measurements, you’d use your odometry calculations to measure relative error and detect changes (like your bot getting pushed, etc). Feed that into your PID.

As a side note, you seem to be hinting very strongly that you want someone to send you working code. A few things about that:

  • People here aren’t gonna do that. If you show us the code you’re using and tell us why it doesn’t work, people will help you debug it. But without code, the best way to help you is by making sure you understand the concepts behind these algorithms. If you understand them, you shouldn’t have too much trouble implementing them.
  • If you are dead set on finding code for these algorithms, it already exists in many places. I would advise against copying other people’s code though, because everyone implememts things differently based on their robot and their needs. If you use that code without understanding why it works, you will not be able to adapt it to your own robot.