ardupilot: add messages to configure ADSB and provide vehicle info

[peterbarker]

WIP

[peterbarker]

I don't see squawk anywhere?

My bad. It was in multiple places and it was a "do this later" thing which didn't get done. I've added "squawk".

And I have a bit of a concern over having to send a full emitter config which on some hardware requires actually shorting a pin to ground in order for the transponder to take the command, and doesn't really make sense to resend that full config message when changing smaller bits of state.

The two messages suggested here are basically high-rate/low-rate, rather than "configure" and "status" as I've named them. The naming is general intent rather than anything else, and naming them HighRate and LowRate seems wrong....

I was imagining we might push the low rate message maybe every 10 seconds or when fields change, that sort of thing, and the higher-rate message at maybe 10Hz.

I was imagining that the AP_Periph device would be storing all of this information for passing to the device as required.

AFAICS a directly-attached MXS gets this same information at intervals, rather than on command. So when you press the button I expect it's writing to persistent storage data which it's already received.

In terms of "smaller bits of state", I don't think we want to have too many messages here - there's a flash and memory cost for each type of message we send/receive.

[WickedShell]

AFAICS a directly-attached MXS gets this same information at intervals, rather than on command.

This is rather more of a bug rather then a good thing. Particularly the installation message shouldn't be sent out like that. Point of fact is that on that hardware if you haven't grounded a physical pin on the device to put it in maintenance mode the message isn't even accepted. If it's going to ignore the message anyways we shouldn't be sending it.

In general I agree about having to generally mirror information out at different rates. Somestuff you have in the low rate message feels much more high rate to me (ie squawk/callsign/transmit modes/emergency), but as long as we push it out upon change (and maybe slightly faster after it changes) then I'm fine with it.

[peterbarker]

AFAICS a directly-attached MXS gets this same information at intervals, rather than on command.

This is rather more of a bug rather then a good thing. Particularly the installation message shouldn't be sent out like that. Point of fact is that on that hardware if you haven't grounded a physical pin on the device to put it in maintenance mode the message isn't even accepted. If it's going to ignore the message anyways we shouldn't be sending it.

This is true, but having it sent constantly - even at a very low rate - means that to configure the hardware-locked parameters is just a matter of shorting the pin, and doesn't require any further co-operation from the flight controller. Further, this is more of a device-agnostic approach to the problem. Sending the callsign once every 5 or 10 seconds (or whenever the data changes) shouldn't break the bank.

In general I agree about having to generally mirror information out at different rates. Somestuff you have in the low rate message feels much more high rate to me (ie squawk/callsign/transmit modes/emergency), but as long as we push it out upon change (and maybe slightly faster after it changes) then I'm fine with it.

Yes, I was thinking it would get pushed out on change. CAN's delivery mechanism should mean it doesn't need to be sent at a higher rate to guarantee delivery, but that could be done, of course.

In the particular task we're looking at the location, cog and ground-relative velocities are expected to come from the FIX2 message. Should we omit them from this message? That has the unfortunate consequence that if your GPS is serially-connected to the flight controller the ADSB unit wouldn't have all the information it requires. Perhaps this should be configured on the peripheral.

[WickedShell]

In general I agree about having to generally mirror information out at different rates. Somestuff you have in the low rate message feels much more high rate to me (ie squawk/callsign/transmit modes/emergency), but as long as we push it out upon change (and maybe slightly faster after it changes) then I'm fine with it.

Yes, I was thinking it would get pushed out on change. CAN's delivery mechanism should mean it doesn't need to be sent at a higher rate to guarantee delivery, but that could be done, of course. It could get lost of course, but since we should be sending out a new message pretty rapidly if you are content to always broadcast it then I can be convinced it will work, without any real noticeable problems.

Not sure I'm following, would this be both low rate and on change, or just on change? If it's just on change then there's a decent chance to drop it, if you are looking at both then I agree it will be enough to keep the system feeling setup correctly.

In the particular task we're looking at the location, cog and ground-relative velocities are expected to come from the FIX2 message. Should we omit them from this message? That has the unfortunate consequence that if your GPS is serially-connected to the flight controller the ADSB unit wouldn't have all the information it requires. Perhaps this should be configured on the peripheral.

I'm not quite following here. I'm looking at the exact setup you've described of the GPS being serially connected to the flight controller, and having the flight controller broadcast the information. Notionally I'd think we'd want to rate limit this though, if we are running 10Hz GPS we don't necessarily need to be updating the ADS-B as fast. Although it wouldn't be terrible if we did.

[peterbarker]

Not sure I'm following, would this be both low rate and on change, or just on change? If it's just on change then there's a decent chance to drop it, if you are looking at both then I agree it will be enough to keep the system feeling setup correctly.

low rate and on-change.

In the particular task we're looking at the location, cog and ground-relative velocities are expected to come from the FIX2 message. Should we omit them from this message? That has the unfortunate consequence that if your GPS is serially-connected to the flight controller the ADSB unit wouldn't have all the information it requires. Perhaps this should be configured on the peripheral.

I'm not quite following here. I'm looking at the exact setup you've described of the GPS being serially connected to the flight controller, and having the flight controller broadcast the information. Notionally I'd think we'd want to rate limit this though, if we are running 10Hz GPS we don't necessarily need to be updating the ADS-B as fast. Although it wouldn't be terrible if we did.

I was assuming some form of certified GPS on the CAN bus, rather than something coming via (and possibly being interpreted by) the autopilot. Never mind.

But back to the question, then. Should we be including GPS information in the high-rate message if the same information is expected to be on the bus in FIX2? Same now seems to be true of magnetic heading and perhaps airspeed data. Perhaps we include the data in the new VehicleStatus but the device could choose to rely on FIX2?

[WickedShell]

But back to the question, then. Should we be including GPS information in the high-rate message if the same information is expected to be on the bus in FIX2? Same now seems to be true of magnetic heading and perhaps airspeed data. Perhaps we include the data in the new VehicleStatus but the device could choose to rely on FIX2?

I think my current thought is that Fix2 gets ambigous which GPS it should be using in the ADS-B out (IE think of multiple GPS's on the CAN bus). And in some cases (such as mine) we were only going to put a Fix2 message out to get the data to the ADS-B system anyways. This steers me a bit towards putting it all in a single status message for now, and if we want to add option bits to not use that later it's fine.