Experience with mecanum wheels?

[mikets]

@mikets - FYI - your private message inbox has reached its quota.

Sorry, didn't realize the inbox is so small (only 50 messages). In any case, I cleared most of them.

[FTC7253]

@mikets - FYI - your private message inbox has reached its quota.

[mdolecki9455]

Sounds good Mike. I just got my volunteer notification to be a CSA at the state championship on the 4th so maybe I will see you there. One of our teams (6188 SiBorgs) will also be there competing.

[mikets]

Hi Mike -

I am a bit familiar with your team's robot since we competed against you at the Interleague (congratulations!) and I had a chance to look at it in the Pits.

One of our three teams used mecanum wheels and saw some of the same behavior at one point. It worked itself out as the build progressed, so we didn't pursue it once it was gone.

Since the encoder counts are coming out equal, and the robot is drifting to the left and back when strafing left, I would focus on the back left wheel and then front right wheel. The force vectors for the front left and back right wheels during a left strafe push your robot to the back left, and this is supposed to be balanced out by the force vectors from the front right and back left motors which push the the front left. The front and back portion of the vectors cancel out, leaving only left motion.

This means that the front right and/or back left wheels are not providing the same amount of force as the opposing corners. This is like a four legged table with one slightly shorter leg, but the weight of your robot may not allow it to rock when on a flat surface.

I would start with looking at weight distribution. My initial assumption would be that there is some difference where the back left or front right is slightly higher than the other wheels, reducing friction and allowing one or the other wheel to slip a bit. The second assumption would be that your center of gravity is closer to the front right, so that motion to the left is causing the back left wheel to lift slightly, again reducing friction. I would test at very low and high speeds to see if the drift varies. Logging gyro data would show whether there is some tilt during a left strafe.

The shift of weight from moving any mechanisms on your robot will change your center of gravity and could cause a slight tilt that wouldn't likely be visible. You could test this with the robot stationary. Move various mechanisms while logging gyro data.

Since you are already attempting hardware tweaks, another option is to compensate by using an accelerometer or IMU to correct your motion vector if it deviates from expected vector. As our programmers say, "just code around it".

Good luck.

Mark

Thank you Mark. It will be a good exercise to find the root cause of this problem but at this point we probably wouldn't change anything because our robot works very well and like you said, we have "worked around" the issue and not heavily dependent on strafing anymore. I agreed with your assessment. I also think weight distribution is one factor and the floor tile friction is another. At one point, the strafing was really bad, so we "vacuum the floor clean" and it improved strafing for a while. So debris on the field does affect strafing too. After the season, we will probably have the kids do some experiments on this issue and find the root cause.

[mdolecki9455]

Hi Mike -

I am a bit familiar with your team's robot since we competed against you at the Interleague (congratulations!) and I had a chance to look at it in the Pits.

One of our three teams used mecanum wheels and saw some of the same behavior at one point. It worked itself out as the build progressed, so we didn't pursue it once it was gone.

Since the encoder counts are coming out equal, and the robot is drifting to the left and back when strafing left, I would focus on the back left wheel and then front right wheel. The force vectors for the front left and back right wheels during a left strafe push your robot to the back left, and this is supposed to be balanced out by the force vectors from the front right and back left motors which push the the front left. The front and back portion of the vectors cancel out, leaving only left motion.

This means that the front right and/or back left wheels are not providing the same amount of force as the opposing corners. This is like a four legged table with one slightly shorter leg, but the weight of your robot may not allow it to rock when on a flat surface.

I would start with looking at weight distribution. My initial assumption would be that there is some difference where the back left or front right is slightly higher than the other wheels, reducing friction and allowing one or the other wheel to slip a bit. The second assumption would be that your center of gravity is closer to the front right, so that motion to the left is causing the back left wheel to lift slightly, again reducing friction. I would test at very low and high speeds to see if the drift varies. Logging gyro data would show whether there is some tilt during a left strafe.

The shift of weight from moving any mechanisms on your robot will change your center of gravity and could cause a slight tilt that wouldn't likely be visible. You could test this with the robot stationary. Move various mechanisms while logging gyro data.

Since you are already attempting hardware tweaks, another option is to compensate by using an accelerometer or IMU to correct your motion vector if it deviates from expected vector. As our programmers say, "just code around it".

Good luck.

Mark

[Alec]

We are using the relatively cheap VEX mechanum 276-1447 wheels, with 3d printed adapters to go to Tetrix hubs and chain sprockets: http://www.vexrobotics.com/edr-wheels.html

So far no issues in 17 league runs and plenty of driving in practice, though we should probably get a spare set considering how comparatively inexpensive they are.

I agree. We use the VEX mecanums both on our demo bot and on our competition bot. They still work perfectly after a lot of abuse and require no maintenance after a lot of abuse. We like them so much that we now use VEX parts for our competition bot and use non-VEX parts only if we have to (which is very rare).

[5294-jjkd]

We are using the relatively cheap VEX mechanum 276-1447 wheels, with 3d printed adapters to go to Tetrix hubs and chain sprockets: http://www.vexrobotics.com/edr-wheels.html

So far no issues in 17 league runs and plenty of driving in practice, though we should probably get a spare set considering how comparatively inexpensive they are.

[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

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

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

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

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

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

[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]

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.