search

strands-project / strands_executive

Executive control code for STRANDS robots.
10 stars 19 forks source link

several issues using the correct executor #307

Open marc-hanheide opened 5 years ago

marc-hanheide commented 5 years ago

@francescodelduchetto and I are a bit lost what the "correct" executor/scheduler would be to use for our museum case.

The problem: We have so far tried to use https://github.com/strands-project/strands_executive/blob/kinetic-devel/task_executor/launch/task-scheduler-top.launch as a simple scheduler. However, that one seems to be deprecated, and lacking recent features (e.g. time critical tasks). Also with that one, we had the following issue:

@francescodelduchetto submitted in private issue https://github.com/LCAS/LindIMP/issues/40:

Basically, a task was running and I was trying to cancel it but I wasn't able to do so...bcs of this error I presume @marc-hanheide 

[INFO] [1542370813.904951]: Concurrent state 'MONITORING' returned outcome 'preempted' on termination.
[WARN] [1542370813.923710]: State 'MONITORING' in concurrence did not service preempt.
[INFO] [1542370813.924395]: Concurrent Outcomes: {'MONITORED': 'succeeded', 'MONITORING': 'preempted'}
[INFO] [1542370813.924950]: Action terminated with outcome succeeded
[INFO] [1542370813.931177]: State machine transitioning 'TASK_EXECUTION':'succeeded'-->'TASK_SUCCEEDED'
[INFO] [1542370813.932638]: Preempt requested on state machine before executing the next state.
[INFO] [1542370813.933305]: Last state 'TASK_EXECUTION' did not service preempt. Preempting next state 'TASK_SUCCEEDED' before executing...
[ERROR] [1542370813.941010]: InvalidUserCodeError: Could not execute state 'TASK_SUCCEEDED' of type '<task_executor.sm_base_executor.TaskSucceeded object at 0x7f1a2b95bc$
  File "/opt/ros/kinetic/lib/python2.7/dist-packages/smach/state_machine.py", line 247, in _update_once
    self._remappings[self._current_label]))
  File "/localhome/lcas/workspaces/museum_ws/src/task_executor/src/task_executor/sm_base_executor.py", line 79, in execute
    self.executor.task_succeeded(completed)
  File "/localhome/lcas/workspaces/museum_ws/src/task_executor/scripts/scheduled_task_executor.py", line 139, in task_succeeded
    self.task_complete(task)
  File "/localhome/lcas/workspaces/museum_ws/src/task_executor/scripts/scheduled_task_executor.py", line 135, in task_complete
    self.execution_schedule.task_complete(task)
  File "/localhome/lcas/workspaces/museum_ws/src/task_executor/src/task_executor/execution_schedule.py", line 118, in task_complete
    assert self.current_task is not None
AssertionError

Exception in thread Thread-89:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner
    self.run()
  File "/usr/lib/python2.7/threading.py", line 754, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/opt/ros/kinetic/lib/python2.7/dist-packages/smach/state_machine.py", line 359, in execute
    container_outcome = self._update_once()
  File "/opt/ros/kinetic/lib/python2.7/dist-packages/smach/state_machine.py", line 254, in _update_once
    + traceback.format_exc())
InvalidUserCodeError: Could not execute state 'TASK_SUCCEEDED' of type '<task_executor.sm_base_executor.TaskSucceeded object at 0x7f1a2b95bc10>': Traceback (most recent $
  File "/opt/ros/kinetic/lib/python2.7/dist-packages/smach/state_machine.py", line 247, in _update_once
    self._remappings[self._current_label]))
  File "/localhome/lcas/workspaces/museum_ws/src/task_executor/src/task_executor/sm_base_executor.py", line 79, in execute
    self.executor.task_succeeded(completed)
  File "/localhome/lcas/workspaces/museum_ws/src/task_executor/scripts/scheduled_task_executor.py", line 139, in task_succeeded
    self.task_complete(task)
  File "/localhome/lcas/workspaces/museum_ws/src/task_executor/scripts/scheduled_task_executor.py", line 135, in task_complete
    self.execution_schedule.task_complete(task)
  File "/localhome/lcas/workspaces/museum_ws/src/task_executor/src/task_executor/execution_schedule.py", line 118, in task_complete
    assert self.current_task is not None
