Hi,
I am working on writing autonomous code that is accurate. I currently use PID, and use wall checks for the programing skills autonomous, but I can’t seem to get it consistent enough. I have heard that tracking wheals can help, but i s this the next step? My team could modify the bot the fit tracking wheels in. If we do, how many and at what angles should we put them? We are using an xdrive. Thanks in advance.
Yes, tracking wheels would be the next step. However, coding odometry and building thr tracking wheels are not easy tasks. If you choose to do this expect it to take a solid 2-4 weeks
Also, you would generally use three wheels: center left (straight forward), center right (straight forward), and center back (perpendicular to the other two). Also, they must all be equidistant from the center of your robot.
Actually, tracking wheels do not have to be equidistant from the tracking center; people just tend to do this because it looks cleaner. (Think about it, the tracking center can just be transposed to the desired center of the robot in code)
All that matters is that two are parallel and two are perpendicular.
???
One sideways one and 2 forward facing ones. Also remember atan2 is (x,y) in c++. Which is useful for rotating by the average of 2 values(I forgot which ones)
Also I highly recommend this topic for figuring out the speed the wheels need to go at.
Than using PID based off the distance from the target.
One sideways and 2 forward facing matches @2775Josh’s description. The forward facing ones are parallel to each other and forward / sideway facing ones are perpendicular to each other.
Having sensors that are parallel (dist, dAngle) and perpendicular (dSide) is the basis for making odom work. It is just that your setup is the most efficient way to achieve the above criteria
One thing you could also try is just programming the motor revs directly in the code. Sometimes wall checks work and are easy, but if they don’t work, I find it beneficial to directly plug in the revs with a function and after a (long) while, you can get a super consistent auton. But that’s just me. Some people hate doing that. But I think its still easier than doing tracking wheels.
If I have tracking wheels, do I need to use odometry to increase accuracy? Can I just swap out the motor encoder values for the tracking wheel values to have accuracy increase?
Just swapping the motor encoders for tracking wheels would be an increase in accuracy, but odometry would be better.
It’s not necessary, but highly recommended.
@Pat.Chet.02 is absolutely right.
This is better than nothing, but tracking wheels is far better. This is because the wheels on the motor have friction, meaning they will not spin nearly as freely. This may result in not fully rotating, and the encoder value coming up short. In the other direction, the motor may spin and not actually move the robot, meaning that the encoder value will still increase without the position changing.
The increase in accuracy from the tracking wheel comes from the lack of wheel slippage. Not an increase in resolution. In some cases, it might make more sense to use the IME than the quad encoder for the odometry data –– for example, if you know the robot will be in a no slipcase (or can ensure it), than you can get higher resolution data from the IMEs and thus be more “accurate”.
Friction isn’t a term I’d use for the cause of slippage. Rather, the motor is providing a torque against the friction from the ground which can lead to slippage if the static friction is overcome. If you manage the torque output/speed of the wheels, you can do odometry accurately and without seperate tracking wheels. There’s actually a way to detect wheel slippage and factor it into the position tracking but you’d need to individually power each wheel.
Yes, that is what I mean. I apologize for the misuse, I’m “functioning” on very little sleep right now lol.
The benefit of using odometry is that you can turn and move at the same time. Although I would HIGHLY recommend using the 2 parallel tracking wheels to track the angle since it’s extremely simple to do and is better than any other options.
For doing turning PID you should just take the angle and then do it from there
And with the Movement PID you should just track one of the wheels for a directions.
Ie moveTo(5, 3); Use the side to side wheel to handle the x PID and the average of the fwd/rev tracking wheels for the y value.
I consider things like odometry and more complex movement algorithms should be done in over breaks or early in season or if you have a good full time programmer. It can be quite fiddly to work with but once you have it finished it will be extremely helpful and 10x more consistent.