Mecanum Encoders
 

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

Attachment 17963
Attachment 17964
Attachment 17965

Re: Mecanum Encoders
 

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.

Re: Mecanum Encoders
 

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?

Re: Mecanum Encoders
 

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

Re: Mecanum Encoders
 

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.

Re: Mecanum Encoders
 

are you referring to the TalonSRX PDF documents I linked?

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


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?

Re: Mecanum Encoders
 

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.

Re: Mecanum Encoders
 

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.

Re: Mecanum Encoders
 

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.

Re: Mecanum Encoders
 

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?

Re: Mecanum Encoders
 

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

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.

Re: Mecanum Encoders
 

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

Re: Mecanum Encoders
 

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

Re: Mecanum Encoders
 

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

Re: Mecanum Encoders
 

Where was this documented?

Re: Mecanum Encoders
 

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

Re: Mecanum Encoders
 

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!

Re: Mecanum Encoders
 

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.

Re: Mecanum Encoders
 

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.

Re: Mecanum Encoders
 

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.

Re: Mecanum Encoders
 

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.

Re: Mecanum Encoders
 

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.

Re: Mecanum Encoders
 

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.

Re: Mecanum Encoders
 

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.

Re: Mecanum Encoders
 

So how do I account for this?

Re: Mecanum Encoders
 

http://www.chiefdelphi.com/forums/sh...60&postcount=2

Re: Mecanum Encoders
 

Thanks so much Ether, after I post this I'm going to look into a "Zero Velocity Reset" and the Kalman Filter to see if these can help me accomplish my goals.