Intro to real-time software


Read chapter 25 from Programming: Principles and Practice Using C++ (2nd edition) for an introduction to embedded systems software development.


Real-time in FRC

When writing robot code, one should be mindful about how much work a given thread is doing relative to its perceived priority. A robot typically has the following tasks running in different processes or threads, which will be addressed in order of priority.

Their effective priority can be maintained by either adjusting their real-time priority (if they are set as real-time threads or processes) or adding waits to the ends of their loops to reduce the rate at which they execute.

FRC network communication process

This process handles communication between the robot and the driver station. If other tasks starve this process for CPU time or network bandwidth, robot connectivity during competition will be affected.

Feedback control loops

These run as threads and are typically executed at between 20Hz and 200hz (periods of 50ms and 5ms respectively). Given that they are digital feedback controllers, they should be run as fast as possible, without starving other processes, to limit phase loss in the controller implementation (see the modern control theory module for more).

User input

This includes joystick axis movements, button presses, and other control actions originating from the driver via the driver station. These can run at lower sample rates since a human's response time to stimuli is much slower than the tasks previously mentioned. That is, responding immediately is less important.

A good sample rate for user input is 10ms. See FRC 1 for examples.

Telemetry and logging

Information like graph data, print statements, and event logging are the least important from a real-time perspective. Their impact should be minimized in this regard, but they definitely help for feedback controller tuning, assessing robot performance, and debugging.

Its effect on network bandwidth utilization should also be monitored.