Robotics

Mehran Mozaffari·Updated 1 September 2026

10 resources0 related posts

Robotics Is Now Two Fields Sharing One Word

Everything called "robotics" in 2026 splits into two overlapping but differently-shaped disciplines, and most bad adoption decisions come from evaluating one with the other's criteria. The first is the classical deployable stack: middleware, motion planning, simulation, drivers, and control — decades-old engineering problems with mature open-source answers, measured in reliability, correctness, and integration cost. The second is the learned-behavior stack: teleoperation data, imitation and reinforcement learning, vision-language-action policies, and sim-to-real transfer — a much younger discipline measured in generalization and data throughput. Both matter; they are converging; but they buy different things. A warehouse operator choosing ROS 2 and MoveIt cares that a planner provably avoids collisions for the ten-thousandth cycle. A lab collecting manipulation data on an ALOHA rig cares that a policy generalizes to the eleventh object. The projects in this dossier increasingly serve both — LeRobot ships ROS-compatible robots with VLA training; Isaac Lab trains policies that deploy onto ROS 2 robots — but their licences, cost shapes, and failure modes remain sharply different, and pretending otherwise is how teams pick a GPU-cluster tool for a forklift problem.

What gets miscategorized into this field: humanoid-company demos (videos are marketing artifacts until there is a price sheet and an SDK), pure simulation benchmarks with no transfer story, and consumer "robots" (vacuums, mowers) that are appliances with a motor. The center of this dossier is the layer where software engineers actually make adoption decisions: middleware, planning, simulation, data collection, and the SDK boundary of commercial hardware.

The Middleware War Is Over: ROS 2 Won and Set the Terms

The Robot Operating System is a "meta operating system for robots" — libraries and tools from drivers to algorithms — maintained by the non-profit Open Source Robotics Foundation, and ROS 2's victory over both ROS 1 and every would-be replacement is now settled enough that the interesting question changed. It is no longer "which middleware" but "what did ROS 2's win commit you to." The answers: a DDS-based transport with pluggable implementations (Fast DDS, Cyclone DDS — Isaac Lab's own Docker images ship configuration files for both), a time-boxed distribution treadmill (Humble, Jazzy, Kilted, Rolling per REP-2000) that functions like Ubuntu LTS cycles for robots, a colcon workspace build model, and an ecosystem gravity that means any sensor, arm, or mobile base you buy probably has a ROS 2 driver before it has documentation. The stack is Apache-2.0 licensed and supported by an ecosystem (Discourse, Robotics Stack Exchange, an annual conference, a Science Robotics citation) that functions as the field's common language.

My position: ROS 2 is the correct default for anything mobile, multi-sensor, or multi-process, and the argument against it — complexity, DDS discovery quirks, the distribution treadmill — is real but is now an argument about configuration, not about choice. The counter-case that remains legitimate: single-arm manipulation cells and deeply embedded controllers where ROS 2's transport machinery buys nothing, and where a 200-line Python loop against the vendor SDK is more maintainable than a graph of nodes. Mobile ALOHA — arguably the most consequential robot-software project of the decade — still runs on ROS 1 Noetic with ROS 2 support explicitly "underway," which is the field's own verdict on how much middleware a focused manipulation rig actually needs.

Motion Planning Is a Commodity With a Sales Layer

MoveIt 2 (BSD-3-Clause, led by PickNik) is the manipulation planning framework for ROS 2, and its package table is the honest map of what manipulation actually involves: kinematics, collision detection, OMPL/CHOMP/STOMP/Pilz planners, a real-time servoing layer (moveit_servo), perception integration, trajectory caching, a setup assistant, and moveit_py for Python-native use. It is maintained across every active ROS 2 distribution with per-distro stable branches that take backports only — the discipline of infrastructure software, not research code. The commercial layer is explicit: MoveIt Pro is PickNik's supported product, and the open framework's README points to it. My position: for any arm-based application that must prove it won't hit anything — industrial cells, medical-adjacent automation — MoveIt 2 is not one option among several; it is the option, with the open core paying for itself and MoveIt Pro bought exactly when you need someone else to carry the reliability pager. The learned-policy alternative (VLA models predicting joint targets directly) does not yet give the collision guarantees regulated deployments need, which is why MoveIt keeps winning the jobs that pay.

