Manipulation Engineer

• Hands: grasping, dexterity, end-effectors, tactile sensing, in-hand manipulation, bimanual manipulation, force control, and hand-object interaction.
• Brain: task policies, action selection, skill libraries, recovery logic, imitation learning, reinforcement learning, VLA/VLM-conditioned behaviours, and decision-making around manipulation tasks.
• Eyes: object detection, pose estimation, segmentation, tracking, scene understanding, hand-eye calibration, depth sensing, and visual servoing.
• Body: arm motion, torso motion, whole-body reaching, balance during manipulation, joint limits, payload effects, and coordinated upper-body motion.
• Simulation layer: pick-and-place simulation, object assets, contact models, synthetic data, dexterous-hand training, domain randomization, and sim-to-real validation.
• Fleet and deployment layer: task success metrics, manipulation logs, remote intervention, teleoperation data, failure labeling, customer-site task tuning, and regression testing.

A manipulation engineer develops the algorithms, software, models, data systems, and test methods that let a humanoid robot physically interact with objects and tools.

In a humanoid company, the work often includes:

• Building manipulation behaviours such as grasping, pick-and-place, object reorientation, door opening, drawer opening, bimanual handling, part insertion, tool use, sorting, packing, kitting, assembly, and handover.
• Designing pipelines that connect perception to action: detect the object, estimate its pose, choose a grasp or contact strategy, plan a motion, execute it, monitor success, and recover from failure.
• Developing arm and hand motion planning using inverse kinematics, trajectory optimization, collision checking, grasp planning, and constrained motion generation.
• Working on dexterous hands, multi-finger contacts, tactile feedback, force/torque sensing, compliance, slip detection, contact-rich control, and in-hand manipulation.
• Training learning-based manipulation policies using imitation learning, behaviour cloning, reinforcement learning, diffusion policies, visuomotor policies, and sometimes vision-language-action methods.
• Collecting and using data from teleoperation, robot logs, demonstrations, simulation rollouts, human motion capture, tactile sensors, cameras, depth sensors, and task outcomes.
• Building evaluation suites that measure task success rate, grasp stability, cycle time, object damage, recovery rate, generalization, contact quality, safety margin, and sim-to-real transfer.
• Creating simulated manipulation tasks with realistic objects, contact properties, lighting, clutter, occlusion, robot models, and failure cases.
• Working with perception engineers on object pose, segmentation, tracking, depth quality, hand-eye calibration, and scene representation.
• Working with controls engineers on impedance control, force control, trajectory tracking, compliance, torque limits, and contact stability.
• Working with mechanical and actuator teams on hand design, fingertips, tendons, joints, tactile sensors, payload, backlash, thermal limits, and reliability.
• Supporting hardware test sessions where the same task fails for reasons that are not obvious from the software: poor friction, loose calibration, object variation, cable routing, grip strength, actuator heating, or camera occlusion.

The job is cross-functional by default. You may sit on an autonomy team, an AI team, a controls team, a hand hardware team, a robot learning team, or a general robotics software team. The title changes, but the core responsibility stays the same: make the robot physically do useful work with its hands.

What the work feels like day to day

A normal week might include:

• Watching a robot fail to pick an object and deciding whether the root cause is bad perception, bad grasp selection, poor finger contact, wrong compliance, object slip, latency, a policy failure, or a mechanical limitation.
• Training a visuomotor policy on teleoperation demonstrations and then testing whether it survives on the real robot with new objects and new lighting.
• Improving a pick-and-place pipeline so the robot can retry after a failed grasp instead of freezing or dropping into an unsafe state.
• Tuning an impedance controller so the hand can make contact without pushing too hard or losing grip.
• Adding tactile slip detection so the robot knows when an object is moving in the hand.
• Building a simulation benchmark with cluttered bins, varied object shapes, random pose perturbations, and failure labeling.
• Reviewing logs from a field trial where the robot succeeded in the lab but failed at a customer site because the objects were deformable, reflective, or inconsistently stacked.
• Meeting with the hand hardware team to discuss fingertip materials, sensor placement, joint friction, grip force, or actuator limits.
• Comparing a classical grasp planner with a learned policy and explaining which approach is more reliable for the current deployment target.
• Turning messy test failures into clearer metrics and smaller reproducible test cases.

The best manipulation engineers are not only strong in algorithms. They are practical experimenters who can move between code, geometry, learning systems, physical contact, hardware logs, and task-level product requirements.

Humanoid robots are built for environments designed around human bodies. The hands are the main interface between the robot and that world. Walking gets the robot near the work. Manipulation lets the robot actually do the work.

