Skip to main content
Unstrat
Use the up and down arrows to move through results, Enter to open, Escape to close.
Edge flight controller, Sky (Air Domain), Unstrat

Edge flight controller

Dual-IMU autopilot, open standards

Overview

An H7-class flight controller with dual redundant IMUs, magnetometers and pressure sensors, 16 PWM channels, two 8 Mbit FD CAN buses and an operating envelope of -40 to +85 degrees C. Runs ArduPilot and PX4 across multirotors, fixed wings, VTOLs, rovers and boats, with no end-user calibration required.

An autopilot a national programme can own: dual redundant sensors, an industrial -40 to +85 degree envelope, ArduPilot and PX4 support, and custom firmware development when the mission outgrows the standard build.

Unstrat represents this capability to a market only once classification and the end-user-certificate chain are confirmed. Full specifications are shared under briefing.

Capabilities

  • H7-class ARM Cortex-M7 at 480 MHz with 1 MB RAM, 2 MB flash, 32 KB FRAM and SD storage
  • Dual redundant IMUs, dual pressure sensors and dual magnetometers on an integrated system-on-module
  • 16 PWM channels, two 8 Mbit FD CAN buses, four serial ports, optional Ethernet
  • Runs ArduPilot and PX4 across multirotors, fixed wings, VTOLs, rovers, boats and general robots
  • No end-user calibration required; vibration and temperature tested
  • Futaba S.BUS, FRSky telemetry and gimbal ecosystem compatibility
  • 88 g including carrier board and aluminium enclosure, 80 x 55 x 20 mm
  • Custom firmware and carrier-board development available per programme

Specifications

TypeEdge flight controller (autopilot)
ProcessorAvailable under controlled technical briefing
MemoryAvailable under controlled technical briefing
SensorsAvailable under controlled technical briefing
I/OAvailable under controlled technical briefing
FirmwareAvailable under controlled technical briefing
PlatformsMultirotor, fixed wing, VTOL, rover, boat, general robotics
EnvironmentAvailable under controlled technical briefing
Weight & sizeAvailable under controlled technical briefing
OriginIndependent / non-aligned

Published figures appear below; configuration-specific figures are shared under briefing.

Why Unstrat: the difference

Unstrat is the authorised global representative and distributor for this capability. It is already in service with a track record behind it, so you are buying something that has done the job elsewhere, not funding a first attempt. You are not the test bed.

01

Independent, non-aligned origin, with no political exposure to any major-power ecosystem.

02

One accountable team from first briefing through delivery and in-region sustainment.

03

Open-standard autopilot: the buyer's engineers extend it instead of petitioning a vendor.

How it reaches you

Independent maker
Non-aligned manufacturer
Unstrat
Single accountable channel
End user
Government or enterprise buyer
In-region sustainment · training · classification & end-use governance
View all →

Procurement & sustainment

Classification & EUC

Classification and the end-user-certificate chain are confirmed before this capability is represented to your market.

Non-aligned origin

Sourced from an independent manufacturer: no major-power disclosure rules or political conditions.

One accountable channel

A single team responsible from first briefing through delivery: not a chain of foreign primes to integrate yourself.

In-region sustainment

Lifecycle support and operator training delivered in-region, building capability that outlasts the initial deployment.

Questions buyers ask

What is an edge flight controller?

It is the autopilot at the centre of an unmanned vehicle: the board that reads the inertial sensors, holds the aircraft on its flight plan and drives the motors and servos. Ours is an H7-class board running an ARM Cortex-M7 at 480 MHz with dual redundant IMUs, dual pressure sensors and dual magnetometers, and it runs the open ArduPilot and PX4 firmware across multirotors, fixed wings, VTOLs, rovers and boats.

See: How it compares with the Cube and PixhawkWhere it fits an ISR airframe

Does this flight controller run ArduPilot and PX4?

Yes, it runs both. That is the same open firmware the Cube Orange+, Pixhawk 6X and mRo Control Zero H7 use, so the tooling and the community are the same. Because the firmware is open standard, your engineers can extend it rather than waiting on a vendor release, and the principal offers custom firmware development per programme on top of the standard build.

See: Firmware and platform support

What temperature range can a drone flight controller handle?

