In recent years, drone technology has seen rapid advancement and widespread adoption across various sectors. Within railway operations, for instance, DJI drones have become instrumental in tasks such as oblique photography for 3D modeling, station yard inspections, and disaster response. This trend towards intelligent and informatized operations is mirrored in many other industries. However, a persistent challenge lies in the predominant reliance on on-site pilots for manual operation. This decentralized model often lacks centralized oversight and technical guidance, making it difficult to supervise planned flight routes in real-time or promptly assess and mitigate operational risks. Potential issues like geofence breaches or other flight anomalies are hard to address swiftly, leading to significant safety concerns and reduced operational efficiency.
Current mainstream drone management solutions are predominantly built upon Mobile SDKs (MSDK), which are designed for Android or iOS platforms and rely on handheld mobile devices. While these applications facilitate basic data acquisition and monitoring, they are inherently limited by the mobile environment. Their integration with enterprise-level information systems is often cumbersome, and they lack the cross-platform flexibility and scalability required for robust, organization-wide fleet management.
To address these gaps and meet specific enterprise operational needs, this research focuses on designing and implementing a web-based DJI drone operation management platform. The platform leverages the DJI Cloud SDK and Payload SDK (PSDK) to establish a cloud-connected infrastructure, enabling remote supervision and control of drone flight operations, thereby offering a novel technical pathway for enhanced safety and efficiency.
DJI SDK Ecosystem Analysis
The DJI software development kit (SDK) ecosystem provides multiple interfaces tailored for different development scenarios. A comparative analysis is crucial for selecting the appropriate foundation for a web-centric platform. The key SDKs and their primary characteristics are summarized in the following table:
| SDK Type | Primary Purpose | Target Platform/Device | Suitability for Web Platform |
|---|---|---|---|
| Cloud SDK | Cloud service integration, device management, data storage/distribution, flight record sync. | Cloud/Server | High. Essential for device-to-cloud connectivity and web backend services. |
| Mobile SDK (MSDK) | Basic control, real-time data/video, mission planning via mobile apps. | iOS/Android Devices | Low. Confined to mobile OS; not directly usable for pure web clients. |
| Payload SDK (PSDK) | Development for payloads (gimbals, cameras, sensors); control and data interaction with the drone. | Payload Hardware / Cloud-to-Payload | Medium-High. Can be used via cloud channels to send commands to payloads from a web backend. |
| Onboard SDK (OSDK) | Advanced autonomous control, deploying onboard AI models using the drone’s computational resources. | Drone’s Onboard Computer | Low-Medium. Enables advanced autonomy but control logic typically resides on the drone, with limited direct web control paradigms. |
For complex operations like oblique photography collection or detailed infrastructure inspection along railway lines, precise control over both the DJI drone flight path and its payload (e.g., high-resolution camera, LiDAR) is paramount. Based on the analysis, the combination of Cloud SDK and Payload SDK was selected. The Cloud SDK provides the fundamental capability to bring the drone and its remote controller online, enabling real-time synchronization of flight telemetry, status parameters, and mission data to the cloud platform. The Payload SDK, when integrated with the Cloud SDK’s command channels, allows for deep, remote control of the drone’s attached payloads, facilitating the precise adjustments needed for specialized inspection scenarios such as tunnels and bridges. This combination directly supports the development of a comprehensive web-based management system, unlike the MSDK which is unsuitable for this architecture.
Platform Overall Architecture
The designed platform functionally encompasses drone cloud connectivity, flight data transmission, media streaming, mission synchronization, and flight command control. The core enabler is the cloud connectivity of the DJI drone system, where the remote controller (e.g., DJI RC Plus) acts as a relay gateway, connecting the drone to a custom third-party cloud service to facilitate bidirectional data flow. The high-level architecture is described as follows:
1. MQTT for Flight Data Transmission: The flight status data, including attitude, GPS coordinates, battery level, and mission progress, is characterized by small packet sizes but high requirements for real-time delivery and reliability. The platform employs the MQTT protocol for this purpose. MQTT is a lightweight, publish-subscribe messaging protocol ideal for IoT and drone applications due to its low overhead, high efficiency in unstable networks, and configurable Quality of Service (QoS) levels. A custom cloud service module developed with the Cloud SDK is loaded into the DJI Pilot 2 application on the controller. This module publishes telemetry data to topics keyed by the drone’s Serial Number (SN) on an MQTT broker (e.g., EMQX). The web backend subscribes to these topics, receiving real-time data which is then forwarded to web clients via WebSocket connections.
2. RTMP for Media Streaming: Video data from the DJI drone’s FPV or gimbal camera requires high frame-rate continuity and is transmitted using the RTMP protocol, which is well-established for low-latency live streaming. The DJI Pilot 2 application pushes the RTMP stream to a dedicated streaming media server (SRS was chosen for its performance and multi-protocol support) deployed on the enterprise cloud. This server then transmuxes the stream into HTTP-FLV format for efficient playback in modern web browsers using players like flv.js.
3. Backend-Frontend Real-time Communication: A “MQTT → WebSocket → Web Frontend” data pipeline is established. The backend server subscribes to MQTT topics for live telemetry and maintains persistent WebSocket connections with authenticated web clients. This allows for the real-time rendering of flight status, position on maps, and system alerts on the web interface.
Key Technology Implementation
1. Development of Third-party Cloud Service
While DJI’s native cloud services offer basic functionality, they often lack the flexibility for deep integration with custom enterprise systems and data workflows. Developing a third-party cloud service was necessary to establish a direct data conduit between the DJI drone ecosystem and the enterprise platform.
1.1 JSBridge Interface Invocation: JSBridge is a communication mechanism enabling bidirectional calls between a WebView (hosting an H5 page) and a native application. The DJI Pilot 2 app loads the custom cloud service’s H5 page. Through JSBridge, the H5 page can invoke native functions provided by the Cloud SDK, such as retrieving the drone and remote controller SN codes, which are critical for creating unique MQTT topics.
The simplified code flow within the H5 page is as follows. The `window.djiBridge` object is injected by Pilot 2’s native WebView, providing access to native APIs.
// Example: Retrieving device serial numbers via JSBridge-wrapped Cloud SDK functions
const remoteControllerSN = apiPilot.getRemoteControllerSN();
const aircraftSN = apiPilot.getAircraftSN();
1.2 MQTT Broker Setup and Data Publishing: After obtaining the telemetry data via native APIs, the H5 page uses an MQTT client library to publish this data. An EMQX broker acts as the MQTT gateway. Data is published to a structured topic, e.g., `thing/product/{Aircraft_SN}/osd`. The web backend service subscribes to topics matching this pattern to receive data from all connected DJI drones.
1.3 Flight Data Structure: The MQTT payload contains a comprehensive set of flight parameters. Key attributes relevant for monitoring and control are listed below:
| Field Name | Type | Description |
|---|---|---|
| longitude | float | Current longitude of the DJI drone. |
| latitude | float | Current latitude of the DJI drone. |
| altitude | float | Altitude above mean sea level. |
| height | float | Height relative to the takeoff point. |
| horizontal_speed | float | Current horizontal speed. |
| vertical_speed | float | Current vertical speed. |
| gimbal_pitch | double | Pitch angle of the gimbal/camera. |
2. Media Streaming Implementation
2.1 SRS Streaming Server: For video relay, SRS (Simple Realtime Server) was chosen over alternatives like Nginx-RTMP. The decision was based on its superior performance in high-concurrency scenarios and lower end-to-end latency, which is critical for real-time drone monitoring.
| Streaming Server | Supported Protocols | Performance | Typical Latency |
|---|---|---|---|
| Nginx-RTMP | RTMP, basic HLS | Can bottleneck under high load | 3-5 seconds or higher |
| SRS | RTMP, HLS, HTTP-FLV, WebRTC | Optimized for concurrency, stable | 1-3 seconds |
2.2 HTTP-FLV for Web Playback: Since modern browsers do not support RTMP natively, SRS performs real-time transmuxing of the incoming RTMP stream from the DJI drone into HTTP-FLV. The FLV stream is delivered over a long-lived HTTP connection, which offers lower latency compared to HLS segment-based streaming. The web frontend uses the flv.js library to decode and play the FLV stream within a standard HTML5 video element.
3. Mission Planning and Synchronization
The platform enables synchronized mission planning between the web interface and the DJI Pilot 2 application. Flight missions are defined in KMZ files (compressed KML). These files are stored on a cloud object storage service. The web backend manages a database index of available missions.
When the cloud service H5 page is loaded in Pilot 2, it fetches the list of available KMZ files from the backend API and displays them in Pilot 2’s native mission library for execution. Conversely, on the web interface, users can download a KMZ file, extract and convert its KML data to GeoJSON, and modify the flight path using an interactive map built with Leaflet and OpenStreetMap. The modified mission can then be uploaded back to the server and synchronized to the Pilot 2 application.
4. Virtual Joystick Control via PSDK
To enable direct remote control from the web interface, the platform utilizes the Payload SDK’s Direct Remote Control (DRC) capabilities, supported by DJI drone models like the Matrice 350 RTK and Mavic 3 Enterprise.
4.1 Command Channel Establishment: Control commands are categorized into flight control (aircraft movement along pitch, roll, yaw axes, takeoff, landing) and payload control (gimbal movement, camera parameters). A dedicated, low-latency MQTT channel is established between the cloud platform and the DJI drone (via the controller) for command transmission. The sequence involves the web backend first obtaining flight control authority, then publishing structured command messages to specific MQTT topics listened to by the PSDK-enabled service on the controller/drone.
4.2 Web-based Virtual Joystick: A virtual control panel is implemented in the web frontend, mimicking a physical remote controller. User inputs from mouse, keyboard, or on-screen joystick widgets are captured, translated into normalized control values (e.g., pitch rate, yaw rate), and sent as command packets via the WebSocket-backend-MQTT pipeline to the DJI drone. This allows an operator to control the drone’s basic movement and gimbal orientation remotely from a browser.
Experimental Application and Analysis
1. Data Transmission Testing and Latency Analysis
Tests were conducted using a DJI Matrice 350 RTK drone and a DJI RC Plus controller under various network conditions.
1.1 Media Streaming Latency: The end-to-end latency from the DJI drone’s camera to the web video player was measured. The bottleneck remains the proprietary video transmission between the drone and the controller. The SRS server adds minimal delay (typically < 500ms). Results are summarized below:
| Resolution | Obstacles | Drone-Controller Distance | Observed Latency | Latency Jitter |
|---|---|---|---|---|
| 1080P | Yes | 2 km | 2.0 – 2.5 s | High |
| 1080P | No | 500 m | 1.0 – 1.5 s | Low |
| 720P | No | 2 km | 1.8 – 2.3 s | Low |
The latency $L_{stream}$ can be modeled as the sum of several components:
$$L_{stream} = L_{prop} + L_{encode} + L_{tx} + L_{relay} + L_{buffer}$$
where $L_{prop}$ is the propagation delay in the drone-controller link (affected by distance and obstacles), $L_{encode}$ is the camera encoding delay, $L_{tx}$ is the transmission delay to the cloud, $L_{relay}$ is the SRS processing/relay delay, and $L_{buffer}$ is the client-side buffering delay.
1.2 Flight Data Transmission Latency: The MQTT transmission delay for telemetry data (published at 2 Hz) was measured under good network conditions. The delay $D_{mqtt}$ from publication on the controller to reception at the web backend was consistently low:
$$Average\ D_{mqtt} \approx 80\ ms,\ with\ D_{mqtt} \in [50, 120]\ ms$$
This high-frequency, low-latency data is crucial for real-time mapping and monitoring.
1.3 Virtual Joystick Command Latency: The round-trip time for control commands sent from the web interface to the DJI drone’s response was evaluated. The dedicated MQTT channel ensured minimal overhead.
| Command Type | Average Transmission Delay | Observed Range |
|---|---|---|
| Flight Control (Pitch/Roll/Yaw) | 65 ms | 50 – 80 ms |
| Gimbal Control (Pitch/Yaw) | 125 ms | 100 – 150 ms |
The total control latency $L_{control}$ can be expressed as:
$$L_{control} = L_{web\_proc} + L_{ws} + L_{backend} + L_{mqtt\_cmd} + L_{rc\_proc} + L_{drone\_response}$$
where $L_{web\_proc}$ and $L_{rc\_proc}$ are processing times on the web client and remote controller, respectively, and $L_{ws}$ and $L_{mqtt\_cmd}$ are the WebSocket and command MQTT channel delays. The results confirm the feasibility of responsive remote piloting for basic maneuvers.
2. Flight Safety Management
Safety mechanisms were implemented based on the real-time telemetry data.
2.1 Geofence Violation and Intrusion Detection: Operational areas are defined as GeoJSON polygons, creating electronic geofences. The drone’s current $(longitude, latitude)$ from the MQTT stream is continuously checked against these boundaries. A violation triggers an immediate abort command sent via the control channel.
Furthermore, Digital Surface Models (DSM) of the operational area are integrated. The DSM provides ground elevation $E_{ground}(lat, lon)$. By comparing the drone’s current height above takeoff $H_{rel}$ (assuming takeoff point elevation $E_{takeoff}$ is known), its height above ground $H_{agl}$ is estimated:
$$H_{agl} \approx H_{rel} + E_{takeoff} – E_{ground}(lat, lon)$$
If $H_{agl}$ falls below a predefined safety threshold relative to the terrain ahead (predictive check based on flight vector), a collision warning or abort command is issued.
2.2 In-flight Abort Verification: Field tests validated the safety system. The time from violation detection in the cloud to command reception at the controller was between 500ms and 1s. The DJI drone’s reaction time to execute an emergency hover was approximately 500ms. This sub-2-second total response time effectively prevents boundary breaches.
3. Flight Logging and Analysis
Detailed flight logs, including extended telemetry, events, and mission parameters, are retrieved from the DJI drone via the JSBridge interface post-flight. These logs are stored in a structured database with indexed associations to specific flight sessions. This repository enables comprehensive post-operation analysis, fault diagnosis, and audit trails, enhancing operational accountability and continuous improvement.
Discussion and Future Outlook
While the developed platform establishes a functional foundation for web-based DJI drone management, several limitations and opportunities for enhancement exist.
1. Current Limitations:
• Asynchronous Latency: The inherent difference between the low-latency command channel and the higher-latency video stream can create a disconnect between control input and visual feedback, challenging precise remote operation.
• Limited Control Dimensionality: The virtual joystick provides basic axis control but lacks the nuanced tactile feedback and simultaneous multi-control ease of a physical remote, limiting complex maneuver execution.
• Basic Safety Algorithms: Safety relies on static geofences and DSM data. It cannot dynamically identify moving obstacles (e.g., vehicles, birds) or complex, unforeseen risks.
• Underutilized Log Data: Flight logs are primarily archived. Advanced analytics for predictive maintenance, pilot performance assessment, or automated risk modeling are not implemented.
2. Future Research Directions:
• Intelligent Mission Planning: For linear infrastructure inspection, AI-driven algorithms could analyze 3D models (from prior oblique photography) to automatically generate optimized, collision-free flight paths that ensure complete coverage of key assets like bridges, towers, and cables, adapting in real-time to known obstacles.
• Enhanced Human-Drone Interaction (HDI): Exploring multimodal interfaces such as voice commands (“ascend to 50 meters”), gesture recognition via webcam, or immersive control through VR/AR interfaces could overcome the limitations of the virtual joystick and improve situational awareness for remote operators.
• AI-Enhanced Flight Safety: Future integration with the DJI Onboard SDK could deploy lightweight computer vision models directly on the drone’s compute platform. This would enable real-time, low-latency detection of dynamic obstacles and anomalous situations, moving beyond pre-defined geofences to a proactive, perception-based safety system. The reaction time $L_{reaction}^{AI}$ for an onboard model would be significantly faster than a cloud-based loop:
$$L_{reaction}^{cloud} \approx L_{stream} + L_{cloud\_AI\_proc} + L_{command} > 2s$$
$$L_{reaction}^{onboard} \approx L_{sensor\_proc} + L_{onboard\_AI\_proc} + L_{fc\_proc} \ll 1s$$
• Comprehensive Observability: Elevating flight log analysis to a full-stack observability paradigm. This involves correlating logs with system performance metrics and distributed traces of commands and data flows. The goal is to create a unified dashboard that answers not just “what happened” but “why it happened,” enabling faster troubleshooting and optimization of the entire drone operation lifecycle. Key observability metrics $O$ could be formulated from log streams $L$, metrics $M$, and traces $T$:
$$O = F(L, M, T) = \{ Latency\_Correlation, Error\_Causality, Resource\_Utilization\_Trends \}$$
Conclusion
This research presents the design and implementation of a comprehensive web-based management platform for DJI drone flight operations. By leveraging the DJI Cloud SDK and Payload SDK, the platform successfully establishes a cloud-connected architecture that enables real-time telemetry monitoring, live video streaming, synchronized mission planning, and remote virtual joystick control directly from a web browser. The choice of MQTT for data/command transmission and RTMP/HTTP-FLV for video streaming proved effective, with measured latencies supporting operational monitoring and basic remote control functions. Furthermore, the integration of geofencing and DSM-based altitude checks provides a foundational layer of automated flight safety. The platform demonstrates a viable and scalable alternative to mobile-centric solutions, offering the flexibility and integration capabilities required for enterprise-level DJI drone fleet management. Future work will focus on integrating AI for intelligent mission planning and dynamic obstacle avoidance, as well as developing more advanced human-drone interaction models and a comprehensive observability framework to further enhance the safety, efficiency, and intelligence of drone operations.