Robotics Production Readiness Checklist

This checklist assumes a robot that already does its job in controlled conditions with someone watching. Nothing here is about getting the autonomy working. It is about the gap between "it works" and "it works unattended, on the hundredth unit, in weather" — where most robotics programmes stall, and almost none of it is autonomy work.

Work through it once per platform, not once per project. A second application on the same hardware inherits these answers; a new sensor suite or compute module does not.

1. Foundation

• The BSP builds from source in a layer you own, so you can patch a driver and ship it without waiting for the vendor's next binary drop
• The kernel configuration is in version control next to the application code, not a .config someone edited with menuconfig on a bench machine two revisions ago
• PREEMPT_RT is applied only where a measurement showed it was needed — cyclictest run under the load the robot actually carries, not on an idle desk
• Sensor timestamps come from hardware capture — a camera strobe, an IMU data-ready interrupt, a PPS line — and not from the moment a userspace node happened to read the buffer
• The boot path is deterministic: every device enumerates in a known order and is addressed through a udev rule, never through /dev/ttyUSB0 and hope

2. Sensing and state estimation

• Fusion covariances are tuned against logs from the field, not against a lab dataset where the floor was flat and GNSS never multipathed
• Behaviour on a degraded or dead sensor is defined per sensor and tested by causing it: an unplugged LiDAR, an encoder stuck at a value, a camera returning the same frame forever
• Every compute node is clock-synchronised — PTP where the NICs do hardware timestamping, chrony against an on-board reference where they do not. Skewed clocks do not break fusion loudly; they produce a confident, wrong estimate whose symptom surfaces somewhere else
• Sensor health is published at runtime — measured rate, dropped frames, age of the last good sample — so "the LiDAR was fine" is a query rather than an opinion

3. Autonomy and safety

• The emergency stop is hardware and independent of ROS2 — a dual-channel circuit through a safety relay that removes motor power on its own. An E-stop that depends on the software stack it exists to protect against is not an E-stop
• Safety margins — inflation radius, minimum clearance, maximum approach speed — are configuration under version control, not constants compiled into a planner
• Behaviour on localisation loss is defined, and the defined behaviour is stop. Not continue on odometry until the particle filter recovers
• Speed limits and geofences are enforced below the planner, in the motion or safety controller, so a planner bug cannot command a speed or a place the robot is not permitted

4. Real time

• Control-loop period and jitter are measured on the robot under realistic load — perception running, logging on, link busy — and the worst case is recorded, not the mean
• ROS2 QoS is chosen per topic: best-effort with a shallow history for sensor streams, where a stale sample is worse than a dropped one; reliable and transient-local for state a late-joining node must receive. Defaults left in place are a decision nobody made
• The control path allocates nothing, blocks on nothing, and writes nothing to disk — memory locked with mlockall, buffers pre-allocated, logging handed off through a bounded queue — and runs at a set priority on cores perception is not allowed to touch
• CPU, memory and thermal headroom are measured at worst case — mid-replan, with an update downloading, at the top of the rated ambient range — not at idle

5. Connectivity and updates

• Telemetry is enough to diagnose a failure without visiting the robot: state estimate, active behaviour, sensor health, and the seconds before the fault, retained on device
• Remote takeover latency is measured end to end, operator input to wheel response, over the worst link the robot will see. The number is known, not assumed
• Behaviour when the link drops mid-takeover is defined and tested: a watchdog stops the robot rather than letting it continue the last command it received
• OTA updates are signed and verified on the device before they are applied, on an A/B or dual-bank scheme whose rollback has been exercised on real hardware including a power cut mid-write
• Updates roll out in stages — one unit, then a group, then the fleet — with a hold between stages that a human can trigger

6. Fleet operations

• Logs from the kernel, the ROS2 nodes and the cloud services carry a shared unit identifier and a synchronised timestamp, so an incident is one timeline rather than three files to align by hand
• The running software version of every unit — application, ROS2 packages, kernel, BSP — is queryable centrally, and the answer comes from the device rather than from the deployment record
• Failures are aggregated and fingerprinted, so the same fault on ten robots is one pattern rather than ten tickets closed separately
• There is a path from a field failure to a reproducible test case — the log bundle carries enough to replay the scenario in simulation or on a bench rig

7. The conditions prototypes never see

Each of these should have been tried at least once, on real hardware, before anyone calls the robot ready.

• A cold start below freezing: a lithium pack that will not accept charge below 0 °C without a heater, a sensor window that fogs on the way in, stiff bearings for the first ten minutes
• A dirty or wet sensor window — mud on the camera, rain returning off the LiDAR, low sun straight into the lens
• A network that is present but slow — 300 ms of latency and a few percent loss breaks more than a clean disconnect does. Reproduce it with tc netem before the field does
• A battery at 5%, far from the dock, with the reserve calculation deciding whether the robot makes it back
• An eight-hour shift with no restart, watched for memory growth, file-descriptor leaks, log volume and disk fill
• A person standing where a person should not stand: in the charging bay, behind the robot as it reverses, on the floor rather than upright

Where this usually goes wrong

The demo loop is the only tested loop. A robot that has run one route flawlessly for a month has been tested once, thirty times over. The map has memorised the route, the lighting is the same every morning, and the obstacles are where they always are. Coverage means different environments, not more hours in one.

The E-stop is wired through the stack it protects against. It is easier: the button is already a GPIO, and a node already reads GPIO. It is also the one shortcut that removes the entire point of an independent stop, because the failures you most need to stop for are the ones where the stack has stopped responding.

Nobody can say what is running on unit 47. The deployment record says one thing and the robot has been reflashed twice at a customer site. The moment that question has no answer, every diagnosis downstream of it is guesswork — and it is cheap to build early, painful to retrofit across a deployed fleet.

When this needs outside help

Most teams can work through this list themselves, and should. It is worth bringing in help when the blocker is somewhere other than the autonomy:

• BSP and driver work has stalled the programme, the team's expertise is in algorithms, and the blocker is in the kernel
• A real-time requirement configuration cannot meet: tuning priorities and QoS has run out, and the fix is architectural — moving a loop to a microcontroller, or off the general-purpose scheduler entirely
• Scaling from one robot to a fleet, where the missing piece is infrastructure — OTA, telemetry, log correlation, staged rollout — rather than anything to do with how the robot drives

If any of those describe where you are, this is work we do: contact@mnpsystems.ca.