Announcement
Collapse
Technology Forum Has Moved!
The FIRST Tech Challenge Technology forum has moved to a new location! Please take a look at our forum blog for links and instructions on how to access the new forum.
Note that volunteers (except for FTA/WTA/CSA will still access their role specific forum through this site. The blog also outlines how to access the volunteer forums.
Note that volunteers (except for FTA/WTA/CSA will still access their role specific forum through this site. The blog also outlines how to access the volunteer forums.
See more
See less
Omni Wheel Drive Train and Auto Mode
Collapse
X

Originally posted by jkenney View PostMikets,
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 ydirection or xdirection robot motion. What did you find?
Leave a comment:


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 ydirection or xdirection robot motion. What did you find?
Leave a comment:


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 1112 %. So, instead of a factor of 1.41, we got a factor of about 1.25. This was true for both Xmode and Ymode motion.
I attribute the 1112% 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 %.
Leave a 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.
Leave a 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.
Leave a 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];
Leave a 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:
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.
Leave a 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.
Leave a 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.
Leave a 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.
Leave a 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.
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).
Leave a 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.
Leave a 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?
Leave a 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).
Leave a comment:

Leave a comment: