ROS 2 & Robotics Stack 2026 Deep Dive — Jazzy · Kilted Kaiju · Gazebo · MoveIt 2 · NVIDIA Isaac · Drake · Foxglove · Nav2

Prologue — The Year Robots Became "Actually Useful"

The first half of 2026 has an odd vibe in the robotics industry. A year ago, the "humanoid robot" pitch deck was still treated with a mix of curiosity and skepticism — "great demos, no production." Then Figure 03 went into 24/7 operation on BMW lines, 1X Neo started shipping home-beta units, Unitree G1 dropped to roughly USD 12,000, and the chorus turned. NVIDIA GR00T, Physical Intelligence pi-0.5, and Google DeepMind RT-X showed that VLA (Vision-Language-Action) foundation models can drive robots in the same way LLMs drive chatbots: a generalist model, fine-tuned per embodiment.

But the layer below that model is still ROS 2. This article maps the ROS 2 ecosystem as of May 2026 — distributions (Humble · Jazzy · Kilted Kaiju · Lyrical Luth), middleware (Fast DDS · Cyclone DDS · Zenoh), motion planning (MoveIt 2), navigation (Nav2), simulation (Gazebo Harmonic · Isaac Sim 4 · Drake), visualization (Foxglove Studio · RViz2 · PlotJuggler), and the humanoid foundation models running on top of all of it.

1. ROS 2 Distributions — The 2026 Snapshot

The big picture first. As of May 2026, here is the state of the distros.

Distro	Released	EOL	Type	Notes
ROS 2 Foxy	2020-06	2023-06	LTS	Ended
ROS 2 Galactic	2021-05	2022-12	non-LTS	Ended
ROS 2 Humble Hawksbill	2022-05	2027-05	LTS	De-facto standard on industrial floors
ROS 2 Iron Irwini	2023-05	2024-11	non-LTS	Ended
ROS 2 Jazzy Jalisco	2024-05	2029-05	LTS	Default for new projects
ROS 2 Kilted Kaiju	2025-05	2026-11	non-LTS	Sandbox for experimental features
ROS 2 Lyrical Luth	2026-05	2031-05 (planned)	LTS	Freshly out — migration starting

Headline: new projects in 2026 should start on Jazzy or the just-released Lyrical, while live industrial systems remain overwhelmingly on Humble. ROS 1 Noetic hit EOL in May 2025, so greenfield ROS 1 is no longer an option; many teams are still in the middle of ros1_bridge-based incremental migration.

2. ROS 1 to ROS 2 — Migration Reality

The Noetic EOL in May 2025 was one of the most consequential events of the decade for the field. Industrial automation, research labs, and marine/underwater robotics still ran on millions of lines of ROS 1 code.

Three migration patterns dominate.

Incremental migration via ros1_bridge — bidirectional topic-level translation between ROS 1 and ROS 2. The most common path, though custom message types require manual mapping.
Per-node rewrites — re-implement key nodes in rclcpp/rclpy. Cleanest result, highest cost.
Freeze legacy + greenfield ROS 2 — backport security patches to ROS 1 Noetic in-house, do all new development on ROS 2. Conservative industrial teams often pick this.

Common traps.

Trying to port rospy to rclpy line-by-line. The callback model, QoS, and lifecycle semantics differ.
tf to tf2/tf2_ros. ROS 2's tf2 has subtle behavior differences.
Launch files migrating from XML to Python (launch.py). Once you internalize them, they are far more powerful, but the learning curve is real.
Build system change from catkin to colcon plus ament_cmake/ament_python.

3. DDS Middleware — Fast DDS · Cyclone DDS · Zenoh

One of ROS 2's foundational design choices was adopting DDS (Data Distribution Service) as the communication backbone. The RMW (ROS Middleware) abstraction lets you swap the backend.

Major RMW implementations in 2026.

rmw_fastrtps — eProsima Fast DDS. Default on Jazzy. Most widely deployed.
rmw_cyclonedds — Eclipse Cyclone DDS. Was the Foxy default, still popular. Often praised for memory efficiency.
rmw_connext — RTI Connext DDS. Commercial. Used with safety certifications in automotive, aerospace, and defense.
rmw_zenoh — Based on Eclipse Zenoh. Treated as the DDS successor by parts of the community. Excels in wide-area, low-bandwidth, and fleet scenarios. Promoted to first-class RMW candidate starting in Kilted.

Why Zenoh matters: cloud-edge distribution, 5G/satellite uplinks, and multi-robot fleets all break DDS's multicast assumption. Multi-robot coordination and remote teleoperation deployments are increasingly Zenoh-based.

