Something is broken in your Python installation.
I’ve installed an Ubuntu virtual machine on my Windows machine (Ubuntu 20.04).
Following your screencast, I’ve installed Yakut correctly (it gives an output when yakut --help). However, I can’t seem to run the transport. I tried the sourcing method, but it returns:
sudo: setup_slcan: command not found
OSError: [Errno 19] No such device
Auto-selected node-ID for this session:
When I try setting the environment variables manually, I’ve found my Babel as tty/ACM0:
user@ubuntu:/sys$ export UAVCAN__CAN__IFACE="slcan:ttyACM0"
user@ubuntu:/sys$ export UAVCAN__NODE__ID=$(yakut accommodate)
InvalidMediaConfigurationError: Interface does not support CAN FD: slcan
How do I fix this?
Sorry for being a pain 
The first command failed because you need to install setup_slcan, as suggested by the error message. If you google the name, you will find it in the first search result: setup_slcan -- a simple script for managing SocketCAN SLCAN interfaces on GNU/Linux · GitHub
To fix the “interface does not support CAN FD” error, you need to set the bit rate and the MTU manually. This is because by default, PyCyphal assumes that you want CAN FD, but it is not supported by the SLCAN protocol. Here’s how you can do it:
export UAVCAN__CAN__BITRATE="1000000 1000000"
export UAVCAN__CAN__MTU="8"
So I’ve done a fair level of digging and I’m up to this point:
user@ubuntu:~/Desktop$ python3 update_bootloader.py
Install PyCyphal: pip install pycyphal[transport-can-pythoncan,transport-serial]; also configure the CYPHAL_PATH environment variable; see PyCyphal or Yakut docs for details.
But I know that my env path is installed correctly (following the screencast). In the actual python updatebootloader file, I see that error is returned when the program can’t:
import pycyphal
import uavcan
import zubax
Manually running python and checking sees that I can indeed import PyCyphal, but I can’t import uavcan (even after installing it (pip3 install uavcan/pip install pyuavcan_v0) and I can’t import zubax. However, I can’t seem to find an package for that.
How do I solve this?
Thank you once again for your patience Pavel!!
This is because PyCyphal cannot find the DSDL files. Your CYPHAL_PATH variable needs to contain a list of directories that contain DSDL namespaces. For example, if you clone GitHub - OpenCyphal/public_regulated_data_types: Regulated DSDL definitions for Cyphal (standard and third-party) into your home directory, then you should export CYPHAL_PATH=$HOME/public_regulated_data_types.
Please uninstall these, they are not needed.
Done.
When I run echo $CYPHAL_PATH I get: /home/usr/public_regulated_data_types/, and running cd $CYPHAL PATH, throws me into the right folder. When I set the variable correctly, I got a compiling DSDL .... (can’t recall fully), and then the shell gives me the same error as earlier:
Install PyCyphal: pip install pycyphal[transport-can-pythoncan,transport-serial]; also configure the CYPHAL_PATH environment variable; see PyCyphal or Yakut docs for details.
The DSDL files are correct now, yet the error is the same.
Weird. Please export PYCYPHAL_LOGLEVEL="DEBUG" and re-run, then share the output.
This is the result. Not too sure what to make of it.
user@ubuntu:~/Desktop$ python3 update_bootloader.py
2024-11-20 05:32:35,987 8569 INFO pycyphal: Log config from env var; level: 'DEBUG'
2024-11-20 05:32:36,136 8569 DEBUG pycyphal.dsdl._import_hook: Installing default import hook.
2024-11-20 05:32:36,136 8569 DEBUG pycyphal.dsdl._import_hook: lookup dirs: ['/home/usr/public_regulated_data_types/']
2024-11-20 05:32:36,136 8569 DEBUG pycyphal.dsdl._import_hook: output dir: /home/usr/.pycyphal
2024-11-20 05:32:36,137 8569 DEBUG pycyphal.dsdl._import_hook: Using root namespace uavcan at /home/usr/public_regulated_data_types/uavcan
2024-11-20 05:32:36,137 8569 DEBUG pycyphal.dsdl._import_hook: Using root namespace reg at /home/usr/public_regulated_data_types/reg
2024-11-20 05:32:36,192 8569 DEBUG pycyphal.dsdl._import_hook: Attempting to load module uavcan as DSDL
2024-11-20 05:32:36,193 8569 DEBUG pycyphal.dsdl._import_hook: Found root namespace uavcan in DSDL source directory /home/usr/public_regulated_data_types/uavcan
2024-11-20 05:32:36,193 8569 DEBUG pycyphal.dsdl._import_hook: Attempting to load module zubax as DSDL
Install PyCyphal: pip install pycyphal[transport-can-pythoncan,transport-serial]; also configure the CYPHAL_PATH environment variable; see PyCyphal or Yakut docs for details.
Ah it’s easy. According to the last two lines of the log, you just need to download this and store it similarly to your public_regulated_data_types:
Be sure it is listed in CYPHAL_PATH.
Yes! Everything worked smoothly.
Managed to update the bootloader using the python program, then I managed to downgrade the firmware using Yakut (and Yukon on my second ESC).
I will post a complete list of all my steps and commands for posterity. Also, @pavel-kirienko , would it be a good idea to add this as an option for compatibility between Ardupilot and Myxa in the future? Seeing their stubbornness to adopt OpenCyphal, I believe that a more robust option rather than RCPWM would be ideal without compromising elsewhere. Using RCPWM would be a waste of the technologies and data that Myxa offers, no?
Thanks once again for all your help and patience.
At the moment, the preferred way for using ArduPilot with Telega-based ESC is the custom Lua script that I linked earlier:
The script admittedly requires tweaking, but it is currently the best option. I don’t think we’re going to see Cyphal support in ArduPilot as long as Tridge is in charge.
I would use the script, but my Autopilot (Pixhawk 2 - Cube Black) doesn’t support a script that size (Apparently…).
Truly unfortunate.
@pavel-kirienko ,Mission planner reports that my Myxa is reporting an WARNING status (all 4 Myxa’s), and thus blocks me from arming my drone.
Any reason this might be the case?
Have you done motor identification?
Uh… I’m not too sure what you mean? I’ve set each Myxa to a different ID.
Oh this!
Yes, I’ve done this. No difference overall.
Please share the heartbeat status reported by the ESCs.
Interestingly, I got 3/4 ESC’s to work correctly. With the 4th, I’ve encountered an issue. I’ve updated the bootloader and the Python program tells me that I’m at the latest version - good!
However, I can’t downgrade version of the software because it simply just shows an yellow LED (NoAppToBoot). When I send back the 1.0.1. version firmware, the Myxa picks it up and upgrades fine.
This is done through Yukon and UAVCAN GUI.
When I try to update through Yakut, I get this:
2024-12-01 23:50:27 0085034 INF yakut.cmd.file_server: File server root directories: ['/home/usr/Downloads']
2024-12-01 23:50:27 0085034 INF yakut.cmd.file_server: Total update: True; trigger explicitly: []
2024-12-01 23:50:28 0085034 INF yakut.param.transport: Transport constructed from registers: CANTransport(SocketCANMedia('slcan0', mtu=8), local_node_id=74)
2024-12-01 23:50:28 0085034 INF yakut.cmd.file_server: Starting a plug-and-play allocator using file '/home/usr/Desktop/allocation_table.db'
2024-12-01 23:50:28 0085034 INF yakut.cmd.file_server: Initializing the node tracker
2024-12-01 23:50:28 0085034 INF yakut.cmd.file_server: Initializing the software update checker
2024-12-01 23:50:28 0085034 INF yakut.cmd.file_server: Node 125 most recent heartbeat: uavcan.node.Heartbeat.1.0(uptime=1140, health=uavcan.node.Health.1.0(value=3), mode=uavcan.node.Mode.1.0(value=3), vendor_specific_status_code=0)
2024-12-01 23:50:28 0085034 INF yakut.cmd.file_server: Node 125 info: <not available>
2024-12-01 23:50:28 0085034 INF yakut.cmd.file_server: Node 125 most recent heartbeat: uavcan.node.Heartbeat.1.0(uptime=1140, health=uavcan.node.Health.1.0(value=3), mode=uavcan.node.Mode.1.0(value=3), vendor_specific_status_code=0)
2024-12-01 23:50:28 0085034 INF yakut.cmd.file_server: Node 125 info: uavcan.node.GetInfo.Response.1.0(protocol_version=uavcan.node.Version.1.0(major=1, minor=0), hardware_version=uavcan.node.Version.1.0(major=1, minor=3), software_version=uavcan.node.Version.1.0(major=0, minor=0), software_vcs_revision_id=0, unique_id=[48, 0,67, 0,10,81,54,49,48,54,56,56, 0, 0, 0, 0], name='com.zubax.telega', software_image_crc=[], certificate_of_authenticity='')
2024-12-01 23:50:28 0085034 INF yakut.cmd.file_server: Checking if node 125 requires a software update...
2024-12-01 23:50:28 0085034 INF yakut.cmd.file_server: com.zubax.telega-1.3-0.0.app: Checking if com.zubax.telega-1.3-1.2.1e5c06b5751eefb2.6a34880f9af5cb71.app is equivalent...
2024-12-01 23:50:28 0085034 INF yakut.cmd.file_server: com.zubax.telega-1.3-0.0.app: No, the software version does not match.
2024-12-01 23:50:28 0085034 INF yakut.cmd.file_server: com.zubax.telega-1.3-0.0.app: Checking if this app should be updated to com.zubax.telega-1.3-1.2.1e5c06b5751eefb2.6a34880f9af5cb71.app...
2024-12-01 23:50:28 0085034 INF yakut.cmd.file_server: com.zubax.telega-1.3-0.0.app: The applications appear to be compatible -- an update would not break the node. Looking further...
2024-12-01 23:50:28 0085034 INF yakut.cmd.file_server: com.zubax.telega-1.3-0.0.app: CRC is identical or not defined, checking the version information...
2024-12-01 23:50:28 0085034 INF yakut.cmd.file_server: com.zubax.telega-1.3-0.0.app: Yes, com.zubax.telega-1.3-1.2.1e5c06b5751eefb2.6a34880f9af5cb71.app is of a different version and is not older than the current one.
2024-12-01 23:50:28 0085034 WAR yakut.cmd.file_server: Requesting node 125 to update its software: uavcan.node.ExecuteCommand.Request.1.1(command=65533, parameter='com.zubax.telega-1.3-1.2.1e5c06b5751eefb2.6a34880f9af5cb71.application.bin')
2024-12-01 23:50:28 0085034 INF yakut.cmd.file_server: Node 125 confirmed software update command uavcan.node.ExecuteCommand.Request.1.1(command=65533, parameter='com.zubax.telega-1.3-1.2.1e5c06b5751eefb2.6a34880f9af5cb71.application.bin')
2024-12-01 23:50:28 0085034 INF pycyphal.application.file: FileServer(['/home/usr/Downloads']): Request from 125: uavcan.file.Read.Request.1.1(offset=0, path=uavcan.file.Path.2.0(path='com.zubax.telega-1.3-1.2.1e5c06b5751eefb2.6a34880f9af5cb71.application.bin'))
2024-12-01 23:50:29 0085034 INF pycyphal.application.file: FileServer(['/home/usr/Downloads']): Request from 125: uavcan.file.Read.Request.1.1(offset=256, path=uavcan.file.Path.2.0(path='com.zubax.telega-1.3-1.2.1e5c06b5751eefb2.6a34880f9af5cb71.application.bin'))
2024-12-01 23:50:29 0085034 INF pycyphal.application.file: FileServer(['/home/usr/Downloads']): Request from 125: uavcan.file.Read.Request.1.1(offset=512, path=uavcan.file.Path.2.0(path='com.zubax.telega-1.3-1.2.1e5c06b5751eefb2.6a34880f9af5cb71.application.bin'))
2024-12-01 23:50:29 0085034 INF pycyphal.application.file: FileServer(['/home/usr/Downloads']): Request from 125: uavcan.file.Read.Request.1.1(offset=768, path=uavcan.file.Path.2.0(path='com.zubax.telega-1.3-1.2.1e5c06b5751eefb2.6a34880f9af5cb71.application.bin'))
2024-12-01 23:50:29 0085034 INF pycyphal.application.file: FileServer(['/home/usr/Downloads']): Request from 125: uavcan.file.Read.Request.1.1(offset=1024, path=uavcan.file.Path.2.0(path='com.zubax.telega-1.3-1.2.1e5c06b5751eefb2.6a34880f9af5cb71.application.bin'))
2024-12-01 23:50:29 0085034 INF pycyphal.application.file: FileServer(['/home/usr/Downloads']): Request from 125: uavcan.file.Read.Request.1.1(offset=1280, path=uavcan.file.Path.2.0(path='com.zubax.telega-1.3-1.2.1e5c06b5751eefb2.6a34880f9af5cb71.application.bin'))
2024-12-01 23:50:29 0085034 INF pycyphal.application.file: FileServer(['/home/usr/Downloads']): Request from 125: uavcan.file.Read.Request.1.1(offset=1536, path=uavcan.file.Path.2.0(path='com.zubax.telega-1.3-1.2.1e5c06b5751eefb2.6a34880f9af5cb71.application.bin'))
And it keeps going where the offset value just keeps increasing by 256?
EDIT: Further testing shows that once the ESC is updated to the latest 1.1 software, after a power cycle, it returns to the yellow LED state.
It means the firmware is being downloaded. You need to wait for the download to finish, otherwise you get the NoAppToBoot state.
This means that the certificate of authenticity is missing. This is a 222-byte long binary blob that needs to be stored at 0x0000BF00. Here’s your value:
6e8cc6a6f2baa4b5907356c954c6457b7a0649a25ae6776dd9f8bafb75a72b02a3bc7f5c761fbb6782bba02352ddf95bed96668466223ad87821d222132d94f709799e932062fae39467c651cb40a0788c06b3fcecda0860fc1a3b65ffc9c52d4359c20083c45168d2d8804602a57898a0cb9472371af20e4735784409883cc4e8d7f978892ee2eae88731f73785e9fe86761e89ed8a8e414c201fe54ffafd5624e1d063cb4f2c224b7c5103ff53db1a3049bd14f5a8495796ee38b3b8991fbac1dced6c3ca9dbe3222f87a2f5e64b08c6c895aba2f015ce9ed59f86801d
You can convert it into .bin using this Python snippet:
s = '6e8cc6a6f2baa4b5907356c954c6457b7a0649a25ae6776dd9f8bafb75a72b02a3bc7f5c761fbb6782bba02352ddf95bed96668466223ad87821d222132d94f709799e932062fae39467c651cb40a0788c06b3fcecda0860fc1a3b65ffc9c52d4359c20083c45168d2d8804602a57898a0cb9472371af20e4735784409883cc4e8d7f978892ee2eae88731f73785e9fe86761e89ed8a8e414c201fe54ffafd5624e1d063cb4f2c224b7c5103ff53db1a3049bd14f5a8495796ee38b3b8991fbac1dced6c3ca9dbe3222f87a2f5e64b08c6c895aba2f015ce9ed59f86801d'
open('signature.bin', 'wb').write(bytes.fromhex(s))
You can upload it using any SWD debugger, or by introducing a trivial modification to the Python script that you used for updating the bootloader.
Please share the order number or the date when you purchased this last unit.