Lingering obstacles #19
Comments
|
Where are the chest camera points in the first image? Are they the yellow ones? |
|
Also you tried e.g. |
|
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... |
|
OK, I've solved the issue with the voxel cloud, submitting a pull request soon shortly. |
|
Added it for the local costmap in #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. |
|
With that pull, you can add a PointCloud (not 2) with topic |
|
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. |
|
Just confirming that they really do linger when the robot stands still and someone walks in front of it. Will debug further... |
|
Have you tried the thresholds? |
|
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 🍕 first. |
|
Update: the darkyellow points are from the
|
|
local_costmap:
obstacle_layer:
z_resolution: 0.5
z_voxels: 3
unknown_threshold: 3Going to roll around with that this evening and see what gives. |
|
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 |
|
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 |
|
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? |
|
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. |
|
Will try that tomorrow then, Karl just completely shut down without a warning: no more power! |
|
Ok. I should simply change these thresholds to be higher by default, will do that tomorrow also. |
|
Nope,
|
|
Wtf, now I'm getting confused. Any chance of ssh:ing to your robot?
|
|
-> gitter.im |
|
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. |
|
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. |
|
Yes that would be perfect, thanks. I will try it on our robot as soon as he is back up and running. |
|
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... |
|
I'll stick with the |
|
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. |
|
Ah, I see your point now and confirmed that it happens - so I don't have an easy way out. |
|
Main PC time=) |
|
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. |
|
So turns out it's all my own fault, obviously. The problem is that I increased the resolution of our costmap to |
|
Is that something that applies to all sites, i.e. is it in the repos? |
|
asking because we had lingering objects, too |
|
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. |
|
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. |
|
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. |
|
So the stuff I can reproduce is lingering obstacles at the edge of the laser's FOV, mostly close to the robot. |
|
Right, I observed that too but didn't mention it because it's laser, not |
|
I think I also saw that... |
|
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 |
|
I'm running nav in indigo, running the chest camera with openni_launch, because i cant use our openni_wrapper right now (strands-project/openni_wrapper#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 ? |
|
maybe my increase in resolution of the local costmap? https://github.com/strands-project/strands_movebase/pull/30/files#diff-6cfd320e3116e37282da59273455e68fL8 |
|
I'm pretty sure that's the reason. |
|
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? |
|
yeah, local planning gets better in narrow spaces |
|
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 |
|
Lucas increased the resolution for the same reason. Karl got stuck less
|
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?
The text was updated successfully, but these errors were encountered: