From Software Engineer to Physical-AI Engineer

What physical AI actually is, and who this suits

Physical AI is the work of putting learned models inside machines that move. Not chat, not retrieval, not a service behind an API — a body, sensors, actuators, and a control loop that must produce an answer before the next tick whether or not the model is confident. As of July 2026, such roles are reported among the most in-demand technical positions of the year, against a stated talent shortage.

Underneath the label are four genuinely different job families. Robotics software engineering is the systems layer: nodes, middleware, drivers, the thing that keeps a fleet running. Perception and sensing turns camera, depth and inertial data into an environmental understanding a planner can use, and is among the highest-paid specialities in the field. Controls owns motion planning, navigation and the classical control that keeps a machine stable. Physical-AI machine learning trains the policies for dexterity and real-time decision-making — where people arriving from an LLM background instinctively aim, usually too early.

This suits you if you have shipped production software for a few years and physical consequences interest rather than alarm you. It suits you badly if what you enjoy about software is the tight feedback loop, because physical AI has the slowest iteration cycle of any AI specialisation. If you have not yet committed to a direction, our guide to choosing an AI specialisation covers the software-side tracks; this one sits outside that taxonomy.

What transfers, and what genuinely does not

What transfers. Systems thinking carries almost wholesale — a robot stack is a distributed system with a hard latency budget, and your instincts about interfaces, ownership and failure isolation are what robotics teams are short of. Testing discipline transfers and is scarcer here than in web engineering, so you can visibly add it on day one. So do profiling, CI (hardware-in-the-loop CI rarely arrives ready-made), and incident review.

What does not. Real-time determinism is the first shock: the answer must arrive before a deadline every time, and a garbage-collected runtime with unbounded pauses is not an acceptable home for that loop. Sensor noise becomes a first-class design concern rather than an edge case — your inputs are wrong constantly, in structured, correlated ways, and the system must behave sensibly anyway. Safety cases are a new genre of artefact: an argued, documented claim that a machine is acceptably safe, which is not a passing test suite. You cannot roll back a collision, so the fix-forward instinct is actively dangerous. And hardware iteration is slow; no framework fixes it.

Job family	Core skills required	Background it suits
Robotics software engineer	C++ and Python, ROS 2 middleware, state machines, drivers, logging and replay, hardware-in-the-loop CI	Backend and platform engineers — your testing discipline is the gap the team already feels
Perception and sensing	Computer vision, depth and inertial sensing, calibration, sensor fusion, environmental understanding	Vision, graphics and signal-processing engineers — fusion sits on top of vision you may know
Controls and motion	Control systems, motion planning, navigation, rigid-body transforms, real-time determinism	Embedded, aerospace and mechatronics engineers — classical control first, learned policies second
Physical-AI machine learning	Policy learning for dexterity and real-time decision-making, simulation, domain randomisation	ML engineers with strong software fundamentals — the longest bridge; learn the stack before the policy

The skill stack, in the order you should learn it

Sequence matters more here than in most transitions, because each layer makes the next debuggable. A realistic budget at eight to ten hours a week:

• C++ — four to six weeks, then continuous. Start here and do not negotiate. Industry skill lists for physical-AI roles name C++ and Python together, and the split is not arbitrary: anything inside a real-time loop, on constrained on-robot compute, or in a driver layer is overwhelmingly C++. Read a large codebase fluently and write memory-safe components — smart pointers, RAII, move semantics, CMake. Python you likely have already, and it stays the language of training and tooling.
• Linear algebra and rigid-body transforms — three weeks. Rotations in their several representations, homogeneous transforms, and composing chains without losing track of which frame you are in. Almost every embarrassing robotics bug is a frame error.
• ROS 2 fundamentals — five to six weeks. Nodes, topics, services and actions; the tf2 transform tree; lifecycle nodes; and the DDS quality-of-service settings that decide whether messages arrive reliably, quickly, or at all. A QoS mismatch is the classic silent failure — two nodes that look connected and never exchange a message.
• Simulation — three to four weeks, then continuous. Learn one general-purpose simulator well rather than three badly. Gazebo-class and Isaac-class tools differ in physics engine and GPU needs, but the skills transfer: build a world, describe a robot, wire sensors, script reproducible episodes.
• Computer vision and sensor fusion — four to five weeks. Camera models and calibration, then depth, then fusing vision with inertial and odometry data into a state estimate you can plan against.
• Classical control alongside learned policies — four weeks. PID, feedforward, state estimation and stability intuition come first, because on real machines learned policies sit inside a classical safety envelope — and you will be asked to describe it.

A minimal ROS 2 node is the "hello world" of the discipline: a node that publishes on a timer and subscribes to a topic is what nearly every component in a robot stack looks like underneath.

#!/usr/bin/env python3
"""Minimal ROS 2 node: publishes a velocity command, subscribes to odometry.
Illustrative — check your distribution's message types and QoS defaults."""

import rclpy
from rclpy.node import Node
from rclpy.qos import QoSProfile, ReliabilityPolicy, HistoryPolicy

from geometry_msgs.msg import Twist
from nav_msgs.msg import Odometry


class CruiseNode(Node):
    def __init__(self):
        super().__init__("cruise_node")

        # Sensor streams are usually BEST_EFFORT: a dropped sample beats a stalled loop.
        sensor_qos = QoSProfile(
            reliability=ReliabilityPolicy.BEST_EFFORT,
            history=HistoryPolicy.KEEP_LAST,
            depth=10,
        )
        # Commands are RELIABLE: you do not want a stop command silently dropped.
        command_qos = QoSProfile(
            reliability=ReliabilityPolicy.RELIABLE,
            history=HistoryPolicy.KEEP_LAST,
            depth=1,
        )

        self.cmd_pub = self.create_publisher(Twist, "/cmd_vel", command_qos)
        self.odom_sub = self.create_subscription(
            Odometry, "/odom", self.on_odom, sensor_qos
        )

        self.target_speed = 0.25          # metres per second
        self.measured_speed = 0.0
        self.last_odom_time = None

        # 20 Hz control tick. The period is a contract, not a suggestion.
        self.timer = self.create_timer(0.05, self.on_tick)

    def on_odom(self, msg: Odometry) -> None:
        self.measured_speed = msg.twist.twist.linear.x
        self.last_odom_time = self.get_clock().now()

    def on_tick(self) -> None:
        # Stale sensor data is a failure, not a gap. Fail safe, loudly.
        if self.last_odom_time is None:
            self.get_logger().warning("no odometry yet; holding zero")
            self.cmd_pub.publish(Twist())
            return

        age = (self.get_clock().now() - self.last_odom_time).nanoseconds / 1e9
        if age > 0.25:
            self.get_logger().error(f"odometry stale by {age:.2f}s; commanding stop")
            self.cmd_pub.publish(Twist())
            return

        cmd = Twist()
        error = self.target_speed - self.measured_speed
        cmd.linear.x = self.measured_speed + 0.5 * error   # simple proportional term
        self.cmd_pub.publish(cmd)


def main() -> None:
    rclpy.init()
    node = CruiseNode()
    try:
        rclpy.spin(node)
    finally:
        node.destroy_node()
        rclpy.shutdown()


if __name__ == "__main__":
    main()

The second daily task is moving a quantity between coordinate frames — a detection arrives in the camera's frame, the planner needs it in the base frame. Getting this wrong produces the most characteristic robotics bug of all: a system that is confidently, geometrically incorrect.

#!/usr/bin/env python3
"""Transform a detection from the camera frame into the robot base frame with tf2.
The lookup is time-stamped on purpose: frames move, so 'where was the camera
when this pixel was captured' is a different question from 'where is it now'."""

import rclpy
from rclpy.node import Node
from rclpy.duration import Duration
from rclpy.time import Time

import tf2_ros
import tf2_geometry_msgs                      # registers PointStamped conversions
from geometry_msgs.msg import PointStamped


class FrameBridge(Node):
    def __init__(self):
        super().__init__("frame_bridge")
        self.buffer = tf2_ros.Buffer()
        self.listener = tf2_ros.TransformListener(self.buffer, self)

    def to_base_frame(self, detection: PointStamped) -> PointStamped | None:
        """detection.header.frame_id is e.g. 'camera_optical_frame'."""
        try:
            transform = self.buffer.lookup_transform(
                target_frame="base_link",
                source_frame=detection.header.frame_id,
                time=Time.from_msg(detection.header.stamp),   # capture time, not now
                timeout=Duration(seconds=0.1),
            )
        except (tf2_ros.LookupException,
                tf2_ros.ConnectivityException,
                tf2_ros.ExtrapolationException) as exc:
            # Do NOT fall back to the identity transform. A missing transform is
            # unknown geometry; treating it as zero invents a confident wrong answer.
            self.get_logger().warn(f"transform unavailable: {exc}")
            return None

        return tf2_geometry_msgs.do_transform_point(detection, transform)

