A place for general debate and question&answer
Home Page: https://robots.uc3m.es/developer-manual/appendix/repository-index.html
This repository is intended to be a codeless Questions and Answers (Q&A) repository for https://github.com/roboticslab-uc3m, via the GitHub Issue mechanism.
Please, before asking any question, read the guidelines at: Developer Manual: Asking Questions
To see all Open and Closed GitHub Issues of this repository, please follow this link: LINK
Install YARP plugins elsewhere: right now, in Ubuntu, our YARP plugins are installed in /usr/local/lib/yarp. However, icub plugins are installed in /usr/local/lib/icub.
How can I reserve some time with TEO?
I recall https://docs.google.com/a/uc3m.es/spreadsheets/d/1_DjZ9MEbwFc2IecMJ0rrNGOPN1bdDIQezkVwxBhfs80/edit?usp=sharing but there's no 2017... 🙂
Lots of cool organization-level info hidden in wiki, example: http://robots.uc3m.es/contributors/
See https://zenodo.org and https://github.com/robotology/ycm + https://zenodo.org/record/809413.
Maybe members of @roboticslab-uc3m/xgnitive and @roboticslab-uc3m/textiles could find it useful?
Options for documenting dependency installation documentation (note: this all started with https://github.com/roboticslab-uc3m/teo-main/issues/70):
cc: @PeterBowman @rsantos88 @David-Estevez et Al... what is your opinion?
Después de haber hablado con @smcdiaz y con @jmgarciah, y después de todas las consecuencia que supuso el cambio y la redistribución de repositorios, así como las consecuencias de posibles cambios con la actualización de software como puede ser YARP (ver issue) o un futuro cambio de distros de linux en los PCs de Teo (ver issue ) se ha llegado a la conclusión de que son interesantes tomar las siguientes medidas:
Yo creo que con realizar el primer punto sería suficiente por el momento, para tener el robot siempre operativo ante cualquier cambio. Decirme que os parece.
Thoughts arising from roboticslab-uc3m/yarp-devices#118.
Debian vs Ubuntu. This is a nasty fight, don't want to get too dirty LOL. It was actually the start of the original issue stated above. @munozyanez commented on Debian and @PeterBowman and I were a bit more into Ubuntu. Nothing against Debian, which is usually considered more stable. Simple fact is Ubuntu 16.04 has a newer CMake version (hence newer versions in general) than Debian 9.0. Having newer versions is usually interesting for us. In sum, we usually leaned towards Ubuntu due to its newer package versions.
RT or non-RT. Currently, RT is at driver level, the Technosoft IPos PT Mode. We'd have to go years back to ASIBOT's pre-empt kernel, or more recently TEO's Meka head which was formatted due to lack of compatibility of drivers (e.g. its own wifi module could only be used via ndiswrapper, with poor communication quality). This is why we've been leaning towards non-RT.
Graphical desktop environments or not. I was originally against installing anything graphical on a robot. However, this is something like c++ vs python: "Is it worth to program on an ultra-efficient platform, if this means that you will not be as efficient/productive?". @smorante usually preferred graphical desktop environments and was much more productive than me at times, and I've seen this with @rsantos88 too. This, together with the fact that we're non-RT anyway, is why we've been leaning towards graphical desktop environments. Note: I believe installing a server version of Ubuntu is a bit more straightforward than Debian, but that may apply to full distros too. 😅
Edit: Graphical distro tools can also help for settings such as wifi or sound configuration, which need to be configured quick even in working scenarios, such as an imminent demo. 😄 @David-Estevez and I propose, see below, some CLI/curses alternatives.
Edit2: @David-Estevez Proposed, see below, the possibility of having a graphical desktop installed, but not autostarted.
@roboticslab-uc3m/roboticslab It would be great to have your feedback. Obviously there are more considerations such as which graphical desktop in case there is any (I'm in favor of using defaults per distro), please feel free to comment! Am I missing any more relevant considerations?
Program documentation:
Generate FAQ gitbook from relevant closed issues of this repository.
Thanks to #17, weekly cron jobs automatically test latest commits on production against YARP's devel branch. Currently, YARP needs to be cloned and built on every push action, and so do other dependencies (e.g. KDL, PCL, OpenRAVE).
Proposal: for non-cron jobs (perhaps cron too if it makes sense), store YARP (and other dependencies if present) in the Travis cache (docs) in order to speed up things. It's preferrable to hold a global variable with the targeted version so that it can be easily bumped in the YAML file with every new release. Speaking of YARP, current master is tagged at 2.3.72.
Caching has been extensively tested on https://github.com/asrob-uc3m/robotDevastation, see .travis.yml and latest builds.
Error compiling with new versions of YARP on Debian 6.0.1 machines.
/usr/local/include/yarp/os/Contact.h:334: error: wrong number of arguments specified for ‘__deprecated__’ attribute
/usr/local/include/yarp/os/Contact.h:344: error: wrong number of arguments specified for ‘__deprecated__’ attribute
/usr/local/include/yarp/os/Contact.h:354: error: wrong number of arguments specified for ‘__deprecated__’ attribute
/usr/local/include/yarp/os/Contact.h:365: error: wrong number of arguments specified for ‘__deprecated__’ attribute
/usr/local/include/yarp/os/Contact.h:375: error: wrong number of arguments specified for ‘__deprecated__’ attribute
/usr/local/include/yarp/os/Contact.h:391: error: wrong number of arguments specified for ‘__deprecated__’ attribute
/usr/local/include/yarp/os/Contact.h:405: error: wrong number of arguments specified for ‘__deprecated__’ attribute
/usr/local/include/yarp/os/Contact.h:416: error: wrong number of arguments specified for ‘__deprecated__’ attribute
/usr/local/include/yarp/os/Contact.h:429: error: wrong number of arguments specified for ‘__deprecated__’ attribute
/usr/local/include/yarp/os/Contact.h:441: error: wrong number of arguments specified for ‘__deprecated__’ attribute
/usr/local/include/yarp/os/Contact.h:459: error: wrong number of arguments specified for ‘__deprecated__’ attribute
/usr/local/include/yarp/os/Contact.h:473: error: wrong number of arguments specified for ‘__deprecated__’ attributeThe small hack for this can be seen on this line of yarp-devices root CMakeLists.txt:
add_definitions(-DYARP_NO_DEPRECATED_WARNINGS=ON)Use case: roboticslab-uc3m/kinematics-dynamics#98 suggests an API break, implemented in roboticslab-uc3m/kinematics-dynamics@21ec3ea
Should the old function be left around for a while, while marking it as deprecated (as in YARP and OpenRAVE)?
Here are my favourite to least favourite options:
More options/opinions?
See roboticslab-uc3m/installation-guides#22 for origin.
Most of the other organization repos have no apt-get except for on .travis.yml.
Question: Replace apt-get -> by apt even on Travis?
Here are some solutions (updated from roboticslab-uc3m/xgnitive#23):
PD: While we used to publish in https://sourceforge.net/projects/roboticslab/files/Datasets/, these are more modern and probably better solutions.
Where #include directives should be
Is there a TEO hardware manual?
In robotology/community#156 we commented on the intention of splitting several https://github.com/roboticslab-uc3m projects into mini-repositories and then unifying them through git submodules. An alternative was presented (in addition to another discussion), the superbuild mechanism.
I have personally always been quite reluctant to git submodules.
On the other hand, I have usually been satisfied with solutions proposed by the robotology community, and will be as long as YCM is just a thin layer over CMake proves to be YCM is just a thin layer *within* CMake as seems to be the fact.
@PeterBowman @David-Estevez Could you please share your opinion on this issue with us?
Many repos have examples that are compiled separately... that should not mean not having them tested via Travis!
As spoken with @David-Estevez the current names (TeoYarp, etc) are misleading. Options:
Opinions?
Branching this out from roboticslab-uc3m/kinematics-dynamics#103. I've replicated that behavior in latest yarp-devices and Ubuntu 16.04 64 bits, upon the addition of YCM in the build process (roboticslab-uc3m/yarp-devices@891df8f). This is apparently triggered by using both YCM (v0.2.2) and older CMake versions (tested: v2.8.9, v2.8.11). As a result, library binaries are compiled into build/lib/x86_64-linux-gnu. Inside this directory, exported header files are copied into Headers/.
Something among the lines of the following should increase visibility:
Opinions?
In some legacy code, we were used to see <Project>Config.cmake(.in) files with contents that resembled the following lines (source):
SET(KINEMATICS_DYNAMICS_MODULE_PATH "@KINEMATICS_DYNAMICS_MODULE_PATH@")
SET(KINEMATICS_DYNAMICS_DEFINES "@KINEMATICS_DYNAMICS_DEFINES@")
SET(KINEMATICS_DYNAMICS_INCLUDE_DIRS "@KINEMATICS_DYNAMICS_INCLUDE_DIRS@")
SET(KINEMATICS_DYNAMICS_LINK_DIRS "@KINEMATICS_DYNAMICS_LINK_DIRS@")
SET(KINEMATICS_DYNAMICS_LIBRARIES "@KINEMATICS_DYNAMICS_LIBRARIES@")These are now relics from the pre-target era, and as such, the <project>_INCLUDE_DIRS, <project>_LINK_DIRS and <project>_DEFINES variables (holding what is better known as usage requirements) no longer make sense when a <project>Targets.cmake file is finally being generated and exported by CMake along with each successful configuration. The <project>_LIBRARIES var is a mere alias for all exported targets, created plainly for convenience, but might (and perhaps should) be dropped in order to favour explicitness in downstream calls to target_link_libraries().
This is how said <package>Config.cmake.in template file looks now (source):
set(ROBOTICSLAB_KINEMATICS_DYNAMICS_INCLUDE_DIRS)
foreach(_dir @PACKAGE_ROBOTICSLAB_KINEMATICS_DYNAMICS_INCLUDE_DIR@)
set_and_check(_temp_var ${_dir})
list(APPEND ROBOTICSLAB_KINEMATICS_DYNAMICS_INCLUDE_DIRS ${_temp_var})
endforeach()
if(NOT "@_exported_targets@" STREQUAL "")
include(${CMAKE_CURRENT_LIST_DIR}/ROBOTICSLAB_KINEMATICS_DYNAMICSTargets.cmake)
set(ROBOTICSLAB_KINEMATICS_DYNAMICS_LIBRARIES)
foreach(_target @_exported_targets@)
list(APPEND ROBOTICSLAB_KINEMATICS_DYNAMICS_LIBRARIES ROBOTICSLAB::${_target})
endforeach()
endif()The main focus lies now on the following line:
include(${CMAKE_CURRENT_LIST_DIR}/ROBOTICSLAB_KINEMATICS_DYNAMICSTargets.cmake)A configuration file might be as simple as that, see CMake docs. Apart from said line, there is some safety boilerplate, as well as the aforementioned <package>_LIBRARIES alias and more checks and sets for <package>_INCLUDE_DIRS.
The reason behind keeping a variable to point at where headers are stored is linked to the essence of YARP interfaces. In fact, files such as ICartesianControl.h, ICartesianSolver.h, etc. (ref) do not belong to a specific library and therefore didn't undergo the common target mechanism standardization. However, CMake supports the so-called interface targets, suited for header-only libraries that do not generate any output binaries.
In this issue, I propose introducing interface targets for YARP stand-alone interface headers and dropping any exported variable that can be fully replaced by the target mechanism.
Also, the <package>_MODULE_PATH variable setter could be rewritten as one or more calls to the include() command, one per module directory. It is to be considered whether such behavior (automatic inclusion upon returning from find_package()) is desired.
Several long-time deprecated methods will get deleted with the next YARP release (2.3.70). Some of these include (current deprecation list):
yarp::dev::IPositionControl::setPositionMode()yarp::dev::IPositionControlRaw::setPositionModeRaw()yarp::dev::IPositionDirect::setPositionDirectMode()yarp::dev::IPositionDirectRaw::setPositionDirectModeRaw()yarp::dev::ITorqueControl::setTorqueMode()yarp::dev::ITorqueControlRaw::setTorqueModeRaw()yarp::dev::IVelocityControl::setVelocityMode()yarp::dev::IVelocityControlRaw::setVelocityModeRaw()Said methods were migrated upstream to the yarp::dev::IControlMode interface (docs). Apart from that, the yarp::dev::IOpenLoopControl interface and its companion yarp::dev::IOpenLoopControlRaw have been removed at robotology/yarp@73c65b2. Affected repositories:
Hi!
I have just discovered that yarp has a logging system for the log messages (info, debug, warning, error...) of their yarp devices. We are using a similar system for our devices, based on color-debug, but I guess their logging system has better integration with yarp devices and other yarp mechanisms. Messages would also look more homogeneous if sent to stdout with the yarp logger instead of our own system.
The question is... should we use yarp's internal logging for our devices? or should we stick to the current color-debug system?
The screenshots below illustrate how are TechnosoftIpos drivers configured in ASIBOT at this time:
I'll focus on the I2t Over current checkboxes and text inputs inside the Protections group on both windows. The latter is accessible from the Drive Info button in the upper center of the first screenshot.
Drive Info doesn't let us modify I2t, could we suppose that these values are pulled from the firmware?I2t calculated for TEO?I2t through EasySetUp/EasyMotionStudio or via CAN?CC @roboticslab-uc3m/teo.
@edwinDOS please expand in case I missed something.
There seems to be an unwritten rule about always developing against the latest version of YARP. After having read robotology/community#173, I concluded that we may benefit from defining such policies as projects grow larger and more people get involved in their development. I perceive this as a bit of a pressing matter since several of my past commits were mostly aimed at dealing with deprecations, code no longer working due to certain upgrade and achieving backwards compatibility where possible. For example, I'm unsure about the minimum version of CMake I should be targeting at and in consequence I will miss some of the newer features. Additionally, it's not clear to which extent hacks (sometimes dirty ones) must be applied to support outdated software.
The YARP team has a nice page that covers all dependencies:
http://wiki.icub.org/wiki/YARP_Supported_Distributions
Seeing this from another perspective, care should also be taken to conform to the latest releases of upstream software - in case such policy applies, too (as stated in the first sentence, YARP could be a candidate in this respect). To list some of these issues, developers should be aware of incoming deprecations (see roboticslab-uc3m/yarp-devices@efb8962) and keep their documentation up-to-date (roboticslab-uc3m/installation-guides#1).
There are a couple of problems related to Teo movements and it can ruin a demonstration (leading to reset it several times... 😓)
I don't know where I can post this problems, because the first can be a software problem, but the second it can be a tunning motors problem ¿? I don't know
I need some ideas to solve it.
Recommendation/petition: please use yarp namespace if working within robot network (e.g. TEONET) and not using robot (e.g. TEO).
Reason: Address (name) collisions due to sharing yarp server.
Solution: If not connecting to robot, set yarp namespace /yourname, and work with your own instance of yarp server. To return to the robot's namespace, close this instance, and type yarp namespace /root.
Thank you! 🎉
From @rsantos88 on October 4, 2017 8:33
To advance in the correct way with grasping in openrave, we need to make the actual Teo hand able to open and close like the barrett hand.
Which are the steps to follow?
Copied from original issue: roboticslab-uc3m/openrave-yarp-plugins#37
Alberto Jardón y Carlos me han pedido subir un vídeo que grabamos ayer de la demo waiter al canal de RoboticsLabUC3M. ¿Podrías @jgvictores facilitarme usuario y contraseña?
Gracias!!!
Think about "Archive this repository"
For starters, I'd elaborate a list of all the functional libraries (these will mostly be yarp devices) that are of use, and functional programs. Once we lay the tree out, it will be easier to see what goes where. This could take some time!
Yes! That is the question... how can I PbD!?
Is there a TEO software manual?
Following the lines of this comment at roboticslab-uc3m/teo-main#8, and also with #7 (latest-YARP policy) and #16 (YARP deprecations striking out of nowhere) in mind, it might be worth running periodic builds for each repo - say, once a week? - that would fetch YARP's devel branch to keep up with any breaking changes being prepared for the next release. The reasoning behind this is simple: use Travis' mechanisms to warn us against upcoming trouble even if nobody is keeping an eye on YARP's development progress. Such issues will surely arise at stale projects (like asibot-main was until quite recently).
One may use the TRAVIS_EVENT_TYPE default environment variable to differentiate between the usual push jobs and the cron ones.
List of repos on which cron builds have been enabled (roboticslab-uc3m at travis-ci.org):
Currently, it's a common practice in repos that perform unit testing with Travis CI to host a gtest-x.x.x directory within test/, see kinematics-dynamics. Proposal: remove those files and install Google's testing framework via apt:
We don't know how to do this (yet). See roboticslab-uc3m/kinematics-dynamics#132 (comment).
I've set up CI builds for asibot-hmi with this configuration; note that this project depends on kinematics-dynamics, hence an additional git clone step. To avoid building KDL, which is a dependency for kinematics-dynamics itself, I had to configure it appropriately:
cmake .. -DENABLE_TrajectoryLib:BOOL=OFF \
-DENABLE_KdlVectorConverterLib:BOOL=OFF \
-DENABLE_BasicCartesianControl:BOOL=OFF \
-DENABLE_CartesianControlServer:BOOL=OFF \
-DENABLE_CartesianControlClient:BOOL=OFF \
-DENABLE_KdlSolver:BOOL=OFF \
-DENABLE_BasicTwoLimbCartesianControl:BOOL=OFF \
-DENABLE_TwoLimbCartesianControlServer:BOOL=OFF \
-DENABLE_tests:BOOL=OFF
First remark: any options irrelevant to my project could've been set to OFF/FALSE in kinematics-dynamics' root CMakeLists.txt file. Therefore, I'd just concentrate on the funcionalities I'm really interested in, not the other way around.
Then, I configured periodic cron jobs targeted at discovering issues linked with the development of YARP. However, my latest build errored because of recent changes to kinematics-dynamics (CI logs), which happened to introduce a new dependency on KDL. This forced me to take a look upstream and update my .travis.yml accordingly: roboticslab-uc3m/asibot-hmi@9b1959d.
As a second remark, one must always keep an eye on each upstream repo because of new dependencies or changes in CMake configuration. This and the previous remark could be easily extended to YCM-like repos (e.g. teo-main) for the same reasons.
Proposal:
OFF (FALSE)ccmake, cmake-gui) in install guides for ease of initial CMake configuration phaseCMakeLists.txt files, which are easily subject to changes, to provide you the desired configurationRegarding the last point and YCM projects, the CONFIGURE_COMMAND parameter to ycm_ep_helper should come in handy (docs).
Singular or plural and other conventions:
example (yarp-ish) vs examples directory.cmake/template vs cmake/templatestest(s)Proposed ToDo:
We currently have a best practice section in http://robots.uc3m.es
Seeing issues like roboticslab-uc3m/asibot-main#24 (and recent doubts where I've confirmed we like namespaces, etc) I'd say it's a good idea to continue storing our best practices, but move on to markdown on GitHub. Specifically, I propose to begin a repository and generate a GitBook from it. Potential names:
Ideas/alternatives/anything...?
I am currently documenting the dependencies of the textiles project and I haven't been able to find any instructions about how to document a project within the RoboticsLab organization.
Textiles is a large project mixing C++ and Python, using non-stable package versions for some dependencies in order to get state of the art methods not available in stable releases.
As no other project depends on it (yet)... should I include my dependencies / instructions in my repo only? should I use whatever method has been chosen for the main repos of this organization? where can I find that method?
I need a table for a new student. The best option is the table in front of TEO.
can you ( @jgvictores or @RaulFdzbis ) to loof for new place out of the lab for the TV ??
thx
A nasty bug was introduced right before the v0.2.3 and v0.4.0 releases of YCM. It's still present at latest HEAD, for this reason all Travis builds in YCM-enabled repos have been erroring for several weeks: robotology/ycm#118. While this issue is especially noticeable with regard to our CI tools, regular users may experiment the same problems if they recently upgraded their local YCM copy. Current workarounds include:
git checkout tags/v0.2.2).v0.2.2 tag (see roboticslab-uc3m/kinematics-dynamics@6a69f5d).The latter patch has been applied to root CMakeLists.txt at the following repos:
I'd like to leave this issue open until upstream YCM master is fixed. However, we may consider leaving the YCM_TAG thing for good and simply keep updating the release version number to avoid dealing with sudden breakages (one would expect that master branch should be stable, which was not the case here).
As work on #2 goes on, we'll find out that former TEO-specific code is intented to target a wider range of robot platforms, thus rendering the omnipresent teo:: namespace quite inappropriate for common libraries. Proposed solutions:
rl::, rl::teo::, rl::asibot::, rl::amor::, etc.I don't remember how to solve this annoying problem when I connect with a yarp rpc port and I press the direction keys:
yarp rpc /tts/rpc:s
^[[C^[[C^[[C^[[B^[[A
The yarpdev utility suggests using a --verbose CLI parameter in order to list all available options, their description, default value, etc. This comes in handy when working with our own devices, which undergo frequent changes in their usage (or, simply put, are barely or not documented at all). Traditionally, we introduced the --help parameter, but it's hard to maintain (needs hardcoding plus some care to keep it up to date).
YARP offers its own mechanisms for such tasks, tightly bound to the yarp::dev::PolyDriver class: the YarpDevMonitor utility (not shown in Doxygen generated docs nor even exported, check PolyDriver.cpp). Such instance is created by all PolyDriver objects and can be propagated to subdevices (either wrapped devices, or devices opened by other devices in their DeviceDriver::open method). Example:
Try this via yarpdev --device ... with and without --verbose. Example:
yarpdev --device FakeControlboard --name /fake
yarpdev --device BasicCartesianControl --local /local --remote /fake --kinematics path.ini --verboseSome thoughts:
--help actually made the device stop and exit (but remember: std::exit is evil)check calls and add missing comments/defaultsyarpdev, but we'll surely want to achieve the same results with RF modulesThoughts about path-planning within roboticslab-uc3m, and considerations on creating a path-planning repository within the organization.
Considerations to be taken into account before blindly doing this:
As seen, the above candidates already have their place. Therefore, my recommendations are the following:
We've upgraded @roboticslab-uc3m to an organization plan with unlimited free private repositories and unlimited seats (renewable after 2 years).
@PeterBowman All is set to import https://github.com/jgvictores/amor-api to https://github.com/roboticslab-uc3m 😄
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 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.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
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.