3 ms·

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 -- mor

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.

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.