Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 01 16:59

    bfalacerda on kinetic-devel

    re-add logic for nav_before_act… Merge pull request #319 from bf… (compare)

  • Oct 01 16:59
    bfalacerda closed #319
  • Sep 25 16:37
    bfalacerda closed #154
  • Sep 25 16:37
    bfalacerda commented #154
  • Sep 25 16:36
    bfalacerda closed #146
  • Sep 25 16:36
    bfalacerda commented #307
  • Sep 25 16:35
    bfalacerda opened #319
  • Sep 17 15:33
    hawesie commented #307
  • Sep 17 15:32
    hawesie unassigned #307
  • Sep 16 15:42

    bfalacerda on kinetic-devel

    call prediction for first time … Merge pull request #315 from bf… (compare)

  • Sep 16 15:42
    bfalacerda closed #315
  • Sep 16 09:47
    francescodelduchetto commented #307
  • Sep 16 08:17

    hawesie on kinetic-devel

    Removing buggy code for closing… Merge pull request #317 from st… (compare)

  • Sep 16 08:17
    hawesie closed #317
  • Sep 16 08:17
    hawesie closed #316
  • Sep 16 08:07
    hawesie commented #307
  • Sep 13 18:42
    francescodelduchetto commented #307
  • Sep 13 18:37
    francescodelduchetto commented #307
  • Sep 13 18:32
    francescodelduchetto commented #307
  • Sep 13 18:31
    francescodelduchetto commented #307
Marc Hanheide
@marc-hanheide
Now the problem (I assume) is that this causes conflicts when tasks are also being executed.
As we most often have the case that a task is added at "nice" times, e.g. 10:00am sharp form the routine and tasks often also start around the same time, we seem to be temporarily droppping task that are just due to be executed (in the process of finding a new schedule)
It seems there is no lock on the currently executed schedule, while it creates, what I would call temporary ones
Could that be?
That woudl explain quite many of our problem, maybe
I didn't find the right place in the source files, so I need to ask
But am I write, that there should be an "approved" schedule, that is the one currently given to the executors, and a separate volatile one where the scheduler is "toying" around
Nick Hawes
@hawesie
rosed task_executor scheduled_task_executor.py
the execution schedule is set with the call self.execution_schedule.set_schedule
Marc Hanheide
@marc-hanheide
Summarised: Observation is: If tasks (even tasks ways in the future not conflicting with the current task) are added when a new task is due to start, often the current task is removed
Nick Hawes
@hawesie
if this is called when the schedule is not final then you will get the situation you describe, so it should only be called when everything is finalised. I don't know if it's called more often as the priority code is all @mudrole1's so I hand over to her.
Marc Hanheide
@marc-hanheide
what is published on /current_schedule?
the execution_schedule?
Nick Hawes
@hawesie
yes.
see publish_schedule
so what you see there is what is planned for execution
Marc Hanheide
@marc-hanheide
just found it... so if that changes a lot as we see it, it is some indication it's doing something a bit funny good
Nick Hawes
@hawesie
(publish_schedule in scheduled_task_executor.py)
Marc Hanheide
@marc-hanheide
is there a reason why /current_schedule is only published every 5 secs and not on every changed and made latched?
Nick Hawes
@hawesie
nope
(except my bad design under pressure before the last review)
anything that sets the schedule in try_schedule is suspicious to me ;-)
Nick Hawes
@hawesie
I'm dropping out of this as my slides need writing and Lenka is there!
but a ps .. it could also be when tasks are removed from the execution schedule bit by bit
Lenka Mudrova
@mudrole1
yep, lenka is here
Marc Hanheide
@marc-hanheide
yep... Lenka, I'll come across soon
just trying to understand this a bit better first
Marc Hanheide
@marc-hanheide
Are you guys aware that the jenkins tests for strands_executive all fail, because they take too long?
blob
This is after two hours!
It looks as if it doing things correctly: https://lcas.lincoln.ac.uk/jenkins/job/devel-indigo-strands_executive/18/console But maybe these unit tests are a bit too long?
@hawesie @bfalacerda ?
Bruno Lacerda
@bfalacerda
the link requires authentication
Marc Hanheide
@marc-hanheide
ignore it
click cancel
or open in incognito session (it's a cookies problem)
Bruno Lacerda
@bfalacerda
yes, incognito worked
that's a lot of testing :p
Marc Hanheide
@marc-hanheide
indeed, very thourough
Bruno Lacerda
@bfalacerda
it's all @hawesie though, let's see what he says
Marc Hanheide
@marc-hanheide
ok
Nick Hawes
@hawesie
Yeah these are testing time b based tasks over long periods. What's the time limit? I can reduce things a bit.
Marc Hanheide
@marc-hanheide
2 hours gross, so VM setup, compiling, and testing. I have already extended the timeout from 1 to 2 hours...
Marc Hanheide
@marc-hanheide
OK, so #302 has basically worked, though your tests don't return at the moment. I have now also enabled kinect devel builds for strands_executive on the new build farm. We shall see if it works there.
Marc Hanheide
@marc-hanheide
There is a problem to release strands_executive
Marc Hanheide
@marc-hanheide
The problem is that /strands_executive/strands_executive_tutorial depends on /strands_executive_behaviours/routine_behaviours which itself depends on /strands_executive/strands_executive_msgs and /strands_executive/task_executor. This cyclic dependency between the repositories needs to be removed. So, @bfalacerda @mudrole1 @hawesie what do you want to do, I see the following options:
  1. move strands_executive_tutorial out of the strands_executive repo into a separate one
  2. dissolve the entire strands_executive_behaviours repository and put its content into strands_executive repo. It might add some additional dependencies into strands_executive as a repo, but as the packages are separated out afterwards that is not a problem and won't change anything from an end-user perspective.
  3. Refactor your code so it doesn't depend cyclicly.
You might argue "but it worked in the past". My answer is, yes, that's because it was already released before the cycle was introduced. So when we released one package it was build against the available (possibly outdated) version of the other. It's a cover up, not a working solution that we had ;-)
Nick Hawes
@hawesie
I choose 3. Will do it.
Marc Hanheide
@marc-hanheide
thanks