roboticslab-uc3m / teo-main Goto Github PK

From @rsantos88 on April 6, 2018 12:5

Estamos @AlvaroMartinezR y yo reordenando todos los cables y conexiones porque estamos instalando el nuevo router. Teo no funcionará hasta el lunes. Gracias

Copied from original issue: roboticslab-uc3m/questions-and-answers#58

Original issue: roboticslab-uc3m/kinematics-dynamics#31

Robot model joint limits reference should be in https://github.com/roboticslab-uc3m/teo-software-manual/blob/master/appendix/a-teo-diagrams.md

The following is a list of models to potentially be updated.

• .ini of launch files: https://github.com/roboticslab-uc3m/teo-configuration-files/tree/develop/share/launchManipulation and https://github.com/roboticslab-uc3m/teo-configuration-files/tree/develop/share/launchLocomotion
• .ini of kinematics files: https://github.com/roboticslab-uc3m/teo-configuration-files/tree/develop/share/kinematics
• Openrave models: https://github.com/roboticslab-uc3m/teo-openrave-models
• Gazebo models: https://github.com/roboticslab-uc3m/teo-gazebo -> roboticslab-uc3m/legacy-teo-gazebo#5
• ROS URDF model: https://github.com/roboticslab-uc3m/teo-ros-simulation -> roboticslab-uc3m/teo-ros-simulation#4
• ArmarX models: https://github.com/roboticslab-uc3m/teo-simox-models -> roboticslab-uc3m/teo-simox-models#3

Rename files in doc

We currently recommend /etc/hosts in the teo-developer-manual section.

Look at: asrob-uc3m/impresoras-asrob#49 (comment)

Tal y como hablé con @jgvictores y @PeterBowman, está pensado actualizarse teo-head a Ubuntu 16.04. Estoy pendiente de que Miguel Garcia Dominguez termine de realizar un backup de la información que pueda contener ahora mismo este ordenador. Según me ha comentado por correo, se pasará este martes (día 30/04/2019).

Link to https://github.com/roboticslab-uc3m/teo-configuration-files

Extracted from an old version of https://github.com/roboticslab-uc3m/teo-developer-manual :

We are in fact considering creating specific superbuild repositories for each TEO PC.

• teo-manipulation: For the TEO manipulation PC (arms and head joint control, JR3 force/torque sensors).
• teo-locomotion: For the TEO locomotion PC (legs and torso joint control, Xsens inertial sensor)
• teo-head: For the TEO head PC (ASUS XTion Pro Live RGBD sensor, PointGrey RGB camera).

If we are really doing a superbuild, we have to pre-install all the dependencies!!!

From @rsantos88 on November 14, 2017 17:28

There are a couple of problems related to Teo movements and it can ruin a demonstration (leading to reset it several times... 😓)

• The first occurs randomly, when the program sends a sequence of movements, for example salute, composed by four movements: lift arm up, axial arm turn in, axial arm turn out, move arm down.
  We can see that this movement is not executed correctly in certain occasions. The arm finishes the movements early, running all at once and not sequentially. This can produce a freeze of all the demo, because the movement has not finished correctly all the sequence. Can it be a problem with checkMotionDone() function? Why does it works well sometime and sometimes not?
• Other problem observed is, when Teo makes a movement (I would highlight axial movements), sometimes is not finished and the joint starts to shake (like a parkinson). This may take a while (shaking horribly) until the movement finally ends.

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.

Copied from original issue: roboticslab-uc3m/questions-and-answers#34

From @rsantos88 on March 14, 2018 10:27

When we try to use the services of teoBase_app running through YARP module manager, the computers of TEO are unavailables.
Note: I've tried this trick but it doesn't work.
Yarp version instaled on TEO computers: 2.3.70.2
Yarp version instaled on client computer: 2.3.72

Copied from original issue: roboticslab-uc3m/yarp-devices#173

• best-practices
• project-generator
• Update https://github.com/roboticslab-uc3m/teo-software-manual/blob/master/overview-pc.md

Review and Unify TEO kinematic model.

The first step is for table and drawing to agree. Following the workflow for assets, this means we:

1. First edit dh-drawing.svg and dh-table.ods.
2. Then update the corresponding generated assets and resources of other repositories.

Related with most documentation issues. At time of writing, blocked by #23 and #39.

Edit: Very small tool that (may) be nice for debugging: https://github.com/arcoslab/roboview (http://wiki.icub.org/wiki/KDL-simple)

From @jgvictores on June 28, 2016 10:29

The current use of daemontools makes yarprun run sometimes without connecting to the yarp server, which causes problems such as roboticslab-uc3m/kinematics-dynamics#42.
A yarp detect or similar (checking the return value) should be included in the daemontools service script (/etc/service/yarprun) or even completely replace daemontools for a different method to avoid this.

Copied from original issue: roboticslab-uc3m/kinematics-dynamics#43

Using:

• launchManipulation which uses https://github.com/roboticslab-uc3m/yarp-devices
• gcmp from BasicCartesianControl from https://github.com/roboticslab-uc3m/kinematics-dynamics

launchManipulation can be launched, but having issues when used with stated [gcmp]: torque mode is set, but driver 1 of rightArm seems to be in position control (note that kin-dyn stat and yarp-dev [get] [icmd] [cmds] indicate all okay). Sending kin-dyn [stop] then [gcmp] again makes it worse: despite that kin-dyn stat and yarp-dev [get] [icmd] [cmds] indicate all okay, all act in practice as if position mode.

YCM installation-guides

From @AlvaroMartinezR on November 8, 2017 12:15

I have been working with SolidWorks and other CAE programs in order to develop an accurate dynamic model for TEO, including masses, inertias, CoM. It is not yet finished, but I wonder in which repository this kind of information (probably a .doc or a .pdf file) could be placed into.

Copied from original issue: roboticslab-uc3m/teo-openrave-models#11

This is a follow-up of roboticslab-uc3m/openrave-yarp-plugins#27. There are currently two versions of teoSim.

1. Old program: openrave-yarp-plugins/programs/teoSim
2. New script: teo-configuration-files/scripts/bash/teoSim

The new version is much more sophisticated, solving issues such as roboticslab-uc3m/openrave-yarp-plugins#12 and roboticslab-uc3m/openrave-yarp-plugins#36 and many more. The current drawbacks are roboticslab-uc3m/openrave-yarp-plugins#60 (which should not affect teoSim, as it is via CLI without Python), and roboticslab-uc3m/openrave-yarp-plugins#59 (which is currently solved via closing using the simulator close button, or yarp clean in worst-case-scenario).

