Under the hood: how Mobvynt sees and decides.
A step-by-step walkthrough of the perception pipeline, the planning algorithm, and how they talk to each other in real time.
Perception: sensor data to obstacle map
Sensor data ingestion starts with the LiDAR point cloud (and optionally RGBD frames). Background subtraction removes static structure from the occupancy data. Moving object isolation extracts dynamic foreground blobs.
An 8-class CNN classifier labels each detected object: person, forklift, pallet, conveyor, static shelving, mobile cart, unknown-moving, or unknown-static. Unknown classes use safe conservative clearance defaults rather than failing.
Trajectory prediction uses a constant-velocity linear model for dynamic objects. This matters: the robot needs 2–3 planning cycles of lookahead, not just the obstacle's current position. A forklift starting to back up needs to be anticipated 160–240ms ahead.
Dynamic Obstacle Map: temporal costmap
This is Mobvynt's key IP. Instead of a static occupancy grid (occupied / free), each cell in Mobvynt's costmap carries a confidence-decay function and a predicted-trajectory overlay.
The map builds a rolling 2-second obstacle forecast. A cell that was occupied by a moving forklift 400ms ago carries a decayed occupancy probability — it's probably still clear but the planner doesn't treat it as definitely free.
The amber cells in the diagram represent predicted future positions — where MV Perceive estimates the forklift will be in the next 500ms based on its current velocity. The planner routes around both current and predicted occupied zones.
Path Re-Planning: threading obstacle and timing constraints
MV Plan uses a modified A* that simultaneously satisfies two constraints: obstacle clearance from the costmap, and pick-slot arrival window from your WMS.
The trade-off: if the window is tight, the planner may accept a higher-risk shorter path (closer to obstacle predicted positions). If the window is flexible, it goes conservative. A configurable risk tolerance parameter lets you set where on that curve your fleet operates.
The planner outputs three ranked candidate paths at each cycle, color-coded by confidence. The robot takes the highest-confidence path unless a downstream gate fails, in which case it falls back to path 2 or path 3.
Command Output: standard ROS 2 interface
Output is standard ROS 2 cmd_vel and path topics. The robot's motor controller receives updated velocity commands at 20Hz — no changes to robot firmware required. Mobvynt speaks the robot's existing ROS interface.
What "no pre-mapped grid required" actually means: Mobvynt doesn't replace your SLAM map for localization. Your robot still uses its existing base map to know where it is. Mobvynt adds a dynamic obstacle layer on top — it handles the daily delta between your static map and what's actually on the floor right now.
Supported ROS 2 versions: Humble (22.04 LTS), Iron, and Jazzy. Subscribe topics: /scan, /camera/image_raw, /odom. Publish topics: /cmd_vel, /mobvynt/obstacles, /mobvynt/path.
Technical questions
No. Mobvynt adds a dynamic obstacle layer on top of your existing base map. Your robot's SLAM stack still handles localization — Mobvynt handles the daily delta between what your static map knows and what's actually on the floor. You keep your existing infrastructure and add Mobvynt as an obstacle-aware planning layer.
2D LiDAR is the minimum. Adding 3D LiDAR or an RGBD camera improves classification accuracy and enables the full 8-class obstacle model. We have 7 tested hardware configurations ranging from single 2D LiDAR to full sensor fusion. We'll recommend the right configuration for your environment during onboarding.
Runs at real-time rates on Intel NUC-class hardware: ARM Cortex-A72 or Intel Atom class, 4GB RAM, Ubuntu 22.04 + ROS 2 Humble. No GPU required for the 2D LiDAR-only configuration. Camera fusion modes benefit from a GPU but degrade gracefully without one by falling back to LiDAR-only classification.
ROS 2 Humble (22.04 LTS) and Iron are fully supported. Jazzy support is available for new deployments. We recommend Humble for production deployments due to its LTS status. We don't support ROS 1 — the dynamic obstacle layer requires ROS 2 message interfaces for real-time performance.
MV Bridge connects via REST API or MQTT, tested with 12+ fleet management systems including Locus FleetKeeper, 6RS Chuck Fleet, inVia Robotics, GreyOrange Butler, Fetch FetchCore, OTTO Fleet Manager, and others. If your system has an open API, we can integrate. We'll tell you upfront if integration will need custom work.
Unknown objects always get classified into one of two safe fallback classes: unknown-moving or unknown-static. Both use conservative clearance defaults. Unknown-moving gets a larger safety bubble because the planner assumes worst-case trajectory. The system never fails open — an unclassified object is always treated as something to route around, not ignore.
Questions the FAQ didn't answer?
We run 30-minute technical calls with robotics engineers. Bring your architecture questions — we'll bring answers about exactly how Mobvynt fits your stack.