Using a single costmap for local and global planner?

[Piyush]

Hi folks,

Jorge and I were doing some more tests using hydro-devel with the revised eband_local_planner approach. The way the eband approach works, it is necessary to have synchronized global and local costmaps at the time of plan generation (as the approach seamlessly integrates global planning and local navigation). 

The easiest way to do this to is to patch the navigation stack to use a single costmap for both the planner and the controller if requested. Would this be a worthwhile patch to hydro-devel? Are there any comments/questions?

Thanks!

Piyush

[David Lu!!]

The reason why there are two separate costmaps is to avoid localization issues. If you do local planning in the map frame, you can easily run into issues and obstacles. 

--
You received this message because you are subscribed to the Google Groups "ros-sig-navigation" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-navigat...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Piyush]

That's a great point. Our robots are Segway RMP based and have excellent odometry, and the localization does not jump. Consequently, I might not have noticed any problems running against a single costmap. I will have to run some experiments and reason about this.

Piyush

[Jorge Santos]

Right, I was thinking mostly on update rate but that's a stronger reason for separated maps.

Anyway, I'm using layered costmaps, that by now (afaik) cannot be cleared by the recovery behavior. I'm pretty sure the problem will lessen a lot if you can reset local costmap when eband planner fails.

As I must revert some robots to the pre layered-costmap navigation, I'll test eband on them on wensday.

[Dave Hershberger]

I think it would be a fine thing to have a shared costmap as an option for move_base.  It would save a bunch of computation and simplify configuration for those situations where it is applicable.

[Piyush]

Sounds good. I will explore this option this week.

Best,

Piyush

[Jihoon Lee]

Just curiosity. Where can I find a follow-up issue for this? shared costmap for both local and global costmap look interesting to check out.

Cheers,

Jihoon

On Tuesday, June 18, 2013 2:18:52 AM UTC+9, Piyush Khandelwal wrote:

Sounds good. I will explore this option this week.

Best,

Piyush

On Mon, Jun 17, 2013 at 11:56 AM, Dave Hershberger <he...@willowgarage.com> wrote:

I think it would be a fine thing to have a shared costmap as an option for move_base.  It would save a bunch of computation and simplify configuration for those situations where it is applicable.

On Sun, Jun 16, 2013 at 7:45 PM, Jorge Santos <jo...@yujinrobot.com> wrote:

Right, I was thinking mostly on update rate but that's a stronger reason for separated maps.

Anyway, I'm using layered costmaps, that by now (afaik) cannot be cleared by the recovery behavior. I'm pretty sure the problem will lessen a lot if you can reset local costmap when eband planner fails.

As I must revert some robots to the pre layered-costmap navigation, I'll test eband on them on wensday.

On Sat, Jun 15, 2013 at 6:28 AM, Piyush <piy...@gmail.com> wrote:

That's a great point. Our robots are Segway RMP based and have excellent odometry, and the localization does not jump. Consequently, I might not have noticed any problems running against a single costmap. I will have to run some experiments and reason about this.

Piyush

On Fri, Jun 14, 2013 at 3:36 PM, David Lu!! <davi...@gmail.com> wrote:

The reason why there are two separate costmaps is to avoid localization issues. If you do local planning in the map frame, you can easily run into issues and obstacles. 

On Fri, Jun 14, 2013 at 1:50 PM, Piyush <piy...@gmail.com> wrote:

Hi folks,

Jorge and I were doing some more tests using hydro-devel with the revised eband_local_planner approach. The way the eband approach works, it is necessary to have synchronized global and local costmaps at the time of plan generation (as the approach seamlessly integrates global planning and local navigation). 

The easiest way to do this to is to patch the navigation stack to use a single costmap for both the planner and the controller if requested. Would this be a worthwhile patch to hydro-devel? Are there any comments/questions?

Thanks!

Piyush

--
You received this message because you are subscribed to the Google Groups "ros-sig-navigation" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-navigation+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "ros-sig-navigation" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-navigation+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "ros-sig-navigation" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-navigation+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "ros-sig-navigation" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-navigation+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "ros-sig-navigation" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-navigation+unsub...@googlegroups.com.

[Piyush]

Unfortunately, I never followed up on this. It is still something I'm
interested in as well.

IIRC, you'll have to change move_base_node to provide the same costmap
to both planners.

Piyush

>>>>>>> send an email to ros-sig-navigat...@googlegroups.com.

>>>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "ros-sig-navigation" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it, send

>>>>>> an email to ros-sig-navigat...@googlegroups.com.

>>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "ros-sig-navigation" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send

>>>>> an email to ros-sig-navigat...@googlegroups.com.

>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "ros-sig-navigation" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send

>>>> an email to ros-sig-navigat...@googlegroups.com.

>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>
>>>>
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "ros-sig-navigation" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an

>>> email to ros-sig-navigat...@googlegroups.com.

>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "ros-sig-navigation" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to ros-sig-navigat...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Rein Appeldoorn]

Here is an example of such a system:

https://roboticssrv.wtb.tue.nl/svn/ros/user/Rein/rosbuild_packages/tue_vwm_navigation/cb_base_navigation/

Note that the interfaces of the global planner also changed a little bit and that a lot of state is removed compared to 'move_base'. This is still WIP but it might give you some insight in how to create such an implementation.

Cheers,

-Rein