Manipulation matters because humanoids need:

1. Useful physical work
   Most valuable humanoid tasks involve touching, moving, holding, loading, unloading, sorting, pressing, opening, closing, carrying, assembling, inspecting, cleaning, or using tools. A humanoid that cannot manipulate objects is mostly a mobile sensor platform.

2. Generalization beyond one demo
   Real objects vary. Boxes deform. Bags sag. Tools shift. Doors stick. Parts are misaligned. Cables tangle. Customer environments are not clean lab tables. Manipulation engineers build systems that can handle variation rather than only replay a scripted motion.

3. Contact-rich reasoning
   Manipulation is not just motion through free space. The robot must make and break contact, manage friction, detect slip, apply force, avoid damaging objects, and recover when the object does not behave as expected.

4. Perception-to-action integration
   Seeing an object is not enough. The robot needs an action representation that turns perception into a feasible grasp, motion, contact, and task result. Manipulation engineers sit at that interface.

5. Dexterity as a product constraint
   Different tasks need different end-effectors. A simple gripper may work for boxes. A dexterous hand may be needed for tools, doors, soft goods, cables, small parts, or household objects. Manipulation engineering helps decide what the robot can realistically do with the hardware it has.

6. Data for physical AI
   Manipulation creates some of the most valuable robot data: demonstrations, failures, contact events, tactile signals, recovery attempts, and task outcomes. This data becomes the training and evaluation layer for embodied AI.

7. Deployment credibility
   A robot can look impressive when it picks one known object in a polished demo. Real deployment requires repeatable success across many objects, many poses, many operators, many lighting conditions, and many failure modes.

A simple rule: humanoid manipulation is where AI, controls, perception, hardware, and product reality collide. That is why this role is both difficult and valuable.

This role is a good fit for people who like robotics, geometry, learning, physical experimentation, and debugging ambiguous failures. It is usually harder than a beginner role because manipulation failures are often multi-cause. However, a motivated student or software engineer can build credible evidence through arm, gripper, and simulation projects.

Robotics students and graduates

You may already understand ROS, kinematics, motion planning, control, perception, and simulation at a project level.

You are probably missing: real hardware failure experience, contact-rich manipulation, task-level evaluation, data collection, production-quality software, and strong debugging stories.

Best entry angle: junior manipulation engineer, robotics software engineer on a manipulation team, robot learning engineer intern, manipulation simulation engineer, or robot test engineer supporting manipulation.

Controls engineers

You already have useful skills: feedback control, stability, dynamics, tuning, trajectory tracking, impedance control, force control, and systems thinking.

You are probably missing: perception-driven grasping, learned policies, object pose uncertainty, tactile data, high-DOF hand control, task-level autonomy, and large-scale demonstration datasets.

Best entry angle: manipulation controls engineer, dexterous hand controls engineer, force-control engineer, contact-rich motion engineer, or whole-body manipulation engineer.

AI/ML engineers moving into robot learning

You already understand model training, datasets, evaluation, inference, deep learning frameworks, and experiment tracking.

You are probably missing: robot kinematics, transforms, action spaces, contact dynamics, actuation limits, safety constraints, real-time deployment, sensor calibration, and why simulation rewards do not automatically transfer to hardware.

Best entry angle: robot learning engineer for manipulation, imitation learning engineer, visuomotor policy engineer, reinforcement learning engineer, VLA evaluation engineer, or data pipeline engineer for manipulation.

Perception engineers

You already understand cameras, depth, segmentation, pose estimation, tracking, calibration, and visual uncertainty.

You are probably missing: grasp affordances, motion planning constraints, closed-loop control, task execution, tactile feedback, and how small perception errors affect physical success.

Best entry angle: perception-to-manipulation engineer, grasp perception engineer, pose-estimation engineer for manipulation, visual servoing engineer, or scene-understanding engineer for robot action.

Robotics software engineers

You already have useful skills: C++, Python, ROS 2, middleware, debugging, logging, architecture, testing, simulation, and integration.

You are probably missing: grasp planning, inverse kinematics, motion planning, impedance control, contact models, robot learning, and dexterous hand behaviour.

Best entry angle: manipulation software engineer, motion planning engineer, robot behaviors engineer, simulation test engineer for manipulation, or task execution engineer.

Mechanical, actuator, and hand hardware engineers

You already understand mechanisms, joints, tolerances, payloads, friction, materials, sensors, motors, thermal limits, and physical failure modes.

You are probably missing: robot software architecture, manipulation algorithms, policy learning, data pipelines, ROS 2, and task-level evaluation.

Best entry angle: end-effector integration engineer, dexterity hardware integration engineer, tactile sensing engineer, actuator test engineer for hands, or manipulation test engineer.

Data and teleoperation engineers

You already understand data capture, labeling, operator workflows, datasets, quality control, interfaces, and sometimes human motion or VR systems.

You are probably missing: manipulation metrics, kinematics, action representations, policy evaluation, tactile/contact labeling, and robot runtime constraints.

Best entry angle: teleoperation data engineer, manipulation data engineer, demonstration pipeline engineer, robot operator lead for dexterity tasks, or evaluation engineer for robot skills.

Think of manipulation in layers. First learn robot arms and geometry. Then learn grasping and control. Then add perception. Then add learning and dexterity. Do not try to jump straight to “general-purpose robot hands” without understanding the basics.

Robotics foundations

These are the base skills for nearly every manipulation role.

• Coordinate frames and transforms.
• Forward kinematics and inverse kinematics.
• Jacobians and differential motion.
• Joint limits, singularities, redundancy, and null-space behaviour.
• Collision geometry and self-collision checking.
• Trajectory generation and trajectory tracking.
• Basic rigid-body dynamics.
• Contact, friction, compliance, torque, force, and impedance.
• Camera geometry, depth sensing, and hand-eye calibration.
• ROS 2, robot descriptions, launch files, bags, transforms, and visualization.

Motion planning and task execution

These make manipulation systems more than one-off scripts.

• Sampling-based motion planning.
• Optimization-based trajectory planning.
• Collision-aware planning.
• Cartesian path planning.
• Constrained motion planning.
• Grasp pose generation and ranking.
• Pre-grasp, approach, contact, lift, transfer, place, and retreat phases.
• Behavior trees or state machines for manipulation tasks.
• Recovery behaviours: retry, regrasp, reposition, ask for help, or safely abort.
• Task and motion planning at a practical level.

Grasping and dexterity

These are central to the role.

• Parallel-jaw grasping and suction grasping.
• Multi-finger grasping.
• Grasp quality metrics.
• Object affordances and contact points.
• Force closure and grasp stability at a practical level.
• Slip detection and grip adjustment.
• Tactile sensing and proprioception.
• In-hand manipulation.
• Bimanual manipulation.
• Tool use and object reorientation.
• Deformable object handling.
• Contact-rich manipulation and compliance.

Perception for manipulation

Manipulation depends heavily on what the robot can estimate about the scene.

• Object detection and segmentation.
• 6D pose estimation.
• Depth sensing and point clouds.
• Object tracking during motion.
• Scene reconstruction and occupancy representation.
• Hand-object occlusion handling.
• Calibration between cameras, arms, hands, and robot base.
• Visual servoing.
• Perception confidence and uncertainty.
• Failure detection from vision and tactile signals.

Robot learning and embodied AI

These skills matter more as humanoid companies shift toward learned manipulation policies.

• Behaviour cloning and imitation learning.
• Reinforcement learning.
• Offline RL at a conceptual level.
• Diffusion policies and action chunking concepts.
• Visuomotor policy learning.
• Vision-language-action and multimodal policy evaluation.
• Demonstration collection and cleaning.
• Dataset balancing and quality scoring.
• Domain randomization and sim-to-real transfer.
• Policy deployment on real robots.
• Safety wrappers around learned policies.
• Evaluation beyond training reward: task success, recovery, robustness, object diversity, and hardware stress.

Software engineering for manipulation

Good manipulation work needs reliable software, not only research scripts.

• C++ for robot runtime and performance-sensitive systems.
• Python for tooling, data, training, and experiments.
• ROS 2 nodes, topics, services, actions, parameters, launch files, TF, bags, and QoS.
• Clean interfaces between perception, planning, control, and policies.
• Log replay and failure analysis.
• Simulation tests and regression tests.
• Hardware-in-the-loop testing.
• Profiling latency, CPU, GPU, memory, and message bandwidth.
• Experiment tracking and reproducibility.
• CI for robot software where possible.

Humanoid-specific skills

Humanoid manipulation is harder than fixed-arm manipulation because the robot body moves, balances, and shares constraints across the whole system.

• Whole-body reaching.
• Arm-torso coordination.
• Manipulation while standing or stepping.
• Bimanual coordination.
• Payload effects on balance.
• Human-scale workspaces.
• Safe interaction around people.
• Hand and finger limitations.
• Teleoperation-to-policy pipelines.
• Customer-site task adaptation.
• Manipulation skill libraries.
• Failure recovery across perception, hand, arm, torso, and operator layers.

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.

Robot middleware and runtime

• ROS 2: common open-source framework for robot communication, launch, transforms, visualization, and integration.
• MoveIt / MoveIt 2: motion planning, kinematics, manipulation, collision checking, and planning workflows in the ROS ecosystem.
• BehaviorTree.CPP: behaviour trees for task execution and recovery logic.
• Custom robot middleware: many humanoid companies use internal runtime systems, but ROS and MoveIt concepts transfer well.
• DDS, LCM, ZeroMQ: message-passing systems or communication layers used in robotics stacks.

Motion planning, kinematics, and dynamics

• OMPL: sampling-based motion planning, often used through MoveIt.
• Pinocchio: rigid-body kinematics and dynamics.
• Drake: modeling, simulation, planning, optimization, manipulation examples, and robot system analysis.
• KDL / RBDL: kinematics and dynamics libraries.
• cuRobo / NVIDIA cuMotion: GPU-accelerated motion generation and collision-aware planning in NVIDIA robotics workflows.
• IKFast, TRAC-IK, BioIK, or custom IK solvers: depending on robot stack.

Simulation and training

• NVIDIA Isaac Sim: robot simulation, synthetic data, manipulation workflows, and sim-to-real experimentation.
• Isaac Lab: robot learning framework used for control, manipulation, and dexterous manipulation tasks.
• MuJoCo: physics simulation often used for robot learning, contact-rich control, and manipulation research.
• Gazebo: open-source robot simulation with ROS integration.
• PyBullet: useful for quick manipulation experiments and educational projects.
• Unity / Unreal Engine: sometimes used for teleoperation interfaces, data generation, and visual simulation.
• Blender / Houdini / Maya: useful for object assets, collision geometry, and synthetic scenes.

Perception and sensing

• RGB cameras, depth cameras, stereo cameras, fisheye cameras.
• Force/torque sensors.
• Tactile sensors and fingertip sensors.
• Joint encoders, current sensing, torque estimation, and proprioception.
• Calibration tools for intrinsic, extrinsic, hand-eye, and robot-base calibration.
• Point cloud processing libraries.
• Object pose estimation pipelines.
• Visual servoing and tracking tools.

Machine learning and data

• PyTorch: common framework for robot learning and policy training.
• TensorFlow / JAX: used in some research and production stacks.
• Weights & Biases / MLflow: experiment tracking.
• HDF5, Zarr, Parquet, MCAP, rosbag: data storage formats used across robotics data pipelines.
• Labeling tools: for object masks, pose, task outcomes, failure categories, and teleoperation quality.
• Diffusion-policy and imitation-learning codebases: useful research references, but should not replace practical robot integration.

Logging, debugging, and visualization

• RViz: ROS visualization.
• Foxglove: robotics log visualization and analysis.
• MeshCat: visualization often used with Drake and manipulation examples.
• NVIDIA Omniverse tools: visualization and simulation workflows around Isaac.
• GDB, perf, Valgrind, sanitizers: debugging and profiling.
• Grafana / Prometheus / OpenTelemetry: useful for fleet, lab, and test-cell observability.

Hardware and lab tools

• Robot arms such as Franka Panda, UR arms, Kinova, xArm, Interbotix arms, or low-cost educational arms.
• Parallel grippers, suction cups, dexterous hands, tendon-driven hands, and custom end-effectors.
• Force/torque sensors and tactile sensor arrays.
• Motion capture or tracking systems.
• Safety-rated test cells, e-stops, fixtures, object sets, calibration boards, and drop-safe testing procedures.

A manipulation portfolio should show real robot thinking: geometry, perception, action, failure handling, metrics, and repeatability. A flashy video is useful, but it is not enough. Hiring teams need to see how you reason about failure.

Project 1: Perception-driven pick-and-place pipeline

Build: a ROS 2 or MoveIt 2 project where a simulated or real arm detects an object, estimates a pose, plans a reach, grasps the object, moves it to a target location, releases it, and reports success or failure.

Use an affordable arm if you have one. A simulated Franka, UR, xArm, or Interbotix-style arm is acceptable if the project is well explained.

What it proves:

• You understand the basic manipulation pipeline.
• You can connect perception output to robot motion.
• You can manage coordinate frames and calibration assumptions.
• You can structure a task rather than write one giant script.
• You can handle at least one failure case.

Evidence to include:

• GitHub repo with clean README.
• Architecture diagram.
• Video demo.
• TF tree or frame diagram.
• Object detection or pose-estimation explanation.
• Launch instructions.
• Failure cases and recovery logic.
• Task success metrics across multiple trials.

Project 2: Grasp planner and evaluation benchmark

Build: a small benchmark that generates or selects grasps for a set of objects, ranks them, executes them in simulation, and reports success metrics.

You can start with simple objects and a parallel-jaw gripper. Advanced versions can add clutter, occlusion, object variation, friction randomization, and real hardware tests.

What it proves:

• You understand grasp candidates and grasp quality.
• You can evaluate manipulation rather than rely on one demo.
• You can reason about object geometry, contact, and failure.
• You can build a repeatable experiment.

Evidence to include:

• Object set and task setup.
• Grasp generation method.
• Ranking or scoring method.
• Success/failure table.
• Examples of failed grasps and root causes.
• Notes on how simulation differs from hardware.

Project 3: Visual servoing or closed-loop reaching demo

Build: a robot arm or simulated arm that adjusts its motion in response to live visual feedback. The robot should correct for small object shifts instead of assuming the world is static.

This can be done with fiducial markers, RGB-D camera input, or a simple object tracker.

What it proves:

• You understand closed-loop manipulation.
• You can handle sensor noise and latency.
• You can connect perception and control at runtime.
• You know why open-loop motions fail in the real world.

Evidence to include:

• Latency measurement.
• Camera and robot frame diagram.
• Before/after comparison of open-loop vs closed-loop execution.
• Video showing object movement during execution.
• Notes on stability, smoothing, and failure cases.

Project 4: Tactile or force-aware grasping demo

Build: a small gripper or hand demo where tactile, force, current, or torque feedback changes the grip behaviour. For example, detect slip, reduce grip force, stop when contact is detected, or adjust grip based on object stiffness.

This can use low-cost force sensors, motor current estimates, or a simple tactile pad. The point is not expensive hardware. The point is contact-aware behaviour.

What it proves:

• You understand manipulation is about contact, not only position.
• You can work with real sensor noise.
• You can design safety limits around force.
• You can reason about slip, friction, and object damage.

Evidence to include:

• Wiring or hardware diagram.
• Sensor calibration notes.
• Control logic.
• Test objects.
• Plots of force/current/tactile signal during grasp.
• Failure analysis.

Project 5: Imitation learning for a simple manipulation skill

Build: collect demonstrations for a small manipulation task, train a policy, evaluate it on held-out variations, and compare it with a scripted baseline.

The task can be simple: push a cube to a target, place an object in a container, open a mock drawer, align an object, or perform a short pick-and-place sequence.

What it proves:

• You understand demonstration data quality.
• You can train and evaluate a policy.
• You know that robot learning needs baselines and metrics.
• You can discuss where learned policies help and where classical approaches are still better.

Evidence to include:

• Dataset description.
• Policy architecture at a practical level.
• Evaluation protocol.
• Baseline comparison.
• Success rates across variations.
• Failure modes.
• Notes on sim-to-real assumptions if hardware is not used.

Project 6: Manipulation log replay and failure labeling tool

Build: a tool that replays manipulation runs, visualizes key signals, and labels failures such as missed grasp, object slip, bad pose estimate, collision, over-force, timeout, dropped object, or unsafe retry.

What it proves:

• You understand that manipulation progress depends on failure data.
• You can build practical engineering tools.
• You can turn messy robot behaviour into measurable signals.
• You can support a robot team beyond writing algorithms.

Evidence to include:

• Sample logs.
• Timeline view.
• Failure taxonomy.
• Screenshots or short video.
• Explanation of how the tool helps improve policies, planners, or hardware.

Manipulation roles often appear under several names. Use these titles and keywords when building the jobs taxonomy.

Direct titles

• Manipulation Engineer
• Robot Manipulation Engineer
• Robotics Manipulation Engineer
• Dexterous Manipulation Engineer
• AI Engineer, Manipulation
• Robotics Software Engineer, Manipulation
• Manipulation Research Engineer
• Robot Learning Engineer, Manipulation
• Visuomotor Control Engineer
• Grasping Engineer
• Motion Planning Engineer, Manipulation
• Roboticist, Manipulation

Adjacent titles

• Robotics AI Engineer
• Robot Learning Engineer
• Reinforcement Learning Engineer, Robotics
• Imitation Learning Engineer
• Perception-to-Action Engineer
• Perception Engineer, Manipulation
• Tactile Sensing Engineer
• End-Effector Integration Engineer
• Robotic Hand Controls Engineer
• Upper-Body Controls Engineer
• Whole-Body Manipulation Engineer
• Autonomy Software Engineer
• Simulation Engineer, Manipulation
• Teleoperation Software Engineer
• Robotics Software Engineer
• Robot Test Engineer, Manipulation

Search keywords

