On Sun, Aug 8, 2010 at 10:43 PM, nitinDhiman <nitinkdhiman@gmail.com> wrote:

Hello friends,
As per my understanding (attained by looking at code and help pages),
current cost-map generation is predominantly one sensor based. We look at
only laser-scans and point clouds. Output is 2d grid.
I am looking to combine a occupancy grid from vision sensors and then
combine it with what CostMap2DROS produces.

The costmap supports multiple sensors, it just requires that each sensor pass data to it in the form of a PointCloud or LaserScan message. I've seen the costmap used with everything from sonar sensors, to lasers, to stereo cameras. See the observation_sources parameter for more details: http://www.ros.org/wiki/costmap_2d#Sensor_management_parameters. Also, depending on what value you set for the map_type parameter (http://www.ros.org/wiki/costmap_2d#Map_type_parameters), you can have a 2D or 3D representation of the world stored in the costmap. We choose to project the 3D grid down to 2D for more efficient planning, but all the raytracing for clearing obstacles and unknown space is done in 3D.

I have a few queries in general:

a. How to deal with different resolutions of grids when combining together?
One way i see is to publish a topic with values given by
Costmap2DROS::getResolution() . Is it correct way?

I'm not sure what you want do do here. You have a custom occupancy grid type that you want to merge with a costmap? In the node that holds the costmap? Or somewhere else? I think you may want to do this because you don't think the costmap can hook up to your vision sensors, but, if you get them to publish PointClouds, you should be able to make it work.

b. Inflation of obstacle costs: Will such solution lend well to non-square
vehicles? It may be possible for a vehicle to pass through narrow opening in
general but not when cost is inflated.

You're right in that the default global planner, Navfn, assumes a circular robot and therefore may be quite optimistic as the robot's footprint becomes less and less circle-like. When I've dealt with rectangular footprints in the past, I've tended to use a different global planner that accounts for the robot's footprint. In my case, that's the sbpl_global_planner. However, that package is unreleased, unstable, and unsupported so I don't recommend using it, but if you really need a global planner that uses the robot's footprint you could take a stab at it. Another option is to write your own global planner plugin which can do what you like.

One more navie question: Is it correct to say that each instantiation of
NodeHandle creates a new node everytime? This has arised while reading
move_base implementation.

There is only one node, the NodeHandles created in move_base simply access different parameter namespaces.

Hope this helps,

Eitan

Thank you
regards
Nitin
--
View this message in context: http://ros-users.122217.n3.nabble.com/costmap-grids-tp1051168p1051168.html
Sent from the ROS-Users mailing list archive at Nabble.com.

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
ros-users mailing list
ros-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ros-users
_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users