My team is new to mecanum wheels this year. We have modified to original frame that everyone receives to make it work. After getting things programmed mostly, I noticed that some wheels start spinning before the others, which makes our robot move in weird directions. Is there some way for this to be fixed so they spin at the same time at the same speed? Also, how can I set the joystick to have a little play in it before it starts spinning motors?
Just to make sure, you are using the same type of motor controller on all 4 wheels right? And they are controlled by PWM?
Greetings.
are you noticing this when the frame is on blocks? If so, you might be seeing is the inherent difference in the gear boxes/bearing/motors etc. Mecanum is VERY susceptible to uneven weight distribution. Code can help with all of these. There is some really good mecanum code out on the interwebs. Regarding the joystick: you can code in a deadzone in the joystick to set that ‘play’ you are talking about.
We are using talon six for each one which is all controlled by the CAN bus
Yes, when we have it on blocks, I noticed that some start turning before others, making them all different speeds until they reach their top speed.
You’ll want some type of feedback on your wheels, like encoders. And a PID loop (or at least a P loop).
Motors, grearboxes, and other components are not perfectly identical (a gearbox might have extra grease, another has the wires longer, one was dropped by a student/shipping handler with no exterior evidence, etc). This is also why drive trains never drive perfectly straight without feedback control.
An easy way to see if there are obvious mechanical issues is to unplug all the motors then try to turn the wheels by hand. If you can feel one having more resistance than another then that motor/gearbox might have something wrong with it. Trying to get them all perfectly equal is a goose chase though.
Motor unevenness can be somewhat calibrated without feedback, but it’ll take a while and won’t work as well as if you had feedback.
As for wanting a dead zone in for your controls, I wouldn’t worry too much about it: once you have weight on the wheels it’ll take more power to actually move the robot than what you’re seeing on blocks. If you still worry then instead of passing the joystick controls directly to your drive algorithm you can set up a quick if-statement where if the value of the input is between two thresholds then send your neutral value (say if your input range was 0-255 then 103 - 153 would be a 20% dead zone), if above then pass it through (actual programmers feel free to comment better things, I do mechanical)
Do you have some example of your PID or P loop. Is this something in coding or is it a wiring thing.
PID is a coding thing, a very common way of taking in what you want a value to be, what your current/past values have been (the feedback from an encoder usually [a thing that attaches to your motor shaft and tells you the current amount of rotation]), and coming up with the optimal way to get from where you are to where you want to be.
PID is an acronym for Potential, Integral, and Derivative. Don’t let the calculus words intimidate you, it’s simple concepts.
Potential is the difference between where you are and where you want to be (your wheel is going at 5 RPM and you want 7 RPM)
Integral is a sum of how far off you have been in the past (three ticks ago you were 5 off, two ago you were 3 off, one tick ago you were 2 off, etc).
Derivative is how fast you are changing how far off you are (You were 3 off two ticks ago, and you were off 2 one tick ago, so you’re changing at 1 RPM per tick).
You weight these P, I, and D values to determine what you should be sending to your motor controller (You’re 2 RPM off, but increasing at 3 RPM per tick? you should probably send a lower motor power value this time vs last time).
It’s pretty common to just use a P loop or a PD loop for simplicity and they work well enough.
You do need some type of feedback to use PID control though.
Unfortunately that’s basically all I know about it though, again, I build the chassis; you smart people make it actually run. If you ask a team that ran Mechanum or Swerve last year 90% they’ll be able to run you through how they controlled it. It’ll almost certainly involve encoders though. The PID controller wiki page is also pretty good, if a bit in depth. It’s a very common control algorithm.
If you do choose to use it then do yourself a favor and ignore all the fancy math to get better starting values. Pick your favorite number, make it bigger or smaller, see if it gets better or worse, plan for this to take literal hours. Also these values will change on your final robot because the center of mass and total robot weight changed, block out another couple hours.
The Team Captain of the second team my sons were on insisted on using mecanum wheels. He also designed an extremely stiff chassis. Since the floor is never truly flat, only 3 wheels ever had any weight on them. As the chassis moved, different wheels would have no weight on them. The motion across the field was erratic to say the least. It would probably require an IMU to correct such behaviour.
We have used Mecanum before, and are using it again, and this is always a problem that has to be overcome.
Our solution has been to use gyroscopic correction. If you are trying to drive straight, but you are actually hooking to the left, add in some rightward rotation. You can use a PID loop (see the WPILib PIDController object documentation) to set the rotation rate. It makes the robot drive a lot straight.
I got that approach from something I found in the 2014 season (my first year as a mentor) and it worked pretty well, but I don’t have a link to it. I’m sure there are good sources still out there describing it.
Reading the posts in this thread, I also see the value of the PID control on the wheel speeds themselves, and maybe I’ll try that this year. Unfortunately, we’re using PWM, which means we would have to have an encoder on each wheel. That’s 8 Dio ports. I’m not sure we can spare it, but it definitely seems like a good idea.