[Okay, I am more leaning towards not doing a zp structure rework now. The page will need a re-write]
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
...
Intro
The Zeropilot design document serves to explain 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 understanding of ZP3.5 to the current EFS members and drive ZP towards better.
Structure for Milestones 1 & 2
...
Its main components:
Managers - where Where the flight control software lies, it has the actual source files and unit test 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:
Flashing Unintuitive to Flash the codeCode: 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 Difficult to Debug the codeCode: 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 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. 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.
...
Strucuture of Milestone M3
Explanation of the design
...