Real Time Systems

Background Knowledge:

Human computer interfaces are growing more prominent as we enter a more digitalized society. Robotics must react to split second decisions, in a quick and timely manner. In the case of self driving cars it is even more important as we see now, that effects must be instantaneous. Most robotics systems today unfortunately do not use RTOS systems, but rather use ROS. Which has quite a large delay in processing information. With moore’s law, the effects seem negligible however over time they add up and cause glitchs. Below is a more indepth view of RTOS systems.

Quick Run:

There are 2 types of RTOS: soft real time systems, and hard real time systems. The difference between them is in a soft real time system deadlines can be missed, while in a hard real time system deadlines cannot be missed. Within these 2 systems there are also 2 different schools of scheduling, the first is an event driven model, and the second is a time sharing model.

Event Driven Model (Interrupts):

This is a model which is very commonly used, especially among new engineers. Interrupts seem to be the perfect solution due to the fact you do not need to know when a particular thing is going to trigger. Unfortunately, interrupts also have a very negative association with them. Most engineers do not learn how to properly handle interrupts. The greatest example of improper interrupt handling is the Mars Rover, where a critical interrupt was not being triggered due to the fact that a lower priority interrupt was being triggered, and interrupts were being turned off inside the interrupt. Preventing the critical interrupt from being triggered.

Poll Driven Model:

This is a model where we have a single timer which alternates through tasks to finish them in a timely manner. This one also has flaws such as tasks which are in a waiting state will still have an alloted time period in which the CPU is waiting for it.

Hybrid Systems:

This is the smarter systems as it allows the best of both worlds. You create a form of state machine for each task. The tasks can be pushed and popped on and off of priority queues for execution based on if they are in an executing state or in a waiting state (waiting for user input). This allows you to code correctly for interrupts which involves preventing further interrupts, and minimizes the code necessary to be executed in an interrupt state (because interrupt states are privileged CPU states that allow more access). It also allows us to have a proper way for turning the system into a low power consumption were we only monitor for external interrupts. This is possible in systems which do not have to be constantly computing. We can also use time sharing for the scheduling of the CPU, to allow us not to miss crucial deadlines.

Most Important Tidbits: