Robotics Software Engineer Interview Questions

ROS 2 sits on a middleware interface layer, rmw, with DDS implementations underneath. DDS provides peer-to-peer discovery, serialisation and transport, so there is no central master process as in ROS 1: if any one node dies, the others keep talking. That removes a single point of failure and lets nodes start in any order.

Other changes follow from DDS. Every publisher and subscriber has quality of service settings, so you can choose best-effort or reliable delivery per stream. Domains, set by the domain identifier, separate systems that share a network. The client libraries, rclcpp and rclpy, share a common C library, rcl, so behaviour is more consistent between languages. The cost is more configuration: discovery and QoS mismatches are now your problem.

Likely follow-up. What does the rmw layer let you change without touching node code?

Long before the publish, discovery has run: each participant announced itself, the endpoints exchanged topic name, type and QoS, and the publisher matched the subscriber because the profiles were compatible. On publish, rclcpp passes the message through rcl to the rmw implementation, which serialises it, usually to CDR, and hands it to the DDS data writer. DDS sends it over UDP, fragmenting large samples, and with reliable QoS it keeps samples in the writer history until acknowledged.

On the receiving side, the data reader stores the sample in its history queue, which triggers a guard condition in the wait set. The executor wakes, takes the message, deserialises it into the subscriber's type and calls the callback on whichever thread the executor chose. Each step can add latency: serialisation of large messages, network fragmentation and retransmission, and above all waiting for a busy executor.

Likely follow-up. Where would you measure to find which step adds latency?

A lifecycle, or managed, node has explicit states: unconfigured, inactive, active and finalised, with transitions such as configure, activate, deactivate, cleanup and shutdown. You put resource allocation in configure, start publishing and processing in activate, and undo each step in the matching transition. Lifecycle publishers drop messages while the node is inactive.

It is worth it when bring-up order matters. A navigation stack should not start planning before the map and localisation are ready; a driver should not command motors until its configuration has been checked. An external manager moves the nodes through their transitions in a known order and can bring the system to a known inactive state on error, which is far easier to reason about than nodes that each start as soon as their process runs. For a small utility node with no dependencies, the extra states only add code.

First, reuse standard messages where they fit. Joint states, poses, twists and sensor messages are understood by existing tools, so visualisation and recording work for free. For new messages, every time-varying message gets a header with a timestamp and a frame identifier, values use SI units, and frames follow the usual right-handed convention with x forward.

For the gripper I would expose a state topic with position, effort and a status code, and an action for a grasp, because grasping takes time and needs feedback and cancellation. Status codes are constants in the message definition, not free strings. Where an estimate has uncertainty, I include a covariance. I keep messages small and flat, because large nested messages cost serialisation time.

The hard part is change. A message definition is a contract: changing a field breaks recorded bags and every node built against the old type, so I add new messages or fields deliberately, keep interfaces in their own package and review changes to it like an API change.

The common problems are about time and QoS. Nodes must use simulated time, reading the clock topic that the player publishes, otherwise a node compares a recorded stamp from last week with the current wall clock and drops everything as stale. Any node that uses a wall-clock timer or sleeps on system time will behave differently during replay, and playing faster than real time exposes callbacks that were only just keeping up.

QoS matters too. Static transforms and maps are published with transient-local durability; if the recording or playback does not preserve that, late-starting nodes never receive them. Replay is also not deterministic with live processing nodes: executor scheduling and thread timing differ each run, so the outputs vary slightly. For regression tests I either compare outputs with tolerances or run the algorithm directly on the recorded messages without the middleware, which is repeatable.

Default discovery uses multicast, which many Wi-Fi access points filter or rate-limit, and which corporate networks often block between subnets. First I check the basics: same domain identifier, no localhost-only setting, the firewall allowing the UDP port range, and the right network interface chosen when the robot has several.

If multicast is the problem, I configure discovery so it does not depend on it: a list of unicast peers, or a discovery server that participants register with.

Even with discovery fixed, Wi-Fi changes the design. Reliable QoS on a large topic over a lossy link causes retransmission storms and latency, so I send only compressed or reduced data off the robot, use best-effort for telemetry, and never place anything safety-related on the wireless link. Ideally a bridge node exposes a small, defined set of topics to the outside.

Likely follow-up. What would you put on the robot side of the link and what on the laptop?

An executor owns a wait set for the subscriptions, timers, services and clients of the nodes added to it. When spin is called, it waits until something is ready, picks a ready entity and runs its callback, then waits again. A single-threaded executor runs one callback at a time, in the spinning thread, so callbacks never overlap and need no locking between them. A slow callback delays everything else in that executor.

A multi-threaded executor runs callbacks on a pool of threads, so independent callbacks can run in parallel. Which callbacks may overlap is controlled by callback groups. The parallelism is not free: shared state now needs protection, and the order of callbacks is less predictable. For a control loop with a strict period I prefer a dedicated real-time thread outside the executor, and use the executor only for the non-critical parts.

A callback group sets the concurrency rule for the callbacks in it. In a mutually exclusive group, at most one callback runs at a time; in a reentrant group, callbacks may run in parallel, including the same callback more than once. By default every callback is in the node's mutually exclusive default group.

The deadlock: a timer callback sends a service request and then blocks waiting for the response. The response is delivered by the client's callback, which needs the executor. With a single-threaded executor the only thread is the one blocked waiting, so the response is never processed. With a multi-threaded executor the same happens if the client is in the same mutually exclusive group as the timer.

Fixes: send the request asynchronously and handle the result in a callback, without blocking; or put the client in a separate group and use a multi-threaded executor. I prefer the asynchronous style, because blocking in a callback also stalls every other callback in that group.

Reliability is best-effort or reliable, meaning whether lost samples are retransmitted. Durability is volatile or transient-local, meaning whether late-joining subscribers receive samples published before they joined. History and depth set how many samples are kept. Deadline sets the expected maximum period between samples, liveliness detects a writer that has gone away, and lifespan discards samples that are too old.

For a lidar scan, best-effort with keep-last of a small depth: a late scan is useless, and retransmission only adds delay. For a static map, reliable and transient-local with depth one, so a planner started later still gets it. For a stop command, reliable with keep-last, plus a deadline so the receiver notices when the sender goes quiet and stops on its own.

Compatibility is checked per pair: a reliable subscriber does not match a best-effort publisher, and a transient-local subscriber does not match a volatile publisher. A real emergency stop should not rely on any of this; it belongs in hardware.

A ROS timer is just another callback in the executor. If another callback in the same executor is running, the timer waits until it finishes. Late wake-ups also come from the operating system: a normal-priority thread competes with everything else, and without a real-time kernel and settings the wake-up latency has a long tail. If the node uses simulated time, the timer also depends on how regularly the clock topic arrives.

For a steady rate I take the loop out of the executor. A dedicated thread with a real-time priority sleeps until an absolute deadline with clock_nanosleep on the monotonic clock, then adds the period to the deadline. Using an absolute deadline stops errors from accumulating, which a relative sleep does. The loop reads its inputs from lock-free buffers filled by subscriber callbacks and publishes through a real-time-safe path. I measure the period jitter and record the worst case over long runs, not only the mean.

tf2 keeps a tree of frames in which each frame has exactly one parent. Each edge has a buffer of time-stamped transforms covering a recent window, ten seconds by default. Static transforms, such as sensor mounts, are published once on a separate topic with transient-local durability and kept without a time limit.

For a lookup between two frames at time t, tf2 finds the path through their common ancestor, and for each edge on the path it interpolates between the two stored samples around t: linear interpolation for translation and spherical interpolation for rotation. It then composes the edge transforms. If t lies outside the stored range of any edge, the lookup fails with an extrapolation error rather than guessing. That is why the time of a lookup matters: asking for the transform at the measurement time gives the right answer for a sensor reading, while asking for the latest transform gives a slightly wrong one on a moving robot.

The node asked for a transform at a time later than the newest sample on some edge of the path. Typically a sensor message has arrived stamped at time t, but the odometry or localisation transform for t has not arrived yet, because it is published at a lower rate or with delay. It can also mean the clocks of two computers disagree, or one node uses simulated time and another does not.

The right fixes wait for the data instead of hiding the error. Look up with a short timeout, or use a message filter that holds sensor messages until the transform for their stamp is available. Check that the transform publishers run fast enough and that clocks are synchronised. The wrong fix, which I would flag in review, is asking for the latest available transform for every lookup: it removes the error message but pairs the sensor data with the wrong robot pose, which smears obstacles when the robot turns.

RAII ties the lifetime of a resource to the lifetime of an object: the constructor acquires it and the destructor releases it, so the release happens on every exit path, including exceptions and early returns.

For a motor controller on a serial port, a class opens and configures the port in its constructor, throwing if it fails, and closes it in its destructor. I would make it non-copyable, because two objects closing the same descriptor is a bug, and movable if ownership needs to be transferred. For a motor, release should also mean safe: the destructor sends a disable command before closing, and the class enables the motor only through an explicit call.

The limit is that destructors do not run if the process is killed or crashes. So the motor controller itself must also stop on a command timeout. RAII covers clean shutdown; the hardware watchdog covers everything else.

Likely follow-up. Why should a destructor not throw, and how do you report a failed disable command?

When publisher and subscriber are in the same process and intra-process communication is enabled, publishing a unique pointer hands ownership of the message to the middleware. If there is exactly one subscriber that takes ownership, the message can be moved to it with no copy at all. If several subscribers need it, or some take a shared pointer to a const message, the middleware shares one copy where it can and copies only for subscribers that need ownership.

So for large data I publish with a unique pointer and write subscribers that take a const shared pointer when they only read. The trap is publishing by reference or holding on to the message after publishing it: with a reference the library must copy, and using a moved-from unique pointer is a bug. Inter-process subscribers still receive a serialised copy, so a single remote subscriber, such as a recording tool, brings back the serialisation cost.

Allocation in a loop can take the allocator lock or page in fresh memory, which gives unbounded delay. I remove it in several ways. Use fixed-size Eigen types, such as a six-by-six matrix, which live on the stack. For dynamic sizes, allocate once at configuration and reuse, and write expressions so Eigen evaluates into existing storage instead of creating temporaries. Reserve vectors to their maximum size up front, and do not let them grow.

Watch the hidden allocators: std::string building for log messages, std::function with large captures, exceptions, and ROS messages with unbounded sequences. Then prove it rather than hope: run the loop under a test that hooks malloc and fails if it is called after start-up, or use a tool that flags allocations in the real-time thread. Lock memory with mlockall and touch the stack at start-up so page faults do not appear later.

The control thread only ever wants the newest plan, not a queue of them, and it must never block. A queue would deliver stale plans in order, and a plain mutex could make the control thread wait while the planner copies a large plan.

I would use a triple buffer: three slots, one owned by the writer, one by the reader and one spare, with an atomic index exchanged on each publish and each read. The writer fills its slot, then swaps it with the spare atomically; the reader swaps the spare in if it is newer. Neither side ever waits, and the reader always sees a complete plan. For small data, a sequence lock is simpler: the writer increments a counter before and after writing, and the reader retries if the counter changed or is odd.

PREEMPT_RT makes almost all of the kernel pre-emptible: interrupt handlers run as threads with priorities, most spinlocks become sleeping locks with priority inheritance, and long non-pre-emptible sections are broken up. The result is a bounded, much shorter worst-case wake-up latency for a high-priority user thread.

