Motors stopping during match

Hello everyone,
Today our club had some practice matches with each other and when our team was competing, our motors on our scoop (which picks up stars and cubes) stopped working, and after waiting just a little bit, they started working again. Later during the same match our chassis motors would stop working for 6 seconds, then start working again for 6 seconds, and then stop working for 6 seconds, repeating until the match ended. I had read some previous threads on the forum about something similar, but all of the suggestions that they provided, I believe we were already doing. Can someone please provide us with some suggestions or tips? Thanks in advance.

Our robot has
-4 high-speed motors on our scoop
-4 high-speed motors for each wheel (2 high-traction wheels, 2 Omni-wheels)
-Power expander which powers all four wheels

So you have a 16 motor drive?

In all seriousness, the lift is likely due to the PTC’s in the motors tripping. What’s the ratio on your lift? Does it work fine without stars/cubes?
As for the drive, a 4 motor speed drive shouldn’t have any problems, but

  1. ratio?
  2. construction? are you using bearing flats, etc? I know it’s a stupid question, but with how many times I’ve seen a bearing flat forgotten… If not, pull the shafts our of JUST the motors and spin the wheels. Are they smooth? If not, fix that. If so, then we have a real problem :stuck_out_tongue:

Whoops :slight_smile: I meant that we have 4 motors on our chassis, 2 of which are high traction, and the other two are omnis.
The scoop is geared from 12:60 giving the scoop a little more torque. Our scoop seems fine most of the time whether it is scoring a cube or star or nothing at all.
The chassis is direct drive, and we have almost too many bearings on our robot.

I think you may be right :frowning:

Haha no worries. You shouldn’t have any problem with that in most cases up to about a 7:5 ratio with internal speed. (2.1:1) You might think about blaming the electronics; the cortex may be browning out or you may have bad motors/controllers. To rule out the motors, grab a wheel and try to slow is down a little (to simulate the friction of the field) while turning the motor on. If the motors turn off easily, feel the motors. Are they warm? If so, it’s likely your gearing being too robust. But if every motor is doing a similar thing, I’d blame the cortex; it may be browning out. I’m not an expert on this however; you may want to wait for someone better than I to come along.

We have been experiencing slight problems with our cortex (which is old), but nothing bad enough to replace it. I doubt it is the motors because most of them are brand new. After driving in one match, the motors are not warm at all, but after driving in practice for awhile they do get ever so slightly warm.

Can you elaborate more? Also, have you tried other programs on other bots with this cortex? It sounds like whatever it is, it’s a simple fix. Is your program complicated? I remember when I was working on a rerun program a few years ago I would overflow the cortex’s memory and the program would stutter for a bit before going on again.

I don’t quite know how to explain it, but the cortex, when plugged into a battery wouldn’t turn on, (this only happened once as far as I know) but it eventually started working again; we couldn’t ever figure out why it did that. We have also had problems today with the computer not recognizing that the cortex was plugged in, but it eventually worked.
Other programs have worked on this cortex. We have had the same cortex since Toss Up. Our program this year is not very complicated at all. It’s only several hundred lines of code, nothing crazy.

Does the VEXnet connection drop out? What are the LED lights doing when the cortex stops running?

Please see the troubleshooting docs here: http://www.roboticseducation.org/documents/2013/06/vex-cortex-troubleshooting-flowcharts.pdf

Please post your code, there could be a problem with it that you are missing.
If the code is too large to post then zip up the files and attach it to your post.

Thanks

I don’t believe the VEXnet connection is dropping, but I cannot say for sure. I didn’t even think to see what the lights were doing when it happened. I’ll have to post my code tomorrow. Thanks for everyone’s help so far, I really appreciate it.

Have you split the load on the Cortex between ports 1-5 and 6-10? It sure sounds to me like you are tripping circuit protection somewhere. Either the motors, the Power Expander or the Cortex. But the age of the Cortex could play a role as well.

Yes, I have split the load on the cortex.

