Drone Autonomy Spec

flux

I’ll create a structured takeover report covering both boards, architecture, completed work, current live state, known blockers, recovery history, verification gates, and the exact order a new engineer should follow.
Created a project doc

PCB Engineering Takeover Report

View Document
PCB Engineering Takeover Report 1. Purpose and release status
This is the engineering handoff for the two-board KRYSTAL drone companion system. It consolidates the design intent, current implementation, known defects, routing history, verification evidence, and the recommended recovery sequence.
Current release status: HOLD — neither board is approved for fabrication or flight.
The next engineer should treat all counts in this report as the last confirmed state and rerun live ERC/DRC/layout checks before making changes. Do not generate Gerbers until every release gate in Section 13 passes.
2. Projects Safety / power / I/O base board

flux

Created the comprehensive PCB Engineering Takeover Report.
It covers:
  • Both project links and board responsibilities
  • Current CM5 and S32K344 architecture
  • Power, camera, radar, autopilot, Wi‑Fi, FHSS and SIYI interfaces
  • Board dimensions, stackups and enclosure direction
  • Completed fixes and verified checks
  • Routing-service failure and recovery history
  • Known footprints, software and regulatory risks
  • Recommended takeover sequence
  • Fabrication-release gates
  • Immediate first-day checklist and required engineer deliverables
The report clearly marks both boards HOLD for fabrication until routing, interface freeze, DRC, thermal, software and mechanical validation are complete.
Review takeover report
Audit live board states
Prepare migration package
Freeze external interfaces
Sign up to send

Files

Schematic

Layout

3D View

Project Specification — KRYSTAL Module
Reference Drone / SHARD Baseline
The attached drone specification and SHARD baseline are now treated as reference constraints for KRYSTAL.

Table

ParameterValue
Empty mass1.478 kg
Maximum take-off mass2.478 kg
Length0.48 m
Wingspan0.48 m
Maximum flight duration capable30 minutes
Maximum speed capable20 m/s
Maximum height capable19,685 ft
Power sourceLi-Po 4S 3000 mAh
Max thrust1332 g
Control link range @ 22 dB2 km
SHARD reference payload:

Table

ItemValue
PayloadAtreyd / RAYN-SHARD companion computer
RoleCompanion computer communicating with GCS via Wi‑Fi and interfaced to Pixhawk
Mass200 g
Wi‑FiIEEE 802.11ac/a/b/g/n dual-band, 2.412–2.472 GHz or 5.15–5.825 GHz, 2 dBi dual-band antenna
KRYSTAL implication: KRYSTAL should preserve or improve the SHARD companion-computer role while staying compact and weight-conscious. The 200 g SHARD mass is a useful reference target for the KRYSTAL electronics stack, excluding any external gimbal/camera payloads unless explicitly integrated.
Status: Draft v0.1
Project: KRYSTAL airborne autonomy, guidance, and payload-coordination module
Purpose: Replace the prior SHARD architecture with a modular companion-computer and safety-controller platform for drones.
1. Project Overview
KRYSTAL is a compact drone companion autonomy and payload-management module. It is intended to connect to an existing flight controller and provide swarm coordination, GPS-denied navigation support, mmWave-assisted relative positioning, cooperative payload transport, payload monitoring, actuator control, logging, and secure inter-drone communications.
KRYSTAL is not the primary flight controller. PX4, ArduPilot, or a proprietary autopilot remains responsible for stabilization and baseline flight safety. KRYSTAL acts as an independent autonomy, guidance, communications, and payload-management computer.
2. Intended Use
  • Installed on autonomous drones and multi-drone cooperative-lift aircraft.
  • Used for prototype validation first, then evolved toward rugged production hardware.
  • Must support flight-controller-independent integration.
  • Must tolerate vibration, dust, rain, salt mist exposure, and outdoor thermal conditions.
  • Must support modular radio, radar, compute, and payload-interface configurations.
