Unmanned systems: from the component to the aircraft in the air

Heavy-lift multirotors on ArduPilot

The 17–54″ class is tuned differently from a racing quad: ArduPilot has an official parameter table by propeller size, INAV has none at all — only community experience up to 16″. We migrated a heavy hexa from INAV to CubeOrange+ and ArduPilot 4.7.1 and know where it breaks: parameter names change between firmware versions, the loader silently skips an unknown name, and “file applied” only means “file read”.

What we do: powertrain calculation and selection for the payload, wiring the flight controller on the frame with a 12S PDB, calibration in the right order (board orientation → accelerometer → level → compass → pre-arm checks), first flight with a reference log, flight analysis by the numbers. On “Gruz H-24” the analysis showed: frame and motors are even in thrust (spread within rotation groups 31–61 µs), while the machine is fighting its own reaction torque — that is mechanics, not something parameters fix. The pilot complained about “not enough thrust”; the real cause of the sluggishness was yaw.

Read more →

Long-range FPV

Betaflight and INAV, ELRS 2.4 GHz, analog video at 1.2 GHz and 5.8 GHz, digital systems. We keep bird profiles: a description of the physical machine and its reference config apart from the board, plus a registry of which controller sits on which bird. A full dump moves to another board with a compatibility check; an incomplete diff all is refused for writing — that catches half of the “mysterious” problems after a flight-controller swap.

Separately — an analog video switch driven by Betaflight and a second screen in the goggles with a map: both taken apart down to the schematic.

Read more →

Fiber-optic control

Fiber removes the radio link entirely, and with it the usual tools. We took a fiber-controlled aircraft apart down to the board level: CRSF and MSP over fiber, baud negotiation disabled, a failsafe that lands automatically on an irreversible break.

On the spool we know the physics, not the marketing: fiber is limited by bending, not tension (winding loads it to 11–22 % of proof-test; a 5 mm exit edge radius breaks it arithmetically); the peel force of a turn must be in grams, not newtons, because the adhesive sets the bend radius at the peel point; with uneven winding the first hypothesis is spool runout (one gram of imbalance at working speed gives 0.62 N, inside the working tension). We compare OTDR length with one group index, otherwise a short spool hides behind the instrument setting. One media converter — one fiber — one signal: video and control together need a multiplexer or a second fiber.

Read more →

Video pipeline, cameras, goggles

On OpenIPC boards (SigmaStar SSC338Q / SSC377D, Rockchip RV1103) camera compatibility means the driver, the ISP IQ file and the device-tree node all at once: a driver without IQ gives a kernel crash, not a “bad picture”. On the Zmey F-10 aircraft we built the IMX335 driver from upstream sources and found the parameter without which the full 2592×1944 frame is unavailable at all; measured 59.2 fps. Glass-to-glass latency we measure, not copy from a spec sheet.

On goggles — a comparison of five systems (DJI, Walksnail, HDZero, analog, OpenIPC) by inputs and openness, and a verified answer on whether a Quest 3 or Xreal / Viture AR glasses can be adapted for a pilot, and with what latency. Thermal modules 384×288 are available.

Read more →

ArduPilot / INAV / Betaflight

Three flight-controller firmware families, three different tuning cultures. We work in all three and know where each is stronger.

ArduPilot — our choice for heavy and cargo machines. We fly 4.7.1 on CubeOrange+, build the firmware from source with our own features (takeoff guard), run it in SITL with our machine’s physics, and keep passports for 297 boards and 75 frames from the project’s machine-readable sources so the configurator recognizes any aircraft without hard-coded tables.

INAV — we ran a full audit of a heavy hexa on INAV and migrated it to ArduPilot; we know what INAV lacks for the 20″-and-up class (a parameter table by prop) and where it fits: FPV with navigation, return-to-home, waypoint flight on light aircraft.

Betaflight — long-range FPV on 4.5, bird profiles with config transfer between boards, an analog video switch driven by the firmware, a feature-by-feature comparison of our configurator against Betaflight Configurator, and analysis of third-party custom builds on F405 and H743 down to the parameter and the disassembler.

