Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Setup conda environment to run the ergoCub walking controller in Gazebo #163

Open
xela-95 opened this issue Jan 16, 2024 · 18 comments
Open

Comments

@xela-95
Copy link
Member

xela-95 commented Jan 16, 2024

I am trying to reproduce the test performed by @carloscp3009 of running the walking controller on Gazebo, this time by using a conda environment instead of the robotology-superbuild.

I created the environment with the following command:

mamba create -n walking -c robotology -c conda-forge bipedal-locomotion-framework=0.17.0 idyntree yarp icub-contrib-common icub-main osqp-eigen qpoases libunicycle-footstep-planner gazebo catch2 gazebo-yarp-plugins whole-body-estimators icub-models ergocub-software

When building with make I obtained the following error:

In file included from /home/acroci/repos/walking/src/WalkingModule/src/main.cpp:14:
/home/acroci/repos/walking/src/WalkingModule/include/WalkingControllers/WalkingModule/Module.h:25:10: fatal error: BipedalLocomotion/YarpUtilities/VectorsCollectionServer.h: No such file or directory
   25 | #include <BipedalLocomotion/YarpUtilities/VectorsCollectionServer.h>
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

@S-Dafarra discovered this is due to the fact that such header is defined in bipedal-locomotion-framework version 0.17.0, whereas version 0.16.0 was installed.

I tried also to pin the version of bipedal-locomotion-framework by running:

mamba create -n walking -c robotology -c conda-forge bipedal-locomotion-framework=0.17.0 idyntree yarp icub-contrib-common icub-main osqp-eigen qpoases libunicycle-footstep-planner gazebo catch2 gazebo-yarp-plugins whole-body-estimators icub-models ergocub-software

but it was not possible to create such environment for dependency incompatibilities:

Looking for: ['bipedal-locomotion-framework=0.17.0', 'idyntree', 'yarp', 'icub-contrib-common', 'icub-main', 'osqp-eigen', 'qpoases', 'libunicycle-footstep-planner', 'gazebo', 'catch2', 'gazebo-yarp-plugins', 'whole-body-estimators', 'icub-models', 'ergocub-software']

robotology/linux-64                                         Using cache
robotology/noarch                                           Using cache
conda-forge/linux-64                                        Using cache
conda-forge/noarch                                          Using cache
Could not solve for environment specs
The following packages are incompatible
├─ bipedal-locomotion-framework 0.17.0**  is installable and it requires
│  └─ libbipedal-locomotion-framework 0.17.0 he4f1b30_0, which requires
│     └─ libyarp >=3.9.0,<3.9.1.0a0 , which requires
│        └─ ace >=7.1.2,<7.1.3.0a0 , which can be installed;
└─ icub-main is not installable because there are no viable options
   ├─ icub-main [1.19.1|1.19.2] would require
   │  └─ ace >=7.0.1,<7.0.2.0a0 , which conflicts with any installable versions previously reported;
   ├─ icub-main [1.19.2|1.20.0] would require
   │  └─ ace >=7.0.2,<7.0.3.0a0 , which conflicts with any installable versions previously reported;
   ├─ icub-main [1.20.0|1.21.0] would require
   │  └─ ace >=7.0.3,<7.0.4.0a0 , which conflicts with any installable versions previously reported;
   ├─ icub-main 1.21.0 would require
   │  └─ ace >=7.0.4,<7.0.5.0a0 , which conflicts with any installable versions previously reported;
   ├─ icub-main 1.22.0 would require
   │  └─ ace >=7.0.5,<7.0.6.0a0 , which conflicts with any installable versions previously reported;
   ├─ icub-main [1.23.1|1.24.0|1.24.1] would require
   │  └─ ace >=7.0.6,<7.0.7.0a0 , which conflicts with any installable versions previously reported;
   ├─ icub-main [1.25.0|1.26.0] would require
   │  └─ ace >=7.0.7,<7.0.8.0a0 , which conflicts with any installable versions previously reported;
   ├─ icub-main [1.26.1|1.27.0|1.28.1] would require
   │  └─ ace >=7.0.8,<7.0.9.0a0 , which conflicts with any installable versions previously reported;
   ├─ icub-main 1.28.1 would require
   │  └─ ace >=7.0.9,<7.0.10.0a0 , which conflicts with any installable versions previously reported;
   ├─ icub-main 2.0.2 would require
   │  └─ ace >=7.0.11,<7.0.12.0a0 , which conflicts with any installable versions previously reported;
   ├─ icub-main [2.1.0|2.1.1|2.2.0] would require
   │  └─ ace >=7.1.0,<7.1.1.0a0 , which conflicts with any installable versions previously reported;
   └─ icub-main [2.2.1|2.3.0|2.4.0] would require
      └─ ace >=7.1.1,<7.1.2.0a0 , which conflicts with any installable versions previously reported.

CC @traversaro @S-Dafarra

@traversaro
Copy link
Member

