Skip to main content

Philosophy

BellRMF exists to make it painless for any robot — ROS-based or not — to share lifts, doors, and narrow corridors. That means stripping away everything that introduces friction, tight coupling, or unnecessary infrastructure.

We designed BellRMF from the ground up to be cloud-native, stack-agnostic, and autonomy-preserving.

ROS 2 vs Web-First Architecture​

What OpenRMF Assumes​

OpenRMF is built tightly on ROS 2, which uses DDS (Data Distribution Service) for communication. DDS relies on multicast discovery and a shared LAN environment. As a result, integrating with OpenRMF requires robot developers to:

  • Build and maintain a fleet adapter that runs as a ROS 2 node
  • Host it on a server within the same network as the RMF core
  • Understand and conform to RMF messages, actions, and services

This setup introduces considerable friction — especially for vendors who:

  • Don’t use ROS
  • Rely on cloud-based control
  • Operate over cellular or don’t have LAN access

DDS doesn't play well across subnets, firewalls, or cloud deployments. Maintaining a full ROS 2 runtime and build chain just to call a lift or open a door is often unjustifiable.

How BellRMF Does It Differently​

BellRMF is designed to be web-first. Robots connect via a single WebSocket over TLS, and send JSON messages using a simple API.

  • No ROS 2
  • No colcon
  • No DDS
  • No multicast
  • No IT tickets

Any robot — ROS, custom firmware, or cloud-based — can integrate cleanly and securely.
This reflects BellRMF’s core philosophy: easy integration, minimal infrastructure, and maximum compatibility.

Top-Down Control vs Robot Autonomy​

What OpenRMF Expects​

OpenRMF’s model is one of central authority. Robots are assigned tasks through a fleet adapter and are expected to follow them. The central system can pause or reroute robots based on traffic conditions.

While OpenRMF offers a "Traffic Light" interface for read-only mode, it still expects robots to obey pause/resume commands.

This model works in environments where robots are fully subordinate to a centralized planner, but it doesn’t scale well with smarter robots or independent fleets.

How BellRMF Does It Differently​

BellRMF assumes the opposite: that robots are autonomous and self-directed. It does not assign tasks, plan paths, or issue commands.

Instead, it acts as a resource gatekeeper:

  • If a lift or corridor is in use, the robot waits
  • When it’s free, the robot proceeds

Robots retain full control over how and when they move. BellRMF simply ensures they don’t collide over shared infrastructure.

Global Map Unification vs Shared Resource Naming​

What OpenRMF Requires​

OpenRMF depends on a global navigation graph and unified map. All robots must:

  • Translate their SLAM-based maps into a shared coordinate frame
  • Use the same graph edges and waypoints
  • Accept traffic assignments based on centrally defined geometry

In practice, this is difficult:

  • SLAM systems differ in scale, anchors, and fidelity
  • Map reconciliation across vendors is time-consuming
  • Even minor layout changes trigger system-wide rework

How BellRMF Does It Differently​

BellRMF avoids shared maps altogether.

  • There is no coordinate system
  • No graph
  • No YAML map

Instead, BellRMF defines a vocabulary of named resources, like "lift_2" or "door_X" or "hallway_A". Robots agree only on the names, not on any spatial details.

Each robot operates in its own internal map. It simply requests the named resource it needs. No SLAM alignment, no coordinate math, no global transforms.

This makes BellRMF trivial to integrate, even in mixed-vendor environments, and lets robots remain fully decoupled.

TL;DR​

BellRMF keeps the good idea — shared-resource scheduling — and discards the complexity.
No ROS 2, no central planner, no shared map.

Just simple etiquette for shared infrastructure — on the web, at cloud scale.