We were driving our robot like normal, and all of a sudden the motors started staggering. What i mean by this is the motor power is going on and off constantly. We have swapped batteries 3 times and also swapped remote batteries. Does anybody have any solutions??
Sounds like it could be a programming issue. I have seen that when you give conflicting commands to the motor - such as setting it to zero in one place and telling it to power on in another. This typically happens with if then statements.
#pragma config(Motor, port2, leftMotor1, tmotorVex393_MC29, openLoop, reversed)
#pragma config(Motor, port3, leftMotor, tmotorVex393_MC29, openLoop)
#pragma config(Motor, port6, claw, tmotorVex393_MC29, openLoop)
#pragma config(Motor, port7, arm, tmotorVex393_MC29, openLoop)
#pragma config(Motor, port8, rightMotor1, tmotorVex393_MC29, openLoop, reversed)
#pragma config(Motor, port9, rightMotor, tmotorVex393_MC29, openLoop, reversed)
//*!!Code automatically generated by 'ROBOTC' configuration wizard !!*//
#pragma platform(VEX2)
// Select Download method as "competition"
#pragma competitionControl(Competition)
//Main competition background code...do not modify!
#include "Vex_Competition_Includes.c"
#define left false
#define right true
const sbyte leftSpeed]={127};
const sbyte rightSpeed]={127};
//const sbyte armSpeed]={0};
const sbyte clawSpeed]={0,127};
const long time]={3780,789};
//const byte size=2;
//const bool State = 1;
void setMotorSide(bool side, sbyte speed){
if(side){
motor[rightMotor]=speed;
motor[rightMotor1]=speed;
}else{
motor[leftMotor]=speed;
motor[leftMotor1]=speed;
}
return;
}
void pre_auton()
{
bStopTasksBetweenModes = true;
// Set bDisplayCompetitionStatusOnLcd to false if you don't want the LCD
}
task autonomous()
{
setMotorSide(left,127); //go forward
setMotorSide(right,127);
sleep(2000);
motor[arm]=127; // raise arm
sleep(250);
motor[arm]=-127; //lower arm
sleep(250);
motor[claw]=100; //drop cone on mobile goal
setMotorSide(left, -127); //drive backwards
setMotorSide(right, -127);
sleep(500);
/*for(byte X=0; X<size; X++){
setMotorSide(left,leftSpeed[X]);
setMotorSide(right,rightSpeed[X]);
motor[claw]=clawSpeed[X];
delay(time[X]);
*/
}
//setMotorSide(left,0);
//setMotorSide(right,0);
//while(true){
//;
//}
//}
task usercontrol()
{
while (true)
{
if(vexRT[Btn7U] || vexRT[Btn7D] || vexRT[Btn7L] || vexRT[Btn7R] || vexRT[Btn6U] || vexRT[Btn6D] || vexRT[Btn5U] || vexRT[Btn5D]){
if(vexRT[Btn7U]){
setMotorSide(right,127);
setMotorSide(left,127);
}
else{
setMotorSide(right, 0);
setMotorSide(left, 0);
}
if(vexRT[Btn7D]){
setMotorSide(right,-127);
setMotorSide(left,-127);
}
else{
setMotorSide(right, 0);
setMotorSide(left, 0);
}
if(vexRT[Btn7L]){
setMotorSide(right,127);
setMotorSide(left,-127);
}
else{
setMotorSide(right, 0);
setMotorSide(left, 0);
}
if(vexRT[Btn7R]){
setMotorSide(right,-127);
setMotorSide(left,127);
}
else{
setMotorSide(right, 0);
setMotorSide(left, 0);
}
if(vexRT[Btn5U]){
motor[arm]=127;
}
else{
motor[arm]=0;
}
if(vexRT[Btn5D]){
motor[arm]=-127;
}
else{
motor[arm]=0;
}
if(vexRT[Btn6U]){
motor[claw]=127;
}
else{
motor[claw]=0;
}
if(vexRT[Btn6D]){
motor[claw]=-127;
}
else{
motor[claw]=0;
}
setMotorSide(left,((vexRT[Ch3] + vexRT[Ch4])/2));
setMotorSide(right,((vexRT[Ch3] - vexRT[Ch4])/2));
motor[arm]=vexRT[Ch2];
motor[claw]=vexRT[Ch1];
}
}
UserControlCodePlaceholderForTesting();
}
This is our code, i dont see anything wrong with it.
We usually call that “jittering,” but I’ve sometimes heard it called “stuttering.”
I’d check programming if that’s fairly straightforward to do. See if the problem follows the code to another robot.
After that, if you’ve changed to freshly charged batteries, you should start looking at wiring. Very often, this is from an intermittent connection. This can be between a y-cable and the motor controllers, or between the motor controllers and the motor.
My daughter’s team has had three odd instances of that problem this season. The first time it turned out to be a y-cable with one bad socket on one of the ends. A few weeks later, it was a used extension wire that had apparently been placed under a bit of stress in a previous installation. There was no visible break in the insulation and the wire showed continuity. But apparently some of the strands in the multi-stranded wiring were broken. She was able to show that the problem followed the extension wire. That is when she moved the wire to a different mechanism (tower vs mobile goal lift) the jittering action moved to the new subsystem. Replacing the wire fixed the problem.
The third instance happened after a few competitions. It turned out to be that the output wires were starting to separate from a motor controller. They never broke completely, and the motor controller will still operate a motor. Unless it is under a load, then it “jitters.” Replacing the motor controller fixed the problem.
Hmm. All our wires have hear shrink to protect them, so i will come back tomorrow.
You appear to be using buttons to control the drive as well as using the analog stick. This will cause jittering if you are pressing any of the
VexRT[Btn7x]
. Try removing the drive using buttons code and see if the issue disappears.
Edit: spelling
You should check the code first. Looks like you’ve got multiple things changing the drive motors.
Easy fix. We had this exact problem last year when we were programming our holonomic chassis. As mentioned above, your code is inadvertently turning the motors on & off quickly, resulting in jittering.
You already have your button code in a giant if-statement; now you need to put all your joystick code into an else-statement, like so.
while(true) {
// button section
if(vexRT[Btn7U] || vexRT[Btn7D] || vexRT[Btn7L] || vexRT[Btn7R] || vexRT[Btn6U] || vexRT[Btn6D] || vexRT[Btn5U] || vexRT[Btn5D]) {
// all the code you have from above for these buttons
}
// joystick section
else {
setMotorSide(left,((vexRT[Ch3] + vexRT[Ch4])/2));
setMotorSide(right,((vexRT[Ch3] - vexRT[Ch4])/2));
motor[arm]=vexRT[Ch2];
motor[claw]=vexRT[Ch1];
}
} // end of while(true)
This way, if someone is pressing a button, then it will not check the joysticks, and hence not turn them on & off repeatedly.
The last thing to consider is precedence: if someone is pressing a button AND moving the joystick, which should actually happen? The way you’ve got it now, the buttons are the primary; if you would ilke the joystick to be primary, just switch the if- and else- content.
In addition to what BigLeslieP is pointing out, you have another problem:
if(vexRT[Btn7U]){
setMotorSide(right,127);
setMotorSide(left,127);
}
else{
setMotorSide(right, 0);
setMotorSide(left, 0);
}
if(vexRT[Btn7D]){
setMotorSide(right,-127);
setMotorSide(left,-127);
}
else{
setMotorSide(right, 0);
setMotorSide(left, 0);
}
if(vexRT[Btn7L]){
setMotorSide(right,127);
setMotorSide(left,-127);
}
else{
setMotorSide(right, 0);
setMotorSide(left, 0);
}
if(vexRT[Btn7R]){
setMotorSide(right,-127);
setMotorSide(left,127);
}
else{
setMotorSide(right, 0);
setMotorSide(left, 0);
There are four buttons involved: 7U, 7D, 7L, and 7R. Instead of thinking about the state of each button independently, when they are controlling the same motors, you must think about them in aggregate. For example, When 7U=0, 7D=0, 7L=1, and 7R=0, in the 7U if statement, you are commanding the motors off “setMotorSide(right,0); setMotorSide(left,0)” Same with7D, and 7R. However, with the 7L if statement, you are commanding them on. So you are giving the motors conflicting commands.
One way to fix it is to make one big else/if statement.
If Btn 7U
Else if Btn 7D
Else if Btn 7L
Else if Btn 7R
Else if … setMotorSide(right,0); setMotorSide(left,0)
Then they won’t all conflict with each other.
You’re going to have the same problem with your arm and claw.