3.4 Communications Protocol

This section explains how a team’s Operator Control Station (OCS) connects to and communicates with RoboCommand during RobotX 2026.

RoboCommand exchanges course information, run-control commands, vehicle status, and task reports with the OCS. The OCS is responsible for exchanging the relevant information with the team’s vehicles through the team’s own communications system.

Only the OCS connects to RoboCommand. Team vehicles must not connect directly to the RoboCommand network or MQTT broker.

3.4.1 Communications Architecture

The team communications path is:

Team vehicles ⇄ Team OCS ⇄ RoboCommand

• The OCS is the team’s network endpoint and MQTT client.
• The OCS publishes requests and vehicle-attributed reports to RoboCommand.
• The OCS subscribes to course configuration and team-addressed commands from RoboCommand.
• A vehicle_id identifies the vehicle represented by a message; it does not identify a separate RoboCommand network connection.
• The team determines how its OCS communicates with its USV, UUV, UAV, and other systems.
• Additional OCS interfaces and all OCS-to-vehicle networking are outside the scope of this guide.

3.4.2 Competition and Demonstration Networks

RobotX provides four isolated competition course networks: Alpha, Bravo, Charlie, and Delta. Each course has a dedicated RoboCommand computer.

Only one team is active on a course at a time. That team’s OCS is the only team system permitted to connect to the course’s RoboCommand network.

Team Village provides a separate Demo RoboCommand system for integration testing. Multiple teams may connect to the demo environment at the same time. Teams must therefore use their assigned team_id in every topic and message so their traffic remains distinguishable.

Location	Team network	OCS address assignment	RoboCommand address
Course Alpha	192.168.65.0/24	DHCP: 192.168.65.15–192.168.65.254	192.168.65.2
Course Bravo	192.168.66.0/24	DHCP: 192.168.66.15–192.168.66.254	192.168.66.2
Course Charlie	192.168.67.0/24	DHCP: 192.168.67.15–192.168.67.254	192.168.67.2
Course Delta	192.168.68.0/24	DHCP: 192.168.68.15–192.168.68.254	192.168.68.2
Team Village demo	Demo network, VLAN 70	DHCP	Provided with the demo connection instructions

Course networks carry course data only and do not provide Internet access.

3.4.3 Configure the OCS Network Interface

The Ethernet interface connected to the RoboCommand network must be configured as a DHCP client.

1. Select the physical Ethernet interface that will connect to the provided RJ-45 cable.
2. Enable automatic IPv4 address assignment using DHCP.
3. Enable automatic gateway and DNS assignment.
4. Disable Internet-connection sharing, network bridging, and DHCP-server functions on that interface.
5. Connect the provided RJ-45 cable.
6. Confirm that the OCS receives an address in the subnet for the assigned course.
7. Confirm that the assigned default gateway is the course RoboCommand address shown in the table above.
8. Start the team’s RoboCommand communications application on the OCS.

Do not configure a static course address. DHCP allows the same OCS configuration to operate on Alpha, Bravo, Charlie, Delta, and the Team Village demo network.

An OCS may use other interfaces for vehicle links or team systems. Their configuration is the team’s responsibility and must not route, bridge, or expose those networks through the RoboCommand-facing interface.

3.4.4 MQTT and Protocol Buffers

The message definitions and test server are available in the RoboCommand Repo

RoboCommand messages are transported using MQTT. Each MQTT payload is a binary message serialized using Protocol Buffers (protobuf).

Protocol Buffers provide a language-neutral message definition:

1. RoboNation supplies versioned .proto schema files.
2. The team runs the Protocol Buffers compiler, protoc, or uses the supplied generated classes.
3. The OCS application creates a message using the generated class.
4. The application serializes the message to bytes.
5. The OCS publishes those bytes to the required MQTT topic.
6. For received messages, the OCS selects the correct generated class and parses the MQTT payload.

The current repository contains schemas for:

• Common position, robot-state, and task-tier values
• RobotX task, vehicle-type, beacon, pipeline, resource-color, and flight-phase values
• Course configuration
• Team requests
• RoboCommand commands
• Vehicle-attributed status and task reports

Use the competition-provided schema release without changing package names, field numbers, enum values, or MQTT topic names. Protocol Buffer field numbers are part of the wire format.

3.4.5 MQTT Connection

The OCS connects to the RoboCommand MQTT broker using the address for its current course. The current RobotX communications package uses MQTT over TCP port 1883.

The team should maintain one OCS connection and use it for all required subscriptions and publications. If the connection is interrupted, the OCS should reconnect automatically and restore its subscriptions.

The team should publish no more than five(5) messages per second per system unless otherwise specified.

The OCS should not assume that it will retain the same DHCP address after moving to another course or reconnecting. The application should use the configured RoboCommand address rather than binding its logic to the OCS address.

3.4.6 MQTT Topics

All RobotX 2026 topics use the root:

robocommand/robotx

Purpose	MQTT topic	Direction
Course configuration	robocommand/robotx/course	RoboCommand → OCS
Vehicle-attributed report	robocommand/robotx/<team_id>/<vehicle_id>/report	OCS → RoboCommand
Team request	robocommand/robotx/<team_id>/request	OCS → RoboCommand
Team command	robocommand/robotx/<team_id>/command	RoboCommand → OCS

Replace:

• <team_id> with the team identifier assigned by RoboNation.
• <vehicle_id> with the unique identifier declared for the represented vehicle.

For example, a report attributed to vehicle USV1 for team RNRX is published to:

robocommand/robotx/RNRX/USV1/report

The OCS should subscribe to:

robocommand/robotx/course
robocommand/robotx/<team_id>/command

The OCS must not subscribe to or act on another team’s topic namespace.

3.4.7 Message Envelopes

RobotX messages use four top-level protobuf envelopes.

Envelope	Purpose	Publisher
RxCourse	Current course identifier, boundary, and pinger frequency	RoboCommand
RxRequest	Team-level requests, including RunDeclaration	OCS
RxCommand	Run start and Task 4 commands	RoboCommand
RxReport	Heartbeats and task reports attributed to a vehicle	OCS

RxRequest, RxCommand, and RxReport contain a oneof body. Only one body type is valid in each envelope instance.

Every published message must use the correct topic, envelope type, team_id, sequence number, timestamp, and—where applicable—vehicle_id.

3.4.8 Identifiers, Sequence Numbers, and Time

Team and vehicle identifiers

• Use the assigned team_id exactly as issued.
• Use stable, unique vehicle identifiers throughout a run.
• Include every participating vehicle ID in RunDeclaration.
• Use the same vehicle ID in the MQTT report topic and the RxReport.vehicle_id field.

Sequence numbers

• RxRequest.seq is a monotonically increasing team-request sequence.
• RxCommand.seq is maintained by RoboCommand for the addressed team.
• RxReport.seq is scoped per vehicle; each represented vehicle has its own increasing report sequence.
• Acknowledgments and confirmations must reference the sequence number specified by their message definitions.

Timestamps

Set sent_at to the time the OCS publishes the message. Use the protobuf google.protobuf.Timestamp type and keep the OCS clock synchronized.

3.4.9 Course Configuration

RoboCommand publishes RxCourse on:

robocommand/robotx/course

The message is retained by the MQTT broker. After the OCS subscribes, it should receive the current course configuration without waiting for a new publication.

RxCourse includes:

• course_id
• Acoustic pinger frequency in hertz
• Ordered latitude/longitude corners of the course boundary
• Publication timestamp

The first and last boundary points are the same, closing the polygon.

The OCS should validate the course identifier and configuration before beginning a run. The team determines how the OCS distributes relevant course information to its vehicles.

3.4.10 Pre-Run Declaration and Run Start

Before a run begins, the OCS publishes one RxRequest containing RunDeclaration.

The declaration identifies:

• Every vehicle participating in the run
• The tier attempted for Task 1
• The tier attempted for Task 2
• The tier attempted for Task 3
• The tier attempted for Task 4
• The UAV geofence polygon

Use TIER_NONE when the team is not attempting a task. Do not use TIER_UNKNOWN as a substitute for TIER_NONE.

The UAV geofence must be a closed polygon whose first and last points are identical. RoboCommand validates the geofence against the course boundary.

The normal start sequence is:

1. The OCS connects to the course RoboCommand broker.
2. The OCS subscribes to RxCourse and its team command topic.
3. The OCS receives and validates RxCourse.
4. The OCS publishes RunDeclaration.
5. The OCS publishes heartbeats for all declared vehicles.
6. Each declared vehicle’s heartbeat reports STATE_AUTO when that vehicle is autonomous and ready.
7. RoboCommand publishes RunStart after the run-start conditions are satisfied.
8. The OCS verifies that RunStart.declaration_seq matches the declaration it sent.
9. The OCS records the assigned run_id and begins official run processing.

All vehicles should position-hold after switching into Autonomous Mode. Only when the OCS receives and verifies the RunStart should any vehicle begin their run.

3.4.11 Heartbeats and Task State

The OCS publishes a separate RxReport heartbeat on behalf of each active vehicle at 2Hz

A heartbeat contains:

• Robot state: killed, manual, or autonomous
• Position
• Speed and heading
• Roll, pitch and altitude/depth (where applicable)
• Current task
• Vehicle type
• UAV flight phase where applicable

Heartbeat.current_task is the authoritative indication that a vehicle has begun or moved on from a task attempt:

• A transition into a task value begins that vehicle’s task attempt.
• A transition to TASK_NONE signals the end of the task attempt and the transition to the next.
• TASK_UNKNOWN means unset and should not be used. It must not be interpreted as transitioning between tasks.

Relevant telemetry from the heartbeat reports for UAVs will be relayed to Garuda Robotics to meet the Network Remote ID requirements in Singapore. It is critical that these messages are complete and reliable.

3.4.12 Task Reports and Commands

The OCS publishes task reports on behalf of the appropriate vehicle. Message requirements depend on the task and declared tier.

Task 1 — Safe Passage

SafePassageReport communicates the identified entry position, exit position, and detected buoy states. The report is attributed to the vehicle performing the reporting role. Send an updated report when new buoys are detected or the mapped buoy state changes.

Task 2 — Infrastructure Survey and Repair

PipelineSurveyReport communicates the active buoy position and the ordered condition of pipeline segments.

At Advanced and Disruptive tiers, ResourceDeliveryRequest identifies the task, requested resource color, and delivery-circle color. The detecting vehicle reports the request, and the UAV echoes the request when delivery begins.

Task 3 — Coordinated Logistics

DockingReport identifies successful docking in a bay. FirefightingReport signals a successful water delivery attempt to the indicated window (as perceived by the vehicle).

At Advanced and Disruptive tiers, ResourceDeliveryRequest is used for the delivery requirement and identifies Task 3 in its task field.

Task 4 — Dynamic Incident Response

Task 4 uses RoboCommand commands and vehicle-attributed responses routed through the OCS.

• Core: AssistanceRequest → IncidentAck → ReadinessReport → ReadinessConfirm
• Advanced: KeepOutZone → IncidentAck → AllClear → IncidentAck
• Disruptive: MovingObjectAlert identifies the moving object and affected vehicle types. It has no separate acknowledgment or all-clear message.

The OCS must preserve the command and report sequence references required by these response chains.

3.4.13 Application Behavior

Teams should design their OCS communications application to:

• Connect automatically after receiving a DHCP configuration
• Restore subscriptions after reconnecting
• Reject malformed or unexpected protobuf payloads without stopping the application
• Confirm that the topic team and vehicle identifiers match the decoded message
• Maintain independent report sequence counters for each vehicle
• Prevent messages from a previous run from being reused in a new run
• Log connection changes, publications, received commands, sequence numbers, and parsing errors
• Display the current RoboCommand connection state to the operator
• Make command receipt and response state visible to the operator
• Avoid blocking vehicle control if logging or visualization fails

3.4.14 Team Village Testing

Use the Demo RoboCommand system to test the same OCS application and protobuf classes that will be used on the competition courses.

Recommended test sequence:

1. Configure the RoboCommand-facing interface for DHCP.
2. Connect to the Team Village demo network.
3. Confirm that the OCS receives a valid demo-network address.
4. Connect the MQTT client using the demo connection information.
5. Subscribe to the course and team command topics.
6. Confirm that RxCourse can be received and decoded.
7. Publish a RunDeclaration using the assigned team_id.
8. Publish one heartbeat for each declared vehicle.
9. Verify that RoboCommand identifies the team and each represented vehicle correctly.
10. Exercise the task reports and Task 4 command-response chains supported by the demo system.
11. Disconnect and reconnect to confirm automatic recovery.

Multiple teams may be connected in Team Village. Never use another team’s identifier for testing.

3.4.15 Troubleshooting

The OCS does not receive an IP address

• Confirm that the correct Ethernet interface is connected.
• Confirm that IPv4 is set to DHCP.
• Disable any DHCP server, bridge, or Internet-sharing function on that interface.
• Replace the cable or ask course staff to verify the connection.

The OCS receives an address but cannot connect to RoboCommand

• Confirm that the address belongs to the assigned course subnet.
• Confirm that the default gateway matches the course RoboCommand address.
• Confirm that the application is using the RoboCommand address for the current course.
• Confirm that local firewall rules allow the configured MQTT connection.
• Do not use Internet connectivity as a network test; course networks intentionally provide no Internet access.

RoboCommand does not recognize a publication

• Confirm the MQTT topic spelling and capitalization.
• Confirm that the topic contains the assigned team_id.
• For a report, confirm that the topic vehicle_id matches RxReport.vehicle_id.
• Confirm that the correct top-level protobuf envelope was serialized.
• Confirm that exactly one oneof body field is populated.
• Confirm that the application is using the competition-approved schema version.

A command is received but the response is rejected

• Confirm that the response references the correct command sequence.
• Confirm that the response is attributed to the intended vehicle.
• For ReadinessConfirm, use both the report sequence and vehicle ID to identify the readiness report.
• Confirm that sequence counters were not reset during the active run.

3.4.16 Pre-Run Checklist

• RoboCommand-facing OCS interface is configured for DHCP.
• Network bridging and Internet sharing are disabled.
• The OCS received an address in the assigned course subnet.
• The default gateway matches the course RoboCommand address.
• The MQTT client is connected.
• The OCS subscribed to robocommand/robotx/course.
• The OCS subscribed to robocommand/robotx/<team_id>/command.
• The retained RxCourse message was received and decoded.
• The course identifier and boundary were checked.
• The application is using the approved protobuf schema release.
• The assigned team_id is configured correctly.
• All participating vehicle IDs are unique and configured consistently.
• Independent report sequence counters are operating for every vehicle.
• The UAV geofence is closed and within the received course boundary.
• The intended tier for every task is correct in RunDeclaration.
• Operators can see the RoboCommand connection and command-response status.
• Logging is enabled for the run.

3.4.17 Scope Boundary

This protocol governs communication between the team OCS and RoboCommand. It does not prescribe:

• Vehicle-to-OCS radios or network protocols
• The number or configuration of other OCS network interfaces
• Internal team message formats
• Vehicle control architecture
• How the OCS distributes course data or RoboCommand commands internally

Regardless of the team’s internal design, all required RoboCommand messages must enter and leave the team system through the connected OCS.