The genuine failure mode here is configuration, not code: MoveIt's behavior depends on a careful SRDF, controller manager wiring, and perception tuning that the setup assistant only partially automates. Teams routinely spend more time on the robot-description plumbing than on planning parameters, and the MIGRATION.md file in the repo testifies to an API surface that has moved enough between ROS 2 generations to strand casual adopters.

The classical stack's core promise is visible in the ROS 2 action lifecycle that MoveIt wraps: a manipulation goal becomes an asynchronous contract with feedback, preemption, and a result — the machinery that makes a planner auditable in production:

sequenceDiagram
    participant App as Application node
    participant MG as MoveGroup action server
    participant PL as Planner OMPL STOMP or Pilz
    participant EX as Controller manager
    App->>MG: send goal (target pose or joint state)
    MG->>PL: planning request with scene and constraints
    PL-->>MG: candidate trajectory
    MG-->>App: goal accepted, feedback topic live
    MG->>EX: execute trajectory on controllers
    loop until done or preempted
        EX-->>MG: execution feedback
        MG-->>App: progress feedback
    end
    alt completed cleanly
        EX-->>MG: success
        MG-->>App: result succeeded
    else abort or collision check failure
        EX-->>MG: aborted
        MG-->>App: result aborted, replan or escalate
    end
    Note over App,EX: the action contract makes planning auditable<br/>goals are tracked, preemptable, and logged as results

Simulation Split Into Three Answers to Three Different Questions

