Help with auton (i am very confused)

I have been writing code for over 6 years now and i am completely confused at what is wrong with our auton. We have gotten to the point where we are unable to have an auton because, first of all NOTHING RUNS although the code is perfectly formatted and was checked by everyone on my team, or the immediately after auton when we go into driver as soon as you make any movement with the controller everything disconnects from our controller, and that continues to occur through out the match so you are unable to move at all. I have gotten to the point where I removed all my PID and Slew rate to prevent any sort of error. You can imagine how frustrating this is as Ive spent tons of hours writing extremely complex code but Im unable to run any of it due to all the errors that we’ve been viewing in our competitions. I’ve provided my code below from our last competition. If anyone can provide me with an answer as to why it runs auton the way it does and why it screws up when ever we have an auton thatd be great.

(please remember it only disconnects when there IS an auton)

The auton you will see is a short auton we wrote in the finals at the last competition we went to run into another team’s auton. It is the reason we lost the match for the auton didn’t run at all and afterwards during match play everything continued to disconnect and freeze up.

#pragma config(Sensor, in1,    Lift,           sensorPotentiometer)
#pragma config(Sensor, in2,    Gyro,           sensorGyro)
#pragma config(Sensor, in3,    Auton,          sensorAnalog)
#pragma config(Sensor, dgtl2,  LeftDrive,      sensorQuadEncoder)
#pragma config(Sensor, dgtl4,  RightDrive,     sensorQuadEncoder)
#pragma config(Sensor, dgtl7,  Solenoid1,      sensorDigitalOut)
#pragma config(Motor,  port1,           FL,            tmotorVex393HighSpeed_HBridge, openLoop, driveRight)
#pragma config(Motor,  port2,           LBR,           tmotorVex393_MC29, openLoop, reversed)
#pragma config(Motor,  port3,           BL,            tmotorVex393HighSpeed_MC29, openLoop, driveLeft)
#pragma config(Motor,  port4,           LBL,           tmotorVex393_MC29, openLoop, reversed)
#pragma config(Motor,  port5,           RBR,           tmotorVex393_MC29, openLoop, reversed)
#pragma config(Motor,  port6,           LTL,           tmotorVex393_MC29, openLoop, reversed)
#pragma config(Motor,  port7,           RBL,           tmotorVex393_MC29, openLoop)
#pragma config(Motor,  port8,           RTR,           tmotorVex393HighSpeed_MC29, openLoop)
#pragma config(Motor,  port9,           BR,            tmotorVex393_MC29, openLoop, reversed, driveRight)
#pragma config(Motor,  port10,          FR,            tmotorVex393HighSpeed_HBridge, openLoop, driveLeft)
//*!!Code automatically generated by 'ROBOTC' configuration wizard               !!*//

#pragma platform(VEX2)
#pragma competitionControl(Competition)
#include "Vex_Competition_Includes.c"

#define     JOY_DRIVE_V     vexJSRightV
#define     JOY_DRIVE_H     vexJSRightH
#define     JOY_THRESHOLD   10


void pre_auton() //RESETS A FEW SENSORS
{
	bStopTasksBetweenModes = false;
	SensorValue[LeftDrive] = 0;
	SensorValue[RightDrive] = 0;
}






task Claw ()
{
	while(true){
		if (vexRT[Btn5U] == 1){

			SensorValue(Solenoid1) = 0;


		}
		else if (vexRT[Btn5D] == 1){

			SensorValue(Solenoid1) = 1;


		}

	}
}








task ArcadeDrive() //THE SINGLE LEFT JOYSTICK DRIVE FOR PRIMARY CONTROLLER
{
	int    ctl_v;
	int    ctl_h;

	while( true )
	{
		ctl_v = vexRT JOY_DRIVE_V ];
		ctl_h = vexRT JOY_DRIVE_H ];

		if( (abs(ctl_v) <= JOY_THRESHOLD) && (abs(ctl_h) <= JOY_THRESHOLD) )
		{
			motor[FL] = 0;
			motor[FR] = 0;
			motor[BL] = 0;
			motor[BR] = 0;
		}
		else
		{

			motor[FL] = (ctl_v + ctl_h) / 1.5;
			motor[FR] = (ctl_v - ctl_h) / 1.5;
			motor[BL] = (ctl_v + ctl_h) / 1.5;
			motor[BR] = (ctl_v - ctl_h) / 1.5;
		}



		// don't overload cpu
		wait1Msec( 10 );
	}
}