The 26-week study plan

Twenty-six weeks at eight to ten hours a week, in three phases, each ending in something a stranger can evaluate. The failure mode of self-directed robotics study is drifting through tutorials with nothing shippable at the end.

Phase	Weeks	What you work through	Deliverable
1 — Foundations	1–8	1–2: pick a job family, set up Linux and a ROS 2 distribution. 3–6: modern C++ by writing small components, not exercises. 7–8: transforms, drilled until frame composition is automatic.	A small C++ library with tests and a CMake build, plus a note working a two-hop transform chain by hand and verifying it in code.
2 — The robot stack	9–18	9–12: ROS 2 in earnest — nodes, topics, services, actions, tf2, lifecycle nodes, DDS QoS, bag record and replay. 13–15: simulation. 16–18: perception and sensor fusion.	Portfolio project one: a simulated robot navigating a randomised environment, with metrics, a failure analysis and a video.
3 — Policies and hardware	19–26	19–21: classical control and the safety envelope a policy sits inside. 22–24: a policy trained in simulation with randomisation and system identification. 25–26: hardware bring-up, and writing it up.	Portfolio projects two and three, plus a published sim-to-real writeup with numbers from both sides of the gap.

Three portfolio projects, in increasing difficulty

Three projects, sequenced so each reuses the last. The first is deliberately free.

Project	Setup and rough cost	What "done" means	What the writeup shows
1. Simulated navigation under randomisation	Simulation only. A capable laptop or an hour of rented GPU. Effectively zero budget.	Goal reached across 50 consecutive randomised environments at a stated success rate, and you can explain every failure.	Success rate, path length and time to goal against a baseline; randomisation ranges; a failure taxonomy; a 60-second video.
2. Perception and calibration on real sensors	A depth camera or stereo pair, a calibration target, a tripod. A real but modest spend — plan for it honestly.	Detections land in the base frame within a stated positional error, against ground truth you collected yourself.	Calibration procedure and residuals; error under varied lighting and distance; failure cases you did not fix, and why.
3. Sim-to-real transfer on affordable hardware	A low-cost hobby arm or small differential-drive base, plus spares. A genuine budget — do not start until one and two are done.	A policy trained in simulation runs on the real machine and completes the task at a rate measured on both sides of the gap.	Sim success rate, first-attempt real success rate, the gap after system identification, and the safety envelope.

Project one exists so a reader in Bengaluru or Birmingham with no equipment budget can produce hireable evidence within a quarter. Randomise layout, lighting, friction and obstacle placement per episode, and run enough episodes to report a real success rate rather than an anecdote. Most hobby portfolios contain one hand-tuned demo that worked once; a randomised evaluation with a failure taxonomy signals engineering rather than luck.

Project two is where physical reality bites: calibrate a real camera, measure your own ground truth, and report the error honestly, including how it degrades in poor light and at range. Project three separates candidates — train in simulation, deploy on a modest real machine, measure both, write up the gap. Not before the first two are done, because hardware punishes weak foundations expensively. For packaging work so a reviewer can judge it in two minutes, our on-device AI proof-of-work portfolio guide transfers directly.

Sim-to-real: the thing that separates shippers from watchers

Simulation is indispensable and it is also a liar. It lies in specific, learnable ways, and understanding them separates an engineer who has shipped something physical from one who has watched a great many tutorials. The gap has three sources. Dynamics mismatch: friction, damping, backlash, motor response and the contact model are approximations, and contact is where they are weakest — which is why a policy that scores perfectly in simulation so often fails the moment two rigid bodies touch. Perception mismatch: rendered images differ from real ones in noise, exposure, motion blur and the irregularity of real lighting. Timing mismatch: the simulator gives your policy a punctual world; the real machine has jitter, latency and dropped frames.

Domain randomisation is the first line of defence. Rather than making one simulation perfectly accurate, you train across a distribution of them — varying masses, frictions, latencies, textures, lighting and sensor noise — so the policy learns behaviour robust to what you could not measure. The real world then becomes one more sample from a distribution the policy has seen.

# domain_randomisation.yaml
# Sketch of a randomisation config. Every episode samples fresh values.
# Ranges should BRACKET your measured real-world values, not merely include them.

episode:
  count: 20000
  seed_strategy: per_episode          # reproducibility matters for failure analysis

