In working with the integration of Micropython to MicroROS I ran into an issue where if a new type needed to be supported in Python that it would require c code to support the message and a recompile of the device’s binary image.
I wanted to make it so that any existing .msg or a completely new .msg could be supported just by adding the .msg file to Python by uploading the .msg files to the storage area in the device space.
Here is a POC of this .msg compiler along with a pre-compiled binary and example output.
This is a C/C++ project that will be integrated with Micropython code but is compiled as a standalone Linux command line app for ease of debugging.
I wanted to see if any of the ROS IDL experts could comment on my approach and to make sure I am not reinventing the wheel.
If you wanted to test this do the following:
In the project root dir execute.
buildNode.sh
startNode.sh
to create the docker image
then connect to the running docker image
cd /opt/rosbots-rtidl/resg
sh run.sh
If you are on a Linux host, you can also just cd to the test directory and run the same command
Make sure to remove the contents of the Output dir to see new files build.
You can use any other ROS type although the current parser does not support constant or array types.
Interesting stuff @gentijo. I do not have any solutions but I have also thought about this problem with respect to supporting arbitary msg files on the web platform (I am working on getting rclpy working inside of Pyodide).
I think we have slightly different problems though since for MicroROS, I guess dynamic linking is entirely out of the question
I was actually wondering how complicated the compiled msg interfaces were and whether it would be possible to generate them by just adding/removing the appropriate symbols from a template shared object…
Hi @allsey87 ,
Thank you for engaging the conversation
By dynamic linking are you referring to overlays ?
That is an interesting concept, besides supporting ROS Types, you could also do that with the ESP32 modules because the Bluetooth stack consumes a ton of precious iRAM and it would be nice not to have that module loaded if not used. I suspect getting dynamic linking working is more than a compiler option flag Here are some links talking about overlay loading on FreeRTOS.
For the next step, I will port the code to Python and configure it to work as a plugin for Thonny or RShell. For Thonny it could be a dropdown where you pick the types you want supported, it will run the compiler and upload the artifacts to the Micropython device. I also plan to have the code pull .msg files via the GithubAPI or plain HTTP access, so that the python programmer does not have to know how to install the ROS Platform and Thonny along with RShell/Visual Studio code, runs on many platforms.
This approach might be useful for your project with Pyodide. The python version could also run on the MiccroROS device also and would only need to be run in iterative mode, to create the type support, after that the device could be restarted and that code is just taking up space on the SD Card
The compiler I put together in the PoC code is template based so it could produce both the Python artifacts it could also write the C code for a custom type agent.
The compiler knows how to traverse a deep file structure so it could do whole directory scan and build out structure for every type.
TLDR;
For background, my project that has MicroPython integrated into MicroROS (without type support) is here GitHub - gentijo/RosBots and my initial motivation was to build a battle bots style competition that my 11 yo son could enjoy and provide me with a complete project idea to learn ROS.
Some guidelines I have been following to properly fit the audience (Middle / High school kids and their teachers)
least restrictive environment, it should be able to load and go, similar to the MicroBit platform
it should be able to run standalone, not requiring a ROS Agent
be able to also participate in a full ROS environment
Support Google Blockley (Python or JS), which is Scratch like and is becoming a popular platform.
With that said, I could see the following alternative.
Write the python in the simulator, then once you feel that the model is complete, perform a MicroROS compile and perform an OTA update. Downsides, it’s way more complicate that I feel that the audience would accept. Upsides, it could take advantage of Mojo 🔥: Programming language for all of AI to be more performance focused.
So by dynamic linking, I just mean adding symbols at runtime using dlopen, dlsym etc. I will have to double check, but I am under the impression that overlays are a Colcon build system concept and that under the hood, at least on Unix like environments, ROS is just opening an share object (SO file) and loading the symbols from it in order to support different message types. I do not have too much knowledge on how MicroROS works, but I would assume that everything has to be statically linked at compile time, right?
I had a quick look at the FreeRTOS thread and now I see what you meant by overlays. I have never played with this sort of thing before and with WebAssembly supporting up to 4 GB of memory, it is not of much concern for my project.
The dynamic loading / overlays was a useful thought exercise and I think it would have benefit beyond dynamic type support, but the devil is in the details and would require a huge amount of refactoring.
@allsey87 I am going to work on refactoring the C version to python to position the module to be a Thonny plugin as well as running on the device under Micropython. LMK if this sounds interesting for your Pyodide project.
Best of luck with your project @gentijo! I am interested in what you end up doing regarding msg support inside of MicroPython. However, I think beyond our approaches, there will be little that we can share since I am working with the non-micro varieties of ROS and Python (and targeting quite a different platform web vs. microcontrollers).
Here are some links talking about overlay loading on FreeRTOS.