Drone Flight Log Database Fields Telemetry Battery Swap Geotagged Images

A drone flight log database is more useful than a simple record of where a drone flew. A well-designed system connects the flight itself with time-series telemetry, battery identity and swap events, camera activity, geotagged images, operator information, mission data, and the original source logs.

The most important design decision is to avoid putting everything into one enormous flight table. Telemetry is naturally a stream of measurements, while a battery replacement or photograph is an event that happens at a particular point in that stream. Treating those as separate but related entities produces a database that is easier to query, audit, analyze, and extend.

This approach also reflects how real flight systems record information. PX4 uses ULog for system and flight data, while ArduPilot distinguishes between onboard DataFlash logs and ground-station telemetry logs. MAVLink messages expose structured information for position and battery status, and image metadata standards such as EXIF provide standardized fields for image time and GPS information.

What should a drone flight log database actually store?

At minimum, the database should answer six questions:

1. What flight was this?
2. Which aircraft, controller, operator, and mission were involved?
3. What was the drone doing over time?
4. Which battery was installed, and when was it changed?
5. Which photographs or other payload events happened during the flight?
6. Where and when did each image originate?

A practical architecture therefore separates the data into several linked areas:

Data area	Typical purpose
Flight record	Identifies the overall operation
Aircraft record	Stores the drone’s identity and configuration
Mission record	Describes the planned job or route
Telemetry samples	Stores time-stamped aircraft state
Battery inventory	Identifies individual battery packs
Battery events	Records insertion, removal, swap, charging or fault events
Camera/image records	Connects media to a flight and capture event
Geospatial data	Stores coordinates, altitude and geometry
Source-file metadata	Preserves the original log or image provenance
Audit/system metadata	Tracks ingestion, processing and corrections

This separation is important because one flight can contain thousands or millions of telemetry points, several batteries, and hundreds or thousands of photographs.

Why telemetry deserves its own table

Telemetry means the continuously changing information reported by the aircraft and its systems.

Depending on the flight stack and hardware, that can include position, altitude, velocity, heading, attitude, GPS information, battery measurements, sensor data, system status, and other internal states. PX4 describes its ULog format as a self-describing logging format capable of recording sensor inputs, internal states, and messages. ArduPilot similarly records detailed onboard data and can also create telemetry logs at the ground station.

For a database, the central telemetry table could look conceptually like this:

Field	Example type	What it means
telemetry_id	UUID	Unique telemetry record
flight_id	UUID	Flight this sample belongs to
timestamp_utc	Timestamp	Normalized absolute time
time_since_boot_ms	Integer	Original vehicle-relative timestamp, when available
latitude	Decimal	Aircraft latitude
longitude	Decimal	Aircraft longitude
altitude_msl_m	Decimal	Altitude relative to mean sea level
altitude_relative_m	Decimal	Altitude relative to the home point
ground_speed_mps	Decimal	Horizontal speed
vertical_speed_mps	Decimal	Vertical speed
heading_deg	Decimal	Aircraft heading
gps_fix_type	Integer/enum	Positioning solution type
horizontal_accuracy_m	Decimal	Estimated horizontal uncertainty
vertical_accuracy_m	Decimal	Estimated vertical uncertainty
battery_id	UUID	Battery associated with the sample
battery_voltage_v	Decimal	Pack voltage
battery_current_a	Decimal	Current
battery_remaining_pct	Decimal	Reported remaining energy
battery_temp_c	Decimal	Battery temperature
source_message	String	Original message/topic/log field
source_sequence	Integer	Original sequence or sample number

The exact set of fields should depend on what the flight controller actually provides. For example, MAVLink’s GLOBAL_POSITION_INT contains time since boot, latitude, longitude, altitude, relative altitude, velocity, and heading, while its BATTERY_STATUS message includes battery ID, temperature, cell voltages, current, consumed charge, remaining percentage, charge state, mode, and fault information.

Do not store latitude and longitude without time

A coordinate by itself is rarely enough for flight analysis.

Suppose a drone flew over a construction site for 28 minutes and recorded 300 photographs. A row containing only latitude and longitude tells you almost nothing about when the aircraft was there. Adding a timestamp makes it possible to reconstruct the flight path and associate other events with the same point in time.

That is why the logical key for telemetry is closer to:

flight + timestamp + source

than simply:

flight + location

For systems with very high sample rates, a numeric sequence or source timestamp can also be useful for preserving the original ordering.

The timestamp problem is more important than it looks

One of the easiest ways to create incorrect drone data is to assume that every timestamp uses the same clock.

MAVLink messages can use a time-since-system-boot field, while PX4 records both a logger timestamp and, in some messages, a sample timestamp. EXIF image metadata, meanwhile, can contain camera-oriented date/time and GPS date/time fields. These clocks are not automatically interchangeable.

A production database should therefore preserve at least two concepts:

• Original timestamp: exactly as supplied by the source system.
• Normalized timestamp: the application’s best conversion into a common timeline such as UTC.

For example:

time_since_boot_ms = 842356
timestamp_utc      = 2026-08-28T14:31:42.356Z
timestamp_source   = MAVLink
clock_domain       = flight_controller_boot

The exact conversion depends on the source and the available clock relationship. Do not silently manufacture absolute time when it cannot be established.

A useful additional field is:

time_quality

with values such as:

• exact
• synchronized
• estimated
• unknown

That single field can prevent later analysts from treating an approximate image/telemetry match as exact evidence.

Battery swaps need their own event model

Battery management is where many otherwise sensible drone databases become too simplistic.

A flight may begin with one battery and continue after another battery is installed. A simple battery_id column on the flight record cannot accurately represent that situation.

Instead, maintain a battery inventory table and a battery event table.

Battery inventory

The battery table identifies the physical pack:

Field	Purpose
battery_id	Internal database identifier
serial_number	Manufacturer or smart-battery serial
manufacturer	Battery manufacturer
model	Battery model
chemistry	Chemistry/type when known
rated_capacity_ah	Nominal capacity
design_capacity_mah	Design capacity when supplied by the system
full_charge_capacity_ah	Current estimated full capacity, when available
cell_count	Number of cells
purchase_date	Asset-management information
status	Available, maintenance, retired, etc.

MAVLink’s current battery definitions are a useful example of why these fields matter. BATTERY_INFO can describe battery identity and static characteristics such as serial number, name, number of cells, design capacity, full-charge capacity, discharge limits, and manufacture date, while BATTERY_STATUS is intended for frequently changing battery information.

Battery event table

Then model what happened to the battery:

Field	Purpose
battery_event_id	Unique event
flight_id	Related flight
battery_id	Physical battery
event_type	Inserted, removed, swap, fault, etc.
event_time_utc	Time of the event
telemetry_time	Original source time
battery_state_before	Optional pre-event state
battery_state_after	Optional post-event state
location	Where the event occurred, if known
operator_id	Person performing the action, when relevant
source	Telemetry, manual entry, maintenance system, etc.
confidence	Confidence that the event reconstruction is correct

This distinction is crucial:

Battery telemetry tells you about battery state. A battery event records a physical lifecycle action.

A flight controller may report a battery identifier and changing battery status, but that does not automatically mean the logging system has captured a formal “removed at 14:22:13 and replaced at 14:23:01” event. The application should create such an event explicitly when reliable evidence exists.

Why the battery serial number matters

A battery serial number changes the database from a generic energy log into an asset-history system.

You can then ask questions such as:

• How many flights used battery B-1047?
• How much reported charge was consumed?
• How often did it appear in high-temperature conditions?
• When was it last used?
• Did a fault occur repeatedly with the same pack?
• Which aircraft have used that battery?
• What was its reported health or capacity over time?

Those questions are difficult or impossible to answer reliably if all battery information is stored only as anonymous percentages.

Battery percentage is not enough

A field such as battery_remaining_pct = 22 looks simple, but it should not be treated as a universal measure of physical capacity.

MAVLink defines battery remaining as an energy percentage reported by the autopilot, and marks it unavailable in cases where the autopilot does not provide an estimate. Its battery status messages also distinguish between voltage, current, consumed charge, energy consumed, remaining energy, temperature, charge state, mode, and faults.