dynamics:
  payload_mass_kg:      { distribution: uniform,    low: 0.20,  high: 0.85 }
  joint_friction:       { distribution: uniform,    low: 0.01,  high: 0.12 }
  joint_damping:        { distribution: loguniform, low: 0.001, high: 0.05 }
  motor_gain_scale:     { distribution: uniform,    low: 0.85,  high: 1.15 }
  contact_restitution:  { distribution: uniform,    low: 0.00,  high: 0.20 }

sensing:
  camera_pose_jitter_mm:  { distribution: normal,  mean: 0.0, std: 3.0 }
  camera_pose_jitter_deg: { distribution: normal,  mean: 0.0, std: 0.5 }
  depth_noise_std_mm:     { distribution: uniform, low: 1.0,  high: 8.0 }
  dropped_frame_rate:     { distribution: uniform, low: 0.00, high: 0.03 }

visual:
  light_intensity:   { distribution: uniform, low: 0.4, high: 1.6 }
  light_direction:   { distribution: uniform_sphere }
  texture_set:       randomised                # swap materials per episode
  background_images: /datasets/backgrounds     # distractors, not clean voids

timing:
  control_latency_ms: { distribution: uniform, low: 4.0, high: 28.0 }
  jitter_ms:          { distribution: normal,  mean: 0.0, std: 2.5 }

evaluation:
  # Hold out a fixed, UNRANDOMISED scenario set so runs stay comparable.
  holdout_scenarios: 200
  report: [success_rate, time_to_goal, contact_force_peak]

System identification is the complement, and the step most self-taught builders skip. Instead of widening the ranges indefinitely, measure the real machine — step responses, friction, latency, joint limits — and centre the simulator on reality. Randomisation then covers residual uncertainty rather than your ignorance. The rule: identify what you can measure, randomise what you cannot.

Safety and standards literacy

You do not need to be a functional-safety specialist, but you need enough literacy to be credible in an interview and useful in a design review — and you need to lose the software instinct that safety is someone else's compliance problem. Three ideas carry the weight. Functional safety thinking means reasoning about what the machine does when something fails: a sensor stops publishing, a joint stalls, a link drops, the policy outputs nonsense. A well-designed system has a defined safe state and a deterministic path into it, and that path does not run through the learned component. Risk assessment is a structured practice — identify hazards, estimate severity and likelihood, and mitigate in a preferred order: design the hazard out, then guard against it, then warn. Third, know that families of machinery and robot safety standards exist and govern industrial and collaborative deployments. You are not expected to quote clause numbers; you are expected to know that a real deployment involves a documented safety argument, and that "the model handles it" is not one.

Your machine-learning background does not exempt you from this, and believing it does is a red flag to anyone who has worked on a certified system. Learned components are hard to argue about in a safety case precisely because their behaviour is not exhaustively specifiable — hence the simpler, verifiable envelopes around them.

Where the jobs are, by market

First, a caveat on the market sizing quoted everywhere. The humanoid robot market is projected at roughly $4–6 billion in 2026, with projections toward $38–165 billion by 2035. That range comes from secondary reporting, and its width is itself the signal: a forecast whose upper bound is more than four times its lower bound is a statement about uncertainty, not something to schedule a career against. The actionable fact is the other one — physical-AI roles are reported among the most in-demand technical positions for 2026, against a stated talent shortage.

On pay, the reliable published figures are American. The table below is US market data from US job-market aggregates — not an Indian benchmark and not a UK one.

Role (US market data only)	Reported US range	Note
Robotics Software Engineer	Median around $138,000; top roles $160,000–$190,000+	The broadest family and the most common entry point
Perception & Sensing Engineer	Often $190,000–$215,000+	Among the highest-paid specialities in the field
AI/ML Engineer (Physical AI)	$158,000–$182,000+	The premium attaches to people who also know the robot stack

US job-market aggregate data, cited as reported. These figures do not translate to Indian or UK offers and should never anchor a local negotiation.

For India and the UK the honest guidance is structural rather than numerical, because credible per-role robotics salary surveys for those markets are not available to cite — and inventing them would be worse than useless in a negotiation.

In India, employers cluster into research labs, industrial automation and machine-builder suppliers, warehouse robotics, agri-tech, defence and aerospace supply chains, and startups building robot intelligence directly. Two anchors as of July 2026: TCS and NVIDIA operate a physical-AI lab in Bengaluru, covered in our report on the TCS and NVIDIA physical-AI lab; and Bengaluru's Mowito builds AI models for industrial robot arms, profiled in India's bet on robot-arm brains. A large-enterprise lab and a focused startup want different evidence from you.

