ROS 2 stack: driver nodes, ros2_control YAML composition, DDS QoS tuning, Nav2 configuration, launch system architecture, diagnostic framework. Jazzy as the production target; Humble fallback for legacy platforms.
OROCOS RTT integration: port-based hard-RT component model — used for Pinocchio + WBC solver composition pipelines where ROS 2 callback timing variance is unacceptable. Owns the OROCOS robot abstraction adapter shim.
Apex.OS / Apex.Middleware: deterministic ROS 2 variant relevant to SIL/PLd-certified deployment paths (Industrial Mobile Manipulator product). Owns the migration story from Jazzy to Apex.OS for safety-certified configurations.
DDS infrastructure: FastDDS (current production), Cyclone DDS (Humble default), RTI Connext (some customer environments). Owns the implementation trade-off analysis and migration paths between them.
DDS-RTPS protocol mechanics — the wire-protocol level where QoS settings actually behave (or fail to behave) as the documentation implies. QoS profile design, discovery tuning, fragmentation, reliability semantics.
Zero-copy IPC: Iceoryx integration for sub-millisecond intra-host transport. Performance profiling of zero-copy paths under 1 kHz RT constraints.
Eclipse Zenoh: emerging alternative for fleet-scale and edge scenarios where DDS discovery does not scale. Co-owned with the Robot Connectivity Engineer for fleet-side integration.
Cross-middleware contract design: the robot abstraction layer exposes itself to ROS 2 consumers, OROCOS pipelines, and gRPC clients simultaneously via different backend variants. You own the schema coherence and behavioural equivalence across these surfaces.
Observation pipeline middleware: synchronising sensor streams by sequence number, handling the middleware-side of the observation assembly for VLA-style inference inputs.
C++ depth with real-time-safe patterns — lock-free queues, zero-copy semantics, allocation discipline, RT-safe logging.
Operational understanding of how middleware QoS settings behave at the wire-protocol level — not just configuration syntax. Comfortable reasoning about reliability, durability, history depth, fragmentation, discovery, and the failure modes each produces under load.
Production experience integrating middleware into a real-time robot control loop with deterministic timing requirements.
Production hands-on in AT LEAST ONE of the four core middleware paradigms (treated as parallel valid entry paths): (a) ROS 2 with ros2_control hardware interface authoring and lifecycle node design (Jazzy or Humble); (b) OROCOS RTT — component authoring, port-based composition, hard-RT deployment; (c) Apex.OS / Apex.Middleware — deterministic deployment, especially in automotive or industrial SIL contexts; (d) direct DDS implementation work — FastDDS, Cyclone DDS, or RTI Connext at the configuration-and-tuning level (not consumer-of-defaults), including QoS profile design for production deployments.
Hands-on across MORE THAN ONE of the four paradigms above — multi-middleware experience is the role's distinguishing competence, not a baseline requirement.
Eclipse Zenoh for fleet-scale distributed messaging or edge scenarios.
Iceoryx or alternative zero-copy IPC integration.
Multi-middleware bridging patterns: ros1_bridge, OROCOS-ROS2 component bridging, or custom abstraction layers.
DDS Security plug-ins (authentication, access control, cryptographic transformation) for SIL-grade deployments.
Open-source contributions to any of the major middleware ecosystems (ROS 2 core, OROCOS Toolchain, Apex.OS, eProsima FastDDS, Eclipse Cyclone DDS, RTI Connext community).
