Rover Nexus
Answers for teams evaluating Rover Nexus as operations software for mixed autonomous ground-vehicle fleets.
Rover Nexus is operations software for autonomous ground-vehicle fleets. You define the work. Nexus matches robots that can do that work, dispatches missions, and tracks progress on a live map, with telemetry, teleoperation, alerts, permissions, and a full mission history.
It talks to your existing autonomy stack through an on-robot agent. It does not replace that stack.
Most autonomy stacks control one vehicle well. They do not plan work across a mixed fleet, keep two robots out of the same work cell, match machines to required capabilities, or keep people in the loop when a job is blocked.
Rover Nexus is that operations layer: you describe the task; Nexus assigns robots that fit it.
That layer includes secure access, user permissions, live maps, telemetry, mission control, teleoperation, alerts, robot status, and fleet visibility. Teams get the tools to operate robots in the field while staying focused on autonomy, hardware, and field performance. An AGV can be online in minutes.
Teams running or scaling outdoor and site-based autonomous ground vehicles: construction, mining, agriculture, forestry, solar, and industrial sites.
It is also for robotics and autonomy OEMs that want machines to join a shared fleet-operations system without replacing the onboard stack.
No. It is not a navigation, perception, or path-planning stack. You keep your planners, drivers, and hardware. Nexus coordinates work across robots.
An OEM app usually covers one vendor. A generic dashboard shows telemetry. Nexus is built around the operation: job structure, capability matching, spatial reservations, multi-robot dispatch, human-in-the-loop control, and a command-level audit trail across mixed fleets.
You can build dispatch, maps, permissions, and history yourself. Nexus is the packaged operations layer so autonomy, hardware, and field teams are not also maintaining the console, role access, spatial job state, and mission records.
No. Nexus is meant to sit on top of the stacks and site workflows you already run.
You define work as routes, zones, queue points, and reusable job steps, for example a haul loop, a staging pad, and a dig face. You specify the capabilities the job needs. Nexus matches available robots, dispatches missions, and tracks what is complete, in progress, or blocked on the map.
Operators stay in the loop for approvals, blocked jobs, safety exceptions, and teleoperation.
Work is drawn on the map, not only listed as tasks. You define routes, zones, queue areas, and work cells. Robots can reserve those spatial resources so another robot is not assigned to the same area at the same time.
Reservation is a dispatch rule. The onboard stack still owns live collision avoidance.
Yes. Multi-robot orchestration is a core capability. One operation can split work across machines from different vendors or with different capability sets, and still present a single operational picture.
Yes. A single robot is a normal way to integrate, test, and train operators. The main value shows up when you coordinate more than one machine. There is no minimum fleet size.
You can schedule missions or individual commands and reuse operation presets and templates for work that repeats. Dispatch can be bulk assignment, not one robot at a time.
Yes. Operators can take over from the same console that shows live maps, robot status, alerts, and fleet visibility.
Camera support is separate from takeover: the agent can detect USB webcams, and a brdige is being built to stream ROS 2 image messages. Over poor LTE, expect slower video and delayed commands, not fiber-quality teleop.
Nexus is responsible for assignment and operational picture: matching capabilities, dispatching missions, reserving map space so two robots are not sent into the same reserved area, recording what was commanded, and keeping operators in the loop when a job is blocked.
The robot and its onboard stack remain responsible for localization, online planning, collision avoidance, and physical safety. The robot may refuse a command that is not in its allowed-command set.
Nexus will not:
If a job is blocked or a site condition changes, operators approve, pause, reassign, or teleoperate. That is by design.
No. Not in place of the robot. Nexus does not replace onboard localization, obstacle avoidance, or real-time path planning. It may assign a route or corridor as part of job planning. The robot still localizes itself and still does online planning and collision avoidance. Nexus reports the pose the robot provides.
Nexus is vendor-agnostic. It integrates through Zenoh, ROS 2, or a custom adapter. Heterogeneous fleets can run in one operation if each vehicle can report status and accept missions or commands through the agent.
Minimum to appear and be useful: the robot publishes motion and status telemetry as documented (pose, mode, faults, e-stop, mission run status). Partial telemetry is allowed; the robot can show on the map before every topic is wired.
Minimum to do work: the robot advertises capabilities and allowed commands, exposes Actions, and accepts Nexus mission commands (including pause/resume and mission run control).
The agent's job: talk to your onboard software locally (typically Zenoh), then relay telemetry and commands to the Nexus server over a secure link. Integrators use the published wire format (Cap'n Proto and JSON in the rover_nexus_core crate) so robot and fleet manager share one schema.
Out of scope for the agent: navigation, perception, localization, obstacle avoidance, and physical e-stop. The agent is not the autonomy stack and not the safety PLC.
Time-to-online is minutes for an additional robot once the integration path exists. First integration takes longer if you need a custom adapter.
Yes. Nexus is looking for OEM integrations so machines can join customer fleets. Contact us if you want an official adapter rather than a one-off link.
Nexus is built for imperfect site links.
The control link uses multiple QUIC streams so telemetry, commands, and other traffic are isolated. A stalled video or bulk upload should not take down mission control. Degraded LTE usually means slower updates and delayed operator commands, not an automatic abort, unless you configure the robot to stop when supervision is required.
Offline means "continue or hold the last assigned mission," not a second disconnected planning product.
Yes. Every mission, command, fault, and interruption is recorded: who issued which command, when, and what the robot reported back, including failures. Mission history is for after-action review as well as live monitoring.
Nexus uses secure access and role-based permissions so operations, engineering, and field staff do not share the same privileges.
The Nexus server can be deployed on-premises and tailored to the site. Cloud is not required for that path. Contact us if you need on-prem or air-gapped deployment.
It is optimized for outdoor and site-based ground operations. If an indoor AGV fleet uses the same integration interfaces, ask during a demo. Warehouse AMR features are not the product. Indoor use still needs a configured world datum so the map frame can be converted to world coordinates.
It is built first for outdoor unmanned ground vehicles. Other platforms can connect if they speak the same agent interface, but maps, job types, and workflows are designed for ground vehicles on sites. Connecting is not the same as a supported aerial or marine workflow.
Request a live demo at [email protected]. Walk a real use case: define an operation, assign capabilities, dispatch, and watch spatial progress and history.