ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
1 | initial version |
Do you launch robot launch file before client launch file? Can you try under rtabmap node to remap move_base
to /planner/move_base
instead of /planner/move_base/
?
The warning on the robot is ok for the beginning when rtabmap is not started yet (/map
is not yet published).
Last observation, rgbd_odometry is too slow (1.4 Hz). The robot will get lost very often. Consider using back rosaria for odometry instead. To do visual odometry on RPI3, see this post, which decimates the images to reduce computation power required and increase frame rate. In that post, 175 ms is required for odometry, though it is maybe okay for very low cost hand-held scanner, it is still slow for a robot.
Another option, if you can publish the RGB/depth images over 10 Hz to remote computer (though I don't think it is possible with RPI3), you may do visual odometry on client instead (though it is not very safe for move_base if wifi connection is not always good). See Remote Mapping tutorial for an example.
At your place with computation power you have on the robot, I would stick with rosaria for odometry, and try to improve their code (or parameters) or combining it with an IMU if it is drifting too much.
cheers,
Mathieu
2 | No.2 Revision |
Do you launch robot launch file before client launch file? Can you try under rtabmap node to remap move_base
to /planner/move_base
instead of /planner/move_base/
?
The warning on the robot is ok for the beginning when rtabmap is not started yet (/map
is not yet published).
Last observation, rgbd_odometry is too slow (1.4 Hz). The robot will get lost very often. Consider using back rosaria for odometry instead. To do visual odometry on RPI3, see this post, which decimates the images to reduce computation power required and increase frame rate. In that post, 175 ms is required for odometry, though it is maybe okay for very low cost hand-held scanner, it is still slow for a robot.
Another option, if you can publish the RGB/depth images over 10 Hz to remote computer (though I don't think it is possible with RPI3), you may do visual odometry on client instead (though it is not very safe for move_base if wifi connection is not always good). See Remote Mapping tutorial for an example.
At your place with computation power you have on the robot, I would stick with rosaria for odometry, and try to improve their code (or parameters) or combining it with an IMU if it is drifting too much.
cheers,
Mathieu