Operations December 12, 2025

2025 in Review: What We Shipped and What We Learned

Mobvynt team whiteboard with 2025 roadmap and shipped features checkboxes in Austin office

We started 2025 with a short list of commitments we'd made to ourselves at the end of 2024: cold storage support, fleet-level event sharing, and an improved WMS integration story. We're ending the year with all three shipped, plus several things we hadn't planned for that turned out to matter more than some of what we had planned. Here's an honest accounting.

What We Shipped

Cold Storage Perception Profiles (Q1)

Nadia led this one. We'd been getting consistent feedback that our perception pipeline tuned for ambient warehouses didn't transfer cleanly to cold storage environments — specifically freezer rooms operating at -18°C to -22°C. The failure modes were specific: condensation fog on the LiDAR lens during temperature transitions created scan noise that degraded obstacle tracking; thermal expansion in racking geometry changed reflective surface angles in ways that created phantom detections; and PPE-clad workers in insulated suits presented a substantially different silhouette profile to the classifier than the ambient worker training data.

We shipped a cold storage perception profile in February. The profile ships with pre-configured fog-noise filtering tuned for condensation scatter (higher minimum range threshold, tighter angular clustering for point set aggregation), a separate worker classification model trained on silhouette profiles from insulated PPE, and a thermal-variance warning that flags racking geometry drift when accumulated scan data diverges from the initial facility model by more than a configurable threshold.

What we didn't anticipate: the fog-noise filtering that works for condensation also helps in dusty ambient facilities — grain distribution centers, recycled materials handling. We hadn't targeted those environments explicitly but got several inquiries from operators there after word got out about the cold storage release.

Fleet Event Sharing (Q2)

Dario built the majority of this. The pitch was simple: AMRs in a shared space know things about that space that other robots would benefit from knowing — where the obstacles are, where the blocked paths are, where congestion is building. But communicating this without a centralized coordinator is non-trivial because you don't want every robot broadcasting raw sensor data to every other robot.

We landed on an event-sharing model rather than a state-sharing model. Robots publish high-significance events (new obstacle detected, path blocked, reroute intent, charging station congested) to a lightweight shared event bus. Other robots subscribe to event types relevant to their current task state. No continuous state sync, no centralized planner. The event bus is implemented using our /mvnt/fleet/events ROS 2 topic with a structured message schema; a standalone relay node handles cross-robot event routing over the facility's existing Wi-Fi infrastructure.

The measurable outcome: in test environments with 6+ robot fleets, reroute storms — the failure mode where multiple robots simultaneously reroute around the same obstacle and congest the alternative paths — dropped significantly compared to the same environment without event sharing. The coordination is light but it's enough to break the simultaneity that causes storms.

WMS Integration: REST and MQTT Patterns (Q3)

Marcus spent most of Q3 on this. We documented and packaged two first-class integration patterns — REST push and MQTT event stream — with reference implementations, a timing-window-aware task dispatch schema (the deadline_utc field that the earlier article on pick-slot timing covers), and a thin VDA 5050 adapter layer. We also shipped a diagnostic mode that records all WMS ↔ fleet manager message exchanges for post-hoc debugging — which turned out to be genuinely useful in the first deployment that used the MQTT pattern, when we hit a QoS misconfiguration that wasn't obvious until we could replay the message sequence.

Seven New Hardware Configurations Validated

This one was less a product feature and more an ongoing process. Every time we deploy in a new environment, we encounter a sensor configuration we haven't fully characterized: different LiDAR model, different mounting height, different scan frequency. Over 2025 we formally validated our perception pipeline against seven distinct hardware configurations that weren't in our original test set, ranging from a single-plane 2D LiDAR configuration on a budget chassis to a dual-LiDAR setup with a Sick TiM781 at 15cm height for near-floor detection combined with a Velodyne Puck at 85cm for general obstacle detection.

Each validation generates a configuration profile that sets sensor-specific parameters for the perception pipeline: range compensation coefficients, near-field saturation thresholds, scan frequency vs. classification latency tradeoffs. These profiles are now shipped as first-class configuration templates rather than requiring manual tuning on each new deployment.

What We Learned

Simulation Testing Caught Things We Didn't Know to Look For

Nadia wrote about the bag replay harness earlier this year. The lesson that stuck with us most was that the harness's value wasn't primarily in regression coverage — it was in surfacing failure modes we hadn't encountered in the field yet. The sensor dropout sequences, the near-field saturation artifacts from narrow aisles — both of these were in the real-world recordings all along, and we just hadn't been systematically looking for them until the harness gave us a way to replay and annotate at scale.

We're ending 2025 with 47 annotated bag file sequences. We're targeting 80 by mid-2026, specifically filling in coverage for underrepresented facility types: high-bay racking, outdoor dock staging areas, and food-grade washdown facilities.

The Integration Layer Is the Actual Deployment Risk

We came into 2025 thinking the hard deployment problems were perception and path planning. They're not — those are solved well enough. The hard problems are in the integration layer: WMS protocol compatibility, IT network constraints, and the expectation mismatch between what an AMR deployment team thinks an integration means and what the WMS vendor's integration team thinks it means. We lost 6–8 weeks of deployment time across multiple projects in 2025 to integration issues that had nothing to do with the robots or the perception software. That's the thing we're investing most heavily in for 2026.

The Feature Request We Kept Saying No To

Every year there's at least one recurring request that we decline, and this year it's worth writing down why.

The request: pre-mapped grid mode. Several operators have asked for a fallback mode where our software would operate from a static pre-mapped grid — essentially reverting to the behavior of older AMR systems — for environments they consider stable enough that dynamic perception isn't needed.

We keep declining this for a specific reason: "stable enough" is not a property that holds over time in real warehouses, and offering a pre-mapped mode gives operators an escape hatch to skip the process of understanding why their environment isn't as stable as they think it is. We've written about the hidden costs of pre-mapped grids at length. The short version: the first seasonal reconfiguration, forklift incident, or pallet misplacement that happens during a busy shift is exactly the moment when dynamic perception earns its keep, and operators who've been running in pre-mapped mode aren't prepared for what happens when the map diverges from reality.

We're not saying pre-mapped grids are never appropriate. There are specific high-control environments — dedicated automation zones with exclusion barriers and no human access during operation — where static planning is the right approach. We're saying that a pre-mapped fallback mode on a product designed for dynamic environments creates a support surface we don't want to own, and it doesn't serve operators well even when they think it does.

What's Coming in 2026

Daniel has been clear internally that 2026 is an integration year. The perception work is strong; the path planning work is strong. The gap is making all of it easier to deploy at a new facility without a week of configuration work. That means better configuration tooling, more hardware profiles out of the box, and a more opinionated WMS integration layer that handles more of the edge cases automatically.

We'll write more specifically as things ship. Thanks to everyone who's sent feedback this year — the bag file annotations, the integration issue reports, the detailed breakdowns of what the robots were doing when something unexpected happened. Those reports are directly responsible for a meaningful portion of what shipped in 2025.