What is broken? Remote, Radio, or something else?

Sometimes in the middle of practice matches, the teleop program I am using will spontaneously end. The IQ robot will be working fine, and then suddenly, the brain is on the teleop screen, and (obviously) the controller doesn’t move the robot. The ecreen on the brain will flash quickly between teleop menu and the active program screen, and then remain on the teleop menu.
My program is in Robot C, and most times everything works great. It only happens about 1 out of 20 runs.

To restart it, I can just open the program again.

When it happens the battery has been about half.
I am using the 900 mhz radio.

Do you know what is wrong?

1 Like

This is in IQ general discussion, and he is talking about TeleOp programs, so I don’t think that that solution would work. I Might try clearing the brain and redownloading your program, although I have not encountered this problem myself.

4 Likes

Well If I heard it correct the updates on the VexIq brain will be best working for VexIq code. I am really not sure about this but try VexIq code. It may be hard at first but it gets real easy.

Hi Milo,

A couple of questions.

  1. How many motors does your robot have?
  2. Are you pushing any of them to the limit?
  3. Are you driving 2 min sessions and then restarting?
  4. Can you describe your RobotC program? Are you doing anything fancy with functions or tasks?

Where I’m trying to get to is

  1. Could your brain suffering from a brown out? I’ve seen cases where the battery is marginal and during the drive there are 4 motors going and the load dropped the battery voltage down and the brain resets. You said in the description that you just open the program again, so I’m assuming that it’s back to the main start screen you get after a reboot.
  2. You have something in the programming that is causing the RobotC VM to crash and restart the brain. A little less likely than 1, but throwing it up on the table.
6 Likes
  1. 6
  2. At the moment where it keeps cutting off, I just put down a riser and backing out, but that’s all. I can’t think how that would push the motors to the limit. Only 3 motors are moving, maybe sometimes 4 because of the H-Drive.
  3. I am doing 1-minute rounds, and then resetting the robot and field and going again. Every time, I restart the program at the setup for every round.
  4. Here is my code:
#pragma config(Motor,  motor1,          arm,           tmotorVexIQ, PIDControl, encoder)
#pragma config(Motor,  motor3,          claw,          tmotorVexIQ, PIDControl, encoder)
#pragma config(Motor,  motor4,          lowerClaw,     tmotorVexIQ, PIDControl, encoder)
#pragma config(Motor,  motor10,         rDrive,        tmotorVexIQ, PIDControl, reversed, encoder)
#pragma config(Motor,  motor11,         lDrive,        tmotorVexIQ, PIDControl, encoder)
#pragma config(Motor,  motor12,         hDrive,        tmotorVexIQ, PIDControl, encoder)
//*!!Code automatically generated by 'ROBOTC' configuration wizard               !!*//
int armmove = 0;
int clearedLClawPos = 200;
bool lowclawpos = false;
bool clawpos = false;
bool armstarting = false;
bool prevlowclaw = false;
task claws()
{
	while(true)
	{
		if(getMotorEncoder(arm)>=clearedLClawPos)
		{
			if(prevlowclaw==true)
			{
				setMotorTarget(lowerClaw,-190,127);
			}
			if(prevlowclaw==false)
			{
				setMotorTarget(lowerClaw,-340,127);
			}
		}
		if(getMotorEncoder(lowerClaw)<=-340)
		{
			lowclawpos = false;
		}
		if(getMotorEncoder(lowerClaw)>=-190)
		{
			lowclawpos = true;
		}
		if(getMotorEncoder(claw)<=38)
		{
			clawpos = false;
		}
		if(getMotorEncoder(claw)>=290)
		{
			clawpos = true;
		}
		if(armstarting==true)
		{
			if(getMotorEncoder(arm)<=clearedLClawPos)
			{
				setMotorTarget(lowerClaw,-190,100);
			}
		}
		if(getMotorEncoder(arm)>clearedLClawPos)
		{
			if(vexRT(BtnEDown)==1)
			{
				if(lowclawpos==false)
				{
					prevlowclaw = true;
					setMotorTarget(lowerClaw,-190,127);
				}
				if(lowclawpos==true)
				{
					prevlowclaw = false;
					setMotorTarget(lowerClaw,-340,127);
				}
				sleep(250);
			}
		}
		if(vexRT(BtnEUp)==1)
		{
			if(clawpos==false)
			{
				setMotorTarget(claw,290,100);
			}
			if(clawpos==true)
			{
				setMotorTarget(claw,38,100);
			}
		sleep(250);
		}
	}
}
task arms()
{
	while(true)
	{
		while(armmove==1)
		{
			if(getMotorEncoder(arm)<142)
			{
				setMotor(arm,100);
			}
			else
			{
				if(getMotorEncoder(arm)>148)
				{
					setMotor(arm,-50);
				}
				else
				{
					armmove = 0;
				}
			}
		}
		while(armmove==2)
		{
			if(getMotorEncoder(arm)<376)
			{
				setMotor(arm,100);
			}
			else
			{
				if(getMotorEncoder(arm)>382)
				{
					setMotor(arm,-100);
				}
				else
				{
					armmove = 0;
				}
			}
		}
		while(armmove==3)
		{
			if(getMotorEncoder(arm)<-5)
			{
				setMotor(arm,100);
			}
			else
			{
				if(getMotorEncoder(arm)>5)
				{
					setMotor(arm,-50);
				}
				else
				{
					armmove = 0;
				}
			}
		}
		while(armmove==4)
		{
			if(getMotorEncoder(arm)<475)
			{
				setMotor(arm,100);
			}
			else
			{
				if(getMotorEncoder(arm)>485)
				{
					setMotor(arm,-100);
				}
				else
				{
					armmove = 0;
				}
			}
		}
	}
}
task main()
{
	startTask(claws);
	startTask(arms);
	while(true)
	{
		setMotor(lDrive,(vexRT(ChA) + vexRT(ChC))*1.27);
		setMotor(rDrive,(vexRT(ChA) - vexRT(ChC))*1.27);
		setMotor(hDrive,vexRT(ChB) * 1.27);
		if(getMotorEncoder(arm)>200)
		{
			armstarting = true;
		}
		if(vexRT(BtnFUp)==1)
		{
			armmove = 2;
		}
		if(vexRT(BtnFDown)==1)
		{
			armmove = 1;
		}
		if(vexRT(BtnRUp)==1)
		{
			if(getMotorEncoder(arm)<500)
			{
				setMotor(arm,127);
			}
		}
		else
		{
			if(vexRT(BtnRDown)==1)
			{
				if(getMotorEncoder(arm)>0)
				{
					setMotor(arm,-127);
				}
			}
			else
			{
				if(armmove == 0)
				{
					setMotor(arm,0);
				}
			}
		}
	}
}```

So the brownout idea could still be on the table, All I can suggest is track the voltage at the start and end of each match to see if you can track down a pattern.

On the code, you have a task for doing “arm” things. In the main task you are also doing arm things. Is there a reason you are doing that? I’m trying to visualize a race condition where the main task is trying to move the arm and the arm task is also moving the arm. You might want to consider moving the code over to stop the possible race condition.

Remember that while we think tasks run all the time in reality the CPU swaps from task to task.

Other than that I have nothing that is a definite break / fix.

4 Likes

Will do. Thanks! (20 characters)

1 Like

Did you get your robot to work OK? (Follow up post)

We tried to replace the radio in the brain, but the button was broken and it wouldn’t let the radio go. Maybe that was the cause of the faulty connection? Since this is the 6th year on that brain, we bit the bullet and bought a new brain, controller, radios. Works great now!