ROSMicroPy support for Raspberry Pi Pico

[Zeraphu]

Hi everyone,

I'm curious about the potential for expanding support to include the Raspberry Pi Pico as well as the Raspberry Pi 4 and 5. These platforms are quite popular and versatile, and I think they would be great additions to the ROSMicroPy project.

A few questions and ideas:

1. What are your thoughts on the feasibility and potential challenges of supporting the Raspberry Pi Pico and Raspberry Pi 4/5? What are the main hurdles we would need to overcome?
2. Do you have any initial ideas or a rough roadmap for implementing this support? Which areas would require the most focus (e.g., transport layers, middleware integration, hardware abstraction)?
3. I’m very interested in contributing to this effort. Could you provide some guidance on how I can get started? Are there specific tasks or components that would be helpful for a contributor to focus on?

Looking forward to hearing your thoughts and hopefully contributing to expanding ROSMicroPy's platform support.

Cheers!

[gentijo]

Hi @Zeraphu ,

Thank you for reaching out.

yes. I fully agree re:rpi/pico. Recently i refactored the code to use micropython build style vs the microros build style and included microros as an espidf component. I did this mainly to resolve some cmake parameter permission issues but now that this is completed, we should be able to utilize the multiple platform build patterns that are already in place with Micropython.

The biggest hurdle to move to any other architecture is in how to deal with all the espidf components that the project depends on. From a C/C++ perspective very little dependency on the espidf, but from a cmake macro perspective, it heavily depends on the idf macros. It may make sense to convert some of the idf components and port their cmake process to the Micropython c user module format, I am open to suggestions here.

As for roadmap, once I had the Core libraries working, I decided to go for breadth vs depth where the idea was to modularize the code and create build profiles to support multiple device, currently there is the core product, a Camera that streams CompressedImages and an LCD Controller that allows the end user create a custom controller in a switch like format. This should provide enough functionality to create a full bot. The next two build profiles will be an IMU/GPS and one of those $15 lidar sensors.

To add depth, the project could use.

• The Core Module support for sequences in the TypeSupport.
• Server mode support
• Naming conventions of files and methods need to be normalized
• Create build recipes, that instruct the user on how to build a complete bot.
• docs, docs, docs and comments, comments, comments.
• probably many other items, I need to start creating issues to track outstanding items.

Problems I could use help with.
The Camera module creates a Publisher that sends CompressedImage messages. There seems to be an issue with the Agent where messages > 2048 bytes are lost by the Agent. From wireshark, I can see packets received by the Agent but they are never retransmitted to the subscribing node.

From there I tried to set up a Server that would respond to requests for images, and that is when I realized the need for Server support is needed.

Using MicroROS as an espidf component has challenges to support IDL code generation where the ament Cmake macros are not available for another espidf component which makes it hard to support custom types.

There are a bunch of places you can get involved based on your interests, have you tried to compile the core module yet ?

-John