Drone Autonomy Spec


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
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

Compute and Safety Platform Recommendation — KRYSTAL Module
Status: Draft recommendation v0.1
Scope: First-prototype platform decision for KRYSTAL compute and safety-controller boards.
Result: Use an industrial i.MX8M Plus SOM direction for the serious prototype and an NXP S32K3 safety MCU direction for the real-time safety board.

1. Executive Recommendation

Table


SubsystemRecommendationWhy
Main computeVariscite VAR-SOM-MX8M-PLUS, 8 GB RAM configuration, industrial temperature optionBest fit found for KRYSTAL: industrial Linux SOM, NXP i.MX8M Plus, 8 GB RAM option, eMMC options above 32 GB, dual Gigabit Ethernet, dual CAN FD, -40 C to +85 C option
Compute alternateToradex Verdin iMX8M Plus Industrial, 8 GB RAM / 32 GB eMMC class configurationStrong industrial ecosystem and software support; good if vendor lifecycle, documentation, and BSP stability are prioritized over dual-Ethernet emphasis
Fast bench prototype alternateRaspberry Pi Compute Module 4, 8 GB RAM / 32 GB eMMCFastest software bring-up and available in the Flux library, but less production-rugged than industrial SOM choices
Safety MCUNXP S32K344EHT1VPBSTAutomotive/safety-oriented Cortex-M7 MCU, active library part, 172-QFP package, multiple CAN FD ports, security/watchdog/safety features
Safety MCU alternateSTM32H753-class MCUFaster STM32 ecosystem bring-up, but only two internal CAN FD controllers; better as a prototype convenience option than the safety-oriented production direction
AI-heavy alternateNVIDIA Jetson Orin Nano 8 GB or Orin NXUse only if onboard AI/perception becomes central; otherwise power and thermal cost are too high for the base prototype
My concrete decision for KRYSTAL v0.1 electrical planning
  • Compute direction: Variscite VAR-SOM-MX8M-PLUS industrial i.MX8M Plus SOM.
  • Safety-controller direction: NXP S32K344EHT1VPBST.
  • Schematic fallback if SOM library availability blocks capture: begin with the safety board, power input/protection, connectors, and S32K344; treat the compute SOM connector as a to-be-created/imported part.

2. Why Not Start With Jetson By Default
Jetson Orin Nano and Orin NX are strong options if KRYSTAL needs heavy onboard perception, neural inference, visual navigation, or CUDA/TensorRT workflows. However, for the base prototype they add:
  • Higher power consumption.
  • Higher thermal load in a sealed passive enclosure.
  • More difficult power sequencing and storage behavior.
  • More software maintenance complexity.
  • Risk of overbuilding AI before the safety, payload, radar, and flight-controller integration are validated.
Use Jetson only if AI becomes a hard requirement for the first prototype.

3. Compute Candidate Comparison

Table


CandidateStrengthsWeaknessesKRYSTAL fit
Variscite VAR-SOM-MX8M-PLUSIndustrial temp option, 8 GB RAM option, eMMC up to 128 GB, dual GbE, dual CAN FD, NXP i.MX8M Plus NPUNot currently in Flux library; requires vendor carrier design docs and connector symbolBest serious prototype direction
Toradex Verdin iMX8M PlusIndustrial support, strong documentation/software ecosystem, 8 GB/32 GB class options, long-lifecycle embedded focusNot currently in Flux library; Ethernet expansion may need carrier design decisionsBest vendor-support alternate
Raspberry Pi CM4 8 GB / 32 GB eMMCFastest bring-up, huge Linux/robotics ecosystem, available in Flux libraryNot ideal for rugged industrial production; weaker industrial lifecycle storyGood bench and software prototype, not preferred final direction
Raspberry Pi CM5More modern Pi compute path; available in Flux libraryIndustrial qualification and long-term rugged suitability still need confirmationPossible bench prototype, not primary recommendation
AMD Kria K26 SOMIndustrial-capable, FPGA/AI acceleration potential, available in Flux library4 GB RAM and 16 GB eMMC do not meet preferred memory/storage target; more FPGA complexityUseful only if programmable logic becomes important
NVIDIA Jetson Orin Nano/NXStrong AI/perception ecosystem and GPU accelerationPower/thermal cost; Orin Nano search evidence indicates not a full -40 C industrial defaultAI-heavy variant only

4. Safety MCU Candidate Comparison

Table


