My team is having some trouble getting our robot to drive in a predictable fashion. We are a first year FIRST team, so please bear with me. We implemented Mecanum wheels with 4 CIM motors being driven by Jaguars (PWM). Our code is written in LABView.
Going forward and backward works as it should, however, when we attempt to translate left or right the robot wants to rotate about it center axis. Upon inspection of the code the joystick inputs X and Y were wired to the appropriate terminals on the holomorphic .vi (cartesian).
The symptoms that I see are that the motors are not all engaging at the same time or the same speed. I feel that we need some type of feedback control loop but I wanted to ask here before we expend that time and effort. Could it be that I am missing something? And if so, any suggestions no matter how simple or mundane will be appreciated.
James,
If you give a forward command to one side and reverse command to the other side (assuming identical throttle values) then the robot will turn on it’s center axis. If you want to turn on an axis outside of the robot, only drive forward on the side opposite the direction you want to turn. If you want to turn in an arc, simply adjust the throttle values to the two sides independently.
Do you mean it rotates instead of moving sideways, or that it moves sideways but doesn’t maintain its orientation while doing so?
What does the robot do when you command it to turn in place?
Are you certain the mecanum wheels are mounted properly? The diagonal rollers should form a diamond shape where they contact the floor; they will look sort of like an X when viewed from above. If one or more of them is backwards, the turn and strafe behavior will not be as expected.
Are you certain you have wired the speed controllers for the four motors to the proper PWM connectors? Getting a couple of them swapped would really confuse things.
Besides what Alan said, here is how we make sure the wiring and software are correct, assuming you are using 2 Joysticks for control, one for forward/backward and strafe left/right and one for rotation:
Put the robot on blocks so the wheels are free to rotate.
On the Driver Station, make sure that Joysticks 1&2 are assigned to the correct port in the Setup Tab: We prefer that the strafe Joystick is #1 and on the left, and the rotate joystick is #2 and is on the right. Click any button on the Joystick and that will tell you which one is which, and you can click and drag the joysticks to re-order if you need to.
Enable your robot with the Mecanum code running. Slowly move Joystick #1 to a small value forward and hold it there. Check to make sure all the wheels are rotating and rotating in a forward direction. If any wheel is rotating the wrong direction, either change the wires or change the motor inverts in the Begin.vi
Go forward and backward full range to verify that everything mechanical is rotating correctly without any binding.
Use Joystick #2 and rotate to the left. This should make the left side of the robot’s wheels rotate backwards and the right side move forwards. If this is incorrect your speed controller’s PWM cables or software is using the wrong motors.
From what we’ve been able to tell, if all the above steps pass the robot should strafe correctly. So put it on the floor and verify that it moves correctly still. If there is a problem with the robot now, it is more likely a mechanical issue, such as binding, wheels are not touching the ground and/or bad weight distribution.
When working on he robot last night I had it up on blocks at one point and did what you suggested. I don’t remember specifically the results so I will try again tonight and document the results. I do remember though that it seemed as though there were some wheels that lagged a little.
In that I mean that when I pushed slightly forward on the stick some wheels would begin to rotate before the others. Once all the wheels were rotating it was in the correct direction (forward) but it still seemed that some were rotating slightly faster.
I would like to think that this is a software issue rather than a hardware (electrical) or mechanical issue, but I am not sure. Do I need to add some kind of feedback to my system to have all wheels moving at the same speed?
If it is mechanical, I would suspect a problem in the gearbox or the wheels themselves. How much torque do I need to use to tighten the wheels? Should the rollers be able to spin freely, or should they have some resistance, or should they pretty much be bound up and hard to turn?
Sorry to so many questions, I just want to have as many leads as possible for my team when we meet tonight.
P.S. We know that the wheels are mounted in the correct positions, we fixed that problem last night, haha.
James,
It is also possible that the speed controllers do not match. There is a calibrate function to allow you to match joysticks to controllers. This would be the case if you are using the single joystick to drive. This can be handled in software and many teams take this approach. When performing the calibration, I recommend removing all breakers except the controller you are calibrating.
Not necessarily. If the front and back PWM controls are swapped on one side, the robot will probably just bounce in place trying to squeeze or stretch itself sideways. If they’re swapped on both sides, the robot will probably strafe in the wrong direction, and trying to turn while strafing will be very entertaining.
The first thing to do is make sure the wheels are installed in the proper orientation. The second thing is to make sure the PWM definitions in software match the wiring in hardware. Then you can determine whether or not any of the motor directions need to be inverted.
One thing that can cause that is telling the software to control a Jaguar but actually using a Victor, or vice versa. The factory default PWM “neutral” value differs between the two types of speed controller.
Should the rollers be able to spin freely, or should they have some resistance, or should they pretty much be bound up and hard to turn?
The more freely they spin, the better will be your robot’s ability to move sideways. The more resistance they have, the more force you’ll be able to apply in the forward direction before the wheels slip, but strafing will suffer. If they’re too hard to turn, you’re essentially using a bumpy and expensive traction wheel.
Okay, our rollers are pretty tight once the axles (screws) are tightened down enough so that the brass piece is touching both sides of the wheel plates. I am using the AndyMark 8" Mecanums by the way I think we will try lubing up the axles to get the rollers to spin more freely. Does anyone see a problem with this?
You’re probably gonna want to back off a bit on the axle nuts and live with a bit of free play so the rollers spin freely. For each roller, if you push the roller axially until it stops and then continue applying some axial force while trying to turn it, does it turn smoothly? Or does it bind up?
*
*
Very true Alan, I meant to put in a step for checking the correct strafing direction but I forgot apparently.
Jimbo - The “lag” you are seeing could be coming from several different sources. I would look through the Diagnostics tab Error messages and see what’s appearing there, verify you are sending the appropriate values to the Mecanum drive VI using probes/indicators. If you have other code in your project create a new default project, add only the code you need to drive and see if you still have the lag.
If that’s not an issue you may have some binding. For the wheel that is slower see what could be causing it. We had some issues with the 6" Mecanum wheels and the AM Wormbox’s due to very little clearance with the chain sliding across the mecanum plate, along with the Wormbox itself rotating towards the wheel and making the chain bind and then fall off. Only with proper bracing, alignment and spacing are we able to drive effectively, definitely not a “slap together” system.
If you can’t find the problem you can definitely post your code and pictures of your drive-train here so we can help more.
This happened for us at one time too. Look in Begin.vi and make sure that the motors are inverted correctly. Make sure both on the left side are the same and both on the right side are the same. If they aren’t, it will cause this, but will still make it go forward.
Sorry to knock you so quick, but this is not true. The invert selection in the Begin.vi is not dependent on one motor compared to another. Normally, if you have all the CIM motors wired with red+ and black- to each M+/M- terminals on each speed controller, you should not have to invert anything. The only reason that you would have to invert something is if you have your wiring reversed, which is dependent on the motor, not on which side the motor is on.
If you find that you do have to invert something and it’s not because of the wiring, something else is wrong, which may or may not result in a negative impact on the mecanum drive.
Another simple thing to check is the gain on your joysticks (if your joysticks have gain). If they’re off, things can get rather wonky rather fast. Set them to where you need them, and then hot glue them in place!
It also depends on if the gearboxes are meant for 2 CIM motors. If you have 2 gearboxes mounted opposite another, and they are both toward the back of the gearbox, one will be inverted from another. It saves space that way, so there isn’t one motor forward, and another back.
actually, I take that back. It won’t be just one motor in the gearbox.
Try this: imagine a CIM motor with a wheel directly driven by it. Command that motor to go forward and put it on the floor. Naturally, it will go forward. Now, take that motor, and without changing the code or input, flip it 180 degrees. It now will go backwards. One side of the drivetrain needs to be inverted: whether it be software or by swapping the leads on one side. If not, the robot will simply spin in a circle.
I assume most teams using Mecanum drive would have one motor per wheel. However, if they choose to use two motors attached to a gearbox usually the best solution would be to use a PWM Y Cable from the Digital Sidecar to each speed controller for that wheel module. Most dual input gearboxes in use in FRC (that I’ve seen at least) are setup to have the input gears drive the same gear in the gearbox, in which case it is important to ensure that each motor is going the same direction as the other along with the same speed (hence the Y Cable).
True, which is why you need to check the inverts in your begin, using the process outlined earlier. We don’t need to invert anything as we are using Wormbox’s and we swapped the side of the wormbox that the motor is attached to, to facilitate a symmetric layout so we are already “inverting” the output, see attached.
We have one motor per wheel, using the toughbox mini gearboxes. I didn’t think about it before but does it matter which side the motor is mounted to? (left or right, I think I can figure out if the front/back is correct, haha) I wouldn’t think that it would but it wouldn’t be the first time I assumed incorrectly.
We ran some tests last night and got all of the wheels turning in the correct direction. We calibrated each jaguar according to the Getting Started Guide, and adjusted the inverted channels so that the robot can drive correctly.
I now have a question, is there a function somewhere in the software/firmware that limits the speed or response of a motor when it is traveling in reverse? I ask this because it seems that the PWM channels that are inverted in the Begin.vi seem to lag behind the motors that are not inverted.
I have been thinking about it all night and morning and that is the only explanation I can come up with. This afternoon I will try to turn off the inversion on all channels and just hook up two of the motor leads reversed. I guess that would tell me if it is a function of the software.
Another thing, has anyone else found that the calibration procedures in the manual seem a bit minimalist? It took me several tries to calibrate the Jaguars because I did not realize there was a timeout in the calibration mode. I ended up just doing one wheel at a time, a bit of a pain, glad we only have four wheels…
The reason you are seeing some motors going faster/slower than the others may be due to how you calibrated your speed controllers. The factory calibration should work perfectly for what you are doing. The reason they offer that feature is for use in other systems, such as RC control systems where the PWM timing is non-standard. From the TI Jaguar FAQ:
Q38 Do I need to calibrate the Servo (PWM) interface?
A
It depends. The motor controller has a calibration mode, and the need to calibrate depends on the Servo
(PWM) signal range generated by the robot controller.
For FRC users, the answer is probably not if you are using the cRIO system and a new motor controller.
The default parameters of the motor controller are tuned for use with the cRIO. The calibration mode is
provided if you want to use the motor controller with another source of Servo (PWM) signal that does not
have the same range of pulse widths (for example, an older robot controller). Or, if you have calibrated
your Jaguar (MDL-BDC) from a different source and move it back to a cRIO system, you must recalibrate.
I would reset the calibration to the factory default settings (as seen here) and see if you still have this problem, along with making sure that the actual value going into the motor output in your code is going 1:-1 on each motor.