Flight Test and Tracking Platform

General
,
1

Greetings Folks,

I’m creating this thread to brainstorm and explore ideas around creating a system to capture, monitor & organise flight test artefacts; videos, Flight Logs, Mission Reports, etc, that could be generated either in-house and during any decentralised test campaigns. Initially for first use during Quiver development, but then extensible to other systems going forward as well.

We could potentially have dozens of units in the hands of people and entities round the world, spitting out information and giving essential feedback on the state of Arrow Systems. Therefore, to make best use of this, being able to appropriately capture and incorporate every bit of relevant data would be great.

All ideas on functionality, structure and deployment mechanics etc are welcome.

Thanks for all in advance.

2 Likes
2

Thanks for starting this thread. I think it’s a good time to begin planning out requirements so we can do a thoughtful pass at UI/UX design before we get too far into development.

Before even getting to requirements we should be explicit about the goals for this platform. I’d propose:

  • Collect and organize lots of flight test data so that we can improve our hardware design and reliability.

  • Generate data/proof that will meaningfully assist with certification with airspace regulators.

Here are some of the thoughts that I’ve had for this platform. They’re not super developed and I’m not certain that they are all good ideas.

  • Central database where everyone can upload their flights. Including logs, weather data, narrative commentary, video recordings, etc.

  • Users can create their specific aircraft and mark which components are used (airframe, motors, escs, battery, attachment, etc)

  • The platform will track each individual aircraft and even each individual part on the aircraft. For example each ESC will have a serial number/unique id and we can view number of flights/hrs per that specific part.

  • Separately, we can view aggregated data by TYPE (Quiver PT2, Hobbywing X6, etc), that will show us cumulative data for that TYPE of aircraft/part across all of the different aircrafts and flights. Here we can get more statistically significant data such as mean time before failure per part type.

  • Option to omit location data from flight logs for privacy.

  • Accident/Incident reporting so that others can learn from failures. We might have to define what qualifies as an accident/incident.

  • Easy user experience. We should be able to pre-fill as much data as possible from the uploaded logs to make it an easy process for the pilot.

  • Sign in with Ethereum. Some sort of on-chain or verified pilot log so pilots can match their PIC time with the flights and build credibility and flight hours.

  • Decentralized backend? IPFS? I don’t think much of this makes sense to have on-chain but it would be nice to have it be somewhat immutable and decentralized.

  • $ARROW token rewards. We could hold contests for longest flight, most time on a part, etc. We could put specific incentives for things where we need more data, like high altitude flights, flights at MTOW, extreme temperature, etc. This could work kind of like liquidity mining in DeFi but for crowdsourcing flight test data.

  • Parts catalog where you can view specifications on a part gathered from actual flight data. This would help people pick parts on their own drone and could be better data than some manufacturer data sheets.

It’d be great to get some specific feedback on the above goals and ideas. Are they useful? What are they missing? I don’t feel like I have a lot of insight yet on what we’ll need for certification and if this is even useful or not. I think a deeper understanding of the certification process will be critical to inform design of this platform.

2 Likes
3

On the road to certification point, we could explore what kinds of data and information and formats aerospace systems developers usually send to government agencies, or if governments have specification to that effect already, that could be used to specify what information to capture, or generate if possible by aggregating other data point. Then given any existing format templates, having as a function of the system the ability to auto generate that would be useful.

4

FAA Certification Requirements

In the United States, the FAA’s certification process for UAS, especially for advanced operations, involves several steps:​Federal Aviation Administration

1. Special Airworthiness Certificate

Under FAA Order 8130.34D, UAS can be issued a Special Airworthiness Certificate in the experimental category for purposes such as research and development, crew training, and market surveys. This requires detailed documentation, including:

2. Type Certification for UAS

The FAA has introduced airworthiness criteria for UAS seeking type certification under the “special class” category. This involves demonstrating the aircraft’s durability and reliability through rigorous testing and documentation. Federal Aviation Administration

Functionality for Part 107 Compliance:

Structured Data Capture

  • Flight time, date, duration.
  • Pilot-in-Command (PIC) details, including Remote Pilot Certificate verification.
  • Location data (with privacy controls as needed).
  • Aircraft ID/Registration details.
  • Detailed narrative/commentary logs for each flight.

Incident and Accident Tracking

  • Standardized accident/incident reporting template matching FAA format.
  • Automatic alerts and notifications upon logged accident events.
  • Secure, verifiable report submission to FAA channels if required.

Compliance Dashboard

  • Real-time overview of regulatory compliance status (e.g., pilot certification expiration reminders, aircraft registration renewal alerts).
  • Quick-access dashboards summarizing logged flight hours, incident counts, and compliance checks.

Security and Privacy Controls

  • Secure data encryption and secure access management.
  • GDPR & privacy law compliance for handling sensitive pilot/operator data.
  • Optional anonymization or aggregation of location data for broader community insights while protecting user privacy.

if we could have data entry elements into the application like in these types of documents specifying are recording test proceedures and events, pt2 test 3, then having an LLM package the data and spit out formatted reports consistently as required would be trivial.

6

On implementing secure decentralised storage, we could use a combination of IPFS and optimism.

could have an running IPFS node on the server and pin the data for persistence. Then store the data content identifier via an “Anchor” smart contract deployed on Optimism that emits an event containing the CID, immutably recording the file’s fingerprint and timestamp on-chain.

When it comes time to retrieve the data, the app could read the on-chain event to extract the CID, then performs an IPFS check against the node data. IPFS automatically verifies the data’s integrity by checking each chunk’s hash against the CID. so we would have a scalable storage in IPFS plus on-chain anchoring on Optimism for data attestation provable to regulators.

so the data , like gigs of video or log files, wont themselves be onchain but we can have an onchain tx as the ironclad guarantee of the data’s integrity

7

on injecting token rewards, we could have something like a mini “Active Bounties” tab where people can find needed testing aspects with corresponding rewards, and given the nature of some of these task, i.e if they can be checked against log data; like flight times, distances, temperatures or certain kinds of usage intensity, etc, it might be possible to even programmatically determine whether the requirements have been met or not before automatically releasing rewards.