Here is my code

#pragma config(I2C_Usage, I2C1, i2cSensors)
#pragma config(Sensor, in1,    gyroscope,      sensorGyro)
#pragma config(Sensor, I2C_1,  MotorLF,        sensorQuadEncoderOnI2CPort,    , AutoAssign )
#pragma config(Sensor, I2C_2,  MotorLB,        sensorQuadEncoderOnI2CPort,    , AutoAssign )
#pragma config(Sensor, I2C_3,  MotorRB,        sensorQuadEncoderOnI2CPort,    , AutoAssign )
#pragma config(Sensor, I2C_4,  MotorRF,        sensorQuadEncoderOnI2CPort,    , AutoAssign )
#pragma config(Motor,  port2,           MotorLF,       tmotorVex393HighSpeed_MC29, openLoop, encoderPort, I2C_1)
#pragma config(Motor,  port3,           MotorLB,       tmotorVex393HighSpeed_MC29, openLoop, encoderPort, I2C_4)
#pragma config(Motor,  port4,           RightLift,     tmotorVex393HighSpeed_MC29, openLoop)
#pragma config(Motor,  port5,           LeftLift,      tmotorVex393HighSpeed_MC29, openLoop)
#pragma config(Motor,  port6,           hang,          tmotorVex393_MC29, openLoop, reversed)
#pragma config(Motor,  port8,           MotorRB,       tmotorVex393HighSpeed_MC29, openLoop, reversed, encoderPort, I2C_3)
#pragma config(Motor,  port9,           MotorRF,       tmotorVex393HighSpeed_MC29, openLoop, reversed, encoderPort, I2C_2)
//*!!Code automatically generated by 'ROBOTC' configuration wizard               !!*//

#pragma platform(VEX)
//Competition Control and Duration Settings
#pragma competitionControl(Competition)
#pragma autonomousDuration(15)
#pragma userControlDuration(105)
#include "Vex_Competition_Includes.c"   //Main competition background code...do not modify!
/////////////////////////////////////////////////////////////////////////////////////////
//                          Pre-Autonomous Functions
// You may want to perform some actions before the competition starts. Do them in the
// following function.
/////////////////////////////////////////////////////////////////////////////////////////
void pre_auton()
{
	// Set bStopTasksBetweenModes to false if you want to keep user created tasks running between
	// Autonomous and Tele-Op modes. You will need to manage all user created tasks if set to false.
	bStopTasksBetweenModes = true;
}
/////////////////////////////////////////////////////////////////////////////////////////
//                                 Autonomous Task
// This task is used to control your robot during the autonomous phase of a VEX Competition.
// You must modify the code to add your own robot specific commands here.
/////////////////////////////////////////////////////////////////////////////////////////
task autonomous()
{
	//extend the hanging bar out just a little to keep it from scraping the ground.
	motor[port6] = 126;
	wait1Msec(500);//wait .5 seconds
	motor[port6] = 0;
}
/////////////////////////////////////////////////////////////////////////////////////////
//                                 User Control Task
// This task is used to control your robot during the user control phase of a VEX Competition.
// You must modify the code to add your own robot specific commands here.
/////////////////////////////////////////////////////////////////////////////////////////
//#define C1LX vexRT[Ch4]//define variable
//#define C1LY vexRT[Ch3]//define variable
//#define C1RX vexRT[Ch1]//define variable

