Mecanum Encoders

[Nunez4296]

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

[Ether]

Originally Posted by Nunez4296

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.

[Nunez4296]

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?

[Ether]

Originally Posted by Nunez4296

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.c...7s%20Guide.pdf

http://www.crosstheroadelectronics.c...e%20Manual.pdf

[Nunez4296]

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.

[Ether]

Originally Posted by Nunez4296

I have seen both of those threads

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?

[Alan Anderson]

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.

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

[forbes]

Originally Posted by Ether

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

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?

[Ether]

Originally Posted by forbes

What's the best way to go about "suitably scaling"?

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