In the past, developing a drone ground control station usually required completing each part of the system step by step, including the front-end interface, back-end services, communication protocol, deployment, and debugging. The interface had to be designed, flight controller data had to be parsed, command links had to be verified, and the system then had to be deployed to an onboard computer or ground-side device for repeated testing. With a traditional development approach, the overall R&D cycle was relatively long and often took more than one year.

This time, we used the FlyCore hardware platform as an example and introduced AI development tools into the entire development workflow to rapidly build a demo version of a drone Web ground control station. The demo can be used for flight controller data visualization, map display, 3D coordinate visualization, and basic flight control command interaction.

For other unmanned systems, as long as they are equipped with a processor with sufficient computing capability and stable network access, this technical approach can also be used as a reference. By integrating the Web front end, back-end services, and flight controller data link, developers can quickly validate a ground control station prototype.

01

Why Choose a Web-Based Ground Control Station?

The biggest advantage of a Web-based ground control station is its cross-device compatibility.

It can run on Android tablets, Windows PCs, and even browsers built into remote controllers. As long as a device can open a browser, it can access the ground control station interface.

From the perspective of the FlyCore hardware architecture, the RK3588 provides local computing capability, the LQ-10 provides the flight controller data link, MAVLink offers a standardized communication protocol, and the browser serves as the interaction entry point. Together, these components form a solution with high development efficiency, a clear debugging workflow, and convenient scalability.

From the perspective of the FlyCore hardware architecture, the RK3588 provides local computing capability, the LQ-10 provides the flight controller data link, MAVLink offers a standardized communication protocol, and the browser serves as the interaction entry point. Together, these components form a solution with high development efficiency, a clear debugging workflow, and convenient scalability.

02

Core Design

Network Foundation for AI-Assisted Access to the Development Environment

During the actual development process, Codex needs to access the onboard computer of FlyCore. There are two common approaches:

The first approach is to connect through the LQ-10 image/data transmission link within the same local area network. The remote controller, ground-side device, router, and RK3588 are placed on the same network segment. When the router has Internet access, the cloud-based AI development tool can connect to the RK3588 via SSH or Web services and participate in code development, deployment, and debugging.

The second approach is to connect directly to the Ethernet port of FlyCore. As long as the IP segment is properly configured and the RK3588 can access the Internet, AI development tools can also participate in project development.

It should be clarified that the AI here does not directly control the flight controller or operate the drone in flight. Its main role is to help developers write, deploy, and debug the software running on the RK3588. The actual communication with the flight controller is still handled by the back-end program through the MAVLink protocol.

In other words, AI functions more like an engineering assistant entering the development environment, helping engineers get the code, deployment, and debugging workflow running.

03

What Materials Should Be Prepared Before Development?

When using AI to develop an engineering project, the most important step is not to start writing code immediately, but to clearly define the software architecture, interface relationships, and interaction objectives first.

If the instruction is only “help me build a ground control station,” the generated result can easily deviate from the actual requirements.

However, if the interfaces, workflows, architecture, and UI prototype are prepared in advance, AI can understand the project objectives more accurately, which can significantly reduce rework later.

For this project, it is recommended to prepare four types of materials in advance:

1. Interface code

2. Interface documentation

3. UML flowcharts or system architecture diagrams

4. Interactive UI prototype for the Web interface

Interface Code

The core communication protocol of this project is MAVLink. As a widely used communication protocol in the drone industry, MAVLink already has a mature message structure and well-established application scenarios. AI development tools can usually understand its basic logic and common message types.

However, in actual projects, if a specific version of MAVLink interface code is used, it is recommended to provide the relevant code directly to the AI instead of relying entirely on online search. This helps reduce issues caused by inconsistent protocol versions, field definitions, or message type interpretation.

When parsing flight controller data on the back end, the Python library pymavlink can be used. It can read MAVLink data streams output by the flight controller and parse messages such as HEARTBEAT, GPS, attitude, battery, position, and velocity into data structures that can be directly used by the back-end program. This provides the foundation for later data visualization and command interaction.

