openelab.de
openelab.com
A compact 360° LiDAR can make an AMR look simple on a CAD model. The useful question is tougher: does its actual point cloud remain reliable through the robot’s mount, cable path, network, clock chain, route geometry, and recovery behavior? This review puts the Livox MID-360S in that engineering context.
What this guide answers
- What the MID-360S published specifications mean once the sensor is mounted on an AMR.
- Which electrical, mechanical, ROS 2, and SLAM checks should be completed before a field route is accepted.
- Where full-surround 3D coverage is the right sensing geometry, and where a directional LiDAR or a separate safety architecture is the better answer.
What Is Livox MID-360S Designed to Do?
Livox positions MID-360S as a compact hybrid-solid-state 3D LiDAR for intelligent mobile robots. That description matters because it frames the product correctly: this is a surrounding geometry sensor for a robot system, not a self-contained navigation solution. A mobile platform still needs calibrated frames, robot motion data, a mapping or localization pipeline, obstacle policy, diagnostics, and a way to respond when sensor data becomes late, sparse, or unavailable.
The hardware is appealing where the robot has very little unused roof area. The enclosure measures 65 × 65 × 60 mm and weighs 265 g. The published field of view is 360° horizontally and 59° vertically, from -7° to 52° in the typical specification. This is broad enough to provide a continuous horizontal perimeter around a small chassis, but a bracket, handle, payload, bumper, camera mast, or cable loop can still remove useful parts of that volume.
| Published item | MID-360S value | What the robot team should check |
|---|---|---|
| Field of view | 360° horizontal × 59° vertical, typical | Model chassis, payload, and bracket occlusion before cutting the mount. |
| Near field | 0.1 m blind-zone boundary | Test pallet corners, cart legs, floor hardware, and low obstacles at the installed height. |
| Point output | 200,000 first-return points/s at 10 Hz, typical | Measure the rate and CPU load at the message format used by the actual stack. |
| Interface and timing | 100BASE-TX; PTPv2 or GPS synchronization; built-in ICM40609 IMU | Define an authoritative clock, transforms, and loss-of-sync behavior. |
| Environmental envelope | IP67; -20°C to 55°C published operating range | Validate the robot enclosure, connector path, vibration, thermal behavior, and cleaning process as a system. |
Coverage Is Useful Only After the Mount Is Honest
It is tempting to read “360°” as “no blind spots.” On an AMR, that is never the whole story. Horizontal coverage describes the sensor’s nominal volume, while the vehicle defines the usable one. A low mount can put the lower field into the floor at short range. A high mount may clear the payload but weaken visibility of short items next to the bumper. A forward handle or a tall tote can create an occlusion wedge that remains invisible in a desktop demo and becomes obvious only during a turn or docking maneuver.
The current manual gives a practical starting point: a bottom mount, four M3 holes with 5 mm depth, at least 10 mm of surrounding clearance, and a thermally conductive installation surface. It illustrates a flat metal plate at least 3 mm thick with at least 10,000 mm² of exposed area. Treat those figures as design inputs, then confirm them against the document revision supplied with the hardware before releasing a production drawing. The manual also warns that the optical window must remain clear, including from glass or chassis elements.
For an AMR, draw the sensing volume in the robot frame and inspect it at the lowest and highest expected ride height. Add the actual cable exit, enclosure seams, lifting handles, payload envelopes, and nearby sensors. Then make a simple physical mock-up. The result is usually more valuable than a generic range chart because it exposes whether the LiDAR has a useful view of the objects the robot must understand.
Power, Network, and Thermal Checks Before the First Route
MID-360S accepts 9–27 V DC, with 12 V recommended in the current user manual. Its typical power value is 6.5 W, but the supply should be sized for startup and cold-weather behavior rather than only the normal running number. The manual lists a short startup demand of up to 18 W at 0–35°C and a self-heating demand up to 14 W from -20°C to 0°C. Build margin into the robot’s power budget, check brownout behavior during traction events, and verify that the LiDAR’s supply cannot exceed the allowed voltage during charger transitions or battery regeneration.
Power and data use the specified M12 A-coded 12-pin connection. Do not attach the device directly to a Power over Ethernet port. Use the designated cable assembly for debugging or a carefully engineered harness for the vehicle, with strain relief and the bend radius the manual requires. A good cable route protects the connector without making the cable a tall obstruction near the optical head.
| Commissioning area | Evidence to collect | Failure that should not reach the floor |
|---|---|---|
| Supply | Voltage at the device during boot, motion, docking, and cold-start conditions | Repeated restarts, undervoltage resets, or an over-voltage transient |
| Ethernet | Link-up time, packet continuity, switch behavior, and recovery after a reconnect | Point-cloud stream that returns only after a full robot reboot |
| Network addressing | Recorded device IP, subnet, replacement-device procedure, and conflict prevention | Static address collision after field service or a second prototype joins the network |
| Thermal path | Bracket contact, exposed metal area, enclosure temperature, and dust accumulation review | Heat trapped by an attractive but insulating cover or stacked adapter plate |
| Time source | PTP/GPS state, timestamp monotonicity, and defined response to sync loss | Maps that drift because point time and robot motion time disagree |
ROS 2: Prove the Data Before Starting SLAM
A point cloud in RViz is a useful first milestone, but it is not proof that the data is suitable for mapping or localization. The rest of the robot may still be using another clock, a different base frame, a delayed transform, or a message conversion that drops information needed downstream. First prove the sensor, then prove the transport, then prove the fusion pipeline.
The Livox ROS Driver 2 repository provides dedicated MID360S launch files. Release 1.2.6 added MID-360S support and ROS 2 Jazzy support; its documented paths cover Ubuntu 22.04 with ROS 2 Humble and Ubuntu 24.04 with ROS 2 Jazzy. Follow the current SDK2 and driver documentation for the exact revision being deployed. The repository describes the driver as a debugging tool, which is an important engineering signal: a production robot normally adds its own configuration control, logging, diagnostics, health monitoring, recovery behavior, and deployment testing around it.
Starting from a workspace after Livox SDK2 has been installed according to its documentation, this is the documented Humble build pattern:
mkdir -p ~/ws_livox/src
git clone https://github.com/Livox-SDK/livox_ros_driver2.git ~/ws_livox/src/livox_ros_driver2
cd ~/ws_livox/src/livox_ros_driver2
source /opt/ros/humble/setup.bash
./build.sh humble
source ../../install/setup.bash
ros2 launch livox_ros_driver2 rviz_MID360s_launch.pyDo not move directly from that launch command into a SLAM session. With the default driver configuration, inspect the topics and measure the stream that your actual installation produces. Topic names and configuration files can differ across revisions, so the robot should record what is truly running rather than what an older tutorial expected.
ros2 topic list
ros2 topic info /livox/lidar --verbose
ros2 topic hz /livox/lidar
ros2 topic info /livox/imu --verbose
What to validate in the message path
Confirm the point-cloud frame, the IMU frame, the base frame, and every transform between them. Track timestamps through the LiDAR message, the robot state estimator, and the mapping package. Retain the point fields the downstream package expects, and measure CPU, storage, and network load while recording a route. The ROS 1 FAST-LIO tutorials commonly found online are not a drop-in ROS 2 procedure; validate the middleware and mapping package together. For a detailed software path, see the separate MID-360S ROS 2, SDK2, and mapping guide.
SLAM and Localization Are Route-Level Tests
A LiDAR selection guide cannot certify a map. The useful review question is whether a robot can repeat its intended operating route while the full system handles the scene changes it will actually encounter. A clean map made at walking speed is not enough evidence for a delivery robot, industrial AMR, or outdoor service platform.
Build a route that intentionally includes long feature-poor sections, rack rows, doorway transitions, sharp turns, stops, reverse motion, reflective wrap, low items, and the maximum expected payload. Record more than a point cloud: include robot velocity, IMU, odometry, PTP state where used, diagnostics, message rate, localization residuals, and the decisions made by navigation. The goal is to learn which assumption fails first, then decide whether the solution is a mounting change, better transforms, different localization policy, another sensor, or a safer route constraint.
| Route segment | Why it matters | What a useful result looks like |
|---|---|---|
| Warehouse cross aisle | Tests wide geometry, perpendicular motion, and partial views around racking | Stable local pose without unexplained frame jumps or stale data warnings |
| Docking approach | Tests close pallet, cart, and floor-edge behavior | Robot policy remains conservative when near-field geometry is incomplete or ambiguous |
| Doorway and loading bay | Tests brightness, environmental texture, and indoor-outdoor transition | Expected performance is measured and documented across the real boundary |
| Recovery sequence | Tests power cycle, cable disturbance, link drop, and restart workflow | Defined degraded behavior and a repeatable return to service |
Where MID-360S Fits, and Where It Does Not
MID-360S is most compelling when the robot needs continuous surrounding 3D context in a compact, protected package. Typical fits include indoor logistics AMRs, warehouse towing platforms, service robots, inspection platforms, and low-speed outdoor robots that need to understand the area around their chassis rather than only a narrow forward corridor.
It is a less direct fit when the design needs a strongly directional sensing zone, substantially different range geometry, or a formally engineered protective function. In those cases, forcing a full-surround LiDAR into the architecture can complicate mounting and data processing without answering the actual requirement. A directional 3D LiDAR can be more appropriate for a single forward or side perception task. Safety architecture should be selected through a project-specific risk assessment, independent sensing and control requirements, stop behavior, and validation plan.
Livox MID-360S vs MID-70 vs RoboSense Airy 96
These are not interchangeable versions of the same sensor. Start with the volume the robot must see: a compact all-around envelope, a deliberately defined near-field sector, or a taller hemispherical volume. The figures below describe the published sensor geometry; the final robot package still determines what remains visible.
| Model | Published geometry | Where it is a strong fit | What the robot design must still address |
|---|---|---|---|
| Livox MID-360S | 360° × 59° surrounding view; 0.1 m published blind-zone boundary | Compact AMRs, AGVs, service robots, and low-speed robots that need surrounding SLAM and obstacle context | Roof occlusion, close-target validation, time alignment, and route-level SLAM testing |
| Livox MID-70 | 70.4° circular view; 0.05 m published minimum detection range | A defined forward or side near-field zone on a low-speed mobile robot | One sensor does not create all-around coverage; data at 0.05–0.2 m still needs installed-system validation |
| RoboSense Airy 96 | 96-channel hemispherical design with a 360° × 90° published FOV | Robots that benefit from taller vertical coverage and dense, structured surrounding 3D data | Sensor package, driver support, compute budget, field coverage, and the final perception architecture |
Selection shortcut: choose MID-360S when a compact all-around 3D envelope is the central requirement. Choose MID-70 when the task has a deliberately directional near-field zone. Put Airy 96 on the shortlist where vertical coverage and structured high-channel data influence mapping or obstacle interpretation. Compare the final installation, not product names alone.
Compare LiDAR Options for Mobile Robotics
Livox MID-360S 3D LiDAR Sensor for Autonomous Robotics & SLAM Navigation
For a compact robot that needs surrounding 3D geometry for navigation, localization, and obstacle context around the chassis.
View Product
Livox MID-70 Wide-Angle 3D LiDAR for Mobile Robotics
For a defined forward or side sensing zone where a directional field of view better matches the task than all-around coverage.
View Product
RoboSense Airy 96-Channel Hemispherical Digital LiDAR for Robotics
For mobile robots that need a larger vertical sensing envelope and a dense structured 3D view around the platform.
View ProductA Practical Acceptance Test Before Deployment
Before calling the robot ready, write down what “accepted” means. A useful acceptance test has a fixed bracket drawing, device identifier, firmware record, driver and configuration revision, map version, route, payload state, environment, pass criteria, and a record of failures. That turns a promising integration into something another engineer can reproduce after a service visit.
- Inspect the optics, bracket fasteners, cable gland, strain relief, and any new occlusion caused by a payload or accessory.
- Measure normal startup, power interruption, Ethernet reconnect, and time-synchronization recovery rather than assuming they work.
- Validate published near-field boundaries with low, thin, dark, and low-reflectivity targets relevant to the operating site.
- Run a representative route repeatedly with the intended speed, turn rate, payload, docking behavior, and lighting changes.
- Define the robot response to a lost stream, invalid timestamp, unexpected frame, or localization confidence drop before the first live deployment.
For projects that are still at the mounting-and-power stage, the MID-360S AMR integration guide expands the mechanical, electrical, and time-synchronization checklist. This review is deliberately broader: it asks whether the sensor, middleware, and real route form a dependable system together.
Livox MID-360S FAQ
Is Livox MID-360S a good LiDAR for AMRs?
It is a strong starting point for compact AMRs that need surrounding 3D geometry for localization, obstacle context, docking, and low-speed navigation. The fit still depends on the real mounting position, system timing, route, payload, and expected targets. A technical specification alone cannot establish field performance.
Does a 360° field of view remove all robot blind spots?
No. The nominal field of view can be blocked by the chassis, a payload, a bracket, cables, a protective cover, or the ground. Review the sensor volume in the robot frame and verify it with the final hardware.
Does the 0.1 m blind-zone specification guarantee close obstacle detection?
No. The published caution is important: accuracy at 0.1–0.2 m is not guaranteed, and low-reflectivity, thin, or small targets at 0.1–1 m can be difficult. Use a representative target set and a conservative robot policy for the installed geometry.
Does MID-360S work with ROS 2 Humble and Jazzy?
The Livox ROS Driver 2 documentation includes MID360S support, with documented paths for Humble on Ubuntu 22.04 and Jazzy on Ubuntu 24.04. Confirm the exact SDK2, driver release, launch file, message topics, and configuration used by the robot before deployment.
Can MID-360S be used as the only safety sensor on a mobile robot?
MID-360S supplies spatial data, but it does not establish a safety-rated protective function by itself. The final machine needs a project-specific risk assessment, suitable sensing and control architecture, defined fault behavior, stop strategy, and validation.
Is MID-360S a drop-in replacement for the previous MID-360?
Plan a migration test instead. Recheck the mechanical drawing, cable and power configuration, network addressing, firmware, driver version, launch configuration, point-cloud fields, time synchronization, transforms, and route performance. Matching form factor alone is not enough evidence.
What should be recorded before the robot reaches a customer site?
Record the device and firmware identity, mounting drawing, power measurement, network settings, driver and configuration revision, transform chain, time source, route definition, payload condition, target set, pass criteria, and observed recovery behavior. That record makes future service and regression testing much more tractable.
Technical references: Livox MID-360S product page, MID-360S specifications, Livox MID-70 product page, RoboSense Airy product page, MID-360S manuals and downloads, and Livox ROS Driver 2. Confirm values against the hardware, firmware, and document revision supplied with the ordered unit.
