Power budget planning for a Group-2 UAV payload is not optional bookkeeping. It is the first constraint that determines whether your edge-AI compute subsystem is even possible. We have reviewed proposals where the inference module alone was specified at 25W — on a platform with a total payload power allocation of 18W. The proposal failed before the first prototype board was fabbed.
The numbers are unforgiving: a typical Group-2 platform (maximum takeoff weight between 21 and 55 lbs) allocates 10–25W to the full payload bay. That envelope covers the EO/IR sensor, the comms subsystem, the payload controller, and any inference compute you add. Miss the budget and you either exceed the aircraft's thermal limits, trip a breaker mid-mission, or drain the battery fast enough to cut the sortie short.
Start with the Platform's Payload Power Allocation
Before selecting any component, obtain the aircraft's Interface Control Document or electrical power specification. The platform power allocation sets a hard ceiling; nothing else in the design process matters until you know that number. On platforms we have integrated against, the payload bay allocation ranges from as low as 9W on sub-3kg rotary-wing platforms to 22W on fixed-wing Group-2 vehicles designed for longer-endurance ISR missions.
The allocation you receive is typically a peak draw limit, not a sustained draw limit. Most aircraft power controllers will tolerate a brief in-rush above the rated allocation during boot — sometimes for a few hundred milliseconds — but sustained operation above the rated draw will trigger thermal protection or breaker cutoff. Design your subsystem to stay within the sustained allocation with margin. We target a 15% power headroom buffer in our own designs, which means if the allocation is 15W, our full-load draw is targeted at 12.75W or below.
Map Each Subsystem's Actual Draw
The most common power budget error we see is using datasheet typical power figures rather than measured peak draw under operational conditions. Typical figures are measured under specific conditions that rarely match field deployment. Here is a realistic breakdown for a minimal ISR payload on a mid-range Group-2 platform:
| Subsystem | Typical Draw | Peak Draw | Notes |
|---|---|---|---|
| EO/IR gimbal + sensor | 4.5W | 7.0W | Peak during slew and zoom |
| LIDAR module (optional) | 2.8W | 3.2W | Scan rate dependent |
| Payload controller / SBC | 1.8W | 3.5W | Peak during boot and heavy I/O |
| Comms module (C-band / L-band) | 2.0W | 5.5W | Peak during transmit burst |
| Edge inference module (KS-100) | 5.5W | 7.8W | Peak during multi-modal fusion at 60fps |
If every subsystem peaks simultaneously, this payload draws 27W — well over any Group-2 allocation. The critical insight is that simultaneous peak draw is extremely rare in practice. The comms module transmits in bursts; the gimbal slews intermittently; the inference engine has a stable thermal steady-state that sits below the datasheet peak. The design exercise is to model the simultaneous peak accurately and ensure the power controller's overcurrent protection is sized for the realistic worst-case, not the sum-of-maximums.
Thermal Budget Is Not the Same as Electrical Budget
A subsystem that draws 8W in steady state generates 8W of heat that must go somewhere. In a sealed payload bay with no active cooling — the typical condition for Group-2 pod designs — that heat accumulates until the ambient temperature inside the bay stabilizes at a level above the ambient air temperature. How far above depends on the bay volume, the thermal resistance of the enclosure, and the airspeed providing convective cooling over the exterior.
In our own thermal characterization testing, a sealed 250cm³ bay carrying a 7.5W constant heat load at an external air temperature of 35°C stabilizes at an internal temperature between 58°C and 72°C depending on airspeed. That is still within the KS-100's operating range of -40°C to +85°C, but it leaves limited margin. Add a second high-draw subsystem operating concurrently and the bay temperature can exceed component ratings during a slow loiter on a hot day.
This is why we specify not just peak electrical draw but thermal power dissipation curves at multiple operating points. A component that draws 7W at full inference load but throttles thermally to 4W at 75°C may underperform specification in a hot bay — not because it failed, but because the thermal environment was not accounted for in the system design.
Power Sequencing and Boot Order Matter
Many power budget analyses focus exclusively on steady-state draw and ignore boot transients. This is a mistake. At boot, multiple subsystems initialize concurrently and draw peak current simultaneously — often for 200–500ms before settling into their steady-state profiles. The sum-of-inrush at boot can be 40–60% higher than the sum-of-steady-state draws.
We've seen instances where a payload passed its steady-state power budget analysis by a comfortable margin, then tripped the aircraft's payload power controller on every cold start because boot inrush exceeded the overcurrent threshold. The fix is straightforward — a sequenced power-enable circuit that staggers subsystem startup by 100–200ms each — but it requires anticipating the problem in the design phase, not discovering it during platform integration.
The KS-100 is designed with a controlled startup ramp that limits inrush to under 1.2A peak on a 5V rail during the first 300ms of initialization. This is a deliberate design decision to play well with payload power controllers that have fast-response overcurrent protection. It is the kind of detail that does not appear on a datasheet but matters significantly during aircraft integration.
Allocating the Budget: A Working Framework
When we help integrators plan their payload power budget, we recommend the following allocation philosophy:
- Sensors first: The sensor chain (EO/IR/LIDAR) is the mission-critical hardware. Allocate its peak draw first and treat it as fixed.
- Comms second: C2 link and data link are safety-of-flight critical on many platforms. Allocate their transmit-burst peak with a realistic duty cycle model.
- Inference compute third: Edge AI is a force multiplier, but it is not safety-of-flight on most current platforms. Allocate the remaining budget to the inference module and select or configure accordingly.
- Hold 15% in reserve: Do not design to 100% of the rated allocation. Aging, temperature variation, and supply chain component tolerances will eat that margin.
Under this framework, if a platform allocates 15W and the sensor chain draws 7W peak with an 8W comms burst peak, the inference module gets at most 8W — but realistically 5–6W after the reserve buffer and duty cycle weighting. That is the budget to design against.
What This Means for Inference Architecture Selection
A 5–6W inference budget rules out most adapted commercial AI compute boards, which target 15–35W operating envelopes and are thermally designed for forced-air or liquid-cooled environments. It is the right envelope for a purpose-built NPU designed from the start around the payload power constraint.
At Kestrelsense, the 8W maximum draw of the KS-100 was not an optimization target — it was a hard input constraint that preceded every other design decision. The NPU architecture, the memory subsystem bandwidth, the clock frequencies, and the thermal design were all selected to keep the module operational at full inference load within that envelope, with no active cooling required.
Power budget planning is ultimately a system-level discipline, not a component selection exercise. The integrators who get it right start with the platform allocation, model each subsystem with peak and duty-cycle data, account for thermal accumulation in sealed bays, and design the boot sequence before they select a single component. The ones who get it wrong measure their payload components' datasheet typical figures, sum them, compare to the allocation, and discover the problems during aircraft integration when fix costs are an order of magnitude higher.