3. What the Device Should Do
  • Coordinate multiple drones in a swarm or cooperative-lift group.
  • Exchange drone state, payload state, energy reserve, formation assignment, and fault status.
  • Assist navigation when GPS is unavailable or degraded.
  • Process mmWave radar data for relative positioning, obstacle detection, payload tracking, and terminal guidance.
  • Monitor payload sensors including cable tension, IMU, load cells, encoders, limit switches, latch status, and temperature.
  • Control payload-related actuators including PWM outputs, digital outputs, winches, servos, high-current switched outputs, payload power, and emergency release.
  • Supervise health of the main compute system and activate safe states if failures occur.
  • Provide secure communications, logging, diagnostics, and software update support.
4. Main Features
  • Linux-capable main processing unit.
  • Independent real-time safety and payload controller.
  • External mmWave radar support for first prototype.
  • Dual flight-controller links.
  • Multiple CAN/CAN FD networks with safety-critical traffic separated from motor-controller traffic.
  • UART/MAVLink 2 secondary flight-controller interface.
  • Gigabit Ethernet for high-bandwidth sensors and development.
  • Modular radio interface for Wi-Fi mesh, private LTE/5G, Sub-GHz, UWB, proprietary SINE radio, or wired test link.
  • USB-C service/debug/log extraction connector.
  • Rugged power input, protected I/O, and locking external connectors.
  • Passive thermal path to CNC aluminium enclosure.
5. System Architecture
Recommended first prototype architecture: two-board KRYSTAL assembly with external radar evaluation platform.
Diagram



  
    
  
  
    
  













































Aircraft Power 9-36 VDC
Protection + Power Management
Board 1: Compute + Communications
Board 2: Safety + Payload I/O
Protected Aux Power Outputs
RAM
Industrial Storage
Optional AI Accelerator
Gigabit Ethernet
Modular Radio Interface
Secure Element
USB-C Service
CAN 1: Flight Controller + Navigation
CAN 2: Payload Sensors + Actuators
CAN 3: Redundancy / Peripherals
Dual UART / MAVLink
Protected Digital / PWM / Analog I/O
Independent Emergency Release
External TI mmWave Eval Radar
PX4 / ArduPilot / Proprietary Flight Controller
Payload Sensors + Actuators
6. Hardware Subsystems
6.1 Main Compute and Communications Board
Purpose: high-level autonomy, sensor fusion, radar processing, communications, logging, updates, and mission management.
Preliminary requirements:
  • Multicore ARM-class or equivalent application processor.
  • Linux-capable operating environment.
  • Hardware floating-point acceleration.
  • Minimum 4 GB RAM; preferred 8 GB RAM.
  • Minimum 32 GB industrial storage.
  • Secure element or hardware security module.
  • Hardware watchdog path supervised by safety controller.
  • Optional AI accelerator for visual navigation, object classification, and sensor fusion.
6.2 Independent Safety and Payload Controller Board
Purpose: remain operational independently of the main compute board and enforce safe payload behavior.
Preferred controller class:
  • STM32H7, NXP i.MX RT, or equivalent.
  • Dual CAN or CAN FD minimum; design target supports more CAN allocation where needed.
  • Multiple UART, SPI, and I2C buses.
  • Hardware timers and PWM outputs.
  • Independent watchdog.
  • Secure boot capability.
  • Operating temperature at least -40°C to +85°C.
Responsibilities:
  • Payload release control.
  • Winch control.
  • Servo and actuator management.
  • Cable-tension monitoring.
  • Emergency payload isolation.
  • Power sequencing.
  • Flight-controller heartbeat monitoring.
  • Main compute watchdog supervision.
  • Safe-state activation.
6.3 mmWave Guidance Subsystem
First prototype recommendation: use external TI mmWave evaluation radar instead of placing a custom mmWave radar on the KRYSTAL PCB.
Reference direction:
  • 60–64 GHz antenna-on-package radar such as TI IWR6843AOP family.
  • Manufacturer evaluation platform for early point-cloud access and software development.
External radar interface target:
  • Automotive Ethernet or standard Ethernet.
  • Synchronization line.
  • Trigger input/output.
  • Regulated radar power output.
  • Optional CAN FD fallback.
  • Locking miniature connector.