Use these as job-board filters:

• manipulation engineer
• robot manipulation
• robotic manipulation
• dexterous manipulation
• grasping
• pick and place
• bimanual manipulation
• in-hand manipulation
• visuomotor control
• robot learning manipulation
• imitation learning robotics
• reinforcement learning manipulation
• diffusion policy robotics
• VLA robotics
• tactile sensing
• force control
• impedance control
• motion planning
• MoveIt
• Isaac Sim manipulation
• Isaac Lab dexterous
• MuJoCo manipulation
• hand-eye calibration
• end effector
• humanoid hands
• robotic hands

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 humanoid AI, robot learning, manipulation, data collection, controls, systems integration, deployment, and robot operations. Current examples reviewed on 2026-07-02 included a Helix AI Engineer, Robot Learning role focused on learning-based visuomotor policies for humanoid manipulation, plus hand subsystem and robot operator roles that touch manipulation, actuation, integration, and validation.

Why it matters for this role: Figure's current hiring signals show manipulation as a full pipeline: real robot data, policy training, grasping, pick-and-place, object reorientation, door opening, bimanual manipulation, assembly, robustness to sensor noise, integration with perception and controls, and deployment on physical humanoids.

Useful internal links to create:

• /careers/companies/figure
• /careers/jobs?company=figure&role_family=manipulation-and-dexterity
• /careers/role-atlas/robotics-ai-engineer
• /careers/role-atlas/data-teleoperation-engineer
• /careers/role-atlas/robot-test-validation-engineer

Tesla Optimus

Tesla hires for Optimus across AI, learned manipulation, robotics systems, embedded software, controls, tactile sensing, mechanical design, simulation, validation, and manufacturing.

Why it matters for this role: Tesla's Optimus manipulation roles are useful examples of learned robotic manipulation software being developed for real-world production applications. The search intent around “AI Engineer, Manipulation, Optimus” is strong and should map cleanly into this Role Atlas page.

Useful internal links to create:

• /careers/companies/tesla-optimus
• /careers/jobs?company=tesla-optimus&role_family=manipulation-and-dexterity
• /careers/role-atlas/robotics-ai-engineer
• /careers/role-atlas/perception-engineer
• /careers/role-atlas/mechanical-design-engineer

Apptronik

Apptronik builds Apollo and hires across autonomy, reinforcement learning, perception, simulation, hand hardware, end-effectors, platform software, manufacturing, and deployment.

Why it matters for this role: Apptronik's current hiring signals show manipulation as both a software problem and a hardware integration problem. Its dexterity and end-effector roles describe hands as the primary interface between Apollo and the physical world, while autonomy, perception, reinforcement learning, and simulation roles support manipulation, synthetic data, and task execution.

Useful internal links to create:

• /careers/companies/apptronik
• /careers/jobs?company=apptronik&role_family=manipulation-and-dexterity
• /careers/role-atlas/simulation-engineer
• /careers/role-atlas/perception-engineer
• /careers/role-atlas/embedded-systems-engineer
• /careers/role-atlas/mechanical-design-engineer

Sanctuary AI

Sanctuary AI works on physical AI, industrial automation, robotic hands, software, controls, simulation, mechanical engineering, and AI/ML. Current company and careers pages reviewed on 2026-07-02 showed hiring language around AI/ML research engineers, software engineers, simulation experts, mechanical engineers, and controls engineers.

Why it matters for this role: Sanctuary is a useful example for candidates interested in dexterous manipulation, embodied AI, simulation, controls, and the bridge between robotic hands and learned task behavior.

Useful internal links to create:

• /careers/companies/sanctuary-ai
• /careers/jobs?company=sanctuary-ai&role_family=manipulation-and-dexterity
• /careers/role-atlas/robotics-ai-engineer
• /careers/role-atlas/controls-engineer
• /careers/role-atlas/actuator-engineer

1X Technologies

1X works on humanoid home robots and hires across AI, simulation, reinforcement learning, data, software, fleet operations, hardware, manufacturing, and product depending on location and hiring cycle.

Why it matters for this role: 1X is useful for readers interested in household manipulation, long-horizon embodied AI, data-driven robot learning, simulation, and human-in-the-loop systems. Home environments raise manipulation difficulty because objects, layouts, lighting, and tasks vary widely.

Useful internal links to create:

• /careers/companies/1x-technologies
• /careers/jobs?company=1x&role_family=manipulation-and-dexterity
• /careers/role-atlas/robotics-ai-engineer
• /careers/role-atlas/simulation-engineer
• /careers/role-atlas/data-teleoperation-engineer

Boston Dynamics

