thx a LOT for the clarification on the gps_lag. I revert my opinion and totally concur. This was in fact a very helpful explanation, so many thx for that lesson.
I do concur for gps_lag, but not in general. I still argue that there are legitimate situation in which a node might want to report to the flight controller some particular capabilities, or maybe better the other way around, that the flight controller might want to ask the node for some particular capabilities. In this context the gps_lag was an example, albeit admittedly a bad one. I for instance also brought up the example that a gimbal might want to tell the flight controller (or the flight controller might want to ask the gimbal) if yaw_enabled is true. I mean, honestly, that’s so obvious that it hardly can be argued.
As regards the “decent vendor-neutral standardized message”: My point is that it’s neither 100% that or that. In fact, maybe you find time to read https://discuss.ardupilot.org/t/uavcan-gimbal-xyz/, point (B), last paragraph.
My point is also that whenever a standard doesn’t capture the individualism of a node then it limits its potential. If you like that better I’ll proof that using set theory: An element is either part of a set or not, it can’t be both inside and outside a set. So, it is either part of the standard set or not. If the standard is such that it embraces all individualism of all nodes it is not a standard but the full set, if it does not embrace all individualism then some elements are necessarily outside of the standard set, and thus not available … unless, of course one would embrace them via vendor-specifc messages. Q.E.D.
Your example of aerospace industry (and other industries you might bring up) is - IMHO - flawed in an essential point: Aerospace industry is an extremely slow moving and very long-term industry. Drones are quite the opposite (I myself am at least very much impressed by the pace of development in just few years). Of course, one could talk for half a year to settle an addition to a standard, and then wait for another half year for the next AP version to come out, to support a new feature. I mean, Mavlink doesn’t even support the most minimalistic individualism of STorM32, not even a single function can be triggered, and not even the simplest bug got removed. So, if that is your plan, to have a well defined standard set, even at the cost of slow progress, then you are right. Unfortunately, I don’t have this patience, especially as there is a concept to largely get around it :). If your plan is to only achieve what Mavlink offers, then we are actually both spending our time unwisely, because this is essentially already done.
Anyway, I feel like I have said all that before, and that we are going in circles.
At the end of the day it is this: I do have my opinion, but this are just my 2 cents. Only you (not you personally, but you the devs) can decide. And only you decide.
I’m in a passive mode here. I’m just doing my stuff.
The above is the key reason why tunneling of other protocols, such as I2C/UART/SPI, over the CAN bus is never going to happen in UAVCAN.
this just few days ago happened, and who knows, maybe it’s going to happen this evening again