Our own tools that grew out of this work:

• ArduPilot configurator. Everything that normally needs Mission Planner and knowledge of parameter names — as buttons and human words. 26 tabs, about 1,400 parameters with translation and “what it affects” notes, a protected motor test, a one-minute transmitter check wizard, log analysis with charts and a vibration spectrum, PID proposals checked on a digital twin. Windows, macOS, Android (flight controller cabled to the phone), updates arrive by themselves.
• Takeoff guard — three layers of protection against flipping on takeoff: ground-side, Lua on the SD card and C++ inside the ArduPilot firmware; verified on fourteen simulator scenarios including wind gusts and transmitter loss inside the guard window.
• AeroTab GCS — a ground station for the fiber-optic aircraft on protocols we opened and verified: RTP/H.264 video, telemetry and RC as CRSF over UDP, joystick, an aircraft emulator for work without hardware, flight log.
• Fleet server — any configurator or GCS keeps a link to the server: aircraft appear in the registry, a bench can be reached from the internet through a tunnel, logs and aircraft cards upload by themselves. No VPN needed.
• Performance calculator — weight, thrust, TWR, hover throttle, flight time, compatibility check and automatic configuration selection by target parameters.

Read more →

Reverse engineering of proprietary firmware and formats

When the vendor left no documentation, we recover it. We dump the flight controller image over DFU, identify the base and compare it against the official build by every parameter and by code: on one purchased aircraft 65 of 681 parameters were missing, all of them disabled hardware rather than removed protection; on another, a non-standard frequency indicator in the OSD turned out to be a second dBm element bound to the active CRSF antenna, and the advertised “SmartAudio” was in fact Tramp. We open vendor ground-station protocols and replace them with our own software. We take apart binary aviation data formats: obstacle, navigation database and chart formats for Garmin receivers recovered to byte-exact decoders with write-back. We hold a corpus of several thousand DJI firmware images and know how they are distributed, signed and unpacked; we rebuild DJI ecosystem applications from decompilation to a byte-for-byte match with the original and accept them on a live controller. Starlink terminals have been taken apart on our own units down to the boot chain and modem firmware: the eMMC layout, A/B slot selection and rollback in U-Boot, the antenna’s embedded processor and its firmware, the inter-process bus, the terminal’s gRPC interface; individual firmware units run in isolated emulation to confirm static findings. The public analysis corpus is more than a hundred documents cross-checked against open publications from 2021–2025.

One rule: reverse engineering is done for interoperability and on the customer’s own equipment; we do not defeat third-party protections for anyone.

Read more →

Software to aerospace standards

We can run airborne software the way aviation certification demands: DO-178C (and its Russian counterpart KT-178C), target level A. Traceability from high-level requirements through design documentation and low-level requirements down to code and channel configuration; the matrix is rebuilt on every change, otherwise it lies. Code audit for prohibited constructs tied to the standard’s clauses, MC/DC coverage, Ada metrics, vocabulary checks for regulator documents, mapping of norms across related standards. Our analysis tools are qualified as TQL-5: their output is an upper bound on problems, not certification credit — every finding is signed off by a verification engineer. We are working in an active certification project for an airborne computer, preparing packages for the regulator and replies to its findings.

Read more →

Electronics and embedded software

From the board to the firmware, with verification at every level.

