The control architecture problem no one names clearly
Most autonomous machines reach the market as a split architecture. A Jetson development kit handles perception. A PLC from a factory-automation vendor handles the servo and hydraulic loops. A handful of serial buses ties the two together. The result is functional enough for a lab demonstration — and not deterministic enough for a production deployment, because the latency between an AI model’s output and an actuator’s response is not bounded, not guaranteed, and not certifiable.
The deeper problem is structural: neither half was designed to talk to the other. A factory PLC was not built to receive tensor outputs from a vision model. A Jetson dev kit was not built to close a servo current loop at sub-millisecond intervals. Both engineering teams — vision on one side, motion control on the other — end up writing glue code that absorbs the timing gap, hand-tuning interrupt priorities, and hoping the Linux scheduler cooperates. In production, it often doesn’t. A firmware update to the AI stack introduces a processing spike of several milliseconds. The motion controller, never expecting that delay, overshoots an axis limit.
Trusting the scheduler is not a plan. ROS 2, the middleware most Jetson deployments use, is a soft-real-time system. Even with PREEMPT_RT kernel patches, dedicated CPU cores, and elevated RT priorities, worst-case scheduling jitter on a loaded system stays in the hundreds of microseconds to single-digit milliseconds range. That is acceptable for planning a navigation path. It is not acceptable for a hydraulic cylinder actuating at 1 kHz, where a missed deadline means a jerked weld seam, an encoder overrun, or a tripped safety relay.
Cloud offload does not fix the field-machine problem. An autonomous excavator on a remote construction site, an inspection robot inside a steel mill’s EMI-dense environment, an agricultural sprayer covering field rows — none of these can absorb a network round-trip on every inference call. They need perception-to-control decisions within tens of milliseconds, locally, regardless of connectivity.
The architecture that resolves all three constraints — deterministic timing, on-device AI compute, and offline resilience — has a name: the AI-native controller.
What an AI-native controller is
An AI-native controller is a single PCB, or a tightly-coupled module stack, that integrates two computational elements with fundamentally different execution models:
- A deterministic real-time core — almost always an FPGA, or an RTOS on an Arm Cortex-M or Cortex-R for simpler I/O-only designs — running motor control, safety interlocks, and sensor interfaces in hardware-scheduled logic with no operating system between the computation and the silicon.
- An on-device AI accelerator — in 2026 designs, almost always an NVIDIA Jetson Orin-series module — running perception, state estimation, and planning workloads on a GPU-accelerated inference engine.
The two sides share a low-latency interconnect: PCIe, a dedicated SPI or UART link, or a memory-mapped soft-core interface on the FPGA fabric. How many microseconds elapse between an AI model’s output and a resulting control setpoint change is the central design discipline of the architecture. That number — the AI-to-actuator latency budget — is what distinguishes a well-designed AI-native controller from a Jetson bolted to a PLC with a UART in between.
The FPGA side: why hardware execution changes the timing equation
FPGAs execute logic in parallel hardware, not in scheduled software threads. A mid-range device — such as a Lattice ECP5 in a 12–85K LUT configuration — running a motor-control state machine closes its loop in deterministic clock cycles. The loop period is set by the oscillator, not by a kernel timer interrupt. An EtherCAT slave stack implemented in FPGA fabric achieves cycle times below 100 µs with sub-µs jitter at the node, because the protocol logic runs in silicon rather than in a DMA interrupt handler.
Safety logic belongs on the FPGA side. ISO 13849-1 Performance Level–rated hardware interlocks — the PL-d or PL-e output-disable circuits that autonomous machinery regulations require — execute on the FPGA regardless of the Jetson’s state. If the AI module hangs mid-inference, the FPGA watchdog fires and cuts drive power within clock cycles. This hard separation of the safety boundary from the AI stack is one of the structural advantages of the AI-native architecture over a Jetson-only or Jetson-plus-PLC design.
For motor drive, a TI DRV8353 3-phase gate driver (5.5–100 V operating range) on the FPGA’s SPI bus closes a BLDC current loop at update rates no Linux process scheduler can sustain under load — the SPI transaction competes with nothing.
The Jetson side: inference at machine-compatible power budgets
The Jetson Orin Nano (8 GB LPDDR5) delivers up to 67 TOPS of INT8 inference in a 7–25 W power envelope. The Jetson Orin NX (16 GB) reaches 157 TOPS with a 1024-core Ampere GPU and an 8-core Arm Cortex-A78AE CPU, packaged in the same 69.6 × 45 mm SO-DIMM-style module footprint as the Nano. A single carrier board can support both modules, so a team can validate hardware on the Orin Nano and scale to the Orin NX if the inference workload grows — without a new PCB spin.
NVIDIA Isaac ROS provides hardware-accelerated perception packages — stereo depth estimation, object detection, pose estimation — that run directly on either module. In practice: the Orin Nano covers single-camera detection and lightweight navigation models. The Orin NX handles stereo-vision pipelines, point-cloud fusion from a LiDAR and IMU stack, or multi-modal models that combine visual and force-torque sensor inputs at production frame rates.
Programming model: two ecosystems, one board
Legacy PLCs program in IEC 61131-3 languages — Ladder Diagram, Function Block Diagram, Structured Text. AI-native controller projects typically bypass those on the AI side. The Jetson runs C++, Python, or Rust, with TensorRT or CUDA for inference acceleration. The FPGA runs VHDL, SystemVerilog, or vendor HDL compiled by Lattice Radiant or Xilinx Vivado. If a customer’s machine-builder team requires an IEC 61131-3 motion runtime on the FPGA side — to preserve compatibility with an existing HMI or motion library — that runtime can coexist with the AI pipeline. The perception and planning stack on the Jetson operates outside the IEC paradigm regardless.
Architecture comparison
| Dimension | Legacy PLC | PC-based control | AI-native controller |
|---|---|---|---|
| Timing determinism | Hard (ASIC-based I/O, µs) | Soft (Linux, ms jitter) | Hard FPGA + soft AI-side |
| AI compute density | None built-in | Add-in GPU required | 67–157 TOPS on-module |
| I/O flexibility | Fixed at product specification | Moderate | Tailored per machine |
| Software stack | IEC 61131-3, vendor-locked | Open (Linux) | Open on both sides |
| Field ruggedization | Industrial-rated (EN 61131-2) | Low to moderate | Designed per application |
| BOM cost per node | High (licensed runtime) | High (industrial GPU) | Optimized for production volume |
When you are in AI-native-controller territory
Three conditions define the design space. If your machine satisfies all three, a purpose-built AI-native controller is the answer:
- Edge inference at ≥1 TOPS — vision, LiDAR processing, predictive actuator control, or any workload that saturates a microcontroller’s processing budget.
- A control loop at 1 kHz with sub-millisecond jitter — servo axes, hydraulic proportional valves, force-control end-effectors, safety-rated emergency stops.
- An IP-rated enclosure — outdoor or industrial deployment where consumer-grade thermal design and ingress protection are inadequate.
Meeting only condition 1: a Jetson dev kit or industrial PC may suffice. Meeting only condition 2: a standard PLC covers it at lower BOM cost. The AI-native controller pattern exists for machines that need all three simultaneously — and for which splitting the architecture across two separate vendor products introduces the integration risks described above.
How TACTUN designs AI-native controllers
TACTUN designs the control spine — the FPGA real-time control and Jetson AI layer that lets a customer’s own perception and planning models command the machine without owning the board design. The TACTUN platform combines custom FPGA logic with NVIDIA Jetson edge AI on a single carrier board, with I/O tailored to each customer’s specific sensors and actuators. Motor control covers servo, stepper, hydraulic, and pneumatic actuators. Safety logic and machine-state management execute on the FPGA side, keeping the Jetson’s AI stack off the path to the machine’s safety boundary.
TACTUN’s founding engineers have shipped more than 800 controllers across prior companies and bring 14 years of systems-integration experience to each engagement. TACTUN delivers board architecture in 5 business days at $0 NRE — customers pay for production hardware, not the design session. Physical prototypes reach the customer’s test bench in 3–5 months.
Building an AI-native controller from scratch typically costs $900K–$2M+ and takes 18–24 months once board design, firmware, safety logic, prototyping, and production qualification are accounted for. Engaging a team that has already resolved the FPGA-to-Jetson interface, the I/O selection, and the production supply chain — across use cases spanning agricultural, construction, marine, and medical robotics — shortens both figures. TACTUN is an NVIDIA Inception Program member.
Talk to us about your machine — describe the control loop timing, the inference workload, and the operating environment, and we will return a board architecture in 5 business days. Start a conversation →