Major FMS Communications Issues in Week 0

Hi all,

My team went to a Week 0 event last week and we were left unable to drive at all in a match. Our robot showed up being connected via driver station and on the FMS field tech’s side, but once a match started, the only thing that would work would be our compressor charging up (and the blinky light), but no motor controllers, solenoids, or anything else. Smart dashboard was also not receiving information. Our radio was fully flashed, our Roborio on the latest revision, static IP address was set, laptops and ethernet cables were swapped around, code was checked over, basically everything the field expert at the event could think of, but with no avail. Going into actual competition it would be fantastic to see if we could figure out the issue now, if possible. Here’s a link to our code if anyone is interested: https://github.com/brantmeierz/frc-6574-2018

Thanks a ton in advance!

Would it be possible to look at the match logs? They are located on the DS computer in the Public User\Documents\FRC\logs directory. It might be insightful to look at those using the Log File Viewer that you can launch from the DS using the gear button.

I’d be happy to look at them as well. PM and I will give you email info. It would also be good to run the robot using Practice Mode in the DS. This will step through the same sequence of operations as the FMS will for a match. So if there is a logic issue with the progression of the code from disable->auto->disable->teleOp, this will make it easy to reproduce and debug - without an FMS.

Greg McKaskle

One thing you didn’t mention is the firewall state. Is it off?

Did other robots connect successfully at the event? If so, you might consider retitling your thread to more accurately describe the issues as robot connectivity issues.

Their 2018 code looks like it is here.

We turned off all firewalls, double checked that at the event. No other teams were having this issue, so I don’t think it was a venue problem. Title was meant to reflect that the team had major comm issues in a week 0 event using the FMS for the first time, while having no issues over tether on a flashed bridge.

Edit: updated the code link, copy/pasted the wrong one

Notes

  1. this thread indicates some teams had issues reading the game specific data in autonomousInit(). You should add some logic there to protect against not getting that data. This could be causing a crash on the field – the only thing I saw from program inspection that could do so.

  2. A couple changes you should make to make reading your program easier:

a. Remove all unused and commented out code. It’s in GitHub if you need it.
b. Move the logic in your deep if/else structure into methods. It’s hard to reason about an if statement that spans more than one sreen.
c. class names in Java should be InitCap style names.

  1. Your tank drive logic limits power to motors to 75% – is that intentional?

  2. Are the identical values in the “encoder” class intentional?

  3. You have a bunch of default data in the RobotMap. That’s easily forgotten. Either remove values you’re not using, or go through there and assign real values that don’t conflict.

  4. It looks like you started by writing a command-based robot and then switched to a TimedRobot?

  5. Is the gyro installed on the robot?

  6. Move the initialization of drive, intake, and conveyor from class variable initializers into RobotInit(), and add a try/catch around each one with logging if there’s a failure. Extra points if your robot continues to run if one of those initializations fails.

A few other things to try:

  • Ensure your roboRIO has the latest firmware version (v17, I believe). v16 had some communication-related issues that were resolved in 17, and at my week zero event I had a few teams that were unable to connect with 16. That being said, they were unable to connect so nothing worked at all for those teams. I know you said it was up to date, but you didn’t specify the version.

  • Same thing for the driver station

  • You mentioned you have a static IP set. What is the subnet mask? The way most week zero events run, you want a 255.0.0.0 mask, and many teams put in 255.255.255.0 which won’t work. This applies to everything on the network, including your driver station. If you want an easier configuration, just stick with DHCP. Less room for error, and will work at both week zero events and real events.

  • As Steve mentioned, check your firewall. What most teams miss here is that Windows has two places you need to turn off the firewall. The first one is the Windows Defender Firewall. The second is in “Windows Defender Firewall with Advanced Security” if you type “firewall” into the start menu.

The things I listed above are good things to check if you truly believe it is a communication issue. However, communication issues generally manifest themselves as your driver station not connecting to the robot at all. You indicated that the compressor was running, which means two things:

  • Your driver station is connected to the robot and they can communicate with each other.
  • Your driver station is connected to FMS and they can communicate with each other.

One interesting thing to note about the control system is that the FMS doesn’t actually talk directly to your robot. The FMS sends control packets (e.g. “enable the robot in teleop mode”) to the driver station, which relays that to the robot. The way most week zero events work, this communication is done in an almost identical fashion to how you would do it at home when connected wirelessly.

This is why most of the posts here are asking for logs and more information about your code- it is likely that something there is crashing or otherwise preventing your robot from behaving as expected.

Thank you all for your fantastic suggestions so far, we will be sure to go through them all when we meet tonight, will update then.

Just to confirm: if we get it working in practice mode, it should therefore work on the actual FMS?

This is a really important point. We made the mistake of using a laptop with last year’s driverstation installed for half of our week zero event. It worked fine–except that it didn’t relay the gamedata (of course) preventing our auto from working at all until semifinals (by which point we had upgraded that laptop)! We’re in the process of extirpating the 2017 driverstation from all team laptops.

This could easily be the OP’s problem. Combine the old driver station with the lack of string bounds checking in the auto initialization and BOOM.

Alright! We figured it out, thanks a ton everyone for your suggestions! 2 things helped fix it: first, we rebooted our Roborio via the software, and we realized that the week 0 event was not providing values on which side of the scale/switch was our alliance’s, and our auto code did not have a clause for no value sent, causing it to sit and wait forever (also explains why the compressor went off).

Thanks again all!!!