UAVCAN GPS get_lag()

Development Team
1

I’ve seen that UAVCAN GPSes have no way to tell their lag, and that the default 0.2s as specified in the backend is used.

On the other hand, for the ublox devices it is set to either 0.22s or 0.12s. From the latter I would conclude that the devs concluded that this difference of several 0.01s matters, and so much so that it was worthwhile to implement get_lag(). This in turn would imply that it should also matter for a uavcan gps, as it may use whatever gps.

So, there is an inconsistency. Either such differences matter, but then IMHO there should be a way for uavcan gpses to announce their lag so that get_lag() can report anything useful, or they don’t matter.

Matters or not?

1 Like
2

It does matter, because it helps correlate the GPS information with the IMU information. Does it matter so much that it is unflyable if lag isn’t very precise? No, if it is in some ball park it is OK, EKF will deal with it - but obviously the more accurate information the EKF gets, the more accurate its estimation will be.

Supporting get_lag in the UAVCAN backend would be great, do you have any ideas for that? As far as I know no UAVCAN GPS message gives that information. I’m not sure if you understood that this lag is the internal GPS lag, it is how long does a GPS takes to calculate the position and velocity information.

3

I think I understand well the intention and meaning of that lag thing, as well as that it matters. The question was essentially if there was a reason for not having a get_lag() for uavcan, e.g., like “ok, it is a nice have, but it is not that important that it would be worthwhile to spend the effort in a get_lag for uavcan”, or if just isn’t there.

I read your answer however to imply that it would be worthwhile to have a get_lag also for uavcan.

Ideas? Well. To me it seems clear that there should be some sort of initialization request/response message. Like the GetNodeInfo for nodes, a GetGpsInfo for gps (or a GetMagInfo for mags, a …)(even though there is no use currently for a GetMagInfo, but conceptionally thinking). To me it is also clear that its content would be very device dependent, and thus not suitable to a standardization (except of having such a message).

To me it is, btw, also clear that it would be better to have a device-dependent Gps broadcast, and not a fixed standard message … it’s likely to get too narrow quickly (there is already fix and fix2, even though there is just one uavcan gps around ;)).

So, I guess I would do these as a variable length thing, there maybe the first field is a device specifier, like “Hey, it’s ArduPilot”.

But that’s just what seems clear to me. Anyone else me see that differently :).

Cheers, Olli

4

I welcome you to read the archives of ArduPilot CANBUS Gitter channel. We already discussed with Pavel about standards not working and that would be nice to have UART/SPI/I2C protocols working over UAVCAN, but that’s not his vision.

Your ideas involve UAVCAN changes and that’s not run by ArduPilot, so you need to discuss it with the team behind the UAVCAN protocol :wink:

5

The easy version is to make a UAVCAN parameter and attempt to fetch it from ArduPilot.

I assume you came across it since you found get_lag(), but if the user provides a parameter value to ArduPilot it overrides the backend. It would still be best to be able to fetch it automatically though :slight_smile:

6

@oxinarf:

ha … I actually added this additional “BTW” comment only because I had seen the discussion on gitter, and grabbed the opportunity here to expose my opinion … for the good or bad you guys will decide

EDIT: I know that this would imply changes to ArduPilot, obviously. But, you were asking me for my ideas, right :D. I’m not sure if the situation is such that I have to discuss that with the uavcan devs … maybe the uavcan devs want to discuss that among themselves ?!? :). From my side what is relevant is to know that the uavcan gps should eventually get a get_lag() function.
I’ve read your statement incorrectly and thus gave a nonsense answer, sorry. The answer to your point should be:
I think I disagree. Uavcan - at least in my understanding consists of two independent layers, which I’d like to call protocol layer and message layer. I think uavcan has been very well defined in that regard (in contrast to mavlink LOL). This means: Whatever vision anyone may have for the messages, anyone other is free to use whatever messages they want, the uavcan protocol supports that. So, I disagree, because it’s a thing only to be discussed among the ArduPilot devs, and not the UAVCAN devs, and it only involves changes to ArduPilot, but not UAVCAN. IMHO.

@WickedShell
since all that is in an early, flowing stage anyhow, I’m always of the opinion not to start with a tweak but to get it conceptionally right

all that are just my 2 cents

7

@olliw42 I’m onboard with doing it right :slight_smile: I was just pointing out the workaround (if it was an immediate issue), and the parameter one is an approach. It’s not the best one, but it does seem like a way to allow the autopilot to control remote GPS settings. It does seem like a dirty approach though.

8

well, I didn’t wanted to say that it is not the best thing, it - IMHO - eventually might actually turn out to be the best thing ! … I didn’t express myself well, sorry … I guess what I was trying to say was that one maybe wouldn’t want to jump into implementing something without evaluation … I think your idea isn’t bad at all

9

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.

10

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”

11

@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.

12
  • this had been just my 2 cents :slight_smile:
  • I think if it’s good what you’re doing, hardware makers will follow
  • you can do both, work with uavcan (which is obviously a good thing!) and do you’re own thing (why else would a standard have vendor specific definitions?)
  • not sure if you note the logical trap you are in, you can’t have “standard” and “specific” at the same time
  • as much as I can see, your desire to standardize everything for any specific device has bogged you down instead of liberated you (you = AP), the gpses are just going to be the next example, IMHO.

Anyway, this is a bit of a degression from the main topic, right :slight_smile:

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.

:slight_smile:

13

You’ve made an excellent post for Pavel :wink:

14

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.

15

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. :slight_smile:

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. :slight_smile:

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 :smiley:

16

@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.

17

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

18

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.

19

[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.

20

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).