6.4 Payload Sensing and Actuation
Sensor inputs should support:
  • Four to eight cable-tension sensors.
  • Payload IMU.
  • Payload GNSS receiver.
  • Load cells.
  • Winch encoders.
  • Motor-current sensing.
  • Limit switches.
  • Payload-presence sensor.
  • Latch-status sensor.
  • Temperature sensors.
  • Optional radar or optical payload tracker.
Actuator outputs should support:
  • Four protected PWM outputs.
  • Four protected digital outputs.
  • Two high-current switched outputs.
  • Two reversible winch-control interfaces.
  • Two servo interfaces.
  • One independent emergency-release circuit.
  • One payload power enable.
  • One auxiliary power enable.
Payload release must require:
  1. Valid mission authorization.
  2. Valid flight state.
  3. Positive actuator feedback.
  4. Safety-controller approval.
Emergency release must use an independent hardware path with configurable dual-condition logic to reduce accidental activation risk.
7. Interfaces and Connections
External Connectors

Table

ConnectorFunctionPreliminary signals
APower9–36 VDC input, reverse protection, surge/OV/UV protection, input current monitoring, ground
BFlight Controller 1CAN H/L, UART TX/RX, ground, synchronization
CFlight Controller 2Redundant CAN, redundant UART, ground, heartbeat input
DPayload BusCAN FD, RS-485, 12 V aux, 5 V aux, ground, emergency line
EEthernet1 Gbit/s Ethernet through locking/rugged connector
FRadarEthernet or serial data, synchronization, trigger, regulated radar power
GServiceUSB-C, debug, software loading, log extraction, bench power only
HAntennasGNSS, swarm radio, optional LTE/5G, optional UWB through locking RF connectors
CAN Allocation
  • CAN 1: flight controller and navigation.
  • CAN 2: payload sensors and actuators.
  • CAN 3: redundancy or external peripherals.
  • CAN 4 optional: ESC and propulsion telemetry.
Motor-controller traffic should not share the same CAN bus as safety-critical payload and navigation messages.
8. Power and Runtime Expectations
  • Main aircraft input: 9–36 VDC nominal.
  • Recommended aircraft bus: 12 V or 24 V.
  • USB-C is for service, debug, log extraction, and bench use only; it is not the primary flight power input.
  • Complete system normal objective: below 35 W.
  • Short-duration peak design allowance: 65 W.
  • Payload motors, winches, and high-current actuators must receive aircraft power through separate protected circuits and must not draw operating power through the KRYSTAL PCB.
9. Power Tree and Power Budget
Preliminary Power Tree
Diagram



  
    
  
  
    
  
























9-36 VDC Aircraft Input
Reverse / Surge / OV / UV Protection
Input Current + Voltage Monitoring
Protected 12 V Aux Rail
5 V System / Aux Rail
3.3 V Logic Rail
Compute Board Local Rails
Safety MCU + Logic
Sensor / I/O Logic
USB-C Service Power Domain
Regulated Radar Power Output
Protected Actuator / Payload Power Enables
Preliminary Budget

Table

SubsystemTypical targetPeak design allowance
Main processor8–15 W20 W
AI accelerator3–8 W12 W
Safety controller and I/O1–2 W3 W
Communications2–8 W12 W
mmWave radar2–5 W8 W
Sensors and auxiliaries2–5 W10 W
Complete system18–35 W65 W
Detailed regulator selection, thermal derating, input surge limits, hold-up behavior, fusing, and connector current ratings remain open until the aircraft power environment and selected compute platform are known.
10. Manufacturing and Assembly Expectations
  • First prototype: CNC aluminium enclosure with passive thermal path.
  • Production options: magnesium or aluminium enclosure, hard-anodized external finish, conductive internal surface for EMC control.
  • Conformal-coated PCB expected.
  • Replaceable external connector harnesses preferred.
  • Two-board internal architecture with two high-reliability board-to-board connectors between boards so power and safety signals do not depend on one connector.
  • Test points required for all power rails, programming/debug interfaces, critical buses, watchdog, reset, emergency release, and actuator outputs.
  • Layer count and PCB stackup TBD; likely more than a simple 2-layer board due to EMC, power, Ethernet, RF/radio, and dense processing requirements.
