Layer 5 — Navigation, localisation and perception

Supporting depth. For a Software Solutions Architect the goal is to understand the stack and its design consequences — what it demands of the building, what it costs to commission, what breaks — not to implement it. If asked, say that honestly and then reason well about the consequences; that reads far better than bluffing SLAM internals.

DM code, inertial and SLAM navigation

What it is. How a robot knows where it is.

Why it matters here. The localisation choice dictates what the building must provide — floor markers, floor flatness, lighting — and that lands squarely in site-readiness planning.

Fundamentals.

• Fiducial navigation. Coded markers (DataMatrix/DM codes, QR, AprilTag) on the floor or racking give absolute position with high accuracy and near-zero drift. Cheap and extremely reliable — at the cost of installing and maintaining the markers, and of a floor that must stay clean and undamaged.
• Inertial navigation (IMU + wheel odometry) gives continuous high-rate pose between markers. It drifts — error accumulates with distance — so it is always a complement, never a standalone.
• The standard pattern is fiducial + inertial fusion: markers correct absolute position, inertial interpolates between them. This is the workhorse of warehouse AGV/AMR navigation.
• SLAM (Simultaneous Localisation and Mapping) builds and localises against a map of natural features, usually from LiDAR. No floor infrastructure needed, which is its whole appeal. The costs: sensitivity to environments that change (a warehouse where pallets move daily is a changing environment), higher compute, and harder-to-guarantee accuracy.
• The engineering point worth making: infrastructure-based navigation trades installation effort for determinism. In a high-throughput warehouse where you must guarantee cycle times, determinism usually wins — which is why fiducials remain dominant despite SLAM being technically more sophisticated.

How Hai applies it.

"They integrate advanced software strategies and hardware features, such as DM code navigation plus inertial navigation, optional SLAM navigation, and environmental mapping." — /robots/heavy-duty-amr-k600-k1000

Read the hierarchy carefully: DM code + inertial is the primary stack; SLAM is optional. That is exactly the determinism-over-sophistication tradeoff above, and it explains why they chose it.

"A42T and A42 SLAM ACRs are launched for HaiPick System 1" — /company

SLAM-capable models have existed in the line since 2020.

Tradeoffs and pitfalls.

• Floor markers are consumables. Forklift traffic, cleaning chemicals and pallet drag destroy them; marker maintenance is a real operating cost.
• Floor flatness tolerance is a genuine building requirement — and a common source of go-live delay in retrofit sites.

Key terms. fiducial · DataMatrix / DM code · AprilTag · IMU · odometry · dead reckoning · drift · sensor fusion · SLAM · environmental map · floor flatness.

LiDAR obstacle detection and collision avoidance

What it is. Laser scanning to detect obstacles and stop or route around them.

Why it matters here. It is the layer that makes robots safe around people and unexpected objects, and it interacts directly with throughput: a robot that slows for every shadow is a slow robot.

Fundamentals.

• 2D safety LiDAR at low height is the industry standard for mobile robots: it defines protective fields (stop) and warning fields (slow), typically speed-dependent — faster travel needs a longer look-ahead field.
• Safety-rated LiDAR is a certified functional-safety device, distinct from navigation LiDAR. Conflating the two is a common mistake.
• 3D perception catches what 2D at ankle height misses — an overhanging pallet arm, for instance.
• The tuning tension is direct: tight fields mean nuisance stops and lost throughput; loose fields mean risk. This is a real commissioning decision, not a factory default.

How Hai applies it.

"Experience superior case-handling stability features and LiDAR collision avoidance." — /robots/haipick-a42-e6s

"LiDAR remote scanning." — /robots/fast-transit-amr-k50

"Obstacle detection, active obstacle avoidance, anti-collision alarm, and emergency stop" — /robots/haipick-a42

Note "active obstacle avoidance" — routing around, not merely stopping.

Tradeoffs and pitfalls. Nuisance stops from over-tight fields are one of the most common causes of a system underperforming its simulated throughput.

Key terms. safety LiDAR · protective field · warning field · speed-dependent field · nuisance stop · active avoidance.

3D vision for container recognition

What it is. Camera-based recognition of tote and carton position, size and pose.

Why it matters here. It is what lets the system handle cartons and mixed container sizes rather than only uniform totes — and that capability decides whether a customer needs to decant into standard totes, which is a large hidden cost in any proposal.

