Exploring a Unified Payload and Companion Computer SDK for Quiver

[Alexander_Dada]

Quiver Hub v1 Completion & Release

• What is the work being proposed?

  • Title of the project: Quiver Hub v1: Logs/OTA + Mission Planner Foundations + Security Baseline & Deployment
  • Brief project description: Complete the Hub features that are currently “indicated/future” in Quiver Hub Information Note; Flight Log Capture, OTA Flight Controller Interaction System, Mission Planner, harden the platform so it’s safe to operate a fleet, Local & Cloud Deployments.

• Why do you think this work is necessary?

  • Hub is the “product surface” and orchestration plane. Without Logs/OTA + mission workflows + job safety, Hub remains a powerful demo but not a safe/complete operational platform.
  • Needs to be deployed in a way that can be distributed and accessed safely and reliably

• Is there any related work this builds upon?

  • Builds on the existing Hub architecture; App Builder, real-time streaming plane, job queue concept, and server-side parsing sandbox, already described in the Hub design and SDK information notes.

• Will the results of this project be entirely open source? ([MIT], [GPL], [Apache], [CC BY] license or similar)?

  • Yes

Benefits to

• If this grant is successfully completed, how does it help the Project ?
  • Quiver gets a shippable “v1” hub with operator-grade workflows, eliminating ad-hoc scripts and manual fleet operations.

Benefits to Arrow

• If this grant is successfully completed, how does it help Arrow?

  • Produces a usable platform for Dev kits and partner pilots: Mission Authoring, OTA roll-outs, Log Retrieval, Fleet Admin, Payload Use & Management — all in one place.

• Which other non-Arrow projects, or individuals, would stand to benefit from this grant?

  • Any open drone ecosystem project needing: device management, telemetry visualisation, payload stream routing, and plugin-style data pipeline apps.

Assignee & Background

• Assignee:
  (Name/Username): 21stcenturyAlex
  (Email): alexdada555@arrowair.com / akinola@panrobotics.xyz
  (Organisation): Arrow DAO / Pan Robotics
  (Website): arrowair panrobotics

• What is the background of the person(s) doing the work? What experience do they have with such projects in the past?

  • Systems architecture + robotics platform engineering; author/operator of the Quiver Hub and Quiver SDK design direction and initial reference pipelines.

• Have you examples of similar work you have completed in the past?

  • Existing Hub architecture and payload pipeline work (LiDAR stream → Hub visualisation; job queue direction: SDK “bridge” patterns).

Work Details

• Do you need any input from another bounty/grant before the final submission?

  • Perhaps some nods from the fight tracking platform

• What is the breakdown of the proposed work, in terms of milestones and/or deadlines? Please include specific dates for milestones.

  • Milestone 1 (Mar 10, 2026): Hub Security Baseline

    • Artefact integrity model (hashes/signatures)
    • Job allow listing model (typed jobs, constrained parameters)
    • Job Reliability and Permissions setting

  • Milestone 2 (Mar 17, 2026): Logs v1 Module

    • FC to Companion log Bridge and upload Flow
    • Log browsing & Upload UI
    • Rotation + retention policies

  • Milestone 3 (Mar 23 , 2026): OTA v1 Module

    • Upload artefact → validate → stage → dispatch → verify/apply → report/rollback hooks
    • Roll-out policy: single drone + batch waves Flows

  • Milestone 4 (Apr 7, 2026): Mission Planner Foundations

    • Mission authoring data model + storage
    • “Publish mission” flow (even if execution is stubbed to SDK commands initially)
    • Map component verified + integration tests
    • Companion to FC Bridge

  • Milestone 5 (Apr 10, 2026): Local Executable & Cloud Deployment

  • Single seat Version deployed on local machines @localhost

  • Website deployment with User Sign-in and profile Flow

• List the details of the problem and what you want to accomplish with this grant.

  • Convert Hub from “feature-rich interface” into an operational & deployable platform:
    • secure job execution
    • safe software / config roll-out
    • post-flight troubleshooting via logs
    • basic mission planning workflows
    • Deploy for mass use distribution

• What will be the outcomes of the grant? List all the deliverables and include specific dates for their delivery. For example:

  • Security baseline (Mar 10)
  • Logs v1 UI + Companion log ingest API spec (Mar 17)
  • OTA v1 flow + artefact validation + roll-out policies (Mar 23)
  • Mission planner foundations + stored missions + publish flow (Apr 7)
  • Local Executable & Cloud Deployment (Apr 10)

