ardupilot: add messages to configure ADSB and provide vehicle info #48
Conversation
There was a problem hiding this comment.
I don't see squawk anywhere? 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.
| uint16 EMERGENCY_UNLAWFUL_INTERFERANCE | ||
| uint16 EMERGENCY_DOWNED_AIRCRAFT | ||
| uint16 EMERGENCY_RESERVED | ||
| uint16 emergency # enumerated |
There was a problem hiding this comment.
Shouldn't this be in the VehicleStatus? Some of these seem like something the aircraft might conceivably want to flag on it's own, such as minimum fuel, no comm, or downed? We can't change that on the fly without resending many of the config parts here, that could notionally be coming from a GCS.
I'm also a little worried that some transponders require asserting a pin into a configuration mode to change some of these parameters. (positions/offsets/callsign/icao id), which probably shouldn't be done mid flight ever, but others like flight id, rf select, squawk and emergency are completely valid to toggle all the time/whenever.
peterbarker
force-pushed
the
pr-spektreworks/my-loc-in-frontend
branch
from
8a92b90
to
35a62be
Compare
My bad. It was in multiple places and it was a "do this later" thing which didn't get done. I've added "squawk".
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. |
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. |
|
|
||
| uint8 STATE_AUTOPILOT_ENABLED = 0 | ||
| uint8 STATE_ON_GROUND = 1 | ||
| uint8 state # bitmask |
There was a problem hiding this comment.
Do we need airspeed and heading in here?
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.
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. |
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.
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. |
low rate and on-change.
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? |
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. |
WIP