mirror of
https://bitbucket.org/librepilot/librepilot.git
synced 2024-11-30 08:24:11 +01:00
71 lines
2.7 KiB
Plaintext
71 lines
2.7 KiB
Plaintext
------- TELEMETRY ---------
|
|
The Telemetry system has been implemented, and is composed of a few
|
|
major components:
|
|
|
|
Telemetry.java - receives command to transmit objects through telemetry and
|
|
also emits notification when transactions are completed
|
|
|
|
TelemetryMonitor.java - monitors the FlightTelemetryStats and GCSTelemetryStats
|
|
to establish when a working connection is in place. Also initiates downloading
|
|
all the objects on a new connection.
|
|
|
|
UAVObjectManager.java - the central data store. The data is actually stored
|
|
within objects, but this maintains the handles to all of them.
|
|
|
|
UAVTalk.java - the actual communication layer. Can packetize an object and
|
|
insert into stream and process the incoming stream and update objects
|
|
accordingly.
|
|
|
|
** Threading
|
|
Currently object updates run within the thread of the function that called
|
|
update. This should be changed so that it adds a message to the Telemetry
|
|
thread which will then send on its own time.
|
|
|
|
---- MESSAGE PASSING ----
|
|
The current implementation/analog to the slots/sockets in QT are Observers
|
|
which are registered as added to an Observable. This is used extensibly within
|
|
the telemetry system. I will continue to use this _within_ the Telemetry
|
|
module so it doesn't depend on any android features.
|
|
|
|
In android there is a constraint that UI operations should all be done from the
|
|
UI thread. The most common way to do this is for the UI object (such as
|
|
Activity) to instantiate a Handler to which messages or runnables are posted.
|
|
|
|
So for external objects they will register a runnable somehow...
|
|
|
|
--- TELEMETRY SERVICE ---
|
|
The telemetry connection will be maintained by a service separate from the the
|
|
main activity(s). Although it is a bit unusual, the service will support being
|
|
started and stopped, as well as being bound. Binding will be required to get
|
|
access to the Object Manager.
|
|
|
|
In addition, to make it forward looking, the start intent can specify a
|
|
connection to open. This will allow the service in future to monitor multiple
|
|
connections.
|
|
|
|
The service will destroy itself only when all active connections disappear and
|
|
all activies are unbound.
|
|
|
|
It will also handle any logging desired (I think).
|
|
|
|
There will be a primary message handler thread. This thread will separately
|
|
launch telemetry threads when required.
|
|
|
|
The service should send broadcast intents whenever a connection is estabilished
|
|
or dropped.
|
|
|
|
I dont think the service should have the options about which UAVs are
|
|
supported.
|
|
|
|
** Telemetry IBinder
|
|
*** Give handle to the ObjectManager for each UAV
|
|
*** Call disconnect
|
|
*** Query conncetion status
|
|
|
|
--- TELEMETRY WIDGET ---
|
|
Listens for conncet/disconnect intents
|
|
|
|
Also show if service is running?
|
|
|
|
Ability to launch service?
|