Help with RobotC

Hey everyone,

We are trying to set different channels of buttons to a single set of motors. One set of buttons would be full power, the other half power. However, whenever we try to do this, both channels end up causing the motors to run at half power and also stutters.

The program currently looks like this:

if (vexRT[Btn6U] == 1)
{
motor[arm] = 127;
}
else if (vexRT[Btn6D] == 1)
{
motor[arm] = -127;
}
else
{
motor[arm] = 0;
}

if (vexRT[Btn8U] == 1)
{
motor[arm] = 63;
}
else if (vexRT[Btn8D] == 1)
{
motor[arm] = -63;
}
else
{
motor[arm] = 0;
}

Thank you!

In the first set of if/else you switch your motor to zero. Then you do another check. That might explain your stuttering. Why not have them all in one conditional:

if (vexRT[Btn6U] == 1)
{
    motor[arm] = 127;
}
else if (vexRT[Btn6D] == 1)
{
    motor[arm] = -127;
}
else if (vexRT[Btn8U] == 1)
{
    motor[arm] = 63;
}
else if (vexRT[Btn8D] == 1)
{
    motor[arm] = -63;
}
else
{
    motor[arm] = 0;
}

@Ashwin Gupta

My goodness not sure why we didn’t even think of doing that! We will try tomorrow and post updates of our results. Thank you!

no problem, LMK how it goes. Just to clarify (I realize my explanation was a bit unclear), one of the following happens every time you press a button:

  1. You are pressing a button in the 6 quadrant, but the motor value is immediately reset to zero by the else in the next set of conditionals because you aren’t pressing any 8 quadrant buttons

  2. You are pressing a button in the 8 quadrant, but the motor was already on zero before, and will be reset to zero with the next iteration of the main while loop in the first conditional before being set to the correct value again in the second conditional.

Either way, not the intended behavior (or so I assume). Best of luck.

Ahh. The infamous motor jitter!

Another way of going about fixing this is to only assign a variable to be the output of the arm motors, then update the variable periodically and assign the appropriate motors to the variable at the end of your loop. I documented the implementation of this here (shameless self-plug).

You code could be adapted to something similar to this: (in the context of a competition template)


// This is just to allow us to update 
// the motor config at any time without
// having to make major changes.
bool powerArm(char powerValue) {
	motor[arm] = powerValue;
	return false;
}

task usercontrol()
{
  // Define a variable we can use to
	// hold the current value and initialise it.
	char armPowerValue = 0;

  while (true)
  {	
		// Do our motor control operations here.
		if (vexRT[Btn6U] == 1)
		{
			armPowerValue = 127;
		}
		else if (vexRT[Btn6D] == 1)
		{
			armPowerValue = -127;
		}
		else if (vexRT[Btn8U] == 1)
		{
			armPowerValue = 63;
		}
		else if (vexRT[Btn8D] == 1)
		{
			armPowerValue = -63;
		}
		else
		{
			armPowerValue = 0;
		}
		
		// Send the decided value to the motors
		powerArm(armPowerValue);
		
		// Don't hog the CPU
		wait1Msec(20);
  }
}

@EvolvingJon do both of these solutions work as well as the other? It does look like having that would be a good failsafe for stuttering (if what we’re thinking is correct).

@Ashwin Gupta got it. Hopefully all goes well!

The reason I developed the above was to able to provide it to students who were developing more complex code for the Robots to be able to write it in such a way that they should never have issues with Jitter and that can easily be expanded to use control algorithms (Like PID). It’s very easy to write Jitter-prone code once your complexity increases.

In this respect, doing the above is more robust - primarily because it ensures you only set it once per loop. However, the first solution suggested by @Ashwin Gupta is perfectly viable as long as you ensure you connect statements that address the same motor(s) and you properly handle any edge cases (such as addressing a single motor).

When the code gets more complicated your technique will make it incredibly hard to debug. And in your case only pressing 6U will result in 0 power for the exact same reason the OP had an issue.

I stand corrected. I have made the applicable changes to the above code. I mean either way, there is going to be an issue because we are using multiple statements to address a single motor (or variable).

@Ashwin Gupta it worked out well, thanks!

@EvolvingJon definitely gonna keep that code in mind (gonna have the next team try it out).

cool glad to hear it.

@Molokai Robotics Also, take a look at this post.
https://vexforum.com/index.php/conversation/post/123070

@jpearman got it thanks!

Got another issue -

Trying to use Natural Language for Autonomous but running into problems getting it to work properly. Looks like this:
{

forward(360, degrees, 63);

wait1ms(1000);

sensor[rightencoder] = 0;
sensor[leftencoder] = 0;

turnleft(125, degrees, 63);

wait1ms(1000);

sensor[rightencoder] = 0;
sensor[leftencoder] = 0;

}

The robot won’t function properly after the initial forward movement.

Sorry, a bit of a noobish question considering its Natural Language (we’re actually able to get it running properly the long way but want to condense our code).

The motors and sensors are set up with left and right drives set to a single encoder each.

Thanks again!

Update:

Robot is having issues with Autonomous. We are using the Competition Template and cannot seem to get the robot to do anything besides go forward constantly. Any ideas?

I’d advise you start a new thread, its a different topic. In the new thread, please post your auton and pre-auton code.

@Ashwin Gupta will do! Just wanted to make sure we don’t add unnecessary clutter to the forums.