Feasibility of replacing MID-360 with Livox Avia

[Yccmv]

Hi all,
I plan to buy a Livox Avia for the better range and point density instead of the MID-360, but I have two quick technical queries before proceeding:

Indoor Drift / Robustness
Has anyone successfully deployed this handheld system with a Livox Avia? Given the Avia's narrower FoV (~70°), have you experienced significant issues with rotational drift or tracking loss in confined indoor spaces (e.g., tight corners, long corridors) compared to the MID-360?

Configuration
I assume I need to switch the livox_ros_driver2 configuration file. The MID-360 typically uses a specific config type (e.g., xfer_format: 0 or specific LIDAR_TYPE). Does the Avia require a different point cloud format (e.g., CustomMsg vs PCL) for this pipeline to ingest the data correctly? Besides updating extrinsics (R,T) in the yaml config, does the backend require specific tuning for the Avia's non-repetitive pattern, or is it sufficient to just update the livox_ros_driver2 to publish the correct CustomMsg?

Thank you in advance for your support!!

[JanuszBedkowski]

I observed some difficulties for AVIA in indoor. Recently we published this https://www.mdpi.com/1424-8220/26/1/63

[Yccmv]

Thanks for sharing the paper/preprint. The results (1.50 cm RMSE on DBH) are impressive and confirm the hardware capabilities.

My rationale for the Avia is exactly aligned with your findings: I need that higher precision, point density, and longer range for large-scale mapping, while keeping the budget in the "low-cost" range.
However, I noticed the paper focuses on a static multi-scan approach (TLS) (likely to mitigate the 70° FoV limitations).

Since my goal is mobile handheld mapping (continuous SLAM), do you have any specific suggestions for maintaining robust tracking with the Avia while moving?
(e.g., specific scanning motion patterns to compensate for the narrow FoV, or specific tuning in the config file to trust the IMU more during rotations?)

[JanuszBedkowski]

I have this working prototype. What data You need to check?

[Yccmv]

That prototype looks great!!

• Could you just share the config files (.yaml and launch files) you are using for the Avia?
• If you have any existing raw sample on hand (even the forest dataset from the paper would be perfect), could you share a link?

I would like to verify that I can run the pipeline correctly with the Avia data structure on my machine before buying the sensor...

[JanuszBedkowski]

I am using https://github.com/[JanuszBedkowski/mandeye_controller](https://github.com/JanuszBedkowski/mandeye_controller)

there is no .yaml and launch files

[JanuszBedkowski]

https://github.com/JanuszBedkowski/mandeye_controller

[JanuszBedkowski]

https://github.com/JanuszBedkowski/mandeye_controller/tree/livox_sdk_1

[JanuszBedkowski]

I asked Michal for help, hopefully he will give some advice

[JanuszBedkowski]

I will make data tomorrow.

[Yccmv]

you are fantastic !
Thank you, Janusz, for your availability. It will be incredibly valuable to verify your data.
I also took a look at the mandeye_controller repo.. so the interfaces directly with the SDK (bypassing the standard ROS driver overhead), which explains why there are no standard launch files on the acquisition side.
I will wait for the data and Michal's advice. Standing by!

[JanuszBedkowski]

what LIO are You using?

[Yccmv]

I plan to use FAST-LIO2 (like livo-handheld implementation).
So I think i would need the rosbag to contain the livox_ros_driver/CustomMsg topic (and the IMU topic), for FAST-LIO.

[JanuszBedkowski]

Tomorrow I will show You how to use this software with AVIA. You can always convert data to ROS with https://github.com/MapsHD/mandeye_to_bag

[Yccmv]

thanks!
however the data format dictates which SLAM algorithm is possible to run successfully, especially for handheld Avia setups.

• Ideal Scenario FAST-LIO2 or Point-LIO
  These should require livox_ros_driver/CustomMsg with per-point timestamps. This allows for IMU-based deskewing, which is crucial to fix the motion blur caused by the Avia's 100ms integration time. This setup should eliminates the "indoor drift" you mentioned(?)

• Fallback Scenario (KISS-ICP):
  If mandeye_to_bag only outputs standard sensor_msgs/PointCloud2 (without per-point time), I will have to resort to algorithms like KISS-ICP. but could struggle more with the Avia's narrow FoV in tight corridors without proper deskewing.

So, for tomorrow's demo, if you can ensure the raw timestamps are preserved (or convertible to CustomMsg), we can unleash the full potential of the sensor.
If not, I'll test with generic PointCloud2 solvers, but we should expect higher drift.

Since I do not have the Avia hardware yet, I will rely entirely on the rosbag you generate with mandeye_to_bag to validate the pipeline.

[JanuszBedkowski]

did You see this
https://github.com/MapsHD/HDMapping/blob/main/images/bunker1.png