Confusing docs & Guide - or maybe still Windows Compatibility issues?

[RichardKroesen]

Cause:
Well, I tried several times to use this template but still got no where. Maybe it's because I am new to ROS2, and instantly get thrown into Pixi which is again a whole other environment, and still work in windows...

Things that are not clear to me

• Jazzy distro is not supported by Pixi yet, like humble is? And therefore we need additional scripts to install it through conda manually?
  Is that what you mean by rattler?
• Are the guides really complete or just copy pastes of each and simplified versions? I have the feeling that this template was created after audio_tools and there were details taken out of it, and never checked if they still make sense without audio_tools.

Taken actions

And here are the things I encountered during these actions, which could help for the guide enhancements:

• I followed but get confused because this template are different for Jazzy: https://pixi.sh/v0.39.4/tutorials/ros2/#community-examples
• Followed teh usage guide, but after couple of times I never got the custom_pkg aka hello_world example working on windows. Everytime each command works fine, only at the last part I get: "custom_pkg not found" which is true since there it is not in the ros2 package list after the installation.

[Hoog-V]

TLDR;
It is inexperience with ROS2 and not understanding the purpose of this repo probably. I guess :)

Well, I tried several times to use this template but still got no where. Maybe it's because I am new to ROS2, and instantly get thrown into Pixi which is again a whole other environment, and still work in windows...

Windows works, have verified it, as long as you build Release it will work (debug won't work, as python_debug is not available in Conda but is hard dependency for ROS node package debug build in Windows). Pixi is nothing but a simple wrapper, which allows you to easily specify which dependencies to add to your virtual conda environment.

@RichardKroesen Seriously, these seem like two questions, but these are like fifteen different questions. So will try to answer them as shortly as possible.

Jazzy distro is not supported by Pixi yet, like humble is? And therefore we need additional scripts to install it through conda manually?

This is not true, it is supported by Pixi. Their documentation is sometimes not completely up to date as they work with a small team of developers which have to upstream like >1000 packages over 3 platforms (your link was also many versions behind on current, yours 0.39.4, current: 0.45.0). But for pixi team, documentation is not the first priority. Anyways on the link you provided it says Humble on official robostack wiki (maintainers of the ROS packages on Conda (and also Pixi, see point below)), they say it is supported. Which is more important then Pixi wiki.

The reason those scripts are included is for packaging using the rattler-build tool, which packages our node using a recipe to be published for conda and to be upstreamed in conda channel. Which we do with our own private channel: https://github.com/CLFML/conda_ros2_jazzy_channel

And also what our workflows does for us, we literally already use Continuous Deployment. So that's what these scripts are for. Normally in ROS-land you would submit these packages in separate repo with their respective build scripts in ROS-build farm. But we do everything ourselves, as the process of using the build-farm and conda-forge build-farm is very slow and bureaucratic. Which would mean also, that our packages have to be a lot more polished, with most bugs out of the package for publishing.

Also a bit, on why it is supported, Pixi is nothing but a fancy wrapper over Conda. Meaning they have done, almost exactly what platformio has done with the GCC compiler and underlying Ninja build-system. They have wrapped it, made it easier to port over multiple platforms. Meaning since that it is basic Conda, you should be able to install and run every conda package (packaged for Windows) out-there.

The only thing I can imagine, could be the fault that it doesn't find the ROS packages of Jazzy is that you have not added the Conda-forge & Robostack channel to your pixi.toml:

channels = ["https://fast.prefix.dev/conda-forge", "https://prefix.dev/robostack-jazzy"]

Want a quick list of packages, use the prefix.dev website (which lists also packages from conda-forge and robostack, use the search bar to search for the package). For example, you can see here that jazzy packages are in the channel. Fyi, ros-jazzy-desktop is a meta-package. Meaning if you specify this package in your pixi.toml almost all ros dependencies needed to run desktop app are installed (including gui tools, like rviz I believe.

Okay next thing, you might want to know is that you can not specify in Pixi to automatically install custom_pkg. Not like this;

[dependencies]
ros-jazzy-custom-pkg = "*"

Why? Because it is not in the Conda-forge, Robostack-jazzy repositories nor the CLFML private repo; https://clfml.github.io/conda_ros2_jazzy_channel/. So Pixi can't find it. This is off-course done on purpose! This is a template package, which should not be upstreamed in any of above channels. You should copy it make your own node (which has a real purpose), with provided workflows/actions and by adding an action to our clfml_conda_channel repo you can easily upstream that package.

Usage Guide in This Repository

Are the guides really complete or just copy pastes of each and simplified versions? I have the feeling that this template was created after audio_tools and there were details taken out of it, and never checked if they still make sense without audio_tools.

Yes, these are mostly copy-pasted. And no of-course they are not complete, these are templates and simplified versions of other packages. Reason for this is that only the common bits are left in and the package specific things are left out. This is a boilerplate template project, meaning it has to be minimalistic.

That's also why the usage guide in this repository is intended for reference when the package has been internally upstreamed. It is not suitable for package development, as it relies on prebuilt binaries generated by the workflows within this repo. During development, those binaries are not available.

You might wonder why the guide is included at all. The reason is that this repository serves as a template, not a starter project. It's designed to be cloned and adapted with minimal changes, allowing downstream nodes to easily provide meaningful guidance for using the library once it's upstreamed internally.

Developing and adapting the code in this repo

If you want to run the code in this package you have two options:

1. Do a manual build
2. Download the conda release package (remove the -win in the name, which is artificially added to circumvent it from becoming a name collision with the linux package) and specify in Pixi to use the local file.

I always recommend option 1 over 2 when there is no package available from our custom private repo (officially called channel). Why? As this is how you would develop these packages.

Manual build

You probably think it is the same as building an CMake app right? Well yes and no, ROS does somethings a bit different. Here are the things that are different:

• ROS2 is a multilanguage toolchain with many modules which couple in to and after the build-proces. So that means that it is crucial to let the other packages know where things like custom_msgs are located.
  • You do this by using many modules in the CMakeLists.txt (so right files such as python bindings for msg files are generated:

    ROS2_Package_Template/CMakeLists.txt

    Lines 11 to 25 in 0f6705b

    	rosidl_generate_interfaces(${PROJECT_NAME}
    	msg/Custom.msg
    	DEPENDENCIES std_msgs
    	)
    	ament_export_dependencies(rosidl_default_runtime)
    	rosidl_get_typesupport_target(cpp_typesupport_target ${PROJECT_NAME} "rosidl_typesupport_cpp")
    	add_executable(custom_node src/custom_node.cpp)
    	ament_target_dependencies(custom_node
    	rclcpp
    	std_msgs
    	)
    	target_link_libraries(custom_node "${cpp_typesupport_target}")

    )
  • And by sourcing the install afterwards (to let ros nodes on system know, where the files are located):

   # Windows
   .\install\setup.ps1
   # Linux
  source install/setup.sh

• For best compatibility while building use Colcon build instead of raw CMake (I use CMake only in vscode to quickly test my node, but the launch terminal used for cmake has to be sourced with pixi environment before running: pixi shell otherwise it won't run in pixi env). For usage with colcon build:

colcon build --cmake-args -DCMAKE_BUILD_TYPE=Release --event-handlers console_direct+

--event-handlers console_direct+ is added to make sure it outputs to terminal the error messages from cmake during build. Which are normally not visible

Why colcon build is preferred over CMake? It installs files already with all needed scripts in the install/ dir in your project. This is way easier to test then with CMake which does not produce any of these scripts. Colcon is also the official build tool for ROS2 packages.

If you want to read more about how to build and run ros2 jazzy packages. Look here. Which just works with the ros-jazzy-desktop package installed, as the native ros libraries and packages are installed in your virtual conda env using Pixi. So same workflow still applies!

What I think the problem is

I think that either you did not build with colcon and source it afterwards. Or either one of the two actions.

Please note, that for every new terminal you launch, you have to manually source the build again in pixi shell .e.g. .\install\setup.ps1. As it is not added to path by default, which would certainly break things if you are developing.

Fyi; That's why we moved to system-wide install for publishing packages internally after being in somewhat acceptable state e.g. lowwi. As that makes it way easier to integrate, no more sourcing required as the packaged versions have the sourcing automatically added to the global source script. Which runs when opening new shell.

Just once again

The steps using Windows powershell:

# Open conda environment with ROS packages installed (pixi.toml in repo should have it all, preconfigured)
pixi shell
# Run the build
colcon build --cmake-args -DCMAKE_BUILD_TYPE=Release --event-handlers console_direct+
# Source the custom_pkg environment
.\install\setup.ps1
# Run
ros2 run custom_pkg custom_node

In other terminal open:

# Open the repo dir and again run pixi shell
pixi shell
# Source the custom_pkg environment
.\install\setup.ps1
# Run rqt_topic to inspect message
ros2 run rqt_topic rqt_topic
# or without gui
ros2 topic echo /hello_world

[RichardKroesen]

Oof, ehm. Yes .\install\setup.bat does the magic :P
Makes sense, at first I tried my machine-wide and therefore got the package not found. Which in hindsight is untrivial offc since the package is added locally in that scope.

Fyi I got ROS2 packages, just got confused by Pixi usage and hoped it made my life easier not harder lol.

Tbh I will just quickly skimmed through your comment. I would advice not to go that deep in depth next time.

Thank you anyway I think I will use it, since I see some relevant info I just couldn't find in the guide :D.

Look I just wanted to point out my confusion, and it's because I am really triggered by guides that are confusing.

The whole point of Pixi would be to make it easier, but just with ROS2 I understand their tutorials document it well. With Pixi I got the feeling they do things for me, and you added custom magic things on top of it (Now I got it, no worries).

Since I can also figure it out myself / do it my way. But I saw the template which is intended to be used (and assumably make my life easier) I had really put in a couple of hours to figure it out based on the guide. And I couldn't, I may not be that script kiddy like you are :P But I am most of the times not retarded either XD

I add documentation since I called this, and prob only untrivial information for me ;D

Anyhow, it was not critique, and I called it by issue and not as an internal conversation since I think others could encounter this as well... Or I am living lonely on the confusion island (not anymore thanks to you), liked the sunny weather there tho!☀😎

[Hoog-V]

The reason I went in depth is that there are a lot of loose puzzle pieces. The more I give, the easier it is to link. Not only for you but also for others reading this Issue. The other reason I went in depth, is that there are a lot of factors which can give the issue you're having, and I not only want to give the solution but also the reasoning why it works the way it does.

Ofcourse I know you're not dumb, sorry if it was borderline offensive. It was absolutely not meant this way. But mansplaining is so easy when going on topics like these, knowing other people can learn from it too.

You know toolchains are not easy. They never will probably. Everytime it is like a whole new ecosystem with it's own pro's and cons. For me it is sometimes also very frustating to see guides not lining up with reality. (Most of the time I don't even read them properly and search for examples, as my attention span does not allow for it).