Bizarre Mecanum Programming Bug

Hey Guys,

I have tried both my own code and stuff based on what team 357 put on this site and I have encountered the same problem in both cases. The robot will move straight forward and backward just fine. It will even spin in circles in both directions just fine.

Whats bizarre is that when we attempt to just strafe to the side, the robot will travel in an arc and spin slowly one way or the other (depending on which way we try to strafe). The problem seems to be caused by two wheels (diagonal from each other) spinning much faster than the other diagonal pair. Here’s the real interesting part, though: the pwms indicate that the 4 wheels should be rotating in their respective directions at the same rates. When we try to strafe in the opposite direction, though, the pair of diagonal wheels that spin faster is the other one and again the pwms (seen via printf) indicate that there should be no problem.

Would someone please explain what is going on and maybe how we can fix this?

If you’ve calibrated the Victors and if you’re using the Chicklet, calibrated the joystick, then numerically, everything is equal.
One thing that could be happening is that the motors are biased to run in one direction. They run faster (in general) forward than backwards. That could cause the arc you’re seeing and in both directiions. By the way, I’m seeing the same arc you mentioned in my mechanum platform so it’s not unusual.
I tweaked my numbers and got it to run straighter and I’m incorporating some feedback that is also helping with the strafe motion.

Steve

I think it might be a problem with the victors, I noticed this year they might be uneven as they might give more power in one direction.

Is there any chance that your wheels are on backwards?

We saw this too, a bit. Weight distribution and frame straightness/rigidity is also very important, I’m told.

This can be fixed by feeding back the gyro into the rotation command. Something like:


read joysticks and adc for gyro, scale to same units

rotation = (joystick_rotation - gyro_rotation) * gain;

do mecanum algorithm

So if you try to purely translate and get some rotation, the gyro picks it up and the controller sends a rotation command the other way, even if the joystick is in the zero rotation position. Your results may vary, but when we stuck this in we got this:

http://techtv.mit.edu/file/544

This is with both joystick and gyro scaled to a value of -127 to 127 and then the difference fed into a mecanum routine with a gain of 1. You can see it auto-correcting rotation if you look closely.

Check your weight distribution. A large weight on one end of a mecanum robot will cause it to arc while strafing.

Wheels being on backwards would result in NO strafing ability.

No. The wheels are mounted correctly.

Overall, what I gather is that I need to implement a Gyro to correct the arcing and redistribute the weight so that it is spread more evenly. I am pretty sure that the direction biases on the CIMs are negligible.

Thanks for all the feedback guys!

We tried using the gyro from the KOP only to encounter frustration in that the gyro would sense angular velocity just fine in one direction while giving random positive and negative numbers in the other direction. I am talking about an output of 15,15,15,15,15 for one direction and 1,-5,16,-15,-4,10 for the other direction. we have decided its simply pointless to mess with the gyro. The arcing I am describing is to the point that the bot strafes in a medium sized circle.

The problem persists in that strafing in one direction (lets say right) makes a diagonal pair of wheels rotate faster than the other pair. Strafing in the other direction yields the same problem but with the other diagonal pair going faster. Does anyone else see this? How do you suggest I proceed?

Our new mecanum drive does exactly what you describe when the weight is not perfectly balanced. The heavy end slides sideways slower than the light end.

If you’ve given up trying to make the gyro work for you, I can think of three other options. First, you can use some sort of wheel speed sensors to try to maintain equal speeds on all wheels. Second, you can attempt to blindly compensate for the imbalance by driving the slow-turning wheels with more power. Finally, you can give your driver the next couple of weeks to learn how to stabilize the robot’s strafing manually.

We have successfully resolved our strafing issues without implementing either the gyro or encoders in a PID-type loop. We simply wrote code to cycle through all the possible PWM values and counted how many encoder counts the PWM value would produce per 10 loops. By graphing the Rotations vs. PWM data, we were able to see that the problem lay not so much in the speeds of different wheels but in where the real “deadzone” for the drivetrain was. All we had to do was shift the PWM deadzone center from 127 to 133 and we had our problem fixed. Just to note, our battery is mounted in the geometric center of the drive base, so uneven weight distribution is a negligible problem for us. I just thought should let everyone know this so that others can diagnose how to solve any arcing problems while strafing with mecanum wheels. Graphing the RPM vs PWM data really showed us exactly what we needed to do.

Thanks for the advice guys!

-Matt