Robotics AI Engineer

• Brain: robot learning, policy models, vision-language-action models, task reasoning, skill selection, memory, planning interfaces, and learned behavior systems.
• Eyes: learned perception, scene understanding, object detection, segmentation, visual representations, video models, and multimodal sensor understanding.
• Hands: imitation learning, visuomotor policies, grasping, dexterous manipulation, bimanual manipulation, tactile learning, and contact-rich skills.
• Legs: reinforcement learning, whole-body policies, learned locomotion, balance recovery, terrain adaptation, and sim-to-real tuning.
• Simulation layer: large-scale training environments, synthetic data, domain randomization, policy evaluation, sim-to-real validation, and digital robot twins.
• Data layer: teleoperation data, robot logs, human demonstrations, data quality, dataset curation, labeling, trajectory processing, and model evaluation datasets.
• Fleet layer: policy monitoring, failure mining, online/offline evaluation, model rollout gates, safety limits, and feedback loops from deployed robots.

A robotics AI engineer builds learning systems that help robots improve from data, simulation, demonstrations, and real-world evaluation.

In a humanoid company, the work often includes:

• Training learned policies for manipulation, locomotion, navigation, tool use, object handling, mobile manipulation, or whole-body behaviors.
• Building or fine-tuning vision-language-action systems that connect natural language, visual understanding, robot state, and robot actions.
• Developing imitation learning pipelines from teleoperation data, human demonstrations, motion capture, robot logs, video, or synthetic trajectories.
• Applying reinforcement learning to simulated robot tasks, then testing transfer to real hardware with controls, safety, and validation teams.
• Building multimodal models that combine camera images, depth, proprioception, force signals, tactile data, language instructions, robot state, and task context.
• Creating data pipelines for cleaning, filtering, segmenting, labeling, balancing, and replaying robot trajectories.
• Designing evaluation suites that show whether a model is more robust, not just more impressive in a cherry-picked demo.
• Debugging model failures such as distribution shift, poor recovery behavior, hallucinated goals, brittle grasping, unsafe actions, overfitting, sensor dependence, or sim-to-real gaps.
• Deploying models to real robot runtimes with latency, memory, GPU, power, observability, and fallback constraints.
• Working with perception engineers to decide what representations the policy needs from sensors.
• Working with controls and locomotion engineers to define action spaces, safety limits, tracking interfaces, and low-level control boundaries.
• Working with manipulation engineers to improve task success, dexterity, recovery behavior, bimanual coordination, and contact handling.
• Working with simulation engineers to create training environments, randomized scenarios, task distributions, and regression tests.
• Working with data and teleoperation teams to improve demonstration quality and failure coverage.
• Working with product and field teams to understand which robot tasks matter in real customer environments.

The role is research-heavy in some companies and engineering-heavy in others. In early humanoid teams, one person may move from a training script to a robot test session to a dataset review to a deployment bug in the same week.

What the work feels like day to day

A normal week might include:

• Reviewing failed robot trials and tagging whether each failure came from perception, policy output, controls, hardware limits, poor data, ambiguous instructions, or a bad test setup.
• Training a new manipulation policy on teleoperation demonstrations and checking whether it improves real robot pick success.
• Adding domain randomization to simulation because the policy only works in one lighting condition or with one object pose distribution.
• Testing whether a video-pretrained representation improves downstream task learning.
• Building an evaluation dashboard that compares model versions across task success, recovery rate, latency, safety interventions, and out-of-distribution scenarios.
• Debugging why a policy works in simulation but fails when a real gripper slips, a camera is slightly miscalibrated, or a human places an object differently.
• Working with controls engineers to decide whether the model should output joint targets, end-effector poses, residual actions, waypoints, contact targets, or high-level skills.
• Working with teleoperation teams to improve demo consistency, timing, viewpoint coverage, and action labels.
• Compressing, quantizing, or optimizing a model so it can run on robot compute without breaking latency budgets.
• Writing a short technical note that explains what changed, what improved, what regressed, and whether the model should be allowed onto hardware.

The best robotics AI engineers are not only model builders. They are careful experimenters who understand that robot intelligence is judged by repeatable physical performance, not by a single clean video.

Humanoid robots are meant to work in environments designed for people. Those environments are variable, messy, and full of objects, surfaces, instructions, constraints, and edge cases that are hard to hand-code. Learning-based systems are becoming important because the classical robotics stack alone struggles to cover the full range of real-world physical tasks.

Robotics AI engineering matters because humanoids need:

1. Generalizable skills
   A humanoid should not need a new hand-coded program for every object, shelf, drawer, package, tool, and instruction. Learned policies can help robots generalize across task variations, but only when trained and evaluated carefully.

2. Data-driven improvement
   Modern humanoid development depends on teleoperation data, robot logs, simulation rollouts, human motion data, synthetic data, and real-world trials. Robotics AI engineers turn this data into measurable capability improvements.