A stronger database therefore stores the measurements separately:

battery_voltage_v
battery_current_a
battery_remaining_pct
current_consumed_mah
energy_consumed_hj
battery_temperature_c
battery_charge_state
battery_fault_mask

Do not convert one into another unless the source system explicitly defines that conversion.

How to store geotagged drone images

A geotagged image is a photograph associated with geographic coordinates, usually through metadata or an external matching process.

EXIF, the metadata format commonly used by digital cameras, includes dedicated GPS fields. The current CIPA standards page lists the 2026 revision of EXIF Version 3.1, published January 30, 2026. EXIF GPS metadata includes latitude, longitude, altitude, GPS time, GPS date, GPS status, positioning information, image direction, and other related tags.

That means an image table might contain:

Field	Purpose
image_id	Unique image
flight_id	Flight in which it was captured
capture_time_utc	Normalized image capture time
capture_time_original	Original camera timestamp
latitude	Image capture latitude
longitude	Image capture longitude
altitude_m	Image-associated altitude
heading_deg	Camera or aircraft direction, if known
gps_accuracy_m	Position accuracy, if known
camera_id	Camera or payload identifier
file_name	Original file name
mime_type	Image type
width_px	Image width
height_px	Image height
sha256	Cryptographic file hash
object_uri	Location of original media
metadata_status	Complete, partial, missing, corrected
geotag_source	Embedded EXIF, telemetry match, camera log, etc.

Store the image location and the aircraft location separately

This is an important detail.

The aircraft’s position at the time of capture is not always identical to the point represented by the photograph. The camera may be mounted away from the aircraft’s navigation reference point, and a gimbal-mounted camera can point in a direction different from the aircraft’s heading.

For basic drone mapping, aircraft position may be a useful approximation. For higher-accuracy work, the database should preserve the distinction between:

aircraft position

and

image/camera position

A more advanced payload model can therefore include:

aircraft_latitude
aircraft_longitude
aircraft_altitude
camera_latitude
camera_longitude
camera_altitude
camera_heading
camera_pitch
camera_roll
gimbal_yaw
gimbal_pitch
gimbal_roll

Only populate fields that the hardware and logging system actually measure.

How images are matched to flight telemetry

There are two common approaches.

Camera trigger events

The first is to record a camera-trigger event in the flight log and associate the event with a particular frame or filename.

ArduPilot documents a workflow in which camera-trigger information in the DataFlash log can be used to add accurate geotag information to images.

This approach is often preferable because the log contains a direct record of when the camera was triggered.

Timestamp matching

The second approach is to match the image’s timestamp to the nearest point in the flight log.

ArduPilot also documents a method that uses the difference between the camera clock and the system clock to determine where in the flight log an image was captured.

A database implementation should record how the match was made, not just the final coordinates.

Useful fields include:

geotag_method = "camera_trigger"

or

geotag_method = "timestamp_interpolation"

along with:

time_offset_ms
matched_telemetry_id
match_error_ms
position_quality

That makes the result auditable.

Why interpolation is often better than nearest-point matching

Imagine telemetry is recorded every 200 milliseconds and a camera captures an image between two telemetry samples.

Choosing the closest sample may introduce a small positional error. A better processing pipeline can use the samples immediately before and after the image timestamp and interpolate where appropriate.

For example:

Telemetry A: 14:31:42.200  → position A
Telemetry B: 14:31:42.400  → position B
Image:       14:31:42.350

The database does not need to pretend that the drone was actually recorded at exactly 14:31:42.350 by the flight controller. Instead, it can store the original observations and separately store the derived image position together with the method used to derive it.

That preserves the difference between measured data and processed data.

Do not overwrite original metadata

One of the strongest design rules for a professional drone data system is:

Never replace the original file metadata with your corrected interpretation.

Suppose an image contains no GPS coordinates but the flight log allows you to determine where it was captured. Store:

embedded_gps = NULL
derived_gps = POINT(...)
geotag_method = "timestamp_interpolation"

rather than pretending that the camera originally wrote the GPS coordinates into EXIF.

The same principle applies to timestamps.

Keep:

original_capture_time
normalized_capture_time
time_correction_ms

rather than changing the source value and losing the evidence trail.

Source provenance is a first-class database field

A useful drone database should always be able to answer:

Where did this value come from?

A latitude could have come from:

• flight-controller telemetry,
• raw GPS measurements,
• a fused navigation estimate,
• camera EXIF,
• a geotagging algorithm,
• a manual correction,
• or another external system.

These sources are not equivalent.

PX4 explicitly distinguishes fused global position from raw GPS measurements; its VehicleGlobalPosition message describes the fused WGS84 estimate rather than the raw GPS sensor reading. MAVLink likewise distinguishes GPS_RAW_INT from GLOBAL_POSITION_INT.

A robust schema can therefore include:

source_system
source_component
source_file
source_message
source_field
source_timestamp
processing_version
derived_from

This becomes extremely valuable when a result needs to be investigated months later.

A practical relational schema

A clean starting design could use these tables:

aircraft
operators
missions
flights
telemetry_samples
batteries
battery_events
cameras
image_assets
camera_events
flight_source_files
processing_runs

The relationships would look roughly like this:

Aircraft ───────┐
                │
Operator ───────┼──> Flight ───> Telemetry Samples
                │       │
Mission ────────┘       ├──> Battery Events ───> Batteries
                        │
                        ├──> Camera Events
                        │
                        └──> Image Assets

The flight table becomes the parent record. High-volume telemetry stays in its own time-series-oriented table, while lower-frequency events remain compact.

Recommended fields for the main flight record

The flight itself should represent the operation, not every measurement.

A useful flight table might contain:

Field	Description
flight_id	Unique identifier
aircraft_id	Aircraft used
operator_id	Responsible operator
mission_id	Planned mission
start_time_utc	Flight start
end_time_utc	Flight end
takeoff_latitude	Launch position
takeoff_longitude	Launch position
landing_latitude	Landing position
landing_longitude	Landing position
flight_mode_summary	Recorded operating modes
distance_m	Calculated distance
duration_s	Calculated duration
max_altitude_m	Calculated maximum
max_speed_mps	Calculated maximum
log_format	ULog, DataFlash, TLog, vendor format, etc.
log_file_uri	Original log location
log_hash	File integrity hash
ingestion_time_utc	Database import time
processing_version	Parser/processor version
status	Complete, partial, failed, etc.

The final calculated fields should be marked as derived values, because they are analytics rather than raw observations.

The database should preserve both raw and derived information

Consider maximum altitude.

One system might calculate it from the reported relative-altitude field. Another might calculate it from altitude above mean sea level. A third might use an ellipsoidal altitude measurement.

Those values can legitimately differ because they describe different references.

MAVLink, for example, distinguishes altitude above mean sea level from altitude relative to the home position, while PX4’s global-position data can include both altitude above mean sea level and altitude above the ellipsoid.

The safest pattern is therefore:

raw_altitude
altitude_reference
derived_max_altitude
calculation_method

rather than one ambiguous field named simply altitude.

Use explicit coordinate reference information

Latitude and longitude should never exist without a clearly defined coordinate reference system when precision and interoperability matter.

PX4 documents its fused global position in WGS84, while modern geospatial formats such as GeoTIFF and GeoPackage provide standardized ways to describe coordinate systems and georeferencing.

For a conventional global drone database, fields could be stored as:

latitude_deg
longitude_deg
crs = "WGS84"

For a more sophisticated spatial database, the application can use a native spatial geometry type and store the authoritative CRS separately.

This becomes especially important when drone data is transformed into projected coordinate systems for surveying, mapping, or engineering work.

Where should the actual image files go?

For small prototypes, it may be tempting to put full-resolution photographs directly into a database as binary objects.

That is not always the best architecture.

For large drone operations, it is usually cleaner to separate:

metadata database

from

media/object storage

The database stores information such as:

image_id
flight_id
capture_time
location
file_size
mime_type
sha256
object_uri

while the original image stays in object or file storage.

This makes the database fast enough for search and analysis without forcing every query to move large image binaries.

The exception is when a self-contained geospatial package is specifically required. OGC GeoPackage, for example, is a standardized SQLite-based container that can hold vector features, tile matrices, imagery-related content, and non-spatial tabular data.

GeoPackage and GeoTIFF can complement the flight database

The relational database should not be expected to become the only format for every downstream mapping product.

For geospatial image products, GeoTIFF is a standardized way of encoding georeferenced imagery, while Cloud Optimized GeoTIFF (COG) adds a structure designed for efficient partial access over networks. OGC’s COG standard requires geospatial referencing through GeoTIFF metadata and supports workflows where software retrieves only the portions of imagery it needs.

That leads to a sensible architecture:

Flight database
    ↓
Telemetry + events + image metadata
    ↓
Photogrammetry / GIS processing
    ↓
Orthomosaic / DEM / map products
    ↓
GeoTIFF / COG / other geospatial deliverables

In other words, the flight database is the operational record; it does not need to be the final format for every processed map.

How to handle high-volume telemetry

A drone can produce far more telemetry samples than a conventional business database table is designed to handle efficiently.

Instead of treating every row as a general-purpose transaction, consider:

• append-oriented storage,
• time-based partitioning,
• compression,
• indexes on flight_id and timestamp,
• geospatial indexes where supported,
• retention rules,
• and separate storage for raw logs.

For small and medium projects, a standard relational database may be enough. For very large fleets or long-running telemetry streams, specialized time-series or analytical storage may become appropriate.

The important point is that database technology should follow data volume and query patterns. There is no single database engine that is automatically correct for every drone operation.

What fields should be indexed?

Commonly useful indexes include:

flights(flight_id)
flights(aircraft_id, start_time_utc)
telemetry_samples(flight_id, timestamp_utc)
battery_events(flight_id, event_time_utc)
battery_events(battery_id, event_time_utc)
image_assets(flight_id, capture_time_utc)

For spatial searches, add a spatial index appropriate to the database system.

This supports queries such as:

Show all images captured within this construction site.

Show every battery swap during this flight.

Find the aircraft position when image IMG-004821 was taken.

Show flights using battery B-1047 during the previous 90 days.

Find all flights that entered this geographic area.

Those are the kinds of questions a well-designed schema should make easy.

Common mistakes in drone flight databases

One giant table

Putting flight metadata, telemetry, batteries, images, and mission information into one table produces duplicate values and makes updates difficult.

Better: separate entities and relate them with stable identifiers.

One battery per flight

This fails as soon as a pack is replaced.

Better: create battery events and associate telemetry samples with the battery active at that point in time.

Latitude and longitude without time

This destroys much of the value of historical tracking.

Better: every position observation should carry a timestamp and time provenance.

Overwriting EXIF metadata

Changing original image metadata can remove useful evidence about what the camera actually recorded.

Better: preserve the original metadata and store derived geotags separately.

Assuming all GPS coordinates are equally accurate

Raw GPS, fused navigation estimates, and camera-derived positions can have different quality and meanings. PX4 and MAVLink explicitly distinguish raw positioning data from filtered or fused position estimates.

Better: store source and accuracy information.

Using only human-readable filenames

A filename such as DJI_0482.JPG is not a durable database identity.

Better: assign an internal image_id and preserve the original filename as a separate field.

No processing history

A corrected position can become impossible to explain later if the system does not record how it was derived.

Better: maintain processing version, method, source, and correction information.

A stronger design includes data quality fields

Drone data is often incomplete.

A log may stop recording before landing. GPS quality can change. A camera clock may be wrong. Some battery fields may be unavailable. Some images may not contain GPS tags.

Instead of filling every missing value with zero, use explicit states:

NULL
unknown
not_available
not_measured
estimated

For important measurements, useful quality fields include:

position_valid
altitude_valid
time_quality
position_accuracy_m
source_confidence
processing_status

MAVLink itself uses explicit invalid or unavailable values for several battery and GPS fields, which illustrates why applications should not confuse “zero” with “unknown.”

Security and privacy matter too

A drone database can reveal much more than aircraft performance.

Flight locations may identify private properties, industrial facilities, infrastructure, or sensitive operations. Images can contain GPS metadata that exposes where a photograph was captured. Operational logs can also reveal the timing and location of aircraft activity.

For that reason, production systems should consider:

• role-based access,
• encryption in transit and at rest,
• audit logging,
• controlled access to original media,
• retention policies,
• immutable or versioned source records,
• and appropriate redaction for externally shared data.

The exact legal requirements depend on the jurisdiction and the use case, so the database should not assume that every flight record can be publicly exposed simply because it is technically available.

An example of a complete flight record

Imagine a survey drone begins a mapping mission at 14:10 UTC.

The system creates:

flight_id = F-2026-004821
aircraft_id = UAV-17
mission_id = SURVEY-2026-113

Battery BAT-204 is installed before takeoff.

Telemetry then records:

14:10:03  position / altitude / speed / battery state
14:10:08  position / altitude / speed / battery state
14:10:13  position / altitude / speed / battery state
...

At 14:27, the first battery is removed and BAT-319 is installed.

Instead of rewriting the flight record, the database stores:

Battery event:
14:27:11  BAT-204 removed
14:27:42  BAT-319 installed

At 14:31:42.350, the camera captures an image.

The camera contains an EXIF timestamp, while the flight telemetry uses its own clock domain. The processing system determines the time relationship, matches the image to the flight timeline, calculates or retrieves the corresponding position, and stores:

image_id
flight_id
capture_time_original
capture_time_utc
latitude
longitude
altitude
geotag_method
matched_telemetry_id
time_offset_ms

The original JPEG remains unchanged.

This design allows an analyst to move backward through the chain:

image → capture event → telemetry → active battery → flight → aircraft → mission

That is the real value of a properly structured flight-log database.

The best database model is about relationships, not just fields

The phrase “drone flight log database fields” can make the problem sound like a checklist of columns. In practice, the harder and more important problem is deciding how those fields relate to one another over time.

A flight is a container for an operation. Telemetry describes continuous or periodic state. Battery swaps are discrete lifecycle events. Camera triggers are discrete capture events. Images are durable media assets. Geospatial products are often derived outputs.

Keeping those concepts separate makes the system much easier to maintain.

It also prevents a common analytical error: treating a calculated answer as though it were an original measurement.

Recommended minimum schema

For a general-purpose system, the following is a strong starting point:

Table	Key fields
flights	flight ID, aircraft ID, operator ID, mission ID, start/end time, source log
telemetry_samples	flight ID, timestamp, position, altitude, speed, heading, accuracy, battery ID
batteries	battery ID, serial, model, capacity, cell count, status
battery_events	flight ID, battery ID, event type, event time, location, source
camera_events	flight ID, timestamp, event type, camera ID, frame/file reference
image_assets	image ID, flight ID, timestamp, GPS, altitude, camera ID, hash, media URI
flight_source_files	file ID, format, path/URI, hash, parser version
processing_runs	run ID, software version, input files, processing method, completion status

For a larger enterprise deployment, add operator, maintenance, mission planning, airspace, weather, payload, and compliance-related entities as required by the use case.

FAQ

Final takeaway

A reliable drone flight log database should not be designed as a digital spreadsheet containing one row per flight. The strongest architecture treats the flight as the parent record and connects it to time-stamped telemetry, explicit battery lifecycle events, camera events, and image assets.

The most important principles are simple:

Keep original data. Normalize time carefully. Store battery identity. Model swaps as events. Preserve geotag provenance. Distinguish measured values from derived values. Keep large media separate from operational metadata.

For mapping and geospatial workflows, standardized formats such as GeoTIFF, Cloud Optimized GeoTIFF, and GeoPackage can then sit alongside the operational database rather than forcing the database to become every data format at once.

The result is more than a flight-history system. It becomes a traceable digital record of what aircraft flew, when it flew, which battery powered it, what the aircraft measured, and exactly how each photograph or derived geospatial result was connected to that flight.

---

Also Read: OpenWrt-Nikki | A Clear Guide to Nikki, Mihomo, Installation, Modes, and Configuration