• In which areas can this work be used? What is the scope of its applicability?

  • Applicable to any Quiver Dev kit, partner payload developer, or Arrow pilot fleet.

• What metrics will be used to evaluate the outcomes of the project? E.g. how the GBC would measure the impact of your project.

  • OTA: successful staged roll-out across ≥3 test drones without manual SSH
  • Logs: retrieve logs from UI
  • Security: all job executions successful and map to allow listed job types; artefacts validated before execution
  • Mission planning: create/save/publish missions to FC via UI with schema validation
  • Usability

Risk Assessment

• What are the potential risks or challenges for this project?

  • Over-scoping mission planning; security model complexity; OTA rollback semantics.

• How will these risks be managed or mitigated?

  • Mission planning = “foundations only” (data model + publish) with minimal execution coupling.
  • OTA = staged + single drone first; rollback as “hooked mechanism” initially.

• How will you handle unforeseen obstacles or delays?

  • If mission planner slips, ship Logs/OTA/Security first (Hub v1 still valuable).

• Is there a long-term plan for updating or improving the work over time?

  • Iterate mission execution integration after SDK v1 is stable.

• What steps can be taken to ensure the longevity and sustainability of the work?

  • Versioned APIs, migrations, and tests.

Costs

• How many work hours will be spent on this grant?

  • ~36 hours

• How much USDC/ARROW is the applicant requesting?

  • 1,800 USDC + 1000 ARROW

• How does the amount requested represent good value for Arrow?

  • This assumes substantial in-kind contribution and re-use of existing code, focusing the grant on “closing gaps” (security baseline + OTA/logs scaffolding + mission foundations) rather than net-new platform invention.

• What is the proposed payment schedule for the grant?

  • 20% per milestone (M1–M5)

• How will the Project verify that the work delivered matches the proposed cadence?

  • Demo videos + acceptance test checklist + deployed test instance.

• What alternatives or options have been considered in order to save costs for the proposed project?

  • Defer mission planner; ship only Logs/OTA/Security first.

• Have you examples of similar work you have completed in the past?

  • Prior pipeline + architecture work evidenced by existing Hub+SDK materials

[Alexander_Dada]

Working Camera Stream from Siyi A8 to Quiver hub

[Alexander_Dada]

SDK Repo

GitHub - Arrow-air/quiver-sdk: Python SDK for the Quiver UAV platform

[Alexander_Dada]

Quick update after discussion on Quiver Hub v1 Completion & Release scope:

For the time being, I’ll be proceeding with Milestones 1–3 only.

The idea here is to first get the core functionality in place, so we have the main building blocks working and available. Once that is done, we’ll take stock of where things stand overall and then reevaluate the best way to approach the remaining work.

In particular, the later stages will be reviewed in the context of whether it makes sense to continue straight into full deployment and how best to mate that work with the evolving SDK effort.

So for now, the focus is: deliver M1–M3, establish the core, then reconvene and rescope the next phase based on the actual state of the system.

Milestone 1 (April 10, 2026): Hub Security Baseline

• Artefact integrity model (hashes/signatures)

• Job allow listing model (typed jobs, constrained parameters)

• Job Reliability and Permissions setting

Milestone 2 (April 12, 2026): Logs v1 Module

• FC to Companion log Bridge and upload Flow

• Log browsing & Upload UI

• Rotation + retention policies

Milestone 3 (Apri 15 , 2026): OTA v1 Module

• Upload artefact → validate → stage → dispatch → verify/apply → report/rollback hooks

• Roll-out policy: single drone + batch waves Flows

[Alexander_Dada]

I have now completed the M1–M3 scope for Quiver Hub V1.

This phase was focused on delivering the first practical core of the Hub by covering three main areas: security foundations, logs handling, and OTA update handling.

Over the course of this work, I put in place the initial security baseline for the Hub, built the first working logs flow between the flight controller, companion computer, and Hub interface, and implemented the first OTA update workflow for firmware upload and flashing. I also delivered the supporting frontend and backend functionality needed to make these features usable through the Hub itself.

Overall, this means Quiver Hub V1 has moved forward from partial scaffolding into a much more functional operational base.

Some parts of the wider security pipeline remain planned rather than fully implemented at this stage. That is intentional. Those items are better suited to the next phase of development alongside the broader Quiver SDK / quiver-hub maturation, rather than forcing them prematurely into the M1–M3 window.

In short, M1–M3 was about getting the most immediately valuable core pieces in place first, and that has now been done.