AssertionError

So, maybe we should be using the MDP scheduler? That one, however, in the current version uses the a door config file: https://github.com/strands-project/strands_executive/blob/74d4d03754c59c0c90758b54a3aa4238e4c8ab23/task_executor/launch/mdp-executor.launch#L9-L11

And it doesn't seem to work properly. Can @bfalacerda or @hawesie suggest what the correct launch file would be for a "simple" (no doors, no adaptation, no bells and whistles), but robust and full-featured scheduling? I feel we are doing something stupid here. If it helps, I can invite you guys to the private repo to understand our situation better. Simple first questions: Which launch file should we be using?

bfalacerda commented 5 years ago

I don't see any old parameter on that link, is it correct?

hawesie commented 5 years ago

This is the old one: https://github.com/strands-project/strands_executive/blob/deprecated-kinetic-devel/mdp_plan_exec/scripts/mdp_policy_executor_extended.py#L38

bfalacerda commented 5 years ago

But the line you linked first is just me setting the server as aborted when there is no policy, was that what you intended to link?

Looking at the code, I think it's needed: https://github.com/strands-project/strands_executive/blob/kinetic-devel/mdp_plan_exec/scripts/mdp_robot_policy_executor.py#L101

The boolean variable linked above ensures the robot does a navigation action before it executes any other action.

hawesie commented 5 years ago

But what does starting_exec do? That looks related to me, and wasn't present in the old code.

bfalacerda commented 5 years ago

it ensures ensures the robot does a navigation action before it executes any other action, i.e., exactly the opposite of what is intended. I don't understand exactly what is old and what is new code. The most up to date code in terms of the logic for navigating (or not) before executing an action is the one in https://github.com/strands-project/strands_executive/blob/deprecated-kinetic-devel/mdp_plan_exec/scripts/mdp_policy_executor_extended.py#L38

bfalacerda commented 5 years ago

I didnt merge the param thing to the fork we were using, that might be why this is confusing.

hawesie commented 5 years ago

I'm a bit lost. Let's chat in person.

hawesie commented 4 years ago

@francescodelduchetto is this still an open issue for you? We haven't provided any kind of fix, but before I start trying to puzzle through the messages I wanted to check you still cared.

francescodelduchetto commented 4 years ago

Hi @hawesie, yes it is still an open issue. We are using my fork of this repo for the robot now, but I guess it would be nice if we can return to the upstream one

francescodelduchetto commented 4 years ago

I guess that the main problem and the reason I started to use my fork is what described in here https://github.com/strands-project/strands_executive/issues/307#issuecomment-451978391 .

francescodelduchetto commented 4 years ago

The nav_before_action_exec feature was implemented by @bfalacerda in https://github.com/bfalacerda/strands_executive/blob/a8e8ce2483680bb4417c560e90f82157876ac363/mdp_plan_exec/scripts/mdp_policy_executor_extended.py but then disappeared when the script was replaced by https://github.com/strands-project/strands_executive/blob/kinetic-devel/mdp_plan_exec/scripts/mdp_robot_policy_executor.py

hawesie commented 4 years ago

Thanks, that's super useful. So the task for me is to put back the nav_before_action_exec option?

francescodelduchetto commented 4 years ago

Yes, I think so. Thank you!

hawesie commented 4 years ago

Ok, @bfalacerda is now in charge of this. It's quite a hard thing to change directly, so this probably won't happen immediately.

bfalacerda commented 4 years ago

@francescodelduchetto please check #319. Should be back to the behaviour you asked for.