The Jetson should not be treated as a bigger microcontroller.

A Jetson-class edge AI computer is excellent for perception, local AI inference, sensor fusion, planning, visualization, logging, and ROS 2 orchestration. It is not the right place to put every control loop just because it has more CPU, more GPU, and a full Linux environment. In a real robot, the dangerous failures are often boring: a delayed callback, a blocked process, a stale command, a thermal throttle, a cable fault, a bus timeout, or a control loop that misses its deadline while the rest of the software still looks alive.

The practical design question is:

Which decisions may run on Linux, and which decisions must remain close to the actuator on a deterministic microcontroller path?

My answer: put high-level autonomy on the Jetson, put hard real-time actuator authority on the microcontroller, and define the boundary as a contract with timing, ownership, watchdogs, command age limits, and fallback behavior. That contract matters more than the hardware brand.

This article extends the architecture in Jetson edge AI placement, splitting authority between an LLM, ROS 2, and a microcontroller, micro-ROS on a Jetson robot, real-time Linux for robotics, sensor-to-actuator timing budgets, and robot safety architecture.

Key takeaways

• A Jetson is a strong edge AI and ROS 2 computer, but Linux scheduling, memory, GPU load, thermal behavior, and process-level failure make it a poor owner for hard real-time actuator loops.
• A microcontroller should own fast, bounded, actuator-near control: PWM generation, encoder counting, current limits, low-level watchdogs, emergency stop inputs, and last-resort safe behavior.
• ROS 2 can supervise real-time control, but supervision is not the same as owning the final motor update deadline.
• The boundary should be expressed as a control placement matrix: loop rate, maximum jitter, safety impact, fallback behavior, observability, and command authority.
• The Jetson should send bounded setpoints or goals, not raw motor pulses, when the robot can move in the physical world.
• A reliable architecture has two watchdog paths: Jetson-to-MCU command freshness and MCU-to-actuator local safety.

Citation-ready answer

In AI-enabled robots, real-time motor control should usually live on a microcontroller or safety-rated actuator controller, while a Jetson-class edge AI computer should handle perception, inference, planning, ROS 2 orchestration, logging, and operator interfaces. The reason is not compute power; it is determinism and authority. The Jetson can produce high-level goals, velocity setpoints, trajectories, or skill proposals, but the microcontroller should enforce timing, command age, actuator limits, encoder feedback, watchdogs, and safe fallback behavior close to the hardware.

Start with the control deadline

Do not start with the board. Start with the deadline.

Real-time control is not “fast code.” It is code that must run before a deadline with bounded jitter. The official ROS 2 real-time programming documentation frames the problem around periodic update loops, maximum allowable jitter, and avoiding nondeterministic operations such as page faults, dynamic allocation, and unbounded blocking: Understanding real-time programming.

That distinction changes the design.

A vision model can take 40 ms instead of 25 ms and still produce useful perception if the rest of the system knows the observation age. A motor commutation loop or fast wheel-speed loop missing its deadline may create oscillation, overshoot, degraded braking, or loss of stability. Those are different classes of failure.

Use this simple test:

If missing the deadline can move the robot into a dangerous or unrecoverable physical state, the loop should not depend on a best-effort Linux process.

That does not mean Linux can never participate in control. It means Linux should not be the last deterministic safety boundary unless the whole system has been engineered and measured for that responsibility.

The practical split

Here is the default architecture I would start from for a mobile robot, manipulator, inspection platform, or lab robot with local AI:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

camera / lidar / IMU / application inputs
  -> Jetson / ROS 2 / edge AI
       - perception
       - localization
       - planning
       - model inference
       - operator UI
       - logging and replay
       - bounded setpoint generation
  -> MCU / actuator-near controller
       - command freshness check
       - encoder and limit-switch handling
       - PWM / CAN / fieldbus timing
       - current, speed, and position limits
       - watchdogs
       - safe stop or hold behavior
  -> motor driver / actuator / brake / power stage

The Jetson owns semantic intelligence. The microcontroller owns deterministic admission to physical motion.

This is not a weakness of Jetson hardware. It is a boundary between two different operating models:

The right answer is often layered. A Jetson can run a controller manager, a microcontroller can enforce actuator limits, and a safety chain can own the final stop path.

Placement matrix

