We hit this at the wrong time, chewing up 2 out of 4 remaining hours of unbagged time before our upcoming competition.
Today, on a freshly imaged v17 roboRIO - our completion robot, we can deploy code from Eclipse, and DS connects but reports No Robot Code.
I reproduced this on another roboRIO, which happened to be on v16 - on v16, I was able to deploy our code (the same code), then I imaged that to v17, and once again I could connect with the DS but the DS reported no robot code (and comm light was red on the RIO).
If I ssh into the roboRIO, and MANUALLY execute “sh robotCommand” to manually start the robot program, the DS is now fine - i.e., comms are green and the DS is happy. Unfortunately, restarting the roboRIO brings us back to the original state. When logged in I looked around in various log files and could not find any clues.
Any suggestions on how to diagnose the problem further would be helpful. Is the robot code failing on startup, but running ok when manually started later? Or is somehow never being started?
There’s an option in the roborio imaging tool to start code when the robot is turned on. Reimage the roborio and make sure that option is checked. If you click “restart robot code” from the driver station, does the code start?
H Jay, the start robot code was not disabled - checked in the roboRIO admin web console, and from the DS, attempting to restart robot code has no effect.
I looked at the logs in the admin console and see this:
2018-03-28T01:46:08.000-07:00 roboRIO-1899-FRC /usr/local/natinst/bin/nirtmdnsd[2592]: Service locator returned 0 for service ‘Main Application Instance/RTServiceName’, unable to start ‘_ni-rt._tcp’ service.
Which may not have any relevance, but just reporting it. I’m next going to try downloading a simple sample program and see if that works. Thanks.
Deploying a simple test program works fine, and that 'Service locator returned 0" still shows up on reboot, so I think that log message is a red herring. The original issue is still unresolved - deploying our competition bot code - but at this point it looks to be an issue with the code being deployed, not the system, though we are still stuck trying to figure the root cause.
I agree, if a sample project deploys fine, then it’s likely something in your code. Can you check the DriverStation logging for “Code Start notification”? That should indicate whether the code started at all. Additionally, that log may show an error/stacktrace indicating a crash and where.
Ssh in (using PuTTY) as lvuser and run “top”. Do you see a java process starting and ending? If so, your code is crashing. If you don’t see a backtrace in riolog or the DS console, it may be that the crash message is too big (I saw that with one team due to an infinite recursion in their constructor). You can start the program manually by ssh’ing in as lvuser and running “./robotCommand”. That will run the robot program interactively so you can see the console output from Java.
Hi Peter, I will try that if nothing than just to familiarize myself with the process. I could start the robotCommand process myself and it runs fine, but I will try to reproduce this problem and check the results of top.
I think that it may be down to not having the latest version of the Eclipse Wpilib Robot Java Development - this problem that I have been describing happened on a laptop that had 2018.3.1. It does not happen from a laptop with 2018.4.1. The curious thing is that after a single deployment of robot code from the 2018.4.1 machine, the laptop with 2018.3.1 can subsequently deploy code fine.
Do you have any sysouts in your robotInit() and robotPeriodic()? If not I would add them and see if it is even getting there. If you see the robotInit() sysouts but not the robotPeriodic() sysouts, throw everything in robotInit() in a try/catch and print the stack trace from the exception and post it.
Are you able to see any log messages in the console? If not you can putty in and run that the command like Peter recommended. I think we generally run /usr/local/frc/bin/frcRunRobot.sh which in turn runs robotCommand (and some other setup stuff) but I’m not at a roboRIO to tell you for sure.
Also, we use a logging framework (logback) that saves log files to the roboRIO so we can just WinSCP in and grab the files whenever (super handy when your bot craps out in a match). Also, then you can control which log statements actually print (trace, debug, info, warn, error). Obviously not very helpful right now, but something to look into adding before future issues crop up.