So I’m trying to get the robot to automatically move to another position using two integrated motor encoders. This code runs when the user presses a button. I have run into this problem before on a completely different robot but ended up doing each action individually instead of in a single while loop.
The effect is that even though my Debugger window shows the value of the I2C sensors (which are going negative in my case), none of the motors stop when they reach the limit. The motors start at zero each time.
Here is a snippet:
bool isScored = false; //I use this because I had been playing with the conditions.
while(!isScored)
{
if(nMotorEncoder(FrontChain) > liftlimit) //limit is negative
{
motor[FrontChain] = 127;
motor[BackChain] = 127;
}
else
{
motor[FrontChain] = 0;
motor[BackChain] = 0;
}
if(nMotorEncoder(Rotator) > rotatelimit) //limit is negative
{
motor[Rotator] = 64;
}
else
{
motor[Rotator] = 0;
}
if(nMotorEncoder(Rotator) <= rotatelimit && nMotorEncoder(FrontChain) <= liftlimit)
isScored = true;
wait10Msec(10);
}
Open debugger. If you adjust your settings you should be able to see your encoder values. Maybe your encoders are going in the wrong direction,
My IMEs all run in the negative direction, so my stopping point is also negative. They work when measured separately.
From what I understand, The I2C sensors pass values down the daisy chain one at a time (I2C_1 then I2C_2), is it possible that I’m not properly adjusting for some hardware limitation?
It might be that you have your IMEs chained in the wrong order. Try switching FrontChain to I2C_2 and Rotator to I2C_1 or vice versa if they’re already set to those.
Second thing I checked. My wheels have _1, my chain _2, my rotator _3.
Can you show us how you set your limits? I don’t see that part of the code. This may not be necessary if the below comment solves it.
I do see a potential problem with how you wrote the code, and it would cause some or all motors to keep going past the limits. You call nMotorEncoder() twice each within the same loop. In general, that’s a really risky approach. Here is an example of why within your particular case, for simplicity assuming you’re already under rotatelimit:
Your liftlimit is -2000.
You enter the loop.
You check nMotorEncoder(FrontChain) and get -1999.
You set motor[FrontChain] to 127.
You set motor[BackChain] to 127.
You check and leave motor[Rotator] at 0.
Here’s the rub: you check nMotorEncoder(FrontChain) again and get -2009, so you change isScored to true.
Since isScored is true, you never repeat the loop again.
Both those motors are still set to 127.
In general, a far superior practice when you’re expecting the same values throughout a loop would be to declare two new long variables and set them equal to the nMotorEncoder() values at the beginning. You use these two variables for all your checking within the loop. Next time through the loop they get reset as it begins.
I said “in general” a couple times because sometimes you may well be expecting a value to possibly change in the middle of some loops and be checking for that. In such a case, you wouldn’t want to hold a value and check the same value repeatedly since you could never find such a change. That’s not the case here, though.