2 ms·

Hey - Thank you for the detailed insights! I appreciate all the info. For some context, I am writing bare-metal in Rust. I've been using MavLINK for some basic

Hey - Thank you for the detailed insights! I appreciate all the info. For some context, I am writing bare-metal in Rust. I've been using MavLINK for some basic stuff that is self-contained; trying to use a MAVLink Gimbal this weekend. The naive approach didn't work, but we'll see. I will hint that DroneoCAN: #1: Uses bit-alignment. Even if that means throwing off the alignment on an 80 byte message to save 3 bits. #2: Uses something similar and as poorly-document as the CRC_EXTRA byte based on message format. #3: Uses inscrutable ID assignment and Get/Set APIs. I have posted on various Githubs and discords, and the verdict is I'm the only out of touch. Ok. Fine. I will and have complied with the standards, but I am not obliged to like them, and I think they have severe engineering problems. Thank you for your insight on MavLINK. I am tolerating it for now for gimbal operations, but see the writing on the wall for the custom messages I'm using it for. Like, I need 1 byte for payload size, 1 byte for message type, maybe 1-2 for CRC... the rest of the header is a liability for OTA transmission time. I propose we don't even talk about MSP; Holy fuck.

inetknght 3y ago
Don't misunderstand me: mavlink gets the job done which is better than nothing. But its use requires careful consideration about scope and error handling -- more careful than should be necessary if COTS were used instead. I seriously wish I could have a few years to rewrite the whole stack. > I am tolerating it for now for gimbal operations Make sure you're using latest (there was a recent fix to a crash in the gimbal manager and reconnect code recently). The mavlink guys are usually pretty responsive to mavlink support questions on Github issues and discord. Many of the vendors are also on discord, useful if you're integrating with components. > I need 1 byte for payload size, 1 byte for message type, maybe 1-2 for CRC... the rest of the header is a liability for OTA transmission time. Yup, exactly. If the component and you are both already connected to an IP network then there are more industry standard protocols to use which perform better (battery, bandwidth, latency, the whole shebang) perform in a more expected behavior (a single message to a single IP destination is has well-defined routing rules, but a single mavlink message is likely broadcasted and possibly broadcasted multiple times (even when deployed to a single system), and can be secured better because security tools talk IP. You mention DroneoCAN - I assume that's a typo for DroneCAN [0]. Can you use ROS2 [1]? Contrast ROS2 with mavlink. The communication layer between different ROS2 components (nodes) can be changed for different implementations of transport and I've seen things like shared-memory (same-host, saw it at a drone conference) or replacing with another COTS (I don't remember which one though, but I think it was ZeroMQ or based on it). If you can provide a ros service then that's a step in the right direction as far as I'm concerned. ROS already has existing services to interface with CAN [2]. Even if you have some specific reason to need DroneCAN, there appears to be a an example for using ROS2 to talk to DroneCAN [3]. [0]: https://dronecan.github.io/ https://dronecan.github.io/ [1]: https://github.com/ros2 https://github.com/ros2 [2]: https://kagi.com/html/search?q=ros2+canbus https://kagi.com/html/search?q=ros2+canbus [3]: https://github.com/ARK-Electronics/ros2_dronecan https://github.com/ARK-Electronics/ros2_dronecan
- the__alchemist 3y ago
  Interesting in regards to ROS2; I'd not heard of it. It sounds like a type of RTOS or library? I'm not sure if I can use it; my devices are bare metal currently. I am using DroneCAN because it is #1: A bus. #2: Differential signaling. #3: plug+play with an ecosystem. It's a great way to set up decoupled systems, where the flight controller isn't doing all the IO. I should note that my perspective subtly clashes with the designers of both MavLINK and DroneCAN: think these protocols should operate as you'd read a hardware datasheet: It should be easy to implement in any language by referencing a byte-aligned table, and have explicit instructions. Because, it's just bytes down the wire. The DroneCAN creators, and it sounds like MavLINK as well consider it something where you should rely on an official library. The Get/Set API is a hot mess? It doesn't matter if you expect no one to implement it because the expectation is to use the official library. You will also note that DroneCAN (and maybe mavlink? Not sure) devices have poor or no protocol documentation, which is astounding to me.
  - inetknght 3y ago
    ROS2 is not a RTOS library. It's a set of libraries and tools. Though it can be installed in a real-time OS, it can also be installed in eg a Dockerfile. > You will also note that DroneCAN (and maybe mavlink? Not sure) devices have poor or no protocol documentation, which is astounding to me. Astounding, yes. Surprising, no.