• FPGA and digital signal processing — the HackRX project. Video signal decoding in VHDL for the Ettus USRP B210 SDR platform (Spartan-6): the full chain from IQ samples at 61.44 MHz to RGB, all PAL / NTSC / SECAM modes and the FM modes of FPV transmitters, bit-exact against a reference encoder; a channel model with multipath and fading in which FPV “sparklies” emerge on their own.
• RF boards. An antenna-array layout generator: impedance control from the real stackup, a feed network with equal electrical length to every element, quarter-wave matching, via stitching. Output — a KiCad project that passes DRC with zero errors, Gerber X2 with drill and pick-and-place, and an electromagnetic check of the unit cell.
• Embedded Linux. OpenIPC boards on SigmaStar and Rockchip: building kernel modules for sensors, device tree, ISP IQ files, camera bring-up, frame-rate and latency measurement. Our own services on board instead of the vendor’s.
• Flight-controller firmware. C++ in ArduPilot (takeoff guard), Lua on board, builds for a specific board from hwdef, SITL simulation before the first power-on.
• Microcontrollers and bridges. A bridge between the ground network node and the transmitter: SFP module diagnostics over SFF-8472, a protocol with two-path deduplication and a “failure = silence” principle.
• Avionics networks. Design study of an ARINC 664 / IEEE 802.1DP airborne network on FPGA and a DO-254 toolchain — from interface comparison to an implementation plan.

Read more →

Series production of UAVs

A series differs from a single machine not in quantity but in the fact that every next one is built and accepted without the person who built the first. That is exactly what we set up:

• Documentation another person can build from: the machine’s technical card, wiring diagrams for the flight controller and power section, a component specification.
• A reference instead of an opinion: the reference log of the first flight and a calibration passport; every machine in the batch is compared with it by the numbers — hover throttle, spread across arms, vibration, compass.
• Replicated tuning: the machine profile lives apart from the board, the config moves to the next aircraft with one command and a compatibility check; firmware is flashed as an image with a self-test.
• Bench: an automatic sweep of every check before roll-out, a one-minute transmitter check written into the aircraft log, a protected motor test.
• Records: an aircraft registry by board serial number, flight hours, sessions, logs; software updates reach the whole fleet by themselves.
• Production engineering: we have costed production down to the scrap threshold and know that yield is driven not by an item’s price but by its effect on scrap — for fiber winding that is spool runout and turn peel force, not the adhesive brand. Our own winding machine, a tension setup runbook, a throughput calculation for printing enclosures, an acceptance test.

Read more →

Radio reconnaissance

Receive-only: we listen to the air and understand what is in it, without transmitting or jamming.

• Video signal decoding. HackRX: receiving analog video from FPV transmitters on SDR and restoring it to a picture in real time on FPGA, including FM modes with ±2.5–4 MHz deviation as in real transmitters.
• Direction finding of Starlink terminals. Our own development of a receive-only Ku-band direction finder at 14 GHz on the user terminal’s uplink; it rests on our terminal reverse engineering: beamforming, transmission timing and per-country power tables are known from the firmware, not guessed. Array synthesis and debugging in our own tool, from geometry and radiation pattern to a manufacturable board.
• Passive radar. Design study of bistatic reception using the Starlink signal as illumination: the satellite transmits, we only receive.
• Channel and signal models. Multipath, fading, phase noise — we test the receive chain on synthetic data that is bit-exact with the reference encoder before going on air.

Read more →

Cartography and air navigation — the AeroTab projects

The AeroTab electronic flight bag and the whole data chain beneath it are ours, from the AIP text to the approach chart on screen.

• Aeronautical database. ARINC 424 from open AIP text, AIXM 5.1 export, an aerodrome mapping layer to ARINC 816 / DO-272 in PostGIS, bitemporal AIRAC cycle supersession with rollback and a change journal.
• Charts. Georeferencing of AIP charts, FMS-grade vision OCR of minimums and MSA with mandatory human verification, a SID / STAR / approach procedure viewer with a terrain-based vertical profile.
• Reference. An open catalog of aerodromes, navaids, airways, airspace and procedures on tens of thousands of pages, each with its AIRAC cycle and source; an airspace hub with search and map.
• Garmin. NavData, FliteCharts and obstacle database decoders, a database generator for receivers, synchronization of official packages and device updates from the customer cabinet.
• GIS. Our own MapLibre map, a decoder of 2GIS city data with routing over the street network, a satellite tile pipeline with recognition of area, line and point objects verified against OSM.

Read more →