[uss_qualifier/monitorlib] Support new flight_planning API fields#1373
Conversation
| * `Ground`: The aircraft is reporting status but is not airborne. | ||
| * `Airborne`: The aircraft is, or should be considered as, being airborne. | ||
| * `Emergency`: The aircraft is reporting an emergency. | ||
| * `Unknown`: The system supports acquisition of knowledge about the status of the aircraft, but the status cannot currently be determined. |
There was a problem hiding this comment.
The RID standard has a value RemoteIDSystemFailure, from the description I assume this falls into this Unknown case. If so, document this here out of clarity?
There was a problem hiding this comment.
The immediate reason this enum doesn't have RemoteIDSystemFailure is because the flight_planning API doesn't have RemoteIDSystemFailure. I don't remember a reason why this option would have been intentionally omitted from the API, so I'll add it here to the internal representation and consider adding to the flight_planning API as well.
There was a problem hiding this comment.
When adding an option, I think I may have remembered: these states are supposed to be general to the flight (flight_planning) and the remote ID system specifically having a failure is hard to fit into that paradigm -- presumably remote ID subsystem failure would be reported/specified in another part of the flight description defining subsystem functionality. I've sidestepped this for now by extending this option more broadly to a failure regarding the reporting/telemetry system. This should be applicable to flights in general, and could potentially be used directly for remote ID testing.
2 participants
The InterUSS flight_planning API somewhat recently added some additional fields to the flight plan object. This PR adds that information to the business objects of monitorlib's flight_planning client. These are intentionally duplicated (for now) to allow the API definition and internal representations to diverge (same style as the rest of flight_planning).