Experience with mecanum wheels?

[mikets]

I want to tap into the experience of other teams with mecanum wheels. We are using mecanum wheels this season. Earlier in the season, it was performing very well. But lately, it can't strafe straight any more. When strafe to the left, it also goes a little backward so it was traveling diagonally left and back (the heading is fine though since we use gyro to maintain proper heading). It messed up our autonomous. We examined the wheels very careful. We thought we found some free play of the wheels (some wheels have free play side to side so that when it strafes, they may shift to one side rubbing against the frame). We took the wheels out and re-assemble them with proper spacers to get rid of the problem. The problem went away for a while. Then it's back again. We examined the wheels again and they don't have any free play any more. So what caused that? We have a motor test that we run on each individual wheel for 5 seconds and if one wheel has more friction than the others, it will show up with a lesser encoder count. But all wheels have pretty much the same count (with insignificant differences). We vacuumed the field thinking debris on the field may make the wheels slip. Anything we did would improve the situation a bit but the problem always comes back. So I am wondering if anybody has any suggestion on what else to look for.

[mlwilliams]

We have the same issue and I believe it is affected by the foam tiles more than anything. We also use a gyro to maintain proper heading while strafing but have the same issue of drifting forwards and backwards while going both left and right. One test was to strafe across the entire field with the intention of moving in a straight line. Sometimes it was in front of the line and sometimes behind the line. It actually made it to the other side right on target. Differences in the floor is the only thing that could explain that. We haven't come up with a way to detect or compensate for this but only plan on strafing short distances in autonomous.

Does speed make a difference for you? We're using the dpad buttons to move in the four cardinal directions but at a low speed for precise control during teleop. It seems to go straighter at lower speeds.

[Philbot]

Does speed make a difference for you? We're using the dpad buttons to move in the four cardinal directions but at a low speed for precise control during teleop. It seems to go straighter at lower speeds.

I don't know how much load is placed on the motors while running mecanum wheels, so I'll ask a couple of questions..

1) What motors are you using?
This is important for a couple of reasons:
a) because most motors generate less CPS than the standard TETRIX motors. So if you are over-demanding, some of your motors may be generating more speed than the others, simply because they are maxed out
differently. This may cause drift while strafing. Requesting a lower speed would eliminate this problem.

b) we know that last season's NR motors had an issue that they generated less pulses while under load, but only in one direction (this was due to shifting of the encoder magnet).
Is the issue symetrical? eg: is the drift the same in both directions.


What % speed are you requesting f

[msonnier]

Having fought (and finally overcome) these same issues on an FRC build 2 years go, here are three thoughts on things you can try:

1> You could try moving the Center of Gravity around the robot (e.g. by adding temporary ballast). If your CoG is not directly over the geographic middle of your wheels, you will have different weights and thus different frictional effects on each wheel. Mecanum works best with equal weight on each wheel. Going slower generally limits wheel slippage, and reduces the impacts of the above. Moving the CoG around and testing impacts will help you understand if unequal wheel slippage might be a problem.

Also consider the "net torque" around the non-centered CoG for all the force vectors for your 4 wheels, and if they don't net out to 0 your robot will rotate as it strafes. If your CoG is far from centered, this can be significant.

In short, having stable and centered CoG if possible is the most important fix. Everything else you do is to OVERCOME the issues that are created with other configurations.


2> Another thing to look at: are you regulating the wheel speeds via Encoder (e.g. Run With Encoder) as you strafe? Minor variations in motor, gear box, axles, bearings, etc can have a huge impact on real wheel rotational speed, and even very minor variations will cause issues. For TeleOp this is pretty easy to deal with just be setting motor controller mode. For Auto, the problem is you are probably using Run to Position, which AFAIK doesn't guarantee the motor is running at a particular encoder verified speed, only that it will attempt to run to a specific encoder value. All 4 wheels might be moving the right number of clicks, but not necessarily at synchronized RPMs (e.g. one wheel moving a bit faster at the start of the motion than others). The MR motor controllers are I think fairly unsophisticated in managing the motor speed -- pretty much just powering the motor "open loop" at the max power you specify until it gets close to the target.

We overcame this with an FRC robot build a few years back using custom PID code in Java instead of relying on PID code in motion controllers. Basically you need a PID routine on the overall robot that controls the distance moved (forward/back or strafe). This is a single PID for the entire robot, not per wheel. Its input is the "average" of the distance to be moved of the 4 wheels -- i.e. average of the encoder clicks remaining to be moved -- but you have to carefully account for the "sign" of the encoders and wheels turning in opposite directions when you strafe and same direction for forward/back movement when you compute this average. Note that this PID has NO direct connection to powering/moving individual wheels.

