Oak-D-Lite vs Oak-D-W vs Oak-D-W-97 - optimizing RTABmap

[cyclicalobsessive]

I have been attempting to use RTABmap with a Luxonis Oak-D-Lite mounted on a Create3 platform.

Due to issues with the Create3 platform locking up when I launch the depthai_ros_driver node and the rtabmap node, I had to turn off the Create3 IMU to achieve my first minimal success.  (Create3 stops responding for 10 seconds at a time, but I was able to get what appears to be a 3D cloud that matches the RGB)

My particular Oak-D-Lite does not have an IMU, so I am contemplating purchasing a new Oak-D-Lite with an IMU, or the wider angle Oak-D-W (12MP RGB) or Oak-D-W-97 (ony 1MP RGB).

My robot does not have a 2D LIDAR scanner.  I hope to be able to enable localization and obstacle avoidance without a LIDAR.

Does anyone have a feel for the impact of each of the following on RTABmap quality (not as concerned about speed)?
- IMU versus no IMU
- 12MP RGB (4056x3040) vs 1MP RGB (1200x800)  
- 640x480 Stereo Depth vs 1200x800 Stereo Depth

Running the Oak-D-Lite camera node and RTABmap nodes on a Raspberry Pi5 is using roughly 50% of the processor.

[matlabbe]

The IMU is not that useful if you are going to map only in 2D (with Reg/Force3DoF=true). The internal create3 IMU may be useful for wheel odometry / IMU fusion (for better yaw estimation). Don't know if Create3 default odometry is computed like that though.

From rtabmap point of view, RGB/depth resolution doesn't really matter, but FOV does (larger is better) and depth accuracy. Depth would be more accurate on larger resolution.

Global shutter RGB is also better than rolling shutter.