task LiftSimple (){



	while(1==1){

		motor[LBR] = vexRT[Ch3]+6;
	motor[LBL] = vexRT[Ch3]+6;
		motor[RBR] = vexRT[Ch3]+6;
		motor[LTL] = vexRT[Ch3]+6;;
		motor[RBL] = vexRT[Ch3]+6;;
	motor[RTR] = vexRT[Ch3]+6;;





	}
}



void pre_auton()
{

	 bStopTasksBetweenModes = true;
	SensorValue[LeftDrive] = 0;
	SensorValue[RightDrive] = 0;
}

task autonomous()

{
motor[FR] = 127;
motor[BR] = 127;
motor[BL] = 127;
motor[FL] = 127;
wait1Msec(13000);
motor[FR] = 0;
motor[BR] = 0;
motor[BL] = 0;
motor[FL] = 0;
}

task usercontrol()
{
	
	startTask( ArcadeDrive);
	startTask(LiftSimple);
	startTask(Claw);

	while(1==1){
		
	}
}

I see a few questionable things, some probably having nothing to do with your problems and some which may well be causing them.

Separate: Why have you defined pre_auton() twice? They’re not quite the same, either.

Perhaps the problem: Looking at your four 127s, I would expect the motors on one side to be reversed and not the other side. Or maybe you have an odd configuration, and one on each side would be reversed. But I would always expect two reversed, though you might have some really odd, very asymmetrical build. Looking at your four within the #pragma statements, only BR is reversed. Now I would also note that it is very confusing that you label FR for a left and FL for a right, while BL is left and BR is right. Presumably these are BR = “front right,” etc. Having weird labels doesn’t stop things from working inherently, though; it’s just confusing and therefore bad practice. Anyway, back to the 3 v. 1. It looks like you are probably driving two motors against each other at full power. These are sitting on different ptc’s. Could it be that you’re tripping both ptc’s by running these two at full power against each other? Otherwise I would expect a swing turn instead of driving straight. But if this does quickly trip the ptc’s, that would also explain your “disconnect” in remote control because you’d again be driving them against each other. Is it really disconnecting? Or could it be that both ptc’s are repeatedly tripping so it’s not responding, which is very different?

Perhaps another problem: You have no wait1mSec() commands inside several of your tasks. You could easily be starving the ArcadeDrive() task. I don’t see any task priority to fight against that. So I would expect ArcadeDrive() to essentially never run once one of the other tasks has started running.

1st: that was a copy and paste error
2nd: We’ve manually reversed motors in the motor and sensor set up and I’m pretty sure one cable is reversed which fixed it; moving all at positive works fine for us
3rd: Right as we go from auton to driver we have all green lights, then as soon as we try to make any movement with the controller the communication from the cortex to the controller disconnects and the lights turn all red and we are unable to do anything for the entire match. When unplugged from the tower and we are just practicing this is not an issue at all. but this problem only appears in competition when we have an auton written in.

Hmm… Well, definitely put some wait1Msec() commands in those tasks.

Have you tried swapping cortexes?

Another thought upon rereading this: You say it only happens “when we have an auton written in.” But you always have autonomous written in. So I figure what you mean by that is if you leave inside autonomous() entirely blank, it works in competition. Or does it still fail when in competition, which necessarily triggers autonomous()?

No not yet, this was THIS robot’s last competition of the season since we have built a new one for states. Im just trying to figure out if its a coding issue or what so it doesnt happen on this new one

It only fails when there is actual code in the Auton brackets

Now that is definitely odd. There is so little code there, and it’s not doing anything crazy; just some basic quick commands.

As for swapping Cortexes, that should be one of the immediate things you do. Also swapping the USB wireless card. Doing such swapping is absolutely vital in circumstances such as these. Sometimes something has died, and you could spend hours looking at code and never find it. For example, something happened to one of my students’ pots. The confusing thing was that he was altering the code relating to the pot. Suddenly the arm would just swing and never try to stop. After a quick glance at the code, checking the pot itself saved lots of time. I still need to go back to be sure whether it was the pot itself or the connection to it. But the point remains: if you only check one portion of the system, the error may be in a different part of the system and you may never find it.