Karl fails on a daily basis

[ghost]

Hello all,

We have been running the autonomous patroller again for the past two days and sadly I must say Karl gets stuck (without calling for help) at least once a day. Very popular is the door of my office, where it somehow drives very close to the wall and then cannot turn because it might bump into the wall while doing so. See the image below.

In such a situation the robot will stand there and as far as I can judge it will fail to get a plan to the next waypoint, then it tries to execute the recovery behavior, which it cannot due to a possible collision and then it will abort, get the next waypoint and repeat this.

While I wasn't a big fan of the driving backwards, it seemed to fix this problem. Maybe it would be a possibility to drive back very slowly, at least until a turn is possible again. In case it would bump into something, it wouldn't press the bumper too hard so it could probably release the bumper and drive in a different direction.

[bfalacerda]

I put the driving backwards in the first place because we were also having a problem with a door. Driving backwards creates a tradeoff between move_base and bumper failures basically. I can see 2 ways to tackle this problem:

1. Try making navigation more robust by playing with the parameters in https://github.com/strands-project/scitos_2d_navigation
2. Edit the recover state for navigation in https://github.com/strands-project/autonomous_patrolling/blob/master/waypoint_patroller/src/waypoint_patroller/recover_states.py. The previous move backwards behaviour is just commented so you can see how it was implemented and adapt it as you wish.

Since you have those problems, it would be cool if you could test using some slowly drive backwards based recovery behaviour and see if that improves the overall robustness.

PS.: There's no call for help when move_base fails, it will be added soon :)

[bfalacerda]

I just merged the disallowing of the rotate recovery for move_base, so now the robot just clears the costmap without trying to rotate, you can check if that makes a difference before going for other options.

[ghost]

I think we will get time to do this on Monday, I'll report back once I know more about it.

On Thu, Oct 24, 2013 at 12:08 PM, BFALacerda notifications@github.comwrote:

I just merged the disallowing of the rotate recovery for move_base, so now the robot just clears the costmap without trying to rotate, you can check if that makes a difference before going for other options.

— Reply to this email directly or view it on GitHubhttps://github.com/strands-project/autonomous_patrolling/issues/70#issuecomment-26980390 .

[ghost]

Sadly I must say I haven't been able to really get something done on this topic. Just so you know that you are not duplicating any work :x

[ToMadoRe]

Our robot also gets stuck frequently. Even in situations where there would be enough space to perform actions it fails to produce a path as for example shown in the picture.

We can only recover the waypoint_patroller if we push him a little bit or send a joystick command. I don't think the robot will last long at the marathon with the current configuration.

[hawesie]

Can you include the cost maps in RViz so we can see which space is ruled out due to obstacles? Someone else can tell you the correct topics to visualise (as I always seem to pick the wrong ones!)

[ToMadoRe]

Sure, I will post the RVIZ display next time it gets stuck

[bfalacerda]

It looks like most of the failures in navigation come from the robot getting it's front too close to a wall and then being unable to rotate, since it is not symmetric. One possible naive solution for this is change its footprint so that it becomes symmetric, i.e., enlarging the front part of the footprint a bit. I know it's an ugly thing to do, but for the marathon it might work.

[hawesie]

That sounds like something worth trying to me.

[ToMadoRe]

Here another example - this time with the costmap... The robot could actually easily turn to right but DWA planner failes to produce path and never recovers without human interaction.

[hawesie]

Actually I don't think the robot can turn given the exerted back end and the proximity to the green bits. Maybe this would be a case where @BFALacerda's idea of extending the footprint would help things.

[nilsbore]

That could potentially be problematic if is to go through doors, since that is already tight at our site. So maybe we can do that (extend the base) in conjunction with changing the cost of going close to obstacles?

[bfalacerda]

My suggestion is only increasing the "front" of the footprint, the width will be the same, so I would expect the robot to try and align itself with a door further away from it, but hopefully it will not fail to go through it because of the increased front.

Anyway, playing with move_base parameters would be cool, I also think that they are not as finely tuned as they could be. I spent some time around them, in a trial and error approach, before the first version of the patroller, but since then I think they have been pretty much the same

[nilsbore]

Related to https://github.com/strands-project/scitos_2d_navigation/issues/13: Does anyone know if there's a blueprint for the robot with measurements somewhere? I was gonna make a new footprint for people to try out but I can't seem to find the measurements of the base anywhere. I remember there were some at the awakening camp.

[bfalacerda]

In https://github.com/strands-project/scitos_2d_navigation/blob/master/scitos_move_base_params/costmap_common_params.yaml there is a commented line which is a very precise footprint that we took from some file from metralabs. I guess you can use that one as a starting point. We are not using it because it has too many points and makes the control loop lag a bit