The kernel alone is not enough. The loop thread needs a real-time policy, usually SCHED_FIFO, with a priority above the interrupt threads that do not matter to it and below those it depends on, such as the network card for EtherCAT. Memory must be locked and pre-faulted. I isolate a core from the general scheduler, move other interrupts off it, and fix the CPU frequency and disable deep idle states, because waking from them adds latency. Then I measure with a cyclic latency test under heavy load, CPU, network and disk, for hours, and look at the maximum. A system is only real-time with respect to the worst case you have measured and understood.

Several recur. Storing time or position in single precision: a float has about seven significant digits, so a map in a projected coordinate system with values of hundreds of kilometres has only decimetre resolution, and timestamps in seconds since 1970 lose sub-second detail. I use doubles and local origins.

Domain errors in inverse trigonometry: a dot product of unit vectors can come out slightly above one, and acos then returns NaN, so I clamp first. I use atan2 rather than atan of a ratio, to keep the quadrant and avoid division by zero.

NaN propagation: one NaN from a bad sensor reading flows through a filter and poisons every later estimate, so inputs are checked at the boundary. Comparing floats with equality, and subtracting nearly equal numbers, give fragile results. Finally, angle arithmetic must wrap: the difference between 179 and minus 179 degrees is two degrees, not 358.

With the convention I use, T_A_B is the pose of frame B expressed in frame A, and it maps a point written in B into A: p_A equals T_A_B times p_B. T_B_A is its inverse. Composition then chains naturally: T_A_C equals T_A_B times T_B_C, with matching inner letters.

To avoid mistakes, I put both frames in every variable name, such as world_T_base or T_world_base, and check that inner frames cancel whenever I multiply. Functions take and return named frame types where the language makes that cheap. I write down the convention in the project, because some libraries name transforms the other way round. And I test with numbers I can check by hand: a sensor mounted half a metre forward of the base, robot rotated ninety degrees, and confirm the result points where a person would expect.

They give two different guarantees. The odom frame is continuous: the pose of the base in odom, from wheel odometry and an IMU, changes smoothly with no jumps, but it drifts without bound. The map frame is globally accurate: the pose of the base in map stays consistent with the map over time, but it can jump when localisation corrects itself.

Different consumers need different guarantees. A local controller or obstacle tracker needs smooth motion, so it works in odom; a jump would make an obstacle seem to leap. A global planner and anything referring to places on the map work in map. Because each frame may have only one parent, localisation does not publish map to base directly; it computes map to base, subtracts the current odom to base, and publishes the correction as map to odom. That edge absorbs the jumps and the drift, while odom to base stays smooth.

A rotation matrix has nine numbers with orthonormality constraints. It composes by multiplication and rotates vectors directly, but drifts from orthonormal after many products and is bulky to store and interpolate.

Euler angles use three numbers and are easy for people to read, so I use them for configuration and display. But there are twelve possible orderings, they have singularities, and adding or interpolating them is not meaningful.

Axis-angle, or a rotation vector, is minimal and natural for small rotations, angular velocity and errors in an estimator, but composing two of them needs a conversion.

Quaternions have four numbers and one unit-norm constraint, no singularity, cheap composition, easy renormalisation and smooth interpolation, so they are the usual choice for storage and computation. Their pitfalls are the double cover, where q and minus q are the same rotation, and the order of components, which differs between libraries.

Likely follow-up. Which representation would you put in an estimator state, and how would you express its error?

SO(3) is the group of 3D rotations and SE(3) the group of rigid transforms, rotation plus translation. Neither is a vector space: you cannot add two rotations, and a rotation parameterised by four or nine numbers has constraints. But near any element the group looks like a vector space of three or six dimensions, its tangent space, with the exponential map going from a small vector to a group element and the logarithm going back.

Estimators use this to express uncertainty and corrections. The state stores the full rotation, while the error and covariance live in the three-dimensional tangent space. An update computes a small correction vector and applies it with the exponential, so the result is always a valid rotation with no need to renormalise and no redundant parameter in the covariance. Optimisers in pose graph SLAM and calibration do the same. The detail to state clearly in an interview is whether the perturbation is applied on the left, in the world frame, or on the right, in the body frame, because Jacobians differ.

For a camera on an arm, this is hand-eye calibration. Move the arm to many poses while the camera observes a fixed target; for each pair of poses, the arm motion A and the camera motion B satisfy A X equals X B, where X is the unknown camera-to-flange transform. Solve for rotation first, then translation, then refine all of it with non-linear least squares on reprojection error. Poses must include rotations about different axes, or the problem is degenerate.

For a camera and an IMU, move the rig in front of a target with rich rotation and acceleration, and estimate the extrinsic rotation, translation and time offset together, typically with a continuous-time trajectory fitted to both sensors. The time offset matters as much as the transform.

A gyroscope measures angular velocity in the body frame. Over a step dt, the rotation increment is the exponential of omega times dt, which as a quaternion is cos of half the angle as the scalar part and the unit axis times sine of half the angle as the vector part, where the angle is the norm of omega times dt. Because the rate is in the body frame, the increment multiplies on the right: q at k plus one equals q at k times the increment.

Details that matter: subtract the estimated gyro bias first; for small angles avoid dividing by a near-zero norm by using the first-order form; normalise the quaternion now and then; and if the rate changes within the step, use the mean of consecutive samples or a higher-order method. Even then, integrated orientation drifts because of bias and noise, so roll and pitch are corrected with the accelerometer's gravity direction and yaw needs a magnetometer, a heading sensor or visual features.

The Jacobian maps joint velocities to the end-effector twist: the linear and angular velocity of the tool. Each column is the motion the tool gets from moving one joint at unit speed with the others still. For a revolute joint, the angular part of the column is the joint axis and the linear part is the cross product of that axis with the vector from the joint to the tool.

It tells you several things. Its transpose maps a force and torque at the tool to the joint torques that produce it, which is how you do force control and gravity compensation of a payload. Its rank tells you whether the tool can move in every direction: where the rank drops, the arm is at a singularity. Its condition number, or a manipulability measure, tells you how close you are to one, which is useful for choosing poses and for warning before a motion would demand huge joint speeds.

Iteratively: compute the pose error between the current and target tool pose, expressed as a six-dimensional twist, and solve for the joint step that would remove it using the Jacobian, then repeat until the error is small. Plain pseudo-inverse steps blow up near a singularity because tiny singular values become huge gains.

Damped least squares fixes that: the step is J-transpose times the inverse of J times J-transpose plus lambda squared times the identity, all times the error. The damping trades a little accuracy for bounded joint motion near singularities, and I raise lambda when the manipulability is low. I also clamp the step size, respect joint limits, and restart from several seeds because the problem has multiple solutions and local minima.

For common six-joint arms with a spherical wrist, an analytic solution exists and is faster and returns every solution branch, so I use it where it applies and keep the numerical solver for general chains.

On a typical six-joint industrial arm, the wrist singularity occurs when the fourth and sixth joint axes line up, which happens when the fifth joint is at zero. Rotating joint four one way and joint six the other then produces the same tool motion, so one degree of freedom is lost and the arm cannot rotate the tool about one direction.

In practice, a straight-line Cartesian move that passes near this pose asks joints four and six to spin very fast in opposite directions, hitting velocity limits or causing a protective stop.

Remedies: plan in joint space when the exact Cartesian path does not matter; adjust the tool orientation slightly so the path avoids the singular region; use damped least squares so speeds stay bounded at the cost of path accuracy; or use a redundant arm and the extra joint to stay away.

An arm is redundant for a task when it has more joints than the task needs, such as a seven-joint arm placing a tool in six dimensions. There is then a set of joint motions, the null space of the Jacobian, that move the joints without moving the tool.

You can spend that freedom on a secondary objective. The joint velocity is the pseudo-inverse solution for the tool motion, plus the null-space projector, the identity minus J-pseudo-inverse times J, applied to the gradient of a secondary cost. Typical costs: keep joints away from their limits, keep manipulability high, keep the elbow away from an obstacle or a person, or stay close to a comfortable posture. Because of the projection, the secondary task never disturbs the primary one, at least to first order. With several priorities, the same idea is applied recursively, or the problem is set up as a quadratic programme with priorities and inequality constraints, which handles joint limits more cleanly.

The bicycle model lumps each axle into one wheel. With the rear axle as reference point, the state is x, y and heading, and the inputs are speed v and steering angle delta. Then x-dot is v cos(theta), y-dot is v sin(theta), and theta-dot is v tan(delta) divided by the wheelbase.

The robot is non-holonomic: it cannot move sideways, because the wheels do not slip laterally, and its turning radius has a minimum set by the wheelbase and the steering limit. So a path with a sharp corner or a sideways step cannot be followed exactly, however good the controller. The planner must produce paths of bounded curvature, using primitives such as Dubins curves for forward motion only, or Reeds–Shepp curves when reversing is allowed, or a state lattice or hybrid search that expands only feasible motions.

The joint-space equation is M(q) times q-double-dot plus C(q, q-dot) times q-dot plus g(q) equals tau, plus friction and external torques. M is the symmetric positive-definite mass matrix, C collects Coriolis and centrifugal effects, and g is gravity.

It appears in several places. Gravity compensation adds g(q) to the command so a position loop does not have to fight the weight of the arm, which reduces steady-state error and the integral action needed. Computed-torque control cancels the whole model and imposes linear error dynamics, which works well only when the model is accurate. Feedforward for a trajectory computes the torque the desired motion needs, leaving feedback for the error. Collision detection compares measured torque with the model torque and flags a large residual.

For the usual layout, with rollers at 45 degrees forming an X when viewed from above, wheel radius r and half wheelbase and half track lx and ly, the inverse kinematics for body velocities vx, vy and yaw rate omega are:

k = lx + ly
front_left  = (vx - vy - k * omega) / r
front_right = (vx + vy + k * omega) / r
rear_left   = (vx + vy - k * omega) / r
rear_right  = (vx - vy + k * omega) / r

I would check the signs on the real robot, because they depend on how the rollers are mounted and on each motor's direction: command pure forward, pure sideways and pure rotation and watch the base. After computing the wheel speeds, if any exceeds the motor limit, I scale all four by the same factor so the direction of motion is kept rather than clipping one wheel. Mecanum wheels slip, especially sideways, so the inverse of this mapping gives poor odometry, and I would fuse an IMU or other source for heading.

Start safe: low gains, limited current and speed, the joint away from its end stops, and an emergency stop in reach. If the joint has an inner velocity or current loop, tune that first, because the outer loop assumes it is fast and well damped.

Then raise the proportional gain with small step commands until the response is fast with modest overshoot, add derivative or velocity feedback for damping, and add integral last, only as much as needed to remove offset. Use step sizes small enough not to saturate, or you are tuning the saturation rather than the loop.

Measure rather than eyeball: log command, position, velocity and output at the loop rate. Better still, run a frequency sweep to measure bandwidth and phase margin. Test at several positions and payloads, because inertia and gravity change across the workspace, and use gain scheduling or gravity feedforward if one set of gains does not fit all.

Feedforward computes the actuator command from the desired motion and a model, before any error appears. Feedback only acts on error, so a pure feedback controller tracking a moving reference must always lag behind it to produce any command at all.

For a joint following a trajectory, the feedforward terms are typically velocity times a viscous-friction or back-EMF gain, acceleration times inertia, a gravity term from the model and a friction offset in the direction of motion. With good feedforward, the feedback loop only corrects the model error, so tracking error drops sharply and the feedback gains can stay modest, which helps stability and noise.

