# ROS map of environment?

Hello I am new to ROS

I found c++ code for different robotic path planning algorithms: A*, Dijkstra,….

https://github.com/vss2sn/path_planning

I am trying to improve the code to have GUI and also to use it in ROS

The map in this project is 2d vector of vector of integers, which has the same index notation for arrays(the yellow part in the image link below).

https://ibb.co/Lz6zDfL

in the file utils.cpp, in function GetMotion(), which gets the neighbors of any cell.

For example, based on the calculations done in operator+(Node p) function:

For the point (1,1) in the yellow part The down neighbor is (1,2)

The up neighbor is (1,0)

The left neighbor is (0,1)

The right neighbor is (2,1)

BUT, I think the down and up must be swapped to be consistent with left and right, so down becomes (1,0) and up becomes (1,2)

I am right?

NOTE: The pink part is the representation of any digital image. In ROS, maps are digital images.

My questions:

(1) If I take the c++ code and apply it in ROS. How could I deal with the map.

In ROS, I have to specify the :

origin : The 2-D pose of the lower-left pixel in the map, as (x, y, yaw), with yaw as counterclockwise rotation (yaw=0 means no rotation). Many parts of the system currently ignore yaw.

So In ROS:

The origin will be : (4,0) as in the vector of vector of int, OR (0,4) as in the digital image ?

(2) Will the c++ code change if I use it in ROS?

I mean (1,2) in c++ code (yellow part) differs from (1,2) in ROS digital image representation

edit retag close merge delete

Sort by » oldest newest most voted

I'm not sure I have completely understand your issue but here some insights : try not to represent the environment and the neighbors with up, left, right and down but instead use the axis of the frame of reference because it can also depends of the convention you use. For example, for a map in ROS if you check the REP-103 moving forward is increasing data along x-axis and going left is increasing data along the y-axis, depending of the convention you use it can be differents north/east/west/south but in the end the data is correctly increased/decreased on the propper axis. In utils.cpp l77 you have : Node up(0,-1,1,0,0,0);, meaning that up is decreasing data along the y-axis, if you check the three other declarations you can find that what you call the pink part actually represents how your path planning algorithms represent up, down, left and right. The yellow part is actually how maps are represented in ROS.

With that in mind :

If I take the c++ code and apply it in ROS

There shouldn't be some issues, even though the spatial representations are not the same in the end it just calculates a path based on the input you give. If the up isn't the same as you think but the algorithm calculates that the robot should go up, the coordinate that the algorithm considers to be up would match your map.

About the origin, it can be anything you want, the origin defined in ROS is just corresponding to the first cell of the map data array. In ROS the occupancy grid is a 2D-array and you can find the link between a coordinate and index with those formulas :

index = floor((x - x_origin)/resolution) + floor((y - y_origin)/resolution)*map_width
x = (index % width) * resolution + x_origin
y = ((index - (index % width)) / resolution) + y_origin

more

Many thanks for clarifying.

This is what I understand, please correct me if I am wrong:

• ROS use the map(the occupancy grid image file) as 2d vector of integers, in ymal file we need to specify the origin(in http://wiki.ros.org/map_server)

origin : The 2-D pose of the lower-left pixel in the map, as (x, y, yaw), with yaw as counterclockwise rotation (yaw=0 means no rotation).

So, in the image

https://ibb.co/mGBHB8C

If I want the blue part to be my map ==> the map origin is (9,4) is that correct?

• The x and y axis differs based on the robot orientation(robot has its own xy axis), forward x(green arrow) and left y(red arrow). As in image above. But,the project in https://github.com/vss2sn/path_planning does not consider the orientation, and it seems that they assume the orientation ...
(more)
( 2019-11-28 06:42:41 -0500 )edit