Using RVIZ to compute total square foot coverage

Hi,

I am very new to ROS and was passed an existing application surrounding a self-driving unit. The unit uses SLAM to create a persistent map and a coverage map with every new run. The developer created a topic called map_from_machine which shows the coverage of the robot on an RVIZ screen (pose, orientation, where it's been, etc.).

Is it possible to use RVIZ to compute the total cumulative square footage the unit has covered in Gazebo? I know the squares represent lengths, but for complex maps this is not feasible.

Looking for any feedback!

MAP EXAMPLE:

$C:\fakepath\map.PNG$

ROSMSG INFO:

$C:\fakepath\rosmg.jpg$

Thanks, Raj

Asked by nrjbs87 on 2019-09-13 07:28:48 UTC

Comments

Do you want the area of the generated Map? Or the length of the path it has driven? Or what exactly do you mean with "cumulative square footage the unit has covered"? Maybe an example image?

Asked by LeoE on 2019-09-13 07:51:00 UTC

Hi LeoE,

I tried to add a photo but I guess I am not experienced enough on this site to have access..? I would like to see the both the area of the map generated and how far the robot has driven. Imagine the robot was driving in a straight line, it would be easy to compute how far it went. In this application though the robot makes many turns so tracking that total distance is difficult. So yes to both your options :).

Asked by nrjbs87 on 2019-09-13 08:20:47 UTC

Hi, so what exactly is inside of "map_from_machine"? Is it the path it has driven and the explored map? Or how is the data organized? Also do you have access to the source code? Probably calculating it online during the exploration and adding this information to the "map_from_machine" is quite easy. Can you maybe include the msg from map_from_machine in your question?

Asked by LeoE on 2019-09-13 08:32:23 UTC

I don't have access to source code unfortunately. Looks like ros topic info map_from_machine shows it is using a nav_msgs/OccupancyGrid Message.

rosmsg show nav_msgs/OccupancyGrid shows:

std_msgs/Header header uint32 seq time stamp string frame_id nav_msgs/MapMetaData info time map_load_time float32 resolution uint32 width uint32 height geometry_msgs/Pose origin geometry_msgs/Point position float64 x float64 y float64 z geometry_msgs/Quaternion orientation float64 x float64 y float64 z float64 w int8[] data

Does this help?

Asked by nrjbs87 on 2019-09-13 08:44:39 UTC

I've given you enough karma to be able to upload the image now. Just to clarify something, RVIZ does include a very basic distance measuring tool. But you will probably need to write your own node to be able to collect the metrics you're describing here.

Asked by PeteBlackerThe3rd on 2019-09-13 08:45:14 UTC

Thanks Pete!! Added a photo. I figured I'd need to write some code, but not sure where to begin. The RVIZ tool will not help for anything that is not a square or rectangle.

Asked by nrjbs87 on 2019-09-13 08:49:16 UTC

Is it only one nav_msgs/OccupancyGrid? Or is there more data in the message? How often is it published? Because the nav_msgs/OccupancyGrid includes no data on your robots current position. In your uploaded image there is a path and some extra poses, where do they come from? They are not part of the map_from_machine topic, right?

Asked by LeoE on 2019-09-13 08:52:39 UTC

Does the geometry_msgs/Point position float64 x float64 y float64 z not tell us something? It looks like there are a few msg's inside the nav_msgs/OccupancyGrid message.

Asked by nrjbs87 on 2019-09-13 12:45:11 UTC

No, it is only part of the meta-data (see answer) and states the origin. the geometry_msgs/Point, together with the geometry_msgs/Quaternion, makes up a geometry_msgs/Pose and this is the origin. See the documentation of nav_msgs/OccupancyGrid There in the "Compact Message Definition" you can click on all field and look at them. In a nav_msgs/OccupancyGrid is no information of the position of the current robot.

Asked by LeoE on 2019-09-13 12:49:43 UTC

Added a photo of the output as well in post.

Asked by nrjbs87 on 2019-09-13 12:50:04 UTC

You can see the same in the link I just posted. But there is no information of the robots position in the map, it is only the map. Your rviz has to subscribe to something else as well.

Asked by LeoE on 2019-09-13 12:51:56 UTC

Answers

So to answer your first question regarding the path driven and its length: I would recommend having a look at this question or better the accepted answer. Instead of creating the path you can use it to get the euclidean distance between two robot poses and add it up. This returns you the current driven distance of the robot. If you already have a path (as it looks like on the image you posted) you could subscribe to this path and add up all positions as if you would using a subscriber. This would not make sense however, since the time to compute the distance increases with the length of the path.

Regarding the second question with the area explored by the robot, depending on the mapping algorithm, I see no other way than to analyze the map in each time-step. Assuming the robot uses gmapping for generating the map you could subscribe to the map output and see how many pixels (in int8 data[] of the OccupancyGrid) are not equal to -1. All those have been explored in some way. Each entry in data[] represents a pre defined area (default 0.05*0.05 m²) which you can find in the resolution of the MapMetaData (see here )

Asked by LeoE on 2019-09-13 09:11:35 UTC