Two conditions apply. The trajectory must be smooth enough to differentiate, with continuous velocity and bounded acceleration, otherwise feedforward produces spikes. And the model needs identifying on the real machine; a wrong inertia or friction value makes things worse, so I add terms one at a time and check the tracking error each time.

A digital controller sees the plant only at sample instants, and its output is held between samples. That hold behaves like a delay of about half a sample, and computation and communication add more. Delay costs phase at every frequency, and the cost grows with frequency, so it directly reduces the phase margin at the crossover frequency and limits the achievable bandwidth.

A common guideline is to sample ten to twenty times faster than the closed-loop bandwidth. Faster sampling helps up to the point where derivative estimates become noisy, since the change in the measurement per sample becomes comparable to the noise. Inputs must be filtered before sampling to avoid aliasing, and that filter adds its own phase lag.

Jitter matters too: if the period varies, a controller that assumes a fixed dt computes wrong derivatives and integrals. I either keep the period steady with a real-time thread or use the measured dt, and I count the total loop delay, from sensor to actuator, when I analyse stability.

MPC solves an optimisation at every control step: using a model, it predicts the state over a finite horizon, chooses the input sequence that minimises a cost, such as tracking error plus control effort, subject to constraints, applies only the first input, then repeats at the next step with fresh measurements. With a linear model and quadratic cost, each step is a quadratic programme.

I would use it when constraints and preview matter: actuator limits, speed and acceleration limits, obstacle clearances, and a reference known in advance, as with a vehicle following a path through a bend or a legged robot planning foot forces. PID handles one loop well but cannot reason about constraints or anticipate the future.

The costs are a model that must be accurate enough, a solver that must finish within the period every time, and more ways to fail. In practice I warm-start the solver from the previous solution, cap its iterations, check feasibility, and keep a simple fallback controller if the solver fails or overruns.

A good first choice is pure pursuit. Pick a point on the path a lookahead distance ahead, and steer along the circular arc that passes through it; the curvature is two times the lateral offset of that point divided by the lookahead squared. The lookahead is the main tuning knob: short follows tightly but oscillates, long is smooth but cuts corners. Scaling it with speed works well.

For a car-like robot, the Stanley controller combines heading error with cross-track error measured at the front axle, and tends to track more tightly at low speed. For tight spaces or high speeds, MPC handles curvature and acceleration limits explicitly.

Whatever the law, the practical parts matter as much. Slow down before sharp curves and near obstacles, limit acceleration so the wheels do not slip, handle the end of the path so the robot stops at the goal instead of circling it, and detect when the robot has drifted too far from the path and needs a replan.

For a loop that is close to linear, I measure the open-loop frequency response, injecting a sine sweep or a pseudo-random signal at the controller output and measuring the response, then read the gain margin and phase margin from it. As a rule of thumb I want a phase margin of at least about 45 degrees and a gain margin of at least about 6 dB.

Margins must hold across operating conditions: different arm poses, payloads, temperatures and battery voltages change the plant, so I check the worst cases. Resonances in gearboxes and belts can create a second crossover, which needs a notch filter or lower bandwidth.

For non-linear systems, such as a robot with saturation or a learned policy, linear margins are only part of the picture. I use simulation across the range, Lyapunov arguments where they can be made, and limit checking at run time, so that if behaviour leaves the region where stability was shown, a supervisor takes over.

For a linear system with Gaussian process and measurement noise that is white and uncorrelated, and a Gaussian initial state, the Kalman filter computes the exact posterior distribution of the state, which is Gaussian. Its mean is then the minimum mean-squared-error estimate. If the noise is not Gaussian but the system is still linear and the second-order statistics are right, it is still the best linear unbiased estimator.

Each assumption can fail on a robot. Models are non-linear, so we linearise. Noise is often correlated in time, such as a GPS error that wanders slowly, or bias, which must be modelled as an extra state. Some errors are not Gaussian at all, such as wheel slip or a lidar return from the wrong surface, which need outlier gating. And the noise covariances are rarely known exactly. So the filter is optimal for its model, and most of the engineering is making the model close enough.

I would run two estimators, matching the odom and map frames. The first fuses wheel odometry and the IMU into a continuous estimate of velocity and pose in the odom frame, with no GNSS, so it never jumps. It uses wheel speeds as velocity measurements and the gyro for yaw rate, with the IMU accelerometer helping roll and pitch on slopes. The second adds GNSS positions to estimate the pose in the map frame and publishes map to odom.

Details matter. GNSS gives positions in latitude and longitude, so I convert to a local metric frame with a fixed origin. The GNSS antenna is not at the base origin, so the lever arm must be included, especially when the robot turns. Heading from GNSS is only observable when moving. Covariances from the receiver are often optimistic, so I inflate them and use innovation gating to reject multipath jumps near buildings. Finally I check that wheel velocity covariance increases when slip is likely, such as during sharp turns or on grass.

Several options exist, chosen by how late and how often. If the delay is small and constant, the simplest correct method is to keep a short history of states, covariances and inputs. When the late measurement arrives, rewind to the state at its timestamp, apply the update, and re-run the predictions and later updates up to the present. The cost is the re-propagation, which is fine for small states and short delays.

Alternatively, run the filter deliberately behind real time by the maximum expected delay, so all measurements arrive in order, and predict forward from the delayed estimate to produce the current output. This costs latency in the delayed estimate but is simple and exact.

For large states, such as visual-inertial odometry, the filter can keep a clone of the state at the time an image was taken, and apply the update to that clone when processing finishes, which correctly correlates past and present. Whatever the method, I first make sure the timestamps themselves are right, because a wrong stamp hurts more than a late one.

The innovation is the difference between a measurement and the filter's prediction of it. Its covariance S combines the predicted state uncertainty, projected into measurement space, and the measurement noise. Gating rejects a measurement whose innovation is too unlikely under that covariance.

