Inconsistent launch and mapping in RViz with Kinect

asked 2019-05-26 11:08:35 -0500

etorobot gravatar image

First is the Kinect using roslaunch freenect_launch freenect.launch depth_registration:=true,

followed by rtabmap and rviz with roslaunch rtabmap_ros rgbd_mapping.launch rtabmap_args:="--delete_db_on_start" rviz:=true rtabmapviz:=false.

It does work, launching rviz and building a 3D map (and even 2D if the proj_map topic is added), but it's inconsistent. The error could be in the one or more of the Displays: PointCloud, TF, or Global Options, or Status (the fixed frame [map] does not exist, same with proj_map if added during the errors. The errors may fluctuate, even with a successful launch, and a couple of the displays flicker red (error) while everything seems fine.

Any ideas as to why it's perfect sometimes and fails the rest of the time (with no changes)? And how, if possible, it could be fixed?

edit retag flag offensive close merge delete

Comments

1

If you're using the setup you describe in #q323569, then I would suggest looking into synchronisation of the clocks of all involved hosts. Especially if you're getting warnings/errors about TF frames not existing / requiring extrapolation into the past / future.

gvdhoorn gravatar imagegvdhoorn ( 2019-05-26 12:58:21 -0500 )edit

@gvdhoorn I'm using the Acer (currently master, with hostname) offline due to network/router issues, and testing through handheld mapping. this isn't the final setup

etorobot gravatar imageetorobot ( 2019-05-26 13:57:52 -0500 )edit

@matlabbe probably knows more here, but it may be that there are too few features for rtabmap to successfully perform its VO duties.

gvdhoorn gravatar imagegvdhoorn ( 2019-05-27 02:29:23 -0500 )edit

See Lost Odometry section here: https://github.com/introlab/rtabmap/w... Use also rtabmapviz to see if you have red screens. To recover from that, we should move back the camera where it got lost.

matlabbe gravatar imagematlabbe ( 2019-05-30 09:30:03 -0500 )edit

@matlabbe the lost odometry red screen is not necessarily the issue here, although the reset_odom service got it working one time.

The 'red' referred to is under the Displays panel, the "PointCloud2" and "TF" in the list. The text itself is what flickers red, to show there's an error. The PointCloud2 and TF statuses could go from 'Ok' to 'Error' at any time, for no obvious reason. With PointCLoud2, the error message is under Status>Transform [sender=unknown_publisher]

For frame [camera_rgb_optical_frame]: No transform to fixed frame [map]. TF error: [Lookup will reauire extrapolation into the future. Requested time xxx.xxx but the latest data is at time xxy.zbd (there is a differnece), when looking up transform from frame [camera_rgb_optical_frame] to frame [map]]

A couple times, a few seconds after it went red (not flashing), it restored to normal (blue), and status returned to 'Ok', and mapping continued

@gvdhoorn ...(more)

etorobot gravatar imageetorobot ( 2019-06-01 11:59:22 -0500 )edit

When /map to camera frame is not found, the TF tree may be broken with a node not publishing a transform. As you have problems with odometry, it may be because /odom to camera frame is not published because odometry is lost. Setting Odom/ResetCountdown parameter to 1 will automatically reset the odometry for you when lost. However, it is better to never have odometry lost! What is the environment? Are there a lot of visual features that the camera can always see (no white walls)? If your environment is lacking visual features, I suggest to use wheel odometry instead of visual odometry, or if you have a lidar, then using lidar odometry (as long as there is geometry in the environment).

matlabbe gravatar imagematlabbe ( 2019-06-02 16:18:53 -0500 )edit

@matlabbe it's hand-held mapping. the kinect hasn't even been attached to the robot yet. environment is a small room, with minimal whitespace.

etorobot gravatar imageetorobot ( 2019-06-04 07:39:59 -0500 )edit

I suggest to use rtabmapviz to see better when odometry gets lost, as with rviz it is not that obvious. When you will use the robot, if it has wheel odometry, the robot should not get lost anymore.

matlabbe gravatar imagematlabbe ( 2019-06-04 17:38:39 -0500 )edit