Fundamentals.

• Two problems: detection (is there a case, where, at what angle?) and dimensioning (how big is it, will it fit the fork?).
• Depth sensing options: stereo, structured light, time-of-flight. Warehouse lighting and reflective packaging are the practical enemies.
• The commercial significance is the decanting question. If a system needs uniform totes, the customer must transfer goods into them on receipt — labour, space and packaging cost. Handling original cartons removes that entire step.

How Hai applies it.

"Yes, with the installation of a 3D camera, HAIPICK is capable of picking multiple specifications of cases." — /robots/haipick-a3

"Adapt to the situation that some containers cannot be identified by the code." — /robots/haipick-a42

"Cartons and bulky items can be handled directly on trays, keeping products in their original packaging while fitting into automated workflows. This reduces labor and preserves packaging integrity." — /solutions/haistation

3D visual recognition is an optional feature on the A42/A42T, not standard — worth knowing when scoping a proposal.

Tradeoffs and pitfalls. Vision adds a per-robot cost and a per-pick latency. For a uniform-tote operation it is pure overhead; for a mixed-carton operation it is what makes the project viable.

Key terms. decanting · structured light · time-of-flight · stereo depth · pose estimation · dimensioning · mixed-SKU handling.

Sensor calibration and commissioning

What it is. The setup work that makes a robot's sensors agree about where things are.

Why it matters here. Context depth only — but it is where deployment time goes, and estimating deployment effort is part of a solutions architect's job.

Fundamentals.

• Extrinsic calibration establishes the rigid transform between sensor frames and the chassis — expressed as homogeneous transformation matrices (4×4, a rotation plus a translation). Chained wrongly, everything downstream is wrong.
• Intrinsic calibration covers lens distortion and focal parameters per camera.
• Point-cloud filtering removes noise, ground returns and outliers before the cloud is used for detection.
• Calibration drifts with vibration and collisions; recalibration is scheduled maintenance, not a one-off.

How Hai applies it.

"tune and calibrate mobile robots for desired actions using homogeneous transformations, image calibration, point cloud filtering algorithms, depth camera calibration, chassis-to-AprilTag mapping, and LiDAR calibration for obstacle detection" — /join-us/recruitment/robotics-engineering-manager

"analyze detailed logs from robotic components such as the chassis, IMU, LiDAR, motors, and microcontroller" — /join-us/recruitment/robotics-engineering-manager

This JD is the only place in the corpus where the sensor suite is named concretely: chassis, IMU, LiDAR, motors, microcontroller, depth camera, AprilTag.

Tradeoffs and pitfalls. Calibration effort scales with fleet size and is routinely underestimated in deployment schedules.

Key terms. extrinsic / intrinsic calibration · homogeneous transformation · point-cloud filtering · AprilTag · commissioning · root cause analysis.

Mechanical constraint as a substitute for perception

What it is. Designing the physical environment so that a sensing problem disappears.

Why it matters here. This is the most quietly impressive engineering decision in the corpus — a systems-engineering move rather than a software one, and easy to miss on a first read of their material.

Fundamentals.

• Every perception problem can be attacked from two directions: better sensing, or constraining the world so less sensing is needed. Jigs and fixtures in manufacturing are the classic example.
• Constraint is cheaper, faster and more reliable — but it reduces flexibility and imposes requirements on the environment.
• The general principle: do not sense what you can constrain.

How Hai applies it.

"we must install a guard board on the rack" — /robots/haipick-a42-e6s

The full FAQ explains the chain of reasoning: a guard board restricts the tote's position, so tote angle need not be recognised by QR code, which removes a sensing step and speeds up loading — while simultaneously enabling the 30 mm case spacing that gives this model its density advantage. One mechanical part removes a perception requirement and buys density.

"Horizontal case spacing up to 30mm* while reducing the gap between front and back of totes to 0mm." — /robots/haipick-a42-e6s

Tradeoffs and pitfalls. The rack is now part of the robot's design. Retrofitting into existing racking becomes harder, which partly conflicts with Hai's "works with any racking" positioning — a legitimate, respectful question to raise.

Key terms. design for constraint · fixturing · mechanical tolerance · sensing-vs-constraint tradeoff · retrofit compatibility.