RTOS Kernel Architecture for Robotics: Scheduling, Interrupts, and Hardware Control

A robot needs the right command while that command can still help. A real-time operating system (RTOS) coordinates the work between sensing and actuation. Follow one joint correction through the RTOS architecture, from sensor input to hardware output.

1. The processor is fast. The robot still reacts too late.

A quadruped detects an uneven step and calculates the right correction

A quadruped steps onto a broken paving stone. An encoder reports a changed joint angle; the inertial measurement unit (IMU) detects the body rotating. The controller calculates a correction—but the robot keeps moving while that command travels to the joints.

Correct arithmetic is only part of the job. A command based on an earlier posture may arrive after that posture has disappeared.

The correction reaches the joints after the robot needs it

Suppose this example requires the actuator command to be applied within 1 ms of the sensor sample. Computing the answer in 0.2 ms does not prove that the full response fits.

A fast average can hide occasional late updates. Real-time control requires sufficiently bounded and consistent timing across the complete path. The ROS 2 real-time background develops that distinction.

2. How the controller coordinates each step

How the CPU, memory and drivers turn sensor readings into joint commands

In microcontroller-based embedded systems, the CPU reads measurements, calculates a target, and calls a driver. The driver configures a peripheral; the peripheral delivers a signal to the actuator interface.

The robotics hardware guide explains how motors, transmissions, sensors, and joint loads shape that actuator interface.

A PWM driver can write a timer’s compare register; the timer then generates pulses without the CPU toggling every edge. A bus driver instead prepares a transfer, sometimes assisted by DMA. Register write, transfer completion, and command application are different moments.

At instruction level, a memory-mapped register is an address decoded by the peripheral bus. A CPU store changes hardware state rather than an ordinary RAM variable. A timer may latch a new compare value only at its next update boundary; ST’s timer cookbook explains this preload mechanism. A CAN transfer must also wait for bus access. The drive then decides when to apply the command. These waits sit beyond task selection.

Inside a typical MCU controllerDifferent addresses, different jobs

STOREFlashInstructions + constants

WORKRAMSamples, stacks + buffers

CONTROLI/O registersPeripheral state + settings

A register write becomes a physical signal

1. 01CPU store
2. 02Timer compare register
3. 03PWM waveform
4. 04Motor drive

A control pin carries a signal. The motor drive supplies operating power and may run its own faster current loop. The electronics behind physical AI follows that surrounding circuit and power path.

Each task needs RAM for its execution stack and its TCB. The stack holds function-call state and saved registers; the TCB tells the kernel where that context lives. A task’s stack is reserved storage, even when the task is Blocked.

With upstream FreeRTOS, xTaskCreate() obtains the stack and TCB through the configured allocator. xTaskCreateStatic() accepts application-provided storage. Both still consume RAM; static creation removes the heap allocation for those objects. Stack depth uses StackType_t elements in upstream FreeRTOS, while ESP-IDF task-creation APIs use bytes. Check the task API and IDF port differences before copying a stack size.

That storage budget helps explain the platform split. A small FreeRTOS kernel and a Linux system carry different services; compare what each number includes before using it to select a chip.

Inside the RTOS kernel: how tasks, interrupts and scheduling work together

RTOS is an operating-system category. FreeRTOS and Zephyr are implementations that supply scheduling and synchronization. Developers configure those mechanisms and implement their application tasks.

To follow FreeRTOS task scheduling, use a preemptive, single-core configuration for this walkthrough. A control task waits for fresh data while sensing and telemetry get their own execution contexts.

The kernel stores task state in a task control block (TCB). pxTopOfStack locates its saved context; uxPriority ranks it; list items connect it to state and event lists. An RTOS context switch resumes the task at its saved execution point.

When switching is permitted, the highest-priority eligible Ready task is selected. A high-priority task that never blocks can starve lower-priority work. See the FreeRTOS task implementation .