inetknght 3y ago

Don't misunderstand me: mavlink gets the job done which is better than nothing. But its use requires careful consideration about scope and error handling -- more careful than should be necessary if COTS were used instead. I seriously wish I could have a few years to rewrite the whole stack. > I am tolerating it for now for gimbal operations Make sure you're using latest (there was a recent fix to a crash in the gimbal manager and reconnect code recently). The mavlink guys are usually pretty responsive to mavlink support questions on Github issues and discord. Many of the vendors are also on discord, useful if you're integrating with components. > I need 1 byte for payload size, 1 byte for message type, maybe 1-2 for CRC... the rest of the header is a liability for OTA transmission time. Yup, exactly. If the component and you are both already connected to an IP network then there are more industry standard protocols to use which perform better (battery, bandwidth, latency, the whole shebang) perform in a more expected behavior (a single message to a single IP destination is has well-defined routing rules, but a single mavlink message is likely broadcasted and possibly broadcasted multiple times (even when deployed to a single system), and can be secured better because security tools talk IP. You mention DroneoCAN - I assume that's a typo for DroneCAN [0]. Can you use ROS2 [1]? Contrast ROS2 with mavlink. The communication layer between different ROS2 components (nodes) can be changed for different implementations of transport and I've seen things like shared-memory (same-host, saw it at a drone conference) or replacing with another COTS (I don't remember which one though, but I think it was ZeroMQ or based on it). If you can provide a ros service then that's a step in the right direction as far as I'm concerned. ROS already has existing services to interface with CAN [2]. Even if you have some specific reason to need DroneCAN, there appears to be a an example for using ROS2 to talk to DroneCAN [3]. [0]: https://dronecan.github.io/ https://dronecan.github.io/ [1]: https://github.com/ros2 https://github.com/ros2 [2]: https://kagi.com/html/search?q=ros2+canbus https://kagi.com/html/search?q=ros2+canbus [3]: https://github.com/ARK-Electronics/ros2_dronecan https://github.com/ARK-Electronics/ros2_dronecan

the__alchemist 3y ago
Interesting in regards to ROS2; I'd not heard of it. It sounds like a type of RTOS or library? I'm not sure if I can use it; my devices are bare metal currently. I am using DroneCAN because it is #1: A bus. #2: Differential signaling. #3: plug+play with an ecosystem. It's a great way to set up decoupled systems, where the flight controller isn't doing all the IO. I should note that my perspective subtly clashes with the designers of both MavLINK and DroneCAN: think these protocols should operate as you'd read a hardware datasheet: It should be easy to implement in any language by referencing a byte-aligned table, and have explicit instructions. Because, it's just bytes down the wire. The DroneCAN creators, and it sounds like MavLINK as well consider it something where you should rely on an official library. The Get/Set API is a hot mess? It doesn't matter if you expect no one to implement it because the expectation is to use the official library. You will also note that DroneCAN (and maybe mavlink? Not sure) devices have poor or no protocol documentation, which is astounding to me.
- inetknght 3y ago
  ROS2 is not a RTOS library. It's a set of libraries and tools. Though it can be installed in a real-time OS, it can also be installed in eg a Dockerfile. > You will also note that DroneCAN (and maybe mavlink? Not sure) devices have poor or no protocol documentation, which is astounding to me. Astounding, yes. Surprising, no.