Omni Wheel Drive Train and Auto Mode

[Tomy]

This year my team is going to be using omni drive. In previous years we've used encoders to tell our robot to drive a certain distances. How will the wheels at a 45 degree angle affect the calculations?

This is the example from this year modified since we do not have any drive gear reductions

    static final double     COUNTS_PER_INCH         = (COUNTS_PER_MOTOR_REV) / (WHEEL_DIAMETER_INCHES * 3.1415);

Thanks for the help

Tomy

[4634 Programmer]

Just to throw out a suggestion - we are using the Lego ultrasonic sensor for moving certain distances from the wall, and we found that it was extremely accurate up to ~5FT.

[FTC4160]

Omni drives slip a lot and the amount of encoder counts required to move a certain difference will vary large amounts based on the weight of your robot, the speed it is moving (or rather, acceleration), the direction of the movement (with respect to the wheels) and the amount of wear on the floor tiles. Our team is also using the Lego ultrasonic sensor for moving distances from the wall.

[Tomy]

Distance from the wall is a really smart idea. How well does it sense the distance if the wall is at an angle?

[FTC4160]

I haven't tested this, but I know Sonar Sensors are pretty bad at sensing angled surfaces because the ping is not reflected back at them. We use a gyroscope to preserve our orientation during autonomous (we don't turn at all).

[Tomy]

Ah ok. I am thinking of putting the sensor on a servo and changing the angle of it after we turn.

[msonnier]

Can you share any info as to the positioning of the Omni wheels? Are all your wheels Omni? Simple rectangular placement, or some other Holonomic driving configuration?

An FRC team I mentor a few years ago (Recycle Rush) used Mecanum wheels and encoder + gyro based Autonomous navigation with pretty good luck. Depending on your wheel configuration, Omni wheels and Mecanums have a lot of similarities. The key to successful navigation we found was doing every move either as a straight motion, using wheel encoders to measure distance and the gyro to correct any direction deviations, or doing simple rotation motions (using gyro instead of encoder counts).

Using the above configuration, we were able to do complex autonomous routines (10 plus individual movements including some side strafing motions) and ending up within about 2 inches and 5 degrees of desired outcome probably 95% of the time.

Our biggest cause of error was due to having to cross the "scoring platforms" in some autonomous configurations, which were not flat and caused some wheels to lose traction or at least shifted weight balance across wheels causing encoder errors. Probably not a huge issues w/ Velocity Vortex unless you are crossing the Center Vortex base or trying to climb a Corner Vortex.

[Tomy]

Can you share any info as to the positioning of the Omni wheels? Are all your wheels Omni? Simple rectangular placement, or some other Holonomic driving configuration?

An FRC team I mentor a few years ago (Recycle Rush) used Mecanum wheels and encoder + gyro based Autonomous navigation with pretty good luck. Depending on your wheel configuration, Omni wheels and Mecanums have a lot of similarities. The key to successful navigation we found was doing every move either as a straight motion, using wheel encoders to measure distance and the gyro to correct any direction deviations, or doing simple rotation motions (using gyro instead of encoder counts).

Using the above configuration, we were able to do complex autonomous routines (10 plus individual movements including some side strafing motions) and ending up within about 2 inches and 5 degrees of desired outcome probably 95% of the time.

Our biggest cause of error was due to having to cross the "scoring platforms" in some autonomous configurations, which were not flat and caused some wheels to lose traction or at least shifted weight balance across wheels causing encoder errors. Probably not a huge issues w/ Velocity Vortex unless you are crossing the Center Vortex base or trying to climb a Corner Vortex.

We are using 4 double omni wheels in a square formation. Picture found here

I am hopping that you have the answer and that we can use encoders because we will need to turn and strafe for our strategy to work.

[msonnier]

In that configuration, be aware that for motions along the robot axes (i.e. not moving at 45 degrees off axis from the robot chassis) your encoder counts will have to be adjusted for the "off axis" direction they are driving -- I believe adjusted by sqrt(2) though you will want to verify the math. If your primary linear moves can be constrained along the 45 degree offset axes (i.e. parallel to 2 wheels, perpendicular to the other 2) you may find encoder + gyro direction correction may be more accurate.

Also, your center of gravity will likely have an impact -- i.e. you want all 4 wheels to have equal weight on them for ideal operation. If you are unbalanced, you will find that encoder counts may not work out as well.

It may be too late, but have you considered an H configuration Omni such as shown here. This configuration would behave more like "standard" drive with encoders for forward back motion at least.

Good luck to you. I think you will have to do some testing to see if our Mecanum experiences will translate to your Omni configuration...

Regards

[Philbot]

We are using 4 double omni wheels in a square formation. Picture found here

I am hopping that you have the answer and that we can use encoders because we will need to turn and strafe for our strategy to work.

Omni drives like the one you have there are are sensitive to the weight distribution of the robot, and any variations in wheels speeds.
Using encoders and running the wheels in RUN_USING_ENCODER mode will help a lot, but you will naturally get a certain amount of rotational variation.
That is, as you strafe, the robot will tend to drift off course. This occurs much more than a traditional fixed wheel drive. To mitigate this, you reallllly need to use a gyro.
The gyro will let you keep the robot pointing straight which will let the encoders do their job.

having said that, it's simple to calculate the distances required for the encoders.
You just need to draw a picture of the path of an individual wheel, and figure how far the wheel has to run, to move forward a set distance.

eg
if the wheels are at 45 deg. then for the robot to move forward 1 inch, the wheel has to move at 45 degrees a longer distance, equal to the hypotenuse of a 1 x 1 right triangle. or sqrt(1 + 1)
so any distance just needs to be multiplied by 1.414

Use the usual math for converting inches to encoder counts, just upscale your distances by 1.414