When switching, set RMW_IMPLEMENTATION=rmw_cyclonedds_cpp (or similar). QoS compatibility and discovery behavior differ subtly across RMWs — never assume a drop-in swap.

4. Nodes · Topics · Services · Actions · Parameters — The Core Five

ROS 2's abstractions reduce to five concepts.

Concept	Communication model	Use case
Topic	publish/subscribe	Sensor streams, state
Service	request/response	Short synchronous calls (configuration changes, etc.)
Action	goal / feedback / result	Long-running tasks (motion, navigation)
Parameter	synchronous setter/getter	Node configuration and tuning
Lifecycle event	state-transition notification	Node state management

The classic mistake: forcing everything onto topics. Actions exist for progress, cancellation, and results; services for short calls. Faking actions over topics scatters cancellation and timeout logic.

5. Composition — Multiple Nodes, One Process

One of ROS 2's biggest performance wins is Composition (Component Nodes). Multiple nodes in the same process can use intra-process communication — messages move via pointers rather than serialized copies.

When does it matter?

A pipeline like camera → image processing → object detection → tracker, where each stage serializes a megabyte-scale image, blows up CPU, memory, and latency. Composition often yields a 10x improvement.
Don't inherit from rclcpp::Node; write a component and load it into component_container_mt. Use launch with composable_node_descriptions.

Tradeoff: composition makes debugging slightly harder because multiple nodes share one log stream — per-node logging conventions become important.

6. Lifecycle Nodes — Managed States

rclcpp_lifecycle::LifecycleNode makes the node an explicit state machine: Unconfigured · Inactive · Active · Finalized.

Why it matters: in autonomy and industrial automation, the system needs a standardized way to know whether a sensor is on, calibration finished, or motors armed. Lifecycle expresses this outside of topic traffic. Almost every core Nav2 node is a lifecycle node.

The typical flow: configure → activate → (run) → deactivate → cleanup.

7. QoS — Quality of Service Policies

QoS is the part newcomers stumble on most. The four key policies.

Reliability — RELIABLE vs BEST_EFFORT. Raw sensor data is best-effort; commands are reliable.
Durability — VOLATILE vs TRANSIENT_LOCAL. Transient-local is the new equivalent of "latched topics."
Deadline — declares that messages must arrive on a cadence, with callbacks on violation.
Liveliness — publisher health guarantees.

The common pitfall: if pub/sub QoS profiles are incompatible the connection never forms (no error, just silence). When a topic does not show up in RViz or Foxglove, QoS mismatch is the cause 90 percent of the time.

Recommended profiles: rclcpp::SensorDataQoS() for raw sensors, rclcpp::ServicesQoS() for services, rclcpp::ReliableQoS() for commands.

8. rclcpp · rclpy — Client Libraries

ROS 2's two workhorse languages.

rclcpp (C++) — performance-critical nodes. Composition, lifecycle, and intra-process communication are all fully available. Use here when realtime guarantees matter.
rclpy (Python) — fast prototyping, research, high-level logic. The GIL caps throughput, but ergonomics are excellent.
rclrs (Rust) — community-driven, still experimental. Growing interest for safety and concurrency.
rclnodejs / ros2-web-bridge — web and Node.js integration.

Typical split: low-level drivers, filters, and SLAM in C++; behavior trees, UIs, and integration with external systems in Python.

9. MoveIt 2 — The Motion Planning Standard

MoveIt has been the standard motion planner since ROS 1 days and remains so in ROS 2.

What matters in 2026.

MoveIt 2 — built on Humble/Jazzy. The de-facto standard for manipulation.
MoveIt Pro — PickNik Robotics' commercial offering. Behavior-tree-driven manipulation workflows, simulation, certification — the enterprise extras.
Planners: OMPL (sampling-based, default), CHOMP (trajectory optimization), STOMP (stochastic trajectory optimization), Pilz Industrial (LIN/CIRC/PTP — industrial motion primitives).
IK solvers: KDL (default, generic), TRAC-IK (fast and accurate), bio_ik (parameter-rich), IKFast (analytical, robot-specific, compiled).
Servo — realtime teleoperation and Cartesian jogging.

Common trap: if the collision model differs from the real robot, simulation passes but the physical machine collides. Spend serious time on URDF and SRDF cleanup.

navigation2 (Nav2) is the ROS 2 navigation stack — the successor to ROS 1's navigation. Its biggest architectural shift: behavior trees sit at the center.

