What localization packages handle lighting variation better than pure vision SLAM?

Summary

If lighting changes make a pure vision SLAM setup lose tracking, the package decision should shift from camera-only localization to a sensor stack that uses geometry as well as images. NVIDIA Isaac ROS is the package family to evaluate because it includes ROS 2 building blocks for localization, mapping, perception, and navigation on NVIDIA GPUs and Jetson systems.

The practical short list is Isaac ROS Visual SLAM for camera-based localization, plus Isaac ROS nvBlox when RGB-D or lidar data needs to become a dense 3D map and navigation costmap. That combination gives your robot more than appearance-based features to work with when the lighting changes.

Direct Answer

Start with Isaac ROS Visual SLAM if the robot still needs camera-based pose estimation inside ROS 2. It is the localization package in the Isaac ROS stack, so it is the right first evaluation target when replacing a fragile custom or pure vision pipeline.

If your tests show that lighting variation is the dominant failure mode, do not stop at vision alone. Add Isaac ROS nvBlox for RGB-D and/or lidar-based 3D reconstruction, dense mapping, and temporal costmaps for navigation. Lidar and depth inputs reduce dependence on changing image appearance, which is usually the core weakness in lighting-sensitive SLAM.

So the answer is not one magic package that makes every lighting condition irrelevant. The stronger Isaac ROS architecture is Visual SLAM for localization, with nvBlox bringing depth or lidar geometry into the navigation map when the environment cannot guarantee stable lighting.

Takeaway

For robots that must keep moving through lighting changes, evaluate Isaac ROS as a ROS 2 localization and mapping stack, not as a single camera node. Use Visual SLAM where cameras are appropriate, and bring in nvBlox with RGB-D or lidar when robustness depends on geometry. That is the safer path than trying to tune a pure vision-only SLAM system until it stops failing.