micro-ROS / micro-ROS/micro_ros_arduino
Sending ESP32CAM images on a best-effort basis
- Dominant language
- C
- Stars
- 576
- Forks
- 146
- PR merge metrics
- No merged PRs in 30d
Description
Hello, I managed to write some Arduino code for an ESP32-S3R8 using this library that publishes compressed images to the according ROS topic. However, it only works when using reliable mode, but ideally I would want to use best-effort as a few missed camera frames are not the end of the world for my use case. This not working actually makes sense, when looking into the [documentation](https://docs.vulcanexus.org/en/latest/rst/tutorials/micro/memory_management/memory_management.html#middleware-related-memory):
> When using Best Effort entities, the maximum serialized size of a topic shall fit in `UCLIENT_[XXX]_TRANSPORT_MTU` both for outgoing and incoming data.
> When using Reliable entities, the maximum serialized size of a topic shall fit in `UCLIENT_[XXX]_TRANSPORT_MTU * RMW_UXRCE_STREAM_HISTORY` both for outgoing and incoming data.
So naturally, I increased the value of UCLIENT_CUSTOM_TRANSPORT_MTU to 32768, such that it would fit my camera frames (the default value is 512) and recompiled the library. This hugely increases the memory requirements though, much more than I expected. With RMW_UXRCE_STREAM_HISTORY being 4, I assumed I would need a little less than 32768*4 bytes of memory more, but it seems to be way more than that, making my sketch not even compile and stating that it uses multiple hundreds of kilobytes too much. I also tried this with smaller values, and 16384 is still too large.
So my question is: Can I somehow use best-effort modes without the adjustments to `UCLIENT_CUSTOM_TRANSPORT_MTU`? Or are there other ways I could decrease memory usage, so everything would fit into the ESP32s RAM again?
Contributor guide
Research direction
Start with the linked middleware-related memory documentation and the configuration around UCLIENT_CUSTOM_TRANSPORT_MTU and RMW_UXRCE_STREAM_HISTORY. Determine why the ESP32-S3R8 memory increase exceeds the expected transport and history allocation, and whether best-effort image publishing can work within the reported RAM limits; document the supported configuration or limitation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- arduino
- Domain
- embedded-iot, networking
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100