11. Firmware-Relevant Hardware Requirements
Main Processor Software
Runs:
  • Swarm manager.
  • Navigation fusion.
  • Radar processing.
  • Payload estimation.
  • Mission manager.
  • Communications.
  • Logging.
  • User interface and configuration.
  • Software update manager.
Safety Controller Firmware
Runs independently:
  • Watchdog.
  • Payload actuator state machine.
  • Emergency logic.
  • Power monitoring.
  • Flight-controller heartbeat.
  • Cable-tension limits.
  • Winch limits.
  • Safe shutdown.
  • Independent fault reporting.
Hardware must ensure that failure of the main processor cannot directly activate, release, or move a payload.
12. Physical Design Expectations
Target Module Dimensions
  • Length: 95 mm.
  • Width: 65 mm.
  • Height: 22 mm excluding connectors.
  • Maximum installed height: 28 mm.
  • Mounting-hole pattern: 80 mm × 50 mm.
  • Four M3 mounting points.
Target Mass
  • Base module without external radar: less than 220 g.
  • Preferred base module target: 160–190 g.
  • External radar head: less than 80 g.
  • Combined target: less than 280 g.
Environmental Targets
  • IP65 minimum.
  • IP67 preferred.
  • Operating temperature: -30°C to +70°C.
  • Storage temperature: -40°C to +85°C.
  • Resistance to multirotor vibration, dust, rain, and salt mist.
  • Passive cooling only; no fan.
CAD Reservations
Mechanical CAD must reserve:
  • Clear radar field of view.
  • RF antenna keepout zones.
  • Minimum cable bend radius.
  • Connector removal space.
  • Thermal contact areas.
  • Gasket compression surfaces.
  • Pressure vent location.
  • Access to service connector.
  • Access to status LEDs during bench testing.
  • No metallic fasteners in radar radiation cone.
  • Minimum 2 mm enclosure wall around mounting points.
  • Replaceable connector panel if practical.
13. Thermal Design Expectations
  • Main processor should contact top enclosure through a machined thermal boss, thermal interface material, internal heat spreader, and external enclosure fins.
  • Radar must have a separate thermal path and must not be positioned directly above the main processor.
  • No thermal throttling during normal operation.
  • Processor junction margin target: at least 15°C under worst-case normal conditions.
  • Surface-temperature target: below 70°C.
  • Temperature monitoring needed on processor, radar, power supply, and enclosure.
  • Automatic load reduction before critical shutdown.
14. Status Indicators
Externally visible indicators should cover:
  • Power.
  • Main processor.
  • Safety controller.
  • Flight-controller link.
  • Swarm link.
  • Payload status.
  • Fault state.
Indicators should support software dimming or disablement.
15. Important Design Decisions
  • Use a two-board architecture: compute/communications board plus safety/navigation/payload-I/O board.
  • Use an independent safety controller that remains operational during main compute reboot or failure.
  • Use external mmWave radar evaluation hardware for the first prototype to reduce custom RF risk.
  • First-prototype platform direction: industrial i.MX8M Plus SOM for compute, with Variscite VAR-SOM-MX8M-PLUS as the primary engineering direction and Toradex Verdin iMX8M Plus as a strong alternate.
  • First-prototype safety-controller direction: NXP S32K344EHT1VPBST, with STM32H753-class MCU as a faster ecosystem fallback.
  • Keep KRYSTAL flight-controller independent.
  • Keep motor-controller CAN traffic separate from safety-critical payload/navigation traffic.
  • Use USB-C only for service/development, not as primary flight power.
  • Design as a modular platform so compute, radio, radar, AI accelerator, navigation sensors, and payload interface can evolve independently.
16. Assumptions
  • First prototype will prioritize risk reduction over minimum size.
  • External radar head will be used before custom radar PCB development.
  • Exact main processor is not selected yet.
  • Exact SINE radio module and interface are not selected yet.
  • Exact rugged connector family is not selected yet.
  • External radar base-board connector is now selected as DEUTSCH DT13-08PA for power/control; the radar-head voltage, continuous/peak current, startup capacitance, Ethernet physical interface, and sync/trigger/status electrical levels remain mandatory confirmation items.
  • Aircraft power input transients are not yet defined.
  • Environmental qualification target is not yet finalized.
  • Detailed safety certification target is not yet finalized.
  • Winch voltage/current and maximum payload mass are not yet finalized.