Boston Dynamics hires across Atlas, robotics software, controls, simulation, robot learning, testing, applications, and systems engineering depending on hiring cycle.

Why it matters for this role: Atlas is a strong reference point for whole-body mobile manipulation, where arms, legs, torso, perception, and task execution must work together. Even when a role is not titled “Manipulation Engineer,” Atlas applications, teleoperation, AI, simulation, controls, and testing roles may connect to manipulation.

Useful internal links to create:

• /careers/companies/boston-dynamics
• /careers/jobs?company=boston-dynamics&role_family=manipulation-and-dexterity
• /careers/role-atlas/locomotion-engineer
• /careers/role-atlas/controls-engineer
• /careers/role-atlas/robot-test-validation-engineer

Agility Robotics

Agility Robotics builds Digit for logistics and industrial automation. Its role mix varies, but current careers messaging emphasizes engineers, AI researchers, manufacturing experts, testing, validation, skills development, and deployment.

Why it matters for this role: Agility is useful for candidates who want manipulation-adjacent work tied to practical logistics tasks, warehouse workflows, task reliability, and deployment operations.

Useful internal links to create:

• /careers/companies/agility-robotics
• /careers/jobs?company=agility-robotics&role_family=manipulation-and-dexterity
• /careers/role-atlas/field-robotics-engineer
• /careers/role-atlas/robot-operations-fleet-operator
• /careers/role-atlas/robotics-safety-engineer

NEURA Robotics

NEURA Robotics hires across AI, manipulation, humanoid robotics, perception, simulation, reinforcement learning, teleoperation, product, and robot training roles depending on location.

Why it matters for this role: NEURA's AI manipulation roles are clear examples of manipulation work at the intersection of imitation learning, reinforcement learning, multimodal sensing, tactile-rich hardware, and real hardware deployment.

Useful internal links to create:

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

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

Strong positive signals

• Can explain the full perception-to-action pipeline for a manipulation task.
• Has built a working pick-and-place, grasping, visual servoing, tactile, or policy-learning project.
• Understands frames, calibration, kinematics, and motion planning.
• Can debug why a grasp failed without blaming only “the model.”
• Can discuss contact, friction, compliance, force, slip, and object variation.
• Has used simulation but does not pretend simulation equals hardware.
• Can describe metrics: task success rate, grasp success, recovery rate, object damage, cycle time, and generalization.
• Has worked with ROS 2, MoveIt, Isaac Sim, MuJoCo, Drake, or comparable robotics tools.
• Can compare classical planning and learned policies without treating one as universally better.
• Writes readable C++ and Python.
• Uses logs, videos, plots, and trial data to diagnose failures.
• Understands safety boundaries around arms, hands, force, payload, and human proximity.

Weak signals

• Only shows AI papers or notebooks with no robot action pipeline.
• Cannot explain coordinate frames or hand-eye calibration.
• Treats grasping as only object detection.
• Has no failure analysis.
• Shows one polished demo with no metrics or repeatability.
• Does not understand contact, friction, force, or compliance.
• Assumes a learned policy is automatically better than a simpler engineered pipeline.
• Has never thought about object damage, dropped objects, or unsafe retries.
• Cannot explain how data was collected, cleaned, labeled, or evaluated.
• Describes ROS or MoveIt as skills but cannot explain how the pieces connect.

Interview questions to prepare for

• Walk me through a manipulation system you built from perception to action.
• How would you debug a robot that detects an object correctly but fails to grasp it?
• How do you choose between a classical grasp planner and a learned manipulation policy?
• What metrics would you use to evaluate a pick-and-place skill?
• How would you handle object pose uncertainty during a grasp?
• What is hand-eye calibration and why does it matter?
• How would you make a manipulation policy safer on real hardware?
• How would you design retries for a failed grasp?
• How do force control and impedance control help during contact?
• How would you test manipulation in simulation before deploying to hardware?
• What makes dexterous manipulation harder than parallel-jaw grasping?
• How would you collect high-quality teleoperation data for a robot manipulation task?
• What failure modes would you expect when moving from lab objects to customer-site objects?
• How would you coordinate manipulation with locomotion or whole-body balance?
• Tell me about a manipulation bug that was caused by hardware, not software.

