VIO or LiDAR SLAM: choosing by environment and payload

1. Engineering problem

Visual-inertial odometry (VIO) and LiDAR SLAM fail in different places. A robot that works in a warehouse may fail in a dark corridor with plain walls or in an open field.

2. When is this needed?

• At the start of a project, from the ODD.
• When moving to a new site.
• When payload or power limits sensor choice.

3. Selection and design decisions

The VINS-Fusion README (read 2026-11-06) notes that VIO “heavily relies on hardware quality” and recommends global-shutter cameras and hardware-synchronised IMUs for good results. LiDAR methods (such as FAST-LIO or LIO-SAM) use geometry and are independent of lighting but need enough structure to constrain the scan match.

4. Advantages and disadvantages

• Fusing both covers each other’s failures and costs more integration and compute.
• Cost: cameras are cheap; capable LiDARs cost more.
• Map reuse differs: visual place recognition versus scan matching.

5. Requirements and constraints

• The ODD’s worst lighting and structure conditions are covered by at least one modality.
• Payload and power budgets are met.
• Time synchronisation and calibration are planned for each added sensor.

6. Architecture

ODD (light, texture, structure, payload) ─▶ advise ─▶ VIO | LiDAR SLAM | both ─▶ test in the worst-case place

7. Implementation

1. Write the ODD’s worst case for light, texture and geometric structure.
2. Run the advisor (below) for each worst case.
3. If one modality has a blocker in a case, add the other or change the choice.
4. Test each method in its worst case on recorded data.
5. Plan the failure response when one modality drops out.

def advise(lux, texture, structure, payload_kg):
    notes = []
    if lux < 50:
        notes.append("low light: camera-based VIO is at risk")
    if texture == "low":
        notes.append("low texture: few visual features")
    if structure == "low":
        notes.append("low geometric structure (long corridor, open field): LiDAR matching is under-constrained")
    if payload_kg < 0.5:
        notes.append("tight payload: a small camera and IMU fit, a 3D LiDAR may not")
    return notes or ["no obvious blocker for either method"]
for case in ((300, "high", "high", 5), (20, "low", "high", 5), (300, "high", "low", 5), (300, "high", "high", 0.3)):
    print(case, "->", advise(*case))

Printed (checked by the site’s tests):

(300, 'high', 'high', 5) -> ['no obvious blocker for either method']
(20, 'low', 'high', 5) -> ['low light: camera-based VIO is at risk', 'low texture: few visual features']
(300, 'high', 'low', 5) -> ['low geometric structure (long corridor, open field): LiDAR matching is under-constrained']
(300, 'high', 'high', 0.3) -> ['tight payload: a small camera and IMU fit, a 3D LiDAR may not']

Reading it: the first case has no blocker for either; a dark, textureless site flags VIO; a low-structure site flags LiDAR matching; and a 0.3 kg payload limit flags the 3D LiDAR. The thresholds (50 lux, 0.5 kg) are illustrative: derive yours from tests.

8. Real examples

• Warehouse AMR: LiDAR SLAM, indoor, structured shelves, lit.
• Small drone indoors: VIO if lit and textured.

9. Failure scenarios

• VIO in a dark corridor.
• 2D LiDAR matching in a long featureless hallway.
• Choosing from a demo video taken in a different environment.

10. Troubleshooting

1. If VIO loses tracking, check light, exposure and texture first.
2. If LiDAR SLAM slides in a corridor, add an IMU, odometry or another constraint.

11. Validation

• The advisor prints the lines shown (executed by the site tests).
• Each method is tested in the ODD’s worst case with recorded data.

12. Engineering checklist

• Worst case per dimension
• Blockers found
• Payload and power met
• Fallback defined
• Tested in the worst case

13. Further references

• READMEs of the projects, read 2026-11-06: slam_toolbox, ORB-SLAM3, LIO-SAM, FAST-LIO, VINS-Fusion.

Related on FixTheRobot