Lingering obstacles

[lucasb-eyer]

I think by now the biggest navigation-related problem left to solve for Karl is lingering obstacles on the costmap. They usually appear where when humans walked in front of the robot and are never cleared, not even when I (not Karl) walk there and go away.

Here's two examples of it:

This completely screws over navigation. I'm confident the chest-cam is well calibrated, and you can see there is no laser or chest-cam point in there. It also doesn't flicker.

How to debug this?

[nilsbore]

Where are the chest camera points in the first image? Are they the yellow ones?

[nilsbore]

Also you tried e.g. z_obstacle_threshold=0.2, z_stair_threshold=0.2? That could be a good starting point.

[nilsbore]

Hmm, if the two are the same situation and we are seeing the points there in the second they should indeed be cleared. This is a problem that I don't observe here at all...

[nilsbore]

OK, I've solved the issue with the voxel cloud, submitting a pull request soon shortly.

[nilsbore]

Added it for the local costmap in https://github.com/strands-project/strands_movebase/pull/20. Maybe I can help you getting rid of this, I don't experience the problem of obstacles not getting cleared if the robot stands still. Of course there is stuff lingering when she moves, that's unavoidable.

[nilsbore]

With that pull, you can add a PointCloud (not 2) with topic /marked_cloud.

[lucasb-eyer]

Yep, the yellow dots. Will have a look at the voxel map and see if I can debug that. Will also double-check that lingering isn't leftover from previous movement. Thanks for the pointer so far.

[lucasb-eyer]

Just confirming that they really do linger when the robot stands still and someone walks in front of it. Will debug further...

[nilsbore]

Have you tried the thresholds?

[lucasb-eyer]

Not yet, I'm currently trying to reliably reproduce it, and I think just having it stand somewhere, walk past it, and there's linger. Moving the robot just a tiny bit then clears it, just posted it here as an update and reminder to self, still need to try both your visualization fix and thresholds, but waiting for :pizza: first.

[lucasb-eyer]

Update: the darkyellow points are from the /voxel_marked_cloud topic, so you can see there are lingering points. They are just a few cm above the ground, way below the laser-plane. Going to play with the parameters next.

[lucasb-eyer]

z_obstacle_threshold=0.2 doesn't really help much. What helps a lot though is reconfiguring the following:

local_costmap:
  obstacle_layer:
    z_resolution: 0.5
    z_voxels: 3
    unknown_threshold: 3

Going to roll around with that this evening and see what gives.

[nilsbore]

Didn't see that you had fewer voxels as well so that part should be fine. But I would recommend resetting these changes as they will affect the configuration a lot as the z origin of the voxel map and the number of voxels (6) have been tuned to the sensor heights. Try z_stair_threshold:=0.12 and z_obstacle_threshold:=0.2 and I would be very surprised if there are still points lingering. (note that I think that I think that the stair part is the important here, if you don't have any stairs that could be set even higher). The z_obstacle_threshold can also be set to a lower value afterwards if you want higher sensitivity.

[lucasb-eyer]

No, that doesn't make it better. I reset my aforementioned parameter and set the two thresholds you gave. There's arguably less lingering, but there still is: red arrows. But now there's even lingering cliff detections pointed out by the green arrow. Interestingly, though, these two points don't add to the costmap O.o.

Just to check that last point, I drove right in front of stairs and they do seem to be added to the costmap:

Now why do you say I shouldn't change the three other parameters like I did? According to my limited understanding, the voxel-grid would be 1.5m high (now it's only 1.2), and I updated the unknown threshold accordingly. It did run extremely well and I was even able to lower z_obstacle_threshold so it recognizes my slippers but not the carpet.

[nilsbore]

For example, the laser will clear observed obstacles that are observed well above and below it. This holds for the other sensors as well. If changing the stair threshold helps, try something even higher, 0.2 like initially suggested?

[nilsbore]

For the height of the map, 1.2 is good for the chest camera. For the head camera, it changes to be 9 voxels instead of 6, encompassing that camera as well.

[lucasb-eyer]

Will try that tomorrow then, Karl just completely shut down without a warning: no more power!

[nilsbore]

Ok. I should simply change these thresholds to be higher by default, will do that tomorrow also.

[lucasb-eyer]

Nope, 0.2 for both thresholds does not improve things. I just tried it (undone my other changes) and there's lots of lingering after just walking in front of the immobile robot just once:

[nilsbore]

Wtf, now I'm getting confused. Any chance of ssh:ing to your robot? Den 20 nov 2014 10:27 skrev "Lucas Beyer" notifications@github.com:

Nope, 0.2 for both thresholds does not improve things. I just tried it (undone my other changes) and there's lots of lingering after just walking in front of the immobile robot just once:

[image: lingering5] https://cloud.githubusercontent.com/assets/1476029/5122184/df84ce38-709d-11e4-8205-97de08a1def4.png

— Reply to this email directly or view it on GitHub https://github.com/strands-project/strands_movebase/issues/19#issuecomment-63781296 .

[lucasb-eyer]

-> gitter.im

[nilsbore]

Ok, I figured out the problem, I can replicate it on Rosie. If I tilt the camera upwards so that calibration returns an angle close to 30 degress then there are points lingering at the top of the field of view, probably either because the points behind them are to far away to observe or because of a threshold on the distance of raytracing. Tilting it more downwards, returning about 45 degrees from calibration fixes the problem.

[nilsbore]

If @lucasb-eyer can confirm that this fixes the problem I will add a recommendation to the readme and maybe some printouts from calibration saying that it's good or bad.

[lucasb-eyer]

Yes that would be perfect, thanks. I will try it on our robot as soon as he is back up and running.

[lucasb-eyer]

Just as a follow-up, our camera was at 50 degrees, which should be even better. But after moving it to 44 degrees, the lingering still didn't stop. I'm about to give up for now and have Karl get stuck regularly...

[lucasb-eyer]

I'll stick with the 0.5/3/3 parameters I've mentioned previously. I understand your concerns, but in practice, it just seems to work too well. I can even set the obstacle threshold to below 10cm. Will post back when Karl runs into something, or doesn't.

[nilsbore]

Allright, sounds good. Just see that your stairs are properly detected with that configuration. Also know that obstacles below 0.5m will be cleared by the laser as soon as they go outside the view of the chest camera, unless they are also observed in the laser.

[lucasb-eyer]

Ah, I see your point now and confirmed that it happens - so I don't have an easy way out.

[nilsbore]

Main PC time=)

[marc-hanheide]

Just confirming that when we accidentally move the camera up (looking more straight) we had loads of problems. Tilting it down as much as possible solved it, but it seems quite a sensitive thing.

[lucasb-eyer]

So turns out it's all my own fault, obviously. The problem is that I increased the resolution of our costmap to 0.02, which helps navigating tight spots, but didn't increase the resolution of the subsampled chest_xtion pointcloud. When I use the same resolution for both, points linger much less often. Sorry for taking so much of your time, @nilsbore!

[marc-hanheide]

Is that something that applies to all sites, i.e. is it in the repos?

[marc-hanheide]

asking because we had lingering objects, too

[nilsbore]

No, it shouldn't.. I've also seen a few instances of lingering stuff but it doesn't seem to affect navigation much. I might look into making the point cloud slightly more high resolution if people are experiencing problems.

[lucasb-eyer]

No, I didn't commit my resolution changes because I exactly wanted to see if it doesn't cause far-reaching problems like this one. Don't get me wrong, there are still lingering objects, just way less.

[nilsbore]

I've found a bug here that might explain the lingering obstacles you are experiencing so you were not totally wrong @lucasb-eyer . The ray-tracing for the laser is too short (I think). So if the stuff behind a previously observed obstacle is too far away, the obstacle won't be cleared. This is a major bug so I will try to fix it as soon as possible. EDIT: after some more testing, it seems to be OK. This might have been caused by blinds spots of the laser when facing glass doors. It seems to reliably raytrace away obstacles even when the stuff is more than 10m away. So I guess that was not it.

[nilsbore]

So the stuff I can reproduce is lingering obstacles at the edge of the laser's FOV, mostly close to the robot.

[lucasb-eyer]

Right, I observed that too but didn't mention it because it's laser, not chest. Just to confirm that I have that too.

[marc-hanheide]

I think I also saw that...

[bfalacerda]

We might also be suffering from this, as we're barely using the depth cloud anymore and we had some obstacles staying close to the robot

[bfalacerda]

I'm running nav in indigo, running the chest camera with openni_launch, because i cant use our openni_wrapper right now (https://github.com/strands-project/openni_wrapper/issues/14)

It looks like it's worse than usual. I have this just by going around the robot and leaving:

If I reload the costmaps, here's what it looks like:

Any idea why it's worse than before @nilsbore ?

[bfalacerda]

maybe my increase in resolution of the local costmap? https://github.com/strands-project/strands_movebase/pull/30/files#diff-6cfd320e3116e37282da59273455e68fL8

[nilsbore]

I'm pretty sure that's the reason.

[nilsbore]

That was the exact same problem @lucasb-eyer had because he had increased the resolution. What's the reason for increasing resolution? More precise planning?

[bfalacerda]

yeah, local planning gets better in narrow spaces

[nilsbore]

Hmm, if we want to go with that resolution, we must increase the resolution of the obstacle adding cloud like @lucasb-eyer created a parameter for. This will of course be more computationally expensive so we will have to make some kind of trade of there.

Since the old move_base version makes it navigate better in those situations I would suggest getting to the bottom of that before fiddling with these parameters.

[Pandoro]

Lucas increased the resolution for the same reason. Karl got stuck less often, at the cost of getting the lingering points. But this was mainly fixed by upping the resolution of the pointclouds used to clear the costmaps. On Dec 3, 2014 3:08 PM, "Nils Bore" notifications@github.com wrote:

That was the exact same problem @lucasb-eyer https://github.com/lucasb-eyer had because he had increased the resolution. What's the reason for increasing resolution? More precise planning?

— Reply to this email directly or view it on GitHub https://github.com/strands-project/strands_movebase/issues/19#issuecomment-65411533 .