# 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:

ROSMSG INFO:

Thanks, Raj

edit retag close merge delete

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?

( 2019-09-13 07:51:00 -0500 )edit

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 :).

( 2019-09-13 08:20:47 -0500 )edit

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?

( 2019-09-13 08:32:23 -0500 )edit

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?

( 2019-09-13 08:44:39 -0500 )edit
2

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.

( 2019-09-13 08:45:14 -0500 )edit

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.

( 2019-09-13 08:49:16 -0500 )edit

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?

( 2019-09-13 08:52:39 -0500 )edit

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.

( 2019-09-13 12:45:11 -0500 )edit

Sort by » oldest newest most voted

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 )

more