The Mahalanobis distance, y-transpose times S-inverse times y, scales the error by its expected spread in each direction, so it accounts for the fact that a one-metre error may be normal along a corridor but impossible across it. For a correct filter it follows a chi-squared distribution with as many degrees of freedom as the measurement has dimensions, so the threshold comes from a table: about 9.21 for two dimensions at 99 per cent.

The danger is a filter that has become overconfident: its S is too small, it rejects every correct measurement, and it never recovers. So I count consecutive rejections and, beyond a limit, inflate the covariance or reinitialise, and I log rejection rates as a health metric.

A state is observable if the measurements over time, together with the inputs, determine it uniquely. If not, the filter cannot correct it, its uncertainty should grow, and a linearised filter that wrongly treats it as observable becomes overconfident and inconsistent.

Examples. In visual-inertial odometry, global position and the yaw about gravity are unobservable, because rotating or shifting the whole trajectory changes no measurement; only roll and pitch are pinned by gravity. In monocular vision alone, absolute scale is unobservable. IMU biases are observable only with enough motion: an accelerometer bias cannot be separated from tilt while the robot sits still. Heading from GNSS positions alone is unobservable when the robot is stationary. A wheel-odometry-only robot cannot observe its absolute pose at all.

Practical consequences: do not let a filter shrink the covariance of an unobservable state through linearisation errors, use first-estimate Jacobians or a formulation that preserves the correct unobservable directions, and plan motion to excite the states you need, as calibration routines do.

After a few updates, most particles end up with negligible weight and one or a few carry almost all of it. The filter then represents the belief with very few effective samples and wastes computation on the rest. The effective sample size, one over the sum of squared normalised weights, measures this.

Resampling fixes it by drawing a new set in proportion to the weights. I resample only when the effective sample size drops below about half the particle count, because resampling every step throws away diversity. Systematic, low-variance resampling is preferred: it is linear in time and adds less randomness than independent draws.

Resampling causes the opposite problem, impoverishment: many identical copies of a few particles. Process noise in the motion model spreads them out again, and if the sensor model is very sharp, I widen it a little so that small pose errors do not zero the weights. To recover from a wrong convergence, such as a kidnapped robot, a small fraction of random particles is injected when the measurement likelihood drops.

SLAM estimates the robot trajectory and a map at the same time, from sensor data and odometry, when neither is known in advance. It is hard because pose errors corrupt the map and map errors corrupt the pose, and because data association, deciding which observation matches which part of the map, is uncertain.

Filter-based SLAM, such as an EKF over the robot pose and landmark positions, keeps only the current pose and marginalises out the past. The covariance becomes dense, the cost grows quadratically with landmarks, and linearisation errors become permanent once past poses are gone.

Graph-based SLAM keeps the trajectory as a graph of poses, with edges from odometry, scan matching and loop closures, and optimises the whole graph as non-linear least squares. The problem is sparse, so it scales well, and relinearising past poses keeps it accurate.

Nodes are robot poses at selected keyframes. Each edge is a measured relative transform between two poses, with an information matrix, the inverse covariance, saying how much to trust it: odometry edges between consecutive poses, and loop-closure edges between a pose and an earlier one when the robot recognises a place.

Optimisation minimises the sum of squared errors, each the difference between the measured relative transform and the one implied by the current pose estimates, weighted by the information matrix. It is non-linear because of rotations, so it uses Gauss–Newton or Levenberg–Marquardt with updates in the tangent space. Each iteration solves a sparse linear system, fast with sparse Cholesky factorisation and a good variable ordering. One pose must be fixed, because the whole graph could otherwise move freely.

The practical risk is a false loop closure, which bends the whole map. Loss functions that grow slowly for large errors, such as Huber or Cauchy, reduce the pull of large residuals, and switchable constraints or consistency checks between closures reject the bad ones.

A point at X, Y, Z in the camera frame, with Z along the optical axis, projects to normalised coordinates X over Z and Y over Z. The intrinsic matrix maps those to pixels: u equals fx times x plus cx, v equals fy times y plus cy, where fx and fy are focal lengths in pixels and cx and cy the principal point. Real lenses add distortion, usually modelled with radial terms and two tangential terms, or with a fisheye model for wide lenses.

Intrinsic calibration estimates these parameters from many images of a known target, such as a checkerboard, seen at different positions, distances and tilts that cover the whole image, especially the corners where distortion is largest. The solver minimises reprojection error over intrinsics and the target poses. I judge the result by the reprojection error, which should be a fraction of a pixel, by its uniformity across the image, and by checking it on images not used in the fit. A calibration is tied to focus and zoom settings, so those must be locked.

Iterative closest point aligns a source point cloud to a target. Each iteration pairs every source point with its nearest target point, rejects pairs that are too far apart, computes the rigid transform that best aligns the pairs in a least-squares sense, applies it, and repeats until the change is small. Point-to-plane ICP minimises distance along the target surface normal instead of point distance, which converges much faster on structured scenes because points can slide along surfaces.

It fails in predictable ways. It is a local method: with a poor initial guess, nearest neighbours are wrong and it converges to a wrong alignment, so it needs odometry or a global method to start from. In geometrically degenerate scenes, such as a long featureless corridor or a flat open field, the alignment along the corridor or in the plane is unconstrained and drifts. Moving objects and partial overlap pull it off. I check the condition of the final system, the inlier ratio and the residual, and report a covariance so the fusion layer can weight it.

A typical pipeline runs within the sensor period. First, correct motion distortion, then transform into the base frame at the scan time. Crop to the region of interest and remove points on the robot body. Downsample with a voxel grid to bound the cost of later steps.

Next, separate the ground. On flat floors, fitting a plane with RANSAC works; on uneven terrain, a local method, such as comparing the slope between consecutive points in each laser ring or fitting small patches, avoids removing ramps or keeping kerbs. Then cluster the non-ground points by Euclidean distance, using a kd-tree or the sensor's own range image to find neighbours fast, and discard clusters too small to be real.

