Encoder with CAN for Drive Train

[bradleybaldwin]

Hello,
During the offseason our team is trying to use mechanum wheels so we can move side to side. When we first put the wheels on the robot it moved diagonally instead of side to side. We attempted to fix this by switching from PWM to CAN and by adding encoders to each wheel. We then attempted to tune each pid controller with minimal success. Is this the best way to go about solving this problem and if it is then what is the optimal way to tune the PID controllers.

[Ether]

Hello,
During the offseason our team is trying to use mechanum wheels so we can move side to side. When we first put the wheels on the robot it moved diagonally instead of side to side. We attempted to fix this by switching from PWM to CAN and by adding encoders to each wheel. We then attempted to tune each pid controller with minimal success. Is this the best way to go about solving this problem and if it is then what is the optimal way to tune the PID controllers.

1) Can you post a picture of how you have the mecanum wheels mounted so we can look at it? This is among the most common mistakes made by teams using mecanums for the first time.

2) Are you using LabVIEW's built-in mecanum robot-drive VI, or did you use a home-brew mecanum algorithm?

3) Put the robot up on blocks and give it a sideways command. Carefully observe each wheel and note which direction it is spinning, and post your results here.

[bradleybaldwin]

Hopefully this is enough, if not I will be able to take pics Thursday. We are using Labviews Holonomic Drive, is there another config for mecanum wheels in Begin?

[Clinton Bolinger]

Wheels look correct (Can't see the 4th wheel).

Refer to this with strafing left and right:

http://www.vexrobotics.com/catalog/product/gallery/id/22135/image/26308/

-Clinton-

[Ether]

3) Put the robot up on blocks and give it a sideways command. Carefully observe each wheel and note which direction it is spinning, and post your results here.

Attached pic shows how each of the four wheels should be turning for a strafe right (slide right) command.

Picture is TOP view of robot.

Arrow inside each wheel shows direction wheel should be spinning, e.g., Front Left wheel should be spinning "forward".

[Levansic]

Do you have a gyro setup and connected to the holonomic drive?

The default for the cartesian holonomic drive is a field-centric control, meaning a forward command would move the robot away from the driver, no matter which way the robot actually faced. It sounds like you may have a drifted gyro accumulator, which makes the vi interpret your side to side commands as a diagonal movement, relative to the local coordinates of the robot.

Our robot could rotate much faster than our gyro could handle. This would "upset" the gyro accumulator, and cause the robot to move in un-intended directions. The gyro vi may need to be sent a reset signal.

On the drive wheel encoders for mechanum wheels and CAN Jaguars, good luck. We attempted to do that this year, but the onboard PID in the Jaguars was just too fragile. Maybe that's not the correct word, but is probably the most euphemistic I can muster today. Probably the best example we hit this year to illustrate the difference between theory and practice. In our case, no matter how much we practiced, we could not make it match the perfect theory. In the end, we just used %VBus, and attempted to scale our inputs so that we wouldn't approach the rotation speeds that upset our gyro.

-- Len

[bradleybaldwin]

No gyro, could this be part of the reason for the diagonal drift?

[Levansic]

It could be. I don't recall what the default value is, if the gyro input is not connected. Are you connecting a rotational control input, like a joystick twist or throttle axis?

At a minimum, I would have three joystick axes connected (X, Y, Z-rotate), and a gyro read. You can wire a joystick button to a case that encloses a gyro-reset vi, so that you can reset the accumulator at any time.

-- Len

[Ether]

No gyro, could this be part of the reason for the diagonal drift?

Do you have access to the robot?

[Greg McKaskle]

There doesn't really seem to be enough symptom to diagnose the issues. I'll just list a few things.

1. Make sure that the VI being used is Mecanum Cartesian. The Polar version is not intended for direct joystick inputs, but rather mathematically based autonomous.
2. Check the wheel orientations. The two shown clearly in the photo are correct. The other two should be the mirror image left-to-right of what is shown.
3. On blocks, check other joystick inputs and summarize the results. Observe what pure Y, pure -Y, pure X, pure -X, look like. also use the twist or rotation parameter with no X and Y.

Perhaps a bigger set of correct and incorrect results will help identify the issue.

Also, I don't believe a gyro or lack of gyro is the issue, as the VI I was looking at has no knowledge of a gyro. Perhaps there is an example that incorporates a gyro, but the default expectation seems to be a robot-centric holonomic drive system.

Greg McKaskle

[Ether]

The two shown clearly in the photo are correct.

If you look closely, the third wheel is also correct.

Putting the bot up on blocks was suggested in post2. I get the impression the OP doesn't have access to the robot until tomorrow.

[Levansic]

Also, I don't believe a gyro or lack of gyro is the issue, as the VI I was looking at has no knowledge of a gyro. Perhaps there is an example that incorporates a gyro, but the default expectation seems to be a robot-centric holonomic drive system.

I agree with all of your suggestions, but our cartesian holonomic vi had a gyro input by default. I don't doubt that there may be instances of that vi that don't have that input, but ours had a gyro terminal. I just really wish I had a few screen shots of how our code was set up.

If Bradley's vi has that terminal, he could just wire a zero constant to it, and that should force robot-centric control.

-- Len

[Greg McKaskle]

I looked again and found the gyro angle input. I was looking for a gyro refnum during the Open.

The gyro input has a default of 0 if not wired, so not wiring it shouldn't be a problem. Wiring in a changing value would cause a changing orientation, even when you were sending in 0,0,0. So that is another good vector to test on the robot.

Greg McKaskle

[bradleybaldwin]

Sorry but I won't be able to access the robot now until Friday. I will make sure to check the following though.
1. Robot Wheel orientation.
2. Wheel direction when moving sideways.
3. Wheel speed?
4. The holonomic drive code.

[bradleybaldwin]

Okay so all the wheels were in the correct orientation and they were spinning in the correct direction. The problem though was that the back two wheels were spinning slower than the front two wheels. According to the build team this is because of a gear ratio problem. If they cannot fix it what are my other alternatives?

[Greg McKaskle]

Can you measure or calculate the ratio of motor input to wheel velocity for the back and front wheels?

If so, you can try to fix it in the SW. After the vector math, the Holonomic VI updates four labeled motors. You can scale the outputs so that the wheel speeds are normalized. I'd make a copy of the VI under a new name. Note that if the ratios are very different, I suspect the nonlinearities in the drive system are going to make this way less satisfying than correcting it with a gear or sprocket change. But since it is a quick SW experiment, I'd give it a try.

Greg McKaskle

[Ether]

Okay so all the wheels were in the correct orientation and they were spinning in the correct direction. The problem though was that the back two wheels were spinning slower than the front two wheels. According to the build team this is because of a gear ratio problem. If they cannot fix it what are my other alternatives?

You mentioned that you have wheel encoders installed but had trouble getting closed-loop wheel speed control to work.

Find a nearby team that has experience with drivetrain wheel speed control using encoders.

Take the 4 wheel speed outputs from the LabVIEW Cartesian mecanum VI and use each one as a setpoint for a closed-loop wheel speed controller for the associated wheel.

It goes without saying (but I'll say it anyway): Unless you fix the drivetrain gearing issue, this will work only up to a point. Beyond a certain speed, the motors on the slower-geared wheels will not be able to generate torque. And at low speeds, the motors on the faster-geared wheels will not be able to generate as much torque as the other motors. All-in-all, a kludgey solution. Tell the mechanical team they must fix the drivetrain.