Fix bugs in the planner

Question

Fix bugs in the planner

clement-moulin-frier opened this issue 8 years ago · 15 comments

clement-moulin-frier commented 8 years ago

Cc @sockchinglow @jypuigbo

The planner module is still not behaving as expected in some situations. The following problems sometime occur:

When a drive is close to the threshold and the human give an order, the execution of the plan and of the drive-related behavior can be mixed together (e.g. 1st action of the plan, then drive-related behavior, then 2nd action of the plan). A temporary solution for avoiding it is to not giving orders to the robot when a drive is close to the threshold.
The order point to the X when X is an unknown object is supposed to ask the human to point to X. We have observed that this sometimes lead to a blocking situation. A temporary solution is to avoid asking the robot to point to an unknown object, except if this object is the only unknown one (in that case the robot will deduct the object, this works fine). The reason for this bug could be related to the previous point.
Last time we executed the demo, the order "give me the cube" where recognized correctly but no behavior was triggered in the planner. It was the first time we experienced it though.

I will sit with @sockchinglow early next week to debug the planner and we'll keep you updated on the progress here.

Answer 1 · 2017-01-25T15:50:46.000Z

Repetitive error message describing the failure to execute a plan is addressed in #212

Answer 2 · 2017-01-25T18:04:08.000Z

Occasionally, within the time for a command to be processed and sent to the planner, the allostaticController starts another behaviour in the behaviorManager based on the internal drive dynamics. This causes the planner to send the command to the BM and receiving a nack response. As this response was included in the attempt count, which has a limit of 3, the planner interjects the ongoing action with the error message (something like "I have tried too many times etc.").

This is rectified by f8917d5 where now, once planner receives a nack from the BM it cancels the plan instead of reattempting the plan. It says "wait a second" for a verbal indication of this (this can, of course, be changed to be much more informative).

Answer 3 · 2017-01-25T18:50:14.000Z

We still need to check and test it on the robot though, we'll do it tomorrow Thursday

Answer 4 · 2017-01-26T08:51:51.000Z

So what does that mean for the plan to be executed though? Say the plan consists of behaviors B1 and B2 (e.g. B1: Ask human to push the object to shared area, B2: Pull object). The planner sends the command for B1 to BM which is successfully executed. Now allostaticController kicks in and asks BM to execute B3. planner tries to get B2 executed, but BM replies nack as B3 is currently executed. The planner gives up, the plan fails, and B1+B3 were randomly executed rather than the meaningful B1+B2. Is that right?

Wouldn't it be better if the planner asks allostaticController to not do anything while the plan is being executed?

Best, Tobi

Answer 5 · 2017-01-26T10:51:23.000Z

That is actually the case, the drives are frozen during the entire plan execution. The change is that now the planner give up if the 1st action can't be executed because the BM is busy. Before it was keeping trying, postponing the plan execution. This was noy good for the interaction because the plan was often executed long after it was requested.

Answer 6 · 2017-01-26T11:54:32.000Z

Okay, I see, this makes sense. However, shouldn't the fix be on a higher level then? Shouldn't there be a "common mutex" which only allows access to the BM by either the allostaticController or the planner?

Answer 7 · 2017-01-26T12:55:16.000Z

This is also the case, there is a mutex in the BM for this.

Answer 8 · 2017-01-26T13:23:15.000Z

@Tobias-Fischer the mutex in the BM successfully prevents the planner from sending commands to it while it is running another behaviour. However, because the planner used to take this as a failure of action execution it was added into the same attempt count as sensing the failure of an action (e.g. seeing that the object has not changed position when it should have).

Answer 9 · 2017-01-26T13:51:20.000Z

Okay cool .. seems like you guys found the bug :). Did you get to test it yet?

Answer 10 · 2017-01-26T13:52:20.000Z

Not yet. Also, #212 ensures that the error sentence is more natural.

Answer 11 · 2017-01-26T18:08:56.000Z

Tested.

nackfrom BM is no longer a problem. Planner has been sped up and if there is a conflict instead of overlapping it just reports it.
Fixed the bug about not meeting preconditions
The 3rd error was a bug in our grammar

I keep it open as we are still improving it slightly. More mews coming soon

Answer 12 · 2017-01-26T18:17:41.000Z

Well done, sounds good. Did you save a log file by any chance?

Answer 13 · 2017-01-27T17:50:12.000Z

The three last commits in fix/planner allow a better checking of when a plan can be executed or not. It has been tested without the robot. We'll test it on the full demo on Monday.

Answer 14 · 2017-01-30T16:13:04.000Z

Hi,

The last commits on this branch have been tested and the robot and everything works fine here at UPF. Can another lab give it a try? Then I think we can merge.

Cheers,

Answer 15 · 2017-02-02T13:55:45.000Z

Closing here, let's open another issue if new bugs show up.