Can't create subscriber on ESP32-C3

examples/int32_sub_pub と ping_pong から始め、次に monitor の backtrace に示されている subscription のセットアップを rmw_wait まで追跡します。int32_publisher と比較し、subscriber_bug.txt を調査します。提供された Dockerfile と ESP32-C3 の手順で再現します。subscriber の例が panic なしで実行され、期待される 2 つの topic が agent 経由で確認できれば完了です。

Problem description

I have recently started to experiment with micro-ROS. While the examples involving just publishers such as int32_publisher are running fine, if I run any example involving a subscriber such as int32_sub_pub or ping_pong according to the official documentation using the provided Dockerfile this results in a stack dump.

• Hardware description: Seeed Studio Xiao ESP32C3/ESP32-C3-MINI-1
• RTOS: FreeRTOS
• Installation type: micro_ros_espidf_component
• Version or commit hash: humble (27158f2369bd7bd02ce3cda61a785bf32ce10883)

Steps to reproduce the issue

In order to replicate this flash the ESP32-C3 board with one of the examples involving a subscriber (in the following I will make use of int32_sub_pub). In my case I open it in the container with the provided Dockerfile in interactive mode:

$ export LC_ALL=C # Override locale settings
$ . $IDF_PATH/export.sh
$ cd examples/int32_sub_pub
$ idf.py set-target esp32c3
$ idf.py menuconfig
# Set micro-ROS agent Settings ->
#   WiFi configuration ->
#     WiFI SSID (test_hotspot)
#     WiFI Password (test_password)
#   micro-ROS Agent IP (10.42.0.1)
$ idf.py build
$ sudo chmod o+rw /dev/ttyACM0 # Allow to write to device file
$ idf.py flash

connect both micro-controller and computer to the same hotspot, in my case a self-hosted hotspot, then run the micro-ROS agent on the computer (10.42.0.1)

$ docker run -it --rm --net=host microros/micro-ros-agent:humble udp4 --port 8888 -v6

and finally monitor the ESP32-C3 with:

$ idf.py monitor

Expected behavior

The ESP-C3 should publish its messages to the micro-ROS agent on the int32_publisher topic and wait for messages on the int32_subscriber topic. I should be able to see both topics on the micro-ROS agent side.

Actual behavior

The ESP32-C3 runs into a stack dump and reboots (For a full output see subscriber_bug.txt):

I (1599) main_task: Returned from app_main()
Guru Meditation Error: Core  0 panic'ed (Illegal instruction). Exception was unhandled.

Stack dump detected
Core  0 register dump:
MEPC    : 0x42015a2e  RA      : 0x4201596c  SP      : 0x3fcad780  GP      : 0x3fc91400  
0x42015a2e: rmw_wait at ??:?

0x4201596c: rmw_wait at ??:?

TP      : 0x3fc901b8  T0      : 0x4005890e  T1      : 0x0000000c  T2      : 0x00068081  
S0/FP   : 0x3fc94350  S1      : 0x3fcadafc  A0      : 0x3fca9a58  A1      : 0x00001000  
A2      : 0x00001000  A3      : 0x00000001  A4      : 0xffffffff  A5      : 0x00000001  
A6      : 0x00000000  A7      : 0xf4240000  S2      : 0x3fcadaf0  S3      : 0x00000064  
S4      : 0x3fcadb08  S5      : 0x3fcadb14  S6      : 0x05f5e100  S7      : 0x00000000  
S8      : 0x00000000  S9      : 0x3fcad8c4  S10     : 0x3fcadaec  S11     : 0x00000000  
T3      : 0x00000975  T4      : 0x00000000  T5      : 0x4200a2c8  T6      : 0x4200a2d0  
0x4200a2c8: __default_deallocate at allocator.c:?

0x4200a2d0: __default_allocate at allocator.c:?

MSTATUS : 0x00001881  MTVEC   : 0x40380001  MCAUSE  : 0x00000002  MTVAL   : 0xd009f7d3  
0x40380001: _vector_table at ??:?

MHARTID : 0x00000000  

Backtrace:

0x42015a2e in rmw_wait ()
#0  0x42015a2e in rmw_wait ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
ELF file SHA256: dc5c59390d980376
Rebooting...

Additional information

I have tried the following already to no avail, the problem stays the very same:

• Reflash the ESP32 several times
• Try a different ESP32 I had lying around
• Change hotspot
• Switch to ROS 2 Iron instead of Humble
• Remove the publisher, being left with an example with only a subscriber
• Doubled the statically allocated memory to 32000 Bytes for the ROS task in $ idf.py menuconfig under micro-ROS example-app settings/Stack the micro-ROS app (Bytes)
• Added the following options to colcon.meta and proceed with a clean build, cleaning the workspace first with $ idf.py clean-microros:
  • Added -DRMW_UXRCE_ALLOW_DYNAMIC_ALLOCATIONS=ON to microxrcedds_client.cmake-args
  • Increased the number of nodes -DRMW_UXRCE_MAX_NODES, publishers -DRMW_UXRCE_MAX_PUBLISHERS, subscribers -DRMW_UXRCE_MAX_SUBSCRIPTIONS, guard conditions -DRMW_UXRCE_MAX_GUARD_CONDITION under rmw_microxrcedds.cmake-args

If I comment the line that adds the subscription to the executor, e.g. RCCHECK(rclc_executor_add_subscription(&executor, &subscriber, &recv_msg, &subscription_callback, ON_NEW_DATA)); the publisher runs just fine while clearly the subscriber will not work.

Any input is highly appreciated!