CandidateStrengthsWeaknessesKRYSTAL fit
NXP S32K344EHT1VPBSTAutomotive/safety-oriented, multiple CAN FD ports, security features, watchdog/safety architecture, available in Flux library, QFP package is more prototype-friendly than large BGAMore complex ecosystem than STM32; requires S32K tooling and safety-oriented firmware disciplineRecommended safety-controller direction
NXP S32K358More performance and higher-end S32K3 optionBGA complexity and routing burden; likely unnecessary for first prototypeProduction upgrade only if S32K344 is insufficient
STM32H753 / STM32H743Very mature ecosystem, high performance, strong peripheral set, 2 MB Flash / 1 MB RAM class, dual CAN FDOnly two native FDCAN controllers; less explicitly safety-oriented than S32K3Good quick prototype alternate
i.MX RT class MCUStrong real-time performanceSafety/security story and CAN count depend on exact partSecondary alternate

5. Flux Library Availability

Table


PartLibrary statusNotes
NXP S32K344EHT1VPBSTAvailablePart UID found: ef03404b-66f5-422c-98cd-876f32eeec70
Raspberry Pi Compute Module 4AvailablePart UID found: 68199d52-41ec-4bc3-bf05-5f01fbf1b4c8; datasheet metadata appears incomplete, so verify before final schematic
Variscite VAR-SOM-MX8M-PLUSNot foundMissing-part request submitted internally
Toradex Verdin iMX8M PlusNot foundMissing-part request submitted internally
Variscite DART-MX8M-PLUSNot foundAlternative compact SOM, but not selected as primary
Implication: the safety-board schematic can start immediately around the S32K344. The compute carrier schematic may require importing/creating the selected SOM connector symbol from the vendor documentation, or using the CM4 as a bench-prototype fallback.

6. Evidence Summary
Research findings used for this recommendation:
  • Industrial i.MX8M Plus SOM search found Toradex Verdin iMX8M Plus, Variscite VAR-SOM-MX8M-PLUS, DART-MX8M-PLUS, and VAR-SMARC-MX8M-PLUS options with industrial temperature configurations.
  • Variscite VAR-SOM-MX8M-PLUS search evidence indicates up to 8 GB LPDDR4, eMMC options, dual Gigabit Ethernet, dual CAN FD, and -40 C to +85 C configuration availability.
  • Toradex Verdin iMX8M Plus search evidence indicates up to 8 GB RAM, up to 32 GB eMMC, and -40 C to +85 C industrial options.
  • Jetson Orin Nano search evidence indicates 7 W / 15 W power modes, with newer higher-power modes, but not a default full -40 C industrial-temperature match.
  • STM32H753 research confirms two CAN FD controllers and industrial-grade options.
  • NXP S32K344 research confirms six CAN FD ports available on S32K344-based reference hardware.
  • Flux library search confirms S32K344EHT1VPBST is available as an active NXP part with 172 terminals and datasheet link.

7. Electrical Architecture Implications
Compute board implications
  • Design as a carrier board for an industrial SOM.
  • Reserve enough connector pins for dual Ethernet, USB, PCIe/M.2 or radio interface, debug, boot controls, reset, power enables, and time-sync signals.
  • Include a private radar Ethernet path or an Ethernet switch if radar, service Ethernet, and external network are all needed.
  • Keep AI physically optional through M.2 or a separate module instead of forcing Jetson power/thermal requirements into the base design.
Safety board implications
  • Put S32K344 on the safety/payload I/O board.
  • Use native CAN FD ports for flight-controller and payload buses before adding external CAN controllers.
  • Keep the safety rail always-on and independently monitored.
  • Route compute reset, compute power enable, heartbeat, watchdog, and emergency inhibit/status signals through the board-to-board interconnect.
  • Use external precision ADC/AFE for load cells; do not depend on MCU internal ADC for precision tension measurement.

Proceed with the connector pinout matrix and power-domain pin allocation using:
  • Compute SOM target: Variscite VAR-SOM-MX8M-PLUS.
  • Safety MCU target: NXP S32K344EHT1VPBST.
  • Bench fallback: Raspberry Pi CM4 8 GB / 32 GB eMMC if the industrial SOM part cannot be created/imported quickly enough for early schematic capture.
After the connector matrix is defined, start schematic capture with:
  1. 9-36 V power input and protection.
  2. Always-on safety regulator rail.
  3. S32K344 MCU core, clock, reset, debug, watchdog.
  4. CAN FD and UART flight-controller interfaces.
  5. Board-to-board compute-control signals.
  • 1. Executive Recommendation

  • Recommended serious first prototype

  • My concrete decision for KRYSTAL v0.1 electrical planning

  • 2. Why Not Start With Jetson By Default

  • 3. Compute Candidate Comparison

  • 4. Safety MCU Candidate Comparison

  • 5. Flux Library Availability

  • 6. Evidence Summary

  • 7. Electrical Architecture Implications

  • Compute board implications

  • Safety board implications

  • 8. Recommended Next Step