3. Perception-to-action learning
   The hard part is not only recognizing objects. The robot must use sensory input to choose physical actions under uncertainty. That means connecting images, depth, language, proprioception, force, and robot state to action.

4. Better recovery behavior
   Real robots fail constantly: they miss grasps, slip, collide lightly, lose track of objects, encounter clutter, face ambiguous instructions, or drift from expected state. Learning-based systems can help with recovery if the training and evaluation data includes failure cases.

5. Scalable task acquisition
   Humanoid companies cannot manually engineer every behavior forever. They need methods that learn from demonstrations, simulation, fleet data, and repeated trials.

6. Robot foundation models
   The field is moving toward large multimodal models that connect vision, language, action, video, temporal structure, and robot state. These systems may become the reusable intelligence layer for many robot tasks, but they still need careful grounding in physical constraints.

7. Sim-to-real transfer
   Many policies are first trained or stress-tested in simulation because real robot time is expensive and risky. Robotics AI engineers help decide which simulation results are meaningful and which are just simulation artifacts.

8. Deployment discipline
   A model that performs well offline can still fail on robot hardware because of latency, memory limits, sensor timing, action saturation, poor fallback states, or unexpected human behavior. Robotics AI engineers need to understand deployment, not only training.

A simple rule: in humanoid robotics, AI is useful when it improves reliable physical behavior. It is not enough for a model to sound intelligent or score well on a static benchmark. The robot has to do the task, recover when it fails, and stay inside safe operating limits.

This role fits people who like machine learning, robotics, data, experiments, and real-world feedback. It is a strong role, but it is not usually the easiest beginner entry point because many openings expect strong ML depth, robotics intuition, or research evidence.

AI and machine learning engineers

You already have useful skills: Python, PyTorch or JAX, model training, evaluation, datasets, metrics, experiment tracking, deployment, optimization, and debugging model behavior.

You are probably missing: robot kinematics, action spaces, contact, simulation, controls interfaces, sensor timing, teleoperation data, hardware constraints, and safety limits.

Best entry angle: robot learning engineer, embodied AI engineer, AI infrastructure engineer for robotics, model evaluation engineer, data/model pipeline engineer, learned perception engineer, or imitation learning engineer.

Robotics software engineers

You already understand robot systems: middleware, sensors, transforms, logs, simulation, deployment, debugging, runtime constraints, and cross-functional integration.

You are probably missing: modern deep learning training loops, imitation learning, reinforcement learning, representation learning, multimodal models, distributed training, and formal evaluation of learned policies.

Best entry angle: policy deployment engineer, robot learning infrastructure engineer, autonomy software engineer, simulation-to-policy integration engineer, or robotics AI engineer with strong systems grounding.

Robotics, CS, and engineering graduate students

You may already understand robotics math, ML papers, control theory, simulation, and research workflows.

You are probably missing: production code quality, real robot deployment, data quality discipline, robust evaluation, model monitoring, CI, and cross-team engineering constraints.

Best entry angle: AI research engineer, robot learning engineer, reinforcement learning engineer, perception learning engineer, or embodied AI research scientist depending on depth.

Perception engineers

You already understand sensors, computer vision, geometry, detection, segmentation, tracking, scene understanding, and real-time inference.

You are probably missing: action learning, policy interfaces, imitation learning, reinforcement learning, robot state, control constraints, and how perception errors propagate into physical actions.

Best entry angle: learned perception engineer, VLA engineer, world model engineer, multimodal representation learning engineer, or robotics AI engineer focused on perception-to-action.

Controls, locomotion, and manipulation engineers

You already understand robot dynamics, kinematics, contact, constraints, motion quality, hardware limitations, and physical testing.

You are probably missing: deep learning training stacks, dataset curation, reinforcement learning infrastructure, multimodal models, and large-scale experiment management.

Best entry angle: reinforcement learning engineer for locomotion or manipulation, sim-to-real learning engineer, residual policy engineer, learned whole-body control engineer, or robot behavior learning engineer.

Simulation and game-engine engineers

You already understand physics environments, scene generation, assets, performance, procedural variation, rendering, and runtime systems.

You are probably missing: robot learning objectives, reward design, imitation datasets, policy evaluation, action spaces, and sim-to-real failure analysis.

Best entry angle: robot learning simulation engineer, synthetic data engineer, policy evaluation engineer, training environment engineer, or sim-to-real learning engineer.

Data and teleoperation engineers

You already understand data collection, logs, labeling, human-in-the-loop workflows, data quality, dashboards, and operational edge cases.

You are probably missing: model training, robot kinematics, policy inputs/outputs, representation learning, and how dataset decisions affect physical robot behavior.

