I am using rtabmap/rtabmap_ros for a homemade 3D printed skid-steer rover that I am using at home intended to be used as the mobile base for a variety of future projects for both indoor and outdoor projects. Right now I am working on getting the robot to reliably localize itself in my house by using a Pixhawk+CubeOrange+mavros combo for performing the robot localization (via EKF3) and motor control. Everything else (the robot brains), is done on a Jetson TX2 (and an optional RPi4 which I predict will be needed later on for supporting future projects like beer retrieval :P). My current setup uses your rgbd_odometry ROS node as the front end visual odometer (either F2M or ORB_SLAM2) which outputs a 3D estimated pose (via mavros) to be fused with the wheel encoders and IMU, by the EKF running on the Pixhawk. The Pixhawk's EKF in turn outputs the final estimated pose of the robot (via mavros) to your rtabmap node, which I use for running the backend SLAM and pose (via map->odom tf) corrections.
All of this, in combination with move_base, is what I have been using to send the robot to various locations in my office, and I have been very happy with all the work you are doing with rtabmap and the performance of it with my setup so far. The only thing that I have been trying to work out recently is better handling of the visual odometer (VO) losing track during zero-point and/or fast turns. Among many other things, my current solution has been to make move_base send relatively conservative (i.e. slower) velocity commands to the Pixhawk for controlling the motors. Although, the VO will still lose track sometimes, depending on the visual scenario, the final EKF-fused pose of the robot has been relatively reasonable when I manually control the robot in a 2 x 2 meter box. One thing I recently stumbled upon (today), was the ORB_SLAM3 algorithm which, judging from the Youtube video I saw, seems to handle fairly well fast rotational camera motions. Since I am a strong supporting on the use of rtabmap for robot localization, I was wondering if supporting the use of ORB_SLAM3 is something you might consider? If not, how might I go about integrating this new VO method (or any other VO method for that matter) into rtabmap?
control the robot slowly and I have to say that I am a strong advocate for rtabmap, since (so far) has worked the best at helping my robot to localize itself.
I am using rtabmap/rtabmap_ros for a homemade 3D printed skid-steer rover that I am using at home intended to be used as the mobile base for a variety of future projects for both indoor and outdoor projects. Right now I am working on getting the robot to reliably localize itself in my house by using a Pixhawk+CubeOrange+mavros combo for performing the robot localization (via EKF3) and motor control. Everything else (the robot brains), is done on a Jetson TX2 (and an optional RPi4 which I predict will be needed later on for supporting future projects like beer retrieval :P). My current setup uses your rgbd_odometry ROS node as the front end visual odometer (either F2M or ORB_SLAM2) which outputs a 3D estimated pose (via mavros) to be fused with the wheel encoders and IMU, by the EKF running on the Pixhawk. The Pixhawk's EKF in turn outputs the final estimated pose of the robot (via mavros) to your rtabmap node, which I use for running the backend SLAM and pose (via map->odom tf) corrections.
All of this, in combination with move_base, is what I have been using to send the robot to various locations in my office, and I have been very happy with all the work you are doing with rtabmap and the performance of it with my setup so far. The only thing that I have been trying to work out recently is better handling of the visual odometer (VO) losing track during zero-point and/or fast turns. Among many other things, my current solution has been to make move_base send relatively conservative (i.e. slower) velocity commands to the Pixhawk for controlling the motors. Although, the VO will still lose track sometimes, depending on the visual scenario, the final EKF-fused pose of the robot has been relatively reasonable when I manually control the robot in a 2 x 2 meter box. One thing I recently stumbled upon (today), was the ORB_SLAM3 algorithm which, judging from the Youtube video I saw, seems to handle fairly well fast rotational camera motions. Since I am a strong supporting on the use of rtabmap for robot localization, I was wondering if supporting the use of ORB_SLAM3 is something you might consider? If not, how might I go about integrating this new VO method (or any other VO method for that matter) into rtabmap?
control the robot slowly and I have to say that I am a strong advocate for rtabmap, since (so far) has worked the best at helping my robot to localize itself.