Pass config options to CanBusControlboard's subdevices

[PeterBowman]

Originally a subtask of roboticslab-uc3m/questions-and-answers#49, I'm opening this to deal with the issues that led to 6467003 (rollback commit of 3fcf1b5).

#175 (comment)

yarp-devices/libraries/YarpPlugins/CanBusControlboard/DeviceDriverImpl.cpp

Line 301 in 08f6a41

if((nodes[i]->getValue("device")).asString() == "TechnosoftIpos"){

Looks like getValue performs a lookup on the monitor instance (not on options passed through open), ref.

#175 (comment)

From PolyDriver.cpp:

Value PolyDriver::getValue(const char *option) {
    if (system_resource==nullptr) {
        return Value::getNullValue();
    }
    return HELPER(system_resource).getValue(option);
}

The system_resource member is a local instance of YarpDevMonitor (which extends SearchMonitor). However, we don't use it at all if the config parameter to PolyDriver::open already has a monitor object attached to itself:

bool PolyDriver::open(yarp::os::Searchable& config) {
    if (isValid()) {
        // already open - should close first
        return false;
    }
    if (system_resource==nullptr) {
        system_resource = new YarpDevMonitor;
    }
    yAssert(system_resource!=nullptr);
    bool removeMonitorAfterwards = false;
    if (config.getMonitor()==nullptr) {
        config.setMonitor(&HELPER(system_resource));
        removeMonitorAfterwards = true;
    }

    //dd = Drivers::factory().open(config);
    coreOpen(config);
    HELPER(system_resource).info.fromString(config.toString());
    if (removeMonitorAfterwards) {
        config.setMonitor(nullptr);
    }
    return isValid();
}

The monitor linked to config registers a device key in coreOpen. If this is not the local monitor instantiated in open, getValue won't return what we actually expect.

roboticslab-uc3m/questions-and-answers#49 (comment)

To sum up, PolyDriver::getValue does not work as expected when the instance has been configured and opened with a Searchable object to which a monitor has been attached to (usually via options.setMonitor(config.getMonitor())). See #175 (comment) for full explanation. Might need to circumvent the way we use getValue in that repo (example) or enhance the value lookup mechanism upstream.

roboticslab-uc3m/questions-and-answers#49 (comment)

There is no simple way to sort this out on the upstream side without proposing a breaking change of the (undocumented) SearchMonitor interface, which lacks option getters (check sources).

On our end, the CanBusControlboard device might hold a vector of Property instances besides the existing one for PolyDriver objects (ref) in order to store and access device configurations. This is a hack.

[jgvictores]

Please note that while DeviceDriverImpl.cpp has been populated with this kind of string comparisons, I'd much rather all to be moved to their corresponding classes and reached via polymorphism.
The only reason there are string comparisons in the first place is actually my fault, a hack I think we could do better now (there was some issue related to passing a pointer in a Property, but since a while ago we know this can be passed as a blob):

yarp-devices/libraries/YarpPlugins/CanBusControlboard/DeviceDriverImpl.cpp

Lines 170 to 172 in 08f6a41

	if( types.get(i).asString() == "CuiAbsolute" )
	{
	int driverCanId = ids.get(i).asInt() - 100; //-- \todo{Document the dangers: ID must be > 100, driver must be instanced.}

[PeterBowman]

Work on #211 might shed some light regarding how class inheritance is going to be shaped.

[PeterBowman]

Probably blocked by #74.

[PeterBowman]

Circumvented at ab72254 and cbb840c while working on #74.