Yakut monitor with a Babel

Hello everyone ! I am pretty new to UAVCAN and more generally to any topic related to communication/networking.
So I have made the acquisition of a Babel in order to monitor my node network through uavcan_gui_tool, which worked perfectly fine.

Now it would be great for me if I could monitor my network through the Yakut CLI tool.
So far I have tested some stuff but none of them lead to a success:

  • I have changed the environment variable : export UAVCAN__CAN__IFACE=‘slcan:/dev/serial/by-id/usb-Zubax_Robotics_Zubax_Babel_1F003000185130465638362000000000-if00’
    Which led to this error :
File "/home/louis-nicolas/.local/lib/python3.8/site-packages/pyuavcan/transport/can/media/pythoncan/_pythoncan.py", line 371, in _construct_slcan
    raise InvalidMediaConfigurationError(f"Interface does not support CAN FD: {parameters.interface_name}")
pyuavcan.transport._error.InvalidMediaConfigurationError: Interface does not support CAN FD: slcan

I think I am pretty close as the error message is pretty explicit.
Then I have tried also to change the env variable related to the MTU and the bitrate ( I have put the same value than one on the git readme of yakut in monitor section) as they are related to CAN/CAN FD. The error message changed to :

File "/usr/local/lib/python3.8/dist-packages/serial/serialposix.py", line 325, in open
    raise SerialException(msg.errno, "could not open port {}: {}".format(self._port, msg))
serial.serialutil.SerialException: [Errno 2] could not open port slcan0: [Errno 2] No such file or directory: 'slcan0'

Any help would be greatly appreciated. Thank you all for reading me :slight_smile:

On your first attempt you stumbled upon this issue, which is known and already fixed in the development branch but not yet released:

Although you would also need to export UAVCAN__CAN__MTU=8 because it defaults to 64 (CAN FD mode).

Your second attempt is failing because you are trying to use a SocketCAN network interface with the SLCAN driver. That won’t work because the SLCAN driver expects a serial port to work with, not a network interface. You can fix it by simply replacing this:

UAVCAN__CAN__IFACE='slcan:slcan0'

with this:

UAVCAN__CAN__IFACE='socketcan:slcan0'

Haa thank you ! I understand. Now it’s working by replacing UVCAN__CAN__IFACE.
Now I have a yakut monitor that is launching correctly.
That said, it’s pretty weird because on yakut monitor I can only see the “yakut node” whereas, when launching uavcan_gui_tool (selecting the same can iface slcan0) I can see my can network beside the yakut node. :thinking:
Capture d’écran de 2021-11-11 13-50-52
Capture d’écran de 2021-11-11 13-51-42

Do you have any idea what I have might done wrong ? Thanks :slight_smile:

Yakut works with UAVCAN v1 only. It may support the old protocol at one point but it is not implemented yet.

The UAVCAN GUI Tool is only compatible with the old v0.

Ok I will then try to switch to v1. Thank you really much for your fast answers. It really helped me a lot.

Before switching make sure that your target implementation supports v1 and that v1 fits your needs. There’s a lot of confusion at the moment, but broadly speaking v0.9 is much more supported - it’s the protocol that is used by almost all the available uavcan hardware.

1 Like

If compatibility with ArduPilot is a requirement, then staying with v0 might be a wise decision. In all other scenarios, this would likely be a mistake.

  1. v0 is only suitable for highly centralized systems where there is only one actor responsible for the consumption of data from the bus and the issuance of imperatives to other nodes.

  2. v0 is only suitable for networks that match the rigid architectural patterns envisioned by the authors of its data types. E.g., if you have a quadplane and the authors of the ESC service did not foresee that use case, you’re out of luck.

  3. v0 only supports CAN, which is being phased out in the industry. In five years every major medium- to the high-end vehicle will be heavily leveraging Ethernet.

  4. All existing implementations of v0 (both official and third-party) are seriously lacking in quality compared to v1, which might make them inadmissible in many systems where UAVCAN would be useful.

You may find more information on the differences here: UAVCAN 2019 roadmap

1 Like