Comments (27)
To sum up:
- passing monitor objects on PolyDriver instances: done, except for some leftovers (openrave-yarp-plugins, wink wink @jgvictores?) and possibly new & unaware code
- adding documentation parameter to
check
calls: same as above - nasty
getValue
bug (roboticslab-uc3m/yarp-devices#207): solved - passing monitor objects via RFModule: not done, propose upstream issue/PR
--help
versus--verbose
: not sure how to proceed, we use neither of both anyway...
Closing due to inactivity/too broad a scope/lack of interest on tedious subtasks.
from questions-and-answers.
How to make this work on RF modules (e.g. transCoords app):
int main()
{
MyMonitor monitor; // implements yarp::os::SearchMonitor
yarp::os::ResourceFinder rf;
// tweak 'rf', e.g. set default context and so on
rf.setMonitor(&monitor, "transCoords");
roboticslab::TransCoords mod;
mod.configure(rf); // check return value!
// at this point, retrieve options stored in 'monitor' and
// print them on stdout if --verbose was passed on
return mod.runModule(); // no need to configure again
}
We'll need a class that implements yarp::os::SearchMonitor
(no Doxygen, see definition) and provides a public method for obtaining option bottles. Compare YarpDevMonitor
.
from questions-and-answers.
need to review all check calls and add missing comments/defaults
Speaking of the yarp::os::Searchable class (see inheritance diagram, it has several implementations), prefer
bool check(const ConstString &key, const ConstString &comment) const;
Bottle findGroup(const ConstString &key, const ConstString &comment) const;
instead of
check(const ConstString &key) const;
Bottle findGroup(const ConstString &key) const;
The former generate a report that may be used by the monitor in verbose mode. Also, the following are available:
bool check(const ConstString &key, Value *&result, const ConstString &comment="") const;
Value check(const ConstString &key, const Value &fallback, const ConstString &comment="") const;
from questions-and-answers.
I'm going to list here all repos that have been improved by providing or expanding on option documentation (now passing appropriate defaults and description in config.check()
and the like) and propagating it through device wrappers:
- roboticslab-uc3m/kinematics-dynamics@1f18d71
- roboticslab-uc3m/tools@babb13c
roboticslab-uc3m/vision(no YARP devices here)roboticslab-uc3m/asibot-hmi(...and here)roboticslab-uc3m/speech(nothing to do here either, Espeak device is already documented)roboticslab-uc3m/openrave-yarp-plugins(no monitor available - plugin loader in OR environment)- roboticslab-uc3m/yarp-devices
- roboticslab-uc3m/yarp-devices@5377c2a (partially reverted due to roboticslab-uc3m/yarp-devices#175)
- roboticslab-uc3m/yarp-devices@3d66a62
from questions-and-answers.
Or, since I like simplicity:
if (config.check("optionA", "enables A (and additional options)"))
{
// ...
}
Thus, users would be aware of the existence of hidden options (and how to enable them).
from questions-and-answers.
Okay, it'll take a while, but I will find a moment to do it!
from questions-and-answers.
I'd rather close roboticslab-uc3m/yarp-devices#175 and track that bug here. 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 roboticslab-uc3m/yarp-devices#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. For that reason, I'd keep the blocked
label for now.
from questions-and-answers.
Looks good! I'm going to be touching RobotServer
/RobotClient
pair at https://github.com/asrob-uc3m/yarp-devices, would look like a nice opportunity to experiment!!
from questions-and-answers.
Thanks a lot for this info! Always loved the behavior, but found the intrinsics quite cryptic, especially for modules.
from questions-and-answers.
Bad thing is, YARP should have already provided an implementation, otherwise we are forced to write a tiny library only for this and replicate the same code in several places... This is what yarpdev
runs behind the scene: ref. The sample main
function from my previous comment would check verbose
and reuse that code to print the report (replace PolyDriver
with MyMonitor
in the function's signature).
from questions-and-answers.
Maybe we could develop some kind of helper class that could be PR'ed directly into YARP?
from questions-and-answers.
Sure, the sooner the better. I'm afraid of those find_package(YARP 3.0.0 REQUIRED)
in each single app (unless we stick to preprocessor conditionals).
from questions-and-answers.
Thanks a lot for this!
from questions-and-answers.
Sometimes, device options hide each other, like this:
if (config.check("optionA"))
{
yarp::os::Value v = config.check("optionB", yarp::os::Value(MY_DEFAULT));
}
The check for optionB
could be pulled out from its enclosing if
clause so that it's parsed by --verbose
regardless of the presence of optionA
. Then, additional logic would take care of the implicit relationship between both options. Is this the way to go?
from questions-and-answers.
Custom devices wrapped by controlboardwrapper2
cannot display options via --verbose
due to an upstream bug (tracked at robotology/yarp#1608).
from questions-and-answers.
Related upstream PR regarding --help
: robotology/yarp#1473.
from questions-and-answers.
I'm going to list here all repos that have been improved...
All set but openrave-yarp-plugins. @jgvictores I'd really appreciate if you could take a look at existing device options and review/fill their description fields :) (low priority).
from questions-and-answers.
yarp-devices still WIP due to roboticslab-uc3m/yarp-devices#175, marking as blocked.
from questions-and-answers.
Note to self: use simpler unit notation and replace parens with square brackets. Example: [m/s] or [deg/s]
instead of (meters/second or degrees/second)
.
from questions-and-answers.
Added some documentation on ORYP at roboticslab-uc3m/openrave-yarp-plugins@e0adfbc
from questions-and-answers.
Applied to asrob-uc3m/yarp-devices
here; works, but ran into asrob-uc3m/yarp-devices#12
from questions-and-answers.
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.
from questions-and-answers.
IMHO, a big issue is too much being done on the CanbusControlboard. Things such as home should be done within Technosoft open or new method which is involved for all devices and each one implements their behavior via polymorphism.
The only special case where I introduced the original ugly hackish code was connecting the CuiAbsolute to the TechnosoftIpos, but that (apart from different) could be done better.
from questions-and-answers.
Custom devices wrapped by controlboardwrapper2 cannot display options via --verbose due to an upstream bug (tracked at robotology/yarp#1608).
Merged into YARP's master
branch, scheduled for the 2.3.72.1 release.
from questions-and-answers.
This issue has been stalled for too long, therefore...
I'd rather close roboticslab-uc3m/yarp-devices#175 and track that bug here.
I changed my mind (again) and opened roboticslab-uc3m/yarp-devices#207, in the only repo affected by said bug.
The list #49 (comment) is done except for a few undocumented config options in openrave-yarp-plugins. @jgvictores could you please take a look? Apart from that, I need to check whether any new devices that have been added in the past year conform to these new standards.
One last question: is the behavior of --verbose
actually better than the old --help
? Also, note to self: look for remaining occurrences of the latter.
Regarding RFModule: either open an issue upstream considering #49 (comment), or forget.
from questions-and-answers.
The list #49 (comment) is done except for a few undocumented config options in openrave-yarp-plugins. @jgvictores could you please take a look?
I have that repo pretty abandoned, but I'll take a look. Specifically, I had done advances on roboticslab-uc3m/openrave-yarp-plugins#82, raised its priority to get done with it.
One last question: is the behavior of
--verbose
actually better than the old--help
? Also, note to self: look for remaining occurrences of the latter.
My intuition behind --help
was to be implement a --verbose
that additionally quits before running anything, mostly to be able to read the output before all the verbosity of actually running. Would implementing this explicitly make any sense, or do you think we can just force users to stop a running program and scroll up?
from questions-and-answers.
There is not much to do at or-yp, anyway, just a few undocumented occurrences of .check(
at OpenraveYarpPluginLoader.
Would implementing this explicitly make any sense, or do you think we can just force users to stop a running program and scroll up?
It's a pity we don't know the outcome of robotology/yarp#1473. Some thoughts:
- Duplication should be avoided, hence passing
--help
would need to invoke--verbose
under the hood. --verbose
itself is position-dependent, that is, if we fail to pass some check inDeviceDriver::open
and end up in areturn false;
clause, all further instructions won't be reached, especially accounting for those documentation comments passed toSearchable::check
. In other words, the output of--verbose
may be incomplete.- With that last point in mind, we could place all check in the beginning or the end of the
::open
method: either parse all YARP options and store them in local variables before using them in conditional checks or whatever (i.e. register doc comments before doint anything else), or defer the early exit of a failed configuration (letreturn false;
be the very last instruction in said method), respectively. Such a big change would enforce a new paradigm of writing YARP devices which I'm not sure to be fond of, but it's definitely doable. - How do we really want
--help
to behave? Should it output additional, textual clues which are not specific to YARP options shown by--verbose
? Must it actually propagate to subdevices, just like--verbose
does, now? - I'm not sure yet how to cope with the different behavior of
PolyDriver
andRFModule
. Our implementation of a--help
handler could differ between those, also we need to know whether YARP catches this option anywhere and enforces its own solution (see linked PR above).
from questions-and-answers.
Related Issues (20)
- Make dox target via YCM goodies HOT 9
- Unit tests and unsatisfied dependencies lead to compilation failure HOT 1
- Embrace hooks HOT 3
- Bump required YCM version (v0.10+) HOT 4
- YARP 3.0 upgrade path HOT 5
- Update CMake/YCM export options HOT 10
- [GitHub] Git LFS disabled for roboticslab-uc3m HOT 2
- Centralize Travis scripts HOT 4
- Changes to git branch policy in YARP/YCM HOT 8
- Drop dual master-develop branching in favor of a single prod branch HOT 10
- Review installation-related snippets in Markdown docs HOT 1
- Migrate to GitHub Actions HOT 24
- Add C++ examples to main build HOT 7
- Update links to GitBook project instances on legacy servers HOT 3
- Portmonitors renamed at YARP >= 3.5 HOT 1
- Update links pointing at new subdomain HOT 4
- sp_ineachdb and also sp_msforeachDB return only 50 records instead of hundreds HOT 3
- Randomization problems with JsPsych HOT 1
- cards in Thingsboard professional version HOT 1
- Abandon GitBook, look for alternatives HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from questions-and-answers.