• Thinking manipulation is just computer vision. Seeing the object is only one part of the task. The robot still needs a feasible contact, trajectory, grip, force profile, and recovery strategy.
• Thinking manipulation is just motion planning. Planning through free space is not enough when the robot has to make contact, hold objects, handle slip, and react to uncertainty.
• Jumping straight to dexterous hands. Start with simpler grippers and clear metrics. Dexterous hands multiply the difficulty.
• Ignoring calibration. Small frame errors can destroy manipulation performance.
• Only testing one object. A robot that works on one known object is not ready for real deployment.
• No failure taxonomy. “It failed” is not enough. Label whether the failure was perception, grasp selection, collision, slip, force, timeout, planning, policy, hardware, or recovery.
• Overclaiming learned autonomy. Be clear about what is scripted, learned, teleoperated, simulated, or manually reset.
• Ignoring hardware limits. Grip force, joint torque, backlash, thermal limits, sensor noise, and fingertip material all matter.
• No safety story. Manipulation can damage objects, robots, fixtures, and people. Explain limits, stops, retries, and safe aborts.
• No repeatability. A single successful video is weaker than twenty trials with a table of outcomes.

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

First 30 days: build the manipulation base

• Learn coordinate frames, transforms, forward kinematics, inverse kinematics, and basic motion planning.
• Run a simulated robot arm in ROS 2, MoveIt 2, Isaac Sim, Gazebo, Drake, or MuJoCo.
• Build a simple scripted pick-and-place or reach-and-grasp demo.
• Learn how robot descriptions, joint limits, collision geometry, and camera frames affect manipulation.
• Write a clean README for every experiment.

Output: a small manipulation repo with a robot arm, a launch file, a scripted motion, a frame diagram, and a video demo.

Days 31-60: connect perception, planning, and feedback

• Add object detection, fiducial tracking, pose estimation, or point-cloud perception.
• Connect perception output to grasp or target pose selection.
• Add collision-aware motion planning.
• Add one recovery behaviour, such as retry, regrasp, reposition, or safe abort.
• Record and replay logs.
• Measure task success across repeated trials.

Output: a perception-driven manipulation demo with at least ten trials, metrics, failure labels, and a short failure analysis.

Days 61-90: make it look hireable

• Add closed-loop feedback: visual servoing, force/contact detection, slip detection, or policy monitoring.
• Add tests or simulation regression scenarios.
• Compare two approaches: scripted vs planned, classical vs learned, open-loop vs closed-loop, or simulation-only vs hardware.
• Improve documentation and architecture diagrams.
• Create a short project video and a concise technical write-up.
• Map your project to real job descriptions.

Output: a portfolio project that looks like a small version of real manipulation engineering work: task definition, system architecture, metrics, logs, failure modes, and a clear explanation of what you would improve next.

Is a Manipulation Engineer the same as a Robotics AI Engineer?

Not exactly. A Robotics AI Engineer may work on broader embodied AI, world models, reasoning, planning, or foundation models. A Manipulation Engineer focuses specifically on physical interaction: grasping, dexterity, arm/hand motion, contact, perception-to-action, and task success on real or simulated robots. Some jobs combine both.

Is this role mostly machine learning?

Not always. Some manipulation roles are heavily learning-based, especially in humanoid robot learning teams. Others are more focused on motion planning, control, grasping, tactile sensing, integration, simulation, or test. Good candidates understand both classical robotics and learning-based approaches well enough to choose the right tool for the task.

Do I need a PhD?

For research-heavy dexterous manipulation or robot learning roles, a PhD or equivalent research experience can help. For applied manipulation software, integration, test, simulation, and platform roles, strong project evidence and real robot experience can matter just as much. Be honest about the level of role you are targeting.

Can a beginner start here?

Yes, but start with simpler projects. Begin with a simulated or affordable robot arm, ROS 2, MoveIt, kinematics, pick-and-place, and clear metrics. Do not start by claiming you can solve general-purpose dexterous humanoid manipulation in a few weeks.

Should I learn MoveIt or reinforcement learning first?

For most people, learn MoveIt or a similar manipulation stack first. It teaches frames, kinematics, planning, collision checking, and task execution. Reinforcement learning and imitation learning become more useful once you understand the robot action problem.

What is the fastest credible project?

A perception-driven pick-and-place project with ROS 2, a clear TF diagram, MoveIt or another planner, ten or more trials, failure labels, and one recovery behaviour is more credible than a polished AI demo with no metrics.

How is humanoid manipulation different from industrial robot-arm manipulation?

Industrial arms are often fixed in controlled cells with known fixtures and repeatable tasks. Humanoids must manipulate at human scale, often while standing, balancing, using two arms, dealing with varied environments, and sometimes using human-like hands. The constraints are broader and messier.

What should I show in my portfolio?

Show the system, not just the result. Include architecture diagrams, frame diagrams, logs, trial metrics, failure cases, code quality, hardware or simulation setup, and a clear explanation of what did not work.