Closed rsantos88 closed 6 years ago
From what I'm seeing, it shouldn't be due to 3fcf1b5aeda71a234c2a61b2b7905213ca8d5f85.
Could you do the following to see if this is repeatable?
My guess is it may be related with #170
With 08f6a4162ef0af342ff9489c21901d062fc88e8f:
[debug] DeviceDriverImpl.cpp:298 open(): Moving motors to zero.
[debug] DeviceDriverImpl.cpp:331 open(): Moved motors to zero.
With 72d4c8e5b615fc14d7ab4a087e54d70b6c052d1d:
[debug] DeviceDriverImpl.cpp:294 open(): Moving motors to zero.
[debug] DeviceDriverImpl.cpp:302 open(): Value of relative encoder ->0.000000
[debug] DeviceDriverImpl.cpp:309 open(): It's already in zero position
My fault, but PolyDriver's docs and implementation are a bit weird wrt. PolyDriver::getValue
:
Looks like getValue
performs a lookup on the monitor instance (not on options passed through open
), ref.
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.
As pointed out by @rsantos88, this happens since 3fcf1b5 (https://github.com/roboticslab-uc3m/questions-and-answers/issues/49).
Partially reverted in 6467003, should be fine now. I'll be looking for some means to make this work again...
Partially reverted in 6467003, should work now. I'll be looking for some means to make this work again...
Thanks @PeterBowman. Yes, it works now.
The high-priority bug is solved, but the rationale behind the now-reverted commit affects more repos. Let's get back to https://github.com/roboticslab-uc3m/questions-and-answers/issues/49 and track it properly at that place.
The high-priority bug is solved, but the rationale behind the now-reverted commit affects more repos. Let's get back to roboticslab-uc3m/questions-and-answers#49 and track it properly at that place.
Locally split back into https://github.com/roboticslab-uc3m/yarp-devices/issues/207.
Since this commit (https://github.com/roboticslab-uc3m/yarp-devices/commit/3fcf1b5aeda71a234c2a61b2b7905213ca8d5f85),
--homePoss
is not working. The robot doesn't move to the home position and the shell shows this:but no movement... Doing
git checkout 72d4c8e5b615fc14d7ab4a087e54d70b6c052d1d
(reference: https://github.com/roboticslab-uc3m/yarp-devices/commit/72d4c8e5b615fc14d7ab4a087e54d70b6c052d1d) it works again without any problems. @PeterBowman could you fix it? Thanks!