new scheduler amendments in gcal_routine and aaf_control_ui

[marc-hanheide]

as discussed with @hawesie

• infoterminal: not time critical, time window given as before, everything should be working as we do at the moment, no chance needed (other than probably adjusting the max_duration?)
• calendar: make it time-critical, the max_duration is derived from the calendaer, the end time is same as start time
• web interface: submit ondemand

[marc-hanheide]

OK, I believe this could now work with #373 and strands-project/strands_executive#266 in place... needs testing in system context

[Jailander]

these are the outputs of the tests:
Scheduler
tmux-scheduler.txt
/current_schedule
tmux-current_schedule.txt
/task_executor/events
tmux-task_events.txt

[marc-hanheide]

Right... so what do we see in this test? What did you do in which order?

[marc-hanheide]

tmux-task_events.txt has two entries only...?

[Jailander]

Yes it does, this was infoterminal running with two calendar events (that it went to but didnt even do) and one on demand task that I dont think it was submitted at all from the UI

[marc-hanheide]

@Jailander @hawesie I have investigated this further. Here are som observations

1. The gcal_routine had a bug that didn't work with time critical tasks. This is resolved in fb4a74bd100493235ab63a18ee989b6f16991295 (strands-project/strands_executive#266)

2. it still doesn't work fully correctly as now on demand tasks don't work anymore... What happens when it is currently executing a time-critical task "A" (with priority 2) and a new task "B" with (priority 100) comes in, is that

   1. the scheduler accepts the new on-demand task "B" (with priority 100, but I think this is ignored anyway...),
   2. it preempts a currently running time-critical task "A"
   3. goes to the waypoint of the demanded task "B"
   4. starts the on-demand task "B" where it should
   5. BUG immediately preempts the on-demand ask "B" because it things it should be doing the time-critical task "A"
   6. goes back to waypoint for task "A" and starts it again

   Some log output from the moment it changes its mind again:

   [INFO] [WallTime: 1479680725.752496]  received feedback PENDING
   [INFO] [WallTime: 1479680726.758082] Reached waypoint ChargingPoint
   {'_da': 0, 'executed_n21_info_task_server_at_ChargingPoint': 0, 'waypoint': 2, 'door_edge0': -1, 'door_edge1': -1}
   {'_da': 0, 'executed_n21_info_task_server_at_ChargingPoint': 0, 'waypoint': 0, 'door_edge0': -1, 'door_edge1': -1}
   [INFO] [WallTime: 1479680726.760689] Station_ChargingPoint received feedback SUCCEEDED
   EXECUTE ACTION
   [INFO] [WallTime: 1479680726.860512] Executing n21_info_task_server_at_ChargingPoint. Actionlib server is: info_task_server
   [INFO] [WallTime: 1479680730.413579] Another 3656.35 seconds until expected policy completion
   [WARN] [WallTime: 1479680730.414457] We should be executing a time-critical task now, so cancelling execution
   [WARN] [WallTime: 1479680731.012259] Policy execution has been preempted by another process
   

   This latter is a bug for @hawesie to lock at I believe. The behaviour of the calendar and the control UI is now exactly as expected.

[marc-hanheide]

OK, I believe all this should be working now.

Question for @capamat-aaf related to this:

Which on-demand task do you guys want to be able to trigger vai the Control UI? In other words, which jobs do we need to offer to be available spontaneously? Think along the lines of

• What do you need to show the robot off to some visitors (and where)?
• What admin/maintenance jobs do we need (e.g. just putting the robot to charge for an hour, with info-terminal) to have it out of the way and for how long
• Where do you want to give it a spontaneous bellbot task (where should it start)?

Anything else? Maybe @Jailander wants to share ideas as well. Currently, it looks like this, but I can redesign this easily:

[cdondrup]

@marc-hanheide I am not entirely sure we want to offer the 'schnelle Gruppe' as a choice in the first place. Even though it is possible to have the robot go quicker, we noticed that this leads to unforeseen side effects like the increased number of disgruntled patients when it comes too close for comfort. Also, this won't be changed by any new form of human-aware navigation as it needs time to spot the human and classify the action first. Having the robot go quicker just decreases the planning time.

In the last deployment, we never used that anyway.

[marc-hanheide]

OK, I have made some changes to the button. To be viewed at https://lcas.lincoln.ac.uk/werner/tasks I leave it for now, if you have more requests, let me know.

[cdondrup]

Looks good to me, thanks!