The output of this first stage PID provides a desired velocity you want to move the robot, in this case in a particular strafing direction. We then apply the normal Mecanum motion mathematics to convert this velocity into specific required rotational velocities for each wheel. We then use this as the input to each wheels motors using a PID type speed control (e.g. Run With Encoder). This scheme which relies on averaging the various encoders as a measure of overall distance moved / remaining only works for motion directly forward/back or direct side to side strafing. The mathematics breaks I think if you try and use it for diagonal motion of any type.


3> You may be able to use a gyro to help keep things in alignment as you strafe. Depending on how you apply gyro correction, it might just keep you "straight" but with forward/rear drift as mlwilliams points out. Generally Mecanum motion calculations have as an input both a translation motion vector (distance and velocity) but also a rotational velocity input. Using the gyro to detect alignment error as you strafe (i.e. you turned) would allow you to deriva a rotational velocity input for your Mecanum calculations. However, there are several complexities here, as CoG potentially comes back into play doing the rotational correction accurately. Finally, the math for rotational calculations of the "simple" Mecanum dynamics assume the wheels are in a square configuration (equal wheelbase side to side and front to rear wheels). If your geometry is different, you may need to adjust.

There are several white papers and presos on ChiefDelphi that go through Mecanum motion dynamics, including calculations accounting for varying wheel bases, track widths, etc... Some to start with:
https://www.chiefdelphi.com/media/papers/1836
https://www.chiefdelphi.com/media/papers/2390
https://www.chiefdelphi.com/media/papers/1836



Good luck with this. It's certainly doable and has been done by teams in the past -- but does require quite a bit of time to get right.

[mikets]

Does speed make a difference for you? We're using the dpad buttons to move in the four cardinal directions but at a low speed for precise control during teleop. It seems to go straighter at lower speeds.

We tried strafing both in autonomous and teleop. In teleop, we moved the stick slightly so it was not full power. When moving across the entire field, it may start out straight but then it would soon go diagonal at almost 45 degree. Occasionally, it may even go as bad as forward or backward only while trying to go sideway. Now I can't swear to the fact that the kids might have moved the stick at full power at some point. But interestingly, when it drifts it always drifts backward when strafing left and drifts forward when strafing right. That's why we were suspecting mechanical issues with some particular wheels. If they were strafing less than 20 degrees (i.e. drift one foot forward/backward while strafing sideway 3 feet), we wouldn't even complain. But it was at least 45 degrees or worse.

[mikets]

I don't know how much load is placed on the motors while running mecanum wheels, so I'll ask a couple of questions..

1) What motors are you using?
This is important for a couple of reasons:
a) because most motors generate less CPS than the standard TETRIX motors. So if you are over-demanding, some of your motors may be generating more speed than the others, simply because they are maxed out
differently. This may cause drift while strafing. Requesting a lower speed would eliminate this problem.

b) we know that last season's NR motors had an issue that they generated less pulses while under load, but only in one direction (this was due to shifting of the encoder magnet).
Is the issue symetrical? eg: is the drift the same in both directions.


What % speed are you requesting f

We are using NeveRest 40:1. I should test this again personally tomorrow to make sure we are not using full power.
Strafing does cause a lot of stress on the motors. I can tell because I was monitoring the battery voltage. If we are just driving forward and backward, a fully charged battery (13V at rest) will be drawn down to 12V or may be 11V in the worst case. But when strafing, the battery can go down to 10 or 9V easily.

[mikets]

1> You could try moving the Center of Gravity around the robot (e.g. by adding temporary ballast). If your CoG is not directly over the geographic middle of your wheels, you will have different weights and thus different frictional effects on each wheel. Mecanum works best with equal weight on each wheel. Going slower generally limits wheel slippage, and reduces the impacts of the above. Moving the CoG around and testing impacts will help you understand if unequal wheel slippage might be a problem.

We will try to determine the center of gravity tomorrow but just thinking about it, I don't see too much asymmetry on our robot. The right side has an aluminum box beam but should be balanced out by the battery on the left.

