Filtering out unexecutable tasks from the routine.

[hawesie]

This has become necessary since the abilty to add daily tasks allows the addition of arbitrary tasks which are no longer bounded sensibly in time by the routine windows.

Also this now deals with runaway and non-terminating child processes.

HOWEVER this needs a different fork of SMACH

Either

1. an update to SMACH if/when this PR is in: Deal with prior preemption and runaway child states. ros/executive_smach#37

Or

2. https://github.com/hawesie/executive_smach

So 2) as of April 23, 2015.

[bfalacerda]

this seeks to work nicely. what do we do with it, since it depends on unreleased software?

[hawesie]

This PR is definitely necessary for both deployments (so cc @marc-hanheide). This means we will need a checkout of this repo in our ws, or otherwise self-release smach (bad idea I guess).

[marc-hanheide]

Can you explain this? I don't know how this effects us as we are not using any routine stuff in aaf, AFAIK.

[hawesie]

It's actually the hawesie@475d48a commit you need, but it got added to an existing PR.

Before this the executor didn't actually have a way of moving past tasks that have genuinely got locked up. A timeout would be triggered, but that timeout wouldn't do anything under a number of conditions as it somewhere it would be waiting for a thread join that will never happen. Now that join times out too.

In addition to that, if a demanded task tried to kill a previous task, there is a timing issue that could mean the preemption is not handled cleanly. This resulted in the executor getting into an ugly mess. This latter issue is also fixed by that commit.

This commit requires changes to SMACH which are in the PR linked above.

[bfalacerda]

The SMACH changes are also important for monitored_navigation, which, in rare situations, could get stuck in a state that would require it to be killed

[marc-hanheide]

So, that means we should release our own SMACH, right? So, @hawesie do you want to transfer ownership of your repo to strands-project so I can set up Debian builds for this and we release it? Waiting for ROS to do it seems unfeasible.
We'd have to bump the version number to make sure our packages use our version rather than the official one...

[marc-hanheide]

@hawesie I can of course also fork your repo into strands-project to release from there.

[marc-hanheide]

I now set up the strands-project repo for Jenkins builds based on @hawesie s code. We can then release from there.

[marc-hanheide]

As our own smach is now released...

retest this please

[marc-hanheide]

retest this please

[marc-hanheide]

Now fine to merge.

[hawesie]

Thanks @marc-hanheide. I will let you know if and when things get merged upstream.