For the single-core model, Ready lists are indexed by priority. Blocking on a queue removes a task from the Ready set and registers it as a waiter; a finite timeout also needs delayed-list bookkeeping. An event or timeout makes it eligible again. The kernel protects these list updates so an interrupt cannot observe a half-modified scheduling structure. Priority lookup may use a port-optimized bitmap where configured; it is not one universal algorithm on every chip.

Now let the sensor assert its data-ready interrupt. Follow the complete handoff below: Ready does not yet mean Running.

On the Cortex-M4F port, a requested switch can pend PendSV, a low-priority exception. Hardware first saves an exception frame; the port saves the remaining task context, selects another TCB, and restores that task. The process stack pointer (PSP) follows task storage; handler code uses the main stack pointer (MSP).

The port raises BASEPRI while selecting the next task to mask the interrupt priorities that may access kernel data. Higher-urgency interrupts can remain enabled, but must not call the affected FreeRTOS APIs. Pending PendSV does not force a switch through an active higher-priority handler. This is specifically the Cortex-M4F port , not ESP32’s Xtensa or RISC-V assembly.

Preemption can respond between ticks. Time slicing gives equal-priority Ready tasks turns at ticks. They have separate FreeRTOS configuration switches .

How queues, semaphores and mutexes coordinate tasks and shared resources

RTOS task synchronization has two jobs here: deliver the sensor sample and wake the waiting control task. Choose the kernel object by what needs to cross that boundary.

A sample becoming available can move its waiting receiver Blocked → Ready. CPU access comes next. A semaphore carries availability, not the sample itself; a mutex adds ownership and basic priority inheritance.

Inside FreeRTOS, a queue combines a circular payload buffer, an item count, and lists of tasks waiting to send or receive. Sending copies the configured item bytes and may release a waiting receiver. Semaphores reuse queue machinery with zero-sized data items: the count and waiting lists matter, not a payload buffer. A mutex additionally tracks its holder so the kernel can temporarily raise that owner’s priority. The queue implementation makes these relationships concrete.

3. Why a critical correction can still be delayed

Why a ready control task cannot always run immediately

A high-priority task can be eligible yet unable to take over the CPU. It can also be waiting on a dependency. Raising its task priority alone does not automatically remove either wait.

Critical sections, interrupt masking, scheduler suspension, and ISR execution can postpone task dispatch—including in FreeRTOS. Protected work has no special “highest task priority”; it temporarily restricts when switching can happen.

Consider a Linux driver holding spinlock_t on a non-PREEMPT_RT CPU. An enabled interrupt can wake a higher-priority control thread and set a rescheduling request. On returning from the interrupt, the CPU may still have to finish the protected driver section before switching. The control thread is Ready; the remaining protected work is part of its response-time budget.

vTaskSuspendAll() in FreeRTOS is different from masking interrupts: ISRs can still execute, but task switching is postponed until scheduler resumption processes deferred work. A Cortex-M critical section instead uses port-specific interrupt masking. Raising a task’s priority does not undo either mechanism. The Linux locking rules explain the corresponding spinlock and IRQ distinctions.

With a mutex supporting priority inheritance, its owner temporarily inherits the priority of a higher-priority task waiting for it. This helps the owner finish and release the resource. It does not remove the critical work, cure deadlock, or bound a device that never responds.

How FreeRTOS and desktop Linux differ—and what PREEMPT_RT changes

An RTOS vs Linux comparison must account for the complete response path. Both kernels manage task states, priorities, preemption, and interrupts; the distinction is how the configured system controls interference across that path.

PREEMPT_RT is a Linux configuration, not a FreeRTOS feature. It places more kernel work under scheduler control through threaded interrupts and PI-aware sleeping locks.

A typical threaded IRQ path keeps a short hard-interrupt entry that acknowledges or masks the source, then wakes an IRQ thread. That thread competes according to scheduling policy and priority. PREEMPT_RT changes normal spinlock_t to an RT-mutex-based implementation: a contender can sleep, and priority inheritance helps its owner progress. raw_spinlock_t, low-level entry paths, and other explicitly protected regions remain non-preemptible. See how RT kernels differ .

Real-time Linux on a suitably configured PC can perform robot control. Ordinary Ubuntu cannot simply be assumed to meet a strict deadline; neither can an unvalidated FreeRTOS system. Open-source licensing is independent of that timing question.

Memory can add another delay even after scheduling permits execution. With virtual memory, an instruction may fault because a page needs allocation, a copy-on-write copy, or a file/swap read. Only some faults involve storage. A typical MCU FreeRTOS system uses resident memory without demand paging, although allocation, flash/cache access, buses, and devices can still stall it.

For Linux control threads, prepare critical buffers and stack pages before starting the loop, prefault the needed mappings, and use appropriate memory locking while checking errors and limits. mlockall() does not make future allocation or copy-on-write harmless. PREEMPT_RT itself does not eliminate page faults; the memory-locking manual explains these constraints.

Now give the whole correction one budget. Add distinct bounds for sensing, interference, computation, transport, and output application; include higher-priority work that interrupts computation.

With 120 µs of waiting, the example totals 600 µs, leaving 400 µs before its 1,000 µs deadline. With 800 µs of waiting, the same fixed work totals 1,280 µs and arrives 280 µs late. These are teaching values, not board measurements.

Measure the actual output boundary. Scheduler latency alone does not reveal when a drive applies a command, and the largest observed delay in one run is not a worst-case proof.

4. From local control to a complete robot

Building the control firmware and exposing it through a custom SDK

The FreeRTOS vs Linux choice starts with the hardware that must sense and act. RAM, CPU architecture, peripheral drivers, and timing requirements determine which software can do that job. These are example choices for supported targets, with two options per platform.

Give sensing and feedback control explicit wake-ups, priorities, execution limits, and enough stack. Keep parsing, network traffic, logging, and storage from holding resources needed by the critical loop.

The kernel supplies scheduling and synchronization. Your firmware supplies the control behavior and drivers; a custom SDK exposes commands and measured state.

Here is the earlier interrupt handoff expressed as a small FreeRTOS pattern. A one-item queue keeps the latest complete sample. Create the queue and task before enabling the interrupt; acquire the sample through a bounded hardware path.

void sample_isr(void) {
  BaseType_t wake = pdFALSE;
  Sample s = read_ready_sample();
  xQueueOverwriteFromISR(
    sample_q, &s, &wake);
  portYIELD_FROM_ISR(wake);
}

void control_task(void *arg) {
  Sample s;
  for (;;) {
    xQueueReceive(sample_q, &s,
                  portMAX_DELAY);
    Target t = target_snapshot();
    Command u =
      control_step(s, t);
    actuator_write(u);
  }
}

The ISR copies a completed sample and requests a switch if required. The task waits without consuming CPU, reads a coherent target snapshot, computes the next output, and calls the driver. Copy a multi-field target as one consistent version using message passing or a bounded task-level lock; do not hold that lock across slow I/O.

For a periodic loop, use an appropriate timer or xTaskDelayUntil() rather than accumulating work time with repeated relative delays. Tick resolution must fit the period; sub-tick requirements need a suitable hardware timing source.

Set configUSE_PREEMPTION, the priority range, allocation options, and stack sizes in the supplied kernel configuration. Then implement the tasks and their synchronization. You normally configure and port the scheduler rather than writing Ready-list selection yourself. When running FreeRTOS on ESP32 with a supported dual-core ESP-IDF configuration, the scheduler also considers core affinity. Pinning a task does not isolate shared memory or buses; a local interrupt mask does not stop the other core. Shared data needs the target’s supported cross-core synchronization.

Define units, accepted ranges, timestamps, sequence numbers, acknowledgements, freshness, and timeout behavior. Receipt is not proof of physical execution.

At the wire boundary, define serialization explicitly: field widths, byte order, framing, and integrity checks where needed. Avoid sending a raw C structure whose padding may differ on the host. The controller validates a packet, publishes a complete target, and reports the sequence actually applied. A timeout can select a defined hold, ramp-down, or fault response appropriate to the mechanism. The SDK should expose that state, rather than disguising receipt as successful motion.

