MAVLink also has messages separated from the protocol, you can define whatever messages you want - actually MAVLink has different messages for different autopilots besides the common set.
Well, but then you are out of the standard and the current only available UAVCAN GPS (that I’m aware of) wouldn’t support those messages. And, if we were going out of standard, then having UART/SPI/I2C encapsulation would be much more valuable.
no. Mavlink entangles protocol and message layers, with all sorts of issues. The fact that one can define a message isn’t really telling anything. But I agree, that’s OT.
I think two things get mixed here. As regards the original topic of having some startup exchange: No, you can do what you want, uavcan allows user defined messages. As regards the “btw” comment: Yes. But: One gps doesn’t really set a standard. The situation would be different if there were 100reds of gpses, but that’s not yet the case, So, you guys should define what ArduPilot needs for best operation, and not limit yourself. If you don’t do now, then of course you eventually will have to adapt instead of to define. I also don’t really see any practical issue, it is just one message, so it should be always easy to support the “standard”, but at the same time do your own, better thing. If it is better, gpses will follow. E.g., Ublox speaks NMEA and UBX.
my 2 cents
btw: it might be that in not too far future a 2nd gps becomes available, to the “masses”
@olliw42 Of course ArduPilot can do whatever it wants, but there’s no point in developing our own messages if no hardware maker supports them. And as I said, if we are going to deviate from the standard messages set by UAVCAN, it is best to just encapsulate the existing protocols and use our existing drivers.
Also, that would deviate from UAVCAN’s plan and, at this point, we are trying to work with them and not going with our own separate path.
Anyway, this is a bit of a degression from the main topic, right
I think we all agree that one would want to have some mechanism for getting some startup config info from a node, and for gpses the lag specifically. Some few suggestions came up, a final concept not yet. Maybe something to work on.
You’ve made an excellent post for Pavel 
Hi Olli & Francisco,
I wasn’t aware of this discussion until now (several months later).
@olliw42 @OXINARF @WickedShell You’re approaching the problem from a wrong mindset. UAVCAN GNSS broadcasters do not need to report their lag to subscribers because the UAVCAN protocol provides built-in means of network-wide time synchronization. The standard GNSS Fix message includes a timestamp that is made in the network-shared time base. If the autopilot is synchronized with the network time base (of course it should be, and it’s easy to do), the lag of each received message can be trivially obtained by subtracting the timestamp of the GNSS message from the timestamp of the moment when the EKF begins processing of the message.
Please observe that unlike the currently used lag-based approach, this is the direct solution of the problem that can be extended towards other sensor feeds, and other data flows. The sensor timestamping approach is widely used in robotics in general. The current lag-based approach is flawed in many ways, most importantly it doesn’t account for the latency of the data bus itself, whereas the proper timestamping approach does.
Concerning the message standardization issues: the idea expressed by Olli that there can’t be a decent vendor-neutral standardized message, and that, therefore, vendors should opt for vendor-specific messages, is entirely wrong. There is plenty of examples of solid well-designed standards in the aerospace industry that work well by abstracting away the implementation differences and converging a huge variety of equipment produced by various vendors to a simple common interface. I understand that some might want to point out that there were highly unsuccessful attempts to achieve the same goals in other industries, such as NMEA 0183, which I agree is a disaster, but one particular flawed implementation says nothing about the concept itself.
As has been explained in the chat room linked earlier, the addition of vendor-specific messages would defeat one of the primary purposes of UAVCAN, which is to define a standardized data interface that can be used by any sort of equipment from different vendors out of the box. When one proposes that vendor-specific messages are acceptable, they apparently aren’t thinking outside the narrow limits of the most basic UAV applications where the usage of CAN bus is limited to carrying measurements from the sensors to the autopilot and from that to actuators. The vendor-specific messaging approach would immediately break apart even in a slightly more complicated scenario.
Consider, for example, a camera that wants to geotag its images by using GNSS data from the CAN bus (like Mapir cameras that support UAVCAN do). The task is trivial as long as there is a standard data bus interface that can be relied upon by the vendors of the camera, the GNSS receiver, and the autopilot. Shall one resort to vendor-specific definitions, the whole ecosystem immediately falls apart. I hope this example is illustrative enough. Needless to say, the example applies to other use cases beyond cameras and GNSS receivers.
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.
I invite @EShamaev to this discussion, perhaps he has something to add.
Pavel.
hey Pavel,
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.
Cheers, Olli
ähm, btw:
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 
@Pavel_Kirienko The GPS lag that is used inside ardupilot is more then just a transport mechanism lag term. It’s intended to represent the internal processing lag to the GPS chip itself summed with any other processing enroute to the autopilot. Typically this works out to being around one measurement period, but it can be much higher or lower depending upon GPS manufacturer. It’s also worth mentioning that higher end GPS units will actually express their entire internal processing lag terms that allow you to precisely compute the lag from the PPS event.
Unless the CAN GPS is automatically subtracting this lag term before time stamping the data and sending it I don’t see how the autopilot will know the offset.
I understood this to exactly mean this
I mean, otherwise it wouldn’t make any sense, exactly as you say
so, let’s see what Pavel says
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.
@olliw42 We’re on the same page here. So far I couldn’t abstract away the capability reporting task into a dedicated feature of the protocol. Until that is done, I propose to use ad-hoc reporting methods. Using your example of a gimbal controller, the information about whether it supports yaw or not could be carried in its status message, for example. That approach is also more beneficial compared to the capability requesting scheme because it is fully stateless.
I’m open to propositions though.
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.
That’s fine; you could use robotics frameworks as an example, such as ROS, instead of the aerospace industry. They standardize on the common functionality as well, while allowing users to define application-specific definitions, just like UAVCAN does. It should be entirely evident that standardization of core functionality is required and unavoidable, I don’t think further talks about this would serve any purpose.
this just few days ago happened, and who knows, maybe it’s going to happen this evening again
My point was that the set of standard data type definitions is not going to support tunneling because it would incentivize bad practices.
Unless the CAN GPS is automatically subtracting this lag term before time stamping the data and sending it I don’t see how the autopilot will know the offset.
I understood this to exactly mean this
I mean, otherwise it wouldn’t make any sense, exactly as you say
@WickedShell Olli is right. Of course, the sensor node is responsible for time stamping its data correctly.
[quote=“Pavel_Kirienko, post:18, topic:16922”]I’m open to propositions though.[/quote]I very much like the suggestion of WickedShell, in post no. 4 or so.
As part of the startup of the node “driver”, AP just would ask the peripheral for the value of a particular parameter. The node either has a value or not, AP would know. And any node could freely decide if it wants to offer that value, or not. Looks very simple and elegant to me.
One maybe could extend the parameter concept to support “hidden” parameters, i.e., parameters which can be accessed by the standard parameter mechanism, but which would not usually be displayed to the user. There are some voids in the response, one of which one could use as a flag.
I very much like the suggestion of WickedShell, in post no. 4 or so.
For reference, this is the suggestion:
The easy version is to make a UAVCAN parameter and attempt to fetch it from ArduPilot.
This is a fine suggestion, and there’s nothing wrong with it. Except, perhaps, that it is stateful for the autopilot, but this extra complexity can be tolerated. The names of parameters should be standardized when appropriate, too (e.g. uavcan.gimbal.yaw_enabled, and so on).
well, it is a statefull as initializing a driver is stateful
the ublox driver is e.g. doing a heck of initialization steps, no issues with that
it’s IMHO actually not extra but less complexity for the autopilot, it is digested only at startup, so no need to handle changes dynamically later on
nice to hear you like that, so, one probably oould propose it as possible mechanism for
any comments on “hidden” parameters?
any comments on “hidden” parameters?
I would advise against that because it introduces complexity with no apparent benefit to the protocol.
If the purpose of hidden parameters is to avoid bothering the user with irrelevant stuff, it can be easily accomplished at a higher level; for example, GUI tools could choose to not display parameters that cannot be changed.
but how should the gui tools know about that
e.g. Uavcan GUI Tool? You would have to hardwire that info into UavcanGUITool for ALL nodes, and whenever there comes a new node it needs to be reconfigured. Or you have to provide a “plugin” mechanism to make that info available.
Along the same lines one could have argued that also min,max,default are inappropriate
(which I in fact find way to restrictive to be really useful)
the “hidden” flag does not add any complexity. It is, as you say, with no benefit to the protocol (and in fact should not affect the protocol at all). However, that’s exactly so with ANY data carried by any message, any data adds complexity and is of no benefit to the protocol. Like min, max, default are data. Like a hidden flag would be data.
your argument doesn’t make any sense to me
but how should the gui tools know about that
If min == max, the parameter is unchangeable, hence it does not have to be displayed. Pretty simple. My point is that the problem can be solved using existing features, no need to add new concepts.
@Pavel_Kirienko I’m sorry you have only seen this now. I’m sure I’ve invited you to this topic, maybe you didn’t get the e-mail, we’ve had some server issues in the past.
Where is this enforced in the spec? From my look of it, it looks like the node is free to choose when to do the timestamp and I see no where that says that GNSS hardware lag should be removed.
no
not all, but some, maybe most, of these parameters certainly should be changeable in some way without extreme hassles, such as having to flash new firmware or using secret gui tools etc. pp
I think I stop making suggestions on the dsdl layer, it’s not very fruitful. I just hope that the AP devs make something futured of uavcan. The uavcan protocol layer is a huge step forward from mavlink, the dsdl layer isn’t yet, IMHO.
[quote]Where is this enforced in the spec? From my look of it, it looks like the node is free to choose when to do the timestamp and I see no where that says that GNSS hardware lag should be removed.[/quote]I think what Pavel wanted to say without explicitly saying it (= politeness) is that this is within the concept and not a thing of specs, and that it just me(us) who didn’t got it. I think the statement is that when one wants to remove the hardware lag one should do it through the time stamp and not some artificial additional values. Generally. That’s not gnss specific. And it is not a “should” but a “could”, like “if you want to do that you should do it so” and not “you have to do that and so”. So not a matter for a spec.
To me the concept he describes just “looks correct”, and I think that AP would indeed profit on the longer run if it would switch to it, as Pavel suggested between the lines.
If each node does what it wants, then how is it a standard? Let’s say you have two GPS with exactly the same hardware, but the driver in one removes the hardware lag and in the other it doesn’t. There is no way for ArduPilot to know it, but it would have clear implications on the lag reported to EKF - which in turn has clear implications on how well the EKF predicts position and velocity.
This is exactly the reason why some ArduPilot devs wanted to do protocol tunneling so we can use our drivers. At least we would know what the driver does instead of guessing on how some company used the standard.
@OXINARF Olli is right here. The principles of timestamping are independent of their particular application. If the vendor of a sensor node forgot to compensate for the latency of the sensor itself or that of the communication channel between the MCU and the sensor, the timestamping is implemented incorrectly, and it has to be fixed. I don’t think it’s strictly necessary to spell out such basic things in the specification, but then again, it won’t hurt to be a little too verbose either, so I’m going to add a couple of words on this to the UAVCAN spec soon.
I have nothing to add apropos tunneling - all has been said already. I wish people would stop viewing CAN as an improved I2C.