Plugin categories.

Planner — global paths: NavfnPlanner (default), SmacPlanner2D/Hybrid, ThetaStar.
Controller — local control: DWB, RPP (Regulated Pure Pursuit), MPPI (Model Predictive Path Integral).
Costmap — layered: static_layer, obstacle_layer, inflation_layer, voxel_layer.
Recovery / Behaviors — Spin, Wait, BackUp, AssistedTeleop.
Localization — amcl, slam_toolbox (SLAM mode).
Behavior tree — files like navigate_to_pose.xml carry the real logic. Planners and controllers are invoked as BT nodes.

The 2026 default combination: SLAM Toolbox + AMCL + Nav2 + RPP/MPPI + behavior trees.

A common reaction is "why is this so complex?" Once you have N recovery behaviors and M conditional flows, the BT is far cleaner than imperative code. Start visual in BT Studio, then graduate to hand-editing YAML.

11. Gazebo — The End of Classic, the Age of Harmonic

January 2025 brought the EOL of Gazebo Classic 11. The simulator that defined ROS for nearly fifteen years was officially retired.

The lineup (formerly "Ignition Gazebo," unified back to plain "Gazebo" in 2022):

Gazebo Garden — 2023, paired with Humble/Iron.
Gazebo Harmonic — late 2023 LTS, the default simulator on Jazzy.
Gazebo Ionic — late 2024, paired with Kilted. Non-LTS.
Gazebo Jetty — planned 2026, paired with Lyrical.

Differences from Classic.

Modular architecture: gz-sim, gz-physics, gz-rendering, gz-transport as separate components.
Multiple physics engines: ODE plus DART, Bullet, TPE.
Rendering: ogre2 by default, Vulkan eventually.
SDF model format v1.10/1.11.
ROS 2 bridge: ros_gz_bridge, ros_gz_sim (launchers).

Migration trap: about 90 percent of Classic plugins are incompatible. URDF still works, but Classic plugins (gazebo_ros_*) must be rewritten against the new ones (gz_ros2_control and friends).

12. NVIDIA Isaac Sim 4.x + Isaac Lab 2.x — GPU-Accelerated Simulation

The biggest 2026 trend in simulation is NVIDIA Omniverse Isaac Sim and the Isaac Lab stack on top of it.

Isaac Sim 4.x's strengths.

GPU-accelerated PhysX — thousands of parallel environments. Reinforcement learning wall-clock drops from days to hours.
Physical fidelity — rigid, deformable, cloth, rope, and contact modeling.
Photorealistic rendering — RTX ray tracing, ideal for synthetic-data generation.
USD-based — Pixar's Universal Scene Description as the industry-standard backbone.

Isaac Lab 2.x (the merged successor of Isaac Gym + ORBIT):

A unified environment for RL and imitation learning workflows.
Common learning libraries: rl_games, rsl_rl, skrl, stable-baselines3.
Stock assets for ANYmal, Spot, Cassie, H1, G1, UR10, and others.

New in 2026: NVIDIA Cosmos — a video-grounded foundation model that generates synthetic training data from prompts like "lifting a box on a wet concrete floor."

The common pattern: pretrain large-scale in Isaac Lab, fine-tune on a small real-world dataset, deploy on top of ROS 2 with Nav2/MoveIt for the runtime stack.

13. NVIDIA Isaac ROS — CUDA-Accelerated Packages

Isaac ROS is a set of ROS 2 packages that accelerate perception and compute on CUDA.

isaac_ros_visual_slam — GPU VSLAM (cuVSLAM-based).
isaac_ros_nvblox — 3D occupancy mapping.
isaac_ros_dnn_inference — TensorRT-backed detection and segmentation.
isaac_ros_image_pipeline — GPU image transforms and rectification.
isaac_ros_apriltag — accelerated AprilTag detection.
isaac_ros_argus_camera — Jetson camera interface.
isaac_ros_object_detection — DetectNet/YOLO inference.

Target hardware: Jetson Orin Nano/NX/AGX, IGX Orin, and x86 plus RTX. Jetson Orin AGX has effectively become a standard brain for mobile robots.

14. Drake — TRI's Precision Dynamics Engine

Drake is a Toyota Research Institute-led, MIT-licensed library focused on precise multibody dynamics and optimization-based motion planning.

Highlights.

Multibody Plant — accurate rigid-body dynamics with automatic differentiation.
Mathematical Programming integration — interfaces to MOSEK, Gurobi, IPOPT, SNOPT, and friends.
Trajectory optimization — direct collocation, KKT-based methods.
System diagrams — compose controllers as block diagrams.
Python bindings — pydrake for rapid prototyping.

