Encoder with CAN for Drive Train
 

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.

Re: Encoder with CAN for Drive Train
 

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.

Re: Encoder with CAN for Drive Train
 

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?

Re: Encoder with CAN for Drive Train
 

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

Refer to this with strafing left and right:

http://www.vexrobotics.com/catalog/p...5/image/26308/

-Clinton-

Re: Encoder with CAN for Drive Train
 

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

Re: Encoder with CAN for Drive Train
 

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

Re: Encoder with CAN for Drive Train
 

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

Re: Encoder with CAN for Drive Train
 

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

Re: Encoder with CAN for Drive Train
 

Do you have access to the robot?

Re: Encoder with CAN for Drive Train
 

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

Re: Encoder with CAN for Drive Train
 

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.

Re: Encoder with CAN for Drive Train
 

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

Re: Encoder with CAN for Drive Train
 

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

Re: Encoder with CAN for Drive Train
 

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.

Re: Encoder with CAN for Drive Train
 

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?