Robotics Software Engineer Career Guide | Humanoid Robotics Role Atlas

Q: Where should this page link jobs?

Use the internal jobs portal only. Link to `/careers/jobs?role_family=robotics-software`, not to point-in-time external job posts.

00 · Stack map

Where this role sits in the humanoid stack

Brain: behavior logic, planning systems, robot state machines, AI integration, autonomy runtime.
Eyes: sensor drivers, perception data flow, calibration support, transform handling.
Hands and legs: interfaces to manipulation, locomotion, controls, and whole-body behaviors.
Body: hardware abstraction, robot health state, diagnostics, fault handling.
Simulation layer: simulated robot environments, test harnesses, regression checks, sim-to-real workflows.
Factory layer: build validation, bring-up tooling, end-of-line test software, release gates.
Fleet layer: logs, telemetry, deployment tooling, monitoring, operator tools, over-the-air software workflows.

01 · The work

What this role actually does

A robotics software engineer writes and maintains the software systems that connect a robot's hardware, algorithms, and operating environment.

In a humanoid company, the work often includes:

Building robot software services in C++, Python, and sometimes Rust, Go, or TypeScript.
Working with ROS 2 or comparable middleware to pass messages between sensors, controllers, planners, and applications.
Integrating cameras, IMUs, force sensors, tactile sensors, joint encoders, motor controllers, compute boards, batteries, and networked devices.
Creating behavior logic so the robot can perform tasks such as pick, place, walk to a location, recover from a failed grasp, dock, wait, stop, or ask for human help.
Building APIs between autonomy software, operator tools, simulation tools, product interfaces, data systems, and fleet management systems.
Writing tools for debugging robot state, replaying logs, visualizing sensor data, checking transforms, and diagnosing failures.
Improving latency, reliability, memory use, CPU/GPU use, startup behavior, shutdown behavior, and fault recovery.
Creating tests that run in simulation, on hardware-in-the-loop rigs, and on real robots.
Supporting field deployments when software behaves differently in the real world than it did in the lab.
Translating ambiguous robot behavior problems into concrete bugs, metrics, dashboards, and fixes.

The job is usually cross-functional. You may work with controls engineers, mechanical engineers, electrical engineers, perception engineers, simulation engineers, data engineers, QA engineers, field engineers, safety engineers, and product managers.

What the work feels like day to day

A normal week might include:

Debugging why a robot sometimes stops after a sensor stream drops for 300 milliseconds.
Adding a new ROS 2 node that publishes robot health status to an operator dashboard.
Profiling a perception pipeline because latency increased after a model update.
Writing a behavior tree or state machine for a warehouse task.
Creating a replay tool so engineers can reproduce a failure from a logged deployment.
Working with an electrical systems engineer to validate a new sensor bus.
Adding simulation tests so a robot behavior is checked before it reaches hardware.
Joining a robot test session, watching what fails, and turning the failure into a concrete software fix.
Building a launch or configuration system that prevents the wrong robot version from running the wrong software build.
Writing documentation so another engineer can run, debug, and extend your subsystem.

The best robotics software engineers are not only good coders. They are good debuggers of systems where software, hardware, physics, timing, and human expectations all collide.

02 · Why it matters

Why it matters in humanoid robotics

Humanoid robots are full-stack machines. A useful humanoid is not just an AI model, a mechanical body, or a walking controller. It is a live system where many subsystems have to coordinate under real-world constraints.

Robotics software engineering matters because humanoids need:

Reliable integration
A strong perception model or control algorithm is not useful if it cannot run reliably on the robot, communicate with the rest of the system, recover from failures, and expose useful diagnostics.
Real-time awareness
Robots move in the physical world. Delayed data, stale transforms, overloaded compute, dropped messages, or poorly handled edge cases can become physical failures.
Clear behavior boundaries
Humanoid systems need software limits, fallback modes, emergency states, watchdogs, health checks, and clear operating modes. Safety is not only a hardware problem.
Scalable testing
Humanoid companies cannot rely on hero demos. They need simulation tests, regression tests, log replay, hardware-in-the-loop testing, and deployment gates.
Deployment readiness
The industry is moving from research prototypes toward pilots, factories, warehouses, homes, and customer sites. That shift increases the value of engineers who can make robot software maintainable and observable.
Data flow for physical AI
Modern humanoid development depends on robot logs, teleoperation data, simulation data, human motion data, and training pipelines. Robotics software engineers often build the bridges that make this data useful.