The problem is that we have been not generating any package in the robotology channel (so icub-contrib-common, icub-main, whole-body-estimators and ergocub-software) for a while, mainly because we run out of space on the robotology anaconda channel. So while conda-forge packages like yarp are building with recent versions of libraries like ace, icub-main only has version have have been compiled with old ace versions, and hence you can't install a recent version of yarp (required by the latest version of blf) with a icub-main compiled with an older ace version. The solution is to unblock the generation of packages on the robotology channel.

@traversaro
Copy link
Member

@xela-95
Copy link
Member Author

xela-95 commented Jan 16, 2024

Ok understood thanks @traversaro. I can close this issue for now since the reason belongs to external factors to the repository.

When it will be possible to create the environment with the right dependencies I will run the walking controller using conda and then open a PR to document the process.

@xela-95 xela-95 closed this as completed Jan 16, 2024
@traversaro
Copy link
Member

A possible alternative is to move all dependencies to conda-forge, see . However, robotology channel workflow is useful, so anyhow I would like to fix robotology/robotology-superbuild#1572 .

@traversaro
Copy link
Member

@xela-95 @S-Dafarra just FYI, as discussed in robotology/robotology-superbuild#1572 we fixed the generation of packages in the robotology channel, so now updated version of the packages icub-contrib-common, ergocub-software and icub-main are available in robotology, so you should be able to install them with a recent version of blf (probably at this point you are interested in 0.18.0, not 0.17.0 ).

@xela-95 xela-95 reopened this Jan 29, 2024
@xela-95
Copy link
Member Author

xela-95 commented Jan 29, 2024

Thank you @traversaro, now it is possible to create the mamba environment with the following command:

mamba create -n walking  -c robotology -c conda-forge bipedal-locomotion-framework=0.18.0 idyntree yarp icub-contrib-common icub-main osqp-eigen qpoases libunicycle-footstep-planner gazebo catch2 gazebo-yarp-plugins whole-body-estimators icub-models ergocub-software

I tried to run the simulation as explained in the readme but I got stuck at step 6. When I executed YARP_CLOCK=/clock WalkingModuleI got the following errors:

[INFO] |yarp.os.Port|/IITICUBLAP218/WalkingModule/39373/clock:i| Port /IITICUBLAP218/WalkingModule/39373/clock:i active at tcp://192.168.158.201:10085/
[INFO] |yarp.os.Network| Success: port-to-port persistent connection added.
[INFO] |yarp.os.Time| Waiting for clock server to start broadcasting data ...
[INFO] |yarp.os.impl.PortCoreInputUnit|/IITICUBLAP218/WalkingModule/39373/clock:i| Receiving input from /clock to /IITICUBLAP218/WalkingModule/39373/clock:i using tcp
[ERROR] |yarp.os.Property| cannot read from dcm_walking_with_joypad.ini
[ERROR] [getiDynTreeVectorFixSizeFromSearchable] Missing field  goal_port_scaling
[ERROR] [WalkingModule::configure] Failed while reading goal_port_scaling.
[INFO] |yarp.os.RFModule| RFModule failed to open.
[WARNING] |yarp.os.NetworkClock| Destroying network clock
[INFO] |yarp.os.Network| Success: port-to-port persistent connection added.
[INFO] |yarp.os.impl.PortCoreInputUnit|/IITICUBLAP218/WalkingModule/39373/clock:i| Removing input from /clock to /IITICUBLAP218/WalkingModule/39373/clock:i

I don't know if this is related to some environment dependencies or not. @carloscp3009 have you encountered something similar in your tests?

@S-Dafarra
Copy link
Collaborator

[ERROR] |yarp.os.Property| cannot read from dcm_walking_with_joypad.ini

This is the error. What is the content of your YARP_ROBOT_NAME env variable?

@carloscp3009
Copy link
Contributor

@xela-95 Unfortunately, I didnt get this error, but what I understand is that the goal_port_scaling variable is missing inside of dcm_walking_with_joypad.ini. I found this file in /robotology-superbuild/build/install/share/ICUBcontrib/robots/ergoCubGazeboV1/ and indeed it contains the mentioned field, as an starting point you could double check that it exists within your .ini file..

# Scales the input coming from the goal port
goal_port_scaling                   (0.5, 1.0, 0.5)

@xela-95
Copy link
Member Author

xela-95 commented Jan 29, 2024

[ERROR] |yarp.os.Property| cannot read from dcm_walking_with_joypad.ini

This is the error. What is the content of your YARP_ROBOT_NAME env variable?

the value is ergoCubGazeboV1 that I have set in every terminal used for the tutorial

@S-Dafarra
Copy link
Collaborator

[ERROR] |yarp.os.Property| cannot read from dcm_walking_with_joypad.ini

This is the error. What is the content of your YARP_ROBOT_NAME env variable?

the value is ergoCubGazeboV1 that I have set in every terminal used for the tutorial

How did you install walking-controllers? In which OS are you?

@xela-95
Copy link
Member Author

xela-95 commented Jan 29, 2024

The problem was given by the fact that when configuring the walking-controllers repo, the variable CMAKE_INSTALL_PREFIX has to be modified to point to the mamba environment in use (in order to avoid installing in /usr/local that requires sudo).
In my case I set those variable to /home/acroci/mambaforge/envs/walking. Then doing:

