Architecture

A high-level overview of the different devices across the rover

The rover has three layers of code that run in different environments. Each layer builds on the previous one to provide extra functionality. The following diagram shows an overview, and the following sections explain in more detail.

All the different software components on the rover and how they communicate

The Firmware

Firmware is at the bottom of the stack — the code that drives the hardware. We have firmware for four subteams: HREI (Arm), EA (Science), Electrical, and Drive. Each subsystem gets its own Arduino microcontroller with code specific to its subsystem and is completely independent of the other firmware. Off-rover, we have a base station setup with a small firmware setup to control the antenna.

This code handles the nitty-gritty details of basic tasks. For example, what could be described as "drive forward" is implemented as a signal on specific pins to drive motors. Once the firmware handles these details, they are never implemented again, and the higher-level API is used instead.

The Software

These devices are the brains of the rover, running on Raspberry Pis. We've chosen Dart to run our programs, but in the past, they have been written in Python or C++. They perform any complex task that doesn't fit within any one subsystem. These programs are separate but don't necessarily have to run on different devices. Currently, we use these computers to:

• Coordinate all the firmware

• Stream and analyze video from all attached cameras and sensors

• Drive the rover autonomously for the Autonomous Navigation mission

The Subsystems program is the main controller of the rover since it ultimately drives the hardware. Any connections to the rover should start here, and no firmware on the rover should be read from or controlled by any other code. Similarly, the Base Station program represents the off-rover responsibilities, like coordinating the antenna firmware with the rover and Dashboard.

The Dashboard

The Dashboard is our user-friendly application that connects to the onboard computers, streams data from them, and sends commands on the user's behalf. This is perhaps the most complex system "on" the rover, since it needs to interface with, ultimately, every other system, whereas most other systems are independent.

The Dashboard is meant to be the ultimate testing, debugging, and operating tool for all our needs. If you need to test any device, it should be possible via the Dashboard. So, aside from connecting to the software on the rover over UDP, the Dashboard can also connect to any firmware device over USB.

While other teams configure their rover to expose a web server and host their dashboard on the rover, we see all this complexity as reason enough to extract it to its own program. And not use JavaScript. Instead, we use Flutter, a cross-platform app framework, with a practical focus on a Windows application. Since Flutter uses Dart, we get to share a lot of code with the rover — particularly, our networking protocols.