Documentation/FlyCore i225U WikiEnglish · V1
Browse documentation
Advanced User Guide

Integration Guide for Developing the FlyCore WEB Ground Station with AI

Using the FlyCore hardware platform as an example, this article explains how to quickly build a UAV Web ground station with the help of AI development tools. Other unmanned syst…

13 min read · English documentation

Using the FlyCore hardware platform as an example, this article explains how to quickly build a UAV Web ground station with the help of AI development tools. Other unmanned systems can also follow the same technical approach, provided they have a processor with sufficient computing power and reliable network access. In the mapping and localization example for the FlyCore perception and planning computer, we mentioned that AI could take over the RK3588 onboard computer to quickly acquire and debug maps, point clouds, and localization information. Continuing with this approach, this article uses Codex to assist in developing a Web ground station for displaying flight controller data and maps, visualizing three-dimensional coordinates, and interacting with basic flight controller commands. A Web ground station offers strong cross-platform capabilities and does not depend on a specific client. It can run on Android tablets, Windows computers, RK3588 computing units, and many other devices. For the FlyCore platform, deploying the Web frontend and Python backend on an onboard or ground computer provides high development efficiency, a clear debugging path, and easy extensibility. The following sections explain how to use the Codex development tool to develop a Web ground station on the FlyCore platform.

image.png

The network topology of this system is built around the remote controller's LQ-10 video and data transmission link. A router is connected to the same subnet, giving the onboard network Internet access. The RK3588 onboard computer can therefore connect to the Internet. On this basis, cloud-based AI can remotely take over the entire onboard system.

Network Foundation for AI-Assisted Development

During actual development, the AI tool must be able to access FlyCore's onboard computer. There are two common methods:

  • Connect to the same LAN through the LQ-3/LQ-10 video and data transmission link. The remote controller, ground unit, router, and RK3588 are on the same subnet. When the router can access the Internet, a cloud-based AI tool can take over the onboard system through SSH or Web services.
  • Connect directly to FlyCore's Ethernet port. Once the IP subnet is configured and the RK3588 can access the Internet, the AI tool can likewise participate in code development, deployment, and debugging. In this link, AI does not directly control the flight controller. Instead, it helps developers write, deploy, and debug software running on the RK3588. The backend program and the MAVLink protocol are still what actually communicate with the flight controller.

Materials to Prepare Before Development

When using AI to develop an engineering project, the most important first step is not writing code, but clearly describing the software architecture, interface relationships, and interaction objectives. For this project, it is recommended to prepare four types of materials in advance:

  • Interface code
  • Interface documentation
  • UML flowcharts or system architecture diagrams
  • Interactive UI prototypes for the Web interface These materials can be provided directly to the AI as engineering context. The clearer the context, the closer the AI-generated code will be to the target and the less rework will be required later.

Interface Code

The core communication protocol of this project is MAVLink. MAVLink is a very common communication protocol in the UAV field, and AI tools can generally understand its basic structure and commonly used message types. If the project uses interface code for a specific MAVLink version, it is recommended to provide it directly to the AI instead of relying entirely on the AI to search online. The backend can use the pymavlink Python library to parse MAVLink data. It can read the MAVLink data stream output by the flight controller and parse messages such as HEARTBEAT, GPS, attitude, battery, position, and velocity into data structures that the backend program can use.

Interface Documentation

Official MAVLink documentation and common examples can serve as references that help the AI understand flight controller data. If the project has special requirements for certain message types, coordinate systems, unit conversions, or flight controller modes, it is recommended to state them clearly in the engineering documentation. For example:

  • GPS latitude and longitude usually come from GLOBAL_POSITION_INT or GPS_RAW_INT
  • Local position can come from LOCAL_POSITION_NED
  • Attitude information can come from ATTITUDE
  • Commands such as arm, disarm, takeoff, and landing are usually sent through COMMAND_LONG
  • Command execution results require attention to the COMMAND_ACK returned by the flight controller These explanations can significantly reduce the likelihood that the AI will misunderstand the protocol.

UML Flowcharts and System Architecture Diagrams

This article demonstrates a relatively simple version of a Web ground station, so the UML flowchart does not need to be overly complex. However, when developing a professional ground station, it is recommended that the architect organize the frontend interaction flow, backend data flow, flight controller command link, and exception-handling logic in advance. See the architecture plan for details. This is a simple test version, so the UML flowchart is not very complex. If you need to develop a professional ground station, the architect should carefully organize this UML flowchart. The UML flowchart includes a frontend Web interaction flowchart and a frontend-backend server interaction flowchart. You can also refer to AI-friendly code-flow diagramming tools available on the market. The more complex the code to be designed, the more detailed this part of the flowchart needs to be. This allows the AI to understand it more deeply and makes the generated code more controllable, which is very important.

Interactive UI Prototype