2> Another thing to look at: are you regulating the wheel speeds via Encoder (e.g. Run With Encoder) as you strafe? Minor variations in motor, gear box, axles, bearings, etc can have a huge impact on real wheel rotational speed, and even very minor variations will cause issues. For TeleOp this is pretty easy to deal with just be setting motor controller mode. For Auto, the problem is you are probably using Run to Position, which AFAIK doesn't guarantee the motor is running at a particular encoder verified speed, only that it will attempt to run to a specific encoder value. All 4 wheels might be moving the right number of clicks, but not necessarily at synchronized RPMs (e.g. one wheel moving a bit faster at the start of the motion than others). The MR motor controllers are I think fairly unsophisticated in managing the motor speed -- pretty much just powering the motor "open loop" at the max power you specify until it gets close to the target.

In TeleOp, we did try RUN_WITH_ENCODER mode and it still drifted. In Autonomous, we use RUN_WITHOUT_ENCODER but we have our own PID control that re-distribute power to all four wheels taking into account of all four encoders and the gyro. Our heading is doing fine because of the gyro so it will just drift forward/backward because the encoders are not accurate in strafing because of slippage. We even tried turning on RUN_WITH_ENCODER mode while doing our PID control on top (i.e. essentially doing a cascading PID control - double PID control) but still didn't help. So I suspect it was due to wheels slipping so the encoder reading is no longer accurate. Tomorrow I will try to limit the output power of the PID controller to 0.5 while strafing and see if that helps.[/QUOTE]

We overcame this with an FRC robot build a few years back using custom PID code in Java instead of relying on PID code in motion controllers. Basically you need a PID routine on the overall robot that controls the distance moved (forward/back or strafe). This is a single PID for the entire robot, not per wheel. Its input is the "average" of the distance to be moved of the 4 wheels -- i.e. average of the encoder clicks remaining to be moved -- but you have to carefully account for the "sign" of the encoders and wheels turning in opposite directions when you strafe and same direction for forward/back movement when you compute this average. Note that this PID has NO direct connection to powering/moving individual wheels.

We use our own PID code, not the per wheel PID built-in to the motor controller precisely for this reason. With our PID code, we shift power around different wheels accounting for the heading using gyro as well as all four encoders. Our algorithm for combining all four encoders is:

        //
        // 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
        //

The output of this first stage PID provides a desired velocity you want to move the robot, in this case in a particular strafing direction. We then apply the normal Mecanum motion mathematics to convert this velocity into specific required rotational velocities for each wheel. We then use this as the input to each wheels motors using a PID type speed control (e.g. Run With Encoder). This scheme which relies on averaging the various encoders as a measure of overall distance moved / remaining only works for motion directly forward/back or direct side to side strafing. The mathematics breaks I think if you try and use it for diagonal motion of any type.

Yes, this is the Cascade PID control you are describing. We just added Cascade PID control to our library but haven't tested it yet (probably won't use it this season because we don't have time to fully test and tune it - Cascade PID control has TWO sets of PID constants to tune and we don't have experience in tuning that yet). But as an experiment, we turned on the RUN_WITH_ENCODER mode because it is equivalent to Cascade PID control. The RUN_WITH_ENCODER mode is the 2nd stage speed control PID while our PID code is the first stage. Like I said, it didn't help.

3> You may be able to use a gyro to help keep things in alignment as you strafe. Depending on how you apply gyro correction, it might just keep you "straight" but with forward/rear drift as mlwilliams points out. Generally Mecanum motion calculations have as an input both a translation motion vector (distance and velocity) but also a rotational velocity input. Using the gyro to detect alignment error as you strafe (i.e. you turned) would allow you to deriva a rotational velocity input for your Mecanum calculations. However, there are several complexities here, as CoG potentially comes back into play doing the rotational correction accurately. Finally, the math for rotational calculations of the "simple" Mecanum dynamics assume the wheels are in a square configuration (equal wheelbase side to side and front to rear wheels). If your geometry is different, you may need to adjust.

Yes, we do use a gyro and maintaining the heading was not the problem, just drifting forward/backward.

[mikets]