Use a matrix instead of arguing from preference.

The most important word in this table is “enforce.” The Jetson can compute, propose, supervise, and explain. The actuator-near layer should enforce the constraints that prevent bad proposals from becoming unsafe motion.

When the Jetson can own a loop

There are cases where the Jetson can own control-like behavior.

Examples:

• a low-rate pan-tilt camera target update,
• an arm waypoint generator that sends bounded trajectories to a controller,
• a mobile robot velocity setpoint at 10 to 50 Hz with a separate low-level drive controller,
• a noncritical lighting, display, or audio actuator,
• a lab prototype where missed deadlines are acceptable and measured.

The phrase “control-like” matters. The Jetson may own a supervisory loop that produces setpoints, but the motor driver, MCU, or controller should still reject stale commands, enforce limits, and define the safe state.

If the loop has hard safety impact, measure before trusting it. The Linux kernel’s PREEMPT_RT documentation is useful context because it explains how real-time preemption changes scheduling, interrupt handling, and locking compared with a non-real-time kernel: Real-time preemption. But PREEMPT_RT is not a magic certificate. It reduces latency sources; it does not remove the need for a measured deadline budget and actuator-near fallback.

When the microcontroller should own the loop

Put the loop on the microcontroller when most of these are true:

• the loop rate is high enough that jitter matters,
• the loop reads encoder, current, limit-switch, or IMU data directly,
• the loop writes PWM, CAN motor frames, step pulses, or brake commands,
• a missed deadline can cause overshoot, instability, collision, or hardware damage,
• the fallback action must work even if the Jetson process dies,
• the behavior should continue or stop safely during network, ROS, GPU, or storage faults,
• the code path should be understandable during a field incident.

micro-ROS exists because ROS 2 systems often need microcontrollers as first-class participants. Its architecture brings ROS concepts onto MCUs using rcl/rclc and DDS-XRCE, and the official overview notes that the rcl+rclc combination is optimized for MCUs and can avoid dynamic memory allocation after initialization: micro-ROS features and architecture. The micro-ROS RTOS page also highlights RTOS support and deterministic scheduling as the normal embedded entry point: micro-ROS supported RTOSes.

That does not mean every MCU should run micro-ROS. For very tight loops, a custom binary protocol or direct motor-controller bus may be simpler. The point is to make the boundary explicit: ROS 2 semantics on the MCU are useful when they improve integration without weakening the deterministic path.

The control boundary contract

Every Jetson-to-MCU control boundary should have a written contract.

The boundary contract prevents a common robotics failure: everyone assumes another layer owns the dangerous edge case.

The Jetson should not assume that the MCU will interpret an old command safely. The MCU should not assume that any command from the Jetson is fresh, authorized, physically plausible, or mode-compatible.

What belongs in ROS 2

ROS 2 is a strong orchestration layer for distributed robot software, but the graph is not a substitute for timing ownership.

Use ROS 2 for:

• sensor pipelines,
• state estimation and perception outputs,
• local planner outputs,
• action servers,
• lifecycle and mode coordination,
• diagnostics,
• parameterized limits,
• rosbag capture,
• replay and incident analysis.

Use the real-time path below ROS 2 for:

• final motor update timing,
• encoder interrupt handling,
• direct safety I/O,
• emergency stop propagation,
• current and thermal shutdown,
• hold/brake/coast behavior,
• command freshness rejection.

ros2_control is relevant because it provides a structured way to integrate robot hardware and controllers in ROS 2. The current Kilted documentation describes controller managers, hardware components, different update rates, asynchronous execution, and related concepts: ros2_control documentation. Use that structure, but do not confuse a clean controller abstraction with a guarantee that the lowest-level timing belongs on the Jetson.

Jetson-specific failure modes

A Jetson can be reliable in production, but it has failure modes that should not directly own the last motor deadline:

NVIDIA’s Jetson Linux power and performance documentation is worth reading because power modes, clocks, thermal management, and related tools are visible to software and affect runtime behavior: Jetson Platform Power and Performance. For robotics, that is not only an optimization topic. It is part of the timing and reliability evidence.

The command path I would ship

For an AI-enabled robot, the minimum safe command path looks like this:

1
2
3
4
5
6
7
8
9
10

