Drive Train Backlash?

Our drive train is pretty snappy this year.

We are using a NavX (and will be using cameras yet) to turn to a heading and then run a motion profile. Motion profile is within an inch and we’re content with that.

We can enter a heading such as 90deg. and the chassis will get there in a heartbeat. We are using a PID subsystem to drive one side forward and one side in reverse to basically turn on a dime. As I said, it’s quick. You can see it oscillate just a bit and then settle down. At this point we’ll typically be less than one degree of the target.

Then we run the motion profile. That’s when I think we are getting in trouble. During the turn, one side of the drive train drove forward last and the chains are tight. The other side drove in reverse and the chains will have slop in the forward direction. When we trigger the motion profile, the side that went forward last starts moving immediately. The side that went reverse last, needs to tighten the chain first and then it starts moving. This is causing a change in directions immediately when motion profile starts. The further we drive, the further we are off.

Any suggestions on how to take the backlash out? We have no idea which side is tight and which is loose. It varies from time to time. We need a way to tighten up the loose side without actually driving the side that’s tight to begin with.

Thanks ahead!

I wonder if you could just precede your “drive” commands with a low voltage to each motor in the desired direction for about half a second. That is, enough torque to “snug up the chains” without actually moving the robot.

  • During setup, are you sure you push the robot backwards into its starting position?
  • What gearbox setup do you have?
  • What wheels do you have, and are they clean?
  • Is the sequence of paths you chose the simplest-possible sequence?

Both sides are the same. Three CIM motors driving a central gear. That gear is on a hex shaft that drives two sprockets and one wheel. One of the sprockets is chained to another hex shaft driving another wheel towards the front of the bot. The other is chained to another hex shaft driving another shaft with two sprockets and drive wheel towards the back of the bot. The second sprocket on this shaft is chained to another hex shaft with a drive wheel at the back of the bot. So, four wheels per side, one drive from motor, one in front driven by chain, and two behind driven by chains.

Not sure what wheels, 4" diameter and they are clean. Rubber faced wheels. A substantial amount of rubber.

The sequences are anywhere from three to four drives with multiple turns, to a simple straight drive. The more complicated they are, the more magnified the issue becomes. But motion profile is nailing the distance. It’s the turn that seems to start the issue.

Setup is with the back of the chassis hard against the wall. We can either roll it back into the wall and go from there, or roll it into the wall and then rotate wheels in forward direction on both sides. At the end of the first motion profile drive (straight line) the corner of the bot will be within a 2" circle from one try to the next.

Then we make the turn and run another straight line profile. Now, we’ll see that 2" circle in two places about 8-10" apart with a couple of hits in between. I think that’s the final oscillation in the turn being one way or the other with a couple of outlayers in between.

I’ve wondered about applying a small amount of forward drive for a short time. Enough where it wouldn’t drive the side that’s engaged but would tighten up loose chains on the other side. If all the axles were chain driven, I think that would work. But I think the drive wheel on the main gear shaft will defeat this.

The single reduction gearbox would rule out most backlash within the gearbox (there’s always some with 20DP gears). The only thing I’d think of is to ensure the chains have proper tension and then tune down the gains for the turn.

Our side peg is pretty dead-on, maybe +/- half an inch after a forward-turn-forward sequence. If you try running things at, say, 40% power output, do the results differ? That’s the only quirk we’ve done this year that’s different from prior years. It was done at first for safety, but we found that it also prevents that initial wheel slip during initial acceleration for ‘drive straight’.

We have a similar setup (2-speed 2-reduction gearbox, 6WD, all driven Colson wheels). We run auton in low gear, which is 10.1 ft/s theoretical.

In our turning code we’re doing the PID math internally so we can set a turn timeout, margins of error (10ths of a degree), and a theoretical minimum power needed to actually turn the robot (0.05). These prevent needing high ‘P’ values (0.009…), which may be why our wheels don’t slip during the acceleration of the turn. It looks like we don’t use ‘I’, but I dunno why.

Just a note - I’m not an expert on our robot code, but I can read it since I write Java for a living. if you have questions, I can forward them to the kids.

FYI - It’s not useful to give PID values without telling people the units. Is this in volts/degree? PWM/degree? Volts/rad? It’s not very useful to know the numbers without the units, especially since different teams tend to do things differently. (voltage vs pwm, degrees vs rad, etc)

Good point. I didn’t know there was a difference in ‘P’ value units. I’m not sure how they derived their values outside of a lot of tuning.

The basic math is “output = KP * error …”, and error is in degrees. We then call the CANTalon.set(output) method after a bit of logic on the ‘output’ value (mode is PercentVBus). Error comes from the NavX’s AHRS.getAngle() method, and then some math to clamp it from 0 to 360. I’d have to dig into it more to explain it further.

So - volts / degree?