ethz-asl / voxgraph

Voxblox-based Pose graph optimization
BSD 2-Clause "Simplified" License
522 stars 69 forks source link

lidar_odometry and coloring_point #61

Closed bulinx closed 2 years ago

bulinx commented 3 years ago

I'm sorry to ask this seemingly simple question. But I haven't found a solution for a long time. I have installed voxgraph and run the packages then have a good result, when I use my own packages there have many problems(my platforms: ubuntu18 melodic), I want to realized coloring lidar point to creat dense map.

1 : I change the odometry source to hdl-graph-slam, my hdl tf tree : image there I change the voxgraph_mapper.yaml to :

2: I change the source of dense (depth) data to my coloring-lidarpoint(In fact, it is the color point obtained by the projection between the lidar and the camera)

there I change the pointcloud_topic to /pcl_coloring/velodyne_coloured

my launch flies : image

My steps :

roslaunch hdl-graph-slam my.launch -----for lidar odometry

roslaunch coloring my.launch -----for coloring depth data

roslaunch voxgraph my.launch rosbag path := /my.bag ----run voxgraph

Final running result: image

my odometry and depth data all failed to input.

So I don't know how to run your code correctly with my package. Can you provide some solutions? Thank you very much.

victorreijgwart commented 3 years ago

From the TF tree it looks like the timestamps of velodyne_nodelet_manager are 1744584 seconds behind the rest of the system. Are you running voxgraph on a live robot, from a rosbag or in simulation? If you're running it from rosbag or in simulation, you should set the use_sim_time param to true before launching the other nodes. If you're running it from a rosbag, you should also supply it with the --clock argument.

bulinx commented 3 years ago

From the TF tree it looks like the timestamps of velodyne_nodelet_manager are 1744584 seconds behind the rest of the system. Are you running voxgraph on a live robot, from a rosbag or in simulation? If you're running it from rosbag or in simulation, you should set the use_sim_time param to true before launching the other nodes. If you're running it from a rosbag, you should also supply it with the --clock argument.

Sorry, I’ve updated the question again, I running voxgraph with my rosbag which Information collection performed by VLP-16, mono, and imu of my own robot. I will try your suggestion again. But I still have some questions above, apologies for the lengthy message and hope my questions are well defined!

victorreijgwart commented 3 years ago

In the rqt graph you shared, the pointcloud topic is not being subscribed to by voxgraph. Could you remove/disable the lidar_undistortion node in voxgraph's launch file, directly map the pointcloud topic to voxgraph itself, and let me know if the map then shows something?

victorreijgwart commented 3 years ago

Actually, when looking at it again, the rqt graph is inconsistent with your launch file screenshot. Are you sure you're launching your new launch file and not arche_demo.launch?

bulinx commented 3 years ago

Actually, when looking at it again, the rqt graph is inconsistent with your launch file screenshot. Are you sure you're launching your new launch file and not arche_demo.launch?

Yes, here is my carelessness. Through the correction I got the following result: image In rviz, I have changed different frame, there is no map have created : image At the same time, new questions occur, 1 : when I set the use_sim_time param to true: Warning: TF_OLD_DATA ignoring data from the past for frame velodyne at time 1.62027e+09 according to authority unknown_publisher Possible reasons are listed at http://wiki.ros.org/tf/Errors%20explained at line 277 in /tmp/binarydeb/ros-melodic-tf2-0.6.5/src/buffer_core.cpp [ WARN] [1622034890.251733233, 1620268800.756933632]: TF_OLD_DATA ignoring data from the past for frame velodyne at time 1.62027e+09 according to authority unknown_publisher Possible reasons are listed at http://wiki.ros.org/tf/Errors%20explained [ WARN] [1622034890.355459136, 1620268800.856683090]: Waited 0.260s, but still could not get the TF from base_link to odom [ WARN] [1622034890.355537069, 1620268800.856683090]: Skipping pointcloud since the poses at time 1620268799.595951319 could not be looked up. image

2 : when I set the use_sim_time param to false: image

So, It may be a problem with my tf tree construction?
Thanks again for your reply