[nilsbore]

Ah, ok, I thought that was something that you had approximated. Cool, then I can use it as a starting point.

[ghost]

@BFALacerda you pointed me to the scitos_move_base_params_3d folder. Is there any difference? Because the file is present in both. I approximated it with the following:

footprint: [[-0.3000, -0.3200],[ -0.5200, -0.1100],[ -0.5200, 0.1100],[ -0.3000, 0.3200],[ 0.1000, 0.3200],[ 0.2500, 0.1100],[ 0.2500, -0.1100],[ 0.1000, -0.3200]]

Seems to work okay so far, although I can't say it is a miraculous improvement.

On Mon, Nov 18, 2013 at 10:18 AM, Nils Bore notifications@github.comwrote:

Ah, ok, I thought that was something that you had approximated. Cool, then I can use it as a starting point.

— Reply to this email directly or view it on GitHubhttps://github.com/strands-project/autonomous_patrolling/issues/70#issuecomment-28683821 .

[nilsbore]

This is the outline of the different footprints, blue the real one, red the box and green Alex'. What strikes me is that the (0, 0) (should be the rotational centre?) is much further forward than I had thought. This can explain why it has a problem turning where it doesn't seem that way. And I guess Bruno's solution with an extended front would be the only reasonable way to fix this?

[bfalacerda]

I think I pointed you to this one also. I don't know the difference between the 2 folders, I wasn't aware of the scitos_move_base_params_3d folder. @nilsbore, what's the difference?

[bfalacerda]

Cool, we should have plot this before. Yeah, it's pretty forward but I think we also got that from some metralabs file, so the rotational centre is really there. @cburbridge, do you remember where we got these values from?

[nilsbore]

Oh, the difference is that in costmap_common_params.yaml, two new inputs are added, for adding and deleting obstacles. Then in local_costmap_params.yaml, it says to use a voxelgrid instead of a flat costmap. Then I changed the update frequency of the costmap to be slightly lower in global_costmap_params.yaml.

It was done this way to be able to run exactly the old version of the navigation and being able to tinker with the new parameters. I also think it's good to be able to run it without the camera if need be.

[nilsbore]

So these are the parameters it will use if you run scitos_2d_nav with the with_camera:=true parameter, as detailed in the instructions.

[ghost]

@BFALacerda Okay, maybe I messed up then, but I changed the stuff in the 3d version and it did make a difference. @nilsbore but what is the difference between the normal and the 3d folder?

@nilsbore I already tried extending it exactly as far to the front as to the back and it didn't work better for us. Furthermore I agree with Bruno, it seems to me that the rotational center is rather good. I just rotated the robot and it seems to actually correspond to what you see on the plot.

When Karl is unable to rotate, the problem I typically observe in rviz is that it looks like he is slightly mislocalized, putting possible locations inside some obstacle. Maybe I just interpret it in the wrong way, but if Karl thinks he possibly is in the wall it makes sense to me that he doesn't rotate.

On Mon, Nov 18, 2013 at 10:45 AM, Nils Bore notifications@github.comwrote:

Oh, the difference is that in costmap_common_params.yaml, two new inputs are added, for adding and deleting obstacles. Then in local_costmap_params.yaml, it says to use a voxelgrid instead of a flat costmap. Then I changed the update frequency of the costmap to be slightly lower in global_costmap_params.yaml.

It was done this way to be able to run exactly the old version of the navigation and being able to tinker with the new parameters. I also think it's good to be able to run it without the camera it need be.

— Reply to this email directly or view it on GitHubhttps://github.com/strands-project/autonomous_patrolling/issues/70#issuecomment-28685267 .

[bfalacerda]

I think it's normal that the particles are a bit spread around the robot's real pose, that how mcl should work, so I wouldn't worry if some particles are inside an obstacle. What matters is that the expected value is in the right place, which I think it is.

[nilsbore]

@AlexanderHermans The difference is described above, scitos_move_base_params are used when not providing with_camera:=true and scitos_move_base_params_3d are used when providing the argument. I probably should add this in some documentation together with ways to debug the obstacle avoidance.