Best entry angle: robot learning data engineer, teleoperation-to-imitation-learning engineer, model evaluation engineer, data curation engineer for robot policies, or robotics AI infrastructure engineer.

Think of robotics AI in layers. Do not try to learn every topic at once. Start with the layer closest to your background, then build toward real robot evidence.

Core machine learning skills

These are the base for most robotics AI roles.

• Python: training code, data processing, evaluation scripts, automation, notebooks, and production-quality tooling.
• PyTorch or JAX: model definition, training loops, distributed training basics, automatic differentiation, GPU workflows, checkpointing, and debugging.
• Deep learning fundamentals: optimization, loss functions, regularization, representation learning, sequence models, transformers, diffusion models where relevant, and failure analysis.
• Data handling: dataset formats, train/validation/test splits, leakage prevention, sampling, balancing, augmentation, metadata, and reproducibility.
• Evaluation: metrics, ablations, baselines, confidence intervals, regression tracking, and honest reporting of failure cases.
• Experiment management: config files, seeds, logs, artifacts, versioning, dashboards, and reproducible runs.
• Model deployment: inference optimization, batching, quantization, GPU memory, latency, model serving, and fallback behavior.

Robot learning foundations

These separate robotics AI from generic ML.

• Imitation learning: behavior cloning, dataset aggregation, action chunking, diffusion policies, trajectory prediction, and learning from demonstrations.
• Reinforcement learning: reward design, policy gradients, actor-critic methods, offline RL basics, model-based RL concepts, exploration, curriculum learning, and sim-to-real transfer.
• Vision-language-action models: multimodal inputs, language-conditioned policies, action tokenization or continuous action outputs, temporal context, and embodied reasoning.
• World models: learned dynamics, video prediction, latent state, planning with learned models, and uncertainty.
• Representation learning: visual features, proprioceptive state, contact/tactile signals, language embeddings, and task-conditioned state representations.
• Human motion and teleoperation data: retargeting, alignment, time synchronization, action labels, demonstration quality, and recovery examples.
• Policy evaluation: success rate, partial success, recovery rate, intervention rate, constraint violations, latency, robustness, and real-world repeatability.

Robotics foundations

You do not need to become a controls PhD for every robotics AI role, but you need enough robotics to avoid naive model assumptions.

• Coordinate frames and transforms.
• Forward and inverse kinematics.
• Jacobians and velocity mappings.
• Basic rigid-body dynamics.
• Contact, friction, slip, impact, and compliance.
• Robot state: joint positions, velocities, torques, IMU, contact sensors, force/torque, tactile, battery, and health status.
• Action spaces: joint targets, joint velocities, torques, end-effector poses, waypoints, residual commands, skill selection, or language-conditioned task commands.
• Motion planning and control interfaces.
• State estimation basics.
• Sensor calibration and timing.
• Safety limits, emergency stops, watchdogs, and fallback states.

Humanoid-specific skills

These matter because humanoids combine dexterous manipulation, whole-body motion, dense sensing, and human environments.

• Whole-body state representation.
• Bimanual manipulation and upper-body coordination.
• Hands, wrists, arms, torso, head, and balance coupling.
• Contact-rich manipulation and locomotion.
• Language-conditioned task execution.
• Human demonstration data and motion retargeting.
• Teleoperation-to-autonomy workflows.
• Multi-camera perception and temporal context.
• On-robot inference constraints.
• Safe policy rollout and intervention handling.
• Failure mining from fleet logs.

Evaluation and deployment skills

This is where many AI candidates are weak. Robot companies care about whether your model can be tested, compared, deployed, and rolled back.

• Build task-specific evaluation suites.
• Track model versions against robot software versions, dataset versions, and hardware revisions.
• Separate offline validation from real robot validation.
• Define safety gates before hardware rollout.
• Detect regressions in task success, latency, stability, and intervention rate.
• Create failure taxonomies for robot trials.
• Use logs and videos to diagnose model behavior.
• Profile inference latency and memory on target hardware.
• Design fallbacks when the policy is uncertain, stale, overloaded, or outside its operating envelope.

Software and systems skills

Robotics AI engineers are often expected to write clean software, not just research scripts.

• C++ basics for robot runtime integration.
• ROS 2 or comparable robot middleware.
• Linux, Docker, Git, CI, and remote development.
• CUDA basics for debugging performance where relevant.
• Distributed training concepts.
• Data pipelines and storage.
• APIs between training systems, simulation, robot runtime, and evaluation dashboards.
• Documentation for model cards, eval reports, and rollout notes.

Do not present this list as a syllabus where every tool is required. Different humanoid companies use different stacks. These are the common clusters to recognize.

Languages

