The Honest Guide to Choosing Between Real-Time Linux and Standard Linux for Robotics Projects

You’ve got a robot arm that needs to catch a ball mid-flight, or a drone that must adjust its motors 1,000 times a second. Standard Linux says "I'll get to it when I can." Real-Time Linux says "Give me a deadline, I'll meet it." The choice feels obvious until you realize real-time comes with a cost—complexity, compatibility headaches, and sometimes diminished performance for the other 99% of your tasks.

Let's cut through the marketing noise. Here’s what actually matters.

What Real-Time Linux Actually Does

Standard Linux is a general-purpose operating system. It schedules tasks to maximize throughput and fairness. When you run ros2 control or a sensor fusion algorithm, the kernel might pause your robot's control loop to flush a log file or serve a webpage.

Real-Time Linux (specifically the PREEMPT_RT patch set) guarantees worst-case response times. The kernel becomes fully preemptible—critical tasks can interrupt almost anything to meet their deadlines. If your robot needs positional updates within 1 millisecond, PREEMPT_RT ensures that happens, even under heavy load.

But here's the catch: real-time is about predictability, not speed. A PREEMPT_RT kernel might actually run slower on average because it sacrifices throughput for latency guarantees.

When Standard Linux Is the Right Choice

Most robotics projects don't need real-time. Seriously. If your robot: - Uses ROS 2 with DDS (which has its own QoS mechanisms) - Runs vision processing that's inherently "as fast as possible" rather than hard real-time - Has mechanical systems with low natural frequencies (big, slow arms or heavy mobile bases) - Uses dedicated microcontrollers for low-level motor control (like an STM32 or Teensy)

Then standard Linux—especially the RT kernel that Ubuntu ships by default—will likely work fine. Many teams build entire autonomous vehicles on standard Ubuntu with a separate microcontroller handling the "I'll explode if not on time" signals.

I've seen teams spend weeks tuning PREEMPT_RT for a robot arm, only to realize their encoders and motor drivers introduced more jitter than the OS ever did. Hardware latency often dwarfs kernel latency.

When Real-Time Linux Shines

You need PREEMPT_RT when: - You're doing direct actuator control from the main CPU — no dedicated motor controller in between - Your control loop runs faster than 1 kHz — high-speed drones, balancing robots, surgical tools - You can't tolerate missed deadlines — if a control update arrives 2ms late, the robot becomes unstable - You're running multiple real-time tasks that share the same CPU — and you need strict priority guarantees

The classic case is a quadcopter running its attitude control loop at 1,000 Hz directly on a Raspberry Pi or Jetson. Without PREEMPT_RT, even occasional jitter from WiFi interrupts or USB polling can cause a crash.

The Hidden Costs You Won't Find in Benchmarks

1. Driver Compatibility

PREEMPT_RT changes how kernel spinlocks work. Some drivers — especially for cameras, GPUs, and neural accelerators — either don't work or require custom patches. Your shiny OAK-D camera or RealSense depth sensor might suddenly stop delivering frames reliably.

2. Debugging Hell

When something breaks under PREEMPT_RT, the stack traces are different. Tools like perf and ftrace become your best friends, but learning them takes weeks. You'll develop a deep appreciation for what "sporadic" means.

3. Performance Trade-offs

The same kernel that guarantees a 50-microsecond response to your motor controller might introduce 100 microseconds of overhead to your object detection pipeline. You're trading average performance for worst-case guarantees.

The Practical Middle Ground

Most successful robotics projects use a hybrid approach:

[Main CPU - Standard Linux]
    - Runs ROS 2, perception, planning
    - Communicates over Ethernet or UART

[Motor Controller - Dedicated RTOS or Microcontroller]
    - Runs control loops at 1kHz+
    - Handles all safety-critical timing
    - Simple, well-tested code

This is the ROS 2 architecture, it's how industrial robot arms work, and it's how Boston Dynamics' robots operate. The main CPU runs standard Linux; a separate chip (or FPGA) handles real-time control.

Exceptions: When your project needs a single board (Raspberry Pi 4, Jetson Orin) to do everything — control loops and high-level logic — PREEMPT_RT becomes attractive.

How to Decide in 15 Minutes

1. Run latency tests on your hardware — use cyclictest to measure baseline jitter on standard Linux
2. Identify your worst acceptable response time — be honest, not theoretical
3. Check your motor controller specs — if it handles real-time already, you're done
4. Look up driver compatibility — Google "[your hardware] PREEMPT_RT issues"
5. Decide based on risk — for a research prototype, standard Linux is fine; for a production robot, plan for RT

The honest answer? If you're asking this question, you probably don't need real-time Linux. Install standard Ubuntu, use ROS 2's real-time capable DDS, and let your motor controller handle the timing. Save PREEMPT_RT for when your robot literally crashes without it.