First post

A project log for MakerNet

The fast, intuitive and modular way to make awesome portable projects that maximize creativity and sharing

Jeremy GilbertJeremy Gilbert 04/13/2017 at 13:360 Comments

Wow, OK, here it is, my first post about Makernet. The last four months have been a busy blur with my day job plus my Makernet hacking work crammed in between. I am remiss in keeping this journal up to date and even explaining to anyone out there what the idea is about.

The goal of Makernet is simple: Democratize the creation of projects where the increase in hardware complexity creates sub-linear increases in complexity. Or in laymen terms, adding more stuff to your project should be easy, transparent and modular. The result will be faster learning for new makers, because it makes hardware look and act more like the software paradigms they are already used to in their daily life.

Wow. OK. So what do I mean by that?

I want hardware projects to act more like software projects where there are libraries of interchangeable parts with clean abstraction barriers, substitutability, and clean APIs.

You want to swap out your rotary encoder scrolling interface for a touch-based one? That should be a snap. A 10 minute job.

You want to refactor your project case to sit on your desk rather than your shelf? That should be easy. 30 minutes or less.

Here's the challenge -- for many reasons, hardware engineers don't typically think about clean lines of abstraction and modularity. They often cant - a OLED display needs extra control lines and and SPI interface. A rotary encoder needs to be on interrupt generating pins. There are tons of wired dependencies that take hours to understand and grapple with. So the typical project has multiple design layers: the physical layout of the project, the PCB layout, the circuit design and finally the code design. All of these different things become hopelessly tangled together. You want to experiment with a different user interface for your project? Or add a new peripheral? In many cases, you end up re-designing half of your project! So you end up with cascading complexity when you start adding new things.

This is not how pure software works. In pure software, you pick really good abstraction layers that keep one part of your project from touching other parts. CSS keeps your styling separate from your rendering code. React keeps your UI logic separate from your back-end. I'm not saying web technology isn't complex, but we've done so much to iron it out and smooth it down to clean borders.

I want to help do this for hardware makers. Especially young, up-and-coming makers.

I want to meaningfully make it easier for the average hardware builder to benefit from modularity of the components they use, and the software they use to talk to their hardware.

So why is this good for the world?

In short, I think it will transform the way people learn about and understand electronics. Young makers are exposed to computers and software early in life. They use Minecraft. They tinker with legos. The use USB to plug in new webcams. They expect their world to be rearrangeable using software-like principals. Hardware in its current form will seem archaic, like a weird throwback. Things like I2C address conflicts, and the hardware internals of PWM are great to understand eventually, but should not be a major consideration for new makers.

In my view, early makers should be exposed to simple combinations of hardware and software that they can tinker with and earn fast results. They should be able to start building things that resemble the world around them quickly. And they should be insulated from complexity until they are ready to dive into it. They should stay frustrated enough that they have to learn and it doesn't come too easy, but not so frustrated that they half to walk away from projects they think and known ought to be simple.

I also fundamentally believe that projects should be shareable. If my daughter builds a cool little project that glows different colors based on the temperature, she should be able to take it with her. She should be able to show it to her class, or take it on a play date. It should fit into her pocket. Sharability is a major driver in our world - it is the portable things like photos, 140 character ideas, little lego contraptions, phone applications, or minecraft savefiles that drive the ability for skills to spread within young social circles. And sharing creates gratification that spurs you to build more!

Breadboards are awesome for learning the basics, but they do not create shareable projects. How many cool things have been created in the world that could be shared to spread the word but haven't because they can't get past the breadboarding stage? Also, breadboards work on the layer of abstraction of the underlying wires. This means that a device of any complexity rapidly becomes unmanageable and hard to debug if it stays on a breadboard.

So come along on a bit of imagination with me for a second.

What if every bit of hardware acted like a USB device? Or a computer on a network? Imagine the bits of hardware in your project were on a common network. And it was really easy to connect them together or rearrange them in different ways. You want a sound to play? Send the sound playing module a command! Want a blue shaded box to appear on a OLED display? Send a command to the OLED module. Want to add a touchpad to a project? Just plug it in into your project's network and write a tiny bit of glue code.

Think of every module in your project being networked. Your potentiometer volume control? Networked. Your status LED? Networked. Your LIPO charger? Networked.

Every device is connected by four pins: power, ground, and network differential pairs. It doesn't matter what order you connect them, or which component is on which pins. Its simple - modular, just like ethernet.

In this world, its easy to rearrange the shape of your project. It easy to stuff it into a case, or reassemble it if something breaks. If you want to borrow one part for another idea, you can do it easily without desoldering anything.

I can already hear you saying "Hey, aren't you describing CANBUS?" Or "Aren't you describing I2C or SPI?" Well, yes. I am. But I want consistency. I want a whole portfolio of little useful modules all available on one common protocol. And I want to abstract away all of the pesky details like I2C addresses, level translation, and tons of other things like that. I want many different hardware peripherals that are all just based on these four basic pins with zero wacky exceptions or stumbling blocks for new makers.

This is the basic concept of Makernet.

So doesn't this drive up the cost of every project? Won't this require extra glue logic and networking controllers? Yes. It does. Every device will need an MCU and a transceiver. But this is not a big deal. You can source these parts for almost nothing.

My first goal is to show this is possible. Right now I am constructing a proof of concept of a few different modular types. I am experimenting with the ergonomics and form factors. I want to quickly demonstrate a wide diversity of different project types that can all work via Makernet.