Ours is stated at -40 to +85 degrees C and is vibration and temperature tested. For comparison, the Pixhawk 6X publishes the same -40 to 85 C, while the Cube Orange+ publishes a narrower -10 to 55 C and the Control Zero H7 does not publish an operating range at all. For cold-climate or desert operations that row narrows the field, so specify against the published envelope and confirm it in your own trial.

See: Temperature envelope against alternatives

How many IMUs does this autopilot have?

It carries dual redundant IMUs, plus dual pressure sensors and dual magnetometers on an integrated system-on-module. On the raw IMU count the Cube Orange+ and Pixhawk 6X publish three, so they lead there; where ours differs is the compass, where it states two magnetometers against a single onboard compass on the three competitors. Match the redundancy that matters for your airframe rather than the headline number.

See: Sensor redundancy compared

Open-standard autopilot a national programme can own and modify

That ownership is the point of an open board. It runs ArduPilot and PX4, so the firmware is not locked, and the principal offers custom firmware and carrier-board development per programme from one independent, non-aligned team. That means your own engineers extend the I/O map, the sensor mix and the firmware rather than petitioning a foreign vendor and waiting on an export decision. The mRo Control Zero H7, by contrast, lists custom carrier board support as No on its spec table.

See: Who extends the firmware and carrier boardField-assembled airframes it can fly

Flight controller for a VTOL or fixed-wing with many servo channels

It provides 16 PWM channels, two 8 Mbit FD CAN buses and four serial ports, which covers a VTOL's mixed rotor-and-control-surface layout. The Cube Orange+ publishes 14 PWM outputs and the Control Zero H7 publishes 8. Bring the full channel map, including any CAN peripherals and the number of control surfaces, to the technical review so the carrier board is scoped for the whole airframe rather than the minimum.

See: I/O and bus count compared

Autopilot that needs no end-user calibration before flight

It is stated to need no end-user calibration and is vibration and temperature tested before it ships. That matters for a unit issued to crews rather than to integrators: the board is ready to configure for the airframe without a bench calibration step for the sensors. Compass and airframe-specific setup still follow the normal ArduPilot or PX4 procedure, so confirm the setup flow for your platform in the review.

See: No-calibration design detail

Flight controller for a drone swarm running coordinated autonomy

A swarm needs a common, extensible autopilot on every airframe so the coordination layer sees one behaviour, not a different board per aircraft. This controller runs ArduPilot and PX4 with two FD CAN buses for peripherals, and the principal can develop custom firmware per programme, which is how a swarm's shared logic gets onto every node. The coordination itself lives in the collective-robotics layer above the autopilot.

See: Coordinated multi-agent autonomyFirmware you can extend across the fleet

How does this compare with a Cube Orange+ or Pixhawk 6X on processor and memory?

They sit in the same class. All run an H7 Cortex-M7 with 1 MB RAM and 2 MB flash; the Cube Orange+ clocks at 400 MHz, the Pixhawk 6X and ours at 480 MHz. Ours adds 32 KB FRAM and an SD card. The processor row does not decide the buy, so the questions that matter are the temperature envelope, the sensor redundancy mix and who can extend the firmware and carrier board.

See: Full head-to-head against the Cube and Pixhawk

We build our own airframes and need to change the carrier board layout. Can we do that with this autopilot?

That is the design intent. The controller is an integrated system-on-module on a carrier board, and the principal offers custom carrier-board development per programme from one accountable team. The mRo Control Zero H7 lists custom carrier board support as No, and while CubePilot and Holybro support customisation through their own channels, those routes end at a foreign vendor. Bring your airframe's connector, power and I/O requirements to the review so the carrier is designed to your layout rather than adapted to a fixed one.

See: Custom carrier-board development comparedAirframes designed to be reconfigured

For a sovereign drone programme, why does the autopilot's supplier nationality matter?

Because the autopilot is the aircraft's brain, and a programme that cannot modify or resupply it is not sovereign. The Cube Orange+, Pixhawk 6X and Control Zero H7 all sit with foreign vendors, so firmware changes and spares run through their release schedules and export rules. Ours comes from one independent, non-aligned team that offers custom firmware and carrier-board work, so the board can be extended and sustained inside your jurisdiction. The processor is the same class either way; the supply relationship is what differs.

See: Non-aligned origin and support line

