Locomotion Engineer

• Legs: gait generation, foot placement, balance, contact handling, push recovery, stepping, turning, squatting, kneeling, and fall prevention.
• Brain: high-level motion commands, learned policies, task-conditioned movement, recovery decisions, behavior interfaces.
• Body: whole-body dynamics, torso posture, center-of-mass control, load carrying, reaching while walking, mass distribution, joint limits.
• Simulation layer: physics simulation, reinforcement learning, domain randomization, controller validation, sim-to-real testing.
• Factory and test layer: harness testing, fall analysis, reliability metrics, actuator thermal limits, endurance tests, safety gates.

A locomotion engineer develops the control, planning, learning, testing, and debugging systems that let a humanoid robot move through the world on legs.

In a humanoid company, the work often includes:

• Building controllers for standing, walking, turning, stopping, stepping, recovering from pushes, and transitioning between motions.
• Designing gait strategies: step timing, swing-leg trajectories, foot placement, stance phases, contact transitions, and terrain adaptation.
• Working with floating-base robot dynamics, where the robot is not bolted to the ground and can fall if the motion is wrong.
• Developing whole-body control systems that coordinate legs, torso, arms, head, and hands without violating contact, torque, joint, balance, or safety constraints.
• Using model-based methods such as inverse dynamics, impedance control, model predictive control, trajectory optimization, centroidal dynamics, and quadratic programming.
• Using learning-based methods such as reinforcement learning, imitation learning, policy distillation, motion retargeting, curriculum learning, and domain randomization.
• Training locomotion policies in simulation and validating whether they survive on hardware.
• Tuning controllers against real robot data: IMU drift, encoder noise, actuator lag, belt elasticity, foot slip, impact forces, thermal limits, and communication latency.
• Building metrics for walking speed, energy use, foot scuffing, slip rate, recovery time, fall rate, step accuracy, terrain success rate, and hardware stress.
• Working with mechanical engineers on leg geometry, foot design, mass distribution, compliance, joint limits, cable routing, and impact loads.
• Working with actuator and electrical engineers on torque limits, current limits, thermal constraints, sensor sampling, motor control, and power draw.
• Working with safety and test engineers to create safe test plans, harness protocols, emergency stop behavior, and regression tests.

The job is cross-functional by default. A locomotion engineer may sit on a controls team, an AI team, a robot learning team, a simulation team, or a robot hardware team. The title changes, but the core responsibility stays the same: make physical motion work.

What the work feels like day to day

A normal week might include:

• Watching a replay of a robot fall and identifying whether the root cause was foot slip, bad state estimation, actuator saturation, delayed contact detection, or a policy failure.
• Running hundreds or thousands of simulated walking tests across randomized floor friction, slopes, payloads, pushes, and sensor noise.
• Tuning a swing-foot trajectory because the robot occasionally scuffs its toe during fast walking.
• Adding a recovery behavior that takes a stabilizing step after a shove.
• Comparing a model-predictive controller with a reinforcement-learning policy on the same benchmark.
• Meeting with the mechanical team to discuss whether ankle torque limits or foot geometry are limiting balance recovery.
• Reviewing logs from a hardware test where the robot walked for twenty minutes but overheated one actuator.
• Updating safety limits so a new controller cannot command motions outside validated torque, speed, or joint ranges.
• Writing a short analysis explaining why a controller works in simulation but fails on hardware.

The best locomotion engineers are not only math-heavy researchers. They are practical system builders who can move between equations, code, simulation, logs, and hardware.

Humanoid robots need legs because they are supposed to operate in spaces built for people: factories, warehouses, retail back rooms, homes, stairways, narrow aisles, ramps, doorways, and cluttered work cells. But legs are also one of the hardest parts of the robot to make reliable.

Locomotion matters because humanoids need:

1. Balance before usefulness
   A robot cannot manipulate, carry, inspect, clean, pick, pack, or help if it cannot remain upright. Locomotion is the foundation for nearly every mobile humanoid task.

