praveen-palanisamy / multiple-object-tracking-lidar

C++ implementation to Detect, track and classify multiple objects using LIDAR scans or point cloud
MIT License
796 stars 229 forks source link

Visualise Output in RViz #42

Closed Surajj4837-th closed 3 years ago

Surajj4837-th commented 3 years ago

This is similar to #33. But it was left unanswered so opened similar issue. Please explain how to visualise the output clusters. All the topics are appearing in RViz and only /filtered_cloud topic's data is visible, how to see the final output(clusters)?

image

praveen-palanisamy commented 3 years ago

Hi @Surajj4837-th , your screenshot doesn't show if/what data is published to the /filtered_cloud ROS topic which is the required input before you can see any output from this ROS node on RViz.

Could you make sure you are publishing your point cloud to the filtered_cloud topic and are running the kf_tracker node (rosrun multi_object_tracking_lidar kf_tracker)?

Surajj4837-th commented 3 years ago

I m able to visualise the /filtered_cloud data as below. image

praveen-palanisamy commented 3 years ago

Okay good to see. Are you also running the kf_tracker node (rosrun multi_object_tracking_lidar kf_tracker)? If all is well, you should see data on these topics: obj_id, cluster_0, cluster_1, …, cluster_5. If not, could you post the output from the tf_tracker node?

Surajj4837-th commented 3 years ago

The rosrun multi_object_tracking_lidar kf_tracker is running: image

It is printing lot of data on screen, here is the some of it: minIndex=2,5 Received minIndex=2,5 clusterCount=4 findIndexOfMin cALLED minEl=3.40282e+38 minIndex=0,4 Received minIndex=0,4 clusterCount=5 filterN=0 filterN=1 filterN=2 filterN=3 filterN=4 filterN=5 distMat.size()6 distMat[0].size()6 30.2337 18.9655 10.8738 17.3644 22.2284 14.7323 45.6086 18.984 21.9845 19.2437 13.4239 25.5487 27.9296 22.4994 6.15419 21.1029 18.3425 10.2841 40.2809 10.3622 18.4184 9.40051 21.3166 22.6616 30.4465 19.4718 9.237 18.0428 19.4408 13.3678 25.334 28.9543 2.88143 27.7678 14.4805 5.1217 findIndexOfMin cALLED minEl=3.40282e+38 minIndex=5,2 Received minIndex=5,2 clusterCount=0 findIndexOfMin cALLED minEl=3.40282e+38 minIndex=3,3 Received minIndex=3,3 clusterCount=1 findIndexOfMin cALLED minEl=3.40282e+38 minIndex=2,5 Received minIndex=2,5 clusterCount=2 findIndexOfMin cALLED minEl=3.40282e+38 minIndex=1,4 Received minIndex=1,4 clusterCount=3 findIndexOfMin cALLED minEl=3.40282e+38 minIndex=0,1 Received minIndex=0,1 clusterCount=4 findIndexOfMin cALLED minEl=3.40282e+38 minIndex=4,0 Received minIndex=4,0 clusterCount=5

Surajj4837-th commented 3 years ago

rostopic echo command is also printing the data from /cluster_x topics. One of the example is as follows:

image

praveen-palanisamy commented 3 years ago

Al right. In that case, add the viz topic on RViz so that RViz subscribes to the MarkerArray that's being published. As long as your TF frame is setup fine so that the Markers frame is reachable with a transform from your velo_link fixed frame, you should see the markers on the tracked object display on RViz in view.

Surajj4837-th commented 3 years ago

I don't see anything after adding MarkerArray and viz topic.

praveen-palanisamy commented 3 years ago

Please add screenshots to debug. If the markers are not in the view, make sure your TF tree is setup correctly. Does the tracked cluster centroid values make sense in terms of relative position to the origin of your point clouds?

Surajj4837-th commented 3 years ago

image

I will check TF tree setup.

Surajj4837-th commented 3 years ago

