System Design & Ownership

Pin down the task, environment, and constraints before proposing components: What's the robot doing? Indoors/outdoors? What payload, speed, and duty cycle? What's the safety criticality (a warehouse AMR vs. a surgical robot have wildly different bars)? What already exists to build on?

Success criteria and constraints (cost, power, compute, latency budget) should shape every downstream choice, not get bolted on at the end.

Sensing (raw sensor data) to perception (objects, lanes, free space) to state estimation (where am I, what's my velocity/pose) to planning (what should I do: mission to behavior to trajectory) to control (actuator commands that track the planned trajectory).

Each interface is a contract: perception hands planning a probabilistic, timestamped world model, not raw pixels; planning hands control a feasible reference trajectory, not a wish. Most integration bugs live at these seams — a timestamp mismatch or a frame convention disagreement, not inside any one module.

Every sensor has a regime it fails in: cameras degrade in low light/glare, lidar struggles with rain/fog/specular surfaces, radar has poor angular resolution but sees through weather, wheel odometry drifts without slip. Combine complementary sensors so no single failure mode takes out the whole estimate.

Compute selection trades power, cost, and latency against model size and redundancy (e.g. a lockstep pair of compute units for a safety-critical path vs. a single best-effort box for a non-critical one).

For each major failure (sensor dropout, planner timeout, actuator saturation, compute crash), name the detection mechanism and the fail-safe response (stop, hold position, degrade to a simpler backup controller, hand off to a human). A safety case is the explicit argument, with evidence, for why the system is acceptably safe to operate — not just a list of things that could go wrong.

Pick metrics that reflect the actual mission (task success rate, intervention rate, time-to-completion, comfort/jerk) alongside component metrics (perception precision/recall, localization error) — and set targets before you have the system, not after, so you know what "good enough" means.

Evaluate offline (replay logs/sim against ground truth) before online (shadow mode, then limited real-world rollout with a rollback path) — never ship a stack's first real-world test as its evaluation.

Owning a system end to end means test coverage that matches the failure modes you named (not just unit tests on the happy path), clear communication of trade-offs to stakeholders (why this sensor suite, why this latency budget), and driving interface changes across the teams that own perception, planning, and control — because a system-level design decision usually requires several teams to change their module's contract together.