Do you have any components that you wish would interface over the shiny UAVCAN protocol? That way you can have legacy hardware that experiences the benefits of UAVCAN. Think if you could experience the benefits of software update over UAVCAN on legacy hardware – pretty neat!
I’ve been working on a USART to UAVCAN bridge (with the help of the ever patient @bugobliterator!) and assortment of USART (not happy with the usb port quality on eBay boards – I had a usb port die!), PixRacer, Zubax Babel and of course my trusty soldering iron.
So here’s how it works. In the picture above, from the bottom up we have the USART adapter, a PixRacer and finally a Zubax Babel. The USART sends text via mavproxy.py, and the frames enter USART2 on the PixRacer. The PixRacer is running OpenMotorDrive framework with basic UAVCAN functionality. Currently the messages are sent as debug messages, but this is slated to change. The PixRacer sends a UAVCAN frame when it receives data as seen here:
And here it is in action: as you can see on the right where I have a terminal window open, I have sent the character ‘a’ twice. On the left in the selected row in the Bus monitor of the UAVCAN gui tool you can see that the Babel has received the debug message with the character I sent.
I’m currently working on getting the messages to be sent as @MagicRuB’s tunnel packets (so that serial messages can be sent over UAVCAN). These tunnel packets were introduced to send Mavlink messages over UAVCAN but I’m using them for my own purposes. As I understand, the body of the tunnel packet is simply the Mavlink packet (in my case the serial packet) and the packet is serialized through the magic of UAVCAN’s data serialization routines.
The code is written, just being debugged at this point. Fingers crossed it will go smoothly! Next step will be parsing actual sensor data rather than arbitrary serial messages.