Yes, it seems the control system isn't real-time anyway, so this discussion is moot. But to answer your question:

A real-time system can still have inputs that can not be guaranteed, and internal processes can have an upper and lower bound for their execution time. So a result would be late if either:

  1) $T_{input} + t_{process_min} > T_{deadline}$
  2) $T_{input} + t_{process_actual} > T_{deadline}$

(where $T$ is a timestamp given by some time source and $t$ is process duration). Condition 1 can be determined on arrival of the data, and the input can be discarded immediately. Condition 2 cannot be determined beforehand, but if the processing isn't finished at $T_{deadline}$, the process/thread could be killed without waiting for it to complete.

Of course, this requires that an accurate deadline can be determined for each input packet. The textbook use case is for rendering live video streams, where stream latency is more important than rendering each frame accurately. This flight control system is a similar use case, since the utility of the camera feed for determining location or drift rapidly declines as the picture ages.

But if the timestamp-keeping isn't accurate as it seems in this case, it really doesn't matter if the system was real-time or not.