Full Stack Robotics

Introduction

When reading about a robotics system I’ve often found that writers tend to split the systems into two main sections, hardware and software. I find that this works as an introduction, but undersells the complexity of the software stack that makes up modern robotics systems. This post aims to remedy that by providing a comprehensive overview of the full stack of robotics systems.

Before we dive into the different software layers, lets take a brief moment to understand why we even want a layered architecture. After all, most web applications are organised as a collection of peers and that microservice archtecture works well for them.

Consider a middling level function such as navigation. The purpose here is to find a path between the current location and the desired location. This can be done in numerous ways but the end result is a series of waypoints that the robot needs to navigate between, A -> B -> C -> D. But what happens if something interrupts that plan? Maybe a door closes, or a vehicle moves, or a person strolls in front? Well we would simply need to make a new plan! But how long does that take? What if the environment has changed again by the time we finish? Do we stop the robot while it’s planning stalling movement completely in a busy environment? Or do we continue moving and potentially crash into something (or someone!).

One solution is to have a second “local” planner which rather than focusing on the full path from A -> D, it might only looks at a single waypoint, A -> B. Now when an “obstacle” appears, (a vehicle, person, another robot, etc), we only need to recalculate a little part of the overall plan and by doing so we reduce the time to process it. (Note that this is a simplification of a true local planner which I’ll come back to later). This trade-off between large complex tasks, and time to act, is the fundemental safety question in robotics and the primary reason we split the stack into layers. Each layer becomes responsible for a small but well defined task where we can assess the safety implications more easily. Higher layers can rely on the safety requirements that lower layers guarantee and focus on their own safety requirements.

Layers

Each layer has two interfaces, between it and the layer below, and between it and the layer above. It also has safety guarantees and time requirement.

Hardware

Hard to draw a line, most “hardware” has its own software (firmware) in it. Safety wise things like lidar provide a safety “envelope” which can send a signal to halt the robot if something is inside it. The motor system might have torque limits to avoid damage if a collision does happen.

Embedded layer

Normally the “internal” firmware for a robot. Very fast, hooks up various sensors and actuators. Doesn’t have much context. Stops the robot if the safety envelope is breached or an estop is pressed, etc. Moves the robot safely based on mass, speed, and torque based on commands from the

Base layer

Converts a single position goal into velocity goals and applies limits to the speed and direction of the robot. Slows down when near obstacles and tweaks the velocities to move around them when possible. Gets commands from

Takes large goals and breaks them down into a path with many waypoints. Avoids busy areas, applies speed constraints to “zones”.

Task layer

Last layer normally on the robot - based on the purpose of the robot, generates high level goals. i.e. navigate to the fridge

Fleet layer

Runs on a server- cloud or local Delegates tasks across many robots

Operations layer

Maintains the entire robotic fleet across organisation - monitoring, upgrading, etc