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.
...
So what did we learn? There are 2 major take aways here:
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.
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