Position: heavy use in academia and research labs, plus selective adoption inside Toyota TRI. If Gazebo and Isaac are graphical simulators, Drake is the mathematical analysis engine. Direct ROS 2 integration is light, but bridge packages like drake_ros exist.

15. Foxglove Studio — Beyond RViz

Foxglove — founded by alumni of the Cruise visualization team — is building the new standard for ROS visualization.

Feature comparison.

Tool	Strength	Limitation
RViz2	Native ROS, strong 3D	Dated UI, poor collaboration
Foxglove Studio	Desktop, web, embed, deep panel library	Some RViz plugins missing
PlotJuggler	Best-in-class time-series plotting	Weak on 3D
rqt	Diverse diagnostic plugins	Aging UI

What sets Foxglove apart.

MCAP file format — adopted as the default rosbag2 backend. Compression, random access, multi-language decoding.
Foxglove Data Platform — cloud log storage, search, and sharing.
Identical desktop and web UX — usable as a remote teleoperation console.
WebSocket / Rosbridge connectivity.

The 2026 pattern: Foxglove rarely replaces RViz entirely, but it has become the de-facto standard for data analysis, debugging, and remote monitoring.

16. rosbag2 + MCAP — A New Log Standard

rosbag2 is the ROS 2 logging tool. The default backend is still SQLite3, but since 2024 MCAP (the format Foxglove created) is the recommended choice.

MCAP advantages.

Language-independent decoding — SDKs for Python, C++, Rust, JS.
Compression options (LZ4, Zstd).
Random access — time-indexed seeks.
Embedded message schemas — IDL/schema inside the file, so future tools can decode without external dependencies.
Reach beyond ROS — autonomous-vehicle and drone companies use MCAP in custom pipelines too.

CLI: ros2 bag record -s mcap /topic. Analyze with Foxglove Studio or mcap-cli.

17. Humanoid Foundation Models — The Year of VLA

The dominant 2026 narrative in robotics is VLA (Vision-Language-Action) foundation models. Natural-language commands plus visual input map directly to robot actions.

Major models and players.

NVIDIA GR00T (Generalist Robot 00 Technology) — humanoid generalist foundation model. GR00T N1 and N1.5 are public; GR00T N2 is the 2026 step. Integrated with Isaac Sim/Lab.
Physical Intelligence pi-0 / pi-0.5 — Pi (πbot) Company's VLA models, with pi-0.5 emphasizing generalization across homes and warehouses.
Figure 02 / Figure 03 + Helix — Figure's humanoids; Helix is their VLA. Figure 03 is deployed on BMW production lines.
1X Neo + Redwood — 1X's home humanoid. Redwood handles voice and vision inputs.
Apptronik Apollo — industrial humanoid. Mercedes and NASA collaborations.
Unitree G1 / H1 — the low-cost segment. Mass-deployed into research labs.
OpenAI + Microsoft + Hyundai (Boston Dynamics) partnership — humanoid collaboration announced late 2025.
Google DeepMind RT-1, RT-2, RT-X — the family that adds action tokens onto an internet-text-pretrained backbone, generalizing across the Open X-Embodiment dataset.
Boston Dynamics Atlas + Spot — the new electric Atlas plus Spot SDK. Spot has become the de-facto industrial inspection standard.

The core observation: the field is moving from "one model per task" to "one model across many tasks". "One model for everything" remains aspirational.

18. Open Robotics Datasets — Fuel for Learning

The headline asset of the VLA era is large-scale robot demonstration data. Major public datasets in 2026.

Open X-Embodiment — Google plus 22 institutions. 22 embodiments, over a million episodes. Powers RT-X, OpenVLA, and Octo.
DROID — Stanford, Berkeley, CMU. Large-scale demonstrations on Franka arms across diverse home and office environments.
BridgeData v2 — benchmark of choice for object-manipulation generalization.
RoboMind / RoboCasa — UC Berkeley and NYU; mixed synthetic and real-world data.
ALOHA / Mobile ALOHA — Stanford's bimanual teleoperation imitation-learning standard.
HumanoidBench — humanoid benchmark suite.

The open challenge is tokenization and embodiment mismatch across datasets. Embodiment-agnostic models like OpenVLA and Octo are the active research frontier.

19. Standard Hardware Platforms — Where to Start

If you are starting a ROS 2 robot in 2026, which hardware should you reach for?