2. Whole-body coordination
   A humanoid does not only walk with its legs. Arm motion changes balance. Carrying a box shifts the center of mass. Reaching while walking changes contact forces. A useful humanoid must coordinate the full body, not treat walking and manipulation as separate demos.

3. Reliable contact handling
   Walking is a sequence of contacts being made and broken. Foot slip, soft floors, uneven surfaces, impacts, and timing errors can break a controller that looked good in simulation.

4. Safe failure recovery
   A fall can damage the robot, the environment, or people nearby. Locomotion engineers help build recovery strategies, fall detection, controlled shutdown behavior, safety limits, and test gates.

5. Sim-to-real discipline
   Modern humanoid companies train and test locomotion in simulation, but a simulation win is not the same as hardware success. Locomotion engineers help close the gap between simulated physics and real motors, contacts, sensors, and delays.

6. Deployment readiness
   Walking once in a lab is not the same as walking reliably for hours in a customer environment. The industry needs engineers who can turn impressive motion into repeatable, measurable, testable capability.

A simple rule: locomotion is mature enough for amazing demos, but not mature enough to ignore reliability. That is why this role matters.

This role is a strong fit for people who like math, physics, code, simulation, and real hardware. It is less forgiving than some robotics roles because the robot can literally fall over when the work is wrong.

Controls engineers

You already have useful skills: feedback control, modeling, stability, dynamics, state-space systems, tuning, and maybe model predictive control.

You are probably missing: floating-base dynamics, hybrid contact systems, legged robot state estimation, simulation workflows, humanoid hardware constraints, and learned policy deployment.

Best entry angle: humanoid controls engineer, whole-body control engineer, motion control engineer, gait control engineer, or robot dynamics engineer.

Robotics students and graduates

You may already understand ROS, kinematics, control, simulation, and basic motion planning.

You are probably missing: production-quality controller implementation, rigorous testing, real robot debugging, hardware safety protocols, and experience with large humanoid models.

Best entry angle: junior controls engineer, locomotion research engineer, simulation-to-real engineer, robot test engineer supporting locomotion, or robotics software engineer on a motion team.

AI/ML engineers moving into robot learning

You already understand training, evaluation, neural networks, reinforcement learning concepts, datasets, and Python tooling.

You are probably missing: rigid-body dynamics, contacts, actuators, torque limits, state estimation, control theory, safety constraints, and the brutal difference between simulated reward and real hardware success.

Best entry angle: reinforcement learning engineer for whole-body control, robot learning engineer, locomotion policy engineer, imitation learning engineer, or training infrastructure engineer for legged robots.

Mechanical engineers moving toward robot behavior

You already understand mechanisms, mass properties, joints, materials, loads, tolerances, and failure modes.

You are probably missing: real-time control software, simulation pipelines, locomotion algorithms, optimization, reinforcement learning, and control-system debugging.

Best entry angle: lower-body mechanical engineer, actuator integration engineer, dynamic systems engineer, robot test engineer, or controls-adjacent mechanical engineer.

Simulation and game-engine engineers

You already understand physics engines, 3D scenes, runtime performance, assets, animation, and environment generation.

You are probably missing: control loops, floating-base dynamics, real sensor noise, actuator models, contact modeling, validation metrics, and sim-to-real failure modes.

Best entry angle: locomotion simulation engineer, robot training environment engineer, sim-to-real test engineer, synthetic motion data engineer, or simulation infrastructure engineer for whole-body control.

Embedded and firmware engineers

You already understand timing, real-time constraints, hardware interfaces, motor-control basics, sensors, and reliability.

You are probably missing: high-level legged locomotion algorithms, robot dynamics, policy training, whole-body coordination, and simulation-based validation.

Best entry angle: actuator control engineer, real-time robot control engineer, embedded systems engineer on lower-body hardware, or hardware-in-the-loop engineer for locomotion.

Think of locomotion in layers. Do not try to learn every paper, simulator, and control method at once. First understand the physical problem, then learn the controller families, then build evidence.

Math and physics foundations

These are the base layer.