As for the localization, there should be no difference whatsoever between the old and new version. Are you sure this is the error? Can you upload a screenshot as Tomas did, with the GridCells (it's on the topic local_costmap/marked something).

I don't think the centre is an error of the footprints but that it could potentially be problematic if the robot wants to turn when facing a wall. But I also think that the flat front could be the problem and that your footprint could solve this since it's a bit more circular at the front.

[ghost]

@nilsbore , sorry I skimmed your post too briefly.

I didn't take a screenshot just now, but the next time it happens I will. But as Bruno already explained, it is a normal behavior. The expected value, (considering this is where the robot is displayed in rviz?) was not inside of the obstacles, although I'm not sure what exactly was there on the costmap as it was covered by the pose array.

We just had the problem that Karl hit a door with his display while turning. The rectangular back of the footprint actually seemed like a good idea in this case. Maybe we should just go with a rectangular front side?

On Mon, Nov 18, 2013 at 11:01 AM, Nils Bore notifications@github.comwrote:

@AlexanderHermans https://github.com/AlexanderHermans The difference is described above, scitos_move_base_params are used when not providing with_camera:=true and scitos_move_base_params_3d are used when providing the argument. I probably should add this in some documentation together with ways to debug the obstacle avoidance.

As for the localization, there should be no difference whatsoever between the old and new version. Are you sure this is the error? Can you upload a screenshot as Tomas did, with the GridCells (it's on the topic local_costmap/marked something).

I don't think the centre is an error of the footprints but that it could potentially be problematic if the robot wants to turn when facing a wall. But I also think that the flat front could be the problem and that your footprint could solve this since it's a bit more circular at the front.

— Reply to this email directly or view it on GitHubhttps://github.com/strands-project/autonomous_patrolling/issues/70#issuecomment-28686157 .

[bfalacerda]

I would be more conservative with the front and make it bigger than it really is, and make the back more precise, if that makes any sense

[ghost]

Making the back more precise will actually cause problems with the display I think. So making it "more precise" would actually mean to just keep the box shape at the back. How much bigger do you want to make it at the front? The box shaped bigger front didn't work out well when I tested it, as you could clearly see Karl would get possible collisions more often and thus turn even less. Maybe a bigger round front end?

On Mon, Nov 18, 2013 at 11:10 AM, Nils Bore notifications@github.comwrote:

Yeah, I that was actually my initial idea so it would be cool if you could try that out!

— Reply to this email directly or view it on GitHubhttps://github.com/strands-project/autonomous_patrolling/issues/70#issuecomment-28686651 .

[nilsbore]

I would propose trying something like this red footprint with an elongated front that's also a bit rounded off. Maybe also make the back corners a tiny bit more round? This footprint is: [[0.235, 0.31],[-0.515, 0.31],[-0.515, -0.31],[0.235, -0.31],[0.415, -0.12],[0.415, 0.12]]

[nilsbore]

No, it should be ok...

[bfalacerda]

the problems with the display only happen if the robot rotates when its close to an obstacle, and the elongated front would avoid that. But if you tested it and it didn't work properly, we can scratch that option out. @nilsbore's footprint looks like a better compromise

[ghost]

I will test this, however currently we are having trouble getting the cameras to work again.

On Mon, Nov 18, 2013 at 11:43 AM, BFALacerda notifications@github.comwrote:

the problems with the display only happen if the robot rotates when its close to an obstacle, and the elongated front would avoid that. But if you tested it and it didn't work properly, we can scratch that option out. @nilsbore https://github.com/nilsbore's footprint looks like a better compromise

— Reply to this email directly or view it on GitHubhttps://github.com/strands-project/autonomous_patrolling/issues/70#issuecomment-28688471 .

[ghost]

Currently the new proposal from Nils seems to be running okay as well. Still it got stuck a few times though. Here is a screenshot of the latest case:

It often fails here. I think in this screenshot you can actually see something on the costmap that was not cleared correctly.

[nilsbore]

Yeah, it seems like someone walked by or stood there and the robot tried to avoid it by going right. Then it couldn't see the person with the Primesense anymore so it couldn't clear the map and thought it was stuck. Do you think that could be it?

[nilsbore]

On the other hand the object looks very small so it should have had some opportunity to clear it.

[ghost]

It's not exactly next to my office, so I don't really know what happened there. It could very well have been someone who passed the robot while turning, but it did not recover from this state.

Assuming it did believe that there is something there, the only real way would have been to carefully drive backwards, or to maybe try to turn to the left and drive between the two obstacles. The first option is obviously not considered, but I noticed that more difficult routes than the direct one aren't really considered. Does anyone know if there is such a kind of behavior? A sort of random walk to get out of a situation?

[bfalacerda]

shouldn't the clear_costmap service of move_base (which is called on its recovery behaviour) take care of this issue?

[nilsbore]

I had a brief look at this and it seems like the costmap is cleared outside or within(not entirely clear) a circle with default radius 3.0 m. This radius can be changed with the conservative_reset_dist parameter of move_base. It would be cool to see what happen if we set this parameter to 0.0, hopefully the whole map will clear.

[nilsbore]

This issue is more of a discussion thread and many of the problems have been fixed since, those that haven't have more specific threads for them. Close, @marc-hanheide ?

[marc-hanheide]

sure