My plan was to make it work on QEMU and other Zephyr supported boards before announcement but couldn’t finished everything yet. But I believe it does show where I’m heading to. It currently does finish building for QEMU ARM Cortex M3 and Native Posix arches, but not yet tested at all (literally).
The things I know I haven’t done are:
No transport from libmicroros is ported yet.
Dependency checks are not complete.
IDL generations are ad-hoc.
Some compiler warnings are not yet removed.
No execution test is done.
My goals for this port are:
Pure Zephyr / West modules.
Reuse as much Micro ROS fix as possible.
Reuse as much CMake code from packages as possible.
Upstream fixes.
Colcon and Ament free.
Colcon and Ament are great tools. I use every day. But the reasons not to use Colcon and Ament for this port are that
The Zephyr build system, including all modules, is pure CMake. We don’t support any other build system. Thus, we don’t need a universal build tool.
The Zephyr build system is one large CMake build unit. We don’t call CMake and Ninja on each packages / modules. Rather, West, Zephyr’s meta-tool, collects and integrates all CMakeLists from modules and build them in one go. Thus, we don’t need Ament’s inter-package resource registration capability. (some utility functions in Ament are nice to have, though.)
Because of limited resources, we won’t be supporting every other packages in ROS ecosystem. No one will run RViz or Gazebo on it. Thus, package dependencies are relatively simpler than, say, ROS on Ubuntu.
west update fetches repositories specified by manifests. No need to fetch repositories behind the scene while building.
An unexpected bonus is that it seems to build much faster than the original, even though it’s also building Picolibc along the way. But YMMV.
If anyone is interested in, I’d love to talk about the direction I’m taking with this, and also about requirements from other RTOSes and/or the way to push micro-ROS related fixes to the upstream in next week at ROSCon 2022. I haven’t registered or reserved any hotel yet. So, if any one is interested in, please let me know.
I found it very useful to integrate the whole micro-ROS codebase with the Zephyr build system by modifying the packages, this was an option that we at micro-ROS discarded at the beginning due to the maintainability across multiple build systems. In any case, having this work done by an external contributor is awesome. Also, getting rid of colcon is an interesting idea when dealing with embedded.
Some ideas:
Have you thought about having your packet “forks” stored as a folder with a bunch of patches in the main repo? This way it will be just a matter of downloading the mainlines and applying a patch instead of maintaining a whole fork.
When this is ready and tested, feel free to ask us to migrate it to the micro-ROS organization. Maybe we can evaluate which solution shall be the micro-ROS official way to integrate with Zephyr depending on the use case. We can provide you with owner access.
Thanks for your message! Glade to see someone is interested in.
I don’t have intention to modifying the source code. I know there are some modifications in the source code in the repos but I’d like to upstream the changes if possible.
My intention is to reuse the whole source code but integrate to Zephyr build system, by having /zerphyr directory, which contains CMakeLists.txt, Kconfig and module.yml. These files only have instructions to build the source code just like Colcon and other ROS’s build tools do. But much more closely integrated way with Zephyr’s build system. i.e. Select features each user wants via Kconfig, update source code with west update, or build it with west build. I feel that’s much easier for Zephyr users. That might be because I’m not really ROS guy but much more familiar with Linux and Zephyr eco-system. So YMMV for sure.
Have you thought about having your packet “forks” stored as a folder
Having patches in a folder doesn’t really work well with the workflow that I’m intended to provide and the way that Zephyr users are used to, west update.
It’d be super cool if you could host a Zephyr dedicated branch for each repo, say zephyr-humble as I have, under micro-ROS org. That way, users feels more official than accessing my personal repos. But I agree that it’s going to be higher maintenance cost for developers if they have to maintain multiple build systems across RTOSes. OTOH, I believe it’s much lower cost for users, especially if you are used to the build system from an eco-system.
this was an option that we at micro-ROS discarded at the beginning
Do you happen to have a log or a minutes for the discussion I can read? What channel do you guys discuss?
ps. Currently the demo is broken by accident. And i’m a bit too busy to fix it. west update && west build doesn’t work ATM.
We usually talk about this in GitHub issues or the micro-ROS Slack.
You can find the invitation access in micro.ros.org or write me a DM with your mail address.