• Linear algebra: vectors, matrices, rotations, transforms, eigenvalues, least squares.
• Calculus and differential equations: continuous and discrete-time systems.
• Rigid-body mechanics: mass, inertia, angular momentum, center of mass, contact forces.
• Multibody dynamics: forward dynamics, inverse dynamics, Jacobians, constraints.
• Optimization: constrained optimization, quadratic programming, nonlinear optimization.
• Probability basics: noise, uncertainty, filtering, sensor fusion.
• Numerical methods: integration, stability, discretization, solver behavior.

Control foundations

These separate locomotion engineering from pure animation or pure machine learning.

• PID control and gain tuning.
• State-space control.
• Stability and robustness at a practical level.
• Impedance and admittance control.
• Inverse kinematics and inverse dynamics.
• Trajectory tracking.
• Model predictive control.
• Whole-body control using constrained optimization.
• Safety-limited control: joint, torque, speed, contact, and fall limits.

Legged locomotion concepts

These are the core concepts for humanoids and other legged robots.

• Floating-base dynamics.
• Support polygons and balance margins.
• Center of mass, center of pressure, zero moment point, and capture point.
• Centroidal dynamics.
• Linear inverted pendulum models and single rigid body dynamics.
• Step timing, gait phases, stance, swing, double support, and contact transitions.
• Footstep planning and swing-foot trajectories.
• Push recovery and disturbance rejection.
• Terrain adaptation: slopes, friction, steps, mats, cables, gaps, and uneven surfaces.
• Fall detection, fall prevention, and safe fallback behavior.

Whole-body control skills

These become important when walking and manipulation are coupled.

• Coordinating legs, torso, arms, head, and payloads.
• Task-space control for hands, torso, pelvis, and feet.
• Prioritized tasks and constraint handling.
• Contact constraints and friction cones.
• Torque limits and joint limits.
• Kinematic and dynamic feasibility.
• Balancing while reaching, lifting, pushing, or carrying.
• Designing interfaces between high-level planners and low-level controllers.

Learning-based locomotion skills

These are increasingly important, but they do not replace physics knowledge.

• Reinforcement learning basics: policy, value function, reward, rollout, exploration, on-policy vs off-policy.
• Common algorithms: PPO, SAC, behavior cloning, imitation learning, policy distillation.
• Reward shaping for locomotion.
• Curriculum learning.
• Domain randomization.
• Sim-to-real transfer.
• Motion retargeting from human motion capture or teleoperation.
• Policy evaluation and safety gating before hardware deployment.
• Understanding when a learned policy is robust and when it is only exploiting the simulator.

Software and systems skills

Locomotion engineers still need to ship code.

• C++ for real-time or performance-sensitive control code.
• Python for prototyping, simulation, training, data analysis, and automation.
• Linux, Git, CMake, colcon, Bazel, Docker, and CI workflows.
• ROS 2 or equivalent robot middleware.
• Real-time programming constraints: latency, jitter, allocation, scheduling, thread safety.
• Logging, replay, visualization, and metrics dashboards.
• Test automation for simulation, hardware-in-the-loop, and real robot trials.

Hardware awareness

A locomotion controller is only as good as the hardware it commands.

• Electric actuators, transmissions, backlash, compliance, friction, and saturation.
• Encoders, IMUs, force sensors, current sensing, foot contact sensing, and calibration.
• Motor current, torque limits, thermal limits, battery voltage sag, and power draw.
• Foot design, traction, compliance, toe clearance, and impact forces.
• Mechanical limits: joint range, cable routing, fatigue, bearing loads, and structural flex.
• Safety systems: emergency stop, harnesses, watchdogs, fault states, and controlled shutdown.

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

Languages

• C++: real-time control loops, robot runtime code, dynamics libraries, simulation integration, performance-sensitive software.
• Python: research prototypes, RL training, data analysis, simulation scripts, plotting, automation, log processing.
• MATLAB / Simulink: still common in controls education, modeling, and some industrial workflows.
• Julia: sometimes used in optimization-heavy research, though less common in production robotics teams.

Robot middleware and control runtime

