Hi!
I’m looking to fit in 4 Myxa’s on my Ardupilot powered Quadcopter. However, I’m on Telega v1, so using CAN is currently not supported. Is it possible that I downgrade back to Telega v0.2 so that I can fully use Drone/UAVCAN with Ardupilot. This would be more optimal than migrating the whole drone to PX4.
I’ve tried downloading the firmware from here and uploading it to the Myxa using Yukon but I don’t see any Software Version change and all those versions are using OpenCyphal rather than DroneCAN.
tl;dr: Is is possible for me to downgrade my Myxa from Telega v1 to v0.2 to use it with Ardupilot. If so, how do I do this??
v0.2 is probably too old for most applications. You can use any of the firmware versions that you already linked instead – they are all DroneCAN compatible, not Cyphal.
However, I would strongly advise using RC PWM control with Telega v1.0 instead of downgrading back to v0.
Try using Yakut instead. The command is yakut file-server <FIRMWARE-DIRECTORY> --update-software <NODE_ID>; see yakut file-server --help for usage info.
While this is a possibility, I bought Myxas for their excellent motor control but also the CAN interface, diagnostics and the additional data that comes through. Using RCPWM is a workaround, but basically a waste of 4 Myxas with my Pixhawk.
I don’t mind using RCPWM for a while if I was given a rough date or time when there would be some form of OpenCyphal support or a Lua script.
Is 0.6 DroneCAN compatible? This will work with Ardupilot?
Indeed this will be part of the roadmap. I want to get the full system working with Ardupilot working natively with the Myxa’s before I try OpenCyphal through a Lua script.
While running the command you provided (^) and the one from the Telega Reference Manual, I get an output telling me that the node does not require a firmware update.
2024-11-10 19:27:05 0013548 INF yakut.cmd.file_server: Checking if node 125 requires a software update...
2024-11-10 19:27:05 0013548 INF yakut.cmd.file_server: com.zubax.telega-1.3-1.0.1e5c06b5751eefb2.6a34880f9af5cb71.app: Checking if com.zubax.telega-1-0.4.0000000025f393bf.app is equivalent...
2024-11-10 19:27:05 0013548 INF yakut.cmd.file_server: com.zubax.telega-1.3-1.0.1e5c06b5751eefb2.6a34880f9af5cb71.app: No, the software version does not match.
2024-11-10 19:27:05 0013548 INF yakut.cmd.file_server: com.zubax.telega-1.3-1.0.1e5c06b5751eefb2.6a34880f9af5cb71.app: Checking if this app should be updated to com.zubax.telega-1-0.4.0000000025f393bf.app...
2024-11-10 19:27:05 0013548 INF yakut.cmd.file_server: com.zubax.telega-1.3-1.0.1e5c06b5751eefb2.6a34880f9af5cb71.app: The applications appear to be compatible -- an update would not break the node. Looking further...
2024-11-10 19:27:05 0013548 INF yakut.cmd.file_server: com.zubax.telega-1.3-1.0.1e5c06b5751eefb2.6a34880f9af5cb71.app: CRC is identical or not defined, checking the version information...
2024-11-10 19:27:05 0013548 INF yakut.cmd.file_server: com.zubax.telega-1.3-1.0.1e5c06b5751eefb2.6a34880f9af5cb71.app: No, the other application is older.
2024-11-10 19:27:05 0013548 WAR yakut.cmd.file_server: Node 125 does not require a software update.
To force a software update it is necessary to explicitly address the node to be updated e.g. yakut file-server ./fw_directory --update-software 125 where 125 is an example for a ESC node id (check using yakut monitor).
Alternatively rename the firmware file, increasing the software version (SWMAJ or SWMIN) number according to the diagram in the manual (yakut file-server --help) thus make yakut trigger an update:
NAME-HWMAJ.HWMIN-SWMAJ.SWMIN.VCS.CRC.app*
[...]
A node running software version X (as determined from uavcan.node.GetInfo) is considered to require
an update to Y (a local package file) if the names are matching, the hardware version is compatible,
and either condition holds:
- The software image CRC is defined for both X and Y and is different.
- The software version of Y is higher than X.
- The software version of Y is not older than X and the VCS hash is different.
- There may be additional heuristics to handle edge cases. Inspect logs or use --verbose to see
details.
e.g rename your file com.zubax.telega-1.3-1.0.1e5c06b5751eefb2.6a34880f9af5cb71.app to com.zubax.telega-1.3-1.1.1e5c06b5751eefb2.6a34880f9af5cb71.app
Thank you @psandro.
However, trying both the force update and the renaming method, by Myxa goes offline when I try to make the update. This happens both on Yakut and Yukon where is command is sent successfully after it determines it is a “new” update, but the Myxa fails to make the update by simply disappearing then reappearing.
PS C:\Windows\system32> yakut file-server C:\ --update-software 124
2024-11-11 18:09:35 0014760 WAR yakut.cmd.file_server: Requesting node 124 to update its software: uavcan.node.ExecuteCommand.Request.1.1(command=65533, parameter='com.zubax.telega-1.3-1.1.1e5c06b5751eefb2.6a34880f9af5cb71.app.bin')
2024-11-11 18:09:43 0014760 WAR yakut.cmd.file_server: Node 124 ignored because total update mode not selected and its ID is not given explicitly (explicit node-IDs are: (none given))
(Then hangs)
PS C:\Windows\system32> yakut file-server -P 124 C:\ --update-software
2024-11-11 18:12:28 0013184 WAR yakut.cmd.file_server: Requesting node 124 to update its software: uavcan.node.ExecuteCommand.Request.1.1(command=65533, parameter='com.zubax.telega-1.3-1.1.1e5c06b5751eefb2.6a34880f9af5cb71.app.bin')
2024-11-11 18:12:37 0013184 WAR yakut.cmd.file_server: Requesting node 124 to update its software: uavcan.node.ExecuteCommand.Request.1.1(command=65533, parameter='com.zubax.telega-1.3-1.1.1e5c06b5751eefb2.6a34880f9af5cb71.app.bin')
2024-11-11 18:12:45 0013184 WAR yakut.cmd.file_server: Requesting node 124 to update its software: uavcan.node.ExecuteCommand.Request.1.1(command=65533, parameter='com.zubax.telega-1.3-1.1.1e5c06b5751eefb2.6a34880f9af5cb71.app.bin')
2024-11-11 18:12:53 0013184 WAR yakut.cmd.file_server: Requesting node 124 to update its software: uavcan.node.ExecuteCommand.Request.1.1(command=65533, parameter='com.zubax.telega-1.3-1.1.1e5c06b5751eefb2.6a34880f9af5cb71.app.bin')
(Then repeats continously)
In Yukon
24-11-11 18:29:42 Frontend U: ✓ uavcan.node.ExecuteCommand.Response.1.1(status=0) (success)
24-11-11 18:29:46 yukon.services.avatar_handler W: Node with id 124 disappeared at 18:29:46
PS C:\Windows\system32> yakut file-server C:\ --update-software 124
2024-11-11 18:09:35 0014760 WAR yakut.cmd.file_server: Requesting node 124 to update its software: uavcan.node.ExecuteCommand.Request.1.1(command=65533, parameter='com.zubax.telega-1.3-1.1.1e5c06b5751eefb2.6a34880f9af5cb71.app.bin')
2024-11-11 18:09:43 0014760 WAR yakut.cmd.file_server: Node 124 ignored because total update mode not selected and its ID is not given explicitly (explicit node-IDs are: (none given))
(Then hangs)
PS C:\Windows\system32> yakut file-server -P 124 C:\ --update-software
2024-11-11 18:12:28 0013184 WAR yakut.cmd.file_server: Requesting node 124 to update its software: uavcan.node.ExecuteCommand.Request.1.1(command=65533, parameter='com.zubax.telega-1.3-1.1.1e5c06b5751eefb2.6a34880f9af5cb71.app.bin')
2024-11-11 18:12:37 0013184 WAR yakut.cmd.file_server: Requesting node 124 to update its software: uavcan.node.ExecuteCommand.Request.1.1(command=65533, parameter='com.zubax.telega-1.3-1.1.1e5c06b5751eefb2.6a34880f9af5cb71.app.bin')
2024-11-11 18:12:45 0013184 WAR yakut.cmd.file_server: Requesting node 124 to update its software: uavcan.node.ExecuteCommand.Request.1.1(command=65533, parameter='com.zubax.telega-1.3-1.1.1e5c06b5751eefb2.6a34880f9af5cb71.app.bin')
2024-11-11 18:12:53 0013184 WAR yakut.cmd.file_server: Requesting node 124 to update its software: uavcan.node.ExecuteCommand.Request.1.1(command=65533, parameter='com.zubax.telega-1.3-1.1.1e5c06b5751eefb2.6a34880f9af5cb71.app.bin')
(Then repeats continously)
In Yukon
24-11-11 18:29:42 Frontend U: ✓ uavcan.node.ExecuteCommand.Response.1.1(status=0) (success)
24-11-11 18:29:46 yukon.services.avatar_handler W: Node with id 124 disappeared at 18:29:46
This message says that you are already running firmware com.zubax.telega-1.0.1e5c06b5751eefb2.6a34880f9af5cb71 (I see that you added the hardware version number to the file name but it’s not needed). Updating to the same version does not make a lot of sense.
The syntax is correct but the command will only work if the C:\ directory contains the firmware file. From the other invocations it is unclear if this is the case.
It doesn’t hang but keeps running while not doing anything, because there are either no nodes to update or no firmware files available.
This invocation is probably not what you mean because you are using 124 as the file name for the allocation table, while not giving an explicit list of nodes to update. The previous forms are correct.
In case you are dealing with some Windows-specific issues, you could upload the firmware via the debug connector of Myxa:
I didn’t do that - that was the same file name from the server.
Would updating it to a much higher version number work?? (i.e. v1.5.6)
Indeed this the case. I tried a few different folders just to be sure…
I’m just trying everything at this point given that I’m not familar with Yakut as much as I’d like to be.
PS C:\Windows\system32> yakut file-server C:\Users\Public --update-software 124
2024-11-11 21:43:14 0003680 WAR yakut.cmd.file_server: Requesting node 124 to update its software: uavcan.node.ExecuteCommand.Request.1.1(command=65533, parameter='com.zubax.telega-1.4.1e5c06b5751eefb2.6a34880f9af5cb71.app.bin')
2024-11-11 21:43:22 0003680 WAR yakut.cmd.file_server: Node 124 ignored because total update mode not selected and its ID is not given explicitly (explicit node-IDs are: (none given))
This is the closest (I think) I’ve gotten.
I’m using a Babel as part of this workflow. How do I use the the debug connector…?
Hm, this is sus. Your logs refer to com.zubax.telega-1.3-1.1.1e5c06b5751eefb2.6a34880f9af5cb71.app.bin (the second entry from your previous post), but the file on the file server is named slightly differently. The name itself doesn’t matter that much but I need to understand what caused it to be different.
Regarless, though, you don’t need to use the v1 firmware, since you want to downgrade (although I would go with that Lua script still, in which case no downgrade is needed). If you’re confident you want to downgrade, obtain the latest v0 firmware from the file server.
Please try running your first command again, but this time ensure that the binary file is indeed contained in the specified path (or change the path), and add the node-ID after the --update-software flag, like this (I am using shorthand options here for brevity):
y -v file-server C:\Users\Public -P allocation_table.db -u 124
You should see the command emit messages like Requesting node 124 to update its software: ..., followed by requests coming back from the node. If anything goes wrong, we should see helpful log messages.
An alternative to this would be to use any STM32-compatible SWD adapter to upload the firmware as I mentioned earlier. One such adapter is available here:
Oh I see what the problem is – I should have checked this early. The device you’re upgrading was manufactured back in 2019. The bootloaders shipped in 2019 are not compatible with Telega v1 – you can switch to v1 but you can’t go back after that. You have two solutions:
Replace the bootloader using an SWD adapter. Babel cannot be used for this because it is not an SWD adapter. To do that, upload this binary at 0x08000000 (i.e., the origin of flash): https://files.zubax.com/products/com.zubax.telega/com.zubax.telega.bootloader.bin; be sure to retain the 256 bytes between 0x0000BF00 and 0x0000C000, they contain the digital signature. Since you’re using the SWD adapter anyway, you can also use it to rewrite the application as well while you’re at it; the load address is 0x0000C000.
Replace the bootloader using this script via CAN, then update the firmware normally like you’ve been attempting to do: update_bootloader.py (13.5 KB); invoke it as follows (this is Unix shell; adjust for powershell as needed):
export UAVCAN__CAN__IFACE='socketcan:slcan0' # Update as necessary
export UAVCAN__CAN__MTU=8
export UAVCAN__CAN__BITRATE='1000000 1000000'
export UAVCAN__NODE__ID=$(yakut accommodate)
echo "Auto-selected node-ID for this session: $UAVCAN__NODE__ID"
#export VERBOSE=1 # Enable extra logging for troubleshooting.
export UAVCAN__CLN__LOW_LEVEL_IO__ID=10
exec ./update_bootloader.py
PS C:\Users\Jeeva Arjun\Downloads> python ./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.
I have set my Windows environment variables, but this error strongly suggests I’ve done it incorrectly. I’ve tried it a few different ways and there is no change.
(Indeed my installation of PyCyphal is also correct - installed as per the PyPI docs and the error thrown up)
Some help would be appreciated in the verification of my installation.
I used to run WSL (Windows Subsystem for Linux) for that express purpose but it had lots of cross-os dependency issues.
I run Windows for Solidworks/Edge and other stuff. Unless I really have to, I’d like to stick to Windows, but I guess I could run an Ubuntu Virtual Machine. It just means that I’ve got to set everything up again. @pavel-kirienko, did you want me to switch to Ubuntu or can you help me solve this Windows environment variable problem?
Thanks again!
As far as I’m aware using WSL does not solve the issue that Windows is just not very good for these kinds of tasks.
It might work for compiling the occasional program or something like that, but as soon as you want to venture beyond that (like connecting to CAN networks) it becomes really difficult (as you mentioned, that’s when the cross-OS issues start to get in the way).
As a simple example, here I’m doing a simple demo by turning a magnet on/off; on Ubuntu I can open 2 separate terminals connected to the device through Cyphal/CAN; one observing the state of the magnet and one sending commands. This works because at the level of interacting with the network we can rely on SocketCAN.
Using Windows, doing exactly the same is simply not possible: a serial port can only be accessed by 1 process on Windows (and SocketCAN is only supported on Linux).
(If you’re planning to do embedded programming, GNU/Linux is also a no-brainer.)
I have no experience with WSL so I can’t be certain if things are going to work there as they should. If you can switch to a GNU/Linux distribution, that would certainly help (it doesn’t have to be Ubuntu).
The error message explains what needs to be done to fix the problem:
