Aveoni
Flight control and its sensors, the companion computer, cameras, onboard compute and AI models — one engineering environment for intelligent drones.
The experience we are building toward
Not fifteen minutes to build a drone. Fifteen minutes from a working drone to one that senses, decides and acts.
The timing assumes a known, supported configuration — which is what the Drone DevKit is for. It is not a claim that any airframe, any sensor and any model can be brought together in fifteen minutes.
The problem
Flight controller
configurator
Companion
ssh · systemd
Camera
v4l2-ctl · shell
AI model
separate runtime
Four toolchains. You are the integration layer.
And almost none of that work is what makes your drone different from anyone else's.
Product direction · not yet available
The Aveoni Drone DevKit is a pre-integrated, working drone development platform: a known reference architecture where the airframe, the flight controller, the companion computer and the camera are already chosen, wired, configured and known to work together.
Aveoni Studio
The engineering environment
Aveoni Drone DevKit
DirectionPerception
camera · baseline sensors · GNSS · interfaces for more
Onboard compute
companion computer · OS and runtime foundation · Aveoni agent
Connectivity
communication interfaces · telemetry and data paths · networking
Flight system
flight controller · supported flight stack · baseline configuration
Physical platform
airframe · motors · ESC and power system · power distribution
Your sensor
Your payload
Your AI
Intelligent drone
Starting from parts
Starting from a platform
Drone DevKit is a product family rather than one fixed bill of materials — different kits for different aircraft, compute targets and application classes. Nothing above is orderable yet; when it is, the exact contents of each kit will be published with it.
Perception
A drone is only as intelligent as what it can perceive. Sensors are not accessories bolted to the outside of the aircraft — they are where the whole loop begins.
01 · Sense
Cameras and sensors
What the aircraft can know about the world, and about itself.
RGB · depth · thermal
LiDAR · GNSS · IMU
environmental · custom
02 · Understand
Onboard compute and a model
Perception becomes meaning, on the computer the aircraft is carrying.
companion computer
CPU or accelerator
your AI model
03 · Act
Flight, payload, capability
Meaning changes what the aircraft does. That is the whole point of the loop.
flight behaviour
payload control
the capability you built
These are classes of perception an intelligent drone draws on, not a support matrix. Aveoni does not claim automatic support for a specific sensor until that support exists. Today Studio reads the flight controller's own sensors over MSP and enumerates cameras through the companion — the rest of the loop is direction.
Intelligence
In Aveoni a model is a component of the aircraft, like a motor or a camera — not a cloud feature attached to it. Your own models, third-party models, or models Aveoni provides. The aircraft is the thing it has to fit.
Which means a model has to be checked against the aircraft that will actually carry it:
The foundation, available now
Import and verify
Manifest, size and SHA-256, refused atomically
Discover compute
Targets read from the companion, with evidence
Plan execution
Compatibility per artifact and target, with reasons
Developer preview
Deployment does not complete yet. Studio ships no runtime binary for any target, so there is nothing to send — it stops and says so rather than uploading a package that could not run. Nothing in Studio runs a model on your drone today.
Product direction
01
Design
Direction
02
Configureflight controller
Available
03
Integratecompanion + cameras
Available
04
Add AIimport · compute · plan
Preview
05
Test
Direction
06
Deploy
Direction
07
Observe
Direction
Capabilities are being introduced progressively. Studio is the first working layer: configuring the flight controller and integrating the computers and cameras around it is what it does now.
What runs today
No profile to pick and no board list to scroll. Studio asks the hardware and reports the answer.
Flight controller
Read once, at the moment shown. This is what the controller said about its own preconditions — not a clearance to arm. * GNSS reported active recently: a liveness signal, not proof the hardware is fitted, which is why it is marked rather than listed with the others.
USB · MSP
Tykho S4
Betaflight 4.5.1
MSP 1.46
HTTP · local network
Raspberry Pi 5
aarch64 · 4 cores
4049 MB
Through the companion
19 device nodes
1 actual camera
identity survives replug
With evidence
CPU available
Hailo absent
NVIDIA absent
Measured on the reference aircraft. No accelerator has been in front of this build — those absences are what it observed.
Aveoni has a word for each. A board that is silent is not a board that is absent, and saying so is worth more than a confident guess.
Open platform
The Drone DevKit is the fastest way in. It is not the only one, and it is not a requirement.
Aveoni Drone DevKit→Aveoni Studio→add sensor, payload or AI→Intelligent drone
Your airframe→Aveoni Studio→integrate and configure the components→add sensor, payload or AI→Intelligent drone
Betaflight today, over MSP. The flight-stack layer is an adapter, not an assumption.
The companion agent is a small service on your own Linux board. No Aveoni server sits between you and your aircraft.
Bring your own model. Aveoni checks it against the compute the companion actually reports, rather than dictating a stack.
Developer preview
Access is arranged per engineer, per board — so the hardware you name is the hardware we check against next.