"Robot Code" won't turn green, but no errors are displayed

[Maxwell777]

We were working on getting some code debugged, as we have been so far this season, and all of a sudden we started having the strangest issues deploying. We were having problems deploying code from eclipse, it kept not being able to upload to the roborio, as if we weren't connected, but on the driverstation it said that we had comms.

After a few more retrys (and for no well explained reason), we were able to deploy and upload the code, but we hit a more serious issue. Once the code is uploaded you usually have to wait a few seconds for the robot code to start up (the "Robot Code" indicator on the driverstation to go green), but in our case it simply wouldn't start. Usually this is because of an exception being thrown while our code initializes, but said exception would be put up on the driver station console, and we weren't seeing anything. Additionally, the changes that we made were small (we only changed a few constants and I think like an if statement or something; can't remember, but it was nothing that would cause the program to error out on startup) and even when we undid them it didn't fix the issue. We commited and pulled the program down to another laptop and deployed from there, but we had the same issue. When we pulled down and deployed a previous, functional revision everything deployed and started up fine.

Anyone else seen anything similar to this before? Do you know what it could be? I would say we made some sort of fatal error when we modified the program, but we're not getting any errors thrown to the console, sooooo.....? What do?

[rich2202]

Never had that happen before, but this is what I would do:

1) Connect directly to the RoboRio's ethernet port, and try again.
2) If you connect to the RoboRio's USB port, are there any logs you can look at?
3) Load some basic robot test code - print "hello world" to make sure the process works.
4) Re-image the RoboRio. Seems like a fundamental problem.
5) Load some basic robot test code - print "hello world" to make sure the process works.
6) Deploy the new code.

[legts]

My team had this exact same issue at competition. It turned out that we had two sensors assigned the the same port, and another assigned to a dummy address that didn't actually exist. After we set everything to its proper port, everything was fine.

[YoshiCity]

The "Robot Code" light turns red if the code stops running, for example if there is an error that causes the code to restart in tele-op, the robot will disable and the light will turn red until the code has done its thing. The only times the "Robot Code" light has never turned green for me has been when there is such an error in a section of the code that runs immediately (Robot Init). Check out that bit of code and make sure that everything that you're initializing actually exists and is in the right port.
Good luck

[Arhowk]

Another possibility is that you somehow corrupted the JVM... You could try reinstalling that.

If the issue is indeed the code, some debug print statements everywhere is also a good place to start

[MrRoboSteve]

Probably the fastest way to troubleshoot this is to run the robot program in the debugger, with a breakpoint at the top of robotInit(). Then single step through all of your initialization code until you get a failure.

[ARaine]

I had this issue as well, and like your problem, it did not appear to be a code issue. I had originally modified my code slightly (just some constants) but the code would not start and no error message displayed. The project had been working just fine up until this point.

I found a temporary fix, which was to reboot the roboRIO either by pressing the button on the box itself or to click the "reboot roboRIO" button in the Driver Station.

After the reboot, the robot code light came on normally with the new code I had deployed. I do not know why this happens but I hope a simple reboot is a much easier fix than what you had to go through.

[SPQLrobotics]

We are currently dealing with the same issue! Right now the RoboRio is not recognizing it has any code uploaded. We have reinstalled the JVM and a whole host of other items. Unfortunately no luck and no more allotted time before competition this weekend. Hope inspection day sees better things for us!

[josephno1]

I had the same issue during the San Diego Competition.
Make sure all sensors that you are calling actually exist, it took me a while but I found that I was calling for a Sonic Sensor on Analog port 1 when it was on port 0.

I would just make a very simple program and seeing if that uploads

package org.usfirst.frc.team3647.robot;

import edu.wpi.first.wpilibj.BuiltInAccelerometer;

/**
 * The VM is configured to automatically run this class, and to call the
 * functions corresponding to each mode, as described in the IterativeRobot
 * documentation. If you change the name of this class or the package after
 * creating this project, you must also update the manifest file in the resource
 * directory.
 */

public class Robot extends IterativeRobot {

	private BuiltInAccelerometer accel = new BuiltInAccelerometer();
	
	public void robotInit() {
	
	}

	/**
	 * This function is called periodically during autonomous
	 */
	 public void autonomousInit(){
	    	
	    }
	
	public void autonomousPeriodic() {

	}

	/**
	 * This function is called periodically during operator control
	 */
	public void teleopPeriodic() {
		SmartDashboard.putData("Test", accel);
	}

	/**
	 * This function is called periodically during test mode
	 */
	public void testPeriodic() {

	}
}

[kinganu123]

I would recommend looking at you initialization code. We had an issue where we were requiring a subsystem that hadn't been initialized yet (it was null), and it crashed the robot.

[GreyingJay]

Our code uses the navX sensor. If we try to boot the RoboRio with no navX installed (because we moved it to the practice robot or vice versa), we see this problem. So it definitely could be a crash early on in the code.

[WSiggs]

Probably a bit late, but we had the same exact problem a while ago. What we had to do was use bitvise ssh and connect directly to the roborio, and from there find the file with all outputs from the rio. This file (sorry I can't remember what it's called) will show all errors that happen when the code is run, and even those that aren't picked up by driverstation or the compiler. From here we saw that it was an issue with initialization of pwm ports.

[euhlmann]

Originally Posted by WSiggs

Probably a bit late, but we had the same exact problem a while ago. What we had to do was use bitvise ssh and connect directly to the roborio, and from there find the file with all outputs from the rio. This file (sorry I can't remember what it's called) will show all errors that happen when the code is run, and even those that aren't picked up by driverstation or the compiler. From here we saw that it was an issue with initialization of pwm ports.

The file is /home/natinst/FRC_UserProgram.log I believe
tail -f via ssh is a lot more reliable than the DriverStation log (which sometimes dies or has log items out of order)