A simple rule: if the robot can do something impressive once, research may have proved the idea. If the robot can do it repeatedly, safely, with logs, tests, deployment tooling, and recovery behavior, robotics software engineering made it real.

03 · Backgrounds

Best-fit backgrounds

This role is a strong fit for several backgrounds, but each background has a different gap to close.

Software engineers moving into robotics

You already have useful skills: software design, debugging, version control, APIs, testing, CI, deployment discipline, and large-codebase experience.

You are probably missing: coordinate frames, kinematics, robot middleware, sensors, real-time constraints, simulation, Linux hardware interaction, and comfort with physical testing.

Best entry angle: robotics platform software, integration tooling, logging, simulation infrastructure, robot dashboards, fleet tooling, developer tools, or test automation.

Robotics students and graduates

You may already understand ROS, controls, perception, planning, and simulation at a project level.

You are probably missing: production-quality software engineering, clean interfaces, test coverage, code review discipline, deployment thinking, performance profiling, and release discipline.

Best entry angle: junior robotics software engineer, robot behaviors engineer, autonomy software engineer, simulation software engineer, software engineer in test, or robotics integration engineer.

AI/ML engineers moving into embodied AI

You already understand training, inference, models, datasets, evaluation, and Python tooling.

You are probably missing: robot runtime systems, hardware constraints, sensor timing, motion constraints, action interfaces, failure recovery, and safety cases.

Best entry angle: robot learning infrastructure, data pipelines, policy deployment, simulation, teleoperation tooling, perception-to-action integration.

Embedded or firmware engineers

You already understand hardware, low-level systems, timing, drivers, memory, and reliability.

You are probably missing: ROS 2, autonomy architecture, simulation workflows, high-level robot behaviors, perception integration, and AI tooling.

Best entry angle: embedded robotics software, sensor integration, actuator interfaces, compute/sensing platforms, real-time robot systems.

Simulation or game-engine engineers

You already understand 3D environments, physics engines, runtime performance, scene graphs, assets, scripting, and developer tooling.

You are probably missing: robot middleware, control loops, real sensor models, calibration, robot description formats, and sim-to-real failure modes.

Best entry angle: simulation software engineer, synthetic data engineer, robot training infrastructure, test harness engineer.

04 · Skills

Skills to learn

Think of this role in layers. Do not try to learn everything at once.

Core software skills

These are non-negotiable for most robotics software jobs.

C++: memory, concurrency, templates at a practical level, build systems, performance profiling, debugging.
Python: scripting, data processing, automation, testing, ROS tooling, log analysis.
Linux: shell, processes, networking basics, permissions, system services, debugging tools.
Git: branching, pull requests, code review, bisecting, clean commits.
Testing: unit tests, integration tests, simulation tests, regression tests, hardware-in-the-loop tests.
Debugging: logs, traces, profilers, reproducible bug reports, minimal test cases.

Robotics foundations

These separate robotics software from normal software.

Coordinate frames and transforms.
Robot kinematics: forward kinematics, inverse kinematics, Jacobians at a practical level.
Basic dynamics: mass, inertia, torque, contact, friction, momentum.
Sensors: cameras, depth cameras, LiDAR, IMU, encoders, force/torque sensors, tactile sensors.
Actuators and controllers: motors, current/torque/position control, control loops, latency.
State estimation basics: filtering, odometry, localization, sensor fusion.
Motion planning basics: trajectories, constraints, collision checking.
Safety basics: emergency stop, watchdogs, fault states, degraded modes, human proximity.

Robotics software architecture

Humanoid robots are distributed systems with legs.

Learn:

ROS 2 nodes, topics, services, actions, parameters, launch files, bags, QoS.
Message schemas and interface design.
Behavior trees or state machines.
Real-time and near-real-time system constraints.
Multi-process systems and distributed debugging.
Hardware abstraction layers.
Configuration management for robot variants.
Log replay and observability.
Release management for robot software.
Deployment gates for robot software.