AI / planner / operator
  -> ROS 2 action or command proposal
  -> policy and mode gate
  -> bounded setpoint message
  -> transport with sequence number and timestamp
  -> MCU freshness and limit check
  -> actuator command
  -> encoder/current feedback
  -> MCU local watchdog
  -> Jetson diagnostics and evidence log

The AI layer never publishes raw motor commands.

The planner does not bypass the policy gate.

The MCU does not trust a command only because it came from the Jetson.

The robot has a defined behavior when commands stop arriving.

That behavior should be boring, deterministic, and tested: hold position, brake, coast, torque off, enter low-speed mode, or request human handoff depending on the machine and hazard analysis.

Decision checklist

Before placing a control function on the Jetson, ask:

• What is the loop rate?
• What is the maximum allowable jitter?
• What happens if the loop misses one deadline?
• What happens if it misses ten deadlines?
• Can the robot stop safely if the Jetson process dies?
• Does the loop allocate memory, call the filesystem, use the GPU, wait on DDS, or block on a mutex?
• Does it need direct encoder, current, or limit-switch timing?
• Is the fallback independent of the failing path?
• Can we replay the decision from logs?
• Have we measured the loop under thermal, CPU, GPU, IO, and communication load?

If those answers are weak, move the final control authority closer to the actuator.

Testing the boundary

Do not test only the happy path. Test the boundary.

The output should be a timing trace and a safety decision log, not just a console print. The team should know exactly which layer intervened, why, and how long it took.

Common mistakes

The first mistake is using the Jetson’s compute power as an argument for control authority. Compute power and determinism are different properties.

The second mistake is putting a real-time loop in a ROS 2 node and assuming the word “real-time” now applies to the whole path. The path includes scheduling, memory, transport, callback execution, command age, actuator timing, and fallback.

The third mistake is treating the MCU as a dumb I/O expander. If it is close to the motors, it should own at least freshness checks, limits, watchdogs, and safe output behavior.

The fourth mistake is letting the AI layer send commands that are too low-level. A model or agent should propose intent, goals, or bounded setpoints. It should not directly own pulse timing, torque authority, or emergency behavior.

The fifth mistake is failing to measure under load. A robot that behaves in a quiet lab may miss deadlines when logging, visualization, inference, thermal throttling, and network traffic happen together.

FAQ

Can a Jetson run real-time control?

It can run control software, and with careful Linux real-time configuration it can run some time-sensitive loops. But for hard actuator deadlines and safety-critical motor authority, use a microcontroller, dedicated motor controller, or safety-rated controller for the final enforcement path.

Is PREEMPT_RT enough to replace a microcontroller?

Usually no. PREEMPT_RT can reduce Linux latency and improve scheduling behavior, but it does not remove all system-level variability. It also does not give Linux direct actuator-near independence if the Jetson process, power state, GPU load, or storage path fails.

Should micro-ROS run every control loop?

No. micro-ROS is useful when the MCU should participate cleanly in the ROS 2 ecosystem. Very fast or very safety-sensitive loops may still be better as firmware with a narrow protocol to ROS 2.

What should the Jetson send to the MCU?

Send bounded goals, velocity setpoints, trajectory segments, or mode requests with timestamps, sequence numbers, units, frames, and limits. Do not send raw motor pulses from a high-level AI or ROS 2 node.

Where should emergency stop live?

Never only in a Jetson process. Emergency stop behavior should be hardware-near, actuator-near, or safety-rated depending on the machine. The Jetson may observe and log E-stop state, but it should not be the only path that makes the stop happen.

What is the simplest first architecture?

Start with Jetson for perception, planning, ROS 2 actions, diagnostics, and logs. Put encoder handling, PWM or motor-bus timing, command age checks, watchdogs, and safe fallback on the MCU. Then measure the full sensor-to-actuator timing budget under load.

Final opinion

The right robotics architecture is not “Jetson or microcontroller.” It is Jetson plus microcontroller with a disciplined authority boundary.

Let the Jetson do what it is good at: perception, AI inference, ROS 2 orchestration, operator experience, logs, and planning. Let the microcontroller do what it is good at: deterministic timing, actuator-near checks, simple watchdogs, and safe behavior when the smarter computer is late or wrong.

That boundary is what makes Physical AI practical. The model can be probabilistic. The final motor safety path should not be.