Drivetrain.turnFor() not working as expected; turns for double the amount expected


My team was trying to use the Drivetrain.turnFor function this weekend, but noticed something very strange.

For a turnFor(90, deg), the robot would spin 180 degrees instead. We tried a few other degrees - all were doubled. They also tried to test the driveFor function to see if maybe there was something wrong with the drivetrain object that was created, but driveFor worked as expected.

There are no sensors (gyro or inertial) being used right now.

The hack would be to just divide the degrees by 2, but that is not a good coding practice.

We thought there might be something wrong with the drivetrain initialization, but it does not look incorrect. The drivetrain specs are: wheels are 4" omnis, wheel and track width are around 12" each. This the drivetrain initialization:
drivetrain Drivetrain = drivetrain(LeftDriveSmart, RightDriveSmart, 101.6*M_PI, 304.8, 311.15, mm, 1.0);

Any advice?

Without some kind of sensor (inertial, GPS, or legacy 3-wire gyro) to directly measure how far the robot has turned, the Drivetrain class has to estimate how far the motors need to spin to result in the robot turning the desired amount. This estimate will be inherently inaccurate, because there are factors that influence how far the motors need to spin that the Drivetrain class doesn’t know about:

  • What types of wheels are being used (omni vs. traction vs. some mix of the two)
  • The coefficient of friction between the wheels and the ground (which itself depends on various factors – what kind of surface the robot is sitting on, any dirt or dust on the wheels, etc.)
  • etc.

You’ve already hit on one way to correct for this: figure out some “scaling factor” to apply to the angle you want to turn that results in the robot actually turning the desired amount. Another option would be to play around with the wheelbase and track width values you passed to the Drivetrain constructor, until you get a combination of those values that behaves as desired.

These solutions will probably work OK but they aren’t ideal – for example, the required scaling factor might be different when the robot is driving on foam vs. on a hard floor, or it might change over time as the wheels pick up dirt/dust, etc. The most robust solution will be to add an inertial sensor and use the Smartdrive class.


Got it. Thank you so much for explaining!
This helps a lot!