[Tomy]

Omni drives like the one you have there are are sensitive to the weight distribution of the robot, and any variations in wheels speeds.
Using encoders and running the wheels in RUN_USING_ENCODER mode will help a lot, but you will naturally get a certain amount of rotational variation.
That is, as you strafe, the robot will tend to drift off course. This occurs much more than a traditional fixed wheel drive. To mitigate this, you reallllly need to use a gyro.
The gyro will let you keep the robot pointing straight which will let the encoders do their job.

having said that, it's simple to calculate the distances required for the encoders.
You just need to draw a picture of the path of an individual wheel, and figure how far the wheel has to run, to move forward a set distance.

eg
if the wheels are at 45 deg. then for the robot to move forward 1 inch, the wheel has to move at 45 degrees a longer distance, equal to the hypotenuse of a 1 x 1 right triangle. or sqrt(1 + 1)
so any distance just needs to be multiplied by 1.414

Use the usual math for converting inches to encoder counts, just upscale your distances by 1.414

So if we wanted to go 20 inches each wheel would have actually go 20 x 1.414 = 28.28 inches

[mikets]

The problem of calculating the forward distance traveled with the above formula is that it assumes there is no slip of the wheels. But with Omni wheels in diamond formation, they will slip even going forward/backward. So you will most likely be not very accurate. You are better off using mecanum wheels than Omni wheels. With mecanum wheels, going forward and backward is exactly the same as fixed wheels. They are less likely to slip in the forward/backward direction. It will be a little bit tricky with strafing. Again, if it slips then it won't be accurate. In general using encoders to keep track of strafing distance is difficult because of the slip. We do have an algorithm in our library to calculate strafing distance of mecanum drive. It's been fairly accurate for us if we are careful not to let the wheels slip (i.e. strafe at slower speed). Here is how we derived our algorithm for mecanum wheels:

        //
        // According to RobotDrive.mecanumDrive_Cartesian in WPILib:
        //
        // LF =  x + y + rot    RF = -x + y - rot
        // LR = -x + y + rot    RR =  x + y - rot
        //
        // (LF + RR) - (RF + LR) = (2x + 2y) - (-2x + 2y)
        // => (LF + RR) - (RF + LR) = 4x
        // => x = ((LF + RR) - (RF + LR))/4
        //
        // LF + RF + LR + RR = 4y
        // => y = (LF + RF + LR + RR)/4
        //
        // (LF + LR) - (RF + RR) = (2y + 2rot) - (2y - 2rot)
        // => (LF + LR) - (RF + RR) = 4rot
        // => rot = ((LF + LR) - (RF + RR))/4
        //

[Philbot]

The problem of calculating the forward distance traveled with the above formula is that it assumes there is no slip of the wheels. But with Omni wheels in diamond formation, they will slip even going forward/backward. So you will most likely be not very accurate. You are better off using mecanum wheels than Omni wheels. With mecanum wheels, going forward and backward is exactly the same as fixed wheels. They are less likely to slip in the forward/backward direction. It will be a little bit tricky with strafing. Again, if it slips then it won't be accurate. In general using encoders to keep track of strafing distance is difficult because of the slip. We do have an algorithm in our library to calculate strafing distance of mecanum drive. It's been fairly accurate for us if we are careful not to let the wheels slip (i.e. strafe at slower speed). Here is how we derived our algorithm for mecanum wheels:

        //
        // According to RobotDrive.mecanumDrive_Cartesian in WPILib:
        //
        // LF =  x + y + rot    RF = -x + y - rot
        // LR = -x + y + rot    RR =  x + y - rot
        //
        // (LF + RR) - (RF + LR) = (2x + 2y) - (-2x + 2y)
        // => (LF + RR) - (RF + LR) = 4x
        // => x = ((LF + RR) - (RF + LR))/4
        //
        // LF + RF + LR + RR = 4y
        // => y = (LF + RF + LR + RR)/4
        //
        // (LF + LR) - (RF + RR) = (2y + 2rot) - (2y - 2rot)
        // => (LF + LR) - (RF + RR) = 4rot
        // => rot = ((LF + LR) - (RF + RR))/4
        //

Hi

I'm not sure I agree with your analysis of slippage... Omni compared to Mecanum.

If you use an omni-wheel with elongated rollers (rather than the short rollers used on the TETRIX omni wheels), then the rollers are very similarly shaped to mecanum rollers.
Now, because of the angle the roller makes with the ground, both types are required to "slip" in order for the robot to move in any direction (except rotation).

Then, the only real advantage of Mecanum vs Omni is that the complex wheel shape allows you to mount the motors in the conventional transverse parallel configuration.
You can essentially take standard wheels off one robot and replace them with Mecanum wheels to get an omni bot.

The wheel shape turns the rollers 45 degrees, instead of turning the motor 45 degrees.
In both cases, the rollers are needed to decouple the rotation of the wheel from the motion of the robot along the 45 degree axis.
It's not a flaw... it's a required feature.

So, they are essentially the same.

With equal traction material on the rollers, both wheel types roll (not really slip) sideways (inwards) the same amount to allow forward travel.

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

If you take a very close look at a single roller as the robot moves forward (put a marker line on it) you will see the roller rotating.

Custom mecanum wheels have been designed with "locks" or "roller brakes" on them which allow the individual rollers to be locked in position on demand.
These wheels truly are faster in the forward direction as they revert to normal "fixed" wheels when moving forward.

[4634 Programmer]

How well does it sense the distance if the wall is at an angle?

Not well at all, unfortunately.

[4634 Programmer]

I haven't tested this, but I know Sonar Sensors are pretty bad at sensing angled surfaces because the ping is not reflected back at them. We use a gyroscope to preserve our orientation during autonomous (we don't turn at all).

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?