Omni Wheel Drive Train and Auto Mode

[mikets]

Sorry looks like post #24 has more detail analysis.

[mikets]

Mikets,

I'd be very interested to know what results you got for the measurements with your mechanum wheels. I don't have any experience with them, but with the rollers mounted at 45 degrees to the plane of the wheel (as opposed to 90 degrees for the Omni), I'd suspect different results. I would have guessed that forward robot motion equals wheel distance for either y-direction or x-direction robot motion. What did you find?

My finding was on post #28 on this thread. The y direction is a just like normal wheels. But x distance is smaller than wheel distance with a percentage that doesn't look like related to dart of 2.

[jkenney]

Mikets,

I'd be very interested to know what results you got for the measurements with your mechanum wheels. I don't have any experience with them, but with the rollers mounted at 45 degrees to the plane of the wheel (as opposed to 90 degrees for the Omni), I'd suspect different results. I would have guessed that forward robot motion equals wheel distance for either y-direction or x-direction robot motion. What did you find?

[jkenney]

We did some additional testing of our odometry code for our robot (with the four Omni Wheels). The odometry code computes X, Y, and Rotational robot motion based on encoder counts, and converts this to changes in field coordinates. It assumes that the Robot Forward Motion will exceed the Wheel Distance by a factor of sqrt(2) for X and Y modes. We compared the Forward Robot Motion predicted by the odometry code (for pure Y motion and pure X motion) with actual forward robot motion measured with a tape measure. We did find that the forward robot motion is greater than wheel distance, but not quite by sqrt(2). It fell short of this prediction by about 11-12 %. So, instead of a factor of 1.41, we got a factor of about 1.25. This was true for both X-mode and Y-mode motion.

