Intro
While Zeropilot’s design should follow the simplicity design principle, it should also provide a pleasant development experience as it is a collaborative project. In the early development of ZeroPilot 3.5, though we had the basic functionalities and framework in mind, every module was loosely defined, and this caused difficulty and inconsistency in development. This brings out today's topic, a formal definition of the Zeropilot 3.5 framework.
Former Structure
Let’s start with the former structure, talking about our original objectives, and the points we want to improve from there.
...
Its main components:
Managers - where the flight control software lies, it has the actual source files and unit test to enhance test-driven development
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:
Flashing 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
Debugging the code: With the newer version of stm32 ide, it 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.
Confused 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. Sometimes, we don’t know what we want, or sometimes we don’t know where we are supposed to implement the functionality we want.
New Design
What we want to get from the design (Goals)
Design
EFS lead should define the goals and implementation to part of the manager. The design of software is a shared responsibility of the leads and PM. The design should be done before task delegation.
more actual explanation of the design
Explanation of the design
...
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. To view the videos, you must be logged into your UWaterloo OneDrive.
Part 1: Design and Standards Overview
1 - General Information
2 - Drivers
3 - Managers
4 - Putting It All Together
Part 2: Working The Codebase - Coming Soon
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.
| Drawio | ||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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:
Rule | Rationale |
|---|---|
Managers must not include hardware specific functions. | As common files, managers need to be hardware agnostic. They cannot directly include code designed for specialized hardware (RTOS facilities, serial communication drivers). |
Managers must not instantiate their own drivers. | Managers need to implement all their driver interactions with driver interfaces. Driver interfaces will point to a driver instance that is passed in via the manager constructor. |
Managers must not directly read fields from each other. | Managers will interact with each other via CMSIS Memory Queue drivers. This promotes thread safety, and keeps hardware specific flow control features (mutexes and semaphores) out of managers. |
Driver Standards
This sections outlines the requirements that must be followed when designing solutions for ZeroPilot’s managers:
Rule | Rationale |
|---|---|
Drivers must have an abstract interface that cannot be instantiated. | Interfaces will be used by managers to achieve dependency injection. Interfaces themselves have no substance, and thus should not be instantiable. |
Drivers must include both a real and a mock implementation. | This two implementation design allows for the two build architecture, providing the foundation for both hardware and testing builds. |
DAQ drivers are preferably implemented with DMA. | Direct Memory Access is preferred for Data Acquisition related drivers, especially those which operate at high frequency, as it offloads work from the CPU. |