• ROS 2: common open-source middleware for robot software, useful for messages, transforms, launch files, logs, and tools.
• ros2_control: framework for real-time robot control in ROS 2 and hardware-interface abstractions.
• Custom middleware: many humanoid companies use internal real-time stacks, but ROS 2 concepts still transfer.
• Real-time Linux / PREEMPT_RT: useful background for control loops and low-latency systems.
• LCM / ZeroMQ / DDS: message passing technologies that may appear in robotics stacks.

Dynamics and control libraries

• Pinocchio: fast rigid-body dynamics, kinematics, derivatives, and contact-related computations.
• Drake: modeling, simulation, multibody dynamics, trajectory optimization, and control.
• Crocoddyl: optimal control for contact-rich robot control and trajectory optimization.
• RBDL / KDL: rigid-body dynamics and kinematics libraries.
• Eigen: C++ linear algebra library heavily used in robotics.
• CasADi, OSQP, qpOASES, HPIPM: optimization and QP solver ecosystem used in control and MPC workflows.

Simulation and robot learning

• MuJoCo: physics simulation used heavily in robotics, control, biomechanics, and machine learning research.
• NVIDIA Isaac Sim / Isaac Lab: simulation, robot learning, reinforcement learning workflows, synthetic data, and high-throughput training.
• Gazebo: open-source robot simulation with ROS integration.
• PyBullet: useful for quick experiments and education, less common for production-grade humanoid locomotion.
• Unity / Unreal Engine: useful for visualization, teleoperation, human motion data, synthetic scenes, and some simulation workflows.
• PyTorch / JAX: common frameworks for training learned locomotion policies.

Data, logging, and debugging

• rosbag / MCAP: robot data recording and replay.
• Foxglove: robotics log visualization and debugging.
• RViz: ROS visualization.
• PlotJuggler: time-series analysis for robotics and control data.
• Grafana / Prometheus: monitoring dashboards for simulation infrastructure, test rigs, and fleet health.
• GDB, perf, Valgrind, sanitizers: debugging and performance tools.

Test and deployment

• Simulation-in-the-loop tests.
• Hardware-in-the-loop rigs.
• Actuator dynamometers and leg test stands.
• Harnessed walking tests.
• Fall mats and safety cages.
• Automated regression benchmarks.
• CI/CD pipelines for controller validation.
• Release gates for hardware deployment.

A good locomotion portfolio should show that you understand dynamics, contacts, control, simulation, and failure analysis. A flashy walking video is useful, but it is not enough. Hiring teams need to see how you measure, debug, and improve motion.

Project 1: Biped balance and walking controller in simulation

Build: a simulated biped, simplified humanoid, or legged robot that can stand, shift weight, take steps, and recover from small disturbances.

You can use MuJoCo, Isaac Lab, Gazebo, Drake, or another simulator. The controller can be model-based, learning-based, or hybrid, but the README should explain what is scripted, what is optimized, what is learned, and what assumptions are being made.

What it proves:

• You understand balance, contact, and gait phases.
• You can structure a locomotion controller rather than only run a demo script.
• You can connect physical concepts to code.
• You know how to evaluate motion with metrics.

Evidence to include:

• GitHub repo with clear setup instructions.
• Short video of standing, stepping, and disturbance recovery.
• Diagram showing robot model, control loop, observations, actions, and constraints.
• Metrics: walking speed, fall rate, tracking error, foot slip, energy use, and recovery time.
• Notes on limitations and sim-to-real assumptions.

Project 2: Push recovery benchmark

Build: a benchmark that applies random pushes to a simulated biped or humanoid model and measures whether the robot recovers.

The benchmark should vary push direction, magnitude, timing, floor friction, and initial gait phase. The goal is not to create a perfect controller. The goal is to show that you can test locomotion like an engineer.

What it proves:

• You understand robustness, not just nominal walking.
• You can design repeatable tests for unstable systems.
• You can analyze failures quantitatively.
• You understand why humanoid safety depends on recovery behavior.

Evidence to include:

• Test harness code.
• Pass/fail summary table.
• Plots of center of mass, foot placement, torso angle, and recovery time.
• Examples of successful and failed recovery.
• A short write-up explaining what controller changes improved recovery.

Project 3: Learned locomotion policy with sim-to-real awareness

Build: a reinforcement-learning locomotion policy in simulation for a humanoid, biped, or quadruped model.

Use Isaac Lab, MuJoCo, or another simulator. Include domain randomization, noisy observations, action limits, curriculum learning, or perturbation training. You do not need a real humanoid robot. You do need to explain how you would validate the policy before hardware deployment.

What it proves:

• You understand modern robot learning workflows.
• You can train, evaluate, and compare policies.
• You understand that simulated reward is not the same as real-world reliability.
• You can reason about observations, actions, reward terms, and safety limits.

Evidence to include:

• Training configuration.
• Reward breakdown.
• Evaluation videos across varied conditions.
• Robustness metrics.
• Explanation of domain randomization choices.
• Hardware deployment checklist, even if no hardware was used.

Project 4: Whole-body control mini project

Build: a simplified whole-body controller that tracks torso, foot, and hand or end-effector targets while respecting joint, torque, and contact constraints.

This can use a simplified humanoid model. The important part is to show task prioritization and contact-aware control, not photorealistic simulation.

What it proves:

• You understand how walking and manipulation interact.
• You can formulate control tasks and constraints.
• You can use dynamics and optimization libraries.
• You can explain feasibility, failure modes, and trade-offs.

Evidence to include:

• Controller formulation.
• Task hierarchy or QP diagram.
• Plots of tracking error, contact forces, and constraint violations.
• Video showing a reach or torso motion while maintaining balance.
• Notes on what would need to change for a real robot.

Project 5: Locomotion log analysis tool

Build: a tool that reads walking logs and flags likely locomotion problems: foot slip, toe scuffing, late contact, high impact, torso oscillation, actuator saturation, delayed state estimation, or fall precursors.

You can use public simulation logs, your own simulated data, or logs generated from your project. The point is to show that you know how locomotion fails and how engineers debug it.

What it proves:

• You understand robot data and time-series debugging.
• You can build tools that make test sessions more useful.
• You can turn vague “the robot walked badly” feedback into measurable signals.

Evidence to include:

• CLI or simple dashboard.
• Example log files.
• Screenshots of plots.
• Anomaly rules.
• Before/after example showing how the tool helps diagnose a controller issue.

Project 6: Single-leg or actuator test rig

Build: a small physical test rig with a motor, encoder, spring, force sensor, IMU, or low-cost leg mechanism. Implement position, velocity, torque-like, or impedance control and measure response.

This project does not need expensive humanoid hardware. It exists to show that you have touched real signals, delays, saturation, friction, and safety limits.

What it proves:

• You understand that hardware is not simulation.
• You can safely test a physical system.
• You can measure actuator response, latency, and control behavior.
• You can document limits and failure modes.

Evidence to include:

• Wiring and safety diagram.
• Controller code.
• Step response or tracking plots.
• Video of the rig.
• Notes on calibration, noise, saturation, and safety.

Locomotion roles rarely use one exact title. Use these titles and keywords when building the jobs taxonomy.

Direct titles

• Locomotion Engineer
• Legged Locomotion Engineer
• Bipedal Locomotion Engineer
• Humanoid Locomotion Engineer
• Whole-Body Control Engineer
• Humanoid Controls Engineer
• Legged Robotics Engineer
• Motion Control Engineer
• Gait Planning Engineer
• Footstep Planning Engineer
• Robot Dynamics Engineer
• Robotics Controls Engineer, Locomotion

Adjacent titles

• Controls Engineer
• Control Systems Engineer
• Reinforcement Learning Engineer, Whole-Body Control
• Reinforcement Learning Engineer, Policy
• Robot Learning Engineer
• Simulation Engineer, Locomotion
• Sim-to-Real Engineer
• Motion Planning Engineer
• Robotics Software Engineer, Motion
• State Estimation Engineer
• Actuator Controls Engineer
• Robot Test Engineer, Locomotion
• Hardware-in-the-Loop Engineer

