Using: Kx kdb+ in-memory time-series database for data processing, streaming and storage
Scikit-learn (Gaussian Process Regression, Linear Regression), ensemble learning (Adaboost, XGBoost) and Extreme Learning Machines regression models to model flight physics
Keras/tensorflow LSTM model for time-series throttle prediction, trained by synthesized data from regression models
Kx developer, Tableau and Tibco Spotfire dashboards are connected to kdb for additional data filtering, visualisation and analysis. Connectivity through q websocket and ODBC.
Application hosted in cloud on #DigitalOcean for high availability. CPU intensive ML training is executed on a temporary, high-spec instance during batch training. Database and model deployment are deployed on a separate cost-effective instance. Module communications implemented using q IPC.
Live Prediction on Streaming Telemetry (Video Demo): https://youtu.be/7xETmWG2jyI
Tableau Connected to cloud kdb server (Video Demo): https://youtu.be/-vmvTTZp8GE
Application written in Python and q/kdb. Test version hosted at http://renxiang.cloud/OHR400Dashboard
q server process that acts as the database (RDB and HDB). Historical and real-time flight telemetry and Rolling Launch Control data is streamed and retrievable from this process. Hosted at renxiang.cloud.
Interfaces using q IPC, ODBC and websockets. (Requires authentication).
Kx Developer is active if 64bit server is in use.
Requires 32bit or 64bit KDB (requires cloud permission)
Tableau (live data refresh) and TIBCO Spotfire Analyst (manual data refresh) have been successfully connected to this server instance using ODBC.
See screenshots in Git Repository for useful dashboard views.
- To run:
#64 bit version
./FASServer.sh
Alternatively
#64 bit version
nohup q FASServer64bitInit.q -U credentials.txt> nohupServer.out & tail -f nohupServer.out
#32 bit version
nohup ~/q/l32/q FASServer32bitInit.q -U credentials.txt> nohupServer.out & tail -f nohupServer.out
A simple web interface (index.php) allows flight data (GPS and PID csv files generated by Betaflight blackbox tools) to be uploaded to the server.
Once the csv files are uploaded, a simple PHP script detects the number of features in each csv file. A manifest of the uploaded logs and its feature counts are stored into a new csv file called logsManifest.csv.
The web interface has a websocket connection to the kdb server (requires user authentication) that will then call the FASUpdate.q script to read logsManifest.csv file and enlist all the csv logs into kdb.
An as-of join is then conducted on the GPS and PID flight logs (required as GPS data is sampled ~ 5Hz and PID data sampled ~ 2KHz). With the joined data, qsql queries are used to generate a new table (trainingData) that contains features selected for the machine learning model training.
q client process that reads flight data from the kdb server to train ML pipeline implemented in it.
The ML pipeline consists of 3 cascaded models.
2 regression models that predict GPS speed and battery voltage respectively are first trained.
The physics of the UAV and its battery limitations are effectively modelled by the regression models after training.
By crossfeeding the historical flight data between the two trained regression models, with an artificial time increment of 1 time period (0.2s, based on GPS speed refresh rate) between each crossfeed step, an expanding combination of possible future flight data is synthesized.
The synthesized data is arranged in a B-tree and the top 20% throttle sequences, based on final GPS speed, is selected using q-sql.
These throttle sequences are then transformed into a sliding window table in kdb and used to train the LSTM model.
The trained LSTM recognises the latest throttle input received by the UAV and generates the optimal throttle pattern for the next 2 seconds to maintain the highest GPS speed without overexerting the limits of the battery.
This trained LSTM model is used in the deployment of the Rolling Launch Control feature of the UAV.
When the LSTM model is done training, the script will save and transfer the trained model to the kdb server for storage over SFTP.
- To run:
rlwrap q FASMLTrainingClientInit.q
Python client that acts as the streaming telemetry interface between the UAV and kdb server.
It reads Mavlink telemetry data from the USB UAV telemetry radio attached to the local machine and streams it to the server using q IPC.
Requires qPython. Recommended to run on local machine with 3DR telemetry radio attached.
- To run:
python FASMavlinkInput.py
q client process that reads the latest 2 mins of flight data from the kdb server and generates Rolling Launch Control output for the UAV. The generated throttle sequence is streamed back to the server.
Under the hood, a trained keras LSTM model generates the output from the latest throttle data.
Requires 64 bit KDB and embedPy. Recommended to run on local machine with Tensorflow/CUDA.
- To run:
nohup q FASServerInit.q > nohupLaunchControlClient.out & tail -f nohupLaunchControlClient.out
Python client that subscribes to throttle sequence generated by the launch control client on kdb server.
Requires 64 bit kdb and embedpy running on local machine, with USB interface to UAV control link.
- To run:
python FASLaunchControlOutput.py
q client process that streams historical UAV flight logs and training data logs into the server to test client applications that require streaming telemetry input. Simulates Mavlink telemetry sent back by the UAV.
IPC functions are defined on kdb server side.
Requires 32 or 64 bit kdb.
- To run:
rlwrap q FASLogPlayback.q
- Effectively free up reserved, non-essential memory usage after ML model training/deployment
- Rewrite explicit Python variable deletion to work on negative checking. Delete if object is not:
- Python system variable
- variable inserted by q script
- module imported
- Update log upload portal to tag logs with weather conditions during flight
- When running log playback, automatically flush RDB to HDB, purge RDB for incoming telemetry playback
- Create additional bash scripts to launch customised q processes based on operating system and kdb version
- Creation of flight engineering dashboard with Kx Dashboards Direct
- Integration of kdb+ AutoML plugin
- Implement cross validation testing during training for GPS speed and LiPo voltage prediction models
- Implement transfer learning for LSTM to reduce subsequent training time and improve general accuracy from training with old and new telemetry data where applicable
- Further refine Rolling Launch Control ML training methodology
- Improve ML model deployment pipelinei
- Implement option to use plaidml backend for keras, to allow LSTM training using OpenGL with integrated or AMD GPU, if CUDA is not available
- Implement Convolutional Neural Network to recognise scenario occurrences on dimensionality reduced flight data
- Integrate vanilla kdb ticker plant
- Improve feature engineering and selection capabilities with usage of more FRESH utilities
- Call 'del' on python objects not in use (especially during data synthesis and after model training is completed) to reduce Python memory bloat
- Update Tableau Dashboards view with more views useful for real-time flight engineering
- Switch to OpenFOAM for CFD work, with kdb integration for timestep logging
- Switch from manual CAD to machine-learning based generative design CAD with CFD to generate semi-optimal aerodynamic bodywork
- Deploy application as docker container
- Automate instance deployment, ML model archiving and instance teardown when retraining Rolling Launch Control on new data.