Each cluster becomes an obstacle with a bounding shape and, when tracked over time, a velocity. I watch for dust, rain and glass, which produce false or missing returns, and I test on recorded data from those conditions.

With ground truth from motion capture, a survey-grade reference or a carefully built map, I compute two error measures. Absolute trajectory error aligns the estimated trajectory with ground truth, using a rigid transform or also scale for monocular systems, and reports the root mean square of position differences, which measures global consistency. Relative pose error compares motion over fixed intervals of distance or time, which measures drift and is fairer for odometry.

Numbers on public datasets are a start, but product questions decide. How often does localisation fail or need a human, per hour or per kilometre? How quickly does it recover? How does accuracy change with crowds, rearranged furniture, lighting or season? What are the CPU and memory costs on the target computer? I build a regression suite of recorded runs from real sites, including the difficult ones, run it on every change and track these metrics over time, so a change that improves one site but breaks another is caught before release.

The configuration space has one dimension for each degree of freedom: x, y and heading for a mobile base, or the joint angles for an arm. A single point in it describes the whole robot. Obstacles in the workspace map to forbidden regions in configuration space, the configurations where any part of the robot would collide.

Planning there turns a problem about a shaped body moving among shapes into a problem about a point moving among regions, which is what search and sampling algorithms need. For a circular mobile robot, the configuration-space obstacle is the workspace obstacle inflated by the robot radius, which is exactly what costmap inflation does. For an arm, the configuration-space obstacles have no simple closed form, so planners test configurations one at a time with a collision checker. That is why sampling-based planners dominate for arms, and why collision checking is usually the main cost of planning.

An admissible heuristic never overestimates the true cost to the goal. A consistent one also satisfies the triangle inequality: the estimate at a node is no more than the edge cost to a neighbour plus the estimate at that neighbour. Consistency implies admissibility.

With an admissible heuristic, A* returns an optimal path. With a consistent one, each node is expanded at most once, so a closed set can be used without reopening nodes. On an eight-connected grid with diagonal cost of root two, the octile distance is consistent; Euclidean distance is also consistent but expands more nodes because it is weaker.

An overestimating heuristic can return a suboptimal path, but it often expands far fewer nodes. Weighted A*, multiplying the heuristic by a factor greater than one, uses this deliberately and guarantees the cost is at most that factor times the optimum. That is a sensible trade-off on a large map where speed matters more than the last few per cent of path length.

RRT grows a tree from the start. Each iteration samples a random configuration, often biased to the goal a small fraction of the time, finds the nearest tree node, and steers a short step from it towards the sample. If the step is collision-free, it becomes a new node. When a node gets close enough to the goal, the path is read back through the parents. The random sampling pulls the tree into unexplored space quickly, which makes it effective in high dimensions.

RRT finds a feasible path but not a good one, and the path quality does not improve with time. RRT* adds two steps: a new node chooses the best parent among nearby nodes, and nearby nodes are rewired through the new node when that shortens their path. The solution then converges towards the optimum as samples increase, at a higher cost per iteration.

RRT-Connect grows trees from both the start and the goal and repeatedly tries to connect them greedily, which is very fast for single queries with arms. In all cases I follow with shortcutting and smoothing.

A path is a sequence of configurations; a trajectory adds timing, giving position, velocity and acceleration at each instant. Two steps are usually needed. First, make the path smooth enough, since the corners of a piecewise-linear path demand infinite acceleration if followed at speed. Options are blending corners with arcs or splines, or fitting a spline through the waypoints while checking the result is still collision-free.

Second, time-parameterise it within the limits. For a single axis, a trapezoidal velocity profile respects velocity and acceleration limits; an S-curve also limits jerk, which reduces vibration and wear. For a path through many joints, time-optimal path parameterisation finds the fastest speed along the path at each point that keeps every joint within its velocity and acceleration limits, by treating the speed along the path as the single variable.

Trajectory optimisation represents the whole trajectory as variables, such as waypoints or spline coefficients, and minimises a cost, typically smoothness plus a collision penalty from a signed distance field, subject to constraints such as joint limits, dynamics and the start and goal. It uses gradient-based solvers, often sequential convex or quadratic programmes.

Its strengths are smooth, high-quality motions, natural handling of costs like distance from people or effort, and constraints on dynamics. Its weakness is that it is local: it can get stuck in a minimum where the trajectory passes through an obstacle, or fail to find the corridor on the other side of an obstacle, so it depends on its initial guess and gives no completeness guarantee.

Sampling-based planners are the opposite: they find a feasible path in cluttered, high-dimensional spaces, but the path is rough. The common combination is to use a sampling planner for a feasible path and initialise the optimiser from it, or to run the optimiser from several seeds and keep the best result.

Static obstacle avoidance is not enough, because a person who is two metres away and walking towards the robot is closer in time than a wall one metre to the side. I would track people over time to estimate their velocity, predict their motion over a short horizon, and score candidate motions against those predictions, for example with time to collision or velocity obstacles, rather than against the current snapshot only.

Behaviour matters as much as geometry. The robot should slow down near people, keep a larger margin than for objects, avoid cutting directly in front of someone, and make its intent readable by moving smoothly instead of hesitating. Predictions are uncertain, so I prefer motions that leave options open and stop when uncertainty is high.

The safety layer stays separate. Speed and separation monitoring with a safety-rated sensor limits speed by distance regardless of what the planner decides. And I test with recorded crowds and scripted scenarios in simulation, including people who stop suddenly or step out from behind shelves.

As a pyramid. At the base, many fast unit tests for pure code: geometry, kinematics, filter steps and planners, with hand-checked cases, property tests such as transforming and then inverse-transforming a point, and edge cases such as angles at plus and minus pi. These run in seconds on every commit, without any middleware.

