FlyCore User Payload Integration Guide

For layered assembly of the complete aircraft, vibration isolation, radar and baseplate interfaces, and other details, refer to the "Structural Installation Guide" in the same directory. Connector models, pinouts, MIPI mapping, Ethernet port speed, and PoE capability are subject to the documentation, schematics, and BOM supplied with the product; this document focuses on gimbal-side connections and operating procedures.

Interface Overview

This section is intended primarily for gimbal use. Only the following four interfaces are required when using a gimbal.

Standard Interface Board and Pinout

Each connector on the standard interface board is labeled with a silkscreen and corresponds to ③ in the interface overview figure. Connect each interface according to its silkscreen label. If you need to make your own FPC cable or custom crimped wiring harness, compare the interface board pinout against the supplied schematic and BOM before fabrication. The following is a pinout diagram (use it together with the silkscreen on the physical product; the manufacturer's latest schematic shall prevail).

MIPI Interface Integration

MIPI Pinout Reference

The following pinout diagram shows the MIPI connector on the RK3588 side, corresponding to ② in the interface overview figure. It helps users verify the pins when making their own wiring harnesses or adapter boards, or when connecting to the payload side.

The MIPI interface on the X86 side does not currently support gimbal access and is not available to customers.

Key Points for MIPI Integration

Channel planning: Connect gimbals and manufacturer-supplied MIPI payloads exclusively to the RK3588 MIPI interface, and ensure that the connection matches the channel definitions in the image/drivers. Avoid mixing them with unplanned channels, which may cause configuration conflicts (refer to the project image and driver documentation).

Power-on sequence: First complete the power-distribution and grounding checks, then power on the onboard computer and gimbal, and finally verify image output and run the gimbal self-test.

Electrical and grounding: MIPI uses high-speed differential signals. Handle the reference ground and shielding layer according to the manufacturer's wiring-harness requirements to prevent ground loops or common-mode interference from affecting the image.

Software and image output

Drivers and device nodes: After power-on, confirm on the corresponding side that the sensor driver has loaded, and use ls /dev/video* or a similar command to view the available nodes. Refer to the image and device-tree documentation for the specific node numbers and multi-channel topology.

Formats and pipelines: The sensor output format (such as RAW, YUV, or NV12), resolution, and frame rate must match the system-side ISP/driver and application pipeline. After upgrading the kernel or image, retest image output and stability.

Application integration: Images can be acquired through V4L2, GStreamer, the manufacturer's SDK, or other methods. MIPI stream acquisition and gimbal control are both performed on the RK3588 side; do not connect to the X86 MIPI interface.

Alignment with the example gimbal: If you use the Example Gimbal (section at the end of this document) as a reference for MIPI installation, connect it to the RK3588 side. For stream publishing, ground-side stream access, and serial port control, see Example Gimbal (MIPI) Control and Operation.

Common MIPI Issues

No image: Check the physical connection and power supply → whether the device tree/driver is loaded → whether the pipeline points to the correct MIPI channel and /dev/video*.

No image from a gimbal after verifying the driver: Check whether MIPI was mistakenly connected to the X86 side (currently unsupported); it must be connected to the RK3588 MIPI interface.

Corrupted image/intermittent signal loss: Check wiring-harness retention and bend radius → whether the connector is loose → clock- and signal-integrity-related configurations.

Network Camera Integration

Key Points for Network Camera Integration

Network planning: Assign a static IP address to the camera or place it on the same subnet as the onboard computer to avoid DHCP conflicts. For multiple video streams, consider the switch bandwidth and onboard decoding load.

Stream acquisition: Use RTSP, ONVIF, HTTP, or the SDK as specified by the manufacturer. On the onboard side, first use ping and a port connectivity test, and then connect the application software.

Latency and synchronization: Network links introduce buffering latency. If time alignment with the flight controller or radar is required, configure NTP or hardware synchronization for the project (subject to actual capabilities).

Gimbal control: If the device is a serial gimbal that requires onboard signal conversion, it can be routed out through a GH1.25 or similar socket on the adapter board (corresponding to ③ in the interface overview figure) and connected to an external X86 serial port (refer to the silkscreen labels for the pinout, signal level, and pins). It can be planned independently from the serial node used by the Example Gimbal (MIPI), provided there is no conflict.

Common Network Camera Issues

Ping succeeds but the stream cannot be accessed: Check the URL and authentication, firewall, and the camera's concurrent-stream limit.

Stuttering or macroblocking: Check bandwidth, an excessively high bit rate, or whether port negotiation has resulted in a half-duplex or 100 Mbps bottleneck.

Heq Dual-Sensor Dual-Axis Gimbal Operating Instructions

This section uses the Example Gimbal as a reference. It describes network access, stream publishing examples, and serial port control when MIPI is connected to the RK3588 side, allowing practical comparison with the two integration methods above. X86 MIPI does not support this example. If network or streaming configurations have been changed on site, use the actual configuration.

The following assumes that the onboard RTSP service (example port 8554) has been enabled in the factory image.

Network and Login Side

All operations related to the example gimbal are performed on the RK3588 side. The default address example is shown below (if the subnet has been changed on site, use the actual configuration).

The onboard X86 side has a separate default address, 192.168.1.88, for other applications. It is unrelated to X86 MIPI gimbals (X86 MIPI does not currently support gimbals).

The PC and onboard computer must be on the same subnet or have routable connectivity before stream access or serial port debugging.

Operating Steps

• Mechanical installation and MIPI: Secure the gimbal according to the structural requirements and connect MIPI to the gimbal MIPI interface on the RK3588 side (do not connect it to the X86 MIPI interface).

• Power-on: Power on the system after completing the power-distribution and grounding checks for the gimbal and FlyCore. Wait until the system and gimbal have completed their self-tests before acquiring a stream.

• Onboard stream publishing (example): Run the command on the RK3588 side (log in via SSH at 192.168.1.66 or the on-site address). Determine the device node from the on-site ls /dev/video* output or the manufacturer's documentation. The following examples show infrared and visible-light camera stream publishing, respectively:

Example A (1280×512, UDP, published to local RTSP /2, commonly used for one channel such as infrared):

gst-launch-1.0 v4l2src device=/dev/video11 io-mode=4 ! \
video/x-raw,width=1280,height=512 ! \
mpph264enc bps=190000000 gop=1 ! \
rtspclientsink protocols=udp latency=200 location=rtsp://127.0.0.1:8554/2

Example B (1200×912, NV12, TCP, published to local RTSP /1, commonly used for one visible-light channel):

gst-launch-1.0 v4l2src device=/dev/video22 io-mode=4 ! \
video/x-raw,width=1200,height=912,format=NV12 ! \
mpph264enc ! h264parse ! \
rtspclientsink protocols=tcp latency=0 location=rtsp://127.0.0.1:8554/1

Ground-side stream access (VLC, etc.): Enter the RTSP address in "Open Network Stream" in VLC.

Usage Notes

Visible light: rtsp://192.168.1.66:8554/1

Infrared: rtsp://192.168.1.66:8554/2

The resolution, bit rate (bps), GOP, and TCP/UDP settings used for stream publishing can be adjusted based on the bandwidth and image-quality requirements. In weak-network or high-vibration environments, retest for image corruption and latency.

If the pulled stream shows a black screen, first check whether stream publishing is operating normally, and then verify that the MTU is set correctly.

General Inspection and Acceptance Recommendations

Before installation: Confirm that the connector models and pinouts match the BOM, and that the wiring harness has sufficient slack and is protected from suspended abrasion.

After power-on: Confirm that the image is stable, the resolution and frame rate meet the requirements, the gimbal limits and recentering operate normally, and the temperature rise remains acceptable during extended operation.