Phil,
Thinking about it some more, I am suspecting you are right about the shifting magnets in the encoders because strafing does assert a lot of stress on the motors. How do you prove that? Is there a simple way to pinpoint this is the problem? One way I can think of is too add external US Digital encoders but it is a lot of work modifying the robot for this "experiment" (have to somehow mount the encoders on either the motor shaft or the wheel shaft.

[Philbot]

Phil,
Thinking about it some more, I am suspecting you are right about the shifting magnets in the encoders because strafing does assert a lot of stress on the motors. How do you prove that? Is there a simple way to pinpoint this is the problem? One way I can think of is too add external US Digital encoders but it is a lot of work modifying the robot for this "experiment" (have to somehow mount the encoders on either the motor shaft or the wheel shaft.

It was quite difficult to diagnose and prove the encoder issue.
The system "appears" to be working correctly because all the encoder values match what they should,, but in reality the effected motors are trying to run faster because they aren't sending the motor controllers enough pulses. This assumes you are running in RUN_USING_ENCODER mode, which we typically so.

Ultimately we proved what was going on by running running all motors at 50% power (under load) for 2 seconds (when we pressed a button) and recorded the change in encoder counts for each motor.
One was decidedly less than the others. After replacing the motor, things worked fine... for about 2 days, and then it stared happening again.

We disected the motor and saw the encoder magnet move in and out based on load.

------ A new thought ------

Folks have been talking about having a balanced COG, which is pretty essential, but there is another issue...
It's hard to keep even ground contact on a 4 wheel robot, and a mecanum drive needs equal pressure on all wheels to ensure that the force vectors line up.
This is why it's hard to use them on uneven ground.

Have you checked that all your wheels are aligned to the same plane?
If you have direct drive wheels, it's really easy to just accidentally rotate one motor in the mount, and cause an uneven drive surface.
Even a frame that isn't built square (flat) can be a problem. 1/8" can make all the difference.

ps: This is why we went with a three wheel omni this year. Guaranteed contact on wheels plus you get an extra motor to use elsewhere


.

[mikets]

It was quite difficult to diagnose and prove the encoder issue.
The system "appears" to be working correctly because all the encoder values match what they should,, but in reality the effected motors are trying to run faster because they aren't sending the motor controllers enough pulses. This assumes you are running in RUN_USING_ENCODER mode, which we typically so.

Ultimately we proved what was going on by running running all motors at 50% power (under load) for 2 seconds (when we pressed a button) and recorded the change in encoder counts for each motor.
One was decidedly less than the others. After replacing the motor, things worked fine... for about 2 days, and then it stared happening again.

We disected the motor and saw the encoder magnet move in and out based on load.

Thinking even more about it, if the encoders have issues like this. It only affects any driving that involves encoders. We tried this in TeleOp with both RUN_USING_ENCODER and RUN_WITHOUT_ENCODER and still have issues. So it would seem either we have multiple problems or it's not the encoders.

Have you checked that all your wheels are aligned to the same plane?
If you have direct drive wheels, it's really easy to just accidentally rotate one motor in the mount, and cause an uneven drive surface.
Even a frame that isn't built square (flat) can be a problem. 1/8" can make all the difference.

I believe our drive wheels are on the same plane. We use aluminum box beams and precise mill the axle holes on them. I will check to make sure in tonight's meeting but I doubt this is an issue. Also, our drive train is not direct drive so that's not an issue either.

[robgcarlisle]

Robot needs Iron

Mecum wheels have to have balanced loads. We carry 15 pounds of weight on our robot to make it work well with these wheels (really: we buy exercise ankle weights and take the iron out of them). We move the weight around so that everything is exactly balanced in the center of the four wheels. The mecum wheels need even pressure on them to successfully strafe: any differences will cause some to slip and others to roll.

[robgcarlisle]

...and I remembered an easy way to test this. When your robot is staffing poorly, walk with it and push down on it (either centrally or above a wheel). If it straightens up, it needs more weight.

[jrasor]

We rebuilt our robot with mecanum wheels, and find that sideways driving does not go straight due to wheel slippage. Two of our 10th grade team members came up with a test: mark all 4 wheels with a bit of colored tape. Run an Autonomous opmode that simply strafes a few feet, and a little more to get a tape marker to show again. If your software and hardware are turning the wheels the proper amount, all four tape markers will show. Ours passes that test. We therefore think our wheels are slipping. They seem to do so more on a slick floor than on the Velocity Vortex Field.

We tried robgcarlisle's manual push down technique, but it did not help. Static weights, though, may be a better test.

[5294-jjkd]

We are using mecanum wheels, with no issue of slippage --- our robot weighs over forty pounds at this point without any added ballast.

[mlwilliams]

We are using mecanum wheels, with no issue of slippage --- our robot weighs over forty pounds at this point without any added ballast.

Which specific wheels are you using? We using the low-end Andymark 4" wheels but are thinking about upgrading:

http://www.andymark.com/4-inch-mecanum-wheel-p/am-2538.htm