Minimum Viable Quad Build Shows What Starting From Nothing Can Accomplish

While it’s great to be experienced and have a ton of specialist knowledge needed to solve a problem, there’s something liberating about coming at things from a position of ignorance. Starting at ground zero can lead you down the path less traveled, and reveal solutions that might otherwise not have presented themselves. And, if [Robin Debreuil]’s exploration of the “minimum viable quadcopter” is any example, some pretty fun failure modes too.

The minimum viable product concept is nothing new of course, being a core concept in Lean methodologies and a common practice in many different industries. The idea of building an MVP is to get something working and in the hands of users, who will then give you feedback on everything wrong with it, plus, if you’re lucky, what you got right. That feedback informs the next design, which leads to more feedback and a whole iterative process that should design the perfect widget.

In [Robin]’s case, he wanted to build a quadcopter, but didn’t know where to start. So his first version was as simple as possible: a motor with a propellor and a small LiPo battery. No chassis, no control electronics — nothing. And it worked just about as well as expected. But fixing that problem led to different designs, the process of which was fascinating — we especially liked the quad with opposing motors controlled by mercury tilt switches to sense attitude changes.

In the end, [Robin] took a more conventional tack and used a microcontroller and BetaFlight to get his popsicle stick and hot glue UAV airborne. But the decision to start with a minimum viable design and iterate from there was a powerful learning experience in tune with [Robin]’s off-beat and low-key outlook, which we’ve seen before with his use of bismuth for desoldering and his scratch-off PCBs.

11 thoughts on “Minimum Viable Quad Build Shows What Starting From Nothing Can Accomplish

  1. It is worth noting that MVP is not actually about reinventing the wheel or ignoring established knowledge. It might be fun to do that and learn for yourself but it is a misuse of the terminology.

      1. Both valid points! That being said, to find new ways of doing MVPs it can certainly be helpful to go over the basics and analyze them again with a more informed perspective to see how we got to where we are now tech-wise & products that are available in common use.

        I feel this video was a lot of fun, from the experimentation process to the (minor) successes. Definitely feels like something hacking away at a project with some vague goals… :D

      1. My bad. I start with the slide, “Minimal Viable Flying Thing” and went from there, but seeing as none of them were very viable other than the quadcopter, I called it that. I’ve worked with MVP in a few startups, and while the outward facing process is relatively refined, internally we always started from zero and left a lot of experimental scrap on the floor. This is probably more like the internal process with MVP — not sure I’d even hand that last one to a customer :).

  2. I like the process, I like the basics and I like the video.
    Not “like” as in thumbs up button, but as in the effort.

    I love going back to basics in my line of work, IT, but get slapped sometimes, because some problems are hard. Sometimes I argue, “this problem is not hard enough to make weak choices”, mostly focused on security.

    Anyhow. Glad you found out mercury switches don’t switch fast enough, so I don’t have to try that :)


Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.