Randomly being disconnected from the Robot

Hello everyone!

My team and I are having some problems with our driver station. We seem to be randomly getting disconnected from our robot, and we’re not able to reconnect until we restart the robot. We’ve tried using two different RoboRIOs, and to connect, we’ve tried Ethernet, wireless, and USB, but the disconnects keep happening. Here’s the log that the driver station gave us. In this situation we had communication with our robot, we deployed our new LabVIEW code, and the robot was enabled for about 30 seconds before we lost connection again.

Warning 44008 <radioLostEvents> 20.512 <radioSeenEvents> 19.011
FRC: Robot radio detection times.Warning 44003 FRC: No robot code is currently running. Driver Station
Warning 44004 FRC: The Driver Station has lost communication with the robot. Driver Station
Warning 44002 Ping Results: link-bad, DS radio(.4)-bad, robot radio(.1)-GOOD, cRIO(.2)-GOOD, FMS-bad FRC: Driver Station ping status has changed. Driver Station
Warning 44002 Ping Results: link-bad, DS radio(.4)-bad, robot radio(.1)-GOOD, cRIO(.2)-bad, FMS-bad FRC: Driver Station ping status has changed. Driver Station
Warning 44002 Ping Results: link-bad, DS radio(.4)-bad, robot radio(.1)-bad, cRIO(.2)-bad, FMS-bad FRC: Driver Station ping status has changed. Driver Station

I’d appreciate any insight anyone has on fixing this, as it’s really had to make a robot when your computer keeps disconnecting.

Still having the problem a day later. Does anyone know what may be causing this? I’ve just tried reinstalling labview and the FRC update but it still doesn’t seem to be working

I have a couple of questions for you.

Are you running the unmodified default code to make sure it isn’t the code?

Does the robot die while it is still Disabled?
Die when first Enabled?
Die when moving the joystick or pressing a button?

How are you downloading the code, e.g.,

  • Build/Run as startup
  • using the Run button on the window?

Where do you get a connection code?

Bumping this thread. We’re having the exact same problem. Any solutions?

What language are you using? There is an issue in image v16 where large amounts of console output (as can commonly happen in C++ and Java programs) can result in loss of comm. NI is aware of the issue and will be releasing a v17 soon to fix this particular issue, but in the meantime you can reduce the amount of console output to work around the issue.

Also check that all of your firewalls are turned off (Windows 10 comes with 3 different firewalls that you need to turn all of them off). This sounds like it could be a firewall thinking the robot is a hacker and kicking it off the network.

Also, when you lose connection can you ping the roboRIO? (try in command prompt “ping roborio-TEAM-frc.local” where TEAM is your team number.

See the next (previous) thread … do you have the equivalent of println going to the console from within fast running loops. The software this year (and new RioLog) doesn’t handle this - and you get exactly the behavior you describe. That may not be it (without seeing the code you are running) … but it’s not like last year. Of course, YMMV.

I am very new to FTC. What is console output and how do I reduce it?
Also, how do I take off the firewalls in windows 10?

Go to control panel type “firewall” and turn off all that you see

My robot is also having similar problems as juxttech. Another problem is that after hitting the “init” button, the interface of the driver station phone remains frozen on the play button that is indicated by a triangle. This problem just started recently.

Here are some facts about our robot that may help to troubleshoot the problem:

  1. we use modern robotics hardware.
  2. There are many modules, our robot uses a total of 8 motors and 1 servo.
  3. Usually a hard reset (turning the robot off and on by the power switch) solves the problem, but this is problematic in a match since it can not be done.

Not sure what programming language you are using, but in Java something like calls to “System.out.println” or “System.err.println”. Basically anything that would send output to the console if you were running the program from a command line. I forget my C and C++ syntax ( cout << “some string” maybe for C++). Any of your programmers should be able to help you. Someone said NI was going to release an update soon to fix it? But it’s probably not a good programming practice in general. Better to have some kind of logging facility that lets you control it and also write to a file on the RIO itself (using a USB memory stick, for example).

The way you can tell is to open the console from the driver station program (I think it’s the little gear in the upper right hand corner) - which opens up a drop down and lets you do “Console”. If you are getting stuff printed to this when your robot is enabled in any mode, it’s a problem with quantity. I’m at home now - but the WPI screen steps have a section on how to work the driver station program.

There seems to be some confusion here on whether we are talking about FTC or FRC. In FRC, there’s an issue with excessive console output interacting with the Eclipse riolog that should be fixed in the next NI update image. For those talking about FTC, that does not apply.

We are having this problem too and some good suggestions here on what to check which I will follow up on.

One question I had was whether I can get more useful logs on the robot itself which may help identify the cause. I have looked at the logs in /var on the robot through ssh but seems there’s nothing useful in those logs by default - was looking to see if there’s any info on watchdog timeout or similar. Does this have to be specifically added to be logged ?

Our robot goes into disabled mode where it cant be recovered without a reboot though the web interface is still functional.

thanks !