Mecanum Encoders

Could someone please explain how to utilize the encoders in our code to set the outputs of our motors?













If your encoders are connected to roboRIO:

You take the 4 outputs of the mecanum inverse kinematic computation (the desired wheel speed outputs) and you use those as the setpoint input to 4 corresponding closed-loop controllers (most teams use PID).

You use the encoder speed signals (suitably scaled) as the process_variable input to the corresponding closed-loop controllers.

You use the output from the 4 closed-loop controllers to command the 4 corresponding motor controllers.

OR…

If you are using TalonSRX motor controllers with CAN bus, and your encoders are connected directly to the Talons:

You setup the Talons for speed_control mode and send the desired wheel speeds (suitably scaled from the mec inverse kinematic computation) to the Talons.

We are using 4 Talon SRX motor controllers with the encoders wired directly to them. How would I go about implementing the speed_control mode into the code that I have written?

You didn’t affirm explicitly; can I infer you are commanding the Talons via CAN bus and not PWM?

While you are waiting for replies from LabVIEW gurus (I am not one), I recommend reading the TalonSRX User Guide, to familiarize yourself with their built-in PIDF function.

http://www.crosstheroadelectronics.com/Talon%20SRX%20User's%20Guide.pdf

http://www.crosstheroadelectronics.com/Talon%20SRX%20Software%20Reference%20Manual.pdf

I have seen both of those threads and we are using the CAN bus. I suppose 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.

We basically followed this guide (http://www.pobots.com/files/8213/5726/0394/mecanum.pdf) step by step except for the new labview updates. I would think that I need to set the speeds of the talons through PID but I’m not sure how.

are you referring to the TalonSRX PDF documents I linked?

The turning also seems to be terrible in the Holonomic Drive for Labview.

Please describe in greater detail what you mean by “terrible”.

What is your wheelbase and trackwidth?

What is your total speed reduction from motor to wheel?

How many motor(s) per gearbox?

What is the wheel diameter? (e.g. 4" 6" 8")

I would think that I need to set the speeds of the talons through PID

You set the desired speed for each motor by issuing a CAN command to the Talon for each motor. There’s probably a LabVIEW vi for this.

You must also tune the P, I, D, F parameters in the Talon’s built-in PIDF controller. Have you done that? What values did you use?

Using the built-in PID of a Talon SRX is easy for a random motor. There’s a LabVIEW example project that shows you exactly how to do it. However, it gets kind of complicated when you want to use the Drive functions. Those functions are not really designed to give values outside the -1 to +1 range to the drive motors, but the Talons in PID mode want values that match the encoder resolution. It’s also not obvious how to set the individual motors to PID mode when they’ve been opened as a 4 Motor Drive.

But it can be done. We had it working properly today (before the temporarily-mounted robot battery shifted and broke one of the encoder mounts).

Tuning a drivebase’s PID parameters isn’t trivial either. You can’t do it with the robot on blocks and the wheels spinning freely. It’s best done with the robot moving on the surface that it will actually be running on, though if you’re clever you can get started by pressing a patch of carpet lightly against the wheels to give them some load.

If your problem is primarily with the robot not going straight, you might do better to use a gyro as the feedback for a PID controlling the rotation. Our robot’s closed-loop mecanum motor speed control is not sufficient on its own to produce the desired motion, because the weight balance lets some wheels slip more than others.

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.

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.

What’s the best way to go about “suitably scaling”?

Is it as simple as running the drive wheels at full speed, getting the max encoder rate output and then multiplying our joystick values (from -1 to 1) by the max rate? Would this still work even with varying battery levels and all other factors?

[1] The setpoint and the process variable must be scaled and offset so that they are numerically equal (difference is zero) whenever the wheel is going at the commanded speed.

[2] The max (and min) setpoint command must be achievable over the range of operating conditions for which you want the closed-loop to be able to operate.

Is it as simple as running the drive wheels at full speed, getting the max encoder rate output and then multiplying our joystick values (from -1 to 1) by the max rate? Would this still work even with varying battery levels and all other factors?

If by “running the drive wheels at full speed” you mean full unloaded speed, that will satisfy [1] but not [2]. When the wheels are loaded and a command of 1 is given to some wheels, there will be no headroom for the closed-loop controller to achieve the commanded speed, and your wheel speeds will be kinematically incorrect.

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

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

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

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.

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!

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.

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.

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.