• Python: model training, data pipelines, evaluation, simulation scripting, log analysis, and automation.
• C++: robot runtime integration, low-latency inference hooks, middleware, sensor/action interfaces, and performance-sensitive code.
• CUDA: useful for candidates working on inference acceleration, custom kernels, or training performance.
• TypeScript: useful for evaluation dashboards, dataset review tools, teleoperation tooling, and internal model-review interfaces.

ML frameworks and training

• PyTorch: common deep learning framework for robot learning, perception, imitation learning, and policy training.
• TorchRL: PyTorch-native reinforcement learning components for decision-making, robotics, and simulation workflows.
• JAX: high-performance numerical computing and ML research stack, often used for fast experimentation, transformations, and large-scale training.
• TensorFlow: still appears in some robotics datasets and older model pipelines.
• Hugging Face tools: model sharing, datasets, transformers, and evaluation tooling where useful.
• Weights & Biases / MLflow: experiment tracking, metrics, artifacts, and run comparison.

Robot learning and simulation

• NVIDIA Isaac Lab: robot learning framework for training policies at scale, including reinforcement learning and imitation learning workflows.
• NVIDIA Isaac Sim: simulation, synthetic data, robot development, and sensor-rich virtual testing.
• MuJoCo: physics simulation widely used for robot learning, locomotion, manipulation, and control research.
• Drake: modeling, dynamics, optimization, simulation, and control-oriented robotics work.
• Gazebo: open-source simulation, ROS integration, sensors, physics, and robot testing.
• Genesis / SAPIEN / Brax / MJX: useful in some research or high-throughput simulation contexts.
• Unity / Unreal Engine: sometimes used for teleoperation interfaces, synthetic data, human motion generation, or procedural task worlds.

Robotics runtime and integration

• ROS 2: common robotics middleware for nodes, topics, services, actions, transforms, bags, parameters, and debugging.
• rosbag / MCAP: recording and replaying robot data.
• Foxglove / RViz: visualization of robot state, sensor streams, transforms, and logs.
• MoveIt 2: useful for manipulation interfaces, planning, and baseline comparisons.
• Pinocchio / RBDL / KDL: kinematics and dynamics libraries.
• Behavior trees or state machines: often used to coordinate learned policies with deterministic robot behavior.

Data and datasets

• Teleoperation datasets: human-controlled robot demonstrations used for imitation learning and evaluation.
• Robot logs: multimodal streams from real robot runs, including images, depth, proprioception, actions, faults, and operator interventions.
• Open X-Embodiment: open robot learning dataset and RT-X work that shows the direction of cross-robot data and policy learning.
• RLDS / TFDS-style formats: common in robot learning datasets.
• Parquet, HDF5, Zarr, WebDataset, TFRecord: common formats for large ML datasets depending on team preference.
• Data labeling/review tools: custom UIs, CVAT-style tools, video review systems, and failure-tagging dashboards.

Infrastructure and deployment

• Docker: reproducible training, evaluation, and deployment environments.
• Kubernetes / Ray / Slurm: distributed training and large-scale batch evaluation depending on company infrastructure.
• NVIDIA TensorRT / ONNX Runtime: inference optimization and deployment.
• Triton Inference Server: model serving in some ML infrastructure stacks.
• Prometheus / Grafana / OpenTelemetry: monitoring, metrics, and operational visibility.
• GitHub Actions / GitLab CI / Buildkite / Jenkins: CI pipelines for training code, evaluation, simulation tests, and tooling.

Lab and evaluation workflows

• Real robot test cells.
• Hardware-in-the-loop and software-in-the-loop setups.
• Simulation regression suites.
• Dataset review dashboards.
• Intervention logging.
• Task success scoring.
• Safety gate checklists.
• Latency and resource profiling tools.
• Model rollout reports.

A good robotics AI portfolio should show more than a trained model. It should show the full loop: data, model, evaluation, failure analysis, and a clear path toward robot deployment.

Do not overclaim. Be precise about what is simulated, what is real hardware, what is teleoperated, what is scripted, what is learned, and what still fails.

Project 1: Imitation learning policy from demonstrations

Build: a simple robot imitation learning project using teleoperation, scripted demonstrations, or an open robotics dataset. Train a policy to perform a task such as reaching, pushing, pick-and-place, drawer opening in simulation, or object sorting.

For a beginner-friendly version, use a simulated arm or mobile manipulator. For a stronger version, collect your own demonstrations with a low-cost robot arm, VR controller, gamepad, keyboard teleop, or simulated teleoperation interface.

What it proves:

• You understand demonstration data.
• You can build a policy training loop.
• You can evaluate success rate across task variations.
• You understand the gap between copying actions and robust physical behavior.
• You can explain dataset quality problems.

Evidence to include:

• GitHub repo with clean setup instructions.
• Dataset summary: number of demos, task variations, sensors, actions, and labels.
• Training configuration and model architecture.
• Evaluation results across at least three task variations.
• Video of successes and failures.
• Failure analysis explaining where the policy breaks.
• Clear note on what is simulated, real, teleoperated, scripted, or learned.

