> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cyberwave.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Drones
> Build inspection automations with Cyberwave, mixing and matching any type of drone with other sensors and cameras
export const EdgeSetup = ({exclude = []}) => {
const showMac = !exclude.includes("mac");
const showLinux = !exclude.includes("linux");
const macCode = `curl -fsSL https://cyberwave.com/install.sh | bash\ncyberwave pair`;
const linuxCode = `curl -fsSL https://cyberwave.com/install.sh | bash\nsudo cyberwave pair`;
const linuxTip =
First time on a Raspberry Pi? See{" "}
Raspberry Pi Setup.
First time on a Jetson Orin Nano? See{" "}
Jetson Orin Nano Setup
.
;
if (showMac && showLinux) {
return {macCode}
{linuxTip}
{linuxCode};
}
if (showMac) {
return {macCode};
}
if (showLinux) {
return <>
{linuxTip}
{linuxCode}
;
}
return null;
};
Cyberwave treats every drone the same: drop a digital twin into an [environment](/use-cyberwave/architecture/key-concepts#environments), pair the aircraft, and start sending commands from the dashboard, the [Python SDK](/tools/python-sdk), or an AI controller. The same workflow scales from the low-cost [DJI Mini 3 Pro](https://cyberwave.com/dji/DJI-Mini-3-Pro) and [DJI Mini 4 Pro](https://cyberwave.com/dji/DJI-Mini-4-Pro) up to research platforms like PX4 Vision — [browse the full lineup](https://cyberwave.com/catalog/tag/drone). Each catalog page bundles the **bill of materials**, supported drivers, and **troubleshooting** for that aircraft, so start there whenever you're unboxing new hardware.
***
## Set up a drone in 3 steps
From the [dashboard](https://cyberwave.com/dashboard), click **New Environment**, then **Add from Catalog** and search for your drone (e.g. `DJI Mini 4 Pro`, `PX4 Vision`). Position the twin to match your real-world site.
Drones connect to Cyberwave through one of two edge paths, depending on the aircraft:
* **Onboard computer (PX4, Ardupilot, custom builds).** SSH into the companion computer (Raspberry Pi, Jetson, …) on the drone and install the CLI:
The CLI auto-detects the autopilot, installs the right driver, and links it to the digital twin.
* **DJI Mini family (Mini 3 / Mini 4 Pro).** Install the **Cyberwave Edge for DJI** Android app on the phone tethered to your **DJI RC**, then scan the **pairing QR** from the twin's **Live** tab. See the [DJI Mini 4 Pro catalog page](https://cyberwave.com/dji/DJI-Mini-4-Pro) for the full flow.
If you are unsure how the drone you picked may connect, check its dedicated page on the catalog — it details everything you need, plus troubleshooting and FAQs.
Cyberwave already knows what's on your aircraft. As soon as pairing completes, the dashboard lights up with the **live video feed**, **gimbal attitude**, **GPS / pose**, and any other sensor the platform exposes — no per-sensor configuration required.
The drone streams video, telemetry, and gimbal state into Cyberwave in real
time, and the dashboard can drive discrete actions back through the edge.
***
## Control it from Python
Once the twin is paired, the [Python SDK](/tools/python-sdk) gives you the same API for any drone in the catalog. Run this from your laptop or any cloud machine — Cyberwave handles the networking and orchestration end-to-end:
```python theme={null}
from cyberwave import Cyberwave
cw = Cyberwave()
cw.affect("real-world") # or "simulation" for a dry run
drone = cw.twin("SZ-DJI-Technology/DJI-Mini-4-Pro") # swap for any other drone
drone.takeoff(altitude=2.0)
drone.gimbal_rotate(pitch=-45.0, duration=1.5) # tilt camera down
frame = drone.capture_frame("numpy") # latest frame from the gimbal cam
drone.land()
```
Switching to a different drone is a **one-line change** — change `cw.twin(...)` to the new catalog slug and the rest of your automation stays exactly the same. A complete walkthrough — takeoff, locomotion, gimbal control, and the safety commands — lives in [`examples/drone_dji_mini.py`](https://github.com/cyberwave-os/cyberwave/tree/main/cyberwave-sdks/cyberwave-python/examples/drone_dji_mini.py).
On DJI aircraft, **discrete actions** (`takeoff`, `land`, `return_to_home`,
`gimbal_rotate`, set home, compass calibration, reboot, emergency stop)
ship out of the box. **Continuous-stick locomotion** (`move_forward`,
`strafe_*`, `turn_*`, `ascend`, `descend`) is **opt-in per twin** — set
`metadata.drivers.default.virtual_stick = true` to engage DJI MSDK v5's
Virtual Stick API. The physical RC always wins: stick inputs reclaim
authority immediately, targets decay to zero after 500 ms of silence, and
the driver hands authority back to the RC after 5 s of zero-velocity. The
same continuous verbs are fully wired on PX4-class builds and in the
simulator without the opt-in. See the [Cyberwave Edge for DJI
README](https://github.com/cyberwave-os/cyberwave/tree/main/cyberwave-edge-nodes/cyberwave-edge-dji-mini-android#off-rc-teleoperation-virtual-stick)
for the full safety story and pre-flight checklist.
The Mini 4 Pro (and the rest of the Mini / Mavic Mini line) ships with a
**pitch-only mechanical gimbal**, so `gimbal_rotate(yaw=…)` is silently
ignored by the hardware. To rotate the camera view on those aircraft, call
[`FlyingTwin.pan_camera(angle_deg=…)`](https://github.com/cyberwave-os/cyberwave/tree/main/cyberwave-sdks/cyberwave-python/cyberwave/twin.py) —
it yaws the airframe via the same Virtual Stick path used by `turn_left` /
`turn_right` and explicitly zeros the axis when the target angle is
reached. Same opt-in flag applies.
**Every refused command — and every silently-ignored one — shows up
in the alerts panel.** The DJI driver raises a [Cyberwave alert](/feature-reference/edge/drivers/alerts)
the instant it refuses a command (missing `virtual_stick` opt-in,
location permissions not granted, parked on a landing/RTH
confirmation, or an SDK-level failure on takeoff / land / gimbal),
*and* watches commanded-vs-actual aircraft velocity to fire a
`driver_aircraft_not_moving` warning when the FC silently caps a
movement command. The alert *name* carries the primary suspect
computed from telemetry — `Aircraft not moving (GPS-denied: 0
satellites)` for indoor flight, `Aircraft not moving (FC in ATTI
mode)` for compass-interference, `Aircraft not moving (cause
unknown)` for restricted-zone / IMU heating / battery saver / wind
— so the root cause is obvious in the alerts list without
expanding the description. The metadata carries a stable
`error_code` (e.g. `VIRTUAL_STICK_OPT_IN_MISSING`, `LOW_VOLTAGE`)
plus a remediation hint and — for the no-motion case — the
current flight mode, GPS sat count, and the commanded vs observed
velocity magnitudes. SDK-level failures additionally embed a
deep-link to the troubleshooting docs for that aircraft. Keep the
alerts panel open during your first off-RC flights.
***
## Add autonomy with waypoints
Cyberwave ships with **autonomous navigation out of the box**. You don't have to write a planner — drop [waypoints](/use-cyberwave/environment-editor) on the environment map and trigger them from the dashboard, the SDK, or a workflow.
Open the environment, click anywhere on the map to add a waypoint, and label
it (`launch-pad`, `tower-A`, `inspection-point-3`, …).
Send the drone between waypoints from the dashboard, the SDK, or as a
Workflow trigger. Cyberwave plans the path and executes it through the
paired driver.
Wire a [Workflow](/use-cyberwave/workflows) to fire on `waypoint reached` —
e.g. capture a frame, send it to a cloud VLM, and log the finding.
***
## Build inspection workflows
Use [Workflows](/use-cyberwave/workflows) to turn waypoints into repeatable inspection missions. A typical pattern:
`waypoint reached → capture frame → send to a cloud VLM → log finding / raise alert`
See the [edge-to-cloud VLM tutorial](/tutorials/edge-to-cloud-vlm) and the [rover AI mission tutorial](/tutorials/rover-ai-mission) for full walkthroughs of the same pattern on other platforms — the workflow contract is identical.
Because Cyberwave also speaks to [cameras](/get-started/cameras), [robotic dogs](/get-started/robotic-dogs), and [arms](/get-started/robotic-arms), you can mix and match hardware in the same workflow — for example, a fixed perimeter camera that **triggers** a drone patrol, or a drone that hands off to a quadruped once it lands at an inspection point.
Workflows can be authored **low-code** in the dashboard or directly in
**Python**. Cyberwave decides whether each step runs on the edge device next
to the drone, in a [cloud node](/tools/cloud-node), or a mix of both — your
automation and your hardware don't change.
***
## Where to go next
Per-aircraft setup, BOM, and troubleshooting for every supported drone.
The waypoint and navigation driver API.