FMS Lite Warning

Last weekend, at the Battleship Blast offseason event, I noticed a possibly dangerous anomaly in the FMS (FMS Lite, per @DylanB).

First of all, my team, 696, also entered our practice robot as team 9696. This caused some problems initially, since we did not correctly reconfigure all of the networked devices on our practice bot to the 10.96.96.x subnet (we statically address everything). Unsurprisingly, when team 9696 connects to the FMS, a roboRIO at 10.6.96.2 will not respond correctly. Furthermore, because of the small number of teams (16) at the event, at least one of our robots was very often on the field (this will become significant later).

The dramatic anomalies occurred when attempting to run one of the robots tethered in the pit. I unfortunately don’t remember which robot, but I believe it was the practice bot, for reasons that should become obvious. First of all, on several occasions, the driver station would display the “FMS Connected…” message rather than the normal control pane expected when tethering. Second, and much more worryingly, the robot enabled in the pit, despite no action on the driver station, and in fact despite the driver station laptop being physically disconnected from the robot.

I believe that our practice robot’s radio actually reconnected to the field when it was powered on in the pit, and further that whatever FMS software was in use did not segregate communications into separate VLANs. Here’s my analysis:

  • Team 696, with a correctly-configured robot, is on the field
  • Team 9696 is testing robot functionality in the pit
  • The 9696 radio connects to the field when the robot is powered on
  • While the 9696 radio’s configuration is correct, the 9696 RoboRIO is statically addressed at 10.6.96.2, rather than 10.96.96.2
  • (The 9696 driver station may have also been incorrectly addressed in the 10.6.96 subnet, but I’m not sure)
  • As a result, some or all of the packets from the 696 driver station, on the field, ended up reaching the 9696 robot in the pit, leading to spurious enables.

Both of the problems (the driver station believing it was connected to the FMS during pit tethering, and the spurious enables) were corrected by disconnecting the robot radios while in the pit.

Battleship Blast was using FMS Lite/offseason FMS, not Cheesy Arena. Our radio also connected to the field when were in the pits, we worked around it by connecting the RIO to our laptop over USB. We only had one robot so we didn’t have any issues with packets going to the wrong bot. Unfortunately, we never had time to diagnose this issue.

1 Like

Thanks! Edited the post to reflect that.

This can happen for any offseason where the FMS signals are allowed to transmit over the wireless connections. Most offseasons don’t use vlans, but instead just use a normal wifi router. I know that chezy arena actually blocks the FMS packets over wifi for this reason. Its impossible to do on the FMS software side, and must be done on the router side, but it is possible. It’s port 1750 over TCP, and if that is blocked no FMS connection can occur. This is the actual solution, and the reason this never happens on a real field.

1 Like

That wouldn’t actually prevent a driver station on the field from enabling a robot in the pit, would it?

No, it would not prevent the robot from enabling in the pits. Furthermore even with Off-season FMS packets for 696 shouldn’t have been received by 9696. In addition, did 696 & 9696 do testing of 9696 receiving packets from 696’s ds(driver station) with field staff?

Is it also possible if you could send me the driver logs for both teams from the event? If so pm me so I can give you my email to send them to me.

No controlled testing. Matches were back-to-back and behind schedule, so priority was on preventing the robots from enabling unexpectedly, which was achieved by unplugging the radios.

Why wouldn’t 9696 receive packets intended for 696, since both were using the same IP address?

FMS considers 696 & 9696 as separate trams and both teams should have been programmed as 696 & 9696 respectively. Furthermore, the roborio’s and the radios would both have different IP addresses 10.6.96.2 and 10.96.96.2 .

I agree with you if everything was configured correctly. But the OP already said the IPs were identical on both the 696 and 9696 robots.

I know that both robots had the same up address I am trying to say that they should have had the IP address that I mentioned in my previous post.