I attribute the 11-12% distance loss to wheel skidding. This could be adjusted for by inserting a "fudge factor" of 0.89 into the odometry equations for X motion and Y motion. That should work for pure X motion or pure Y motion, but I think it would be a problem for diagonal motion.
For example, diagonal motion using an X mode component of +1 and a Y mode component of +1 would result in wheels 2 and 4 rotating at the same positive speed, and wheels 1 and 3 not rotating at all (just drifting with their rollers). In that setting I suspect there would be very little skidding of wheels 2 and 4 (because they aren't being forced to drift at all), so the fudge factor needed for pure X or pure Y motion wouldn't work for diagonal motion. Haven't had a chance to test this with measurements.

We also compared the odometry code with MR gyro readings in the Rotation mode and found agreement within about 3 %.

[mikets]

I believe that the Robot Forward Motion is actually greater than the Wheel Distance by a factor of sqrt(2), rather than smaller. A Wheel Distance of 1 cm must be offset by a perpendicular Lateral Wheel Shift of 1 cm. These components of motion form the sides of a right triangle whose hypotenuse is the Robot Forward Motion. I did some measurements from this YouTube video (not mine): https://www.youtube.com/watch?v=5vJCucpVdX0, and they support this conclusion. Measurements were done at 4 sec, with wheel diameter taken as average of foreground and background wheel, distance between opposing wheels measured from right to left, and distance between adjacent wheels calculated as opposing/sqrt(2). At 16 sec, the robot crosses perpendicular over a seam in the carpet, and the amount of wheel rotation required for the crossing can be determined. I wish I could back this up (or refute it) with measurements from our own robot, but I've realized our initial measurements were flawed, and I don't currently have access to the robot to repeat them.

I would be very interested in the measurement of your robot. I would want to refute it with our measurement but our robot is using mecanum wheels so it wouldn't be an equivalent comparison to an Omni-wheel robot in diamond formation. I would be surprise if "robot forward motion" is really greater than "wheel distance". Please do let us know what you find. The way we measured ours is to run the robot for a fixed amount of time (e.g. 5 seconds) in a given direction with low power to make sure wheels don't slip (i.e. without free wheeling). All encoders will be reset before the run. At the end of the run, use a tape measure to measure the actual distance traveled (i.e. robot forward motion) and then the program will also print out the readings of all four encoders. If the readings of all four encoders are approx. equivalent, you would conclude there was no major wheel slipping. Then you can use one encoder reading (or the average of all four), the wheel diameter and gear ratio etc to calculate the "wheel distance". Then compare the "wheel distance" with the measured distance (i.e. robot forward motion). I would expect wheel distance is greater than the measured distance.

[jkenney]

OmniWheel Robot Odometry

A team I work with is using 4 OmniWheels, each at one corner, mounted at a 45 degree angle to the robot's sides. I'll use the following terminology. "Wheel Distance" is the distance that would be traveled by the wheel due to rotation around its drive axis, if it were not constrained by opposing forces from the other wheels. "Lateral Wheel Shift" is motion of the wheel due to rotation of the rollers, and is perpendicular to "Wheel Distance". "Robot Forward Motion" is the actual forward motion of the robot.

I believe that the Robot Forward Motion is actually greater than the Wheel Distance by a factor of sqrt(2), rather than smaller. A Wheel Distance of 1 cm must be offset by a perpendicular Lateral Wheel Shift of 1 cm. These components of motion form the sides of a right triangle whose hypotenuse is the Robot Forward Motion. I did some measurements from this YouTube video (not mine): https://www.youtube.com/watch?v=5vJCucpVdX0, and they support this conclusion. Measurements were done at 4 sec, with wheel diameter taken as average of foreground and background wheel, distance between opposing wheels measured from right to left, and distance between adjacent wheels calculated as opposing/sqrt(2). At 16 sec, the robot crosses perpendicular over a seam in the carpet, and the amount of wheel rotation required for the crossing can be determined. I wish I could back this up (or refute it) with measurements from our own robot, but I've realized our initial measurements were flawed, and I don't currently have access to the robot to repeat them.

Our robot configuration is (sorry about the ugly typographic diagram):
______Y________
__2_______3____

______________X

__1_______4___

We've defined the forward direction for each wheel as the direction that results in positive-Y (ie, forward) motion of the robot. We've defined three useful modes of operation:

X-mode: 1 cm of X-travel of robot requires (1-4) Wheel Distances of: -1/sqrt(2), +1/sqrt(2), -1/sqrt(2), +1/sqrt(2)
Y-mode: 1 cm of Y-travel of robot requires (1-4) Wheel Distances of: +1/sqrt(2), +1/sqrt(2), +1/sqrt(2), +1/sqrt(2)
Rotation mode: 1 radian of C-Cl robot rotation requires Wheel Distances of: -R, -R, +R, +R (where R is distance from robot center to wheel center)

In order to describe all possible combinations of wheel motion, a fourth (not useful) mode can be defined. We call it the Fail mode:

Fail mode: Wheel Distances of +1, -1, -1, +1 (would result in skidding of all four wheels with no net robot motion)

Any desired combination of incremental robot travel (X, Y, Rotation, Fail) can be obtained as a linear combination of Wheel Distances, as follows:

W = M.multiplied(Q)

where W is a vector containing the incremental Wheel Distances for wheels 1-4, Q is a vector containing incremental robot mode activity (X distance, Y distance, rotation in radians, and Fail activity), and M a matrix containing the following rows:

-1/sqrt(2), +1/sqrt(2), -R, +1
+1/sqrt(2), +1/sqrt(2), -R, -1
-1/sqrt(2), +1/sqrt(2), +R, -1
+1/sqrt(2), +1/sqrt(2), +R, +1

This matrix is invertible. So, if the incremental (1-4) wheel distances (W) are determined using encoders, the resulting incremental robot motion (X,Y,Rotation,Fail) can be determined as:

Q = M.inverted().multiplied(W)

Some additional calculation is then needed to go from incremental motion in robot coordinates to incremental motion in field coordinates.

[mikets]

Yeah, I didn't realize our difference in terminology until what you described was opposite to my expectation. That's a long paper you linked to. I probably don't have time to read the entire thing but I am interested in what it may contain. In particular, some years ago, I was set out to research how to do autonomous strafing. Autonomous requires close-loop control. It means I need to have sensors to determine how far I have strafed. I need to determine how to combine the four encoders of the four wheels into a net x and y telemetry. Y is simple, it is just like normal wheel where I average all four encoders:

yEnc = (lfEnc + rfEnc + lrEnc + rrEnc)/4;

For x, I have derived:

[COLOR=#808080][I]xEnc = ((lfEnc + rrEnc) - (rfEnc + lrEnc))/4[/I][/COLOR]

However, both x and y are in the units of encoder counts. I want to scale it to physical inches. Again, y is simple. Like I said, you take the wheel diameter multiply by PI and the gear ratio and divide by the ENCODER_COUNTS_PER_REVOLULATION and you get the INCHES_PER_ENCODER_COUNT for y. But how do you get INCHES_PER_ENCODER_COUNT for x? I couldn't figure it out, so I cheated. I determined this scale by measuring it empirically. It worked.
For example, on our robot this year, the scale factors are:

[COLOR=#000080][B]public static final double [/B][/COLOR][COLOR=#660e7a][B][I]ENCODER_X_INCHES_PER_COUNT       [/I][/B][/COLOR]= [COLOR=#0000ff]0.0132166817227156[/COLOR];[COLOR=#000080][B]public static final double [/B][/COLOR][COLOR=#660e7a][B][I]ENOCDER_Y_INCHES_PER_COUNT       [/I][/B][/COLOR]= [COLOR=#0000ff]0.01667[/COLOR];

I was curious what is the relationship between these two numbers. Since the rollers are 45-degree from the wheel's rotation axis, I would think it should somehow relate to square root of 2 but it's not. I still haven't figured that out yet. I wonder if the paper contains hints with regard to this.

[Philbot]

For either robot to move forward, I thought both the left and right wheels need to drive in the SAME direction?! In fact, all wheels should drive in the SAME direction for the robot to go forward/backward.

It's fun seeing how all out terminology is different based on our own experiences.
For you (and probably everyone else), "Diamond" is wheels on robot corners, and for me "diamond" seemed like it should mean wheels in the mid points of the sides (forming a diamond)...
That explains it. I stand corrected.

I'm still very surprised about your measured "no slippage" data from driving forward.
I had done some research to get a verification of my experience and found this paper:

http://www.academia.edu/1079875/Practical_Applications_for_Mobile_Robots_based_on_Mecanum_Wheels-a_Systematic_Survey

The top of page 115 defines the effect that I was explaining, and one of the remedies that I mentioned (roller locks).
So I thought I was golden....

But.... on re-inspection.. The losses due to the roller rotation is described as "loss of kinetic energy".

Now, I'm wondering how you can have loss of kinetic energy, without having loss of forward motion.
Light Bulb... Ff you go the same distance with less speed, that's a loss of kinetic energy.

So I guess that's what's happening.
1) The roller are spinning (my free wheel), so the robot is losing some forward velocity, therefore kinetic energy is being lost.
2) But: The same distance is being traveled (your "no slippage") so odometry is correct.

Wow... that's very interesting.
Who says you can't teach an old dog (me) new tricks.

Phil.

[mikets]

So for either robot to move forward, the left and right wheels need to drive in opposing directions and the each wheel's rollers will freewheel the same amount.

For either robot to move forward, I thought both the left and right wheels need to drive in the SAME direction?! In fact, all wheels should drive in the SAME direction for the robot to go forward/backward.

[mikets]

Hmm, we may have different terminologies here too. From your description, I was assuming your robot has the Omni wheels in a diamond formation. They mounted at the same locations of the robot as mecanum wheels (i.e. front left, rear left, front right, rear right) but they are turned 45-degree. It's a diamond because the square that the wheels formed is a diamond in relation to the square formed by the robot frame.

Sorry, I meant the square formed by drawing lines along the wheels' directions is a diamond in relation to the square formed by the robot frame (so the wheels are at the mid-point of the sides of the square). I can see how you will see this is a square formation if you form the square by linking the four wheels in a square as the four corners.

[mikets]

My definition of slippage is that if the wheel is rotating 1 revolution, the wheel should displace PI*WheelDiameter in the direction of the rotation. If it's less, the wheel has slipped. This is generally true for mecanum wheels running forward/backward. We can prove that it has insignificant slippage going forward/backward because we are using 4" diameter wheels with a gear ratio of (24:16 = 1.5) and a NeveRest 40:1 motor. So the theoretical INCHES_PER_ENCODER_COUNT comes to 0.01683 inches/count. The actual measured value is 0.01667 which is 99% of the theoretical value. So practically, they are identical.
But when mecanum wheels are strafing, by definition, they have to slip.
But for Omni wheels in a diamond formation, the wheels are mounted 45-degree from the forward/backward axis of the robot. It means when the robot is going forward/backward or sideways, they have to slip.
For Omni wheels in a square formation, the wheels are mount front, back, sides and perpendicular to each other. Then going forward/backward/sideways will have no slip for the driving wheels. But like you said, it's very hard to design with the game because we probably want the front to be open for ball pickup and such.

If you look at where the mecanum wheel hits the ground, the roller is on a 45 degree angle to the robot, at a tangent to the circle of contact of all 4 wheels.
If you look at where the omni wheel hits the ground, the roller is on a 45 degree angle to the robot, at a tangent to the circle of contact of all 4 wheels.

Hmm, we may have different terminologies here too. From your description, I was assuming your robot has the Omni wheels in a diamond formation. They mounted at the same locations of the robot as mecanum wheels (i.e. front left, rear left, front right, rear right) but they are turned 45-degree. It's a diamond because the square that the wheels formed is a diamond in relation to the square formed by the robot frame.

[Philbot]

I said that because Omni wheels and mecanum wheels alike, they tend to slip when one force vector has to cancel another force vector. In mecanum wheels, that would be strafing. If only going forward/backward, there is no canceling force vector. However, with Omni wheels on a diamond formation, going forward/backward or sideways requires opposing force vectors canceling each other. The only situation without force vector canceling is going diagonal. I am assuming going forward/backward and strafing is a lot more common than going diagonal. That's why I said I prefer mecanum than Omni in diamond formation.
.

I think I see what you are saying in relation to the omni wheel in diamond vs square formation.
In a square, Axial and lateral motions require balancing force vectaor, but in an diamond formation Axial and lateral motions use pure wheel rotations with no roller action.
It's unfortunate that most robots need a ground opening in the front, so having an omni wheel up front makes for a difficult design.

However, I still think you are miss characterizing how a mecanum wheel works when strafing vs fwd/back.
In both cases, the rollers need to "roll" in order for the force vectors to work properly.

Semantics may be causing a bit of the problem here..

In any wheel system there is the possibility of unwanted loss of traction. This "slippage" is undesirable as it leads to incorrect odometery. Slippage = bad

However, in both omni and mecanum wheels, there is the addition of the diagonal roller, which is required to allow the wheel to drive in one direction, and have free motion in the other.
Slippage = good. So I'd rather not call it "Slippage" because it's not undesired, it's actually required. Perhaps "freewheeling" is better.

We use the DuraOnmi wheels from Andymark

http://www.andymark.com/product-p/am-3047.htm

And these have very grippy rollers, so we don't see any more unwanted slippage than you might see on a mecanum roller.

So, let's just consider the situation where both robot types have the wheels in the same locations.. basic square layout)
And lets ignore "slippage" and only consider "freewheeling"

With both Omni and mecanum wheel types, the drive force can ONLY be applied along the axis of the "roller". Any other force is lost due to the roller's freewheeling.

So the key factor here is where the contact roller hits the ground, and what direction it's pointing in relation to the robot.
If you look at where the mecanum wheel hits the ground, the roller is on a 45 degree angle to the robot, at a tangent to the circle of contact of all 4 wheels.
If you look at where the omni wheel hits the ground, the roller is on a 45 degree angle to the robot, at a tangent to the circle of contact of all 4 wheels.

Whoa... it's exactly the same.

Now, when you rotate the omni wheel, it will be forcing against the opposing wheel, so the contact roller MUST freewheel to prevent locking the drive.

But...when you rotate the mecanum wheel, even though the motor is pulling it directly back, the contact roller will STILL freewheel.

It has to, because it's at a 45 degree angle to the direction of applied force.
The easiest way to see this is to try it with a single roller in your hand.
Place it at 45 degrees and then pull it towards you. The only way for it to move in a straight line is for it to freewheel .
And while it's freewheeling, Half of that force is applied in the forward direction, and the other half is wasted as the roller rotates.

This ratio of usable force to wasted force is directly related to the angle of the roller, and varies from 1:0 to 1:0

So for either robot to move forward, the left and right wheels need to drive in opposing directions and the each wheel's rollers will freewheel the same amount.
Which is why I maintain that the ONLY advantage of mecanum over omni is the ability to mount the motors in a conventional trans robot configuration (at 90 deg to the frame).

[Tomy]

So from what I am reading. Omni drive and Meccanum will slip. It is best to start them off at a slow speed and keep that speed. It wasn't clear if the distance scale formal would actually work or not. We are planning on using a gyro to correct our rotation so that isn't a problem at all.

[FTC4160]

I've been advocating for this approach to my team for a while now, but nobody seems really willing to try it. How well is it working for you?

The gyroscope part is working great; we are using proportional-only logic to stay on target. The only problems we've encountered are related to the differences in the field walls and improper mounting of the beacons at official competitions.

[mikets]

Actually, my question was about how the no turning autonomous was working. (We already use a lego ultrasonic for distance from the wall).

I assume you are referring to using the gyro and keep the heading straight while strafing? If so, was your question "how well does it work?" or "how to use the gyro to keep the robot heading straight?"