It is recommended to update and install the following repositories, as old teoSim will most probably be erased this week (will be announced and closed at roboticslab-uc3m/openrave-yarp-plugins#27):

• https://github.com/roboticslab-uc3m/openrave-yarp-plugins
• https://github.com/roboticslab-uc3m/teo-configuration-files

If you have any issues, do not doubt to post them on the corresponding repository!

From @rsantos88 on October 19, 2017 11:16

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:

• Actualizar la partición arrancable de Backup que hay instaladas en cada uno de los PCs de TEO (backups realizados a fecha 22/04/2016 (ver issue) a una imagen actual
• Posible instalación de un banco de pruebas para cualquier tipo de cambio importante que requiera TEO

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.

Copied from original issue: roboticslab-uc3m/questions-and-answers#33

Currently we have implemented on yarp module manager the command /sbin/runuser to call remotely Teo applications, but with the new downgrade of teo-head (Ubuntu 14.04), when we call this command it can't be found. So, looking for this error, I found that this Ubuntu version doesn't support util-linux 2.23 (this command appeared in util-linux 2.23). Ubuntu 14.04 ships util-linux 2.20, so it doesn't have this command.

Migration from Debian 6.0 to Ubuntu 14.04 on TEO

ToDo:

• Try hc-driver-4.9 on TEO #26
• jr3 drivers with Ubuntu 14.04
• Try xsense (see roboticslab-uc3m/installation-guides#35 )
• Install daemontools as described here
• Change boot order: make Ubuntu default.
• Documentation
  • Create GitHub releases, before erasing all Debian 6.0 documentation.
  • update this table using the agreed format (csv) -> Update: here

Respect with the last changes of forearm piece, it remains to make all the changes regarding the new kinematics, diagrams, model of Teo, etc ...

CMake/YCM not finding already installed repos, the result of doing a cmake over teo_main is the following:

-- Libraries go to /home/raul/repos/teo-main/build/lib
-- Executables go to /home/raul/repos/teo-main/build/bin
-- YCM found in /usr/local/share/YCM.
-- Package TEO_DEVELOPER_MANUAL not found. Will be downloaded and built.
-- Package TEO_CONFIGURATION_FILES not found. Will be downloaded and built.
-- Package TEO_OPENRAVE_MODELS not found. Will be downloaded and built.
-- Package ROBOTICSLAB_DEVELOPER_MANUAL not found. Will be downloaded and built.
-- Package ROBOTICSLAB_PROJECT_GENERATOR not found. Will be downloaded and built.
-- Package ROBOTICSLAB_INSTALLATION_GUIDES not found. Will be downloaded and built.
-- Configuring done
-- Generating done
-- Build files have been written to: /home/raul/repos/teo-main/build

However in my system i have already installed TEO_OPENRAVE_MODELS and TEO_CONFIGURATION_FILES, is this an expected behaviour?

The installation was completed succesfully though.

Started TEO parameter and diagram review and unify project at https://github.com/orgs/roboticslab-uc3m/projects/6

Add continuous integration (e.g. via travis).

As spoken with @rsantos88 @PeterBowman @smcdiaz, as part of Review and Unify TEO kinematic model (#38 and roboticslab-uc3m/teo-developer-manual#40) we are going to change the head (neck) joint order so we can have a nice DH parameter description of the trunk+head kinematic chain (past: 0=no, 1=yes; future: 0=yes, 1=no).

Sorry for the inconveniences! Tasks involved:

• update diagrams
• update .ini configuration files
• update simulation models

Review Joint Directions of Rotation https://github.com/roboticslab-uc3m/teo-developer-manual/blob/master/appendix/a-teo-diagrams.md#joint-directions-of-rotation then unify

Due ALMA EU project needs, the idea is to develop a docker to make easier to develop and deploy algorithms that has to be tested on TEO platform (at least at simulation level...)

Our new head PC will feature a NVIDIA Jetson AGX Xavier mounted on a Rogue carrier board. Hint: this is not the Xavier 8GB, nor the RogueX board. For future reference, instructions for installation and flashing can be found here. Prior to attempting an apt upgrade, please also read this.

This board provides two CAN buses and has built-in support via kernel modules. It seems that the right module is "mttcan", although initially blacklisted (delete /etc/modprobe.d/blacklist-mttcan.conf to enable it on boot). It is also straightforward to configure a CAN interface on boot via systemd, see roboticslab-uc3m/yarp-devices#251 (comment).

At time of writing, I am able to read messages (using 1 Mbps bitrate), but not to send them.

PS the can0 connector is the one farthest from the passive heat sink. Can1 is not configured whatsoever.

Review and Unify TEO joint names

• https://github.com/roboticslab-uc3m/teo-developer-manual
• Openrave models: https://github.com/roboticslab-uc3m/teo-openrave-models
• [ ] Gazebo models: https://github.com/roboticslab-uc3m/teo-gazebo
  • legacy repo, now we use this: https://github.com/roboticslab-uc3m/teo-gazebo-models
• ROS URDF model: https://github.com/roboticslab-uc3m/teo-ros-simulation
• ArmarX models: https://github.com/roboticslab-uc3m/teo-simox-models
• .ini of launch files: https://github.com/roboticslab-uc3m/teo-configuration-files/tree/develop/share/launchManipulation and https://github.com/roboticslab-uc3m/teo-configuration-files/tree/develop/share/launchLocomotion (?????)
  • check our new implementation
• [ ] .ini of kinematics files (?????)
  • no joint names involved here

Need functional version of this repo.

From @jgvictores on April 20, 2016 10:59

Issue inherited from wiki, where work has been done (resulting in current TEO Diagrams). The following is a list of models to potentially be merged or linked somehow.

• Kinematics(DH)+Mass/Inertia used by KdlSolver: [1].
• OpenRAVE 3D and Kinematics used by teoSim: [2]
• Gazebo 3D and Kinematics+Mass/Inertia used by teo-ros-simulation: [3]

For future reference, links to Mass/Inertia (official based on mechanical schematics): .XLS and .PDF.

Updated on 16/08/17 by PeterBowman.

Copied from original issue: roboticslab-uc3m/kinematics-dynamics#29

@rsantos88 and me are trying to unify the limits of TEO's joint based on the real robot rather than broad approximations, but without the encoder board we can't. As mentioned in #15

From @jgvictores on March 7, 2017 18:6

Hola,

Es posible que el Pc-teomain del laboratorio esté desactualizado y que algunas cosas no funcionen?? y en caso afirmativo, para cuando podría estar listo?? gracias

Copied from original issue: roboticslab-uc3m/teo-developer-manual#3

From @munozyanez on March 9, 2017 14:17

Recent merge (roboticslab-uc3m/kinematics-dynamics#83) has uploaded a revised DH parameters configuration in the following folder:

• https://github.com/roboticslab-uc3m/kinematics-dynamics/tree/develop/share/kinematics
  To be more specific, files
• https://github.com/roboticslab-uc3m/kinematics-dynamics/blob/develop/share/kinematics/leftLegKinematics.ini
• https://github.com/roboticslab-uc3m/kinematics-dynamics/blob/develop/share/kinematics/rightLegKinematics.ini
  Have changed according DH Parameter Table published in http://robots.uc3m.es/index.php/TEO_Diagrams .

Copied from original issue: roboticslab-uc3m/kinematics-dynamics#87

Old teo-main is now kinematics-dynamics. Please fresh clone this repo when ready!

Link to manuals from root readme

From @munozyanez on April 20, 2017 19:25

Launching ´´yarpdev --device BasicTwoLimbCartesianControl´´ results in a faulty movement on teo.
teoSim is working correctly with the same parameters.

Find below some points as example.

´´
New trajectory segment : 1->2, Segment index: 1

rfX: 0,-0.124531,-0.825,> rot: -0.707107,-4.32978e-17,0.707107,180,
New trajectory segment : 1->2, Segment index: 1
lfX: 0,0.132469,-0.825,> rot: 0,-1,0,90,
[STEP] [0.239693] x 0.000000 -0.124531 -0.825000 -0.707107 -0.000000 0.707107 180.000000 0.000000 0.132469 -0.825000 0.000000 -1.000000 0.000000 90.000000 xdot 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000
[STEP] [0.239693] 0.001512 0.005314 0.019545 0.003074 -0.008279 -0.001534 -> 0.090844 -0.446273 -43.171995 90.580035 -47.882676 0.270900 [deg/s]
rightLeg encoders: [-0.0878735, 0.0878735, -2.0914, 4.48155, -1.91565, 0.0878735]
[STEP] [0.239693] -0.000482 0.007203 0.019518 0.004293 -0.001233 0.002763 -> 0.157589 -0.599489 -47.676554 100.258585 -52.652003 0.353329 [deg/s]
leftLeg encoders: [-0.158173, 0.246063, -2.02109, 4.11249, -2.02109, -0]
rfX: 0,-0.11952,-0.825,> rot: -0.707107,-4.32978e-17,0.707107,180,
lfX: 0,0.13748,-0.825,> rot: 0,-1,0,90,
[STEP] [0.289795] x 0.000000 -0.119520 -0.825000 -0.707107 -0.000000 0.707107 180.000000 0.000000 0.137480 -0.825000 0.000000 -1.000000 0.000000 90.000000 xdot 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000
[STEP] [0.289795] -0.005570 0.010314 0.019619 0.003062 0.007058 -0.001534 -> 0.082125 -0.902988 -47.336021 100.284197 -52.544070 0.726950 [deg/s]
rightLeg encoders: [-0.0878735, 0.0878735, -2.35501, 4.04218, -2.0914, 0.0878735]
[STEP] [0.289795] -0.001189 0.007640 0.019607 -0.003067 0.000311 0.002761 -> 0.158424 -0.731755 -46.845017 98.606666 -51.744314 0.907526 [deg/s]
leftLeg encoders: [-0.158173, -0.0878735, -2.10896, 4.20035, -2.10896, -0.0878735]

´´

Copied from original issue: roboticslab-uc3m/yarp-devices#115

From @jgvictores on March 7, 2015 8:35

Review dynamic models (masses, COGs and inertias) currently in teo-configuration-files/share/kinematics.

Updated on 16/08/17 by PeterBowman.

Copied from original issue: roboticslab-uc3m/kinematics-dynamics#6

From @jgvictores on October 14, 2016 8:55

Try and doc teoBase with walking demo.

• Try
• Doc at http://robots.uc3m.es/index.php/Procedimiento_Demos

Copied from original issue: roboticslab-uc3m/kinematics-dynamics#67

Review and Unify TEO link names, in parallel to #16 (dynamic info), etc.

• https://github.com/roboticslab-uc3m/teo-developer-manual
• Openrave models: https://github.com/roboticslab-uc3m/teo-openrave-models
• [ ] Gazebo models: https://github.com/roboticslab-uc3m/teo-gazebo
  • legacy repo, now we use this: https://github.com/roboticslab-uc3m/teo-gazebo-models
• ROS URDF model: https://github.com/roboticslab-uc3m/teo-ros-simulation
• ArmarX models: https://github.com/roboticslab-uc3m/teo-simox-models
• .ini of launch files: https://github.com/roboticslab-uc3m/teo-configuration-files/tree/develop/share/launchManipulation and https://github.com/roboticslab-uc3m/teo-configuration-files/tree/develop/share/launchLocomotion (?????)
  • check our new implementation
• [ ] .ini of kinematics files: https://github.com/roboticslab-uc3m/teo-configuration-files/tree/develop/share/kinematics (?????)
  • no link names involved here

Try hc-driver-4.9 on TEO.

If https://github.com/munozyanez/hc-driver-4.9 works, this may affect the Distro we use, propagating to roboticslab-uc3m/yarp-devices#111 and even roboticslab-uc3m/questions-and-answers#17.

This issue originates from roboticslab-uc3m/yarp-devices#118 but is specific to TEO.

From @jgvictores on October 4, 2017 15:26

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

Copied from original issue: roboticslab-uc3m/questions-and-answers#31

Cool demo can be made via small app using tools/programs/controlboardStateToIPosition: teoSim tracking TEO movements, having set TEO in gravity compensation ([gcmp]) mode.

Must update BuildROBOTICSLAB_BEST_PRACTICES.cmake -> BuildROBOTICSLAB_DEVELOPER_MANUAL.cmake

From @jgvictores on October 14, 2016 8:31

Try and doc teoBase with TEO_push demo.

• Try
• Doc at http://robots.uc3m.es/index.php/Procedimiento_Demos

Copied from original issue: roboticslab-uc3m/kinematics-dynamics#65

From @rsantos88 on June 8, 2016 14:39

Se han detectado lentitud en las comunicaciones con los ordenadores de manipulación y locomoción utilizando Wifi en las siguientes situaciones:

• Con el qtcreator abierto por ssh en el ordenador de manipulación, se aprecian bloqueos constantes del programa cuando se da la situación de que Loli está trabajando a la vez con otra terminal conectada por ssh al mismo PC para realizar otras tareas (en este caso, únicamente la adquisición de datos de los sensores).
• Loli haciendo pruebas con las piernas ha detectado también lentitud. Para ello necesita recibir datos de los sensores de los pies a través de Yarp desde el ordenador de manipulación. La conexión entre puertos tarda en hacerse (más de 5 segundos). Al editar un documento por ssh, navegar por la terminal..etc se percibe lentitud.

Copied from original issue: roboticslab-uc3m/yarp-devices#63

On 28th September, an attempt was made to launch a gait trajectory @Luis93A had prepared beforehand using https://github.com/robotology/walking-controllers and reworked TEO's SDF/URDF models. The dataset (involving both legs, both arms and the trunk) and the config file are uploaded here: teo-gait-20210927.zip. We used examplePlaybackThread from the tools repo in order to issue the joint commands.

The plan for said session was as follows:

• A dry-run of the offline-saved trajectory on the real robot (i.e. while lifted by its crane).
• Same trajectory, robot actually walking on the floor.
• Online-generated trajectory using FT sensor feedback.

We only managed to fulfill the first point, at least most of it. A control error was triggered in ID4 (right frontal hip). Currently, we are facing other blocking issues, though:

• CUI111 (frontal left ankle) was reporting weird values on start, usually around 60-67 degrees. This is probably a known issue, I think we already experienced a similar behavior in the past. On this occasion, Luís noticed the encoder was visibly damaged and it stopped responding altogether (i.e. no response from polling) later during the experiments. I suggest to replace this CUI.
• Prior to that, maybe related or not, faulty behavior was observed on left leg bus: roboticslab-uc3m/yarp-devices#246 (comment). However, this time no bus restarts seemed to occur, but we did observe an iPOS error pointing at a damaged connection with the relative encoder. If CUI111 is not the underlying cause for this, the wiring and connectors along the left leg bus should be closely inspected.

cc @smcdiaz

there is an error compilation on manip-waiter repo (branch: jr3) related with ICartesianSolver.h

In file included from /home/teo/repos/manip-waiter/programs/jr3WristControl/InCvPort.cpp:3:0:
/home/teo/repos/manip-waiter/programs/jr3WristControl/InCvPort.hpp:14:30: fatal error: ICartesianSolver.h: No such file or directory
compilation terminated.
programs/jr3WristControl/CMakeFiles/jr3WristControl.dir/build.make:62: recipe for target 'programs/jr3WristControl/CMakeFiles/jr3WristControl.dir/InCvPort.cpp.o' failed
make[2]: *** [programs/jr3WristControl/CMakeFiles/jr3WristControl.dir/InCvPort.cpp.o] Error 1
CMakeFiles/Makefile2:332: recipe for target 'programs/jr3WristControl/CMakeFiles/jr3WristControl.dir/all' failed
make[1]: *** [programs/jr3WristControl/CMakeFiles/jr3WristControl.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2

• Generate trajectories
• Perform on sim
• Perform on real

Edited from: Perform squats using TrajectoryLib of roboticslab-uc3m/kinematics-dynamics#134, preferably from Python (related: roboticslab-uc3m/kinematics-dynamics#168)

From @jgvictores on October 14, 2016 8:43

Try and doc teoBase with grasping demo.

• Try
• Doc at http://robots.uc3m.es/index.php/Procedimiento_Demos

Copied from original issue: roboticslab-uc3m/kinematics-dynamics#66