We were wondering if anyone could help us with calculating the travel distance of an x-drive with one wheel rotation. We are using the 3.25’’ omni-wheels with a standard x-drive (all wheels at 45 degree angles).
We know that with a regular tank drive, travel distance for one wheel rotation would just be the wheels circumference, but what about an x-drive?
Knowing the travel distance would greatly help with doing PID during autonomous. Any help would be much appreciated!
Pretend its a + drive rather than an x drive. In this circumstance you go 1 wheel circumference to the right and 1 wheel circumference forward. The right triangle created has a hypotenuse of length sqrt(2).
Now just change your viewpoint.
The square root of two only applies if you are really going on the heading of the robot front or side. That assumes no rotation as well.
At some point you would need to get to either the generalized equations of motion that include rotation. Using just this will require two movements to get to some other place on the field not directly aligned with your robot’s front or side. 81M did this in sack attack but they spent too much time on this versus an effective scoop.
Another way to look at it is to measure off the actual wheels tangent/natural direction and set targets based upon a coordinate system that is 45 degrees offset. Also ensure rotation is kept at near zero from what the gyro tells you. Otherwise your path of travel has to include the arc length of the rotation and then you factor in the translation of the wheels.
So if you do measure off the actual wheel turns in their coordinate system you can go any arbitrary direction. The downside is that you will be running on two drive wheels for the longer vector length. This generally should be shorter and more efficient than driving forward some distance and then left/right for the next distance. The downside is when you are trying to go 45 degrees from where you are as the one set of wheels will not run.
Many optimizations can be applied to this too in order to minimize time and maximize wheel turning. But it may require a spin at the beginning and end.
We used this strategy for our Toss Up programming; although it was skewed by crossing the bump (and consequently we mostly abandoned it) it worked just fine otherwise. You can actually turn without messing things up too much, even with only two encoders; however it dies throw the grid off, so you can’t rely on that to help you; it works best only when paired with a rerun-style program, or by simply reading encoder ticks off an LCD as coordinates.
Aside from torque concerns, there’s actually no disadvantage in driving on a diagonal, using only two wheels; it’s just as fast as driving straight and then strafing. However, I assume you mean that you could just turn into the diagonal and get the full 1.4x speed bonus that way, which is, of course, better.
Treat all movement as vectors. While I know that for going straight ahead you merely need to multiply by the square root of 2 (1.414…), and that for a perfect diagonal it is multiplied times 1, I do not know how to calculate for angles in between those.
This is where 2 dimensional physics begins to be both applicable and really REALLY helpful.
As long as there is no turning you are golden. You can treat one set of wheels as the X and one set of wheels as the Y coordinates and power each with their own PID. Works brilliantly - until you get a bit of turn.
You will see the robot move in an arc as it hones in on the X and Y values separately. Just reset what you think of X and Y each time. Field centric coordinate systems require some translation.