Search keywords

Use these as job-board filters:

• locomotion engineer
• humanoid locomotion
• bipedal locomotion
• legged robot control
• whole-body control
• whole body controls
• robot dynamics
• gait planning
• footstep planning
• balance control
• push recovery
• centroidal dynamics
• inverse dynamics
• model predictive control robotics
• MPC legged robots
• reinforcement learning locomotion
• sim-to-real locomotion
• robot learning controls
• torque control
• impedance control
• contact dynamics
• floating-base dynamics

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 for humanoid whole-body control, reinforcement learning, training infrastructure, simulation, data, controls, and deployment roles.

Current examples reviewed on 2026-07-02 included AI Training Infrastructure Engineer – Humanoid Whole Body Control and Reinforcement Learning Engineer – Whole Body Control. These roles are useful signals because they connect locomotion to RL, simulation, physics engines, training infrastructure, policy deployment, dynamics, controls, domain randomization, curriculum learning, reward shaping, and sim-to-real gaps.

Why it matters for this role: Figure's listings show that humanoid locomotion is increasingly tied to training infrastructure and robot learning, not only classical controls.

Useful internal links to create:

• /careers/companies/figure
• /careers/jobs?company=figure&role_family=locomotion-and-whole-body-control
• /careers/role-atlas/controls-engineer
• /careers/role-atlas/robotics-ai-engineer
• /careers/role-atlas/simulation-engineer

Apptronik

Apptronik develops Apollo and hires across humanoid robot learning, controls, simulation, human motion data, mechanical design, actuation, and deployment.

Current examples reviewed on 2026-07-02 included a Senior Reinforcement Learning Engineer role focused on locomotion and manipulation challenges on humanoid hardware, a Software Engineer – Human Motion Data role connecting motion capture, teleoperation, generative motion, kinematics, dynamics, and whole-body RL, and a Senior SimOps Engineer role managing simulation infrastructure for locomotion, manipulation, and synthetic data.

Why it matters for this role: Apptronik is a useful example of how locomotion work now spans physical hardware, RL training, human motion data, motion retargeting, high-throughput simulation, and commercial deployment.

Useful internal links to create:

• /careers/companies/apptronik
• /careers/role-atlas/robotics-ai-engineer
• /careers/role-atlas/simulation-engineer
• /careers/role-atlas/data-teleoperation-engineer
• /careers/role-atlas/actuator-engineer

Tesla Optimus

Tesla hires for Optimus across AI, reinforcement learning, whole-body controls, manipulation, policy learning, embedded software, robot systems, simulation, validation, electrical, mechanical, and manufacturing-adjacent roles.

Current examples reviewed on 2026-07-02 included Reinforcement Learning Engineer, Whole Body Controls, Optimus, Reinforcement Learning Engineer, Policy, Optimus, and Internship, Reinforcement Learning Engineer, Optimus. These are useful signals for candidates interested in learned policies for locomotion, manipulation, and full-body robot behavior.

Why it matters for this role: Optimus roles show that locomotion can be hired under AI and reinforcement-learning titles, not only under traditional controls titles.

Useful internal links to create:

• /careers/companies/tesla-optimus
• /careers/role-atlas/robotics-ai-engineer
• /careers/role-atlas/embedded-systems-engineer
• /careers/role-atlas/robot-test-engineer

Agility Robotics

Agility Robotics builds Digit for industrial humanoid automation and discusses whole-body control as a key part of keeping Digit safe and stable while performing a wide range of tasks.

Agility's whole-body-control writing is useful for readers because it explains why humanoid motion is not only walking: the robot must balance, move smoothly, handle disturbances, and coordinate reaching and manipulation while avoiding falls.

Why it matters for this role: Agility is a strong example for locomotion engineers interested in industrial humanoids where walking, carrying, manipulation, and deployment reliability are tightly connected.

Useful internal links to create:

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

Boston Dynamics

Boston Dynamics is a major reference point for dynamic legged robots and humanoid systems. Job openings change, but the company is relevant for candidates interested in advanced mobility, controls, robot behavior, hardware integration, testing, and real robot systems.

Why it matters for this role: Boston Dynamics helps readers understand the high bar for dynamic motion, physical testing, and practical robotics engineering.

Useful internal links to create:

• /careers/companies/boston-dynamics
• /careers/role-atlas/controls-engineer
• /careers/role-atlas/robot-test-engineer
• /careers/role-atlas/technical-program-manager-robotics

Sanctuary AI

Sanctuary AI hires AI, ML, robotics, simulation, mechanical, and controls talent for physical AI and humanoid systems.

Why it matters for this role: Sanctuary is more manipulation-heavy than locomotion-heavy in public positioning, but it is still relevant for candidates interested in AI-based control systems for humanoid robots.

Useful internal links to create:

• /careers/companies/sanctuary-ai
• /careers/role-atlas/manipulation-engineer
• /careers/role-atlas/robotics-ai-engineer
• /careers/role-atlas/controls-engineer

1X Technologies

1X works on humanoid home robots and hires across AI, simulation, robot learning, data, product, hardware, manufacturing, and robotics roles depending on hiring cycle.

Why it matters for this role: 1X is useful for candidates interested in whole-body behavior, home environments, human-robot interaction, data, and simulation-heavy robot learning.

Useful internal links to create:

• /careers/companies/1x-technologies
• /careers/role-atlas/robotics-ai-engineer
• /careers/role-atlas/simulation-engineer
• /careers/role-atlas/data-teleoperation-engineer

A candidate becomes credible for locomotion roles when they can show evidence in these areas.

Strong positive signals

• Can explain floating-base dynamics and why legged robots are harder than fixed-base arms.
• Understands contact transitions, friction, foot slip, support, center of mass, and balance.
• Has built or modified a locomotion controller in simulation.
• Can compare model-based, learning-based, and hybrid approaches without turning the answer into ideology.
• Understands why sim-to-real transfer is difficult.
• Can read and analyze robot logs from a walking trial.
• Can explain how they would test a controller before putting it on hardware.
• Knows how actuators, latency, torque limits, thermal limits, and sensor noise affect locomotion.
• Can define metrics for locomotion robustness, not just show a video.
• Can describe a failure they debugged and what changed after the analysis.

Weak signals

• Only says “use reinforcement learning” without explaining observations, actions, rewards, safety limits, or sim-to-real validation.
• Only shows animation-like motion with no contact, torque, or feasibility reasoning.
• Cannot explain why a humanoid falls.
• Cannot distinguish footstep planning, whole-body control, state estimation, and low-level motor control.
• Ignores hardware limits.
• Has no testing plan.
• Has no failure analysis.
• Claims walking is solved because a demo looked good.

Interview questions to prepare for

• Why is bipedal locomotion harder than controlling a fixed-base robot arm?
• Walk me through the architecture of a locomotion controller.
• How would you debug a humanoid that falls during a turn?
• What signals would you log during a walking test?
• How would you detect foot slip?
• What is the difference between center of mass, center of pressure, zero moment point, and capture point?
• How would you design a push recovery benchmark?
• What are the trade-offs between model predictive control and reinforcement learning for humanoid walking?
• How would you close a sim-to-real gap for locomotion?
• How do actuator torque limits and thermal constraints affect gait design?
• How would you test a new walking controller before deploying it on hardware?
• How should whole-body control change when the robot is carrying a heavy object?
• What does domain randomization help with, and what does it not solve?
• How do you know whether a learned policy is robust or just overfit to the simulator?