Project 2: Reinforcement learning policy with sim-to-real thinking

Build: train an RL policy in MuJoCo, Isaac Lab, Gazebo, or another simulator for a robot control task. Choose a task with physical meaning: balance, reaching, locomotion-like control, contact-rich pushing, grasp approach, or whole-body toy control.

You do not need a full humanoid to show evidence. What matters is that you make the evaluation honest and discuss sim-to-real assumptions.

What it proves:

• You understand policy training, rewards, observations, actions, resets, and evaluation.
• You can use simulation as a controlled training environment.
• You know reward hacking is a risk.
• You can compare model versions using metrics, not vibes.
• You understand why policies trained in simulation can fail on hardware.

Evidence to include:

• Reward design and explanation of trade-offs.
• Learning curves and evaluation metrics.
• Domain randomization or robustness tests.
• Ablation on at least one observation, reward, or randomization choice.
• Video of policy behavior.
• Sim-to-real risk note: latency, friction, actuator limits, sensing, contact, calibration, and safety.

Project 3: Vision-language-action mini system

Build: a small language-conditioned robot policy or task system. The robot receives an instruction such as “move the red block to the left tray” or “pick the object closest to the marker,” uses visual input or scene state, and chooses an action sequence.

This can be done in simulation. The goal is not to build a state-of-the-art foundation model. The goal is to show that you understand the interface between language, perception, robot state, and action.

What it proves:

• You understand multimodal inputs.
• You can connect high-level instructions to robot actions.
• You can design task representations.
• You can evaluate instruction-following failure cases.
• You can separate scripted planning from learned policy behavior.

Evidence to include:

• Task list and instruction templates.
• Model or policy architecture.
• Description of what is learned and what is hand-coded.
• Evaluation on held-out objects, positions, or instructions.
• Examples of ambiguous instructions and how the system handles them.
• Video and screenshots.

Project 4: Robot policy evaluation and failure-mining dashboard

Build: a tool that reads simulated or real robot rollouts, scores task outcomes, tags failures, and compares model versions.

This project is extremely valuable because many humanoid AI teams need better evaluation infrastructure. It can be built with public videos/logs, simulated rollouts, or your own generated data.

What it proves:

• You understand that model quality needs measurable robot outcomes.
• You can build practical tooling for researchers and engineers.
• You can define failure categories instead of only reporting average reward.
• You understand model rollout discipline.

Evidence to include:

• Dashboard screenshots.
• Rollout schema.
• Failure taxonomy.
• Comparison of at least two policy versions.
• Metrics such as success rate, partial success, timeout, collision, intervention, latency, and recovery.
• Explanation of how this would fit into a real robot deployment workflow.

Project 5: Robot learning data pipeline

Build: a data pipeline that ingests robot demonstration data, synchronizes observations and actions, filters bad segments, computes dataset statistics, and exports training-ready examples.

This can use simulated trajectories, Open X-Embodiment-style data, ROS bags, MCAP logs, or your own teleoperation recordings.

What it proves:

• You understand that data quality is central to robotics AI.
• You can work with temporal trajectories, not just image folders.
• You can detect bad data and document filtering choices.
• You can prepare data for imitation learning or model evaluation.

Evidence to include:

• Data schema.
• Synchronization method.
• Filtering rules.
• Dataset statistics.
• Before/after examples.
• Training-ready output format.
• Notes on bias, coverage, and missing failure cases.

Project 6: On-robot or edge-deployed inference demo

Build: deploy a small trained model into a robot-like runtime. It can be a real robot, a simulated robot with ROS 2, or a hardware-adjacent setup. The model should run with measured latency and produce actions, classifications, waypoints, or skill selections.

What it proves:

• You understand that inference is part of robotics AI.
• You can measure latency, memory, and runtime behavior.
• You can connect models to robot software rather than only notebooks.
• You can design fallbacks for invalid or low-confidence outputs.

Evidence to include:

• Runtime architecture diagram.
• Latency measurement.
• Resource usage.
• Failure handling behavior.
• ROS 2 or equivalent integration notes.
• Video demo and log replay.

Robotics AI jobs use many titles. Use these titles and keywords when building the jobs taxonomy.

Direct titles

• Robotics AI Engineer
• Robot Learning Engineer
• Embodied AI Engineer
• AI Engineer, Robotics
• AI Research Engineer, Robotics
• Machine Learning Engineer, Robotics
• Robotics Machine Learning Engineer
• Reinforcement Learning Engineer, Robotics
• Imitation Learning Engineer
• Policy Engineer, Robotics
• Vision-Language-Action Engineer
• Robotics Foundation Model Engineer
• Humanoid AI Engineer
• Humanoid Robot Learning Engineer

Specialist titles