In the UK and Europe, the same families apply over a strong defence, aerospace and precision-manufacturing supplier base, warehouse automation, agri-tech, and a research-institute layer attached to universities. The scale-up end is real too: Humanoid reached a £1 billion valuation — see Europe's physical-AI unicorn scaling up. And Prometheus, co-led by Jeff Bezos and Stanford professor Vik Bajaj, raised a $12 billion Series B at a $41 billion valuation with roughly 150 employees across San Francisco, London and Zurich, aiming at an "artificial general engineer" for engineering, manufacturing and drug design — our report on the Prometheus raise has the detail. The lesson is not the headline number but the London footprint: capital at that scale builds teams in Europe, and those teams hire.

The interview

Physical-AI interviews test a different surface from LLM-engineering interviews, and predictably enough to prepare for directly.

• Coordinate frames. Getting a detection from a camera frame into a base frame, composing transforms without confusing the direction of the mapping, saying which frame each quantity lives in. The most reliable filter in the field.
• Real-time constraints. What happens when a control loop misses its deadline. The good answer treats the deadline as a contract, says what the system does with a late result, and describes how you would detect the overrun in production.
• Debugging what you cannot print into. A scenario — correct on the bench, wrong in the cell — where the reasoning involves structured logging, record and replay, time synchronisation across sensors, and isolating whether the fault sits in perception, planning, control or the machine.
• A design question with a physical failure mode. Say a mobile robot works near people and its perception model occasionally misses a low obstacle. They want defined safe states, redundancy that does not depend on the learned component, a degradation strategy, and whether you reach for a safety argument or only a better model.

Common pitfalls

1. Buying hardware before you can use it. A robot arm bought in week two becomes an expensive shelf ornament. Finish the simulation project first.
2. Learning ROS 2 by rote instead of by building. Tutorials teach the vocabulary and none of the judgement. You will learn more about QoS in one frustrating afternoon of building than in a fortnight of reading.
3. Ignoring C++ because Python bindings exist. They carry you through prototypes and out of most serious job specifications. Real-time and driver layers are C++, and interviewers ask about memory and lifetimes.
4. Treating the simulator's physics as ground truth. Contact modelling is the weakest part of every simulator. A number produced entirely inside simulation is a hypothesis, not a result.
5. No video in the portfolio. A reviewer who watches a machine work trusts the writeup far faster than one reading claims about it. A sixty-second clip is not optional.
6. Applying only to humanoid startups. Humanoids attract the coverage; industrial automation, warehouse robotics, agri-tech, defence suppliers and research labs employ far more people and are much less competitive to enter.
7. Skipping safety literacy. A strong policy portfolio with no ability to discuss safe states, hazard analysis or degradation reads as someone who has not worked on a real machine.

Your first 90 days in the role

The first month is for the fleet's memory, not your code. Learn to record, replay and inspect data, because the log is the primary debugging instrument and everything else is downstream of it. Read the incident history and the failure reports — they teach you more about real behaviour than the architecture diagram. Find out where the safe states are defined and what triggers them.

The second month is for a visible, unglamorous contribution: a regression test on a recorded bag, a simulation job wired into CI, structured logging around a component that keeps surprising people. That work is under-supplied on robotics teams and earns standing quickly. The third month is for owning something small end to end, including on hardware, with a senior engineer reviewing your safety reasoning rather than only your code. Ask for that review explicitly — nobody minds a new engineer being careful around a machine.

Next steps

Physical AI rewards exactly what a working software engineer already has — the discipline to build systems that keep behaving when conditions are not ideal — and demands habits you have never needed, because your bug now has mass. Pick one of the four job families this fortnight. Start the C++ and transforms work while the decision is fresh. Ship the simulation project by week eighteen even if hardware never materialises. Publish both sides of the sim-to-real gap, including the unflattering number. And benchmark your pay against your own city, not a US aggregate.

Then make the work findable, because robotics proof is badly served by a CV. A success-rate table across fifty randomised episodes, a calibration writeup with residuals and a sixty-second clip of a policy transferring to hardware do not fit on two pages of A4 — yet they are precisely what convinces a hiring manager. Put them on a Verified Builder profile, where teams across India and the UK browse for exactly this kind of evidence. One honest note on timing: the earliest verified profiles carry a Founding Builder badge later cohorts will not receive. There is no countdown and no manufactured scarcity — simply that the first cohort is limited by definition, and being early in a directory hiring managers are starting to browse compounds quietly in your favour.