Normalizing motor speeds using Arcade Drive in Labview

Working on the 2009 robot and we notice that the left drive motor starts turning sooner than the right motor. So, using Labview and Arcade Drive, we are trying to make both motors go at the same time.

Looking at the Open 2 Motors vi, it looks like there is a TransformRef buried down in the RobotDriveDevRef that looks promising, or maybe the deadband, which also looks promising. We tried using these without much success of even figuring out how to modify the values.

So, looking for some thoughts or clues of the best way to solve our problem.

Thanks

The first thing I’d do is determine if it is a problem with the joystick values being skewed, or whether it is downstream. If you build a quick autonomous routing that sets the joystick to a known value with no X value, does the left side lead the right? If so, the problem probably has to do with either friction or binding on the right side. If that fixes it, then the problem is that straight forward on the joystick doesn’t really mean straight, and the deadband or other transform sounds like a good fix.

If you open up the Drive Open VI, you’ll see that it creates the Motors with squaring on and without transforms. You can Save As to your own copy and wire up some VI Refs for a transform or otherwise modify the open.

Another interesting thing to do may be to insert a chart into your teleop loop showing the last few hundred X and Y values from the joystick. This could diagnose a bad joystick or train a jittery driver by giving feedback.

Greg McKaskle

Also make sure that the speed controllers on each side are properly calibrated.

Great ideas, I will follow through on both.

Jared,
How do you calibrate the speed controllers?

Have you verified that mechanically, each side of the drivetrain has similar amounts of friction? Many times I’ve found that to be the problem. Simply turning the wheels by hand may uncover something.

Are you using victor or jaguar speed controllers? You’ll get better results with a jaguar. If you look at the Jaguar and Victor transfer characteristics, you’ll see two things about the Victor that hurt you. First, the center point is offset from where it should be (1.5 ms). This year’s code works around this by offsetting the center point to a value that works for most victors, however there is a unit to unit variation. Calibrating them may help also. Instructions for calibrating either the Victor or Jaguar are in their respective manuals. Finally, the sharp increase at low PWM values hurts the victors here, because a small difference there makes a big difference in speed.

There is an example for the TransformRef in the LabVIEW examples. I don’t have LabVIEW in front of me, but I think it was fairly obvious.

This year, for the first time, we had a robot that drove perfectly straight for 30 feet, using no feedback, thanks in large part to the Jaguars.

Great feedback, thanks for that Joe. I will definitely check out the friction issues and also grab the manual for some Jaguar tuning. We are using Jaguars on both motors

There’s a place to select either Jaguar or Victor when you open the drive reference. Make absolutely sure you’re telling the code that you’re using Jaguars. The Victor workaround mentioned by Joe Ross makes Jaguar-controlled motors spin one direction faster than the other if you set it wrong.

wha! That’s almost exactly what we were seeing when we started working on the code… OK, first thing to check when I get back to the code

First off, appreciate all the help.

The problem ended up being a loose electrical connection to the motor and a slight binding problem in the gear box.

Once we fixed all that, everything is looking good.

Funny how as the team’s programming mentor, the first place I turn to is code. I should know better and will check my premises next time.

Sounds like a software problem to me…:stuck_out_tongue:

(Spoken like a true hardware guy)