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.
My feeling is that GPS lag for AP should also be 0 for UAVCAN. The vendor of gnss receceiver should compensate for any lag on the device side in timestamp.
This is universal and strict enough. I think it is worth adding into notes and comments in UAVCAN messages, and also make a new version of firmware (inform vendors) for UAVCAN GNSS receivers on market.