RobotC Error with variable definition and IME?

VEX V5 Technical Support UNOFFICIAL Tech Support
#1

Hey everybody, I’ve been mulling over an odd error with my code for my robot arm. The section of my code dealing with automatic movements for the roll joint aren’t working. Essentially, I copied the code from the other joints (which do seem to be working, but use pots instead of an IME), but one of the variables doesn’t seem to want to be “defined”. What is weird is that I define it and am able to use it a number of times without getting an error message (though not working in execution), but when I try to use said variable to update the “error value” of the movement, it gives a “variable undefined, short assumed” compiler error.

In the following code segment, “desiredEncvalue” is used to represent where the joint is trying to get to. It generates no errors up until it is used to redefine the variable for error, at which point, the compiler thinks it hasn’t been defined yet.


task moveRoll()
{
	if(robotHomed==true) //roll only moves once the robot is homed.
	{
		//where the joint is
		int currentEncValue = nMotorEncoder(rollMotor);
		//where the joint is going
		int desiredEncValue = ((targetPosition.rollDeg*rollEncoderConversion)+rollEncoderBaseline);
		//if the target is in appropriate range
		if((desiredEncValue < 2400)&&(desiredEncValue > -10))
		{
			if(desiredEncValue > currentEncValue)
			{
				//then increase enc until equal to target
				while(nMotorEncoder(rollMotor)<(desiredEncValue-rollEncoderError))
				{
					startMotor(rollMotor, 27);
				}
				stopMotor(rollMotor);

			}//if targetEncValue greater than to currentPotValue
			else //else if the targetEncValue is less than the currentEncValue
			{
				while(nMotorEncoder(rollMotor)>(desiredEncValue+rollEncoderError))
				{
					startMotor(waistMotor, -27);
				}//while
				stopMotor(waistMotor);
			}//else if target less than current
		}//if target in range
	}//if robot homed

	rollEncoderError=desiredEncValue-nMotorEncoder(rollMotor);
	rollMoveDone=true;


}//moveRoll

It’s kind of weird. The whole thing boggles my mind. My code for homing the wrist encoder works fine:


void goHome()
{
	//moves robot to home position. Wrist and LSB will not move yet since encoders haven't been homed.
	//basically, this folds the arm into a good position so it can safely move
	//the wrist and LSB without obstruction.
	movePos(positionHome);

	//runs wrist motor until the reset switch is tripped.
	while(SensorValue[rollLimitReset]!=1)
	{
		startMotor(rollMotor, -27);
	}//until the limit switch is tripped
	stopMotor(rollMotor);

	//reset rollMotorEncoder
	nMotorEncoder(rollMotor)=0;

	//move wrist to baseline
	while(nMotorEncoder(rollMotor)<rollEncoderBaseline-rollEncoderError)
	{
		startMotor(rollMotor, 27);
	}//while encoder is less the baseline corrected for error.
	stopMotor(rollMotor);

	/*put lsb homing code here*/

	//change bool for robotHomed to true to unlock normal movements
	robotHomed = true;
}//goHome

Any insights would be appreciated greatly.

#2

It’s a scope issue. The variable is defined within the braces.

This, for example, will give an error.


task moveRoll()
{
    if(robotHomed==true)
        {
        int desiredEncValue = 10;
        }

    desiredEncValue=20;	
}

Whereas this will work.

task moveRoll()
{
    int desiredEncValue = 10;
	
    if(robotHomed==true)
        {
        // some code
        }

    desiredEncValue=20;	
}

google C++ scope (an example using {} to create scope )

#3

Thanks for the reply. That got rid of that particular error. I knew there had to be something missing, and it never occurred to me that I was declaring it inside the if statement and that meant it could only be used inside that if statement. Good to know.

I have been playing around with the robot a bit since I posted and I actually got the normal move command to work properly for the first two positions (0 and 45), but it refuses to move to the third position (-45).

However, the biggest thing on my priority list has to do with the waist joint, which has decided to be a giant pain in my butt lately. Essentially, the waist joint has a large amount of play in it in the unavoidable gear reduction after the worm gear. Because of the weight of the wires as the base rotates, pressure is placed on the waist which makes it highly inaccurate and makes it bounce as it rotates. Furthermore, for some reason, on the move from position 2 to position 3, it has decided that it wants to turn in the wrong direction >_< this is using the same task as the other movements which both worked correctly.

#4

Hard to say without seeing the code but it sounds like an overflow issue or something like that.

#5