Humanoid-specific skills

These are especially useful for humanoid robotics.

Whole-body state representation.
Contact-rich manipulation and locomotion constraints.
Multi-camera perception pipelines.
Teleoperation data flow.
Human motion data processing.
Simulation-to-real testing.
Robot health monitoring and fault recovery.
Safe task execution around people and customer environments.

Production engineering skills

These become more important as companies move from demos to deployments.

CI/CD for robot software.
Docker or containerized development environments.
Build systems such as CMake, Bazel, or colcon.
Performance profiling for CPU, memory, GPU, latency, and bandwidth.
API design for internal tools.
Observability dashboards.
Release management and rollback.
Documentation that helps other engineers use your system.

05 · Tools

Tools & technologies

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

Robot middleware and runtime

ROS 2: common open-source framework for building robot applications, communication, tooling, and ecosystem packages.
DDS: communication layer used under ROS 2.
Custom middleware: many advanced humanoid companies use internal systems, but ROS knowledge still transfers.
LCM, ZeroMQ, gRPC, or custom pub/sub systems: sometimes used for robot runtime communication.

Languages

C++: performance-sensitive robot runtime, controllers, drivers, middleware, simulation integration.
Python: tooling, experiments, data processing, tests, training infrastructure, automation.
Rust: emerging in safety-conscious systems, tooling, and low-level software.
TypeScript: useful for operator tools, dashboards, internal web tools, and manufacturing/fleet software.

Simulation and robot development

NVIDIA Isaac Sim / Isaac Lab: robot simulation, synthetic data, robot learning workflows, and humanoid development.
Gazebo: open-source robot simulation with physics, rendering, sensor models, plugins, and ROS integration.
MuJoCo: physics simulation often used in robot learning and control research.
Drake: modeling, simulation, planning, and optimization for dynamical systems.
Unity / Unreal Engine: sometimes used for teleoperation interfaces, simulation, data generation, or visualization.

Motion, planning, and manipulation

MoveIt / MoveIt 2: motion planning and manipulation framework in the ROS ecosystem.
OMPL: sampling-based motion planning library often used through MoveIt.
Pinocchio / RBDL / KDL: kinematics and dynamics libraries.
BehaviorTree.CPP: behavior trees for robot task logic.

Sensors and perception plumbing

Camera drivers, depth sensors, IMUs, force/torque sensors, tactile sensors.
Calibration tools for intrinsic and extrinsic camera parameters.
TF trees and transform debugging.
Zero-copy and low-latency data movement where performance matters.

Data, logging, and debugging

rosbag / MCAP: recording and replaying robot data.
Foxglove: visualization and analysis of multimodal robotics logs.
RViz: ROS visualization.
Prometheus / Grafana / OpenTelemetry: sometimes used for robot, fleet, and infrastructure monitoring.
GDB, perf, Valgrind, sanitizers: practical debugging and profiling tools.

Build, test, and deployment

CMake / colcon / Bazel: build systems.
Docker: reproducible development and deployment environments.
GitHub Actions / GitLab CI / Buildkite / Jenkins: CI pipelines.
Hardware-in-the-loop rigs: automated testing against real components.
Kubernetes: sometimes used for cloud/backend/fleet infrastructure, less commonly on the robot itself.

06 · Projects

Portfolio projects to prove ability

A good robotics portfolio should show working systems, not only notebooks. The project should make it easy for a hiring team to see how you think, how you debug, and how you deal with robot-specific constraints.

Project 1: ROS 2 robot behavior stack in simulation

Build: a ROS 2 package where a simulated robot performs a simple task using a state machine or behavior tree.

For a beginner-friendly humanoid-adjacent version, use a mobile manipulator or biped/humanoid model in Gazebo or Isaac Sim. The robot should receive a task command, move through states, publish status, handle one failure case, and log the run.

What it proves:

You understand ROS 2 nodes, topics, services, actions, and launch files.
You can structure robot behavior rather than write one-off scripts.
You can use simulation as a testing tool.
You can expose robot state clearly.

Evidence to include:

GitHub repo with clean README.
Architecture diagram.
Video demo.
Launch instructions.
One recorded log and instructions for replay.
Explanation of one failure case and how the software recovers.

Project 2: Sensor-to-action mini pipeline

Build: a small pipeline where a camera or simulated sensor detects an object or marker, publishes a pose, and triggers a robot action such as pointing, moving toward it, or planning a simple reach.

What it proves:

You understand perception data flow.
You can manage coordinate transforms.
You can connect perception output to robot behavior.
You can handle noisy inputs and invalid detections.

Evidence to include:

TF tree screenshot or diagram.
Latency measurement.
Video of successful and failed detections.
Clear notes on how you validate transform correctness.

Project 3: Robot log replay and debugging tool

Build: a tool that reads recorded robot logs, extracts key events, visualizes timelines, and flags anomalies such as dropped messages, high latency, missing transforms, or state transitions that happen in the wrong order.

What it proves:

You understand that robotics debugging depends on data.
You can build practical tools for engineers.
You can reason about timing and failure reproduction.

Evidence to include:

Sample dataset.
CLI or web UI.
Screenshots.
Explanation of the anomaly rules.
Before/after example showing how the tool speeds up debugging.

Project 4: Hardware interface or hardware-in-the-loop demo

Build: a small hardware interface for a real sensor, motor, microcontroller, or actuator test rig. Publish data into ROS 2, expose diagnostics, and add automated tests where possible.

This can be done with affordable hardware: an IMU, depth camera, motor controller, Arduino/STM32, or small servo rig. The point is not expensive hardware. The point is real integration.

What it proves:

You can handle real devices.
You understand timing, noise, calibration, and fault handling.
You can write software that does not assume perfect inputs.

Evidence to include:

Wiring diagram.
Driver/interface code.
Diagnostic output.
Failure handling notes.
Test procedure.

Project 5: Simulation regression test suite

Build: a small CI pipeline that runs simulation tests for robot behavior. For example, every pull request checks whether the robot can complete a navigation, reaching, or task-state sequence in simulation.

What it proves:

You understand production robotics needs repeatable tests.
You can connect software engineering discipline to robot behavior.
You can prevent regressions before code reaches hardware.

Evidence to include:

CI configuration.
Test pass/fail reports.
Description of test scenarios.
One intentionally failing test and explanation.

See open robotics software engineer jobs

07 · Titles

Common job titles

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

Direct titles

Robotics Software Engineer
Robot Software Engineer
Robot Platform Software Engineer
Robotics Platform Engineer
Robotics Middleware Engineer
Robot Behaviors Engineer
Autonomy Software Engineer
Robot Software Integration Engineer
Robotics Systems Software Engineer
Robotics Infrastructure Engineer

Adjacent titles

Simulation Software Engineer
Perception Systems Software Engineer
Motion Planning Software Engineer
Manipulation Software Engineer
Locomotion Software Engineer
Embedded Robotics Software Engineer
Software Engineer in Test, Robotics
Hardware-in-the-Loop Software Engineer
Robot Reliability Software Engineer
Fleet Software Engineer, Robotics
Teleoperation Software Engineer
Data Infrastructure Engineer, Robotics
Robot Tools Engineer
Robot Runtime Engineer

Search keywords

Use these as job-board filters:

robotics software
robot platform
ROS 2
humanoid
autonomy software
robot behavior
robot middleware
simulation robotics
hardware-in-the-loop
motion planning
manipulation
robot deployment
robot fleet
teleoperation
sensor integration
real-time C++
Linux robotics
robot integration
robot runtime

08 · Companies

Companies hiring for this work

Job openings change quickly. Treat this as a live company map, not a permanent list. These companies are useful examples for the Companies and Jobs sections. The public page should link to internal company pages and your internal jobs portal, not to old external job posts.

Figure

Figure is a strong signal for humanoid software, robot integration, AI infrastructure, commercial deployment, data operations, controls infrastructure, and product-facing systems.

Why it matters for this role: Figure-style listings show that humanoid robotics software is not limited to autonomy research. It also includes middleware, integration tooling, robot operations software, manufacturing support, data systems, and deployment readiness.