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.
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…
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.
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
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
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).
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.
Not necessarily. I was thinking that if you were to calibrate each of two inertial sensors at separate times, you could get much more precise results using a Kalman filter or something similar.
I’m not sure that would work how you’re wanting it to. I spent a while last summer doing a research project with the Kalman Filter For Sensor Fusion which is based off of the generic Kalman Filter but specifically for implementation on gyro, accelerometer (not the linear acceleration kind in the VEX Inertial Sensor), and magnetometer IMU’s for drones. A lot of the reason the Kalman Filter is extremely adept at compensating for gyroscope drift and accelerometer/magnetometer noise is because the output from the gyroscope and acc/mag differ in properties quite a bit. The Kalman Filter uses the assumptions of the gyroscope reading being a true value with some random-walk drift and some Gaussian noise along with a different set of statistical assumptions for the accelerometer. Therefore, if what you were meaning is to perform sensor fusion using two of the VEX IMU sensors, I’m not sure the Kalman Filter is the way to go, seeing as the statistical properties of the readings from each sensor would really be the same.
That being said, I also don’t immediately agree with the fact that using 2 sensors will have no improvement on the drift/variance of the sensor readings. In the case of the drift, both sensors will drift with random magnitude in random directions as gyroscopes are known to do, and I’m not sure that much can be done with two sensors carrying similar properties. However, in the case of the noise or variance, the end error depends on how we combine the readings from the individual sensors. Assuming we simply average them, then yes, the variances will also add and the readings will overall be worse. However, if there exists some sort of combination method that could take advantage of the square root of the reading, then, following error analysis equations, the variance would actually decrease. I can’t think of anything right off the bat that would satisfy what you need there, but I also cannot say that it is not possible. It would require some in depth analysis but I think it may be possible.
Yes. I did this, and it works great.