task usercontrol()
{
	bLCDBacklight = true;// Turn on LCD Backlight
	string mainBattery, backupBattery;
	motor[port6] = 126;//extend the hanging bar out just a little to keep it from scraping the ground.
	wait1Msec(500);//wait .5 seconds
	motor[port6] = 0;//stop

	while (true)
	{
		//--LCD BATTERY PROGRAM
		clearLCDLine(0);// Clear line 1 (0) of the LCD
		clearLCDLine(1);// Clear line 2 (1) of the LCD

		//--Display the Primary Robot battery voltage
		displayLCDString(0, 0, "Primary: ");
		sprintf(mainBattery, "%1.2f%c", nImmediateBatteryLevel/1000.0,'V'); //Build the value to be displayed
		displayNextLCDString(mainBattery);

		//--Display the Backup battery voltage
		displayLCDString(1, 0, "Backup: ");
		sprintf(backupBattery, "%1.2f%c", BackupBatteryLevel/1000.0, 'V');	//Build the value to be displayed
		displayNextLCDString(backupBattery);

		//--Short delay for the LCD refresh rate
		wait1Msec(100);

		motor[port2] = vexRT[Ch3];
		motor[port3] = vexRT[Ch3];
		motor[port8] = vexRT[Ch2];
		motor[port9] = vexRT[Ch2];

		//+++++++++++++++++++++++++++++++++++++++++++++| Fast Movements |++++++++++++++++++++++++++++++++++++++++++++++
		if(vexRT[Btn6UXmtr2] == 1)//If button 6U is prssed, the scoop will go up
		{
			motor(port4) = 126;
			motor(port5) = -126;
		}
		else if(vexRT[Btn6DXmtr2] == 1)//If button 6D is prssed, the scoop will come down
		{
			motor(port4) = -126;
			motor(port5) = 126;
		}
		else if(vexRT[Btn8UXmtr2] == 1)//If button 8U is prssed, the scoop will go up very slowly
		{
			motor(port4) = 40;
			motor(port5) = -40;
		}
		else if(vexRT[Btn8DXmtr2] == 1)//If button 8D is prssed, the scoop will come down very slowly
		{
			motor(port4) = -40;
			motor(port5) = 40;
		}
		else//The scoop will do nothing
		{
			motor(port5) = 0;//speed of 0
			motor(port4) = 0;//speed of 0
		}
		//+++++++++++++++++++++++++++++++++++++++++++++| Hanging |++++++++++++++++++++++++++++++++++++++++++++++
		if(vexRT[Btn5UXmtr2] == 1)//If button 5U is pressed, the hanging mechnaism will extend
		{
			motor(port6) = 126;
		}
		else if(vexRT[Btn5DXmtr2] == 1)//If button 5D is pressed, the hanging mechnaism will retract
		{
			motor(port6) = -126;
		}
		else//The hanging mechanism will do nothing
		{
			motor(port6) = 0;//speed of 0
		}
		//wait1Msec(25);//I have no idea why I put this here, keepuntilyou can figure out it does ordoesn't do.
	}
}

I have no idea whether it matters but it’s kinda bugging me that you used () for some motors and ] for others… lol sorry. Uh, maybe try switching motor ports and seeing if maybe your power expander is fluke or something…

:wink: I guess I never really realized that.
The power expander is pretty new, it must be the cortex. We will try and replace the cortex next week when we get a chance.
Thanks for everyone’s help.

The code appears to be fine. However I just had to fix the round parenthesis for you. :wink:

Also the wait1Msec(20); at the end of the while loop is there because the cortex only updates the motors every 20ms anyway so you don’t need to over-update them.

Also removed that 100ms delay you had for the LCD. If you want to add that effectively then I would suggest using another task just for the LCD screen however updating every 20ms is fine.

