log.flights drone flight planning and logging service

log.flights is an open source web service for planning, logging, and reporting on drone flights. In the interest of promoting a safety culture in drone aviation, log.flights provides open reporting tools for public transparency in operations. Drone operators can jointly see planned and completed flights, understanding who else is operating in the area and learning from each other's operations.

To run the log.flights code on your local development machine, you'll need to install the requirements and then set up the Django application.

You will need Python and related tools installed:

• Python 3.6 (pyenv is useful if you need to run multiple versions, Python2 is not supported)
• PIP
• VirtualEnv: pip install virtualenv

Libraries:

• Libmagic

And services:

• Redis
• SQLite
• PostgreSQL (optional)

Uploads and documents are stored with Google Cloud Storage. See the section below for setting local settings

Enter a new virtualenv and install application dependencies.

virtualenv <name>
<name>/bin/pip install -r requirements.txt

You'll need credentials for a Google Cloud service account stored in a JSON file. Store the JSON file somewhere securely on your system, such as ~/.google.

Set the GOOGLE_APPLICATION_CREDENTIALS environment variable to point to the JSON file.

export GOOGLE_APPLICATION_CREDENTIALS=~/.google/creds.json

Settings that are specific to your deployment should be set in logflights/local_settings.py. This file will not exist, you should create it. It is imported as a standard python file. Common things to include in this file are:

SITE_NAME='log.flights'
GOOGLE_MAPS_API_KEY = 'YOUR_GMAPS_KEY'
SENDGRID_API_KEY='YOUR_KEY'

You'll also need to know the name of the GCS bucket to use for development. The app includes a default test bucket, logflights_data_test. To use a different bucket, also set environment variable GS_BUCKET_NAME.

Set up the database by running migrations, adding fixtures for default data, and collecting static files:

<name>/bin/python manage.py migrate
<name>/bin/python manage.py loaddata --app planner manufacturers missions
<name>/bin/python manage.py collectstatic

Add an admin user:

<name>/bin/python manage.py createsuperuser

Then run the development server:

<name>/bin/python manage.py runserver

In a separate window, run celery to process asynchronous tasks:

<name>/bin/celery -A logflights worker -l info

Log into the admin console and set up default fields:

http://127.0.0.1:8000/_/admin/

cd frontend/ && yarn

cd frontend/ && yarn run dev

App will run at:

http://127.0.0.1:3000

Update the files in frontend/.env.production and frontend/env.local with your Google Analytics tracking ID.

Example:

GOOGLE_ANALYTICS_TRACKING_ID=UA-Example-1

cd frontend/ && yarn run lint

or lint staged files only

cd frontend/ && yarn run lint:staged

cd frontend/ && yarn run test

• terms-of-service.md and privacy-policy.md are loaded by webpack markdown loader from frontend/app/static

log.flights allows the upload of flight plans (waypoints) and flight telemetry.

Supported formats:

• QGroundControl/MissionPlanner TEXT waypoint files ending in .waypoints
• QGroundControl JSON waypoint files ending in .plan
• Keyhole Markup Language / Google Earth documents .kml and .kmz

Supported formats:

• APM binary logs (.BIN, often stored on an SD card on the drone)
• Mission Planner telemetry logs (.tlog)
• PX4 / QGroundControl logs (.ulog)
• DroneDeploy logs (.log or .txt)
• Airdata CSV log exports (.csv) – do not use .kml export, it doesn’t support TimeSpan.
• Keyhole Markup Language / Google Earth documents (.kml and .kmz)

NOTE: We highly discourage using .kml/.kmz documents for telemetry logs. They lack much of the critical information found in telemetry logs. Only .kml/.kmz files with TimeSpan elements supplied are accepted; .kml/.kmz files without TimeSpan elements will be rejected as unsupported file types.

log.flights is licensed under the BSD 3-clause license.

This project was started by Altiscope, part of A³ by Airbus.