From ca8e7d83a6a433ff857de77fe96672c42b436e05 Mon Sep 17 00:00:00 2001 From: jasondaming Date: Sun, 12 Oct 2025 15:40:34 -0500 Subject: [PATCH 1/4] 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 2cd1ee09cb0dc82ea0afd3f7304c8a584ebd98dd Mon Sep 17 00:00:00 2001 From: jasondaming Date: Mon, 13 Oct 2025 21:50:14 -0500 Subject: [PATCH 2/4] 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`. From e64be7898f8495834055f581ea806ef8c1d18780 Mon Sep 17 00:00:00 2001 From: jasondaming Date: Sun, 17 May 2026 22:33:44 -0500 Subject: [PATCH 3/4] Address PR review feedback from cswilson252 - fms-network-architecture: Fix Field Router/AP descriptions per suggestions; add FTA secondary AP note; simplify VLAN/security sections; remove Smart Router entry; fix mode name "test" -> "utility"; tone down wireless specs section - fms-ports-protocols: Remove all NT3/port 1735 references (NT3 removed in 2027); clean up NT table, packet prioritization, troubleshooting, and key takeaways - measuring-bandwidth-usage: Fix typo "he Last" -> "The Last" Co-Authored-By: Claude Sonnet 4.6 --- .../fms-network-architecture.rst | 29 +++++++------------ .../fms-ports-protocols.rst | 20 ++++--------- .../measuring-bandwidth-usage.rst | 2 +- 3 files changed, 17 insertions(+), 34 deletions(-) diff --git a/source/docs/networking/networking-introduction/fms-network-architecture.rst b/source/docs/networking/networking-introduction/fms-network-architecture.rst index 41e0db7a31..e2003a51e9 100644 --- a/source/docs/networking/networking-introduction/fms-network-architecture.rst +++ b/source/docs/networking/networking-introduction/fms-network-architecture.rst @@ -8,16 +8,15 @@ This article provides an overview of how the Field Management System (FMS) netwo 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 +- **Field Router**: Manages FMS network routing (VLANs) and traffic in/out of event internet uplink - **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 +- **Field Access Point (AP)**: Provide 6 GHz wireless connectivity to robots -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. +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. FTAs use a secondary AP with their wireless devices for field network debugging, that runs on either the 2.4GHz or 5GHz band depending on network congestion. ## Team Network Isolation -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. +FMS completely isolates each team's traffic from other teams. Each team's network contains **only** their robot, driver station, and the FMS server. .. 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. @@ -39,22 +38,14 @@ When connected to FMS, teams use the standard ``10.TE.AM.xx`` addressing scheme: ## 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) +- **Frequency Band**: 6 GHz - **Standard**: 802.11ax (Wi-Fi 6E) - **Encryption**: WPA3 with AES encryption -- **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 Keys**: Unique per team, per event (teams program their radio at event kiosks) ## Network Security -FMS uses several techniques to isolate team networks: - -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`) +Teams are isolated from each other through WPA3 encryption with per-team keys, and a field firewall that restricts which ports are available (see :doc:`fms-ports-protocols`). ## How FMS Coordinates Robot Communication @@ -70,7 +61,7 @@ When your robot connects to the field: 6. **Robot** sends status information back to the Driver Station 7. **Driver Station** sends status information back to the FMS -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. +The FMS tells your Driver Station what mode to use (auto/teleop/utility) and when to enable/disable the robot, but your Driver Station and robot communicate directly with each other. ## Bandwidth Allocation @@ -102,8 +93,8 @@ Your robot should work seamlessly in both environments if following standard :do ## Key Takeaways -- Each team's network is completely isolated in its own VLAN -- FMS uses 6 GHz Wi-Fi 6E to avoid interference +- Each team's network is completely isolated from other teams +- FMS uses 6 GHz Wi-Fi 6E; FTAs use a separate 2.4/5 GHz AP for debugging - 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 diff --git a/source/docs/networking/networking-introduction/fms-ports-protocols.rst b/source/docs/networking/networking-introduction/fms-ports-protocols.rst index e0d2313acc..59c4caa17f 100644 --- a/source/docs/networking/networking-introduction/fms-ports-protocols.rst +++ b/source/docs/networking/networking-introduction/fms-ports-protocols.rst @@ -32,9 +32,9 @@ These ports are used for essential robot operation and are always allowed: - TCP/UDP - Camera streams - IP Cameras, Driver Station - * - 1735 - - TCP - - SmartDashboard / Shuffleboard + * - 5810 + - TCP/UDP + - NetworkTables 4 - SmartDashboard, Shuffleboard * - 5353 - UDP @@ -47,8 +47,6 @@ These ports are used for essential robot operation and are always allowed: ## NetworkTables Ports -NetworkTables uses multiple ports for different protocol versions: - .. list-table:: :header-rows: 1 :widths: 15 15 50 20 @@ -57,10 +55,6 @@ NetworkTables uses multiple ports for different protocol versions: - Protocol - Purpose - Version - * - 1735 - - TCP - - NetworkTables 3 - - NT3 (legacy) * - 5810 - TCP - NetworkTables 4 (primary) @@ -70,8 +64,6 @@ NetworkTables uses multiple ports for different protocol versions: - 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: @@ -158,7 +150,7 @@ FMS prioritizes network traffic to ensure reliable robot control: - Joystick/gamepad data - These packets are **never** dropped or delayed -2. **Medium Priority**: NetworkTables data (ports 1735, 5810) +2. **Medium Priority**: NetworkTables data (port 5810) - Sensor readings sent to dashboard - Configuration values from dashboard @@ -216,7 +208,7 @@ See :doc:`windows-firewall-configuration` for detailed firewall setup instructio ## Common Port Issues **Problem**: Dashboard can't connect to robot -- **Check**: Firewall blocking port 5810 (NT4) or 1735 (NT3) +- **Check**: Firewall blocking port 5810 (NT4) - **Check**: mDNS not working (port 5353 blocked) **Problem**: Camera stream not visible @@ -232,7 +224,7 @@ 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) +- NetworkTables 4 uses port 5810 (TCP/UDP) - 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 diff --git a/source/docs/networking/networking-introduction/measuring-bandwidth-usage.rst b/source/docs/networking/networking-introduction/measuring-bandwidth-usage.rst index 61b0048d31..eeeb9c8bc9 100644 --- a/source/docs/networking/networking-introduction/measuring-bandwidth-usage.rst +++ b/source/docs/networking/networking-introduction/measuring-bandwidth-usage.rst @@ -59,7 +59,7 @@ In the ``Maximum Box`` under ``Vertical Scale`` enter 524288 (this is 4 Megabits .. image:: images/measuring-bandwidth-usage/graph.png :alt: Observing the bandwidth usage on the chart screen. -You may now connect to your robot as normal over the selected interface (if you haven't done so already). The graph will show the total bandwidth usage of the connection, with the bandwidth cap at the top of the graph. he Last, Average, Min, and Max values are also displayed at the bottom of the graph. Note that these values are in Bytes/Second meaning the cap is 524,288. With just the Driver Station open you should see a flat line at ~100000 Bytes/Second. +You may now connect to your robot as normal over the selected interface (if you haven't done so already). The graph will show the total bandwidth usage of the connection, with the bandwidth cap at the top of the graph. The Last, Average, Min, and Max values are also displayed at the bottom of the graph. Note that these values are in Bytes/Second meaning the cap is 524,288. With just the Driver Station open you should see a flat line at ~100000 Bytes/Second. ## Measuring Bandwidth Usage using Wireshark From 5b9d1a0d85766770406b6a81c81b9d9494bf53c3 Mon Sep 17 00:00:00 2001 From: jasondaming Date: Sun, 17 May 2026 23:48:06 -0500 Subject: [PATCH 4/4] Update FMS docs for 2027: remove roboRIO/SmartDashboard/Shuffleboard - Replace roboRIO with Systemcore throughout - Remove SmartDashboard and Shuffleboard references (both removed in 2027); use NT4 entries directly in code examples and Elastic/Glass in port table - Remove port 1110 from Core Ports table (it is FMS<->DS comm, not camera; already listed correctly in the Driver Station Ports table) - Update Web Interface Ports to reference Systemcore instead of roboRIO - Remove pinned year from game manual rule reference - Remove roboRIO-TEAM-FRC.local mDNS hostname (Systemcore hostname TBD) - Fix mode name test -> utility in packet prioritization section Co-Authored-By: Claude Sonnet 4.6 --- .../fms-network-architecture.rst | 4 +-- .../fms-ports-protocols.rst | 28 ++++++++----------- .../network-performance-optimization.rst | 10 +++---- 3 files changed, 18 insertions(+), 24 deletions(-) diff --git a/source/docs/networking/networking-introduction/fms-network-architecture.rst b/source/docs/networking/networking-introduction/fms-network-architecture.rst index e2003a51e9..9fe33e5fae 100644 --- a/source/docs/networking/networking-introduction/fms-network-architecture.rst +++ b/source/docs/networking/networking-introduction/fms-network-architecture.rst @@ -31,7 +31,7 @@ When connected to FMS, teams use the standard ``10.TE.AM.xx`` addressing scheme: **Robot Network (via Team Radio):** - Robot Radio: ``10.TE.AM.1`` (static) -- roboRIO: ``10.TE.AM.2`` (DHCP from robot radio) +- Systemcore: ``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 devices onboard the robot. @@ -55,7 +55,7 @@ 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 +3. **Systemcore** receives DHCP address ``10.TE.AM.2`` from robot radio 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 diff --git a/source/docs/networking/networking-introduction/fms-ports-protocols.rst b/source/docs/networking/networking-introduction/fms-ports-protocols.rst index 59c4caa17f..51a8ef79dc 100644 --- a/source/docs/networking/networking-introduction/fms-ports-protocols.rst +++ b/source/docs/networking/networking-introduction/fms-ports-protocols.rst @@ -2,7 +2,7 @@ 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. +.. important:: Port usage rules are defined in the FRC Game Manual. Always consult the current year's manual for official requirements. The `FMS Whitepaper `__ provides additional technical details. ## Core Robot Communication Ports @@ -16,10 +16,6 @@ These ports are used for essential robot operation and are always allowed: - Protocol - Purpose - Used By - * - 1110 - - TCP - - Camera data (roboRIO) - - WPILib CameraServer * - 1130 - UDP - Dashboard-to-Robot control @@ -27,7 +23,7 @@ These ports are used for essential robot operation and are always allowed: * - 1140 - UDP - Robot-to-Dashboard status - - roboRIO, Dashboards + - Robot controller, Dashboards * - 1180-1190 - TCP/UDP - Camera streams @@ -35,11 +31,11 @@ These ports are used for essential robot operation and are always allowed: * - 5810 - TCP/UDP - NetworkTables 4 - - SmartDashboard, Shuffleboard + - Elastic, Glass, custom dashboards * - 5353 - UDP - mDNS (multicast DNS) - - All devices (``roboRIO-TEAM-FRC.local``) + - All devices * - 5800-5810 - TCP/UDP - Team custom use @@ -66,7 +62,7 @@ These ports are used for essential robot operation and are always allowed: ## Driver Station Ports -The Driver Station uses these ports to communicate with the roboRIO and FMS: +The Driver Station uses these ports to communicate with the robot controller and FMS: .. list-table:: :header-rows: 1 @@ -89,7 +85,7 @@ The Driver Station uses these ports to communicate with the roboRIO and FMS: - Robot-to-DS status packets * - 1750 - TCP - - DS-to-roboRIO (webdash, imaging) + - DS-to-Systemcore (web interface) ## Vision Processing Ports @@ -106,7 +102,7 @@ Common ports used by vision processing systems: * - 1180-1190 - TCP/UDP - MJPEG camera streams - - Axis cameras, roboRIO + - Coprocessors, robot controller * - 5800-5807 - TCP - PhotonVision web interface @@ -131,10 +127,10 @@ These ports provide web-based configuration and monitoring: - Purpose * - 80 - TCP - - roboRIO Web Dashboard (HTTP) + - Systemcore Web Interface (HTTP) * - 443 - TCP - - roboRIO Web Dashboard (HTTPS) + - Systemcore Web Interface (HTTPS) * - 5800-5810 - TCP - Coprocessor web interfaces (PhotonVision, Limelight, etc.) @@ -146,7 +142,7 @@ 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) + - Mode selection (auto/teleop/utility) - Joystick/gamepad data - These packets are **never** dropped or delayed @@ -178,7 +174,7 @@ FMS prioritizes network traffic to ensure reliable robot control: - Higher latency than UDP **mDNS (Multicast DNS)** -- Allows devices to be found by name (``roboRIO-TEAM-FRC.local``) +- Allows devices to be found by name instead of IP address - Uses UDP port 5353 - No DNS server required - Essential for DHCP networks where IP addresses may change @@ -215,7 +211,7 @@ See :doc:`windows-firewall-configuration` for detailed firewall setup instructio - **Check**: Bandwidth limit exceeded (camera resolution too high) - **Check**: Firewall blocking ports 1180-1190 -**Problem**: Can't access roboRIO web dashboard +**Problem**: Can't access Systemcore web interface - **Check**: Firewall blocking port 80/443 - **Check**: Using HTTP (``http://10.TE.AM.2``) not HTTPS diff --git a/source/docs/networking/networking-introduction/network-performance-optimization.rst b/source/docs/networking/networking-introduction/network-performance-optimization.rst index c873c3c95f..f4d82365e4 100644 --- a/source/docs/networking/networking-introduction/network-performance-optimization.rst +++ b/source/docs/networking/networking-introduction/network-performance-optimization.rst @@ -86,26 +86,24 @@ NetworkTables is efficient by default, but poor usage patterns can waste bandwid // BAD: Updating every loop (50+ times per second) public void teleopPeriodic() { - SmartDashboard.putNumber("Encoder", encoder.get()); + encoderEntry.setDouble(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()); + encoderEntry.setDouble(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.encoder_entry.setDouble(current_position) self.last_position = current_position ### Data Selection @@ -155,7 +153,7 @@ 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 + private boolean competitionMode = true; // Set via NetworkTables entry public void robotPeriodic() { if (competitionMode) {