#pragma config(I2C_Usage, I2C1, i2cSensors)
#pragma config(Sensor, in1,    gyroscope,      sensorGyro)
#pragma config(Sensor, I2C_1,  MotorLF,        sensorQuadEncoderOnI2CPort,    , AutoAssign )
#pragma config(Sensor, I2C_2,  MotorLB,        sensorQuadEncoderOnI2CPort,    , AutoAssign )
#pragma config(Sensor, I2C_3,  MotorRB,        sensorQuadEncoderOnI2CPort,    , AutoAssign )
#pragma config(Sensor, I2C_4,  MotorRF,        sensorQuadEncoderOnI2CPort,    , AutoAssign )
#pragma config(Motor,  port2,           MotorLF,       tmotorVex393HighSpeed_MC29, openLoop, encoderPort, I2C_1)
#pragma config(Motor,  port3,           MotorLB,       tmotorVex393HighSpeed_MC29, openLoop, encoderPort, I2C_4)
#pragma config(Motor,  port4,           RightLift,     tmotorVex393HighSpeed_MC29, openLoop)
#pragma config(Motor,  port5,           LeftLift,      tmotorVex393HighSpeed_MC29, openLoop)
#pragma config(Motor,  port6,           hang,          tmotorVex393_MC29, openLoop, reversed)
#pragma config(Motor,  port8,           MotorRB,       tmotorVex393HighSpeed_MC29, openLoop, reversed, encoderPort, I2C_3)
#pragma config(Motor,  port9,           MotorRF,       tmotorVex393HighSpeed_MC29, openLoop, reversed, encoderPort, I2C_2)
//*!!Code automatically generated by 'ROBOTC' configuration wizard               !!*//

#pragma platform(VEX)
//Competition Control and Duration Settings
#pragma competitionControl(Competition)
#pragma autonomousDuration(15)
#pragma userControlDuration(105)
#include "Vex_Competition_Includes.c"   //Main competition background code...do not modify!
/////////////////////////////////////////////////////////////////////////////////////////
//                          Pre-Autonomous Functions
// You may want to perform some actions before the competition starts. Do them in the
// following function.
/////////////////////////////////////////////////////////////////////////////////////////
void pre_auton()
{
	// Set bStopTasksBetweenModes to false if you want to keep user created tasks running between
	// Autonomous and Tele-Op modes. You will need to manage all user created tasks if set to false.
	bStopTasksBetweenModes = true;
}
/////////////////////////////////////////////////////////////////////////////////////////
//                                 Autonomous Task
// This task is used to control your robot during the autonomous phase of a VEX Competition.
// You must modify the code to add your own robot specific commands here.
/////////////////////////////////////////////////////////////////////////////////////////
task autonomous()
{
	//extend the hanging bar out just a little to keep it from scraping the ground.
	motor[port6] = 126;
	wait1Msec(500);//wait .5 seconds
	motor[port6] = 0;
}
/////////////////////////////////////////////////////////////////////////////////////////
//                                 User Control Task
// This task is used to control your robot during the user control phase of a VEX Competition.
// You must modify the code to add your own robot specific commands here.
/////////////////////////////////////////////////////////////////////////////////////////
//#define C1LX vexRT[Ch4]//define variable
//#define C1LY vexRT[Ch3]//define variable
//#define C1RX vexRT[Ch1]//define variable

