Awesome Agentic Robotics

A systems-oriented map of robotics: hardware, classical foundations, simulation, autonomy stacks, robot learning, embodied foundation models, datasets, and interview preparation.

Robotics is not one stack. A useful robot joins mechanics, actuation, sensing, estimation, planning, control, real-time software, data, learned policies, and safety into one closed loop. This repository is organized around those interfaces rather than around hype cycles.

Last reviewed: 2026-08-03 · Catalog version: 0.1.0

• Start here
• The robotics stack
• Hardware landscape
• Core software stack
• Robot learning and foundation models
• Essential papers
• Datasets and benchmarks
• Foundations and courses
• Interview preparation
• How to evaluate claims
• Repository map
• Contributing

flowchart TB
    GOAL[Task / language goal] --> TASK[Task and behavior planning]
    TASK --> MOTION[Motion planning / learned policy]
    MOTION --> CONTROL[Whole-body and joint control]
    CONTROL --> ACT[Actuators and mechanism]
    ACT --> WORLD[Physical world and contacts]
    WORLD --> SENSOR[Sensors]
    SENSOR --> EST[Calibration, perception, state estimation]
    EST --> TASK
    EST --> MOTION
    EST --> CONTROL
    SAFETY[Independent safety system] -. constrains .-> TASK
    SAFETY -. constrains .-> CONTROL
    SIM[Simulation + digital twins] -. test/train .-> EST
    SIM -. test/train .-> MOTION
    DATA[Demonstrations + robot data] -. train .-> MOTION

The central engineering fact is the feedback loop. An agentic planner may choose what to do, but a controller must still produce stable commands at the robot's required rate, and an independent safety path must be able to stop it.

The table is deliberately compact. Availability means something different for a research kit, an enterprise deployment, and a prototype announcement; verify the linked primary source before making a purchasing or investment decision.

See the detailed hardware landscape, including selection criteria, actuators, sensors, compute, and what vendor demos do not establish.

Use software-stack.md for simulator selection and layer-by-layer study. For a stable learning environment, prefer a supported ROS 2 LTS distribution over Rolling unless you specifically need unreleased features.

Behavior cloning / offline RL
  ├─ ACT and Diffusion Policy: action chunks and expressive continuous policies
  ├─ RT-1 / RT-2 / RT-X: transformer policies, web knowledge, cross-embodiment data
  ├─ Octo / OpenVLA / SmolVLA / openpi: reproducible open model stacks
  └─ GR00T / Gemini Robotics / Helix / π-series: larger-scale generalist and whole-body systems

Read foundation-models.md before comparing headline success rates. Embodiment, control frequency, action representation, camera placement, evaluation resets, and human intervention policy can dominate a model-name comparison.

The curated paper reading guide covers operational-space and impedance control, RRT/PRM, GraphSLAM/ORB-SLAM, deep RL and sim-to-real, modern manipulation policies, and the VLA lineage from RT-1 through open models and 2026 frontier systems. It also provides a paper-reading rubric and reproduction ladder.

See datasets-benchmarks.md for data leakage, reset policy, confidence intervals, intervention accounting, and cross-embodiment normalization.

• Modern Robotics — screws, SE(3), kinematics, Jacobians, dynamics, planning, and control with code.
• Underactuated Robotics — nonlinear dynamics, optimization, planning, control, contact, and learning.
• MIT Robotic Manipulation — perception, planning, contact, grasping, and modern manipulation systems.
• Planning Algorithms — freely available reference for geometric, sampling-based, feedback, and decision-theoretic planning.
• ETH Robot Dynamics — rigid-body dynamics, legged systems, and estimation/control practice.
• Berkeley CS 285 — deep reinforcement learning.

• coordinate frames, rotations, quaternions, Lie groups SO(3) and SE(3);
• forward/inverse kinematics, Jacobians, singularities, manipulability;
• rigid-body dynamics, contacts, friction, inverse dynamics;
• PID, impedance/admittance control, LQR, MPC, whole-body control;
• Bayes filters, EKF/UKF, factor graphs, SLAM, calibration and observability;
• graph search, sampling-based motion planning, trajectory optimization;
• behavior cloning, offline/online RL, imitation learning, diffusion/flow policies;
• real-time scheduling, concurrency, latency budgets, safety and verification.

The math primer collects the core equations and common mistakes.

A robotics interview usually samples several layers rather than one:

1. Math/algorithms: transforms, Jacobians, least squares, probability, graph search.
2. Controls/estimation: stability, feedback, filters, calibration, sensor timing.
3. Software: C++/Python, ROS 2, concurrency, memory, networking, debugging.
4. Domain depth: manipulation, navigation, perception, locomotion, or learning.
5. Systems design: rates, interfaces, failure handling, logging, deployment, safety.
6. Experimentation: baselines, ablations, confidence intervals, sim-to-real validation.

The interview guide provides question prompts, expected reasoning, coding exercises, system-design cases, and portfolio projects. The learning roadmap turns the repository into a 12-week curriculum.

Do not equate a polished video with general autonomy. Ask:

• Was the run autonomous, teleoperated, scripted, cherry-picked, or reset between clips?
• How many trials, environments, objects, operators, and hardware units were tested?
• Were failures, safety stops, interventions, and recovery time counted?
• Is success binary, partial-credit, time-bounded, or judged by the authors?
• What runs on-board, what runs in the cloud, and what is the end-to-end latency distribution?
• Does the policy survive camera shifts, payload changes, worn grippers, latency, and disturbances?
• Are train/test tasks, objects, scenes, and embodiments genuinely disjoint?
• Can results be reproduced from released code, weights, data, robot description, and calibration?

The repository records access and maturity separately: open code is not proof of capability, and a commercial deployment is not proof of generality.

Contributions are welcome. Read CONTRIBUTING.md and update the canonical YAML first. Every entry needs a primary source, company/steward, access level, maturity, review date, and a concrete explanation of why it belongs.

make setup
make report
make validate

Inclusion is not endorsement. Specifications, availability, licenses, and model access change; verify official sources before purchasing hardware, deploying software, or operating a robot.