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 mergedrenaming2
: Old and shouldn't be merged.joints3d-to-ks2d
: Old but kept for a little longer in case we need some bits and piecesreactiveLayerEFAA
: 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 extendiol2opc
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.