task usercontrol()
{
	bLCDBacklight = true;// Turn on LCD Backlight
	string mainBattery, backupBattery;
	motor[port6] = 126;//extend the hanging bar out just a little to keep it from scraping the ground.
	wait1Msec(500);//wait .5 seconds
	motor[port6] = 0;//stop

	while (true)
	{
		//--LCD BATTERY PROGRAM
		clearLCDLine(0);// Clear line 1 (0) of the LCD
		clearLCDLine(1);// Clear line 2 (1) of the LCD

		//--Display the Primary Robot battery voltage
		displayLCDString(0, 0, "Primary: ");
		sprintf(mainBattery, "%1.2f%c", nImmediateBatteryLevel/1000.0,'V'); //Build the value to be displayed
		displayNextLCDString(mainBattery);

		//--Display the Backup battery voltage
		displayLCDString(1, 0, "Backup: ");
		sprintf(backupBattery, "%1.2f%c", BackupBatteryLevel/1000.0, 'V');	//Build the value to be displayed
		displayNextLCDString(backupBattery);
		motor[port2] = vexRT[Ch3];
		motor[port3] = vexRT[Ch3];
		motor[port8] = vexRT[Ch2];
		motor[port9] = vexRT[Ch2];

		//+++++++++++++++++++++++++++++++++++++++++++++| Fast Movements |++++++++++++++++++++++++++++++++++++++++++++++
		if(vexRT[Btn6UXmtr2] == 1)//If button 6U is prssed, the scoop will go up
		{
			motor[port4] = 126;
			motor[port5] = -126;
		}
		else if(vexRT[Btn6DXmtr2] == 1)//If button 6D is prssed, the scoop will come down
		{
			motor[port4] = -126;
			motor[port5] = 126;
		}
		else if(vexRT[Btn8UXmtr2] == 1)//If button 8U is prssed, the scoop will go up very slowly
		{
			motor[port4] = 40;
			motor[port5] = -40;
		}
		else if(vexRT[Btn8DXmtr2] == 1)//If button 8D is prssed, the scoop will come down very slowly
		{
			motor[port4] = -40;
			motor[port5] = 40;
		}
		else//The scoop will do nothing
		{
			motor[port5] = 0;//speed of 0
			motor[port4] = 0;//speed of 0
		}
		//+++++++++++++++++++++++++++++++++++++++++++++| Hanging |++++++++++++++++++++++++++++++++++++++++++++++
		if(vexRT[Btn5UXmtr2] == 1)//If button 5U is pressed, the hanging mechnaism will extend
		{
			motor[port6] = 126;
		}
		else if(vexRT[Btn5DXmtr2] == 1)//If button 5D is pressed, the hanging mechnaism will retract
		{
			motor[port6] = -126;
		}
		else//The hanging mechanism will do nothing
		{
			motor[port6] = 0;//speed of 0
		}
		wait1Msec(20);//I have no idea why I put this here, keepuntilyou can figure out it does ordoesn't do.
	}
}

Thanks @NattyMan0007
So, my team put on a new cortex, and it did fix the connectivity issues, but our motors are still quitting on us after several minutes of constant driving (not that big of a deal, since each match is 2 minutes). We assume it is from overheating. Any suggestions? Or is it something we will have to live with?
If we need to, our team does have some spray coolant we could use. It worked in previous years. But if there is a permanent fix, I would rather have that than just a temporary fix.

The old Cortex sounds like the battery connection had gone bad. We have all of our robots use the battery extenders. That way when changing batteries, they are disconnecting from the extender and not from the Cortex. Otherwise, it sounds like you are tripping the PTCs on the motors. So you need to find a way to ease the load. How long does it take for the motors to trip. If longer than 3-4 minutes, probably not a problem as matches don’t last that long. But it is still a signal that you are over-stressing the motors. The motors are not a peak efficiency at max power, but at somewhere around 85% power-ish (don’t remember exactly off the top of my head). We will often sacrifice a little speed for reliability.

We do use battery cord extenders, even for the power expander. The PTC’s don’t trip until maybe 4-ish minutes. We will try and reduce the motor speed. Thank you.

It depends on how your robot works, how much load is on the motors, their gearing, the load they are under. You could just have the simple problem of trying to do too much with your motors and they are under extra load.
Or you could be running on a low battery.

Reducing motor speed sacrifices power output as well. They are at maximum efficiency sooner than 100% but they will have less torque as the input voltage decreases (P=V/I). If your robot is under a lot of load then you won’t achieve much by running the motors slower.

I am not quite sure what the load is on the motors. Our robot is similar to 8059D. Our gear ratio is 1:5 on the launcher and we have 4 high speed 393 motors powering it. The wheels are direct-drive with high-speed motors on each wheel.

This sounds like a classic PTC tripping problem. My team had the same issue last year with a heavy robot and “enthusiastic driving”. They implemented the Smart Motor Library (lots of threads on that here), and that was just the trick. Rather than the motors just quitting, the code in the library tracks the motors, and slows them gradually rather than run them right over the edge. Also implements some slew rate control to prevent the wild swings that spike current and stress the motor/PTC.

On the physical side, obvious efforts to reduce friction (axle alignment, etc.) and reducing weight are helpful.