• Reinforcement Learning Engineer, Whole-Body Control
• Reinforcement Learning Engineer, Manipulation
• Learned Locomotion Engineer
• Learned Manipulation Engineer
• Perception Learning Engineer
• World Model Engineer, Robotics
• Video Pretraining Engineer, Robotics
• Multimodal Modeling Engineer, Robotics
• Generative AI Engineer, Robotics
• Robot Behavior Learning Engineer
• Sim-to-Real Learning Engineer
• Robot Policy Evaluation Engineer
• Robot Learning Data Engineer
• AI Training Infrastructure Engineer, Robotics
• AI Inference Engineer, Robotics

Adjacent titles

• Autonomy Engineer
• Autonomy Software Engineer
• Applied Scientist, Robotics
• Research Scientist, Robot Learning
• Machine Learning Research Scientist, Robotics
• AI Infrastructure Engineer
• Data Platform Engineer, Robotics
• Teleoperation Learning Engineer
• Simulation Learning Engineer
• Motion Learning Engineer
• Robotics Systems Engineer, AI

Search keywords

Use these as job-board filters:

• robotics AI
• embodied AI
• robot learning
• humanoid AI
• reinforcement learning robotics
• imitation learning robotics
• behavior cloning
• vision-language-action
• VLA robotics
• robot policy
• manipulation policy
• locomotion policy
• whole-body control RL
• sim-to-real
• robot foundation model
• multimodal robotics
• robot data
• teleoperation data
• diffusion policy
• world model robotics
• AI inference robotics
• AI training infrastructure robotics

Job openings change quickly. Treat this as a live company map, not a permanent list. These are strong examples to seed the Companies and Jobs sections.

Figure

Figure hires across Helix AI, robot learning, perception, modeling, generative AI, pretraining, video pretraining, reinforcement learning, training infrastructure, data infrastructure, and humanoid whole-body-control-related AI.

Why it matters for this role: Figure is a strong example of the robotics AI role family because its listings show the split between model areas: robot learning, multimodal modeling, video pretraining, generative AI, perception, reinforcement learning, and AI infrastructure. This is useful for candidates because it shows that robotics AI is not one job; it includes model research, data, deployment, training systems, and real robot behavior.

Useful internal links to create:

• /careers/companies/figure
• /careers/jobs?company=figure&role_family=robotics-ai
• /careers/role-atlas/manipulation-engineer
• /careers/role-atlas/perception-engineer
• /careers/role-atlas/data-teleoperation-engineer
• /careers/role-atlas/simulation-engineer

Tesla Optimus

Tesla Optimus hires AI engineers for manipulation, policy learning, reinforcement learning, vision and foundation models, AI infrastructure, inference, distributed training, and robot autonomy.

Why it matters for this role: Tesla's Optimus listings are useful examples of robotics AI moving toward production-scale training and deployment. Candidates can see the difference between policy roles, foundation-model roles, RL roles, and infrastructure roles.

Useful internal links to create:

• /careers/companies/tesla-optimus
• /careers/role-atlas/robotics-ai-engineer
• /careers/role-atlas/manipulation-engineer
• /careers/role-atlas/locomotion-engineer
• /careers/role-atlas/simulation-engineer

Apptronik

Apptronik hires for reinforcement learning, perception learning, human motion data, autonomy software, data platforms, simulation, controls, and robot platform roles around Apollo.

Why it matters for this role: Apptronik is useful for showing how robotics AI connects to real robot productization. Its role signals cover reinforcement learning for humanoid locomotion and manipulation, human motion data for whole-body reinforcement learning, learning-based perception, and learning-driven mission-level autonomy.

Useful internal links to create:

• /careers/companies/apptronik
• /careers/role-atlas/locomotion-engineer
• /careers/role-atlas/manipulation-engineer
• /careers/role-atlas/perception-engineer
• /careers/role-atlas/data-teleoperation-engineer

1X Technologies

1X hires across artificial intelligence, world models, simulation, data, robot operations, software, hardware, safety, and manufacturing depending on hiring cycle.

Why it matters for this role: 1X is a useful example for candidates interested in home-oriented humanoids, robot foundation models, reinforcement learning, simulation, data, fleet operations, and robot safety.

Useful internal links to create:

• /careers/companies/1x-technologies
• /careers/role-atlas/simulation-engineer
• /careers/role-atlas/data-teleoperation-engineer
• /careers/role-atlas/robot-operations-fleet-operator
• /careers/role-atlas/robotics-safety-engineer

Sanctuary AI

Sanctuary AI positions itself around Physical AI and hires AI/ML research scientists, data scientists, software engineers, simulation experts, mechanical engineers, and controls engineers.

Why it matters for this role: Sanctuary is useful for candidates interested in dexterity-driven physical AI, humanoid manipulation, ML research, simulation, and production-oriented robotics intelligence.

