RTOS Design Project: Robot with Power Saving Features

In Spring of 2024, I took a real-time operating systems (RTOS) course and learned how to write sophisticated yet responsive microncontroller software using for the ARM Cortex M4 archetecture with the FreeRTOS library.

The class was an opportunity to make tangible projects like a Spectrum Analyzer, a Wireless Chat Program, and an independent project using low-level chip peripheral programming and FreeRTOS . For my project, I chose to make a wirelessly controllable robot with power-saving featured here!

System Summary

As shown below, this system consists of two key parts: the actual robot and the commander board. The robot's job is to obediently queue up commands sent wirelessly from the user and run them. The commander board provides the interface needed to do this from a standard personal computer.

Robot Components

Drivetrain: 2WD with caster wheel
Motro Controller: L298N (Dual H-Bridge)
Main Computer: STM32L476RG (Cortex M4 MCU Arch)
Transceiver and Protocol: SPIRIT1 Radio w/ STack Protocol
Controller Battery: Miady 5000 mAh
Drivetrain Battery: 4x 2300 mAh AA Energizer NiMH rechargable batteries

Commander Board Components

User Laptop: Computer with a USB connection and software like PuTTY to open serial console connection @ 115200 baud
Main Computer: STM32L476RG (Cortex M4 MCU Arch)
Transceiver and Protocol: SPIRIT1 Radio w/ STack Protocol

Hardware Archetecture

In order to facillitate much of the communication, the SPIRIT1 radio was used. It uses SPI and GPIO interrupts to communicate with a main STM32 controller.

Robot HW Archtecture Design Choices

The STM32L476 advanced timer peripheral (Timer 1 in this case) is used as it has features suited for motor control like pulse width modulation.
The timer supports supports multiple PWM channels and hence can enable for indepednent speed control which is used for this case.
STM32 power and motor power are intentionally different since the motors require more power to be driven, and it would be desirable to be scientific instruments like sensors still run if the motor battery fails.

Commander Board HW Archetecture Design Choices

UART will be used as the interface between the commander board and user to enable a text-console based control interface which can easily be expanded upon in the future

With the arch specified, it was now possible to implement the archecture in a hardware schematic with the assistance of STM32CubeIDE.

Robot Schematic

Controller Schematic

Software Archetecture

Although the hardware archetecture is mostly straightforward, most of the design complexity is in the software. It leverages FreeRTOS, a custom network stack to facilitate communication, and Arm M4 power saving features.

Network Protocol Stack

As this diagram reveals, the protocol stack bases itself off of the SPIRIT1 Radio and STack protocol. The STack Protocol enables for devices to have unique addresses and essentially handles layers 2-4 of the diagram. With more development the project could be expanded to control a network of robots or have them work together. Layer 5 would be command interface used by the user and the robots state diagram shown on the right for the robot.

Robot Software State Diagram

Through the use of FreeRTOS tasks, mutexes, semaphores, and queues, the robot software can fundamentally act as a state machine where, at any point in time, the robot is in one of the 5 shown states.
The Task Selection State is the state that occurs when control is yielded to the FreeRTOS Scheduler. The scheduler is in charge of scheduling the next task. When nothing can be scheduled, the robot goes into the Sleep state, which puts the M4 processer into a power-saving Sleep state
The Startup State is the second state the robot enters after the very first round of task selection. It is a task and given the highest priority so that the scheduler, no matter what, always schedules it first. It performs initial configuration and then deletes itself once it is done running.
The recieve task is scheduled whenever a radio-access mutex, which can be thought of as like a key to access something, is free. In this case, the mutex controls access to the radio since the radio cannot receive and transmmit at the same time. Once it acccepts the mutex, it gives it back once the task is done. It places recieved commands into a FreeRTOS queue.
The movement state is a state where a movment command in the queue is actually carried out. If there is nothing in the queue, the task does not get scheduled.

Commander Software State Diagram

The commander board software, much like the robot software, operates based on a state diagram.
It operates in a similar fashion in the sense that it uses semaphores and mutexes to control which tasks get scheduled, however it has a task to handle input from the keyboard and disaply a console to the terminal

Results

From power calculations done with the battery capacity and current-draw measurements from the current monitor port of the STM32 using a current-meter, the predicted best case and worst case run-time was found. With the power-saving features, in the best case, the STM32 on the robot can remain powered for 578 hours. Without powersaving, this number is closer to 350 hours. Thus in the best case , the system gets a whole 228 hours of extra runtime! The motors battery life for the motors however, depends on usage and is only 9 hours if they run at 100% the entire time and 344 hours when not running.

Functional test (wheels removed for safety)

20240603_094252.mp4

Example Inserted Command

As the code relates to a course, I cannot release it publicly at this time. However in case you would like to see the code or have questions, don't hesitate to contact me! This is a very large project and this portfolio is a very surface level description of it. There are many other diagrams I can share as well!

Page updated

Google Sites

Report abuse