robotology-legacy/wysiwyd

Clean up / merge branches

Closed this issue ยท 9 comments

Hi guys,
I think we should try and reduce the number of branches before the integration meeting. Could you please give me an update on the status of these branches?

To be merged ASAP:

  • pushBehaviors: I think we should merge this ASAP, see #170

Under active development:

  • r-4-learnPrimitive Still under development (@maxime-petit is in charge)
  • speech_actions: Work in progress, see #158

To be kept but stale:

  • babblingTest: no active development, not to be merged
  • renaming2: Old and shouldn't be merged.
  • joints3d-to-ks2d: Old but kept for a little longer in case we need some bits and pieces
  • reactiveLayerEFAA: Does not compile and thus should not be merged. However, branch should be kept in case someone picks up work on this in the future.
  • states: Let's keep this for now in case we want to extend iol2opc with some of the contents.
    Done:
- ~~~`longTerm` I think we should merge this, it revives an old demo related to @maxime-petit and my TCDS paper. See https://github.com/robotology/wysiwyd/pull/171 (merged)~~~
- ~~~`samRelated`: See https://github.com/robotology/wysiwyd/pull/169 (merged)~~~

Thanks,
Tobi

I'll clean my branch, reset nicely the conf files, and merge it.
It should be done before the end of the week.

joints3d-to-ks2d that was the first initial implementation of the jointsAwareness module. It was replicating some code for 3d joints position without the call to the cartesianSolver method. Ugo suggested to add that to jointsAwareness for performance issue. At the end we sticked with the original jointsAwareness, so I guess we can delete it.

r-4-learnPrimitive is still under development.

Hi,
Regarding reactiveLayerEFAA, it contains code from EFAA about allostatic control with touch and speech interaction, as well as postures and face expressions.
It doesn't compile correctly due to changes in the subsystem interfaces. We spent a few hours a few weeks ago trying to adapt the code to the new interfaces, but it was not trivial (maybe @jypuigbo remember better than me what was the main problems).
Nevertheless, I think we should keep this code available since it contains an interesting demo that we'll have to revive one day or another.
How about keeping it in modules/reactiveLayerEFAA, without including that folder in the CMakeLists.txt? (as it is actually currently the case.)

Hi, in this case I'd suggest not to merge it, but instead keep it in the separate branch. In case someone gets around to work on it, he can use the branch for it.
Is that fine with you?
Best, Tobi

I've had another look at the states branch and I think it can be deleted. It contains an alternative way of propagating whether an object is in the reachable/non-reachable area, however we decided to go for a solution implemented in iol2opc instead. Can we delete @jypuigbo?

@Tobias-Fischer I'd say we keep it by now. Today I'll do a quick 'merge' of your system with mine, for flexibility, in order to be able to define setups on the go during the integration meeting. I keep you updated.

@Tobias-Fischer I't keep it by know, just temporarily. Because, do you think it's important to adapt the code you added in the wrdac/knowledge and iol2opc to have the kind of area definition I included in the branch feature/upf/states ? As a trade off, it increases flexibility for defining new setups, but reduces efficiency (see app/reactiveLayer/sensationManager/conf/default.ini and OpcSensation::getState in src/modules/reactiveLayer/sensationManager/src/opcSensations.cpp for reference). Let me know if you think it's worth adapting this change.

In any of the cases, the relevant changes for planner/behaviors in that branch are now included in the last commit of the branch feature/upf/pushingBehaviors in order to test with planner and the behaviorManager as well.

@jypuigbo okay thanks. Let's keep it then.

Closing here as only one branch is left to be merged before the integration meeting.