Our robot’s chassis has 3 wheels on each side in a basic tank configuration (minus the treads). I’m trying to find the number of rotations the wheels would have to move to rotate the entire robot a certain angle, assuming both sides spin opposite of each other to do so. I know I could just count the rotations using an encoder by starting the counter and then rotate the robot manually, but I’m asking if there is a way to look for the number using math instead of trials.
I’m sure there’s a simple method to my problem, but I’m having trouble wrapping my head around it.
Each wheel is moving in an arc centered along your chassis rotational axis (affected by wheel type, weight distribution, and wheel location). You just need to calculate the arc length each wheel will move.
My guess is:
r=1/2*track
Θ=90°
assuming your turning center is located midway between your center wheels.
My team uses almost the exact same configuration.
However
We use a Gyroscope for the Rio to measure this sort of thing. There are many different kinds of gyros to buy for the Rio, with varying degrees of difficulty.
I strongly recommend using a gyro (eg, navX) for this. You’ll get MUCH better results with a gyro, and they’re not terribly hard to integrate.
If you really can’t switch to a gyro at this point, you can get the values empirically by logging the encoder counts to smartdashboard and turning your robot as described. If you do the logging in periodic() you can turn manually without even enabling the robot.
Ah, yeah I get it now. It’s just the wheel circumference into the length of the arc, with the degrees desired equal to the arc length over the circumference of the circle between the two center wheels.
As for the gyros, that probably would have been a better idea.
The theory presented here presumes no wheel slip while rotating. It’s good to use this to get a ballpark initial estimate, but in real-life would probably produce somewhat poor quality results (varies depending on robot).
Gyro would seem to be the way to go, in my mind. Directly measure the thing you care about.
I would say your solution would yield an intermediate-quality result. I can’t recall where I saw it, but some teams did use this method to determine the feed-forward portion of rotation calculations.
Run a motion profile that spins the robot in place by turning the wheels a known distance. Do some division to calculate the robot’s “effective trackwidth” from the resulting angular displacement (which you should measure, either with a gyro or otherwise).
The “effective trackwidth” stays pretty reliably constant, in our experience.
we use encoders with a PID. We convert encoders ticks to degrees with a variable that you have to find. Basically, we ask to robot to turn 360 degrees, then calculate the offset. If there was too much rotation, we tune it down a bit, and vice versa. We don’t like the arc method, because it does not consider wheels spinning.