Gyro with Labview to drive straight

Hello all,

We are in need of help for implementing a gyro to drive our robot straight for a certain amount of time. (in auto mode)

Any ideas/help?

Zero the gyro when the bot is facing in the desired direction.


If the gyro says that your bot is facing slightly clockwise from the desired direction you need to increase the speed of the right wheels and decrease the speed of the left wheels.

If the gyro says that your bot is facing slightly counterclockwise from the desired direction you need to increase the speed of the left wheels and decrease the speed of the right wheels.

There are many different ways to do this. You can either invent your own or search around for ideas.

Here’s one way to do it with a skid-steer vehicle.

Here’s one way to do it with a 3DoF vehicle.

Would a PID be something we’d use?

A PID would be something you could use.

Other closed-loop control methods might work too. Has anyone tried Take Back Half for this application?

From my experience, a simple proportional control system is adequate to drive a robot straight, at least in an FRC application.

I’ve written the code to drive a robot straight with a TBH Controller. Unfortunately I haven’t had time to test it on an actual robot.

If you could remember to come back and post your results when you have had a chance to test it, I think that would be useful info.

We usually use an I controller for straight driving. It’s essentially an ‘adaptive drift constant’ in our application, as it finds a ‘drift bias’ between the two sides but it’s treated as a constant to the rest of the distance based controls.

The integral eventually finds a happy place which causes the robot to drive straight, and holds it indefinitely. We also have some speed adaption of the output, so the same integral keeps the drive straight at various output speeds, and we inhibit the control loop (but latch the integral) at low speeds. We also hold the integral between runs of the function, so multiple drive steps can keep the integral. If we were really smart we would store the integral over power cycles, but we don’t.

If the gain is good, it can come out of a turn with quite a lot of error (I tested it to around 15 degrees), and come back to the correct heading very quickly. Past a certain error the control loop was unstable, we did not worry about it because our turns were more reliable than the unstable threshold. But, you should take up turn error in the turn function, not the straight function.

In our 2012 robot, we used a simple proportional control system to turn the robot on heading. It uses a higher power level to turn close to the desired heading, and then lowers the power to avoid overrunning the desired heading. We also had a tolerance around the desired heading of a couple degrees where we considered the robot to be on heading.

All of the constants here are values you will need to determine experimentally.

Initialize at start of turn:

start_heading = current gyro heading
goal_heading = desired heading (calculated from your desired turn and the start heading)

Each loop:

turn_rate = 0 (this ranges from -1 to 1 and is the desired power to drive train)
current_heading = current gyro heading
angle_difference = current_heading - goal_heading

// angle_difference here might be positive or negative, indicating a turn in either direction

If (abs(angle_difference) > 10) then
turn_rate = .7
// when the angle difference is > 10 degrees, turn at .7 power.
Else if (abs(angle_difference) > 3 and abs(angle_difference) < 10)
turn_rate = .6
// when you are within 10 degrees of desired heading, turn at lower
// power to prevent overrunning the desired heading
// Consider heading within 3 degrees of desired heading to be on heading
turn_rate = 0

// Motor inputs

// Depending on your motor configuration and how the gyro is mounted, you may need to reverse the motor controls.

If (angle_difference > 0) then
turn_right(turn rate)

That’s actually really interesting. The Take-Back-Half (TBH) algorithm is actually a form of Integral control, so it may work well for this application.

Ended up using this method but adapted for LabVIEW…works great.

We did this since we aren’t using encoders