All the links are being displayed, does that confirm TF tree is correctly setup? image

/tf messages are also getting displayed: image

praveen-palanisamy commented 3 years ago

From your screenshot in this: https://github.com/praveen-palanisamy/multiple-object-tracking-lidar/issues/42#issuecomment-793403873 There seems to be an error as shown on your RViz window (left panel): The MarkerArray Status: Error Could you fix the error on your end and try? Also try using base_link as the fixed frame instead of velo_view

Surajj4837-th commented 3 years ago

Sure, I will try to resolve: The MarkerArray Status: Error.

Surajj4837-th commented 3 years ago

The /cluster_x topic is sending information to '/map' frame. image

Such frame does not exist as shown below. Is this the problem?

image

Available frames are: base_link camera_color_left camera_color_right camera_gray_left camera_gray_right imu_link velo_link

The /filtered_cloud is linked to velo_link frame: image

praveen-palanisamy commented 3 years ago

Ah! Yes, /map is the assumed ground plane. If you don't have a map, you could you try to relay the z=0 plane from your velo_link topic on /map. In general, you could do that using the relay node from topic_tools Something like this on the command-line: rosrun topic_tools relay velo_link map

Surajj4837-th commented 3 years ago

Thanks @praveen-palanisamy for instant replies you provided till now. Alas I was not able to understand the previous suggestion you provided. The relay approach you are suggesting according to the docs in the link provided it just grabs data from a topic and puts in to another topic, I m still confused how that will resolve the issue, I tried doing that but it was in vain.

praveen-palanisamy commented 3 years ago

Thanks for the feedback. I wasn't verbose enough with the suggestion I was making. I'll elaborate on my suggestion below but, consider this as just a way to get around the problem as not the best.

The kf_tracker node process and publishes the tracked clusters and the corresponding markers for visualization assuming there's some type of occupancy grid map that exists (Typically on the /map topic). This map could be from your custom mapping algorithm or from any of the map server nodes from the ROS navigation stack. From your screenshot, it looked like you were not running a mapping node or a navigation stack that produces the map data. Rather than asking you to produce a map, I was suggesting to convert your laser scan data into a simple occupancy grid. The simplest of that would be to take a planar scan (e.g. the x-y plane with z=0) and publish that as an OccupancyGrid message on the /map topic with appropriate header for TF in order to see the markers relative to the plane/frame of reference.

Surajj4837-th commented 3 years ago

Okay, so /map topic corresponds to occupancy grid and is one of the requirement from user end, but your readme https://github.com/praveen-palanisamy/multiple-object-tracking-lidar#supported-point-cloud-streamssources says point cloud data is enough as input.

Yes, I don't have a mapping node currently.

One more way I was thinking to get around this is to dump the produced cluster data offline in a rosbag and then try visualise it with proper TF header.

Surajj4837-th commented 3 years ago

I introduced a blank map frame now with some tf and linked it to base_link using following command:

rosrun tf static_transform_publisher 0 0 0 0 0 0 base_link map 10

It is appearing in the Fixed Frame drop down menu as well and in tf tree.

image

But still the things remain unchaged.

praveen-palanisamy commented 3 years ago

I may not have stated it clearly. The Marker Arrays published for visualization purposes assume there's a /map frame (the cluster's ref frame matches with this). I updated my earlier comment (edits in Italics) to improve clarity. this ROS package needs only the point cloud for its operation as stated in the README. I should probably add about the /map to the README. The reliance on /map for visualization was taken due to the nature of this Node being used with some Navigation stack that uses/produces a map but, your idea of using the tracker's output and a stand-alone visualization with appropriate transforms will work regardless.

Surajj4837-th commented 3 years ago

Thank you @praveen-palanisamy for clarification, I will try to visualise the clusters by dumping them offline, I hope this works.

brianjzhang commented 3 years ago

Whoops, should have checked the issue list before submitting my own issue. I have a possible fix for this problem in #45 if the transforms have already been set properly.