One other thing to consider: if you drive an omnibot at a 45 degree angle, 2 motors drive regularly with no slipping and 2 motors spin freely with no driving. It can be easier to drive using RUN_USING_ENCODERS mode like this on the 2 driving motors (especially if you use a gyro to correct for rotations).
Announcement
Collapse
No announcement yet.
Omni Wheel Drive Train and Auto Mode
Collapse
X

Originally posted by Philbot View PostI'm not sure I agree with your analysis of slippage... Omni compared to Mecanum.
Originally posted by Philbot View PostWhen discussing pure forward motion, it's easy to think that the mecanum wheels are more efficient because they don't "slip".
But in fact they do.
Comment

Originally posted by 4634 Programmer View PostI'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?
Comment

Originally posted by mikets View PostWe use the range sensor to detect distance to wall and it's working very well. Occasionally, the ultrasonic may lose an few echoes causing it to return 255cm but we have code to detect and deal with that, so it's not a big problem at all.
Comment

Originally posted by 4634 Programmer View PostActually, my question was about how the no turning autonomous was working. (We already use a lego ultrasonic for distance from the wall).
Comment

Originally posted by 4634 Programmer View PostI'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?
Comment

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.
Comment

Originally posted by mikets View PostI 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.
.
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/productp/am3047.htm
And these have very grippy rollers, so we don't see any more unwanted slippage than you might see on a mecanum roller.
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).
Comment

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 45degree 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.
Comment

Originally posted by mikets View PostHmm, 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 45degree. It's a diamond because the square that the wheels formed is a diamond in relation to the square formed by the robot frame.
Comment

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.
Comment

Originally posted by mikets View PostFor 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.
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/Prac...tematic_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 reinspection.. 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.
Comment

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 closeloop 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:
Code:yEnc = (lfEnc + rfEnc + lrEnc + rrEnc)/4;
Code:[COLOR=#808080][I]xEnc = ((lfEnc + rrEnc)  (rfEnc + lrEnc))/4[/I][/COLOR]
For example, on our robot this year, the scale factors are:
Code:[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];
Comment

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 positiveY (ie, forward) motion of the robot. We've defined three useful modes of operation:
Xmode: 1 cm of Xtravel of robot requires (14) Wheel Distances of: 1/sqrt(2), +1/sqrt(2), 1/sqrt(2), +1/sqrt(2)
Ymode: 1 cm of Ytravel of robot requires (14) Wheel Distances of: +1/sqrt(2), +1/sqrt(2), +1/sqrt(2), +1/sqrt(2)
Rotation mode: 1 radian of CCl 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 14, 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 (14) 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.
Comment

Originally posted by jkenney View PostI 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.
Comment
Comment