A robot that drives the aisles at two in the morning and counts a thousand locations sounds like the end of inventory problems. In practice it produces something more modest and more useful: a nightly comparison between what the ERP believes and what a machine observed, with a position and a timestamp behind every line.

The value of the project sits almost entirely in how that comparison is modelled.

What a night robot actually produces

It is a moving sensor platform, not an oracle.

The platform carries a mast, one or more antennas and a localisation stack, usually lidar plus wheel odometry.
It reads location identifiers on the racking and, depending on configuration, item tags, shelf labels or both.
Each capture is tied to a pose: which aisle, which bay, which height, which side.
The output is a set of observations, not a stock level, and observations need interpretation.
Treating the observation as a stock level is how projects end up switching the robot off after a quarter.

The nightly job is a reconciliation

The useful artifact is the difference between expected and observed, with reasons attached.

Build an expected list per location from Odoo quants at mission start, not at import time.
Compare observed reads against that list, location by location, and record agreement as well as variance.
Attach a confidence to each observation: full read, partial read, ambiguous position, no read at all.
Publish the comparison before any stock move is proposed, so humans can see the raw picture.
Keep the snapshot, because the state of the shelf changes while the report is being reviewed.

Model missions, routes and sessions explicitly

A read without a mission is an anecdote; a read inside a mission is evidence.

Store the mission: robot, map version, start and end time, operator or schedule, coverage plan.
Store waypoints and the location each waypoint was meant to observe.
Store the capture session with its sequence number, so replays are traceable.
Version the map, because racking moves and a stale map silently mislabels reads.
Let Odoo reference the mission identifier, so a disputed quantity can be traced to one night.

Position and time are the hard fields

A tag read at the wrong bay is worse than no read, because it looks like a real variance.

Record the pose at the moment of read, not the pose at the end of the stop.
Synchronise the robot clock at mission start, and reject captures with implausible timestamps.
Keep time in UTC; convert once, at display.
Compare observation time with the last stock move for that product and location.
If the ERP moved goods after the capture, the variance is probably history, not error.

Land the data in staging first

Direct writing from a robot API into quants is the fastest way to destroy trust in both systems.

Ingest raw captures into a staging table with mission, pose, timestamp, tag and signal strength.
Validate in staging: product exists, location exists, lot exists, quantity plausible.
Keep rejected observations visible, because read errors cluster in specific aisles.
Process in batches with a deterministic mission key, so a retried upload is harmless.
Promote from staging to a variance document; only then consider stock adjustments.

Match reads to ERP records honestly

The matching layer carries most of the engineering risk.

Maintain an explicit mapping from location identifier to Odoo location, including height levels.
Maintain tag-to-product bindings, and treat unbound tags as exceptions, not as new products.
Handle one tag reading as multiple units only when the process says so; a tag is not a quantity.
Resolve duplicate reads within a pass by taking the strongest observation and recording the rest.
Surface ambiguous matches, where one read fits two candidate records, instead of picking silently.

Classify variance before you act

Not all differences deserve an adjustment, and the classifier is what makes the report usable.

A quantity difference with consistent reads in the right location suggests a real stock issue.
A product found in the wrong bay suggests misplacement, not loss.
A missing read at a location that was also unread last night suggests a broken tag or a blocked shelf.
A difference that appears only after a shift change suggests an unrecorded movement.
Route each class to a different owner, because the fixes are different.

Keep a human in the loop

Automation should narrow attention, not remove it.

Convert variances into tasks in Odoo, with location, expected, observed and a photo or pose reference.
Let the operator confirm, correct or dismiss with a reason code.
Use a mobile verification pass for high-value or high-variance locations before adjusting.
Reserve automatic adjustments for low-value categories with a proven false-positive rate.
Track how often operators overturn the robot; a rising rate means the model or the map is wrong.

Operational constraints nobody budgets for

The robot shares the floor with people, forklifts and charging stations.

Night shifts are quieter but not empty; safety rules and speed limits still apply.
Battery and charging windows bound how many aisles one mission can cover.
Lighting and floor conditions affect localisation more than they affect RFID.
Wi-Fi coverage gaps cause data to buffer; the sync must tolerate late arrival.
Racking changes, pallet overhang and shrink wrap all change what the robot can see.

Metrics and rollout order

Measure whether the robot is making inventory better, not whether it is impressive.

Coverage: share of locations actually observed per night, against the planned route.
Agreement rate: locations where observation matches the ERP expectation.
False positive rate: variances later dismissed by a human, which decides automation scope.
Time to close a variance, from detection to resolution.
Start with one zone and one category, run in report-only mode for a month, then enable tasks.

Teams that begin with report-only mode usually discover that a third of apparent variances are mapping or tag problems, which is exactly the information needed before any stock adjustment is automated.