17. Open Engineering Decisions
  • Exact main processor.
  • Exact SINE radio module and interface.
  • Internal or external mmWave radar for later production revision.
  • Required radar field of view.
  • Required detection and guidance range.
  • Number of drones in one cooperative-lift group.
  • Maximum shared payload mass.
  • Number of cables per drone.
  • Winch voltage and current.
  • Aircraft power-bus voltage distribution and transient limits.
  • Required IP rating: IP65 minimum vs IP67 preferred.
  • Final connector family.
  • Required environmental qualification standard.
  • Encryption and secure-key architecture.
  • Need for integrated visual-navigation cameras.
  • Need for LTE/5G.
  • Need for onboard AI accelerator.
18. First Prototype Configuration
Recommended first prototype:
  • Two-board KRYSTAL architecture.
  • Main Linux companion computer.
  • Independent STM32H7-class safety controller.
  • External TI mmWave evaluation radar.
  • Dual CAN interface.
  • Dual UART interface.
  • Gigabit Ethernet.
  • USB-C service port.
  • Modular SINE radio interface.
  • Four load-cell inputs.
  • Two winch interfaces.
  • Four actuator outputs.
  • External payload IMU.
  • CNC aluminium enclosure.
19. Initial CAD Deliverables
The CAD engineer should produce:
  1. KRYSTAL enclosure assembly.
  2. Upper enclosure and integrated heatsink.
  3. Lower enclosure and mounting plate.
  4. Replaceable connector panel.
  5. PCB placeholder models.
  6. External radar-head enclosure.
  7. Radar mounting bracket.
  8. Drone mounting interface.
  9. Cable-routing model.
  10. Exploded assembly drawing.
  11. Mass-properties report.
  12. STEP files.
  13. STL prototype files.
  14. 2D manufacturing drawings.
  15. Environmental sealing diagram.
20. Change Notes
v0.1
  • Created from the initial KRYSTAL architecture and CAD input brief.
  • Captured first prototype recommendation: two-board KRYSTAL architecture with external mmWave evaluation radar.
  • Captured major power, mechanical, thermal, interface, safety, and open-decision requirements.
v0.1 platform-selection update
  • Added first-prototype platform direction: Variscite VAR-SOM-MX8M-PLUS industrial i.MX8M Plus SOM primary compute direction; Toradex Verdin iMX8M Plus alternate; Raspberry Pi CM4 only as a bench/software fallback.
  • Added safety-controller direction: NXP S32K344EHT1VPBST primary; STM32H753-class MCU as a quick-prototype fallback.

  • Reference Drone / SHARD Baseline

  • 1. Project Overview

  • 2. Intended Use

  • 3. What the Device Should Do

  • 4. Main Features

  • 5. System Architecture

  • 6. Hardware Subsystems

  • 6.1 Main Compute and Communications Board

  • 6.2 Independent Safety and Payload Controller Board

  • 6.3 mmWave Guidance Subsystem

  • 6.4 Payload Sensing and Actuation

  • 7. Interfaces and Connections

  • External Connectors

  • CAN Allocation

  • 8. Power and Runtime Expectations

  • 9. Power Tree and Power Budget

  • Preliminary Power Tree

  • Preliminary Budget

  • 10. Manufacturing and Assembly Expectations

  • 11. Firmware-Relevant Hardware Requirements

  • Main Processor Software

  • Safety Controller Firmware

  • 12. Physical Design Expectations

  • Target Module Dimensions

  • Target Mass

  • Environmental Targets

  • CAD Reservations

  • 13. Thermal Design Expectations

  • 14. Status Indicators

  • 15. Important Design Decisions

  • 16. Assumptions

  • 17. Open Engineering Decisions

  • 18. First Prototype Configuration

  • 19. Initial CAD Deliverables

  • 20. Change Notes

  • v0.1

  • v0.1 platform-selection update