Encoder with CAN for Drive Train

[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]

Originally Posted by Greg McKaskle

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]

Originally Posted by Greg McKaskle

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]

Originally Posted by 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?

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.