From cc4b1aef6b345acb9b0985b0cfa0a038ebdd5473 Mon Sep 17 00:00:00 2001 From: jasondaming Date: Sun, 12 Oct 2025 15:40:34 -0500 Subject: [PATCH 1/2] Add FMS network documentation summary pages MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Adds three new documentation pages summarizing key information from the FMS whitepaper: - fms-network-architecture.rst: Explains FMS network topology, VLANs, IP addressing, wireless specs, and security - fms-ports-protocols.rst: Reference table of network ports and protocols used by FMS and FRC software - network-performance-optimization.rst: Practical guidance for staying within 7 Mbps bandwidth limit These pages provide teams with essential FMS networking information without duplicating the full technical details from the FMS whitepaper. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude --- .../fms-network-architecture.rst | 124 +++++++++ .../fms-ports-protocols.rst | 241 ++++++++++++++++ .../networking-introduction/index.rst | 3 + .../network-performance-optimization.rst | 259 ++++++++++++++++++ 4 files changed, 627 insertions(+) create mode 100644 source/docs/networking/networking-introduction/fms-network-architecture.rst create mode 100644 source/docs/networking/networking-introduction/fms-ports-protocols.rst create mode 100644 source/docs/networking/networking-introduction/network-performance-optimization.rst diff --git a/source/docs/networking/networking-introduction/fms-network-architecture.rst b/source/docs/networking/networking-introduction/fms-network-architecture.rst new file mode 100644 index 0000000000..1fb31f4a52 --- /dev/null +++ b/source/docs/networking/networking-introduction/fms-network-architecture.rst @@ -0,0 +1,124 @@ +# Understanding the FMS Network Architecture + +This article provides an overview of how the Field Management System (FMS) network is structured at FRC competitions. Understanding this architecture helps teams troubleshoot connectivity issues and design robust networking solutions for their robots. + +.. note:: This article summarizes key information from the `FMS Whitepaper `__. For complete technical details, refer to the full whitepaper. + +## Network Topology Overview + +The FMS network is an Ethernet-based system that connects all robots, driver stations, and field equipment. The network centers around a **Score Switch** that manages traffic between: + +- **Field Router**: Connects to the FMS server and manages alliance networks +- **FMS Server**: Controls match flow and communicates with all robots +- **Field Access Points (APs)**: Provide 6 GHz wireless connectivity to robots +- **Smart Router**: Manages external connectivity and network services + +All competition field communication uses dedicated wireless access points operating in the 6 GHz band with 802.11ax (Wi-Fi 6E) to minimize interference from spectator devices. + +## VLAN Structure and Team Isolation + +The FMS network uses Virtual LANs (VLANs) to isolate each team's traffic: + +**Blue Alliance:** +- VLAN 10 (Station 1) +- VLAN 20 (Station 2) +- VLAN 30 (Station 3) + +**Red Alliance:** +- VLAN 40 (Station 1) +- VLAN 50 (Station 2) +- VLAN 60 (Station 3) + +**Administrative:** +- VLAN 100 (Field staff and equipment) + +.. important:: Each VLAN contains **only** the robot, driver station, and FMS server. Teams cannot communicate with other teams' robots or driver stations, even during the same match. + +## IP Addressing on the Field + +When connected to FMS, teams use the standard ``10.TE.AM.xx`` addressing scheme: + +**Field Network (DHCP Range):** +- Driver Station: ``10.TE.AM.20`` - ``10.TE.AM.199`` (assigned by FMS) +- Gateway: ``10.TE.AM.4`` +- Subnet Mask: ``255.255.255.0`` + +**Robot Network (via Team Radio):** +- Robot Radio: ``10.TE.AM.1`` (static) +- roboRIO: ``10.TE.AM.2`` (DHCP from robot radio) +- Other robot devices: ``10.TE.AM.200`` - ``10.TE.AM.219`` (DHCP from robot radio) + +.. note:: The Field Router does **not** provide DHCP services to robot devices. Your team's robot radio provides DHCP addressing for the robot network. + +## Wireless Specifications + +FMS wireless uses modern standards to ensure reliable connectivity: + +- **Frequency Band**: 6 GHz exclusively (avoids 2.4/5 GHz congestion from phones, tablets) +- **Standard**: 802.11ax (Wi-Fi 6E) +- **Encryption**: WPA3 with AES encryption +- **Security Keys**: Unique per team, per event (teams receive keys at check-in) + +.. warning:: Field staff devices use separate 2.4 GHz and 5 GHz networks. Robot radios must be configured for 6 GHz operation at competition. + +## Security Features + +FMS implements multiple security layers: + +1. **VLAN Isolation**: Teams cannot see or communicate with other teams' networks +2. **WPA3 Encryption**: All wireless traffic is encrypted with per-team keys +3. **Port Restrictions**: Only approved network ports are allowed (see :doc:`fms-ports-protocols`) +4. **Traffic Inspection**: FMS monitors network traffic for rules compliance + +These measures protect against accidental interference and ensure fair competition. + +## How Robot-to-FMS Communication Works + +When your robot connects to the field: + +1. **Driver Station** connects to field via Ethernet or field AP, receives DHCP address from FMS +2. **Robot Radio** connects to 6 GHz field AP using team-specific WPA3 key +3. **roboRIO** receives DHCP address ``10.TE.AM.2`` from robot radio +4. **FMS Server** establishes control connection with both DS and robot +5. **Driver Station** sends control packets through FMS to robot +6. **Robot** sends status information back through FMS to DS + +All control traffic is routed through the FMS server, which enforces match timing, enable/disable states, and mode selection (auto/teleop/test). + +## Bandwidth Allocation + +FMS allocates network bandwidth with the following limits: + +- **Per Team**: 7 Mbps maximum +- **Total Field**: 42 Mbps (across all 6 robots) + +Traffic is prioritized in this order: +1. Driver Station control packets (highest priority) +2. NetworkTables data +3. Camera streams and custom data (lowest priority) + +See :doc:`network-performance-optimization` for guidance on staying within bandwidth limits. + +## Field vs. Pits Networking + +**On the Field:** +- FMS provides DHCP for driver stations +- Robot radio provides DHCP for robot devices +- All traffic monitored and controlled by FMS + +**In the Pits:** +- Only your robot radio provides DHCP +- No FMS server present +- Devices may fall back to link-local (``169.254.x.x``) if misconfigured + +Your robot should work seamlessly in both environments if following standard :doc:`ip-configurations`. + +## Key Takeaways + +- Each team's network is completely isolated in its own VLAN +- FMS uses 6 GHz Wi-Fi 6E to avoid interference +- Your robot radio provides DHCP for robot devices; FMS provides DHCP for driver stations +- Bandwidth is limited to 7 Mbps per team with prioritized traffic types +- Standard ``10.TE.AM.xx`` addressing works on field and in pits + +For port-specific information, see :doc:`fms-ports-protocols`. For performance optimization, see :doc:`network-performance-optimization`. diff --git a/source/docs/networking/networking-introduction/fms-ports-protocols.rst b/source/docs/networking/networking-introduction/fms-ports-protocols.rst new file mode 100644 index 0000000000..e0d2313acc --- /dev/null +++ b/source/docs/networking/networking-introduction/fms-ports-protocols.rst @@ -0,0 +1,241 @@ +# FMS Network Ports and Protocols + +This article provides a reference for network ports and protocols used by the Field Management System (FMS) and common FRC software. Understanding these ports helps with firewall configuration, custom software development, and network troubleshooting. + +.. important:: Port usage rules are defined in the FRC Game Manual (Rule R704 for 2024). Always consult the current year's manual for official requirements. The `FMS Whitepaper `__ provides additional technical details. + +## Core Robot Communication Ports + +These ports are used for essential robot operation and are always allowed: + +.. list-table:: + :header-rows: 1 + :widths: 15 15 50 20 + + * - Port(s) + - Protocol + - Purpose + - Used By + * - 1110 + - TCP + - Camera data (roboRIO) + - WPILib CameraServer + * - 1130 + - UDP + - Dashboard-to-Robot control + - Driver Station, Dashboards + * - 1140 + - UDP + - Robot-to-Dashboard status + - roboRIO, Dashboards + * - 1180-1190 + - TCP/UDP + - Camera streams + - IP Cameras, Driver Station + * - 1735 + - TCP + - SmartDashboard / Shuffleboard + - SmartDashboard, Shuffleboard + * - 5353 + - UDP + - mDNS (multicast DNS) + - All devices (``roboRIO-TEAM-FRC.local``) + * - 5800-5810 + - TCP/UDP + - Team custom use + - Custom team software + +## NetworkTables Ports + +NetworkTables uses multiple ports for different protocol versions: + +.. list-table:: + :header-rows: 1 + :widths: 15 15 50 20 + + * - Port(s) + - Protocol + - Purpose + - Version + * - 1735 + - TCP + - NetworkTables 3 + - NT3 (legacy) + * - 5810 + - TCP + - NetworkTables 4 (primary) + - NT4 (current) + * - 5810 + - UDP + - NetworkTables 4 (discovery) + - NT4 (current) + +.. note:: NetworkTables 4 is the current standard. NetworkTables 3 (port 1735) is maintained for backwards compatibility with older dashboards. + +## Driver Station Ports + +The Driver Station uses these ports to communicate with the roboRIO and FMS: + +.. list-table:: + :header-rows: 1 + :widths: 15 15 50 + + * - Port + - Protocol + - Purpose + * - 1110-1115 + - UDP + - FMS-to-Robot control + * - 1120-1125 + - UDP + - Robot-to-FMS status + * - 1130 + - UDP + - DS-to-Robot control packets + * - 1140 + - UDP + - Robot-to-DS status packets + * - 1750 + - TCP + - DS-to-roboRIO (webdash, imaging) + +## Vision Processing Ports + +Common ports used by vision processing systems: + +.. list-table:: + :header-rows: 1 + :widths: 15 15 50 20 + + * - Port(s) + - Protocol + - Purpose + - Device + * - 1180-1190 + - TCP/UDP + - MJPEG camera streams + - Axis cameras, roboRIO + * - 5800-5807 + - TCP + - PhotonVision web interface + - PhotonVision coprocessor + * - 5800-5807 + - TCP + - Limelight web interface + - Limelight camera + +.. note:: Vision coprocessors also use NetworkTables (port 5810) to send targeting data to the robot. + +## Web Interface Ports + +These ports provide web-based configuration and monitoring: + +.. list-table:: + :header-rows: 1 + :widths: 15 15 50 + + * - Port + - Protocol + - Purpose + * - 80 + - TCP + - roboRIO Web Dashboard (HTTP) + * - 443 + - TCP + - roboRIO Web Dashboard (HTTPS) + * - 5800-5810 + - TCP + - Coprocessor web interfaces (PhotonVision, Limelight, etc.) + +## Packet Prioritization + +FMS prioritizes network traffic to ensure reliable robot control: + +1. **Highest Priority**: Driver Station control packets (ports 1110-1115, 1130) + + - Robot enable/disable commands + - Mode selection (auto/teleop/test) + - Joystick/gamepad data + - These packets are **never** dropped or delayed + +2. **Medium Priority**: NetworkTables data (ports 1735, 5810) + + - Sensor readings sent to dashboard + - Configuration values from dashboard + - Vision targeting information + - May be throttled if bandwidth limit exceeded + +3. **Lowest Priority**: Camera streams and custom data (ports 1180-1190, 5800-5810) + + - MJPEG video streams + - Custom telemetry data + - May be significantly throttled or dropped if bandwidth limit exceeded + +.. important:: To ensure reliable robot control, keep NetworkTables and camera bandwidth low. See :doc:`network-performance-optimization` for optimization strategies. + +## Protocol Details + +**UDP (User Datagram Protocol)** +- Used for time-sensitive data (control packets, status updates) +- No guaranteed delivery, but lower latency +- Preferred for real-time robot control + +**TCP (Transmission Control Protocol)** +- Used for reliable data transfer (NetworkTables, camera streams, web interfaces) +- Guaranteed delivery with automatic retransmission +- Higher latency than UDP + +**mDNS (Multicast DNS)** +- Allows devices to be found by name (``roboRIO-TEAM-FRC.local``) +- Uses UDP port 5353 +- No DNS server required +- Essential for DHCP networks where IP addresses may change + +## Firewall Configuration + +For PC-based tools (Driver Station, dashboards, imaging tools) to work properly, your firewall must allow: + +- **All ports listed above** for the ``10.0.0.0/8`` IP range (``10.TE.AM.xx`` addresses) +- **UDP port 5353** for mDNS (for ``.local`` hostname resolution) +- **Link-local range** ``169.254.0.0/16`` (for direct connections without DHCP) + +See :doc:`windows-firewall-configuration` for detailed firewall setup instructions. + +## Port Usage Rules + +.. warning:: The FRC Game Manual restricts which ports teams may use. Always verify port usage against the current year's rules (typically Rule R704). + +**Generally Allowed:** +- Ports listed in the tables above (WPILib standard ports) +- Ports 5800-5810 for custom team use + +**Restricted:** +- Ports outside the approved ranges may be blocked by FMS +- Using non-standard ports may prevent your robot from functioning on the field + +## Common Port Issues + +**Problem**: Dashboard can't connect to robot +- **Check**: Firewall blocking port 5810 (NT4) or 1735 (NT3) +- **Check**: mDNS not working (port 5353 blocked) + +**Problem**: Camera stream not visible +- **Check**: Bandwidth limit exceeded (camera resolution too high) +- **Check**: Firewall blocking ports 1180-1190 + +**Problem**: Can't access roboRIO web dashboard +- **Check**: Firewall blocking port 80/443 +- **Check**: Using HTTP (``http://10.TE.AM.2``) not HTTPS + +For more troubleshooting guidance, see :doc:`roborio-network-troubleshooting`. + +## Key Takeaways + +- Driver Station control packets (ports 1110-1115, 1130) have highest priority +- NetworkTables 4 uses port 5810 (TCP/UDP); NT3 uses port 1735 (TCP) +- Camera streams (ports 1180-1190) are lowest priority and may be throttled +- mDNS (port 5353) is essential for ``.local`` hostname resolution +- Ports 5800-5810 are reserved for team custom use +- Always consult the current Game Manual for official port restrictions + +For bandwidth optimization, see :doc:`network-performance-optimization`. For IP addressing details, see :doc:`ip-configurations`. diff --git a/source/docs/networking/networking-introduction/index.rst b/source/docs/networking/networking-introduction/index.rst index dccbcf3eeb..2eccd73097 100644 --- a/source/docs/networking/networking-introduction/index.rst +++ b/source/docs/networking/networking-introduction/index.rst @@ -7,6 +7,9 @@ This section outlines basic robot configuration and usage relating to communicat networking-basics ip-configurations + fms-network-architecture + fms-ports-protocols + network-performance-optimization roborio-network-troubleshooting windows-firewall-configuration measuring-bandwidth-usage diff --git a/source/docs/networking/networking-introduction/network-performance-optimization.rst b/source/docs/networking/networking-introduction/network-performance-optimization.rst new file mode 100644 index 0000000000..c873c3c95f --- /dev/null +++ b/source/docs/networking/networking-introduction/network-performance-optimization.rst @@ -0,0 +1,259 @@ +# Optimizing Network Performance at Competition + +This article provides practical guidance for staying within FMS bandwidth limits and ensuring reliable robot communication at competition. Following these recommendations will help prevent connectivity issues and improve overall robot performance. + +## Understanding Bandwidth Limits + +The Field Management System (FMS) enforces strict bandwidth limits to ensure all robots can communicate reliably: + +- **Per Team**: 7 Mbps maximum +- **Total Field**: 42 Mbps (shared across all 6 robots) + +.. important:: Exceeding your bandwidth allocation can cause control packets to be delayed or dropped, resulting in robot disconnections or poor responsiveness. + +For detailed information about how FMS manages network traffic, see :doc:`fms-network-architecture`. + +## Traffic Prioritization + +FMS prioritizes network traffic in this order: + +1. **Driver Station control packets** (highest priority) - never throttled +2. **NetworkTables data** - throttled if bandwidth exceeded +3. **Camera streams and custom data** - heavily throttled if bandwidth exceeded + +.. note:: While control packets are protected, excessive bandwidth usage from cameras or NetworkTables can still affect overall robot performance by saturating your network connection. + +## Camera Stream Optimization + +Camera streams are typically the largest consumer of bandwidth. Follow these guidelines: + +### Resolution and Frame Rate + +**Recommended Settings:** +- Resolution: 320x240 or 160x120 for driver cameras +- Frame rate: 15-20 fps (avoid 30 fps unless necessary) +- Compression: Medium to high JPEG compression + +**Example Bandwidth Usage:** +- 320x240 @ 15 fps = ~2-3 Mbps +- 640x480 @ 30 fps = ~6-8 Mbps (uses almost entire allocation!) +- 160x120 @ 15 fps = ~0.5-1 Mbps + +.. code-block:: java + + // Example: Configure camera for competition bandwidth + UsbCamera camera = CameraServer.startAutomaticCapture(); + camera.setResolution(320, 240); + camera.setFPS(15); + +.. warning:: Streaming multiple high-resolution cameras simultaneously will almost certainly exceed the 7 Mbps limit. Use lower resolutions or disable extra cameras during matches. + +### Vision Processing Cameras + +For vision processing cameras (Limelight, PhotonVision, etc.): + +- Stream **processed output only**, not raw camera feed +- Use the vision processor's built-in stream (already optimized) +- Disable unnecessary dashboard streams during matches +- Send targeting data via NetworkTables (minimal bandwidth) instead of streaming annotated video + +### Camera Best Practices + +.. list-table:: + :header-rows: 1 + :widths: 50 50 + + * - Do + - Don't + * - Use 320x240 or lower resolution + - Stream 720p or 1080p video + * - Limit to 15-20 fps + - Use 30+ fps unnecessarily + * - Stream only essential cameras + - Stream multiple cameras simultaneously + * - Use medium/high JPEG compression + - Use lossless or low compression + * - Disable streams when not needed + - Leave all cameras running all the time + +## NetworkTables Optimization + +NetworkTables is efficient by default, but poor usage patterns can waste bandwidth: + +### Update Rates + +.. code-block:: java + + // BAD: Updating every loop (50+ times per second) + public void teleopPeriodic() { + SmartDashboard.putNumber("Encoder", encoder.get()); + } + + // GOOD: Update at lower frequency (10 times per second) + public void teleopPeriodic() { + counter++; + if (counter % 5 == 0) { // Every 5th loop = ~10 Hz + SmartDashboard.putNumber("Encoder", encoder.get()); + } + } + +.. code-block:: python + + # GOOD: Only update when value changes significantly + last_position = 0 + + def teleopPeriodic(self): + current_position = self.encoder.get() + if abs(current_position - self.last_position) > 0.1: + SmartDashboard.putNumber("Encoder", current_position) + self.last_position = current_position + +### Data Selection + +**Publish Only What's Needed:** +- Dashboard displays should show only essential information during matches +- Debug data should be disabled or reduced during competition +- Avoid publishing large arrays or strings frequently + +**Use Appropriate Data Types:** +- Booleans use less bandwidth than doubles +- Integers use less bandwidth than strings +- Avoid sending redundant data (e.g., both raw sensor value and calculated result if one can be derived) + +### NetworkTables Best Practices + +.. list-table:: + :header-rows: 1 + :widths: 50 50 + + * - Do + - Don't + * - Update at 10 Hz or less + - Update every robot loop (50 Hz) + * - Update only when values change + - Always publish, even if unchanged + * - Use booleans and numbers + - Use strings or large arrays + * - Publish essential data only + - Publish all debug data during matches + +## Measuring Your Bandwidth Usage + +Use the :doc:`measuring-bandwidth-usage` tools to verify your robot stays under the 7 Mbps limit: + +1. Connect to your robot as if at competition (via radio) +2. Enable your robot and drive as you would during a match +3. Use the bandwidth measurement tool to monitor usage +4. Identify and optimize any high-bandwidth sources + +.. note:: Test with all cameras and telemetry enabled as they would be during a real match, not just with minimal systems. + +## Disabling Bandwidth-Heavy Features + +Consider creating a "competition mode" that disables non-essential features: + +.. code-block:: java + + public class Robot extends TimedRobot { + private boolean competitionMode = true; // Set via dashboard or SmartDashboard + + public void robotPeriodic() { + if (competitionMode) { + // Disable extra cameras + secondaryCamera.setConnectionStrategy(ConnectionStrategy.kKeepOpen); + // Reduce telemetry update rate + telemetryCounter++; + if (telemetryCounter % 10 == 0) { + updateTelemetry(); + } + } else { + // Full telemetry for testing + updateTelemetry(); + } + } + } + +.. code-block:: python + + class MyRobot(wpilib.TimedRobot): + def robotInit(self): + self.competition_mode = True + + def robotPeriodic(self): + if self.competition_mode: + # Reduce update frequency + if self.telemetry_counter % 10 == 0: + self.update_telemetry() + else: + self.update_telemetry() + +## Common Bandwidth Problems and Solutions + +**Problem**: Robot disconnects intermittently during matches +- **Likely Cause**: Bandwidth exceeded, causing control packet delays +- **Solution**: Reduce camera resolution/frame rate, lower NetworkTables update frequency + +**Problem**: Dashboard updates slowly or freezes +- **Likely Cause**: Too much NetworkTables data or camera stream saturating connection +- **Solution**: Publish less data, lower camera bandwidth + +**Problem**: Camera stream is choppy or stutters +- **Likely Cause**: Other traffic (NetworkTables) competing for bandwidth +- **Solution**: Lower camera frame rate, reduce NetworkTables updates + +**Problem**: Vision processing delays +- **Likely Cause**: Network latency from bandwidth saturation +- **Solution**: Process vision on coprocessor, send only targeting data via NetworkTables + +## Competition Day Checklist + +Before each match, verify: + +- [ ] Camera resolution set to 320x240 or lower +- [ ] Camera frame rate set to 15-20 fps +- [ ] Only essential cameras enabled +- [ ] NetworkTables updates at 10 Hz or less +- [ ] Bandwidth measured under 7 Mbps during practice +- [ ] Non-essential debug telemetry disabled +- [ ] Dashboard showing only essential match data + +## Bandwidth Budget Example + +Here's a sample bandwidth allocation that stays well under the 7 Mbps limit: + +.. list-table:: + :header-rows: 1 + :widths: 40 30 30 + + * - System + - Bandwidth + - Notes + * - Driver Station Control + - ~0.1 Mbps + - Always prioritized + * - Driver Camera (320x240 @ 15 fps) + - 2.5 Mbps + - Primary driver view + * - NetworkTables (10 Hz updates) + - 0.2 Mbps + - Essential telemetry only + * - Vision Targeting Data + - 0.1 Mbps + - Processed results via NT + * - **Total** + - **2.9 Mbps** + - **Well under 7 Mbps limit** + +This leaves ~4 Mbps of headroom for bursts and ensures reliable communication. + +## Key Takeaways + +- Keep total bandwidth under 7 Mbps (measure to verify) +- Use 320x240 @ 15 fps for driver cameras +- Update NetworkTables at 10 Hz or less +- Publish only essential data during matches +- Test bandwidth usage before competition +- Create a "competition mode" to disable non-essential features +- Remember: control packets are protected, but bandwidth saturation still causes problems + +For more details on network architecture, see :doc:`fms-network-architecture`. For port and protocol information, see :doc:`fms-ports-protocols`. From c1ba58da953255ba221d88846dd3fb1b206284db Mon Sep 17 00:00:00 2001 From: jasondaming Date: Mon, 13 Oct 2025 21:50:14 -0500 Subject: [PATCH 2/2] Address review feedback on FMS network architecture documentation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Key changes: - Clarified FMS Server communicates with Driver Station software, not robots directly - Changed "Field Access Points" to singular "Field Access Point" - Simplified VLAN section to focus on isolation rather than specific VLAN numbers - Updated wireless section to clarify only robot communication uses the 6 GHz AP - Changed WPA3 key distribution to mention teams use event kiosks to configure radios - Removed "advertisey" language and incorrect traffic monitoring claims from security section - Rewrote communication flow using "conductor" analogy: FMS tells DS what to do, but DS communicates directly with robot - Corrected communication flow steps to reflect DS-robot direct communication with FMS coordinating - Updated field firewall description to clarify it restricts ports, doesn't monitor/control all traffic - Improved field vs pits section to be more practical and accurate All changes verified against FMS whitepaper for technical accuracy. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude --- .../fms-network-architecture.rst | 59 ++++++++----------- 1 file changed, 23 insertions(+), 36 deletions(-) diff --git a/source/docs/networking/networking-introduction/fms-network-architecture.rst b/source/docs/networking/networking-introduction/fms-network-architecture.rst index 1fb31f4a52..41e0db7a31 100644 --- a/source/docs/networking/networking-introduction/fms-network-architecture.rst +++ b/source/docs/networking/networking-introduction/fms-network-architecture.rst @@ -6,33 +6,20 @@ This article provides an overview of how the Field Management System (FMS) netwo ## Network Topology Overview -The FMS network is an Ethernet-based system that connects all robots, driver stations, and field equipment. The network centers around a **Score Switch** that manages traffic between: +The FMS network is an Ethernet-based system that connects all robots, driver stations, and field equipment. The **Score Switch** connects the following components: - **Field Router**: Connects to the FMS server and manages alliance networks -- **FMS Server**: Controls match flow and communicates with all robots -- **Field Access Points (APs)**: Provide 6 GHz wireless connectivity to robots +- **FMS Server**: Controls match flow and communicates with Driver Station software +- **Field Access Point (AP)**: Provides 6 GHz wireless connectivity to robots - **Smart Router**: Manages external connectivity and network services -All competition field communication uses dedicated wireless access points operating in the 6 GHz band with 802.11ax (Wi-Fi 6E) to minimize interference from spectator devices. +Robot-to-field communication uses a dedicated wireless access point operating in the 6 GHz band with 802.11ax (Wi-Fi 6E) to minimize interference from spectator devices. -## VLAN Structure and Team Isolation +## Team Network Isolation -The FMS network uses Virtual LANs (VLANs) to isolate each team's traffic: +The FMS network uses Virtual LANs (VLANs) to completely isolate each team's traffic. Each team's network contains **only** their robot, driver station, and the FMS server. -**Blue Alliance:** -- VLAN 10 (Station 1) -- VLAN 20 (Station 2) -- VLAN 30 (Station 3) - -**Red Alliance:** -- VLAN 40 (Station 1) -- VLAN 50 (Station 2) -- VLAN 60 (Station 3) - -**Administrative:** -- VLAN 100 (Field staff and equipment) - -.. important:: Each VLAN contains **only** the robot, driver station, and FMS server. Teams cannot communicate with other teams' robots or driver stations, even during the same match. +.. important:: Teams cannot communicate with other teams' robots or driver stations, even during the same match. This isolation protects against accidental interference and ensures fair competition. ## IP Addressing on the Field @@ -48,7 +35,7 @@ When connected to FMS, teams use the standard ``10.TE.AM.xx`` addressing scheme: - roboRIO: ``10.TE.AM.2`` (DHCP from robot radio) - Other robot devices: ``10.TE.AM.200`` - ``10.TE.AM.219`` (DHCP from robot radio) -.. note:: The Field Router does **not** provide DHCP services to robot devices. Your team's robot radio provides DHCP addressing for the robot network. +.. note:: The Field Router does **not** provide DHCP services to robot devices. Your team's robot radio provides DHCP addressing for devices onboard the robot. ## Wireless Specifications @@ -57,33 +44,33 @@ FMS wireless uses modern standards to ensure reliable connectivity: - **Frequency Band**: 6 GHz exclusively (avoids 2.4/5 GHz congestion from phones, tablets) - **Standard**: 802.11ax (Wi-Fi 6E) - **Encryption**: WPA3 with AES encryption -- **Security Keys**: Unique per team, per event (teams receive keys at check-in) +- **Security Keys**: Unique per team, per event (teams configure radios using event kiosks) .. warning:: Field staff devices use separate 2.4 GHz and 5 GHz networks. Robot radios must be configured for 6 GHz operation at competition. -## Security Features +## Network Security -FMS implements multiple security layers: +FMS uses several techniques to isolate team networks: -1. **VLAN Isolation**: Teams cannot see or communicate with other teams' networks -2. **WPA3 Encryption**: All wireless traffic is encrypted with per-team keys -3. **Port Restrictions**: Only approved network ports are allowed (see :doc:`fms-ports-protocols`) -4. **Traffic Inspection**: FMS monitors network traffic for rules compliance +1. **VLAN Isolation**: Each team's network is completely separated from other teams +2. **WPA3 Encryption**: Wireless traffic is encrypted with per-team keys +3. **Port Restrictions**: Only approved network ports are allowed through the field firewall (see :doc:`fms-ports-protocols`) -These measures protect against accidental interference and ensure fair competition. +## How FMS Coordinates Robot Communication -## How Robot-to-FMS Communication Works +Think of FMS as a conductor - it tells each Driver Station when to start and stop, but the Driver Station communicates directly with the robot to "make the music." FMS initially sets up the communication, like a conductor pairing musicians with their instruments. When your robot connects to the field: 1. **Driver Station** connects to field via Ethernet or field AP, receives DHCP address from FMS 2. **Robot Radio** connects to 6 GHz field AP using team-specific WPA3 key 3. **roboRIO** receives DHCP address ``10.TE.AM.2`` from robot radio -4. **FMS Server** establishes control connection with both DS and robot -5. **Driver Station** sends control packets through FMS to robot -6. **Robot** sends status information back through FMS to DS +4. **FMS Server** establishes connection with the Driver Station software and begins sending control packets to the Driver Station software +5. **Driver Station** sends control packets to the robot, corresponding to the FMS-commanded mode +6. **Robot** sends status information back to the Driver Station +7. **Driver Station** sends status information back to the FMS -All control traffic is routed through the FMS server, which enforces match timing, enable/disable states, and mode selection (auto/teleop/test). +The FMS tells your Driver Station what mode to use (auto/teleop/test) and when to enable/disable the robot, but your Driver Station and robot communicate directly with each other. ## Bandwidth Allocation @@ -104,12 +91,12 @@ See :doc:`network-performance-optimization` for guidance on staying within bandw **On the Field:** - FMS provides DHCP for driver stations - Robot radio provides DHCP for robot devices -- All traffic monitored and controlled by FMS +- Field firewall restricts which ports can be used **In the Pits:** - Only your robot radio provides DHCP - No FMS server present -- Devices may fall back to link-local (``169.254.x.x``) if misconfigured +- All ports are available for debugging Your robot should work seamlessly in both environments if following standard :doc:`ip-configurations`.