Interface Documentation

The official MAVLink documentation and common examples can serve as reference materials for AI to understand flight controller data. If the project has specific requirements for certain message types, coordinate frames, unit conversions, or flight modes, these should be clearly documented in the engineering materials.

For example:

GPS longitude and latitude usually come from GLOBAL_POSITION_INT or GPS_RAW_INT.

Local position data can come from LOCAL_POSITION_NED.

Attitude information can come from ATTITUDE.

The command execution result should be checked through the COMMAND_ACK returned by the flight controller.

These explanations can significantly reduce the possibility of AI misunderstanding the protocol.

UML Flowcharts and System Architecture Diagrams

The Web ground control station demonstrated in this article is a relatively simple demo, so the UML flowchart does not need to be overly complex. It only needs to describe the basic front-end interactions, front-end/back-end data flow, and flight control command link.

However, if a professional version of the ground control station is to be developed, it is recommended that an architect define the complete system workflow before formal development begins. This should include the front-end Web interaction workflow, the data interaction workflow between the front end and back-end server, the flight control command delivery workflow, and the handling logic for abnormal states.

This preparation is very important. The more complex the project is, the more detailed the flowcharts need to be. Developers can also use flowchart or architecture diagram tools that are more AI-friendly to clearly describe key modules, data flows, and command relationships. This allows AI to understand the project more accurately, generate code that better matches actual requirements, and reduce the cost of later integration and modification.

Interactive UI Prototype

It is recommended to design the front-end UI prototype in Figma. Compared with static screenshots, a complete Figma project file contains layout information, spacing, component hierarchy, and interaction relationships, making it easier for AI to understand front-end requirements.

If Codex is used to assist with front-end code generation, it is recommended to provide the complete prototype project rather than only interface screenshots. The clearer the prototype is, the closer the generated HTML, CSS, and JavaScript code will be to the actual requirements, and the less modification will be needed later.

The interactive prototype for this project can be viewed in the README of the project’s Gitee repository.

04

Architecture Design

This project adopts a B/S architecture, namely Browser/Server architecture.

• Client side: Android browsers, PC browsers, or other Web-enabled terminals, responsible for page rendering and user interaction.
• Server side: A Python back end running on the RK3588, responsible for hosting front-end pages, parsing MAVLink data, providing API interfaces, and handling flight control commands.
• Data link: The flight controller outputs MAVLink data through a serial port. The LQ-10 forwards the serial data as an IP:Port data stream, and the Python back end reads and parses it through pymavlink.

The current demo version does not include a database. If functions such as flight logs, historical tracks, user accounts, or mission configuration are needed later, a database module can be added to the back end.

A more project-specific architecture can be described as follows:

In terms of code implementation, the front end mainly consists of index.html, src/*.js, and src/styles.css, while the back end is mainly handled by backend.py. By default, the back end listens on Web service port 5173, and MAVLink data enters through UDP port 8080. By default, the LQ-10 image/data transmission module forwards the MAVLink data stream from the flight controller serial port to this port.

05

UI Design and Front-End Interaction Implementation

The front-end interface is implemented based on the Figma prototype, with the goal of providing a mobile-style ground control station operating experience in the browser. The current Web ground control station mainly includes the following functional areas:

• Login and aircraft model selection interface
• Map display interface
• RViz-style 3D coordinate view
• Attitude indicator display
• Status bar for GPS, speed, battery, flight mode, and ARM/DISARM state
• Flight controller message feedback list
• Basic interaction buttons such as arm, disarm, takeoff, and land

The front end does not directly parse MAVLink data. Instead, it obtains processed telemetry data from the back end through HTTP APIs and refreshes the corresponding interface elements based on different data types. For example, the map module reads GPS coordinates, the RViz-style 3D view reads local position data such as x/y/z, and the attitude indicator reads attitude data such as roll, pitch, yaw, and heading.

For flight control command interaction, safety must be carefully considered. Taking “one-click takeoff” as an example, the current design does not send a takeoff command immediately after the user clicks the button. Instead, a slide-to-confirm interface is displayed first. Only after the slide confirmation is completed will the front end request the back end to send the takeoff command. After receiving the request, the back end will further check whether MAVLink is online, whether the target flight controller has been identified, whether the aircraft has already been armed, and then wait for the flight controller to return COMMAND_ACK.

The Figma prototype link for this project can be found in the README of the project source code.

06

Back-End Server Design

The back-end server runs on the RK3588. Its main role is to connect the flight controller data link with the Web front-end interface. It performs three core tasks:

• Reading and parsing MAVLink data using pymavlink
• Caching the parsed telemetry data in memory
• Providing data to the front end through HTTP APIs while receiving control commands from the front end

In the FlyCore system, MAVLink data is typically output from the flight controller through a serial port and then forwarded as a network data stream by the LQ-10 image/data transmission module. During actual deployment, the LQ-10 network forwarding configuration must be set to forward the flight controller MAVLink data to the IP address and corresponding port of the RK3588.

For example:

The default back-end configuration is:

This means that the Python back end listens on UDP port 8080 on the RK3588 and waits for the MAVLink data stream forwarded by the LQ-10.

If QGC and the Web ground control station need to be used simultaneously on site, the LQ-10 can also be configured for dual forwarding:

In this way, both QGC and the Web ground control station can receive flight controller data at the same time. QGC can continue to be used for conventional ground station operations, while the Web ground control station reads data through the RK3588 back end and displays it on the Web interface.

If the LQ-10 image/data transmission module is used, the following configuration can be used as a reference:

When using the LQ-10 image/data transmission module, the flight controller serial data needs to be forwarded to two IP addresses in the forwarding configuration: one for the QGC ground station and the other for the RK3588. In this way, QGC can receive flight controller data normally, while port 8080 on the RK3588 can also receive the MAVLink data stream simultaneously for the back-end server to read and parse.

If the current transmission device does not support one-to-two forwarding, a separate network forwarding solution will need to be designed. This article will not cover that in detail.

The overall data flow can be understood as follows:

The flight controller serial port outputs MAVLink data
  → The LQ10 image/data transmission mobile side receives it
  → The LQ10 image/data transmission ground side forwards it as IP port data
  → The Python back end reads the MAVLink data stream through pymavlink
  → The Python back end provides the data to the Web front end
  → The front end displays the flight controller status and supports basic interaction

06

Code Deployment

During the deployment stage, AI can be used to download the project source code from the Git repository and remotely log in to the RK3588 via SSH to complete code deployment, dependency installation, configuration modification, and service startup. After deployment is completed, it is recommended to configure the back-end service as a system auto-start service, so that it can run automatically after the RK3588 boots without manual startup.

It should be noted that the back-end service continuously reads MAVLink data sent by the flight controller and provides it to the Web front end through APIs. If the back end does not receive the MAVLink data stream correctly, the Web page may still open normally, but real-time flight controller status will not be displayed. Therefore, after deployment is completed, two key items must be checked:

• Whether the back-end service is running properly.
• Whether port 8080 on the RK3588 has received the MAVLink data forwarded from the flight controller.

Only when the back end continuously receives flight controller data can the Web ground control station properly display telemetry data and refresh flight controller status.

AI-assisted remote access workflow for the onboard computer:

The figure above shows the chat process with the AI. By default, the RK3588 onboard computer can be accessed via SSH. The login address is ssh amov@192.168.1.66, and the default password is amov.

Through the previous steps, the local public key can be copied to the RK3588 to enable passwordless login. After the configuration is completed, the AI tool can remotely access the onboard computer through SSH/SCP and perform code deployment, dependency installation, service startup, and troubleshooting in the CLI environment.

This step is critical. It allows AI to move beyond simply generating code locally and enter the actual onboard computer environment, participating in the deployment and debugging stages of drone software development.

The following steps can all be performed by AI on your behalf:

• Upload the code to the RK3588, first by cloning it with Git and then uploading it.
• Install the Python dependencies on the RK3588.
• Configure config.env.
• Start the back-end service.
• Configure systemd auto-start on boot.
• Access http://RK3588_IP:5173 in a browser.

Check whether port 8080 has received MAVLink data.

If the back end does not read MAVLink data correctly, the Web front end may still open, but it will not display real-time flight controller data. Therefore, after deployment is completed, the first two things to confirm are:

• Whether the Web service is running.
• Whether port 8080 on the RK3588 has received flight controller MAVLink data.

Common inspection commands:

systemctl status robosn-ground-station

ss -ulnp | grep 8080

curl http://127.0.0.1:5173/api/flight-fast

If a development computer is used to synchronize code to the RK3588, this can also be done through a script:

powershell -File sync-to-3588.ps1 -HostName 192.168.1.66 -User amov -Restart

07

Browser Access Result

After deployment is completed, the FlyCore Web ground control station can be accessed by entering the following address in an Android browser, PC browser, or remote controller browser:

After entering the page, the system first displays the login or aircraft model selection interface, and then enters the main flight interface. In the main interface, users can view the map, 3D coordinates, attitude indicator, battery level, number of GPS satellites, flight mode, and flight controller feedback messages.

If the flight controller data link is normal, the front-end page will continuously refresh the flight controller status. If the page opens normally but the data does not change, the first step is usually to check whether the LQ-10 has forwarded the MAVLink data to port 8080 on the RK3588.

08

Demo Version and Professional Version

This article presents a demo version of a Web ground control station, mainly used to verify the feasibility of AI-assisted development for the FlyCore ground control station. The current version already supports basic telemetry display, map positioning, 3D coordinate display, attitude display, and basic command interaction, but it is not yet a complete commercial version.

To further develop it into a professional ground control station, additional functions need to be improved, including mission planning, route editing, map caching, flight logs, historical tracks, user permissions, database persistence, abnormal status alerts, flight control safety verification, multi-drone management, and device management.

From the perspective of development efficiency, however, this demo has already validated a more efficient development approach. As long as the architecture, interfaces, flowcharts, and UI prototype are well prepared in the early stage, AI tools can handle a large amount of code generation, integration debugging, and deployment work. Engineers can then focus more on system design, flight control safety logic, and on-site testing and validation.

Deployment Recommendations

For detailed deployment steps, refer to the project README. In actual operation, it is recommended to enable passwordless SSH access so that AI can remotely connect to the RK3588. Provide the project repository address to the AI and let it assist with Git download, environment configuration, service deployment, and troubleshooting. If deployment errors occur or data is not displayed, AI can continue to help analyze and fix the issue based on terminal feedback.

09

Commercial Professional Version Case

Based on the demo validation, we also used a similar approach to develop a commercial version of the Web ground control station. This project was completed in approximately two months. The development process was similar to the one described above, but more time was invested in early-stage preparation and later-stage debugging.

If a similar ground control station were developed using a traditional approach, it would typically require at least two engineers working for about one year. By using AI development tools for code generation, deployment, and debugging, the project cycle from prototype to usable system can be significantly shortened, further demonstrating the engineering efficiency of this development approach.

10

Final Notes

The hardware architecture of FlyCore is highly suitable for Web ground control station development: the RK3588 provides local computing capability, the LQ-10 provides the flight controller data link, MAVLink provides a standardized communication protocol, and the browser provides a cross-platform interactive interface. With AI development tools such as Codex, these modules can be quickly integrated to build a runnable Web ground control station demo.

This approach is not only applicable to FlyCore, but also to other unmanned systems equipped with onboard computers, network links, and standard flight control protocols. By further improving modules such as data storage, mission planning, safety control, and device management, the system can gradually evolve into a professional ground control station for real-world applications.

If a professional Web ground control station for practical applications is required, please contact a sales engineer for further discussion. The professional version will further improve functional details, user interaction experience, flight control safety verification, and adaptation to real-world application scenarios based on the demo version, making it more suitable for direct use in commercial projects.

Project Gitee repository: