Driver Station No Robot Code Light Blinking

Hi Chief Delphi.

During the testing of our robot, I found out that when our robot is enabled from the Driver Station for about 1-2 minutes, it tells us that there is no robot code momentarily. This then happens at intervals of time that get smaller and smaller until eventually the Driver Station reports that communications with the robot has ceased. Sometimes though, after communications have supposedly ceased, when we leave our electronics on, the Driver Station will report that it detects its connection with our cRIO and has robot code but then quickly goes back to its no communication state.

While having the robot in operation, whenever this error appears, the state of our robot freezes. For example, if we were spinning a motor and this error came up, without input from our joystick, the motor would still spin until communications have been detected again.

This has occurred in completely different sets of hardware (different cRIOs, victors, modules, etc.). We tried different batteries (fully charged). This occurs both tethered to our laptop and through our wireless bridge.

I am programming in Java and use NetBeans as our IDE. I am using the supplied Command Based Robot Template. It seems that it is a problem with our code because with other sample code that I loaded into our robot, this problem does not occur. Another oddity is that when I tried to print out the state of our robot in the NetConsole, whether its in teleopInit, disabledPeriodic, etc., I found that when the Driver Station reported no communications with the cRIO, it still went through the disabledPeriodic/Continuous states.

I plan to meticulously, through trial and error remove certain aspects of my code to see what’s causing the error. I was wondering though if anyone ever encountered something like this and if they could give any insight as to what is causing this. I’ve attached my code if it helps in any way. It is very outdated though with poor “grammar” because I could not reach my code which is on a laptop at school right now.

LancerBot.zip (62.6 KB)


LancerBot.zip (62.6 KB)

Does the charts tab in the DS show any trends such as increasing CPU usage or increasing memory usage over time?

I do not think so. I monitored Windows Task Manager’s report on CPU Usage / Memory and they were stable throughout the whole time during one time I observed this error. However I will monitor it more thoroughly during my continued trials of this.

The Charts tab shows cRIO CPU and memory. Task Manager shows your DS computer’s CPU and memory.

Ah, I see. Thank you for that. I will monitor that tomorrow when I can get to our equipment and test it out and hopefully I’ll be able to find a clue for our problem.

Joe is specifically referring to the Charts tab of the Driver Station software, not necessarily the laptop’s task manager. Windows Task Manager will show you the computer’s CPU and memory usage, but the Charts tab of the DS will show you actual cRIO CPU usage.

You can go to Program Files > FRC Driver Station > Driver Station Log File Viewer.exe and review the log of the same display shown in the Charts tab of the DS.

I’ve just run through a few test while monitoring the charts on the Driver Station and there does not seem to be anything out of the ordinary. All data is consistent in the states where our robot is enabled and disabled.

We have been plagued by a similar problem and finally isolated the cause as being power noise from the voltage adapter to the wireless bridge. The adapter can have noise of its own, but we believe it is also originating from the compressor motor. We installed a 220 uF capacitor across the power leads between the voltage adapter and the bridge, and also across the power leads to the compressor. This seems to have solved the problem. Make note of whether the problem occurs mostly when the compressor is running. Power up with the air system fully charged so the compressor does not run, then drain the pressure and power up again with the compressor running, and see if there is a difference.

If you think it’s a problem that’s associated with the wireless bridge, the best and most certain way to troubleshoot that is to plug the DS directly into the cRIO and see if the problem occurs. If it doesn’t, you can be highly suspicious of the bridge. If the problem still occurs, then it’s highly unlikely that it’s the bridge. I don’t think randomly sprinkling capacitors around is good first step for troubleshooting. But then, I prefer rifles to shotguns for troubleshooting problems.

I don’t believe I indicated that the capacitors were randomly sprinkled, nor a first step. They were an effective solution that the solved the problem after many other possibilities were explored. The solution is offered with the chance that another team with the same problem might benefit from it.

Hey guys. Thanks for all the replies. Through many trials of commenting out sections of my code though, I found out that the following line was to blame for:

SmartDashboard.putData(“Scheduler Data” , Scheduler.getInstance());

I’m not too sure why though. This is the first year we are using the SmartDashboard and everything else related to it works.

Thanks for all advice.

The Robot Code light on the DS is controlled by the arrival of info from the robot in the status packets. If the robot code is running slower and slower, it will eventually start to miss status timeouts and the light will flicker. If it stops sending them all-together the light will stay red.

So, I’m not sure what was/is causing it, but I suspect that your code, or more precisely the FRC_Communications task on your cRIO was running slower and slower due to low-memory or task overhead.

Greg McKaskle

Me and a couple of my teammates were thinking about that Greg, which is why I think the line

SmartDashboard.putData(“Scheduler Data” , Scheduler.getInstance());

seems to slow down the robot. I have also recently discovered that when I use a SendablePIDController and use SmartDashboard.putData with it, the same bug comes up.

Can you test whether even more SmartDashboard updates causes the CPU to rise even faster? Can you show that the CPU doesn’t rise when the SmartDashboard is not used? Anything can have a bug in it, including the SmartDashboard, but it would be nice to get to the bottom of it.

Greg McKaskle

According to the Driver Station’s charts, CPU usage stays at a consistent rate whether SmartDashboard is being updated or not. I plan to check out if this problem occurs on our Classmate just in case though to see if we can eliminate some problems.

Just to clarify, the CPU usage, battery usage, RAM, and flash are all robot measurements. The trip time and dropped packets involve both DS and robot. To view the DS CPU and memory usage, use the Task Manager.

Greg McKaskle