Drone Autonomy Spec
Hello, that is good news, can you complete routing on this board using the four layers?
Thought for 19 sec
Yes. I’ll keep the four-layer stackup, clean the dangling/overlapping copper first, then route the remaining connections and iterate until the board is either clean or a specific connection proves unrouteable as placed.
Worked for 10 mins 1 sec
The board has ample room, but the current route contains a small set of conflicting vias/traces. I’m deleting only those offending segments, then I’ll reconnect the resulting airwires cleanly.
Worked for 1 hr 22 mins
Conflicting copper is cleared and the final dangling stub has been removed. The preflight service is timing out on this large routed board, so I’m proceeding with one bounded cleanup route pass and will validate the result independently afterward.
Thought for 53 mins 30 sec
The cleanup router converged, but the platform again failed while applying its result. I’m switching to deterministic, connection-by-connection routing for the remaining airwires so completion no longer depends on the failing apply endpoint.
Working for 18 mins 30 sec...
Refine this doc
Ask about this doc
Block-Level Electrical Architecture — KRYSTAL Module
Drone Platform Reference Constraints
The reference drone baseline is a compact 0.48 m class aircraft with 4S 3000 mAh LiPo power, 2.478 kg MTOM, 30 min target flight duration, and SHARD companion-computer mass of 200 g. KRYSTAL should remain compact and mass-conscious and should preserve the SHARD role: companion compute interfaced to Pixhawk/autopilot and GCS over Wi‑Fi/data links.
Status: Draft v0.1
Source: Project Specification — KRYSTAL Module v0.1
Scope: First-prototype electrical architecture for a two-board KRYSTAL module with external mmWave radar.
Source: Project Specification — KRYSTAL Module v0.1
Scope: First-prototype electrical architecture for a two-board KRYSTAL module with external mmWave radar.
1. Architecture Intent
KRYSTAL should be implemented as two cooperating electrical assemblies:
-
Board 1: Compute and Communications Board
Handles Linux compute, high-bandwidth data, storage, swarm communications, radar data ingestion, logging, and secure updates. -
Board 2: Safety, Navigation, and Payload I/O Board
Handles real-time supervision, flight-controller links, payload sensors, actuator interfaces, power sequencing, watchdogs, and independent emergency-release logic.
The safety board must remain powered and functional if the compute board reboots, locks up, or is intentionally powered down.
2. Top-Level Electrical Block Diagram
Diagram
3. Board Partitioning
Board 1: Compute and Communications
Primary functions:
- Linux application processing.
- Swarm coordination and mission software.
- High-bandwidth Ethernet and radar data handling.
- Storage and diagnostics.
- Radio-module host interface.
- Secure software update and key storage support.
- USB-C service access.
Recommended electrical blocks:
Table
| Block | Purpose | Notes |
|---|---|---|
| Main compute module or SOM | Linux compute platform | Exact processor TBD; choose industrial-temperature capable module if possible |
| RAM | Runtime memory | Minimum 4 GB; preferred 8 GB |
| Industrial storage | Logs, OS, mission data | Minimum 32 GB; eMMC or NVMe depends on compute choice |
| Secure element | Hardware-backed identity and keys | Connected to compute and optionally safety MCU |
| Ethernet PHY or switch | External Ethernet, radar, service network | Decide between 1G standard Ethernet and 100/1000BASE-T1 for radar |
| Radio module interface | Swarm communication modules | M.2 Key E or custom board-to-board connector |
| USB-C service interface | Development, logs, software loading | Not primary flight power |
| Dual remote-camera vision input | Front/down guidance cameras on drone body | Prefer GMSL2 remote camera links; keep CSI-2 local near compute SOM |
| Debug/programming | Factory and engineering access | Must remain accessible in enclosure or via service connector |
Primary functions:
- Independent safety supervision.
- Flight-controller communication.
- Payload sensor acquisition.
- Actuator and winch command interfaces.
- Compute-board watchdog and reset/power control.
- Emergency release interlock and safe-state activation.
Recommended electrical blocks:
Table
| Block | Purpose | Notes |
|---|---|---|
| Safety MCU | Real-time control and supervision | STM32H7-class or i.MX RT-class target |
| CAN FD transceivers | Flight controller, payload, redundancy | Isolate where practical for external rugged buses |
| Autopilot connectors | Easy PX4/ArduPilot wiring | Added JST-GH CAN and TELEM/MAVLink connectors in schematic |
| UART transceivers | MAVLink, GPS, debug, external equipment | Hardware flow control preferred for flight-controller UART |
| RS-485 transceivers | Robust payload sensors | Biasing, termination, ESD protection needed |
| Load-cell AFE | Cable tension sensing | Four channels minimum, scalable to eight |
| Analog sensing | Current, voltage, temperature, 0-3.3 V sensors | Include filtering and input protection |
| Digital input protection | Limit switches, latch status, payload presence | ESD, surge, debounce, optional isolation |
| Protected outputs | PWM, digital outputs, power enables | Current-limited and fault-monitored where practical |
| Winch interface | Two reversible winch-control interfaces | Exact voltage/current TBD; likely external power stage or driver interface |
| Emergency release hardware | Independent release path | Dual-condition logic; not directly controlled by Linux compute |
| Watchdog and power sequencing | Supervise compute board | Safety MCU can reset or power-cycle compute domain |
4. Power Architecture
Electrical Power Domains
KRYSTAL should use separate power domains so compute failures do not disable safety-critical functions.
Table
| Domain | Source | Loads | Notes |
|---|---|---|---|
| Aircraft input | 9-36 VDC | Entire module input | Requires reverse, surge, overvoltage, undervoltage, fuse/current limit |
| Protected intermediate | Post-protection bus | Regulators, aux switching | Voltage depends on regulator strategy and aircraft bus |
| Compute domain | Main DC/DC rails | Main processor, RAM, storage, Ethernet, radio | Can be reset or power-cycled by safety board |
| Safety domain | Always-on regulated rail | Safety MCU, watchdog, emergency logic, critical sensing | Must remain alive during compute reboot |
| I/O logic domain | 3.3 V and possibly 5 V | Transceivers, sensors, level shifting | Protected from external connector faults |
| 5V_CAN_LOCAL | Local LM5013-Q1 buck | CAN transceiver VCC and autopilot connector VREF/accessory pins | Added in schematic; budget 0.25 A nominal / 0.5 A provisional max; not autopilot main power |
| Radar power | Regulated switched output | External radar head | Current rating TBD after radar platform selection |
| Payload auxiliary | 12 V and 5 V protected outputs | Payload sensors and auxiliaries | Do not power high-current payload motors through PCB |
| Actuator power switching | Protected control path | Enables, servos, release, winch interface | High-current loads should use separate protected aircraft power path |
Power Tree Diagram
Diagram
Preliminary Power Requirements
- Design for 65 W short-duration peak at module level.
- Target normal consumption below 35 W.
- Safety domain must be sized independently and remain stable during compute inrush or reboot.
- Add test points for every rail and enable signal.
- Add telemetry for input voltage/current, major rail voltages, regulator temperature, and fault states.
5. External Interface Architecture
Table
| Interface | Board | Electrical recommendation | Main purpose |
|---|---|---|---|
| Power input | Board 2 or power mezzanine | 9-36 V protected DC input | Aircraft bus input |
| Flight Controller 1 | Board 2 | CAN FD plus UART with optional isolation | Primary PX4/ArduPilot/proprietary link |
| Flight Controller 2 | Board 2 | Redundant CAN/UART plus heartbeat | Redundant flight-controller link |
| Payload bus | Board 2 | CAN FD, RS-485, aux power, emergency line | Payload sensors and smart actuators |
| Ethernet | Board 1 | 1G Ethernet, rugged connector | External data, development, high-bandwidth equipment |
| Radar | Board 1 and Board 2 | Ethernet data plus sync, trigger, power | External mmWave radar head |
| USB-C service | Board 1 | USB data, debug, bench power only | Software loading and logs |
| Antennas | Board 1 | Locking RF connectors | GNSS, swarm radio, optional LTE/5G/UWB |
| Load cells | Board 2 | Differential analog AFE | Cable-tension measurement |
| Actuators | Board 2 | Protected PWM/digital/power-control interfaces | Release, winches, servos, payload control |
6. Compute to Safety Interconnect
Two high-reliability board-to-board connectors are recommended between Board 1 and Board 2. Split redundant safety-critical signals across both connectors where possible.
Minimum interconnect signals:
Table
| Signal group | Direction | Purpose |
|---|---|---|
| Power rails | Board 2 to Board 1 | Supply compute board domains |
| Power enable | Board 2 to Board 1 | Safety MCU controls compute power sequencing |
| Reset | Board 2 to Board 1 | Safety MCU can reset compute domain |
| Heartbeat | Board 1 to Board 2 | Compute proves liveness to safety MCU |
| Health/fault | Both | Fault reporting and safe-state coordination |
| High-speed data | Board 1 to Board 2 or shared | Optional Ethernet/SPI/UART/CAN link for commands and telemetry |
| Time sync | Both | Timestamp alignment for sensor fusion and logs |
| Emergency inhibit/status | Board 2 dominant | Prevent compute from directly driving release hardware |
| Debug/service | Both | Manufacturing and development access |
Preferred behavior:
- Safety MCU boots first.
- Safety MCU validates input power and basic hardware state.
- Safety MCU enables compute power.
- Compute sends heartbeat after boot.
- If heartbeat is lost, safety MCU enters defined degraded or safe mode.
7. Safety-Critical Control Boundaries
The Linux compute system may request payload actions, but must not directly energize emergency release, winch motion, or high-current outputs. Safety-controller approval is required.
Required gating model:
Diagram
Design rule:
- Main compute can command only through safety MCU.
- Safety MCU owns final output enable.
- Emergency release path must have hardware interlocks and should remain analyzable without Linux software.
8. Data and Control Buses
CAN Allocation
Schematic status: CAN1 is now exposed on a JST-GH-style autopilot CAN connector for easy flight-controller connection. CAN2 remains available for payload/redundant allocation. CAN transceiver VCC and autopilot connector VREF pins are now powered from local 5V_CAN_LOCAL rather than requiring imported 5 V through the mezzanine.
Table
| Bus | Role | Notes |
|---|---|---|
| CAN 1 | Flight controller and navigation | Safety-critical messages; avoid ESC traffic |
| CAN 2 | Payload sensors and actuators | Cable tension, smart payload modules, actuator status |
| CAN 3 | Redundancy or external peripherals | Expansion or redundant flight-controller path |
| CAN 4 optional | ESC and propulsion telemetry | Keep separate because high-volume ESC traffic can saturate bus |
Other Buses
Table
| Bus | Use |
|---|---|
| Ethernet | Radar data, external data, service, development, high-bandwidth sensor links |
| GMSL2 + local MIPI CSI-2 | Remote front/down cameras for terminal guidance, optical flow, and GPS-denied navigation; compute-side only; FPD-Link III remains fallback |
| UART | MAVLink 2, GNSS, debug, external serial equipment |
| RS-485 | Rugged payload sensor networks and longer cable runs |
| SPI | Local sensors, ADCs, secure element, expansion as needed |
| I2C | Low-speed board sensors, temperature monitors, configuration EEPROMs |
| PWM/timers | Servos, winch control signals, timing capture, pulse/frequency inputs |
| ADC | Analog 0-3.3 V sensors, current/voltage monitoring, conditioned load cells |
Load-Cell AFE Allocation
Schematic status: first cable-tension/load-cell channel added using ADS1232IPW. It uses a ratiometric 3.3 V bridge excitation/reference for compact first-prototype capture, gain 128, 10 SPS, and a 6-pin JST-GH load-cell connector. Upgrade to a clean 5 V analog excitation rail if final load-cell accuracy/noise requirements demand it.
9. Protection and Isolation Strategy
External connectors should be treated as fault-entry points.
Baseline protection targets:
- ESD protection on all external signal lines.
- Reverse-polarity protection on aircraft power input.
- Surge/transient suppression at input and rugged external interfaces.
- Overvoltage and undervoltage cutoff on main input.
- Current limiting or eFuse on protected auxiliary outputs.
- CAN and RS-485 common-mode protection and optional galvanic isolation.
- Input filtering and clamping for analog sensor lines.
- Protected high-side or low-side switches for actuator and aux outputs.
- Fault telemetry routed to safety MCU.
Isolation priority:
- Flight-controller CAN/UART where practical.
- Payload bus and long cable interfaces.
- High-current actuator control feedback.
- Radar/external Ethernet as required by installation and EMC testing.
10. First-Prototype Electrical Build Order
Recommended schematic build order:
- Power input and protection: aircraft input, fuse/eFuse, reverse protection, surge protection, UV/OV, current monitor.
- Always-on safety rail: regulator, safety MCU, clock, reset, debug, watchdog.
- Safety communication interfaces: CAN FD, UART, RS-485, heartbeat/sync lines.
- Compute power control: enable/reset/power-good interface from safety MCU to compute domain.
- Compute board interfaces: compute module/SOM, storage, secure element, Ethernet, USB-C service, radio connector.
- Vision camera interfaces: front and downward drone-body camera links on compute board using preferred GMSL2 deserializer, with short local CSI-2 into the compute SOM.
- Radar connector: Ethernet, sync, trigger, regulated power, optional CAN fallback.
- Payload sensing: load-cell AFE, analog inputs, digital inputs, limit switches, current/temperature monitoring.
- Payload outputs: protected PWM/digital outputs, servo outputs, power enables, winch interface, emergency release logic.
- Status indicators and test points: rail LEDs, fault LEDs, debug pads, programming headers, manufacturing test points.
- Board-to-board connectors: redundant connector pinout, power/current allocation, safety-signal split.
11. Schematic Page Plan
Suggested functional schematic pages:
Table
| Page | Contents |
|---|---|
| 1. System Overview | Block-level connectors, net naming, page notes |
| 2. Power Input Protection | Input connector, fuse/eFuse, TVS, reverse protection, current monitor |
| 3. Power Conversion | 12 V, 5 V, 3.3 V, safety always-on, compute local power enables |
| 4. Safety MCU Core | MCU, clocks, reset, boot config, debug, watchdog |
| 5. Flight Controller Interfaces | CAN 1, redundant CAN/UART, sync, heartbeat, protection/isolation |
| 6. Payload Bus Interfaces | CAN FD, RS-485, aux power, emergency line |
| 7. Payload Sensors | Load-cell AFE, analog inputs, digital inputs, limit switches, temperature |
| 8. Payload Outputs | PWM, digital outputs, servo, winch control, protected switches |
| 9. Emergency Release | Independent hardware path, interlocks, feedback, test points |
| 10. Compute Module | SOM or processor module, RAM/storage dependencies, debug |
| 11. Vision Cameras | Front/down camera connectors, CSI-2 or deserializer, camera power, sync, ESD |
| 12. Ethernet and Radar | Ethernet PHY/switch, radar connector, external Ethernet connector |
| 13. Radio and Antennas | Modular radio connector, RF connector mapping, GNSS/UWB/LTE options |
| 14. USB-C Service | USB data, ESD, debug/log access, bench power constraints |
| 15. Board-to-Board Interconnect | Dual connectors, power pins, redundant control and safety signals |
| 16. Indicators and Test | Status LEDs, test points, programming, factory test hooks |
12. Open Decisions Before Schematic Capture
These choices materially affect component selection and schematic detail:
- Main compute platform: SOM vs discrete processor.
- Safety MCU family and package.
- Required CAN count and whether CAN/UART isolation is mandatory.
- Exact rugged connector family.
- Aircraft power transient profile and required surge standard.
- Radar platform power, Ethernet type, sync/trigger voltage levels.
- Radio module physical format and interfaces.
- Camera physical placement: cameras are remote on the drone body, so use GMSL2 camera heads rather than direct long CSI-2; FPD-Link III remains fallback.
- Front/down camera sensor choice, FOV, frame rate, shutter type, synchronization, and Linux driver support.
- Load-cell quantity, bridge type, excitation voltage, accuracy target.
- Winch voltage/current and whether drivers are onboard or external.
- Emergency-release actuator type and required firing/hold current.
- Environmental qualification target and conformal coating assumptions.
13. Architecture Decisions Captured
- Use two electrical boards: compute/comms and safety/payload I/O.
- Safety board owns power sequencing and final actuator authority.
- Compute board can request actions but cannot directly energize safety-critical outputs.
- External radar is preferred for first prototype.
- USB-C is service-only, not primary aircraft power.
- High-current payload motors and winches should use external protected aircraft-power circuits, not draw operating current through KRYSTAL PCB traces.
- Separate CAN networks are required to avoid bus saturation affecting safety-critical traffic.
- Compute platform direction: Variscite VAR-SOM-MX8M-PLUS industrial i.MX8M Plus SOM; Toradex Verdin iMX8M Plus as alternate; Raspberry Pi CM4 only as fast bench fallback.
- Safety MCU direction: NXP S32K344EHT1VPBST, with STM32H753-class MCU as a quick-prototype fallback.
- Vision architecture direction: dual camera input on Linux compute for terminal guidance and GPS-denied navigation; S32K344 receives bounded guidance outputs only and remains the safety authority.
- Autopilot integration direction: provide plug-friendly JST-GH CAN and MAVLink/TELEM UART connectors so KRYSTAL can connect cleanly to common PX4/ArduPilot flight controllers.
- 5 V rail direction: generate 5V_CAN_LOCAL onboard using a second LM5013-Q1 from VIN_REV_PROT. This rail powers TCAN1462 VCC and autopilot connector VREF/accessory pins only; add connector-side current limiting/backfeed protection before treating it as an external power output.
14. Next Engineering Step
The compute and safety-controller direction is now selected at planning level, and the initial connector pinout matrix has been drafted. The next step is schematic capture beginning with the power input/protection, always-on safety rail, S32K344 safety MCU core, flight-controller CAN/UART interfaces, and board-to-board interconnect symbols.
Connector planning reference: Connector Pinout Matrix — KRYSTAL Module.
Drone Platform Reference Constraints
1. Architecture Intent
2. Top-Level Electrical Block Diagram
3. Board Partitioning
Board 1: Compute and Communications
Board 2: Safety, Navigation, and Payload I/O
4. Power Architecture
Electrical Power Domains
Power Tree Diagram
Preliminary Power Requirements
5. External Interface Architecture
6. Compute to Safety Interconnect
7. Safety-Critical Control Boundaries
8. Data and Control Buses
CAN Allocation
Other Buses
Load-Cell AFE Allocation
9. Protection and Isolation Strategy
10. First-Prototype Electrical Build Order
11. Schematic Page Plan
12. Open Decisions Before Schematic Capture
13. Architecture Decisions Captured
14. Next Engineering Step