The simulator landscape looks crowded and is actually three non-overlapping answers. Gazebo (gz-sim, Apache-2.0, OSRF) answers "how do I simulate the whole robot system — sensors with noise, plugins, GUI, ROS integration — before hardware exists": multiple physics engines through gz-physics, OGRE2 rendering, LIDAR/camera/IMU/force-torque sensor models, SDF as the description language, and a 16-year lineage. It is system-engineering simulation. MuJoCo (Apache-2.0, Google DeepMind) answers "what is the contact physics actually doing": it is the reference simulator for contact-rich dynamics — legged locomotion, manipulation — with the MJX GPU branch enabling RL-scale rollouts, and it is the simulator that projects like MicroDuck and the Open Duck Mini line use to train walking policies that then run on real hardware. Isaac Lab (BSD-3 framework on NVIDIA's Isaac Sim) answers "how do I train at GPU scale": thousands of parallel environments, RTX sensor simulation, 16+ robot models and 30+ ready-to-train environments, built explicitly for RL, imitation learning, and sim-to-real.

The Isaac Lab licence structure deserves the scrutiny it gets in its own README: the framework is BSD-3, the mimic extension is Apache-2.0 — but full-featured workflows (PhysX, RTX rendering, URDF/MJCF importers) require Isaac Sim, which "includes components under proprietary licensing terms," and the mimic extension depends on cuRobo, which is proprietary. A "BSD-3 open-source simulator" whose physics and rendering require a proprietary NVIDIA runtime is a freemium arrangement, and teams should read the Isaac Sim licence before committing. The mitigation the README itself offers — kit-less Newton workflows that do not require Isaac Sim — indicates where this is heading, but today the dependency is real. My positions: Gazebo for system integration testing and ROS-native workflows; MuJoCo when contact fidelity is the research object; Isaac Lab when RL sample throughput is the bottleneck and the NVIDIA coupling is acceptable. Choosing two of the three simultaneously is possible (MuJoCo for policy training, Gazebo for system tests) but doubles the model-maintenance burden across description formats — SDF, MJCF, URDF — which is one of the field's chronic unpriced costs.

The Data-Collection Robot Became a Product Category

The most consequential robotics-software artifact of the decade is arguably not a planner or a simulator but ALOHA — and its Mobile variant (MIT licence, Stanford and collaborators) — because it turned data collection into a designed system: four synchronized low-cost arms (two leader arms a human holds, two follower arms that mimic), three cameras, teleoperation scripts, episode recording to HDF5, and ACT imitation learning on the other side. The repository's setup documentation is a masterclass in what robot reality is: udev rules binding each arm and camera to stable device symlinks because USB enumeration changes across reboots, per-motor current limits set in Dynamixel Wizard to prevent gripper overloads, an explicit warning that the robot "will collapse" if motors torque off because joints have no brakes, a documented patch to an Interbotix SDK function because forward kinematics at every step delays teleoperation. Every one of those lines is a failure mode somebody hit and documented — which makes the repo as much an operations manual as software.

Around that template an economy formed: LeRobot (Apache-2.0) standardized the dataset format (Parquet states, MP4 video) and hosts community datasets on the Hugging Face Hub; the SO-ARM101 gave the pattern a ~$100-per-arm hardware expression; and openpi's π0-family checkpoints — pre-trained on 10,000+ hours of robot data, Apache-2.0 code, fine-tuning documented down to LoRA on a 24GB GPU — turned that data into generalist manipulation policies that physical-intelligence itself frames as "may or may not work for you" experiments. My position: the teleop-rig-plus-shared-dataset pipeline is the most intellectually honest part of modern robotics — progress is measurable in episodes collected and policies fine-tuned — and it is also the most reproducible, because every layer is open and the reference hardware is cheaper than a conference registration.

Commercial Hardware Opened Its Lowest Layers

Unitree's SDK2 (BSD-3-Clause, C++) is the reference case for the closed-hardware/open-interface model that now dominates commercial robotics. The repository exposes high-level sport clients (walking, standing, trajectory following) and low-level joint control across the whole lineup — Go2 and Go2W quadrupeds, the B2, the G1 and H1/H2 humanoids, the A2 — over DDS, with examples that descend all the way to individual joint commands and behavior sequences for the humanoid arms. The licence is permissive; the hardware is not open, and the firmware boundary is opaque. This is the deal: you get BSD-licensed control-plane code and a real API to research-grade locomotion at consumer-hardware prices, in exchange for closed servo firmware, a vendor support forum as the documentation frontier, and the knowledge that your low-level access depends on a company whose roadmap you do not control.

My position: this arrangement is currently the best value in robotics for anyone who needs legged or humanoid capability without building actuators, but it should be adopted with the same eyes you'd apply to a SaaS dependency — the SDK is open, the platform is not, and the durable part of your work should live above the SDK boundary (perception, planning, learning) where it survives a hardware change.

The Options, Side by Side

Project	Role	Licence	Cost shape	What it commits you to	My position
ROS 2	Middleware, ecosystem	Apache-2.0	Free; engineering time in config	DDS transport, distro treadmill, workspace tooling	Default for mobile/multi-sensor robots
MoveIt 2	Manipulation planning	BSD-3-Clause	Free; MoveIt Pro for supported deployments	ROS 2, robot-description plumbing	The choice when collisions must be provable
Gazebo (gz-sim)	System simulation	Apache-2.0	Free; CPU-bound fidelity	SDF, ROS integration patterns	System-level testing before hardware
MuJoCo	Contact dynamics	Apache-2.0	Free; GPU optional via MJX	MJCF models, Python ecosystem	The reference for contact-rich policy training

How the two stacks interlock in practice — training happens in the learned stack, deployment happens in the classical stack, and the seam between them is where most integrations are custom:

flowchart TD
    SIMA[Isaac Lab<br/>GPU-parallel RL training] --> CKPT[Policy checkpoint or ONNX export]
    SIMB[MuJoCo<br/>contact-fidelity training] --> CKPT
    TELEOP[ALOHA-style teleop rig<br/>leader arms plus cameras] --> DS[LeRobotDataset on the Hub]
    DS --> FT[Fine-tune pi0 family or ACT<br/>on your episodes]
    FT --> CKPT
    CKPT --> DEP{Deployment path}
    DEP -->|learned behavior| ROS1[ROS 2 node runs the policy<br/>actions gated by safety checks]
    DEP -->|classical planning| MV[MoveIt 2 plans and validates<br/>collision-free trajectories]
    ROS1 --> HW[Robot hardware via vendor SDK<br/>unitree_sdk2, Dynamixel, Feetech]
    MV --> HW
    HW --> SENSOR[Real sensors feed back to both stacks]
    SENSOR --> SIMA
    SENSOR --> TELEOP

Choosing by Constraint: Deployment Risk, Data Ambition, Hardware Budget

Deployment risk first. If the robot must not hit anything, ever, in a workplace with humans: ROS 2 + MoveIt 2 with formal collision checking, and learned policies only inside guarded envelopes — the planning stack exists precisely because learned behavior cannot yet make the safety case. If the goal is capability demonstration and research velocity, invert it: Isaac Lab or MuJoCo for training, LeRobot for data, and let ROS 2 enter only at deployment.

Data ambition second. The decision that dominates the learned stack is not "which policy" but "can I collect data": a Mobile-ALOHA-class rig (or its SO-101 economy version) plus LeRobot turns manipulation into a data problem you can actually fund, and openpi's fine-tuning recipes consume that data directly. Teams that skip the collection-rig step and try to prompt zero-shot checkpoints into their tasks discover what Physical Intelligence's own README admits: the checkpoints may or may not work on your platform.

Hardware budget third, and honest about coupling. Unitree's SDK gives legged and humanoid capability at the lowest published prices in its class, with BSD licensing on the code — but the closed firmware means your escalation path for hardware bugs is the vendor, not the source tree. The fully open path (SO-101 arms, printed humanoids) inverts this: everything is inspectable, and actuator quality is your ceiling. The middle path — NVIDIA's — is the one to price most carefully: "free" Isaac Lab on proprietary Isaac Sim is free the way a printer is cheap.

Where It Breaks

Sim-to-real gaps that show up as micro-friction, not catastrophe. Policies trained in MuJoCo or Isaac Lab transfer with degraded contact behavior: gripper slip on real object textures, latency in the control loop the simulator modeled as instantaneous, actuator backlash the URDF never expressed. Trigger: first deployment of a sim-trained policy onto physical hardware; Open Duck Mini's repository literally maintains a "state of sim2real" section because this gap is the project's permanent frontier. Mitigation is domain randomization and on-robot fine-tuning, both of which are engineering work the "sim-to-real" phrase hides.

MoveIt configuration debt. Planners return "goal state is in collision" on robots whose self-collision matrix is subtly wrong, or whose perceived octomap disagrees with reality. Trigger: new workcell geometry, camera recalibration, any change to the URDF/SRDF. The failure is silent in simulation and loud on hardware, which is why Gazebo-in-the-loop testing of the full MoveIt stack is standard practice rather than perfectionism.

The version treadmill, on both sides. ROS 2 distros age out; Isaac Lab pins exact Isaac Sim versions (3.0.0-beta2 requires Isaac Sim 6.0.x; the main branch supports 4.5–5.1), so a framework upgrade can strand your environment definitions. Mobile ALOHA's tested configuration is Ubuntu 18.04/20.04 with ROS 1 Noetic — an EOL distribution running the most-copied data-collection pipeline in the field. Trigger: any "we should upgrade" initiative. The honest mitigation is pinning and container images, and the honest cost is that upgrades are projects, not patches.

Whole-body teleoperation is physically fragile. The ALOHA docs warn that the robot collapses if motors torque off — joints have no brakes — and that USB port binding drifts across reboots until tamed by serial-number udev rules. Trigger: power events, cable re-plugs, OS updates that re-enumerate devices. A data-collection rig is a lab instrument: it needs a checklist, an interlock culture, and scheduled re-validation of its device bindings.

Hardware safety is never in the SDK. Nothing in unitree_sdk2, MoveIt, or a learned policy carries the safety case for a robot moving near people — e-stop wiring, speed-and-separation monitoring, workspace fencing. Trigger: first human inside the workspace. Open licences transfer code, not liability; the safety case is the adopter's, always.

Open Questions

The first is whether the two fields' tooling actually converges or just interlocks. The learned stack wants GPU-parallel simulation, dataset formats, and policy checkpoints; the classical stack wants certified planners, DDS QoS, and lifecycle management. Isaac Lab shipping Cyclone DDS configs and MoveIt gaining trajectory caches are early welds, but a robot that plans with MoveIt, executes under a π0-style policy, and re-plans when the policy drifts does not exist as a supported configuration anywhere yet — the integration is everyone's homework.

The second is the closed-core pattern's endpoint. Isaac Lab (BSD on a proprietary runtime), unitree_sdk2 (BSD on closed firmware), and MoveIt Pro (open core plus commercial product) all trade some openness for capability. The field has not yet produced the norm for saying how much openness a project must retain before "open-source robotics" stops being an accurate label — and the answer matters because every licence decision in the table above was made by a vendor or lab, not a commons.

The third is data. π0's pre-training consumed 10,000+ hours of robot data; the community's public datasets are orders of magnitude smaller and narrower. Whether manipulation's ImageNet moment arrives through shared teleoperation datasets (the LeRobot trajectory) or through proprietary fleets (the industrial trajectory) decides whether the learned stack's progress stays inspectable — and it is the one question in this field where a single team's data-collection budget is a vote.