make 
make install

worked fine.

Then I was able to run step 6 and 7. Unfortunately, in step 7 when I've given the command startWalking the rpc port answers Response: [ok] but from the Walking module terminal I get a series of the following error:

[2024-01-29 18:23:54.118] [thread: 55267] [blf] [error] [VectorsCollectionServer::setData] The data collection is not valid. Please call prepareData before calling this function.

Also from the gazebo logs I continue to get the following logs:

[ERROR] |yarp.device.multipleanalogsensorsclient| No data received in the last 0.022016 seconds, timeout enabled.
[ERROR] |yarp.device.multipleanalogsensorsclient| Sensor of type ThreeAxisLinearAccelerometers with index 0 has non-MAS_OK status.
[ERROR] |yarp.device.multipleanalogsensorsclient| Sensor of type ThreeAxisGyroscopes with index 0 has non-MAS_OK status.
[ERROR] |yarp.device.multipleanalogsensorsclient| No data received in the last 0.022182 seconds, timeout enabled.
[ERROR] |yarp.device.multipleanalogsensorsclient| Sensor of type SixAxisForceTorqueSensors with index 0 has non-MAS_OK status.
[ERROR] |yarp.device.multipleanalogsensorsclient| Sensor of type SixAxisForceTorqueSensors with index 2 has non-MAS_OK status.
[ERROR] |yarp.device.multipleanalogsensorsclient| Sensor of type SixAxisForceTorqueSensors with index 1 has non-MAS_OK status.

@xela-95
Copy link
Member Author

xela-95 commented Jan 29, 2024

[ERROR] |yarp.os.Property| cannot read from dcm_walking_with_joypad.ini

This is the error. What is the content of your YARP_ROBOT_NAME env variable?

the value is ergoCubGazeboV1 that I have set in every terminal used for the tutorial

How did you install walking-controllers? In which OS are you?

I followed the https://github.com/robotology/walking-controllers#hammer-build-the-suite guide and I'm on Ubuntu 22.04

@S-Dafarra
Copy link
Collaborator

The problem was given by the fact that when configuring the walking-controllers repo, the variable CMAKE_INSTALL_PREFIX has to be modified to point to the mamba environment in use (in order to avoid installing in /usr/local that requires sudo).
In my case I set those variable to /home/acroci/mambaforge/envs/walking. Then doing:

You need to make sure that the YARP_DATA_DIRS variable is properly set. See the end of Build the suite.

Then I was able to run step 6 and 7. Unfortunately, in step 7 when I've given the command startWalking the rpc port answers Response: [ok] but from the Walking module terminal I get a series of the following error:

[2024-01-29 18:23:54.118] [thread: 55267] [blf] [error] [VectorsCollectionServer::setData] The data collection is not valid. Please call prepareData before calling this function.

Sorry for that, it will be fixed in #162

@S-Dafarra
Copy link
Collaborator

You can try to set this

to 0

@traversaro
Copy link
Member

The problem was given by the fact that when configuring the walking-controllers repo, the variable CMAKE_INSTALL_PREFIX has to be modified to point to the mamba environment in use (in order to avoid installing in /usr/local that requires sudo).
In my case I set those variable to /home/acroci/mambaforge/envs/walking. Then doing:

You need to make sure that the YARP_DATA_DIRS variable is properly set. See the end of Build the suite.

A bit like installing inside an existing robotology-superbuild, installing in the $CONDA_PREFIX in which yarp is installed in theory PATH and YARP_DATA_DIRS should already have the correct values.

@S-Dafarra
Copy link
Collaborator

A bit like installing inside an existing robotology-superbuild, installing in the $CONDA_PREFIX in which yarp is installed in theory PATH and YARP_DATA_DIRS should already have the correct values.

Ah interesting. I did not know about this! I expected it for the PATH but nor for YARP_DATA_DIRS. I noticed this is done in https://github.com/robotology/robotology-superbuild/blob/fcb2ce1f0e4136bcb47cdfbf18a6546d4d738d8c/conda/multisheller/icub-contrib-common_activate.msh#L4

BTW, I noticed a bug in the documentation of the walking. See #166

@xela-95
Copy link
Member Author

xela-95 commented Jan 30, 2024

Thank for the support!! Now I was able to make it work :)

I set the dump_data configuration variable to 0, and by providing in step 7 the setGoal (1.0, 0.0, 0.0) (with three values instead of two) the robot walked as expected. No need to set up the environment variables defined in the last step of https://github.com/robotology/walking-controllers#hammer-build-the-suite; if using conda, just setting the CMAKE_INSTALL_PREFIX equal to $CONDA_PREFIX is enough.

If you want I can write some instructions on how to run the walking controller tutorial :)

@S-Dafarra
Copy link
Collaborator

by providing in step 7 the setGoal (1.0, 0.0, 0.0) (with three values instead of two)

See #166

If you want I can write some instructions on how to run the walking controller tutorial :)

Sure! Feel free to open a PR!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants