Olive devices join the ROS 2 graph from the moment they power on—publishing robot-ready data through a DDS-native communication layer, without a host-side driver stack standing in between.
host-side sensor drivers
required for the ROS path
topics, services and graph
behavior at device level
discovery, serialization,
transport and QoS
from embedded sensing
to autonomy and fleet
Sensors, compute and actuators are useful only when their data arrives with the semantics, timing and reliability the rest of the machine expects.
ROS 2 nodes discover peers through the underlying middleware. A device can participate in the same distributed graph as localization, planning, visualization and logging—without a central ROS master.
Standard ROS interfaces carry structured physical state: timestamps, units, frames, covariance, diagnostics and message types that the rest of the robotics ecosystem already understands.
DDS QoS lets reliability, history, durability, liveliness and timing expectations be chosen for the data path instead of being hard-coded into a proprietary transport.
ROS 2 separates the client API from the underlying middleware through the RMW layer. That keeps application code above the transport and enables multiple standards-based middleware choices.
Olive co-designs acquisition, real-time execution and robot-native publication as one path. DDS is not a converter after the measurement; it is part of how the measurement leaves the device.
The module is the publisher. The host receives the same topic interface it would receive from any other ROS 2 node.
Timestamping, health, covariance, confidence and diagnostics can be attached while local hardware state is still observable.
Move data directly to perception, control, logging or remote compute without inventing another sensor protocol first.
Traditional smart sensors often stop at a vendor protocol. The robot then needs a driver, parser, timestamp strategy, message converter and lifecycle story. Olive moves the ROS 2/DDS boundary into the hardware.
High-rate sensing, control state and diagnostics have different communication priorities. DDS exposes those choices as explicit QoS policies.
/imu/data compatibleFor a high-rate sensor stream, the newest sample can be more valuable than retransmitting an old one. This is an illustrative ROS 2/DDS profile, not a fixed product default.
A timestamp added late in a host driver describes software arrival. A timestamp created near acquisition can describe the physical sample. Olive keeps that distinction inside the data path.
Exact scheduling and transport depend on the product, configuration, message size, QoS and network. The architectural goal is simple: preserve source timing and make every stage observable.
ROS 2 uses the RMW API to separate the robotics client stack from the underlying middleware. DDS/RTPS implementations can provide the distributed communication foundation beneath that boundary.
Nodes find other nodes in the same ROS domain through middleware discovery instead of relying on a central ROS 1-style master.
ROS 2 can support multiple RMW implementations, keeping the application layer less tightly coupled to one transport implementation.
DDSI-RTPS provides the wire protocol used by DDS implementations, giving robotics teams a standards-oriented foundation for networked data exchange.
The value of embedded intelligence grows when its output is easy to consume. Olive can transform high-rate physical signals locally, then publish raw data, fused state, confidence, events and diagnostics through the same robot-native interface.
Keep timing, temperature, saturation, vibration and local dynamics visible to the model—then send the robot a cleaner, richer state instead of another proprietary byte stream.
Raw physical signal + local context
sourceTimestamp · align · validate
timeFusion · AI residual · confidence
olixAIROS message + DDS QoS
ROS 2Control · autonomy · logging · fleet
graphOnce the hardware is on the graph, inspection, recording and integration use the normal ROS 2 workflow instead of a separate vendor toolchain.
The same ROS 2 graph model can connect sensing, interaction, autonomy and diagnostics—so teams spend less time maintaining glue code and more time building robot behavior.
Publish motion, force, vision or machine-state data directly into the graph with source context and explicit QoS.
Connect controllers, localization, perception, logging and diagnostics through interfaces already native to the robotics software stack.
Keep the device interface consistent as systems grow from a bench setup to multi-compute robots and larger deployments.
Middleware, transport and QoS capabilities depend on the selected ROS 2 distribution, RMW implementation, product firmware and network configuration.
Bring robot-native sensing and embedded intelligence into your next system with Olive ROS 2 / DDS hardware.