Mecanum Encoders

[Nunez4296]

Thanks for the replies. We have a gyro on the front of our mecanum chasis and coded in, however values only seem to range from 0.0-0.3. Is this normal? Also, we did believe that weight distribution among the wheels was a problem for rotation, but it seems that the wheels just are not spinning properly all-together. This might be due to a motor being inverted, I'll have to test this theory on Monday.

Also, could you explain how to either set the PID paramaters for each motor or use the gyro properly? I figured out how to set each individual PIDF for the 4 Talon SRXs in the loop so that shouldn't be a problem but only testing will tell.

[Alan Anderson]

What kind of gyro are you using, and how do you have it wired? Does it work properly when you use the LabVIEW gyro example?

For completeness, are your mecanum wheels mounted correctly? At the top of the wheel, the roller axles should point toward the center of the robot. It should look sort of like an X from above, and the rollers should sort of form an O or diamond shape on the floor. If you have them reversed, the robot will not be able to control its direction very well. It might not be able to turn in place at all, and it will very likely rotate some when you don't want it to while trying to drive straight.

[Ether]

Originally Posted by Nunez4296

it seems that the wheels just are not spinning properly all-together. This might be due to a motor being inverted, I'll have to test this theory on Monday.

It would be helpful if you would test it like this and post your results here.

[Alan Anderson]

The Talon SRX always uses raw encoder counts as its PID unit. If you want to control them in closed-loop speed mode, you have to give them set points in "encoder counts per one hundred milliseconds".

[Nunez4296]

When we meet again on Monday, I will check exactly how the wheels are mounted and post a picture. I will also check everything about the gyro. Lastly, I will post the results of that "test" of yours Ether

[jman4747]

Originally Posted by Alan Anderson

The Talon SRX always uses raw encoder counts as its PID unit. If you want to control them in closed-loop speed mode, you have to give them set points in "encoder counts per one hundred milliseconds".

Where was this documented?

[Alan Anderson]

Originally Posted by jman4747

Where was this documented?

I found it in the TALON SRX Software Reference Manual, specifically the second paragraph of section 17.1. (Quadrature) Encoder Position.

[Nunez4296]

Just as an update, I checked all wheel positions and they are mounted in the proper orientation where the rollers make an "X" towards the center. I also figured out what was wrong with the strafing/rotating. All I had to do was invert 2 motors, both of the left side mecanum wheels and the robot now can strafe, drive foward/backwards and rotate with ease. previously we could only Go forward and backward and rotate or go forward and backward and strafe. This brings up the old problem however...

Upon strafing at higher speeds, the robot spins out since the wheels don't turn at a constant speed. I have everything programmed in, the encoders, accelerometer, and gyro, I just need to know how to implement them into the code. Thanks!

[Ether]

Originally Posted by Nunez4296 on Jan24

our largest problem right now is that the robot drifts when it drives forward and backwards, and strafes. The turning also seems to be terrible in the Holonomic Drive for Labview.

Originally Posted by Nunez4296 on Jan27

I also figured out what was wrong with the strafing/rotating. All I had to do was invert 2 motors, both of the left side mecanum wheels and the robot now can strafe, drive foward/backwards and rotate with ease.

For rookie teams who might be reading this thread, you can quickly resolve problems like the above by running the test described here, and posting your results for analysis.

[Alan Anderson]

Originally Posted by Nunez4296

Upon strafing at higher speeds, the robot spins out since the wheels don't turn at a constant speed. I have everything programmed in, the encoders, accelerometer, and gyro, I just need to know how to implement them into the code. Thanks!

If the problem is mostly with the robot turning when you don't want it to, use the gyro to determine how far you're off heading and derive a "turn" correction to feed into the rotation input of the Mecanum Drive function.

[Nunez4296]

Sorry Ether, I forgot to record this but I will do it tonight.

Alan, the problem is I don't understand how to incorporate the gyro back into the code after pulling the value out.

[Ether]

Originally Posted by Nunez4296

Sorry Ether, I forgot to record this but I will do it tonight.

If it's working fine you don't need to. It's part of a troubleshooting procedure which lets you quickly determine how to correct your code and/or wiring.

[Alan Anderson]

Originally Posted by Nunez4296

Alan, the problem is I don't understand how to incorporate the gyro back into the code after pulling the value out.

The value you get out of the Gyro Get represents the direction the robot is currently facing. Can you describe for me, in specific terms, how you think a skilled driver could use that information to keep the robot facing in a particular direction while it was erratically trying to turn on its own? If you can give enough detail about what you want the robot code to do, I can tell you how to wire functions together to do it.

[Nunez4296]

The way I envisioned it, and correct me if I'm wrong, is that the gyro will capture the value of the angle that it is currently facing. This would work for any direction so that when you strafe, rather than having part of the robot swing out, the gyro will force the robot to maintain this header.

[gpetilli]

Originally Posted by Nunez4296

The way I envisioned it, and correct me if I'm wrong, is that the gyro will capture the value of the angle that it is currently facing. This would work for any direction so that when you strafe, rather than having part of the robot swing out, the gyro will force the robot to maintain this header.

One minor clarification. A gyro measures rotational velocity and the WPI API provides an integrated version, which is the change in angle from the initial starting orientation. Minor errors in velocity (gyro "drift") become big errors in angle. Usually not a big problem for 15 sec Autonomous, but many teams have added features to address this during Teleop.