A workaround is to disable this parameter CONFIG_MODULES_MICRODDS_CLIENT=n
or switch to the last stable version, at the time of writing this reply it is v1.13.0.
After accessing the pixhawk’s nsh> through mavlink_shell.py from my companion computer, I get the following error when trying to start the micrortps_client:
nsh> micrortps_client status
INFO [micrortps_client] Not running
nsh> micrortps_client start -t UART
INFO [micrortps_client] UART transport: device: /dev/ttyACM0; baudradevice reports readiness to read but returned no data (device disconnected or multiple access on port?)
This error is originating from .local/lib/python3.8/site-packages/serial/serialposix.py
This error occurs every time I try to start the micrortps_client - whether through the mavlink shell or QGC console. The Pixhawk disconnects from QGC and plays the error tune. The connection between the Pixhawk 4 and the companion computer (a Raspberry Pi running Ubuntu 20.04) is a usb cable into the side port.
I just saw your posted solution; not sure if it applies here but I will try that and report back.
If you aren’t using the stable version it might be that mavlink (QGC also uses mavlink) interferes with the microRTPS. You can check this by using the FMU debug port with a FTDI cable and using the nsh shell directly instead. But in general I would suggest using v1.13.0.