MAVLab is Ascend Labs’ first flagship project.
Updated 18 October 2026 for MAVLab v1.6.0, released on 12 October. The technical paper remains a record of v1.5.0.
It began from a simple question:
Modern phones already have gyroscopes, accelerometers, GPS, magnetometers, cameras, compute, battery, screen, and network connectivity. Can we use a phone to help people understand how drones sense, move, communicate, and execute missions?
That question grew into a product direction:
Build a low-cost drone systems simulator that helps students, operators, and builders understand drones without needing every learner to own a Pixhawk, drone frame, batteries, RC transmitter, telemetry radio, GPS module, or safe flight field.
Today, the sharper purpose is this:
MAVLab makes drone simulation approachable.
The Problem MAVLab Solves
Drone simulation has a steep learning curve.
Professional stacks like ROS, Gazebo, ArduPilot SITL, PX4 SITL, MAVProxy, Docker, and QGroundControl are powerful, but they can overwhelm beginners before the drone concepts are clear.
A learner should not need to become a Linux networking and simulator-infrastructure expert before understanding:
- attitude
- altitude
- telemetry
- sensors
- flight modes
- mission planning
- failsafes
- battery behavior
- control authority
- debrief workflows
MAVLab changes the learning order.
MAVLab first
-> understand drone systems in one approachable app
-> then graduate into ArduPilot SITL, PX4 SITL, Gazebo, ROS 2, Webots, JSBSim, hardware-in-the-loop, and real aircraft
What MAVLab Is
MAVLab is a phone-based drone simulation and digital-twin platform.
It uses an Android phone as the primary simulation device and turns drone concepts into an interactive learning environment.
The v1.6.0 interface has four connected views:
- Cockpit — live attitude, telemetry, control authority and concise mission progress.
- Control — calibrated Phone Sensors, Custom Input, deliberate Direct RPM and contextual mission actions.
- SIM — the 3D simulated vehicle, received-route geometry and observed trail, with a centered camera and clearer inspection lighting.
- Ops — health, link state, failure exercises, upload evidence and recording review/export.
Missions span the four views. Upload a plan from QGroundControl; there is no separate Mission tab or built-in sample route. A nine-step onboarding tour, guarded horizontal swipes and optional full-screen display make the interface easier to explore. Start flying opens Cockpit without arming.
The Core Loop
The MAVLab learning loop should feel practical:
Open MAVLab
-> understand the current drone state
-> arm / take off / control
-> connect QGroundControl if needed
-> upload or run a mission
-> watch telemetry and 3D state
-> inject or observe a failure
-> review and export a session recorded through Ops
Recording is off by default, including AUTO missions. Begin explicitly in Ops, or enable recording on arm while disarmed. Opening the app or uploading a mission does not begin capture.
The user learns by operating the simulator, not by reading static lessons only.
Why Phone-First Matters
A smartphone is not a full drone. But it is an unusually powerful learning device.
It already has:
- motion sensors
- GPS
- magnetometer
- screen
- compute
- network connection
- battery
- camera
- haptics/audio potential
For education and early simulation, that matters.
Phone-first design means a learner can start with something they already understand and already own. It lowers the barrier to entry, especially in contexts where hardware access is limited.
MAVLink and QGroundControl
MAVLab should not be isolated from real drone workflows.
That is why QGroundControl and MAVLink matter.
MAVLink is the communication protocol used by many drone systems. QGroundControl is a real ground control station. When MAVLab connects to QGroundControl, learners can see how a simulated drone appears to real GCS software.
That creates a bridge:
Friendly phone simulator
-> real telemetry concepts
-> real GCS workflows
-> better preparation for professional tools and hardware
The goal is not to replace QGroundControl or ArduPilot. The goal is to make the concepts behind those tools more understandable.
The 3D SIM
The SIM view should not be decorative.
A useful 3D drone model teaches system state:
- body attitude
- altitude
- propeller speed
- mission path
- payload state
- battery state
- GPS or compass issues
- failure conditions
- control authority
When telemetry changes, the SIM should respond.
That matters because many learners understand drone behavior faster when they can connect numbers to physical movement.
Failure Lab and Debrief
A strong simulator should make failure safe to study.
MAVLab should help learners experience scenarios such as:
- GPS loss
- compass interference
- wind drift
- low battery
- motor weakness
- payload overweight
- link loss
- unsafe mission reserve
The point is not drama. The point is judgment.
A good failure scenario should answer:
What happened?
Why did it happen?
What did the telemetry show?
What should the operator do?
What safety lesson should the learner remember?
Why MAVLab Matters for Ascend
MAVLab supports Ascend in four ways.
- Bootcamp teaching — it gives learners a practical way to understand drone systems before real hardware.
- Talent development — it gives motivated students a path from learning to simulation, logs, missions, and technical projects.
- R&D discipline — it creates a sandbox for testing drone behavior, workflows, and assumptions.
- Public artifact — it shows that Ascend Labs is building, not only talking.
What v1.6.0 Changes
The refresh makes state and control easier to follow. Cockpit combines altitude and attitude charts, and foreground phone steering continues through the simulation engine across Cockpit, Control and SIM. Ops brings incidents, recovery actions and saved-session review together.
The protocol layer now emits unsigned MAVLink 2, with targeted acknowledgements and retries for missing plan items. A failed replacement upload preserves the accepted plan. Navigation, fence and rally plans have separate stores; uploading a fence does not enable enforcement.
Simulated fence breaches can trigger engine-driven return or landing. RTL can use an eligible rally or home point. The model uses flat ground and straight-line returns, without terrain or obstacle routing. It does not implement MAVLink signing, SmartRTL or full ArduPilot behavior; timed loiter and waypoint-pause semantics remain limited. Exact behavior is documented in the MAVLink contract.
Release Evidence and Installation
MAVLab v1.6.0 is published under Apache 2.0 for Android 8.0+. Its host checks passed 307 unit tests, APK/AAB assembly and lint with zero errors. Final-artifact phone/QGC qualification remains deferred. Earlier phone checks and demos are separate evidence, rather than acceptance of the published APK.
The v1.5.0 technical paper remains the source for that version’s evaluation; its performance and QGroundControl results are not new v1.6.0 measurements. Learning-outcome efficacy still needs a controlled classroom study. See the release readiness record for the remaining checks.
Before changing installations: v1.6.0 is debug-signed and cannot update the official v1.5.3 APK in place. Export recordings, save QGC plans and note settings first. Uninstalling erases local data; there is no automatic migration. Read the upgrade guide before deciding to switch. The AAB is unsigned and is not directly installable or Play-ready.
What Comes Next
The immediate priorities are stable release signing and an upgrade/migration policy, final-release phone/QGC qualification, broader accessibility/device checks, and classroom learning-outcome evidence.
Longer-term directions include AI flight debriefs, medical logistics scenarios, instructor tools, SITL bridges and hardware-in-the-loop experiments. These remain proposed work.
See the refreshed interface and demos, or explore the versioned user guides.
Make drone simulation learnable.