Useful internal links to create:

• /careers/companies/sanctuary-ai
• /careers/role-atlas/manipulation-engineer
• /careers/role-atlas/data-teleoperation-engineer
• /careers/role-atlas/simulation-engineer

NEURA Robotics

NEURA Robotics hires across AI, humanoid robotics, reinforcement learning, behavior cloning, AI manipulation, robot foundation models, perception, software, hardware, and product roles.

Why it matters for this role: NEURA is useful for candidates because its AI roles explicitly connect cognitive robot capabilities, object recognition, language processing, decision-making, reinforcement learning, behavior cloning, and manipulation.

Useful internal links to create:

• /careers/companies/neura-robotics
• /careers/role-atlas/manipulation-engineer
• /careers/role-atlas/perception-engineer
• /careers/role-atlas/robotics-software-engineer

Agility Robotics

Agility Robotics hires engineers, AI researchers, manufacturing experts, and production robotics teams around Digit and humanoid automation.

Why it matters for this role: Agility is useful for candidates interested in production robots for industrial environments. Its AI work connects perception, skills, learning from demonstration, and deployment-focused robot behavior.

Useful internal links to create:

• /careers/companies/agility-robotics
• /careers/role-atlas/perception-engineer
• /careers/role-atlas/field-robotics-engineer
• /careers/role-atlas/robot-operations-fleet-operator

Boston Dynamics

Boston Dynamics hires across Atlas, robot controls, applications, software, testing, systems, teleoperation, and advanced robotics roles.

Why it matters for this role: Boston Dynamics is useful for candidates because Atlas work shows how AI-driven behaviors, whole-body control, teleoperation, and industrial task performance connect to hard robotics engineering.

Useful internal links to create:

• /careers/companies/boston-dynamics
• /careers/role-atlas/locomotion-engineer
• /careers/role-atlas/controls-engineer
• /careers/role-atlas/data-teleoperation-engineer
• /careers/role-atlas/robot-test-validation-engineer

A candidate becomes credible for robotics AI roles when they can show evidence that they understand both model behavior and robot behavior.

Strong positive signals

• Can explain a robot learning pipeline from data collection to model training to evaluation to deployment.
• Has trained and evaluated a policy, not only a classifier.
• Understands the difference between offline model metrics and real robot task success.
• Can discuss action spaces and why they matter.
• Can explain how imitation learning, reinforcement learning, and classical robot control can fit together.
• Has used simulation carefully and can describe sim-to-real risks.
• Can diagnose failure cases using videos, logs, trajectories, and robot state.
• Understands teleoperation data quality and demonstration coverage.
• Can build reproducible experiments with clear baselines and ablations.
• Has evidence of deployment thinking: latency, memory, target hardware, fallbacks, monitoring, and rollout gates.
• Can collaborate with perception, controls, manipulation, simulation, data, and platform teams.
• Is honest about uncertainty, model limits, and safety constraints.

Weak signals

• Only talks about LLMs and ignores robot state, action spaces, controls, contact, and deployment.
• Shows notebooks but no robot or simulation runtime integration.
• Reports a single success video without failure cases or evaluation metrics.
• Cannot explain the dataset used to train the model.
• Cannot explain what the model observes and what it outputs.
• Treats reward design as an afterthought.
• Does not understand coordinate frames, kinematics, or basic robot motion constraints.
• Cannot discuss latency or real-time deployment issues.
• Overclaims autonomy when the demo is mostly scripted or teleoperated.
• Uses simulation results without discussing transfer risks.
• Has no plan for safe fallback behavior when the policy is uncertain or wrong.

Interview questions to prepare for

• Walk me through a robot learning system you built or studied.
• What data did the policy train on, and how did you check data quality?
• What are the observations and actions in your policy?
• How would you evaluate whether a humanoid manipulation policy is improving?
• How would you debug a policy that works in simulation but fails on hardware?
• How would you design a reward for a contact-rich manipulation or locomotion task?
• What failure cases would you expect from imitation learning?
• How would you use teleoperation data to train a robot policy?
• How do you avoid overfitting to a narrow set of objects, camera views, or task setups?
• How would you deploy a learned policy safely to a real robot?
• What should happen if the model output is stale, low-confidence, or outside safe limits?
• How would you compare a classical planner, an imitation policy, and an RL policy for the same task?
• What metrics matter beyond average success rate?
• How would you build a model evaluation dashboard for robot fleet data?
• Tell me about a model failure that surprised you and how you investigated it.

