ROSMicroPy

Hi All,

I have been working on a Project called ROSMicroPy, an integration of MicroROS and Micropython supporting the ESP32 platform. ROSMicroPy

It’s rounding the corner of being done and I am looking for feedback.

  • Are the Docs clear
  • SDK implementation
  • If someone from eProsima can take a look at my Type Support system and let me know if I am painting myself into a corner, it would be greatly appreciated. Here is a write up on how it works ROSMicroPy Type Support Integration | ROSMicroPy

Suggestions and PR’s are welcome

SDK Docs: Python class: (ROSMicroPy) | ROSMicroPy

How to get started Welcome to ROSMicroPy Python Development | ROSMicroPy

What works:

  • You can register data types
  • Subscribe to events
  • Publish messages

What needs work:

  • You need to recompile to change the SSID/Password, I need to change the locus of control from MicroROS to Micropython for Wifi managment as the MicroROS network interface does not work with MicroPython’s WEBRepl
  • Type support probably has bugs, i need to expand on my testing. Type Support does not support sequences yet.
  • Server support
  • Documentation, Documentation, Documentation

Thank you
John

8 Likes

This is great! I have not tried it yet on a device.

My initial suggestion would be to use Sphinx for the documentation, to make it easier to navigate.

Have you looked into running the ESP32 without the necessary agent on the remote machine, i.e., with embeddedRTPS , linked from GitHub - micro-ROS/micro_ros_espidf_component: micro-ROS ESP32 IDF component and sample code ?

Hi @nuno, thank you for responding. re:embeddedRTPS, I am sure it can be. My challenge is to understand the type support stack better, my education came about by attaching my Jtag debugger and setting a breakpoint rmw_publish, similar on the receive side. Then single step away.

I think, at the low level, I might have tied myself to the eProsima code, that’s why I was asking for advice about my Type Support code. My Type Support code is a bit of a side car along with the installed Type Support. The core of my code is generic, i.e. my serialize / deserialize uses what I am calling an instruction list to drive both. I went in this direction to allow for run time type definition natively in Python.

This posed a bit of a challenge as the MicroROS type support interface requires a structure that contains function pointers to the low level functions and my code uses the same core methods for all types.

I solved it by creating this big chunky macro that creates stub functions so serialize_slot1 → serialize, where serialize_slot one calls the core serialize function passing a 1 for the slot_id, the slot_id points to a run time defined slot with all the necessary type metadata.

So Micropython has it’s own (mostly) full implementation of a ROS Type system, but that Type System, is not a full replacement and depends on the installed Type System installed with MicroROS.

My intention in making this announcement was simply to let people use it and provide feedback, like yours, so I can get out of my bubble and make the code more usable for all.

Here are some code references.

How the Geometry:Twist type is defined in Microipython

How that type is registered and used to register a type definition and use that for subscribing to an event. ROSMicroPy/python_example_code/TwistedSubscriber.py at f1319054c0f0a0732b1b18593cd2df2a47f85e97 · gentijo/ROSMicroPy · GitHub

My big chunky macro

How that macro is used, it’s important to realize that the macro both defines code that is rendered at compile time, and runtime code that runs when init() is called. ROSMicroPy/extra_packages/ROSMicroPy/mp_uros_type_support/mp_uros_type_support.c at f1319054c0f0a0732b1b18593cd2df2a47f85e97 · gentijo/ROSMicroPy · GitHub

Thank you for the reference, I will look into it.