I already ran a microRTPS agent and client with SITL and it worked flawlessly.
But now I want to try it with the real hardware i.e. a pixhawk4.
make px4_fmu-v5_rtps upload and then try to run
micrortps_client start in the nsh but as soon as I press enter I get this hardfault.
The section in the documentation about how to set this up with real hardware is currently wip but maybe someone here already did it.
I saw the other post on this forum and followed it but I still get the hardfault.
I found an issue about this.
A workaround is to disable this parameter
or switch to the last stable version, at the time of writing this reply it is v1.13.0.
Hi @florian.pix, I am also unable to start the
micrortps_client per my previous post.
After accessing the pixhawk’s
mavlink_shell.py from my companion computer, I get the following error when trying to start the
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
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.
I can confirm this worked for me. Thanks very much for the help!