• Treating robotics AI as normal ML with cooler data. Robot data is temporal, physical, noisy, safety-constrained, and tied to hardware state.
• Ignoring action spaces. What the model outputs determines what it can learn, how it fails, and how it interfaces with controls.
• Only reading papers. Papers help, but hiring teams need evidence that you can build, evaluate, debug, and deploy.
• Only building LLM demos. Language can be useful, but humanoid robotics also needs vision, proprioception, contact, motion, control, and safety.
• Reporting only successful videos. Include failures. Failure analysis is a hiring signal.
• Skipping robotics foundations. You need coordinate frames, kinematics, dynamics intuition, sensors, and controls interfaces.
• Ignoring data quality. Bad teleoperation data, poor synchronization, missing failure cases, and narrow task coverage can ruin a model.
• Confusing simulation success with robot readiness. Simulation is useful, but sim-to-real transfer is a separate engineering problem.
• Forgetting deployment constraints. Latency, memory, GPU budget, power, thermal limits, and runtime integration matter.
• Overclaiming autonomy. Be clear about what is learned, scripted, teleoperated, supervised, or manually reset.
• Neglecting safety. Learned policies need guardrails, watchdogs, fallback states, intervention handling, and human-aware rollout rules.

This section is optional on Role Atlas pages, but useful for readers who are ready to act.

First 30 days: build the bridge from ML to robots

• Learn coordinate frames, kinematics, robot state, actions, and basic control interfaces.
• Run a simple simulated robot task in MuJoCo, Isaac Lab, Gazebo, or another simulator.
• Review one imitation learning method and one reinforcement learning method.
• Learn how robot datasets store observations, actions, rewards, metadata, and timing.
• Rebuild a small training loop with reproducible configs, logs, and evaluation.

Output: a small simulated robot task with a documented observation space, action space, baseline policy, and evaluation script.

Days 31–60: train a policy and evaluate it honestly

• Collect or use demonstrations for a simple task.
• Train an imitation learning policy or RL policy.
• Add task variations instead of testing only one setup.
• Create a failure taxonomy.
• Record videos of successes and failures.
• Compare at least two model versions.
• Document what changed and what regressed.

Output: a policy project with metrics, videos, failure analysis, and a README that clearly says what is learned, scripted, simulated, or real.

Days 61–90: make it look hireable

• Add a robot-like runtime interface using ROS 2 or a comparable system.
• Add log replay or rollout analysis.
• Measure inference latency and resource use.
• Add a simple deployment gate: the model only runs if observations are valid and action outputs stay within limits.
• Build a dashboard or report comparing model versions.
• Map your project to real job descriptions.

Output: a portfolio-ready robotics AI project that includes data, training, evaluation, runtime integration, failure cases, and deployment constraints.

Is robotics AI the same as embodied AI?

They overlap. Embodied AI is the broader field of AI systems that perceive, reason, and act through a body in an environment. Robotics AI Engineer is the practical job role focused on building those systems for robots, including data, models, evaluation, deployment, and real-world behavior.

Is this mostly reinforcement learning?

No. Reinforcement learning is important, especially for locomotion, manipulation, and simulated policy training. But robotics AI also includes imitation learning, behavior cloning, diffusion policies, world models, video pretraining, multimodal models, perception learning, data pipelines, and deployment evaluation.

Do I need a PhD?

For research scientist roles, often yes or strongly preferred. For robotics AI engineering roles, not always. Strong project evidence, production ML experience, robotics systems knowledge, and credible evaluation work can matter a lot. Be realistic: many top robot learning roles are competitive and expect deep ML or robotics experience.

Can a normal ML engineer move into robotics AI?

Yes, but not by only rebranding normal ML work. You need to learn robot state, action spaces, simulation, kinematics, teleoperation data, controls interfaces, safety limits, and robot evaluation. Your portfolio should show a robot policy or robot-learning pipeline, not only image classification or LLM prompts.

Should I start with imitation learning or reinforcement learning?

For many learners, imitation learning is the cleaner first step because it forces you to understand demonstrations, observations, actions, and evaluation. Reinforcement learning is powerful but can become confusing if the simulator, reward, resets, and action space are poorly designed. A strong portfolio can include both.

Are vision-language-action models required?

Not for every role. VLA models are increasingly relevant for humanoid robotics because they connect visual input, language instructions, and robot actions. But many robotics AI jobs still focus on narrower policies, perception learning, RL, data pipelines, model evaluation, or inference infrastructure.

What is the fastest credible project?

A small imitation learning policy in simulation with clean data documentation, evaluation across task variations, failure videos, and a runtime integration is more credible than a flashy AI demo with no robot action interface or failure analysis.

How is this different from Perception Engineer?

Perception engineers focus on understanding the world from sensors. Robotics AI engineers focus on learning systems that use perception, robot state, language, and data to choose or improve actions. The boundary is blurry in some companies, but the action and learning loop is the key difference.

How is this different from Robotics Software Engineer?

Robotics software engineers build the reliable robot software system. Robotics AI engineers build and evaluate the learned model or policy. In strong candidates, the two skill sets overlap, but the role focus is different.