Our airframe flies in both desert heat and mountain cold. Will one flight controller cover that range?

Ours is rated -40 to +85 degrees C and is temperature tested, which covers both extremes on paper. The Pixhawk 6X matches that range; the Cube Orange+ is limited to -10 to 55 C, which would rule it out for a cold deployment, and the Control Zero H7 publishes no range at all. A published envelope is a starting point, not a guarantee, so put the board through your own hot-and-cold soak before committing a fleet to it.

See: Operating range against the alternatives

How much redundancy do we actually get, and is dual-IMU enough against the triple-IMU boards?

Ours states dual redundant IMUs, dual pressure sensors and dual magnetometers. The Cube Orange+ and Pixhawk 6X publish three IMUs, so on the inertial count they carry one more sensor to vote against. Where ours leads is the compass, with two magnetometers on the module against a single onboard compass on the competitors, which usually depend on an external GNSS-mounted compass for a second heading source. The honest answer is that dual-IMU is standard practice for most airframes, and whether you need a third IMU depends on your safety case, so decide it against the mission rather than the datasheet.

See: Redundancy count compared

Can this flight controller carry the whole ISR mission stack, not just fly the aircraft?

It flies the aircraft and gives you the buses to hang the mission on: two 8 Mbit FD CAN buses, four serial ports and optional Ethernet for a companion computer, gimbal, GNSS and datalink. The autopilot holds the flight plan while the payload and analytics run on the peripherals it connects. For a full ISR architecture the autopilot is one layer, so plan it alongside the airframe, the sensors and the command-and-control layer rather than in isolation.

See: ISR as an architecture, not a platformThe command-and-control layer above it

We want to standardise one autopilot across multirotor, fixed-wing and rover fleets. Does this do that?

It is built for exactly that. It runs ArduPilot and PX4 across multirotors, fixed wings, VTOLs, rovers, boats and general robots, so one board and one firmware skill set covers the fleet rather than a different controller per vehicle class. Standardising also simplifies spares and training. Bring the full vehicle mix and the peripheral list to the review so the carrier board and I/O are scoped for the widest configuration you will field.

See: Platform coverage comparedThe wider unmanned architecture

Edge flight controller: questions

What is Edge flight controller?

Edge flight controller is Unstrat's Sky (Air Domain) capability: An H7-class flight controller with dual redundant IMUs, magnetometers and pressure sensors, 16 PWM channels, two 8 Mbit FD CAN buses and an operating envelope of -40 to +85 degrees C. Runs ArduPilot and PX4 across multirotors, fixed wings, VTOLs, rovers and boats, with no end-user calibration required.

How does Edge flight controller work?

Edge flight controller delivers its effect through h7-class ARM Cortex-M7 at 480 MHz with 1 MB RAM, 2 MB flash, 32 KB FRAM and SD storage, Dual redundant IMUs, dual pressure sensors and dual magnetometers on an integrated system-on-module and 16 PWM channels, two 8 Mbit FD CAN buses, four serial ports, optional Ethernet, capabilities matched to the requirement and confirmed under briefing rather than published.

Who makes Edge flight controller?

Edge flight controller is built by The Robotics & AI House, whose focus is unmanned systems, eo/ir sensors & ai video analytics. Unstrat represents The Robotics & AI House to government and enterprise buyers worldwide as an independent, non-aligned prime vendor.

Why choose Edge flight controller over a major-power alternative?

Edge flight controller is sourced from an independent, non-aligned manufacturer, so it carries no major-power disclosure rules, upgrade-locks or political ramifications. Concretely: Open-standard autopilot: the buyer's engineers extend it instead of petitioning a vendor. The capability is accountable to you, not to a foreign vendor's government and its release schedule.

How is Edge flight controller procured, and where can it be exported?

An autopilot a national programme can own: dual redundant sensors, an industrial -40 to +85 degree envelope, ArduPilot and PX4 support, and custom firmware development when the mission outgrows the standard build. Every engagement begins with a briefing, and export eligibility is confirmed per market under briefing rather than published. Where controlled capabilities are involved, the classification and end-user-certificate chain is confirmed first. Edge flight controller is then sustained in-region by one accountable team from briefing through long-term operation.

Contact us

Tell us the requirement. Specifications and the export position are confirmed in briefing, not published here.