Skip to main content
Cyberwave treats every drone the same: drop a digital twin into an environment, pair the aircraft, and start sending commands from the dashboard, the Python SDK, or an AI controller. The same workflow scales from the low-cost DJI Mini 3 Pro and DJI Mini 4 Pro up to research platforms like PX4 Vision; browse the full lineup. 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

1

Create an environment and add the drone

From the 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.
2

Pair the hardware

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 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.
3

Stream sensors automatically

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, with 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 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: 
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.
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 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=…): 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 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 on the environment map and trigger them from the dashboard, the SDK, or a workflow.
1

Drop waypoints

Open the environment, click anywhere on the map to add a waypoint, and label it (launch-pad, tower-A, inspection-point-3, …).
2

Trigger a mission

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.
3

React on arrival

Wire a Workflow 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 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 and the rover AI mission tutorial for full walkthroughs of the same pattern on other platforms; the workflow contract is identical. Because Cyberwave also speaks to cameras, robotic dogs, and 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, or a mix of both; your automation and your hardware don’t change.

​
Where to go next

Browse the drone catalog

Per-aircraft setup, BOM, and troubleshooting for every supported drone.

Autonomous Navigation

The waypoint and navigation driver API.