Digital twin systems that connect a physical warehouse to an interactive 3D environment are one of the most practical XR applications in enterprise operations. Unlike VR gaming or consumer AR, warehouse digital twins solve an immediate operational problem: reducing errors in inventory management and speeding up transfer workflows. This article covers the complete architecture for building an XR warehouse digital twin with live Odoo ERP integration, based on a production deployment where we achieved a 40% reduction in transfer processing time.
The Warehouse Operations Problem
Traditional warehouse management through a 2D Odoo interface requires operators to constantly switch context between a screen showing database records and the physical environment they are navigating. An operator confirming an outgoing delivery must: locate the product on the screen, find its physical location in the warehouse, pick the items, return to the screen to validate quantities, scan barcodes if available, and confirm the transfer. Every context switch is an opportunity for error.
A 3D digital twin collapses this into a single interface. The operator navigates a virtual representation of the warehouse, sees live inventory data overlaid on virtual shelving, initiates transfers by interacting with virtual stock, and confirms operations through the same spatial interface — without switching to a separate screen.
Architecture Overview
The system has four layers: the Odoo backend (the source of truth for all inventory data), a JSON-RPC integration service (a Python FastAPI microservice handling bidirectional Odoo communication), the Unity 3D client (the warehouse environment, interaction systems and data visualisation), and an admin configuration layer (bin mapping, product catalog sync, user assignment).
Odoo JSON-RPC Integration
Odoo's primary external API is JSON-RPC, accessible at /web/dataset/call_kw. Authentication uses session-based tokens obtained via /web/session/authenticate. All calls pass the database name, model name, method and arguments.
The integration service handles several Odoo models: stock.location (warehouse locations and bin positions), stock.quant (current inventory per location), stock.picking (transfer documents), stock.move (individual item movements) and stock.inventory (physical inventory adjustments). We wrap Odoo's XML-RPC or JSON-RPC calls in a FastAPI service that the Unity client communicates with via REST, since Unity's HTTP client handles REST much more cleanly than raw JSON-RPC.
Bin Location Mapping
The most important integration step is mapping Odoo's abstract location hierarchy (zones → rows → columns → shelves) to 3D coordinates in the Unity environment. We create a configuration file that maps each Odoo stock.location ID to a 3D position and rotation in the Unity scene. This mapping is managed through a simple admin interface where warehouse managers can drag virtual bin markers to their correct positions after a one-time laser scan of the facility.
Unity Client Architecture
The Unity client has three major systems: the scene manager (handles environment loading, operator navigation and visual state), the inventory overlay system (renders live stock data as floating labels on shelving), and the interaction system (processes operator gestures to initiate Odoo operations).
Data polling is a key architectural decision. Warehouse inventory changes in real time as other operators complete transfers. We poll the Odoo integration service every 30 seconds for inventory updates and immediately on completion of any local operation. Rather than re-rendering the entire scene on each poll, we use a differential update: the integration service returns only the records that have changed since the last sync timestamp, and the Unity client updates only those shelf labels.
Transfer Workflow in XR
The transfer workflow in the XR client mirrors the Odoo workflow but presented spatially. An incoming receipt appears as a highlighted zone on the virtual loading dock. The operator walks to the zone, sees the expected items listed as floating labels, physically (in XR) confirms each item as it arrives, and completes the receipt — which triggers the stock.picking validation via JSON-RPC, updating Odoo in real time.
Error prevention is built into every workflow step. If an operator tries to confirm an item quantity that differs from the expected quantity by more than 5%, the system shows a confirmation dialog requiring explicit acknowledgment. If a product is scanned to the wrong location, the system cross-references the planned put-away rules in Odoo and highlights the correct location.
Performance on Warehouse Hardware
Warehouse digital twins are typically deployed on industrial tablets or low-end AR headsets, not high-performance workstations. The system must run at acceptable frame rates on a mid-range Android tablet. We target 30fps on a device with a Snapdragon 720G or equivalent. This requires aggressive geometry budgeting: the entire warehouse environment must stay under 200,000 triangles, with product models represented as simple cuboids or low-poly icons rather than detailed 3D meshes.
Key Takeaways
- Map Odoo location IDs to 3D coordinates during setup — this one-time investment is the foundation of the entire system.
- Use a FastAPI middleware layer between Unity and Odoo — Unity HTTP client handles REST cleanly while Odoo JSON-RPC is complex to consume directly.
- Poll for inventory changes on a 30-second interval with differential updates — re-rendering the entire scene on each poll is too expensive.
- Build error prevention into every workflow step — the value of the system is reducing validation errors, not just visual novelty.
- Target 30fps on mid-range Android tablets — warehouse hardware is not a gaming machine.
