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
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
at the same time, you may want to look at the new automated_routine package which doesn't seem to depend on anything...
Nick Hawes
@hawesie
OK.