[ros-users] costmap grids

[Eitan Marder-Eppstein]

Nitin,

I've answered your questions inline below:

On Sun, Aug 8, 2010 at 10:43 PM, nitinDhiman <nitinkdhiman at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ros-users
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20100809/5f06468f/attachment-0003.html>