For a custom robot, scope these interfaces alongside sensing and actuator integration. VoicePing’s custom robotics development approach starts with the task and its operating environment.

How a kernel becomes a product platform. Customization can happen in the kernel port, in application firmware, or at the external SDK boundary. A company does not need to rewrite the scheduler to make a distinct controller.

Espressif documents a hardware-specific FreeRTOS implementation and integration. Bitcraze’s Crazyflie shows the other common route: use FreeRTOS tasks and add a sensor-to-estimator-to-controller-to-motor pipeline. Its stabilizer documentation and firmware source expose that application layer.

Unitree illustrates the public-interface layer. The SDK2 Go2 example publishes low-level motor commands and subscribes to state. Its Python SDK documents Cyclone DDS . This establishes an extensible robot interface; it does not establish that the hidden joint controllers use FreeRTOS. Keep the documented SDK behavior separate from assumptions about internal firmware.

Connecting local RTOS control with ROS 2 in quadrupeds and drones

Place that controller in the robot. A host can plan motion while local controllers close feedback loops and joint drives regulate current. Allocate each loop where its timing can be validated.

One possible quadruped architecturePut each loop where its timing can be met

Targets →← Measured feedback

HOSTLinux + ROS 2Plan motion

CONTROLLERLocal RTOSExecute feedback loop

JOINT DRIVEDrive firmwareRegulate current + power

ROS 2 is middleware; an RTOS is an operating-system kernel or platform. They have different responsibilities and often work together. Selected loops can also run on a suitable Linux/PREEMPT_RT host; ROS 2’s real-time design discussion explains the application-level constraints.

Linux is useful on the host because it supplies processes, camera/network drivers, robotics libraries, and deployment tools. PREEMPT_RT improves kernel responsiveness while retaining that platform. A ROS 2 callback still needs a suitable executor/thread policy, bounded work, and prepared memory; an RT kernel does not automatically make every callback real-time. FreeRTOS offers a smaller execution environment for local firmware, rather than a drop-in home for the host’s whole Linux software stack.

Choose the timing requirement before the kernel. A vision or mapping host may need throughput and a broad driver stack while a separate MCU closes the fast loop. A Linux host that directly owns a strict control deadline needs an appropriate real-time configuration and end-to-end validation. A PC can run PREEMPT_RT; ordinary desktop workloads often do not need its tighter latency objective.

These costs are workload-dependent. IRQ threads and priority-inheritance locking add bookkeeping; CPU placement and driver assumptions need review. Disabling deep sleep or frequency changes can trade energy efficiency for response time, but that is a tuning choice rather than an automatic effect of PREEMPT_RT. Canonical’s latency guide describes those practical trade-offs. A CPU-hogging real-time thread can starve other work even on a non-RT kernel.

This coexistence also appears in developer surveys. The two categories below cover different hardware roles; neither is a benchmark or a recommendation for a particular MCU.

Read “constrained” relative to an application’s RAM, flash, CPU, power, and I/O budget. An ESP32-class controller and a Linux edge computer can face different constraints. A survey’s broad Linux result does not establish that desktop Linux fits an ESP32. Memory capacity, MMU support, drivers, and measured loop timing must be checked for the actual board.

The same pattern supports drone stabilization. On supported flight boards, PX4 commonly uses NuttX; ArduPilot uses ChibiOS on many STM32 targets. Follow the PX4 flight-stack overview , system architecture , and ArduPilot porting guide .

Back to the quadruped

We can now follow the uneven-step correction all the way to the joint. The kernel organizes execution; the complete sensing, control, and actuation path determines whether it arrives in time.

For your next controller, trace one sensor event to the physical output. Name the deadline, account for each wait, and verify that boundary on hardware.

To take that controller into an application, explore VoicePing’s robotics engineering approach and define the hardware, control interfaces, and acceptance criteria together.