Hi Anthony,
[0] Based on your previous messages, I'll assume that you have icp_odometry and rtabmap nodes. You can skip icp_odometry if you want and feed your odometry directly to rtabmap. I this case, if scans are also sent to rtabmap node, we can enable RGBD/NeighborLinkRefining to correct the input odometry at rtabmap update rate (refining odometry based on last and current scan). RGBD/NeighborLinkRefining is not nesscarly if icp_odometry is used.
With icp_odometry, if you feed odomety to it, it will be used as guess for ICP. Without input odometry guess, icp_odometry will use a constant motion model to guess the next position for ICP (this is explained in section 3.1.2 of this
paper). In some cases, the result will be the same [1]. When you feed IMU to icp_odometry, similarly to odometry guess, it will use it to guess the rotation for next ICP. If you feed odometry to icp_odometry, IMU will be ignored as the whole guess is taken from input odometry (unless for rgbd_odometry and stereo_odometry where IMU can be used in bundle adjustment). For example, a T265 feeds its odomety to icp_odometry, icp_odometry uses it to set the first guess for ICP, then does ICP and outputs the result of ICP.
[2] If your odometry includes already IMU measurements (like a VIO approach), icp_odometry will use guess odom and IMU exactly the same way, though with odometry the translation can be also used for guess.
[3] For rtabmap node, you can use the topic or TF. If odom_frame_id parameter is set, rtabmap will use TF to get odometry. The odometry covariance can be then fixed with odom_tf_angular_variance and odom_tf_linear_variance. When the odometry topic is used, the twist covariance of the topic is used directly.
cheers,
Mathieu