Work / 02
NEXUS: Modular Robotics Operations Platform
A plugin-first operations platform for heterogeneous autonomous systems, written in TypeScript. The headless core runtime, the plugin platform and a browser-based operator UI shell are implemented and tested; robot adapters and the robot model are the next phase and not built yet.
Current scope: an early implementation. The core runtime, plugin platform and operator UI shell exist in code; the UI runs on mock data and does not connect to the core yet. Robot adapters, the normalized robot model, capabilities and missions are design, not implementation.
My contribution: personal open-source project, published in my GitHub repository.
1 Overview
NEXUS aims to be a robot-agnostic operations layer: robots, simulators, middleware stacks and external services connect through explicit adapters instead of being hard-coded into one runtime. Development started from the platform itself. A headless core runtime and a plugin platform come first, followed by an operator UI shell, so that the extension points exist and are tested before the first robot adapter is written.
2 What is implemented
| Component | Implementation |
|---|---|
| Core runtime | A headless, in-process runtime with an event bus, configuration loading and validation, logging, a service container and a bootstrap that starts and stops everything in order |
| Plugin SDK | Public plugin contracts and a manifest format, with validation of every manifest before a plugin is accepted |
| Plugin platform | Registry, local discovery, loader and lifecycle management; a plugin that fails while starting is rolled back and the failures are reported together |
| Example plugin | A telemetry demo plugin package that subscribes to bus events and normalizes a generic payload |
| Operator UI shell | A browser shell with top bar, activity bar, sidebar, dockable workspace and event panel, a UI-side plugin view registry and a first telemetry view |
| Runtime snapshot boundary | The UI reads one snapshot model of runtime, connection, workspaces, plugins and events. Today a mock provider fills it; the same boundary is where the core will connect |
3 Target architecture
The intended platform is organized around a normalized operations model. Robots, simulators and external systems connect through adapters; adapters expose state and capabilities; a mission and task layer works against those capabilities; plugins extend behavior and UI without tying the platform to one robot type or middleware stack. The plugin runtime and the operator UI shell exist; the layers below them do not yet.
- Robot, simulator, external systemPlanned: physical robots, simulated agents, services
- Adapter layerPlanned: ROS, MQTT, MAVLink, simulator or custom API adapters
- Normalized robot modelPlanned: identity, state, telemetry, health and commands
- Capability registryPlanned: declared robot abilities as stable platform capabilities
- Mission / task layerPlanned: task orchestration against capabilities
- Plugin runtimeImplemented: contracts, discovery, loading, lifecycle
- Operator UIImplemented as a shell on mock data; no API yet
4 Design principles
| Principle | Meaning |
|---|---|
| Plugin-first | Platform behavior, integrations and operator views extend through explicit plugin contracts |
| Robot-agnostic | The core is meant to reason about normalized robots and capabilities, not one vehicle, arm, drone or middleware package |
| Adapter-based | Robot-specific details are meant to sit behind adapters that translate external systems into stable NEXUS contracts |
| Middleware-independent | ROS, MQTT, MAVLink, simulators and custom APIs are integration choices, not assumptions in the core |
| UI modularity | Operator panels are registered by plugins, so the interface reflects the plugins that are installed |
5 Validation and limits
The core and the UI each have their own Vitest suite: event bus, configuration, logging, service container, runtime bootstrap, manifest validation, discovery, loading and plugin lifecycle on the core side; the shell application, selection, plugin view registration and bootstrap and the snapshot provider on the UI side.
Limits. The UI does not connect to the core: there is no API, WebSocket or IPC bridge yet. The event bus is in-process only. Plugins are not sandboxed, and plugin dependencies and versions are not resolved. No robot can be connected or controlled.
6 Roadmap
| Step | Status |
|---|---|
| Core runtime and plugin SDK | Done |
| Example plugin | Done (telemetry demo) |
| Operator UI shell | Done, on mock data |
| Adapter interface and first adapters | Next phase, not started: the adapter contract, a simulated adapter, then ROS, MQTT and MAVLink bridges |
| Robot model and capabilities | Planned: shared model for identity, state, telemetry, health, commands and capabilities |
| Mission workspace | Planned: mission-focused operator layouts and repeatable workflows |