PID tracking wheels?

Ok, quick question. Do yall recommend I do two tracking wheels on each side of the robot in the middle or just use the wheels powered by the motors? I was thinking about wheel slippage and wanted to do something like a free-spinning wheel in the middle with a suspension. Any ideas/do you recommend I do that?

1 Like

I would use two tracking wheels on either side of the robot and one wheel in the back of the robot

1 Like

I would recommend using three tracking wheels. The third tracking wheel is to track the drift of the robot. I wouldn’t use powered wheels as my tracking wheels because of the wheel slippage.


You can do PID with three wheels? I thought that was Odometry?

Odometry is basically tracking algorithm to construct paths and PID is the movement algorithm the robot uses to follow that path


You would use odometry to calculate the position of the robot and PID loops to make it move to a spot on the field. If you are just using your tracking wheels to drive straight you could use only two tracking wheels.

1 Like

It really depends on your situation. If you are trying to use odometry and get a strong programming skills, use the tracking wheels. If you just want an auton for the competition, you might not find tracking wheels necessary (helpful, yes, necessary, probably not).

I think that is the definition of a tracking wheel, so yes…

1 Like

Yea I dont really know how to do Odometry and cant find any good tutorials or any good examples for vexcode c++ so I will just do a PID for turning and going forward, with two wheels. :slight_smile:

There aren’t any tutorials cause a lot of teams see odometry as their ace. You just have to look at real world studies yourself or flesh out all the logistics on your own

Edit: Not as difficult as it sounds

1 Like

Here are some forum posts with some great information on odometry:

Odometry can help you get very precise autonomous but it will require some time to understand and good programming skills.


Ok thanks it just I dont understand that and just need a example or actual tutorial but no one makes any which is kinda sad. I will just have to stick with PID for now which is still good to me :slight_smile:

How would you implement PID’s into odometry code? If I said “go to this point”, how would I implement PID’s into it?

You can use 2 parallel tracking wheels and then inertial sensors, thats what 7K had for tower takeover

U set the error for one side of the chassis as the length of the arc it supposed to be traveling on and just have that side travel that distance

Yes if you are using an omnidirectional drive that would probably be the best solution.

Alright, so to be clear, odometry is simply the act of tracking a robot’s position in the field. It has nothing to do with any motion algorithms. Also, to be clear, you do NOT need odometry if you don’t feel comfortable implementing it.

The OP’s question was whether they could use tracking wheels to minimize wheel slip and improve their linear PID loop. The answer is yes. You don’t need odometry to take advantage of tracking wheels, simply compensating for wheel slip is an improvement.

In terms of a third wheel, you don’t really need it if you aren’t doing odom, though you could still use it to compensate for drift, even with a simple straight-line PID (just take the horizontal drift and use that to slightly rotate the bot to correct for the drift). If your bot does not drift while driving, then there is no point in having a third wheel.

This is not true at all. Odometry is the act of recording the robot’s position while it drives. PID is a linear controller to bring a system to a desired state. This has nothing to do with paths.

7k had a three tracking wheel setup, and did 3 enc odom. They just used the inertial sensor to turn to a global heading as a completely separate function.

This won’t work. The controllers on both sides will output full power and fully saturate the motors, and then one will stop sooner. This will result in a robot that drives straight but then does a little spin at the end.

That is not true. There are plenty of (somewhat advanced) resources online, including the Pilons’ excellent odometry tutorial (give it a read).

However, it is perfectly reasonable to not want to do odom, in which case you can use tracking wheels to minimize slip. However, there are other ways to minimize slip such as controlling the acceleration of the powered wheels.


Are you 100% sure this is what 7K did? im not a programmer so I may have misinterpreted some things, but my team talked to 7K and looked over their code. They have 3 inertial sensors (1 is backup) and 2 parallel traking wheels.

Alright, taking a closer look at their code, it looks like you were right. Btw, having 2 or more IMUs is completely unnecessary, as drift is not predictable or constant so averaging two sensors will have the same amount of drifting (they won’t cancel).

1 Like

If the inertial sensor is accurate enough, couldn’t you use 2 odometry wheels perpendicular to each other?

It’s been considered, but I’m not sure if anyone has tried yet.
The biggest problem is that the IMU refreshes way too slowly, and/or that we don’t know when the IMU updates.

Therefore, with an IMU that only updates around half as fast as the encoders, it means that the arc approximation will be inaccurate if you update the encoders faster than the IMU, and if you slow down the loop you end up with worse odometry.

1 Like