Issue with rosidl_typesupport in pixi
#1635
Labels
🐞 bug
Something isn't working
Comments
|
Maybe need a little bit more information here. Where is the ros-humble conda package coming from in this case? This may be more specifically a RoboStack issue: https://github.com/RoboStack as they are the only producer of conda binary packages in the ecosystem. I have had success building all of ROS 2 from source via conda, so I'm wondering if it's something specific to the way that it is packaged. |
|
Does the following help? As you say, I specify the The relevant parts of my The output of |
|
Pinging @wolfv and @traversaro in hopes of some expertise 😃 |
|
Thanks for the detailed report. I guess there is some package that is generating non-relocatable files, and conda/pixi binary relocation is not working as expected, either due to a problem in boa/conda-build when the package is generated, or on conda/pixi side when the package is installed. I will try to replicate locally to provide more insight. |
I tried to replicate the error (without the docker layer to avoid the exposed surface) as in the following: where fun.sh contains: and the command without any runtime error, Probably there is something in the docker image that is causing the error to appear, could you try to make a more minimal reproducible example? |
|
Hi @traversaro - apologies about the messiness of our setup scripts, and thank you for still investigating the issue. We don't believe the issue is with Minimum ExampleWe've set up a minimum example in the following repo that might be helpful (commit hash Tl;dr: Running our example produces the error This is not exactly the same as the originally-reported error, but might still provide insight. The README on the In this minimum working example, we define 3 packages:
We reproduce in Docker. You can either choose to repro by mounting the repo root or by adding the Either way, within the container, run This will raise the error Upon running Further, by running In particular, we see that it tries to use the By tab completing, we find that this directory contains the following files: So, the Minimum Example Without PixiWe now run the same example but without using pixi. When we do this, there is no error! We install all of the required dependencies via pre-built ROS binaries in the docker container. In particular, we only install the following 4 packages: Similarly, we provide both a mounted and non-mounted option for repro. Within the container, run This will produce periodic output like this: So, it seems to me either the issue is with Confirming the Full Example in DockerWe also confirm that pulling our original repo into a Docker container and running To run the container: Within the container, run the following. The docker compose file doesn't use the nvidia runtime to minimize shared info between the local system and the container - it should still reproduce the error. The nodes cannot completely launch without error, since the setup also cannot initialize GLFW right now, but it will still raise the following error: |
SolutionUpdate: based on the minimal example with After activating the environment, I simply do Difficulties Automatically Setting
|
|
Thanks a lot for the detailed follow up! It is a bit late currently in Europe, I will check it tomorrow. |
|
No worries - your attention is much appreciated! |
|
Thanks a lot for the mwe example, now everything is much more clear. I think the problem is that you are mixing apt's compilers with conda-forge's tools (like cmake) and libraries. By doing that, your executables are not really aware that should look for package manager installed libraries in |
|
I wonder if we should clarify this in some documentation. On the robostack side the need to install |
|
Thanks, this resolved our issues completely and makes the workaround obsolete. Yes, I would say that this should be 100% clarified on the pixi side. Actually, I started using pixi when I was looking for a cleaner way to comanage pypi dependencies with conda deps (for example, cuda). The fact that it was also compatible with robostack was something I noticed afterwards. Therefore, I wasn't familiar with all the robostack documentation that you linked above. Stating it somewhere up front on the pixi docs would have been very helpful. |
|
Our ROS2 tutorial describes it when you build a Thanks @traversaro for the help as always! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Checks
I have checked that this issue has not already been reported.
I have confirmed this bug exists on the latest version of pixi, using
pixi --version.Reproducible example
Tl;dr: Our issue arises when trying to boot up a ROS stack in a pixi shell. When using pixi, rosidl type support packages are not found. However, when we manually install ROS pre-compiled binaries in a Docker container without using pixi, the packages are found and our stack boots up correctly.
We have not found an easily-reproducible minimal example. The issue can be reproduced in the following debugging branch of our project repo with the commit hash
46f503cf2ba7068b2b576e5540eb3ab17cea7f10: https://github.com/Caltech-AMBER/obelisk/tree/debug-docker-rosidl.Assuming you already have required system deps and Docker, run our setup script with the following flags in the root of the cloned repo on the
debug-docker-rosidlbranch:The only thing this does is set an environment variable called
OBELISK_ROOTto the directory where this repository has been cloned and creates a.envfile containing other environment variables useful for dockerizing our dev setup. We run Docker for isolation and run pixi inside of it. To build and enter the container, runThen, to enter the
devenvironment, runWe build some custom messages through some pixi task, then the rest of the ROS2 packages.
Then, we boot up our stack using an alias installed in the Docker container:
This will spawn a simulation, but we see a runtime error in the terminal:
Issue description
Here, we summarize a few things we tested. Each test is independent from each other.
Test 1: Using only Docker without pixi
If instead, the Debug section of the Dockerfile is uncommented and pixi is not installed:
We can successfully boot up the stack with no errors by doing the following.
Then, in the docker container, running the following commands after deleting the
buildandinstalldirectories underobelisk_ws:This should produce the simulation of the dummy robot swinging back and forth with no error messages in the terminal.
Test 2: Not Using Cyclone DDS
We have tried not using Cyclone for our RMW by commenting out the following line in the
pixi.toml:We confirm that the rmw implementation is the default by running
and
which shows that it is
rmw_fastrtps_cpp. When running the same commands as described in the section on reproducing the issue, we get a slightly different error:Test 3: Various Changes to CMakeLists.txt Files
We have determined that the error is introduced by a custom ROS message we define, called
MujocoImage.msgunder theobelisk_sensor_msgspackage located in theobelisk_wsdirectory. When we comment it out from theCMakeLists.txtand rebuild/rerun, the stack runs correctly without error:We have tried numerous other changes noted in related issues online, such as specifying the
LIBRARY_NAME(see: ros2/rosidl#441):This failed.
We have tried downgrading to python 3.10.12 in the
pixi.tomlas per this issue: ros2/examples#303 without success.We have tried to install Cyclone locally (in the docker container) while also running pixi, just in case this issue would have been relevant: ros2/rmw_fastrtps#541 without success.
Other Observations
We noticed that it's looking for
rosidl_typesupportin/opt/conda/..., which we don't have in the container:It also tries to look there for a
.sofile:However, we can find this file successfully in the directory
$OBELISK_ROOT/obelisk_ws/install/obelisk_sensor_msgs/libThis suggests that we may be able to configure something slightly different such that these files are found.
Expected behavior
Our ROS stack should boot up without issue.
The text was updated successfully, but these errors were encountered: