Merge CAN bus&wrapper loader apps

[jgvictores]

Are they required?
Should they be replaced by a script that invokes instances of teo-body yarpdev?

[jgvictores]

Do to implementation using Multiwrapper / CBW2 working at f7d5a3b, they are needed as programs.

[jgvictores]

launchManipulation and launchLocomotion can be scripts that invoke a TwoCanBusThreeWrappers class.

[PeterBowman]

launchManipulation and launchLocomotion can be scripts that invoke a TwoCanBusThreeWrappers class.

Done a long time ago (efb9593). What's left to be done here?

[jgvictores]

The idea was for launchManipulation/launchLocomotion etc to be simple bash alias of some yarpdev command. What would your opinion be?

[PeterBowman]

Both launchManipulation and launchLocomotion as well as oneCanBusOneWrapper should be treated equally: they are merely launchers of their corresponding RFModule class. As such, those executables may read from an .ini configuration file or accept CLI options per the usual YARP policies. Can we achieve that by means of a bash script?

As a first step, I'd think we can merge launchManipulation/launchLocomotion into a single entity, perhaps named as twoCanBusThreeWrappers.

[jgvictores]

Will be moved to teo-configuration-files once #116 is closed.

[PeterBowman]

Will be moved to teo-configuration-files once #116 is closed.

Just noting that we'll have to update CMake/C++ code as well (default environment, installation paths for .ini files).

[jgvictores]

Yep, that's why I've assigned myself. ;-)

[PeterBowman]

Idea: merge libraries/OneCanBusOneWrapper into programs/oneCanBusOneWrapper, same for TwoCanBus...

[jgvictores]

Mmm I think it's the other way around. There's no reason for a program to exist, all could be achieved via YARP plugins...

[PeterBowman]

Following that line of thought, what is the reason for RFModules to exist? How can I tell my RF-based application is better suited for its implementation as a YARP plugin? I'm thinking now about kinematics-dynamics/programs. Moreover, from which interface will oneCanBus... inherit so that it'd make sense to view/acquire a handle and do stuff with it?

[jgvictores]

1. That looks kind of like a deep philosophical question I'm not fit to answer here. Please open an issue on best-practices (finer scope than QA) if you think we could reach some kind of consensus!

2. IHMO, it just feels like launchManipulation should be a one-liner:

yarpdev --device TwoCanBusThreeWrappers --from launchManipulation.ini

Because it's just a specification of a very basic functionality.

3. A more evolved device I once had in mind and not sure if documented would be more like (naming could vary):

yarpdev --device NCanbusNWrappers --from launchManipulation.ini

which actually merges and superseeds the notion of OneCanBusOneWrapper/TwoCanBusThreeWrappers.

What would your thoughts be on (2) and (3)?

[PeterBowman]

It already is an easy-to-type one-liner (supports tab completion):

oneCanBusOneWrapper --from oneCanBusOneWrapper.ini

OK with (3), but we can still achieve the same with executables.

[jgvictores]

Great, that's one use case solved.

Here's the second use case. The second use case is to be able to write an application such as a walking gait, and to be able to switch from local to remote devices easily. Technically, I'm not sure if this is the way (or a good way, or a feasible way) to achieve this. Would have to give it more thought or even better develop some example code. For now just leaving this idea here for the historic.

[PeterBowman]

There's no reason for a program to exist, all could be achieved via YARP plugins...

Please open an issue on best-practices (finer scope than QA) if you think we could reach some kind of consensus!

Even in best-practices, RFModules are recognized as a valid way of creating YARP programs: Programming in C/C++. We have a few of them around and working nicely, so I can't fathom any compelling reason to alter the status quo. If you don't mind, could you be the one to open that issue instead and suggest your changes?

My opinion is that devices provide a wider range of uses (most notably the interface support, plus being able to launch them programatically, plus wrappers), whereas RFModules are basically a convenient RF-enabled subset for executables. In particular, applying the device mechanism to oneCanBus/TwoCanBus feels like a bit of an overkill to me (in other words, being able to achieve the same result with devices doesn't mean that we should), and of course needs some effort to migrate from RFModule to DeviceDriver.

[jgvictores]

As commented with @PeterBowman, this is specifically for CanBusControlboard and wrappers. Thoughts:

• IPositionControl * ipc = nCBMW.view(0);
• ControlBoardRemapper

[jgvictores]

When done, the one-liner will be aliased scripts/bash/launchManipulation and scripts/bash/launchLocomotion as part of https://github.com/roboticslab-uc3m/teo-configuration-files

[jgvictores]

Will be moved to teo-configuration-files once #116 is closed.

No longer blocked by #116, but will not move issue to https://github.com/roboticslab-uc3m/teo-configuration-files because it involves code here.

[jgvictores]

...but as commented above, perhaps http://www.yarp.it/classyarp_1_1dev_1_1ControlBoardRemapper.html is the solution already provided by YARP.

[jgvictores]

Blocks #171.

[PeterBowman]

RFModules have learned to behave like plugins in YARP 3.2.0 in that now you can load them on demand on runtime via yarp::os::RFPlugin, see robotology/yarp#1532 and the moduleLoader example.

This change was aimed to launch several modules in a single-process context. However, this was already possible before thanks to the yarp::os::RFModule::runModuleThreaded() method (in this case, class symbols need to be loaded on init, though).

[PeterBowman]

Idea: give more flexibility to launcher scripts so that the same .ini file can be parsed and loaded differently on demand. Now, I need to keep duplicates of launchManipulation.ini (for instance) whenever I want to launch only a single arm, with or without absolute encoders and/or grippers, and different combinations of those. If the new proposed app could parse an RF option (e.g. --left) so that only specific groups in the .ini file are parsed and used to create their corresponding devices, life could be much easier.

[PeterBowman]

yarpdev --device NCanbusNWrappers --from launchManipulation.ini

Retitled so that it's (more or less) aligned with this proposal. Point here being: let's unify and expand the OneCanBusOneWrapper and TwoCanBusThreeWrappers classes. The Dextra project poses a first and most evident use case: two CAN buses and five wrappers: head, two arms, and two hands (new).

Here's the second use case. The second use case is to be able to write an application such as a walking gait, and to be able to switch from local to remote devices easily. Technically, I'm not sure if this is the way (or a good way, or a feasible way) to achieve this. Would have to give it more thought or even better develop some example code. For now just leaving this idea here for the historic.

Split into #226. Please note that whole-body controllers (you mention that a bit later) require that all four CAN buses are plugged into the same CAN board.

[PeterBowman]

I have merged oneCanBusOneWrapper, launchManipulation and launchLocomotion into one universal app, canBusLauncher, at 46a2f8b. Their respective libraries have been deleted, too.

[PeterBowman]

I have merged oneCanBusOneWrapper, launchManipulation and launchLocomotion into one universal app, canBusLauncher, at 46a2f8b.

Follow-up: this application has been renamed to launchCanBus. See also #237 regarding the new .ini file layout that launchCanBus has learned to parse.