Figma is recommended for designing the frontend UI prototype. Figma is a mainstream cloud-based UI/UX design tool that supports prototype interactions, component management, and multi-user collaboration. For AI development tools, a Figma project file is more valuable than a static screenshot because the project file contains the layout, spacing, component hierarchy, and interaction relationships. If Codex is used to assist in generating frontend code, it is recommended to provide the complete Figma prototype project to the AI instead of only providing interface screenshots. The more detailed the prototype design, the closer the HTML, CSS, and JavaScript code generated by the AI will be to the actual requirements. The interactive prototype is available in the README of this project's Gitee repository.

Architecture Design

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

  • Client: An Android browser, PC browser, or another Web-capable terminal responsible for page rendering and user interaction.
  • Server: A Python backend running on the RK3588, responsible for hosting frontend pages, parsing MAVLink data, providing API endpoints, and handling flight controller commands.
  • Data link: The flight controller outputs MAVLink data through a serial port. The LQ-3/LQ-10 forwards the serial data as an IP:Port data stream, which the Python backend reads and parses through pymavlink. The current Demo version does not yet include a database. If flight logs, historical trajectories, user accounts, mission configurations, or other functions are required later, a database module can be added to the backend. An architecture description more closely aligned with this project is as follows: In the code implementation, the frontend mainly consists of index.html, src/*.js, and src/styles.css, while backend.py is primarily responsible for the backend. By default, the backend listens on Web service port 5173, and MAVLink data enters through UDP port 8080 (by default, the LQ-10 video and data transmission unit forwards the flight controller serial port's MAVLink data stream to this port).

image.png

UI Design and Frontend Interaction Implementation

The frontend interface is implemented based on the Figma prototype, with the goal of providing a mobile ground station-like operating experience in a browser. The current Web ground station mainly contains the following functional areas:

  • Login and aircraft model selection interface
  • Map display interface
  • RViz-style three-dimensional coordinate view
  • Attitude indicator display
  • GPS, velocity, battery, flight mode, and ARM/DISARM status bar
  • Flight controller message feedback list
  • Basic interaction buttons for arm, disarm, takeoff, landing, and other operations The frontend does not parse MAVLink directly. It obtains processed telemetry data from the backend through an HTTP API and then refreshes the interface based on that data. For example, the map module reads GPS coordinates, the RViz module reads the local position x/y/z, and the attitude indicator reads roll, pitch, yaw, and heading. Particular attention must be paid to safety during takeoff interactions. In the current design, clicking "One-Touch Takeoff" does not immediately send a takeoff command to the flight controller. Instead, a slide-to-confirm interface appears first. Only after the slide confirmation is completed does the frontend request that the backend send the takeoff command. The backend also checks whether MAVLink is online, whether the flight controller target has been identified, and whether the flight controller is already armed, and then waits for the COMMAND_ACK returned by the flight controller. The link to the Figma project can be found in the README of the project source code.

Backend Server Design

The backend server runs on the RK3588 and primarily connects the flight controller data link to the Web frontend interface. It performs three core tasks:

  • Use pymavlink to read and parse MAVLink data
  • Cache the parsed telemetry data in memory
  • Provide the data to the frontend through an HTTP API while receiving control commands from the frontend In the FlyCore system, MAVLink data is output through the flight controller serial port, converted into a network data stream by the LQ-3/LQ-10 video and data transmission module, and then sent to the RK3588. During deployment, the RK3588 IP address and UDP port must be configured in the video and data transmission module, for example:
RK3588_IP:8080
MAVLINK_URL=udpin:0.0.0.0:8080

The configuration above indicates that the Python backend listens on UDP port 8080 on the RK3588 and waits for MAVLink data forwarded by the video and data transmission module.

If QGC and the Web ground station need to receive flight controller data simultaneously on site, configure the LQ-3/LQ-10 for dual-channel forwarding:

Flight controller serial port
  → LQ-3/LQ-10 video and data transmission module
    ├─→ QGC ground station IP
    └─→ RK3588 IP:8080 → Python backend → Web frontend

If the video and data transmission module in use does not support one-to-two forwarding, a separate network link must be configured. For details, refer to the documentation for the corresponding video and data transmission product. image.png

image.png

Code Deployment

Have the AI download the relevant source code from Git and remotely log in to the RK3588 through SSH so that it can deploy the code to the RK3588. The backend server can be added to the system's default startup items so that it starts automatically at boot. The backend server must continuously read flight controller data. Make sure that the relevant flight controller data port is receiving data. If the backend cannot read MAVLink data normally, the Web frontend will not be able to display the data normally either. The process for AI to remotely take over the onboard computer is as follows:

Connect remotely to the RK3588 through SSH: amov@192.168.1.66. The password is still amov.

I have a public key on my local computer. Copy it directly to the RK3588. Give me the copy command and I will run it, so subsequent logins will be passwordless;

Yes. Run these two commands in PowerShell on your local computer:
Get-Content "$env:USERPROFILE\.ssh\id_ed25519.pub" | ssh amov@192.168.1.66 "umask 077; mkdir -p ~/.ssh; cat >> ~/.ssh/authorized_keys"

Then test passwordless access:
ssh amov@192.168.1.66 "hostname; whoami; pwd"

If your public key is not id_ed25519.pub, check first:
Get-ChildItem "$env:USERPROFILE\.ssh\*.pub"
Then replace id_ed25519.pub in the first command with the actual file name, such as id_rsa.pub. When you run the first command, you will be prompted to enter the password once: amov. After it succeeds, I will be able to deploy directly through passwordless SSH / SCP access.

The above is a screenshot of a conversation with the AI. The default SSH login for the RK3588 onboard computer is: ssh amov@192.168.1.66, password amov. Through the operations above, copy the local computer's public key to the RK3588 using commands. The AI can then take over the onboard computer through SSH without entering a password. The AI operates entirely in CLI mode and has extensive permissions on the onboard computer. This is a key step in using AI to take over UAV R&D. The AI can perform all of the following operations for you: 1: Upload the code to the RK3588, first using Git to clone it and then uploading it 2: Install Python dependencies on the RK3588 3: Configure config.env 4: Start the backend service 5: Configure systemd to start automatically at boot 6: Access http://RK3588_IP:5173 in a browser Check whether port 8080 is receiving MAVLink data If the backend does not read MAVLink data normally, the Web frontend can still open, but it will not display real-time flight controller data. Therefore, after deployment is complete, first confirm two things: 1: Whether the Web service is running 2: Whether the RK3588's port 8080 is receiving flight controller MAVLink data Common commands for checking: 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 with a script: powershell -File sync-to-3588.ps1 -HostName 192.168.1.66 -User amov -Restart

Browser Access Results

After deployment is complete, enter http://RK3588_IP:5173 in an Android browser, PC browser, or remote controller browser to access the FlyCore Web ground station. The page first opens the login or aircraft model selection interface and then enters the main flight interface. The main interface displays the map, three-dimensional coordinates, attitude indicator, battery level, number of GPS satellites, flight mode, and flight controller feedback messages. If the flight controller data link is operating normally, the frontend continuously refreshes the flight controller status. If the page opens but the data does not update, first check whether the LQ-3/LQ-10 is forwarding MAVLink data to port 8080 on the RK3588.

Demo Version and Professional Version

This article presents a Demo version of a Web ground station, primarily to verify the feasibility of using AI to assist in developing a FlyCore ground station. It already provides basic telemetry display, map positioning, three-dimensional coordinate display, attitude display, and basic command interaction capabilities, but it is not yet a complete commercial version. A professional version usually requires further improvements to the following:

  • Mission planning
  • Route editing
  • Map caching
  • Flight logs
  • Historical trajectories
  • User permissions
  • Database persistence
  • More comprehensive exception messages
  • More rigorous flight controller safety checks
  • Multi-UAV management and device management However, from the perspective of development efficiency, AI tools can already significantly accelerate the process of taking a Web ground station from a prototype to a working Demo. As long as the architecture, interfaces, flowcharts, and UI prototype are adequately prepared in advance, AI can handle a large amount of code generation, integration, and deployment work, allowing engineers to focus more on system design, flight controller safety logic, and on-site testing and verification.

Conclusion

FlyCore's hardware architecture is highly suitable for Web ground station development: the RK3588 provides local computing power, the LQ-3/LQ-10 provides the flight controller data link, MAVLink provides a standardized protocol, and the browser provides a cross-platform interaction interface. AI development tools such as Codex can quickly organize these modules into an operational Web ground station Demo. This approach applies not only to FlyCore, but also to other unmanned systems with an onboard computer, a network link, and a standard flight controller protocol. By continuing to improve data storage, mission planning, and safety control logic on this basis, the system can gradually evolve into a professional ground station for real-world applications. The browser interface is shown below:

image.png

This is the Demo Web ground station. It was only used to build a rough implementation with AI, demonstrating that this is a relatively efficient development approach. If you need a professional ground station, please contact our sales engineers. We also developed the professional ground station using a similar AI-based approach, but it required much more detailed debugging and is intended primarily as a professional ground station ready for direct commercial use. Project Gitee address: https://gitee.com/amovlab/fly-core-web-ground

Commercial Professional Ground Station Case

We spent 2 months using AI to develop a commercial version of the Web ground station. The development process was similar to the one described above, except that more time was spent on initial preparation and later debugging. Previously, developing such a ground station would have required at least 2 people and one year. This fully demonstrates the power of AI and the efficiency improvements it provides.

image.png

image.png

Deployment Notes

For details, see the README file supplied with the project. Manual deployment is not recommended. Instead, use AI to log in remotely through passwordless SSH with a public key, provide the AI with the project address, and let the AI download the project through Git and deploy it automatically. If any problems arise, you can ask the AI directly and resolve them efficiently.