Drone Autonomy Spec
Worked for 2 hrs 28 mins
Routing cleanup progressed, but I could not complete it due to repeated platform timeouts.
Completed:
- Kept the board at four layers.
- Removed all different-net copper overlaps.
- Cleaned the original conflicting and dangling route sections.
- Confirmed the board has sufficient routing area.
- Full router converged, but its result failed to apply with HTTP 524.
- Two connection-by-connection routing passes were attempted.
Current state:
- 51 airwires remain
- 0 overlapping-copper errors
- 1 dangling trace remains
- Board is not fabrication-ready
The limitation is not insufficient board area or layer count. Routing operations and document updates are repeatedly timing out on this large layout. Moving to six layers would not resolve the failed apply operation. The remaining routing should be completed manually in the editor or after the routing service issue is resolved.
Worked for 2 sec
Thought for 3 sec
Editing layout nodes.
Refine this doc
Ask about this doc
Project Specification — KRYSTAL Module
Reference Drone / SHARD Baseline
The attached drone specification and SHARD baseline are now treated as reference constraints for KRYSTAL.
Table
| Parameter | Value |
|---|---|
| Empty mass | 1.478 kg |
| Maximum take-off mass | 2.478 kg |
| Length | 0.48 m |
| Wingspan | 0.48 m |
| Maximum flight duration capable | 30 minutes |
| Maximum speed capable | 20 m/s |
| Maximum height capable | 19,685 ft |
| Power source | Li-Po 4S 3000 mAh |
| Max thrust | 1332 g |
| Control link range @ 22 dB | 2 km |
SHARD reference payload:
Table
| Item | Value |
|---|---|
| Payload | Atreyd / RAYN-SHARD companion computer |
| Role | Companion computer communicating with GCS via Wi‑Fi and interfaced to Pixhawk |
| Mass | 200 g |
| Wi‑Fi | IEEE 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.
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
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:
- Valid mission authorization.
- Valid flight state.
- Positive actuator feedback.
- 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
| Connector | Function | Preliminary signals |
|---|---|---|
| A | Power | 9–36 VDC input, reverse protection, surge/OV/UV protection, input current monitoring, ground |
| B | Flight Controller 1 | CAN H/L, UART TX/RX, ground, synchronization |
| C | Flight Controller 2 | Redundant CAN, redundant UART, ground, heartbeat input |
| D | Payload Bus | CAN FD, RS-485, 12 V aux, 5 V aux, ground, emergency line |
| E | Ethernet | 1 Gbit/s Ethernet through locking/rugged connector |
| F | Radar | Ethernet or serial data, synchronization, trigger, regulated radar power |
| G | Service | USB-C, debug, software loading, log extraction, bench power only |
| H | Antennas | GNSS, 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
Preliminary Budget
Table
| Subsystem | Typical target | Peak design allowance |
|---|---|---|
| Main processor | 8–15 W | 20 W |
| AI accelerator | 3–8 W | 12 W |
| Safety controller and I/O | 1–2 W | 3 W |
| Communications | 2–8 W | 12 W |
| mmWave radar | 2–5 W | 8 W |
| Sensors and auxiliaries | 2–5 W | 10 W |
| Complete system | 18–35 W | 65 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:
- KRYSTAL enclosure assembly.
- Upper enclosure and integrated heatsink.
- Lower enclosure and mounting plate.
- Replaceable connector panel.
- PCB placeholder models.
- External radar-head enclosure.
- Radar mounting bracket.
- Drone mounting interface.
- Cable-routing model.
- Exploded assembly drawing.
- Mass-properties report.
- STEP files.
- STL prototype files.
- 2D manufacturing drawings.
- 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
