Inflation remain in rviz

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Inflation remain in rviz

Zhiping
Hi to all,

I'm currently trying to navigate the office environment using move_base and hokuyo laser sensor.
I noticed that the dynamics inflation result remained in the map although its corresponding laser data is removed from Rviz due to the range limitation of the scanner.

What approach should i use to ensure the dynamic inflation result is removed together with its corresponding laser data?

With thanks,
Zhiping
Reply | Threaded
Open this post in threaded view
|

Re: Inflation remain in rviz

Eitan Marder-Eppstein
Zhiping,

By default, the navigation stack keeps obstacles in its costmap until a sensor sees through them. Are you sure that you have your laser set up to both mark and clear space? Without allowing the laser to clear, you won't clear out obstacles in the map. Also, if your laser is returning max-range values, they're likely being filtered out and not used for clearing space. This could also cause obstacles to stick around unexpectedly. Documentation on the "marking" and "clearing" parameter options for a costmap sensor source may also be useful, see: http://www.ros.org/wiki/costmap_2d#Sensor_management_parameters

Hope this helps,

Eitan

On Tue, Feb 1, 2011 at 7:20 AM, Zhiping <[hidden email]> wrote:

Hi to all,

I'm currently trying to navigate the office environment using move_base and
hokuyo laser sensor.
I noticed that the dynamics inflation result remained in the map although
its corresponding laser data is removed from Rviz due to the range
limitation of the scanner.

What approach should i use to ensure the dynamic inflation result is removed
together with its corresponding laser data?

With thanks,
Zhiping
--
View this message in context: http://ros-users.122217.n3.nabble.com/Inflation-remain-in-rviz-tp2397864p2397864.html
Sent from the ROS-Users mailing list archive at Nabble.com.
_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users


_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: Inflation remain in rviz

clarkwu
Eitan,

Thanks for your reply.

To further explain the problem zhiping and I were facing, here is the youtube link on what we observed:
http://www.youtube.com/watch?v=UUZe5XrYBaM

In the video, red color refers to scanning data from a tilting laser, while the blue color denotes the inflation.
At the very beginning, the space in front of the robot is clear; then I purposely walked into the laser view and left. The video also records the laser result along this event. After several seconds, the red color corresponding to human presence disappeared but the blue color for inflation still remains there.

Understand that "the navigation stack keeps obstacles in its costmap until a sensor sees through them"; yet here the tilting laser keeps scanning and is supposed be able to see through ... your further advise are greatly welcome.

BTW, in yaml file, the observation_persistence for this laser source is set to 4.6 second. We have set both marking and clearing of this observation source to true in costmap_common_params.yaml file.

We also noticed only the tilting laser has the above issue, while for the 2D laser, the corresponding inflation will disappear when human leaves away from the robot. Is this due to that the PointCloud type of observation source is handled differently from LaserScan?

 
Reply | Threaded
Open this post in threaded view
|

Re: Inflation remain in rviz

Eitan Marder-Eppstein
Interesting. I didn't realize that the obstacles themselves were clearing fine and that just the inflation around them was sticking around. That's actually pretty strange.

Can you post the parameters you're using to configure your costmaps?

Also, just to check if its some weird visualization artifact in rviz, can you try unsubscribing and then resubscribing to the inflated_obstacles topic to see what happens? I'd also be curious to see what uknown_space looks like for your costmap, so could you subscribe to that as well?

I'm not immediately sure what's going on. The one thought I'm having is that you could have some thresholds for unknown space that are set too high. So, when the laser sees an obstacle, it goes into the map, but when the laser sees through it, instead of going to free space, it becomes unknown and perhaps I have a bug in the way that I handle old inflation cost around unknown space. I don't think I did a great job of explaining that, but, hopefully, the parameters will shed a bit more light on things.

Hope all is well,

Eitan 

On Tue, Feb 1, 2011 at 11:19 PM, clarkwu <[hidden email]> wrote:

Eitan,

Thanks for your reply.

To further explain the problem zhiping and I were facing, here is the
youtube link on what we observed:
http://www.youtube.com/watch?v=UUZe5XrYBaM

In the video, red color refers to scanning data from a tilting laser, while
the blue color denotes the inflation.
At the very beginning, the space in front of the robot is clear; then I
purposely walked into the laser view and left. The video also records the
laser result along this event. After several seconds, the red color
corresponding to human presence disappeared but the blue color for inflation
still remains there.