• Treating locomotion as only AI. Learning-based policies are powerful, but locomotion still depends on dynamics, contacts, control, hardware limits, and safety.
• Treating locomotion as only classical controls. Model-based control is important, but modern teams increasingly use RL, imitation learning, policy distillation, and large-scale simulation.
• Ignoring hardware. Motors saturate. Sensors drift. Feet slip. Batteries sag. Joints heat up. Simulation does not capture everything.
• Only showing a walking video. A video helps, but metrics, logs, failure cases, and test coverage make the project credible.
• Skipping state estimation. A controller cannot balance well if the robot does not know its body state and contact state.
• Overclaiming sim-to-real. Be precise about whether your project ran only in simulation, on a toy robot, or on serious hardware.
• Not explaining safety. Locomotion errors can cause falls. Show how you think about emergency stops, harnesses, constraints, and deployment gates.
• Using vague language like “make the robot move naturally.” Hiring teams want specifics: gait, contact, balance, push recovery, torque limits, tracking, terrain, and robustness.

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

First 30 days: build the base

• Review linear algebra, coordinate frames, rotations, Jacobians, and rigid-body dynamics.
• Learn the difference between fixed-base robots and floating-base legged robots.
• Study center of mass, support polygon, zero moment point, capture point, and contact forces.
• Run a simple legged robot model in MuJoCo, Isaac Lab, Gazebo, or Drake.
• Create a small notebook or script that plots center of mass, foot contacts, and torso angle during a walking sequence.

Output: a short technical note and small repo explaining the physics of balance using a simple simulated model.

Days 31–60: build a walking or recovery demo

• Implement or adapt a simple standing, stepping, or walking controller.
• Add randomized pushes or floor friction changes.
• Record logs from successful and failed trials.
• Add metrics: fall rate, recovery time, torso angle, step error, foot slip, and energy use.
• Write down what fails and why.

Output: a simulation project with a controller, repeatable tests, metrics, videos, and failure analysis.

Days 61–90: make it look hireable

• Add a more realistic robot model or a harder benchmark.
• Compare two approaches: for example, model-based vs learned, or default vs randomized training.
• Add CI or repeatable benchmark scripts.
• Add a clean architecture diagram.
• Add a sim-to-real validation checklist.
• Map the project to real job descriptions.

Output: a portfolio project that shows controller design, simulation testing, robustness metrics, and honest limitations.

Is Locomotion Engineer the same as Controls Engineer?

No. Locomotion is a specialist area within controls and robot motion. A controls engineer may work on many systems: actuators, arms, balancing, manufacturing controls, thermal systems, or test rigs. A locomotion engineer focuses specifically on legged movement, balance, gait, contact, and whole-body motion.

Is this role mostly reinforcement learning now?

No. Reinforcement learning is increasingly important, especially for humanoid whole-body control and sim-to-real motion policies. But strong locomotion engineers still need dynamics, controls, contact modeling, state estimation, safety, hardware understanding, and testing discipline.

Do I need a PhD?

For senior research-heavy locomotion roles, a PhD or equivalent research background can help. For engineering-heavy roles, strong evidence can also matter: controller projects, simulation benchmarks, C++/Python code, hardware testing, log analysis, and clear understanding of dynamics and controls.

Can a software engineer move into locomotion?

Yes, but the gap is bigger than moving into general robotics software. You need to learn dynamics, controls, simulation, contacts, and physical testing. A good bridge is to build simulation tooling, log analysis, locomotion benchmarks, or training infrastructure before trying to own controllers.

Can an AI engineer move into locomotion?

Yes, especially through robot learning, reinforcement learning, imitation learning, and training infrastructure. The trap is treating the robot as just another RL environment. You need to understand actuators, contacts, safety limits, sensors, and why policies fail on hardware.

Should I learn MuJoCo or Isaac Lab first?

Either can work. MuJoCo is excellent for fast physics and research-style control experiments. Isaac Lab is useful for high-throughput robot learning workflows and GPU-accelerated simulation. The better choice depends on your target role and project. Do not let tool choice become an excuse to avoid building.

What is the fastest credible portfolio project?

A push-recovery benchmark is one of the fastest credible projects. It forces you to define disturbance tests, metrics, failure cases, and controller improvements. That is much more useful than a walking video with no explanation.

Is locomotion a good first robotics role?

It can be, but it is not the easiest first role. Beginners usually need a strong math, controls, robotics, physics, or ML foundation. If you are starting from general software, consider robotics software, simulation, test, or training infrastructure first, then move toward locomotion.