[FTC]: One Encoder Works; The Other Ones Does Not

[F Elliott]

Hi Everyone --- Rookie coach is stumped...


We're trying to use our encoders. motorD seems to be controlled but motorE acts as if it is not being controlled.

Using the code below, MotorD turns 1/4 revolution at what appears to be 50% power. MotorD seems to behave as expected if you change its values for nMotorEncoderTarget[motorD] or motor[motorD]. On the other hand, MotorE ALWAYS runs at 100% power and ALWAYS turns several full revolutions before it stops when it finally reaches the set target value (negative) as seen in the NXT Device Control Display debugger window. If you change motorE's power setting it is ignored.

Both encoder wires are plugged into the motor controller so the orange wire faces the motor controller's lettering and are plugged into the motors so orange is left-most when looking at and reading the label on the motor. We have tried swapping motor controllers, the encoder cables, and we've hooked up motorD as mtr_S1_C1_2 and motorE as mtr_S1_C1_1 all with the same result. It does not matter which motor is reversed in the pragma. I've opened up the encoder on motorE and it seems to be installed correctly. We have not swapped the encoders because that would entail pulling off the encoder wheels, which I'm not ready to do.

Any suggestions most appreciated!

#pragma config(Hubs,  S1, HTMotor,  none,     none,     none)
#pragma config(Sensor, S1,     ,               sensorI2CMuxController)
#pragma config(Motor,  mtr_S1_C1_1,     motorD,        tmotorTetrix, PIDControl, encoder)
#pragma config(Motor,  mtr_S1_C1_2,     motorE,        tmotorTetrix, PIDControl, reversed, encoder)
//*!!Code automatically generated by 'ROBOTC' configuration wizard               !!*//

task main()
{
  nMotorEncoder[motorD] = 0;
  nMotorEncoder[motorE] = 0;
  nMotorEncoderTarget[motorD] = 720;	//Gearing ratio is 1:2 so one revolution is 2880 encoder ticks
  nMotorEncoderTarget[motorE] = 720;  //@720 ticks both wheels should turn 1/4 revolution
  motor[motorD] = 50;
  motor[motorE] = 50;

  while (nMotorRunState[motorE] != runStateIdle || nMotorRunState[motorD] != runStateIdle)
  {
  }
  
  motor[motorD] = 0;
  motor[motorE] = 0;
  wait1Msec(3000);
}

[F Elliott]

I've done some more online research... This is exactly our problem and first surfaced about a year ago:
http://www.robotc.net/forums/viewtop...=2774&start=15

It was supposedly fixed in ROBOTC 3.54. We are running ROBOTC 3.62

Also, the order of powering up the motor controller and the NXT seems to be important. We are using this order:
1. Power up 12v to motor controller
2. Power up NXT
3. Download and run program

[FTC4211]

Hello,

Here is the code that we use for moving motors to a position. We have had problems non-stop with the built in RobotC nMotorEncoderTarget function so we wrote our own.

Here it is written to do what your code was supposed to do:

#pragma config(Hubs,  S1, HTMotor,  none,     none,     none)
#pragma config(Sensor, S1,     ,               sensorI2CMuxController)
#pragma config(Motor,  mtr_S1_C1_1,     motorD,        tmotorTetrix, PIDControl, encoder)
#pragma config(Motor,  mtr_S1_C1_2,     motorE,        tmotorTetrix, PIDControl, reversed, encoder)
//*!!Code automatically generated by 'ROBOTC' configuration wizard  

typedef enum
{
Quintic = 5, // good for very light loads with no backlash/gears: very fast

Cubic = 3, // good for light loads with minimal backlash in the gears: faster near its target but can overshoot the target

Linear = 1, // good for most loads on motors: good average, try starting with this one

CubeRoot = (1/3), // good for heavy loads with backlash in the gears: slow near its target

QuinticRoot = (1/5) // good for very heavy loads with lots of backlash in the gears: slow near its target
}tMotorPowerCurve;  // motor power curve applications: test to find the best for your application

int trim(int num, int min, int max) // clips @param 'num' to be within within min/max values
{
return (num>max) ? max : (num<min) ? min : num;
}

int targetLocationToMotorPower(tMotor nMotor, int targetPos, short deadband, float speedMultiplier, short minPower, short maxPower, tMotorPowerCurve powerCurve=Linear)
{
int iPower;
if (abs(nMotorEncoder[nMotor]-targetPos)<deadband)
{
iPower=0;
}
else
{
iPower = pow((-(nMotorEncoder[nMotor]-targetPos)),(float)powerCurve)*(float)speedMultiplier;
}
return trim(iPower, minPower, maxPower);
}

bool moveMotorToPosition(tMotor nMotor, int targetPos, short deadband=20, float speedMultiplier=1.0, short minPower=-50, short maxPower=50, tMotorPowerCurve powerCurve=Linear) // return true if at target
{
int power = targetLocationToMotorPower(targetPos, nMotor, deadband, speedMultiplier,minPower,maxPower,powerCurve);
motor[nMotor]= power;
return power == 0; // if power = 0 then at target
}

task main()
{

nMotorEncoder[motorD]=0;
nMotorEncoder[motorE]=0;
while (!moveMotorToPosition(motorD, 720)||!moveMotorToPosition(motorE, 720))
{
}
wait1Msec(3000);
}

We have different power curves for the target to motor power function because we found that depending on load and backlash in certain applications a single power curve could cause oscillations. We have used this method for controlling everything from arms to our drive base with great success.

Play around with this code and see what settings work the best.

Best of luck,
Team 4211

[F Elliott]

Wow. Terrific! Many thanks!