Understand that "the navigation stack keeps obstacles in its costmap until a
sensor sees through them"; yet here the tilting laser is keep scanning and
supposed be able to see through ... your further advise are greatly welcome

BTW, in yaml file, the observation_persistence this laser source is set to
4.6 second. We have set both marking and clearing of this observation source
to true in costmap_common_params.yaml file.


--
View this message in context: http://ros-users.122217.n3.nabble.com/Inflation-remain-in-rviz-tp2397864p2403590.html
Sent from the ROS-Users mailing list archive at Nabble.com.
_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users


_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: Inflation remain in rviz

clarkwu
Eitan,

Here attached the yaml files I used for the test.

I tried unsubscribing and resubscribing the inflated_obstacles topic within rviz, yet the inflation is still there after resubscribing.

I also tried subscribing the unknow_space, and here are the results:
/move_base/NavfnROS/NavfnROS_costmap/unknown_space, no message can be received after subscribing;
/move_base/global_costmap/unknown_space, no message can be received after subscribing;
/move_base/local_costmap/unknown_space, although messages received, I didn't see anything shown on the screen.

best regards
xiaojun


yaml.tar.gz

Reply | Threaded
Open this post in threaded view
|

Re: Inflation remain in rviz

clarkwu
The issue still remains unresolved, any suggestion?

xiaojun
Reply | Threaded
Open this post in threaded view
|

Re: Inflation remain in rviz

Eitan Marder-Eppstein
Xiaojun,

I've looked at your parameters and don't see anything that immediately jumps out at me. So, I still don't have a great idea of what could be happening.

Can you tell me what version of navigation you're using? You can find the version number by:

1) roscd navigation
2) cat CMakeLists.txt
3) The version is the x.x.x number on the last line "rosbuild_make_distribution(x.x.x)"

I might actually have to dig into the code a bit, but I'd like to make sure I know what version of the code you're using.

Hope all is well,

Eitan

On Wed, Feb 9, 2011 at 12:04 AM, clarkwu <[hidden email]> wrote:

The issue still remains unresolved, any suggestion?

xiaojun
--
View this message in context: http://ros-users.122217.n3.nabble.com/Inflation-remain-in-rviz-tp2397864p2456960.html
Sent from the ROS-Users mailing list archive at Nabble.com.
_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users


_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: Inflation remain in rviz

clarkwu
Eitan,

Here is the content of the file CMakeLists.txt,
    rosbuild_make_distribution(1.2.3)

Once more, we noticed that only when the ground_object_cloud is included under observation_sources, the above weired phenomenon will happen.

thanks
xiaojun
Reply | Threaded
Open this post in threaded view
|

Re: Inflation remain in rviz

Eitan Marder-Eppstein
Xiaojun,

OK... so you're up to date with CTurtle, which is good.

A few more questions:

In the video you sent, it looks like you're just displaying the VoxelGrid and not its 2D projection... which is published on the "move_base/local_costmap/obstacles" topic. I didn't notice this before, but the box is definitely unchecked in rviz in the video, and now it makes me think that you have obstacles in the VoxelGrid below the height of the map that would actually show up on the "move_base/local_costmap/obstacles" topic.

Can you try a few things:

1) Subscribe to the "move_base/local_costmap/obstacles" topic and report if it provides inconsistent data with "move_base/local_costmap/inflated_obstacles"

2) Turn off the visualization of the map, look at the markers displayed for the VoxelGrid and see if there were actually cells that were not getting cleared near ground level.

My current take on what's happening is that you're using the ground_object_cloud for both marking and clearing, but, assuming that floor scans are filtered out of the cloud... its actually having trouble clearing out obstacles that are close to the floor because the scans are not being used. Typically, I'll mark based on a filtered scan, but clear based on the raw scan. For you, that would mean changing "clearing" to false on the ground_object_cloud and using the raw tilt_scan with "marking" set to false and "clearing" set to true as an additional observation buffer.

Hope this helps,

Eitan

On Thu, Feb 10, 2011 at 7:19 PM, clarkwu <[hidden email]> wrote:

Eitan,

Here is the content of the file CMakeLists.txt,
   rosbuild_make_distribution(1.2.3)

Once more, we noticed that only when the ground_object_cloud is included
under observation_sources, the above weired phenomenon will happen.

thanks
xiaojun
--
View this message in context: http://ros-users.122217.n3.nabble.com/Inflation-remain-in-rviz-tp2397864p2471101.html
Sent from the ROS-Users mailing list archive at Nabble.com.
_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users


_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users