Above that, integration tests that launch a few nodes and check their interaction: topics appear, messages flow, a service returns the right answer, and a node handles missing inputs. Then simulation tests that run whole behaviours, such as docking or picking, across many scenarios and record pass rates. Then log replay tests, which feed recorded real data through perception and estimation and compare with stored results. Hardware-in-the-loop tests run the real controller against simulated or bench hardware, and field tests are the final, most expensive layer.

Simulation is weak at contact, friction, deformable objects, sensor noise and failure modes, and at timing: a simulator usually runs everything synchronously and on time, while the real robot has latency, jitter and dropped messages. A policy or controller tuned only in simulation can exploit simulator errors.

To manage the gap, I identify key parameters on the real robot, such as masses, friction, motor limits and sensor delays, and put them into the simulator. I add realistic noise, latency and drop-outs to simulated sensors. I randomise uncertain parameters across runs so the software works over a range rather than at one point. I keep the same launch files and software on both, with only the hardware interface swapped. Most importantly, I compare simulation and reality on the same scenario regularly, with recorded data, and treat a growing difference as a bug. Simulation decides what is worth trying on the robot; it does not replace that trial.

Flaky tests in robotics usually come from time, threads and randomness. I remove each source deliberately. Algorithms take time as an input rather than reading the system clock, so a test can supply exact times. Randomised algorithms take a seeded generator as a parameter. Core algorithms are written as functions of their inputs, so a unit test does not depend on executor scheduling.

For integration tests, the simulator drives a simulated clock and steps physics and nodes in lock-step, so the order of events is repeatable. Tests wait on conditions with timeouts, not on fixed sleeps. Where a race is possible, such as a subscriber that might connect after the first message, the test either uses transient-local durability or waits for the connection before publishing.

When a test is still flaky, I treat it as a real bug: often it is a race that will also happen on the robot.

The general standard for programmable safety systems is IEC 61508, and machinery safety commonly uses ISO 13849 with its performance levels or IEC 62061. Robot-specific standards build on these, such as ISO 10218 for industrial robots and ISO 3691-4 for driverless industrial trucks.

They ask for a hazard analysis and risk assessment first, from which safety functions and their required integrity are derived. Each safety requirement is traceable to design, code and tests. Safety functions are implemented with appropriate independence, often in certified safety controllers and safety-rated sensors rather than in the main robot computer. Development follows a defined process with reviews, coding rules, coverage targets and controlled changes.

For most robot software engineers, the practical effect is knowing which functions are safety functions, keeping the main software out of them, and not weakening them, for example by changing a speed limit in a configuration file without going through the safety process.

Updates must be atomic and reversible. I build the whole robot software as one versioned image or set of containers, with the configuration and maps versioned separately. On the robot, an A/B scheme installs the new version beside the old one and switches only after a health check passes, rolling back automatically if the robot fails to come up healthy.

Rollout is staged. First internal test robots, then a small canary group of customer robots, then larger waves, with a pause and a review of metrics between waves: mission success rate, interventions, localisation failures, error rates and loop timing. A regression stops the rollout.

Timing respects operations: robots download in the background and install only when idle, docked and charging, never mid-mission, and a site can defer an update during a busy period. I also keep compatibility between versions where robots talk to each other or to a fleet server, because a mixed fleet is normal during a rollout.

First gather facts without guessing: which robots, which software version and map, which aisle, which times of day, and what the robot reported when it stopped. If the black-box recorder captured the event, I pull the recorded sensor data and logs from just before the stop.

Then form hypotheses that fit the pattern. A stop in one aisle suggests something about that place: reflective surfaces confusing the lidar, a sloped floor triggering a tilt check, a narrow gap close to the inflation radius, or a dead spot in Wi-Fi where the robot loses its fleet server.

I test hypotheses by replaying the recording through the same software version, which often reproduces the decision exactly. If the data is missing, I add targeted logging or a trigger for that area and wait for the next event. Once the cause is found, the fix comes with a regression test built from the recorded data and a check across the fleet for the same signature at other sites.

Most job descriptions mention ROS or ROS 2, and interviewers will ask about it, but strong fundamentals matter more. If you have not used it, build one small project with it before applying, such as a simulated mobile robot with a launch file, a custom node, tf frames and a recorded bag, so you can talk about real problems you met. Some companies use their own middleware; for them, show you understand publish-subscribe, timing and serialisation in general.

Expect linear algebra, rotations, basic probability and simple calculus, applied rather than proved. Typical requests are to compose transforms, derive two-link kinematics, explain the Kalman filter steps, or estimate how stereo depth error grows with range. Specialist teams, such as controls or perception, go deeper in their area. Practise deriving on paper and explaining the meaning of each term.

Use the language the role uses most if you are fluent in it, which is usually C++. If the interviewer allows either and the problem is algorithmic, such as A* or ICP, Python lets you focus on the algorithm. For questions about real-time code, memory or concurrency, use C++, because that is what is being tested. In either case, write clean, tested code and state conventions such as frames and angle ranges. Brush up with Modern C++ Roadmap and Data Structures and Algorithms Roadmap.

Projects where you implemented the core algorithm yourself and measured it: a particle filter localising a simulated robot, an EKF fusing odometry and an IMU with plotted innovations, a planner with a tested collision checker, or a real small robot with a tuned control loop. Interviewers ask what went wrong and how you knew, so keep logs, plots and numbers. A wrapper around a library with no measurements does not give you that material.

The coding round is similar but often has a geometric or numerical twist, and the domain rounds test maths and physical intuition as well as software. Design questions are about whole robots, so timing, sensors, failure modes and safety carry as much weight as scalability. Debugging questions describe physical symptoms. General preparation for Software Engineer still helps, and the embedded side overlaps with Embedded Systems Engineer.