TurtleBot 4 — the canonical ROS 2 mobile education platform, built on iRobot Create 3.
Clearpath Husky / Jackal / Warthog — outdoor and rugged research robots. Clearpath is a long-standing ROS partner.
Universal Robots UR3/5/10/16/20 — collaborative manipulator arms. Mature ROS 2 driver.
Franka Emika Panda — 7-DOF arm with torque sensing. Academic standard.
Robotiq grippers — standard end-effectors paired with cobots.
Boston Dynamics Spot — quadruped plus Spot SDK plus ROS 2 interface.
Unitree Go2 / G1 / H1 — high-bang-for-buck quadrupeds and humanoids.
OAK-D / Intel RealSense / ZED — the RGB-D camera triangle.
Velodyne / Ouster / Livox / Hesai — LiDAR lineup.

Selection criteria: community support, driver maturity, then budget. TurtleBot 4 + UR + Spot is the most common "school three-piece."

20. Korean Robotics Landscape — 2026

Trends in Korea.

Hyundai Robotics (HD Hyundai Robotics) — top-five industrial manipulator vendor worldwide. Official ROS 2 drivers.
Doosan Robotics — cobot lineup (M, H, E series). Dart Suite plus ROS 2 interface.
Rainbow Robotics — founded by KAIST Hubo alumni. RB series cobots and humanoids. Samsung Electronics took a stake in 2024.
ROBOTIS — DYNAMIXEL servos and OP3 humanoid. Dominant in the education market. Official ROS 2 support.
NAVER Labs — HORIZON autonomous driving, MINIRO service robots, ARC cloud robotics platform.
KAIST Hubo Lab — the HUBO series. A pillar of global humanoid research. Won the DARPA Robotics Challenge.
Hyundai Motor Group + Boston Dynamics — after the 2021 acquisition, the new electric Atlas was unveiled. Deployed on automotive assembly lines.

The 2026 trend: government investment is concentrated on three pillars — humanoids, cobots, autonomous driving. Industrial clusters of note are Songdo (Hyundai), Daejeon (KAIST, ROBOTIS), and Siheung (Rainbow).

21. Japanese Robotics Landscape — 2026

Japan remains the home of industrial robotics, while humanoid and service-robot activity is also brisk.

Toyota Research Institute (TRI) — leads Drake. The Human Support Robot (T-HSR) is the canonical home-assistance research platform.
Honda Asimo (legacy) — officially retired in 2022. Honda has shifted focus from humanoids to mobility.
Preferred Networks (PFN) — collaborates with Toyota and Fanuc. Leader in applying deep learning to industrial automation.
Sony Aibo — consumer companion robot, periodically refreshed with new AI features.
OMRON — industrial automation, AGVs, and integrated cobot solutions.
Fanuc / Yaskawa / Kawasaki — the global big three of industrial robotics.
Cyberdyne HAL — medical and rehabilitation exoskeletons.
Mujin — logistics automation plus the Mujin Controller (their integrated controller).
GROOVE X LOVOT — emotional companion robot.

The Japanese pattern: industrial robotics is enormously strong, but ROS adoption is conservative. Native controllers from Fanuc and Yaskawa dominate, so ROS lives mostly in R&D and new categories.

22. Learning Resources, Community, Conferences

The standard 2026 learning path.

Official tutorials — docs.ros.org, the Jazzy tutorials are the freshest.
The Construct — online ROS school with hosted lab environments.
Open Robotics teaching material — shared on discourse.ros.org.
ROS Industrial Consortium — the standard community for industrial adoption. Chapters in the Americas, Europe, and Asia.
ROSCon — the flagship annual conference each fall. ROSCon 2026 is slated for Singapore.
ROS Developer's Day — once or twice a year, online.
IROS, ICRA, RSS — the big-three academic conferences.
Humble-Bundle-style robotics book bundles — common appearance on book sites.

Recommended reading: Steven Macenski's Nav2 papers, the MoveIt official tutorials, "Modern Robotics" (Lynch and Park), and "Probabilistic Robotics" (Thrun et al.) — the latter is a classic and still essential.

23. Ten Common Traps

The failure patterns that keep recurring.

