micrortps setup via voxl_io
ryan_meagher last edited by
I was wondering if anyone has successfully setup a
micrortps_agent micrortps_clientconnection via UART attached to J10 or J11 on the voxl to the flight core. Ideally I would have the
micrortps_agentperforming the read and writes but since these connectors are mapped to the SDSP it doesn't seem possible to do it this way. I was wondering if there was an easy way to setup this bridge in the voxl_io and if someone would point me in the right direction as I haven't found much documentation regarding this.
Does the micrortps agent need to open a standard UART port, such as /dev/ttySx or /dev/ttyUSBx or similar? how hard is it to extend the micrortps client to use libvoxl_io functionality to access the serial port via libvoxl_io instead of standard serial port libraries? You would need to use this header https://gitlab.com/voxl-public/core-libs/libvoxl_io/-/blob/master/lib/include/voxl_io.h and link against libvoxl_io.
If changing micrortps code is not an option, then some sort of bridge could work. I have done similar things before using pseudo terminals (pty/tty pairs). Basically the bridge could be the master and would read/write using ptyXY and micrortps would be the client and read/write using ttyXY. However, i don't think pseudo terminals are available on VOXL.
https://stackoverflow.com/questions/52187/virtual-serial-port-for-linux this discusses the pseudo terminal as well another solution using socat. Now, socat is not available on VOXL either, but if you use docker, it can be installed in a small container using apt-get install socat.
Let me check if we can easily add the socat and pseudo terminals to the VOXL system image..
It seems perhaps the most robust solution (for now) would be extending micrortps to work with libvolx_io serial ports..
@Alex-Kushleyev Thanks for the response! the
micrortps_clientis running in the nuttx shell on the flight core and is autogenerated based on the *.msg files when building the px4 firmware. In order for it to work with a companion computer (according to the px4/ros slack channel) you have to pass one of the tty devices that is setup for telemetry in modalai's rtps.cmake file.
The following command will be run from the mavlink console or the voxl-px4-shell:
micrortps_client start -t UART -d /dev/ttyS6 -b 921600
The following command will be run from a docker image on voxl:
micrortps_agent start -t UART -d /dev/ttyX -b 921600
Due to the fact that the flight core doesn't have wifi, I dont think I can setup a socat connection or pseudo terminal as I am assuming this requires ipv4/ipv6 connectivity on both sides of client/agent.
It looks like the
msg/generate_microRTPS_bridge.pyfile is calling
microRTPS_transport.cppwhich is setting up the read/writes so I will try to change this file to use the voxl_io on both sides.
hi @ryan_meagher , yes it looks like you need to implement a custom version of UART_node class, with init, read, write, and a few other functions, which can be just wrappers for libvoxl_io calls. I think this is the best solution in this case and hopefully does not take too much time. Some options are not available, like poll_ms, flow_control, but i think it should be just fine to not implement those.
Let me know if you have any particular questions regarding using uart with libvoxl_io or anything else.
@Alex-Kushleyev That is the route I was taking and have finished implementing in the
I have a few questions:
@Chad-Sweet said that the libvoxl_io is not supported in a docker environment which is needed in order to build the
micrortps_agentwith ROS2. Is this possible?
voxl_io.hspecifies a buffer length of 128 bytes whereas the
micrortps_transport.huses 1024 byte buffers. Can I pass a buffer larger than 128 to the
@ryan_meagher , see responses..
yes, that is an issue.. libvoxl_io library needs to run on the VOXL host operating system because it calls into some device-specific hardware libraries to talk to the DSP. Hmm. It does seem like some sort of a bridge is needed.. Since microRTPS supports UDP, perhaps the next thing to try is writing a simple app that uses libvoxl_io on the host OS and exposes the data via UDP (read/write)?
I don't actually think this is a limitation (128 bytes), it just has not been tested. I am pretty sure you can send more than 128 bytes at a time and receive as well, as long as you allocate a big enough buffer for receiving (see https://gitlab.com/voxl-public/core-libs/libvoxl_io/-/blob/master/lib/apps/voxl-uart-loopback.c for allocation example)
@Alex-Kushleyev So something utilitzing the
io_rpcsimilar to the
io_rpc_mavparser.cand then exposing it to the
voxl_io_mavparser.cthen using this like how you guys are using it in the
When developing this functionality on the hexagon sDSP are there any special issues or pitfalls I should pay particular attention to?
At first, I would not try changing any code that runs on the DSP - just using the functions already exposed in voxl_io.h. So you would write an application that would get data from UDP and send to the serial port using voxl_uart_write. Then read any data using voxl_uart_read and send it out via UDP. Does that make sense?
@Alex-Kushleyev Thanks for the help, still working on this bridge but have made some progress, able to create io_rpc functions and add some stuff to voxl-vision and am now able to get messages in my docker container with
ros2 launch px4_ros_com <launch_file>