The executor is not a safety scheduler
A ROS 2 callback runs when the executor gets to it. That is fine for perception and navigation, and unsuitable for the one decision that has to be bounded — whether the robot is allowed to keep moving.
Solution · ROS 2
A ROS node for distribution. Never for architecture.
EdgeEmbed ships a standard ROS 2 package, so the integration arrives the way your team expects — colcon, params, launch files. But the node itself only translates messages into events. The decision loop deliberately runs inside the runtime, off the ROS executor path, because the one decision that must be bounded should not wait its turn in a callback queue.
How it fits
Beside the graph, not inside it
Your ROS stack keeps doing what it does. The bridge is the only thing that touches it — and everything downstream of the boundary is deterministic.
ROS 2 — probabilistic, DDS-timedRuntime — deterministic, bounded
Perception, Nav2, behaviour trees — publishing on topics, scheduled by the DDS executor.
rclcppDDStopics
A thin ROS node that only translates: message in, event out. No decisions are taken here.
edgeembed_bridgeevent_map.yaml
Off the executor path
Policy, arbitration and the recorded decision — running off the ROS executor path, where the timing guarantee holds.
libedgeembedpolicy.jsonC11
Vetted actions leave through backend plugins to the drive base, CAN bus, or e-stop line.
HAL pluginCANe-stop
The design rule
Why the decision doesn't live in the node
It would be easier to put the policy in a ROS callback. It would also quietly forfeit the property the runtime exists to provide.
A node for distribution, not for architecture
Packaging as a ROS node is how the integration reaches you: colcon, params, launch files, all familiar. But the node only translates messages. The decision loop stays inside the runtime, where its guarantees are real.
Scalars cross the boundary, not blobs
The bridge carries generic hints — urgency, confidence, value — never domain payloads. The runtime decides on numbers and policy, so the same engine serves any robot without learning your message schemas.
Behaviour as data
The mapping is config, not code
Same idea as the policy bundle: what a topic means is declared, not compiled — so the integration is reviewable, versionable, and portable across robots.
One binary, many robots
Which topic becomes which event is declared in a YAML params file, not compiled in. The same bridge node serves every robot on the fleet; only the mapping file differs.
Reviewable by the safety engineer
The mapping sits beside the policy bundle as plain, versioned configuration — readable by someone who needs to sign off on behaviour without reading C++.
Testable without a robot
The translation core is deliberately ROS-independent — it depends only on the public SDK headers, so it compiles and unit-tests with nothing but a C++17 compiler.
At a glance
What ships
edgeembed_ros
Packageedgeembed_ros — a standard ament/colcon ROS 2 package
Nodeedgeembed_bridge — translates subscribed topics into runtime events
MappingYAML params: topic, event symbol, default urgency and confidence, TTL
Decision pathInside libedgeembed, off the ROS executor
LicensingThe node and translation core are open source; the runtime is licensed separately
Verified
The translation core tests without ROS at all
Because the core is ROS-independent, its behaviour is unit-tested with only a C++17 compiler — no ROS install, no runtime binary, no robot.
ctest — edgeembed_ros
$ cmake -S ros/edgeembed_ros -B build-ros && cmake --build build-ros
$ ctest --test-dir build-ros --output-on-failure
Test project build-ros
Start 1: test_bridge_core
1/1 Test #1: test_bridge_core ................. Passed
100% tests passed, 0 tests failed out of 1
Translation-core unit tests. Running the node in a live ROS 2 graph is done in your own ROS environment.
Pilots
Running ROS 2 on a real robot?
If you have a ROS stack and a safety decision you need to make defensible — or a certification conversation coming — we would love to talk.