Topics invisible due to QoS mismatch — declare pub/sub profiles deliberately from day one.
Mixing CycloneDDS and FastDDS breaks discovery — pick one RMW for the whole system.
Attempting 1 kHz control purely in rclpy — the GIL and overhead make it impossible; do low-level in C++.
Hardcoding everything in launch.py — split out parameters, includes, and env vars.
Works in sim but breaks on hardware — the sim-to-real gap. Verify URDF friction, inertia, and calibration.
Broken TF tree — clock-sync mistakes between static_transform_publisher and dynamic TF.
Running image pipelines without composition — CPU and memory explode.
No rosbag recording — incidents are unreproducible. Always record MCAP.
tf2 time-correction errors — apply use_sim_time consistently across every node.
Ignoring lifecycle nodes — Nav2 and any system integration loses state visibility.

24. Seven Criteria for Picking Your Stack

To summarize, seven dimensions decide the right combination.

Distribution — new starts on Jazzy or Lyrical, production stays on Humble.
Middleware — Fast DDS by default, Zenoh for multi-robot and wide-area cases.
Simulator — Gazebo Harmonic for fidelity, Isaac Sim/Lab for GPU-scale learning, Drake for precise dynamics.
Motion planning — MoveIt 2 for manipulation, Nav2 for navigation.
Visualization and debugging — the trio RViz2 + Foxglove + PlotJuggler.
Learning stack — Isaac Lab for RL, LeRobot / HuggingFace / OpenVLA for imitation.
Hardware — TurtleBot 4 (education) to UR/Franka (manipulation) to Spot/Husky (mobility).

The selection principle: "which combination is reasonable under our constraints?" — not "which tool is the best?". And that combination has to be re-evaluated every one to two years, because humanoid foundation models are reshuffling the board every twelve months.

25. The Next Decade — What's Coming

Long-range trends.

VLA models becoming ordinary — base models that handle many tasks with small embodiment-specific tuning.
Closing the sim-to-real gap — Isaac Sim/Cosmos, Drake, and Gazebo continue to push physical fidelity.
An explosion of data infrastructure — successors to Open X-Embodiment will arrive quarterly. Data labeling and curation become a primary discipline.
Humanoid commodification — leased humanoids spread into homes, warehouses, and food service.
Safety certification — ISO 10218 (industrial), ISO 13482 (service robots), and a new humanoid-safety regime crystallizing.
Possible post-DDS middleware — Zenoh, a new RMW, or even a successor to ROS 2 itself are seriously discussed.
Edge-cloud splits — inference in the cloud, control on the edge.

Epilogue — Robots Are the Intersection of Code, Data, and Physics

One-line summary of this article: A 2026 robot is a machine that runs a VLA model on top of ROS 2.

Ten years ago, robots were a stack of PID loops, state machines, and hand-coded motion sequences. In 2026, on top of that stack sits large models, synthetic data, and simulation-based learning as a new layer. But the bottom layer is still ROS 2's topics, services, actions, and TF trees. Above that, Nav2 and MoveIt. Above that, Gazebo and Isaac. At the top, the VLA model.

Over the next decade, robotics engineers will spend less time tuning PID gains and more time designing interfaces between models, data, and middleware. PID, kinematics, and TF do not disappear, though. In an age of layered abstractions, the strongest engineer is the one who can move comfortably between every layer.

12-Item Checklist

Is the chosen distro inside the EOL window?
Is the RMW consistent across the system?
Have you picked QoS profiles deliberately?
Are all critical nodes lifecycle-managed?
Is composition used for intra-process throughput?
Do URDF and SRDF match the real robot?
Are you measuring and managing the sim-to-real gap?
Is every run recorded as rosbag/MCAP?
Does CI/CD include simulation tests?
Is the middleware choice future-proofed for multi-robot and wide-area?
Are data, models, and code versioned together?
Is there a safety, certification, and legal review process?

Ten Anti-Patterns

Trying to port ROS 1 code one-to-one — the model is different.
Mixing RMWs — the canonical cause of broken discovery.
Doing 1 kHz control in rclpy — go C++.
Sloppy URDF — the start of every sim-to-real gap.
Forcing everything through topics — use actions, services, and parameters.
Skipping composition — mandatory for big-data flows.
Operating without rosbag — incidents are unanalyzable.
Deploying only after sim validation — reality breaks it.
Training forever on first-generation data — datasets need freshness management.
Treating safety certification as an afterthought — bake it into design from day one.

Coming Up

Candidate next posts: Hands-on Isaac Lab — teaching a quadruped to walk with RL, MoveIt Pro versus OSS MoveIt 2 — industrial adoption guide, Fine-tuning a VLA model — from Open X-Embodiment to your robot.

"Robots live at the intersection of code, data, and physics. You can't be world-class at one of them and ignore the other two."

— ROS 2 & Robotics Stack 2026, end.