-
Notifications
You must be signed in to change notification settings - Fork 184
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ROS2] costmap does not clear when voxels are cleared #187
Comments
this is a new user-contributed feature, so that’s suspect to me to consider the source of the issue. I haven’t seen that behavior before with a similar configuration on my robots. If you try the default file for standard env, that’s exactly what I use, I’d be interested if you see it there. If the internal voxel grid decays them all, the 2D costmap should definitely fully-clear. I’d venture to guess that the new feature addition wasn’t fully thought through and I didn’t catch it. |
I tried both.
got the same issue stvl_sync_clear_issue_standart-2020-12-27_18.29.31.mp4 |
I'd recommend trying on a commit hash after the voxel min was added to validate that that is indeed the issue |
I am not sure which commit hash did you mean but I tried
They all got the same undesired behavior, So I can't say that this new user-contributed feature is the source of the issue |
Ok. I’m back to work on Monday and I can take a look at this sometime next week. A minimum reproduction example would be helpful if you have a short dataset you can share with that config file. |
After some more digging trying to find better possible causes for that behavior we think we might find something.
https://user-images.githubusercontent.com/54407092/104180976-afc6ff00-5416-11eb-9ca2-f7d1bb7f95ad.mp4
The bottom line is that we are not sure it is a STVL issue but rather a nav2_costmap issue. any thoughts? |
The inflation stuff should have nothing to do with STVL. The layers in the costmap don't impact each other except for the final pixel assemblies for which to take: max or last, which you're using combination method
Have you tried making this match your actual costmap resolution? Maybe your actual issue is raytracing-based. It's really bizarre to me that your STVL resolution doesn't match the master costmap's resolution. I see the lethal-marked voxels on the costmap with space between them like its a multiple of the costmap resolution. That video is strange because I think that light blue color left over isn't actually from STVL. STVL doesn't do "some cost" obstacles, its either lethal or its not. So I don't think that's actually (maybe?) cause by STVL if I'm seeing that correctly as a non-lethal cost. Maybe a weird interaction in the inflation layer not really handling layer data exported that don't match the costmap resolution? |
I tried running the tb3 simulation again but with matching the voxel_size to the costmap resolution (both 0.05) and had no inflation layer and got the same bad result, see params and attached video:
stvl_sync_clear_issue_nav2_tb3_sim_no_inflation_same_res-2021-01-12_12.23.36.mp4than, I added the inflation layer with
stvl_sync_clear_issue_nav2_tb3_sim_with_inflation_0.1_same_res-2021-01-12_12.31.28.mp4Since we have the same issue without the inflation layer but got expected result with inflation layer with a certain inflation radius I still suspect an issue with the nav2_costmap. |
I cannot emphasize enough how much I don't think the layers interact at all unless its an issue with the master costmap itself. This is possible, but doesn't seem like the most likely candidate. I think maybe a good next step is to publish the STVL 2d costmap to visualize so you can compare against the master costmap here and that one. That way when you see things left over, you can see if STVL state is wrong or the costmap layer isn't being updated correctly. Maybe a bounds issue? I'm also vaguely wondering if this is an rviz issue too where the This just seems like such a bizarre issue to not actually be caused by STVL (or if STVL, where it came from out of the blue if not caused by the only recent change with the min voxel count) |
As I said, I do not think it is necessarily a STVL issue and it seems more sense that it is a "master" nav2_costmap issue, due to the impact the costmap's resolution and other layers (inflation) have on this bug. regarding the recent change with the min voxel count, tried it already with 0 and with commits before this change.
Can you elaborate on how should we do this? should be possible as I can easily reprocuce it with the tb3 simulation
I dont believe it is an rviz issue since my actual robot would stuck in these ghost obstacles and the nav_to_goal would fail.
as you can see from the params we already had this one set to "true". did you mean something else? |
When we populate the master grid (this area of the code) https://github.com/SteveMacenski/spatio_temporal_voxel_layer/blob/foxy-devel/src/spatio_temporal_voxel_layer.cpp#L642-L661, create a new occupancy grid object and then publish it so you can see what STVL sees -- or just translate
Good to know
👍 |
Any update on this? I haven't heard any other reports Edit: whoops, hit the wrong button |
sorry, I have not found the time to make the adjustments and find the root cause. If I do, I let you know |
Its my plan to look at this later today to see if I can reproduce at all using ROS2 master or the Foxy branch if I can get to some other maintenance tasks first. Any other info you can share on this or if you fixed your issue? |
Good to hear! I think I have shared with you all the information I could get. |
@tal-grossman I'm really not seeing this behavior in ROS2 Foxy or on the new For example, for the basic turtlebot3 nav2 demo, I use the following for the local costmap (processing the laser)
You can see in black/white the local/global costmap published voxel maps (both with same params). In it, as we enter a new area, we see the points populate in the voxel grid as well as on the 2D costmap. As we pause on the other side of the map, we see the original points decay on the other side and eventually go away. Then we drive back to the original side of the map and see the same behavior again. You may note towards the end you can see a couple of voxels hanging around, but you can also see the laser scan data in those voxels are still visible so they're still rightly marked. I don't see any wrongly marked voxels. This all leads me to believe that you may have found yourself in a strange position while messing with parameters. I'd recommend highly to try to go back to some reasonable defaults and start again changing them to see where this odd situation has come from. I don't completely rule out a bug here, but I really can't see where it is and I don't see the behavior you're seeing on your end no matter what I test 🤷 test.mp4 |
In case it hasn't become obvious yet, the PCL min_points feature is broken. It only works with Pointcloud1 type messages but not with the pointcloud2 format. |
yeah we realized it when debugging this issue. but I don't think it has to do with the issue above. As mentioned, this issue has been tested before and after the |
@nickovaras @tal-grossman I'd be happy to merge a PR reverting this across the board then Edit: re-reading, maybe isn't the issue for this ticket then because I and @tal-grossman didn't see a change in behavior |
Based on what I know about this, I don't see the need to revert it, I believe that at worst it just doesn't do anything. I've had deep looks at the PCL code and done some standalone experiments as well, and when using Pointcloud2 messages the min_points parameters just get completely ignored, at least on the PCL version used by melodic. I can't think of any way in which the point cloud filtering would cause the costmap not to clear. |
Agreed- though something not working I could argue should be removed because its deceptive. @tal-grossman I honestly have no idea how you have the problem that you're seeing if I can't reproduce. The best I can do is ask you to debug a bit further to see where the disconnect is and with more information I could jump in and help work out a solution. |
small feedback: It did turn out to be deceptive for me, spent some time debugging until I could find this issue. Will build latest pcl from source, unless you can advise of a better solution |
Bug report
I'm new in using the the stvl layer (b.t.w - another great job!), and might be doing something wrong.
But according to the tutorials and to the answer given here Spatio temporal voxel layer: Clearing voxels not seen but included in fov - which explicitly saying that if a voxel is removed than the costmap should be updated as well , I think there might be a sync issue - when voxels are cleared after decaying but the costmap is not.
please look at the video -
voxels are green, taken from depth pcl. The 2D local costmap layer is pink.
stvl_sync_clear_issue-2020-12-24_10.06.25.mp4
Required Info:
Ubuntu 20.04
Steps to reproduce issue
Expected behavior
costmap is synced to stvl layer. when voxeled are cleared the costmap should be updated accordingly
Actual behavior
After voxels decayed and cleared from layer the costmap is not totally cleared
Additional information
The text was updated successfully, but these errors were encountered: