Intro

The Zeropilot design document explains the overall software architecture and the functionality of each part of the design using intuitive words and graphical representation. This document is also responsible for recording the design changes that have been made since the beginning of this project. Hopefully, by recording the reasonings for design decisions here, this document could enhance the current EFS members' understanding of ZP3.5 and drive ZP towards better.

...

This document aims to provide guidelines and standards with respect the ZeroPilot’s architecture. The goal is to have EFS members on the same page, making the project easier to both work with and build upon.

The following Knowledge Transfer (KT) videos aim serve as introductory lessons on how to work with and contribute to the ZeroPilot project.

• TODO: make and add videos

Architecture Overview

Since the EFS team simultaneously has members both on and offsite, ZeroPilot supports two builds, one hardware dependent and another hardware agnostic. To achieve this, we interface our higher level software with STM32 firmware through a driver suite that allows for dependency injection.

...

Its main components:

• Managers - Where the flight control software lies, it has the actual source files and unit tests to enhance test-driven development. ZP separates the flight control software into four main managers, they are:

  • System Manager - Coordination of other three managers, decision-making, inter-manager communication

  • Attitude Manager - Software that defines how the aircraft fly(flight mode).

  • Telemetry Manager - In charge of the communication with ground station

  • Path Manager - Grant ZP the ability to fly in a given path

• Drivers - the software that drives the sensors and actuators.

• Board Files - contains the stm32 HAL library, FreeRTOS, and the main.cpp.

• Model Configuration - select the hardware and software configuration of the aircraft.

• Tools - the scripts and makefiles that support the executable compilation and unit test compilation.

Problems we noticed:

• Unintuitive to Flash the Code: To compile with the former code is easy, we only need to run the script. But flashing the code is a little cumbersome. The way we did it, is by making a dummy stm32 project and directing the elf file we compile in the stm32 setting

• Difficulty in Debugging the Code: The newer version of stm32 ide no longer supports opening directories that don’t belong to a stm32 project. And since our board files are inside the ZP, all other main folders don’t show up in the stm32 ide, causing difficulties in debugging with stm32 ide. Unit tests in this version of zp

• Driver Dev Blocking Software Dev: No proper driver interface layer is defined for current drivers. That means the software doesn’t know what the driver interface function is supposed to look like before it is done. The software couldn’t mock the driver function since drivers are missing an abstraction layer.

• Confusing to Manage: This is more of a leader’s(my) issue. I found that since basically, each people manage their task, and different people have different implementations in their code. It makes ZP a difficult project to manage. The lack of design restrictions made this project difficult to integrate and caused incoherence.

Strucuture of Milestone M3

Its difference from the previous structure:

• Board Files at the same level as the Software Package

  • The idea here is to compile Zeropilot Software as an external library, so it fits any board file we wish to flash

  • Isolates hardware and software by folder structure

• Driver Interface and FreeRTOS Interface

  • Provide interface layers that define the data types and methods required by managers.

  • Removed the dependencies between manager development and driver code development

  • Allowing mock driver and mock FreeRTOS to be run in unit test since the real code is not unit testable.

• Mock Drivers

• Mock FreeRTOS

The hardware dependent build (yellow + blue components) is run on either STM32’s Nucleo boards or WARG’s custom ZeroPilot board. This build is used for end-to-end hardware-software integration testing and creating the final product that will fly the drone.

The hardware agnostic build (yellow + green components) can be run on desktops and laptops. The purpose of this build is to enable remote development and provide an environment for effective unit testing.

Manager Standards

This sections outlines the requirements that must be followed when designing solutions for ZeroPilot’s managers:

Driver Standards