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:

1. Keep Things Simple. If we can keep things as simple as possible (architecture, design, implementation) it will save a lot of hassle as we continue to develop. Instead of slamming some “future proof” framework into everyone’s face and forcing them to work with it, let’s start with the basics and continue to build, slowing introducing complexity as we require.

   Although, complexity is sometimes still required, for example, we are still not willing to give up not supporting multiple board packages and flight frames because those issues are immediate and it would be a poor choice to lock us into that type of design. So what we can do is have a really good team discussion, come up with solutions, and document those solutions so everyone knows what is going on.

2. Incremental Development (aka Milestones). Building off the last point, if we keep things simple at first and gradually increase complexity with defined goals in mind, we will set up ourselves for success.

   Last time, we wanted to do everything at once, implement this complex (and quite frankly, unnecessary) framework immediately without having set the groundwork. Now, in industry where everyone is working 8 hours a day, this is possible, but for a design team, it is a stretch. To circumvent this, we would like to introduce milestones, which are a set of goals (that should be completed in order) meant to keep us on track and allow each completed milestone to be a fallback in case the next milestone gets iffy. Basically a “save your progress” button in a game.

   The first couple of milestones should not be too complex, but each milestone after that will introduce new features and concepts that may increase complexity but allow us to work off of something that we know is working (the previous milestone).

Introduction

WIP

Milestones

Milestone are something that is meant to keep us on track, prevent us from looking too far into the future, and give us a safety net to fall back on in case we royally mess up the next milestone and want to start again.

The idea here is that, as a team we will always be working on the next milestone. Once we can definitively say we have reached that milestone through testing and results, we will save that progress (either a tag on a commit or just branch off and never touch that branch). By doing this, we have our sights set on the next goal, giving us a clear sense of priority. Additionally, since we are “saving our progress” each milestone, we have something that we can fall back on or use as the groundwork for the next milestones since we know the previous one is confirmed to be working.

Currently, you can check out our milestones in this meeting minutes doc: Los Discussion 2 and the current progress on the Asana.

Design

WIP