Background

At this point, you have probably seen something similar to this page for all the ZeroPilots (successful and unsuccessful), kind of seems like all those Spider-Man reboots. Well, this time around, we have elected to take a different approach to developing ZeroPilot that is more objective based, allowing us to take incremental steps towards success. We have learned from our past mistakes and have taken measures and implemented design decisions to avoid those mistakes in the future.

Past Mistakes (and what we learned)

Last year (current time of writing: May 28, 2023), we had a big transition away from the ZeroPilot2 software which was very different in terms of design. It supported 2 independent microcontrollers (Safety and AutoPilot). At this time was when we started development of the ZeroPilot3 Custom Flight Controller PCB which happened to contain a different microcontroller chip than previous iterations (because of the chip shortage, we literally scooped up the first microcontroller that we could find good volume for). This instantly sparked discussion about having software that could support multiple board packages as well as drone frames since the upcoming competition would see to a VTOL based drone rather than a multi-copter design.

What we came up with was LOS (LaminarOS) which was meant to be a middleware interface between our higher level software (the managers) and the lower level board packages. In theory this is exactly what a system with changing board packages and flight frames needed, but it contains many fatal flaws that has led us here, talking about an alternate design.

Some of the flaws/hardships include:

• Submodules: good in theory but for a design team where new members are not as familiar with their usage, makes development confusing.

• Config files: were a work around solution for a problem we did not foresee. Lack of documentation on their usage led to them becoming very messy and unorganized.

• Initial discussion on this design was all about “future proofing” without thinking about the smaller steps/goals. The do everything NOW and RIGHT mentality was very present, which is not a bad thing, but it is important to think about what is feasible.

• LOS (which was a git sub module to the ZP repo) contained the boardfiles, a very poor design decision that was a result of poor planning.

So what did we learn? There are 2 major take aways here:

Introduction

Milestones