The bent and broken pieces of the drone were lying scattered on a table in the office. There wasn’t much worth looking at; most of the components shattered beyond repair. The PizzaCopter team looked at the mangled mess at the table. No one really wanted to be the first to talk about the crash.
“Well,” said the lead developer, “it looks like there was a bug with the range sensor. The flight controller didn’t contain a type check on the data and so when it corrupted it interpreted it as NaN and didn’t know what to do. At that point it just sped up and became a high speed projectile with a pizza and smashed into the ground.”
— Glenn Siegman (@gsiegman) August 15, 2013
I’ll tell you what would’ve happened. It would’ve crashed into Venus spitting out NaN errors.
— Glenn Siegman (@gsiegman) August 15, 2013
I’ve spent a while trying to articulate my thinking on this as it’s a complex topic that touches on hardware, design, engineering, community and education. I don’t profess to have all the answers but I hope writing about these topics will create discussion about the role of projects like this in the community.
Growing up a nerd
As a kid I was much more into electronics than I was programming – interested in why a computer worked rather than how to run code on it. I didn’t have access to much hardware but dismantled every toy, VCR, blender or TV I could lay my hands on to understand how they worked. As I got older and computers got more powerful I got lured to the software side due to the ability to make things happen faster – particularly as a result of the Amiga demo-scene of the early 90s.
Eventually, my very first “tech job” was a summer job before writing software drivers for the very first resistive touch screens (Windows 3 and Amigas). These were used for multimedia installations in places like museums and were all custom built. I found it interesting and a lot of the software the screens interacted with was hypermedia. I realised then that I was actually very interested in how people interact with things rather than the things themselves. That went on to manifest itself in my degree choices (Psychology & CS) and then into working with the web very early on and that’s been my career ever since. As a web developer I have always been much more interested in how and why someone interacts with something than the technology that underpins that interaction.
Even though my day job is and has been web development for a considerable number of years I’ve always dabbled with hardware, particularly embedded systems and this increased significantly since 2007.
Having access to free development environments to tinker at a low level (initially with USB development kits) with Linux and then subsequently with the excellent hardware package that is Arduino brought me back to hardware in a big way. Since then I’ve been developing “things” for art, research, personal interest, fixing things for people, scratching itches and generally trying to join hardware with the web. I’ve spoken around the world on the topic and even helped provide feedback on new products being designed.
Over this time I’ve used many different AVR based chips and boards, played with PICs, designed my own boards, blown many things up and have achieved a passable knowledge of how to build and use modern electronics – especially when you want to have a physical “thing” that is interactive and connected to the web.
Executing console.log(“hello world”) or window.alert(2+5-20) brings immediate feedback, makes you feel as though you’re getting somewhere and that you are interacting directly with the computer as a programmer. For those of you old enough to own a Spectrum, C64 or Vic20 – BASIC (itself heavily derided) had the same benefit.
Many of those in their 30s got their first intro to programming by doing this:
10 print “Andrew rulez” 20 goto 10 >run
Immediacy of feedback is a powerful learning step and one that simply cannot be replicated by languages like C. Download and install your build tools, create make files, do your compilation and linking steps. Oops, syntax error! Now go back and do this all again once you fix it. Even as a seasoned embedded developer I HATE going through this process a bajillion times a day.
What must be remembered is that students entering and graduating Computer Science degrees are at an all time low and have been declining for years. And yet the number of informally educated developers in the web community is astonishing, many of them doing excellent work every day.
The ability to self-learn with nothing more than a web browser and an enquiring mind should be seen as the greatest gift the programming community has been given. From my perspective as a senior technologist it’s certainly helped when it comes to availability of great developers to work with that our traditional educational systems have failed to provide.
Given this combination of accessibility and immediacy we find ourselves with an increasingly powerful language that is being extended further and further into “traditional” use cases of “real” languages like C++ (and dare I say Java??) and for reasons that can only be considered protectionist this is met with resistance.
At this point I will direct the reader to “The innovator’s dilemma” by Clayton Christiansen. The gist of which is this:
The incumbents write it off for lack of comparability, usually saying “no one would use that – it doesn’t do x, y, z”.
Over time, users of the new technology get involved with its direction and the features they need to make it better get added – usually at a considerably reduced price and they get the benefit of learning from all the implementations that came before.
Eventually the upstarts take large swathes of the market, seemingly overnight, and the incumbents are left with husks of their former positions – often unable to explain how they got to that point and were unable to see the threat.
After that came the excellent Serial library for node (removing my final objection to using JS with hardware). This meant that applications could control devices that are plugged in via USB. All of a sudden everything from controllable lights (eg Blink1) through to small scale robots started popping up.
So within just over 12 months the community has gone from almost no hardware capability at all to being able to control things that fly, crawl and walk, make things light up and sense the environment. Yes much of this stands on the shoulders of other protocols, libraries and hardware but that’s not the point (all software if built on the shoulders of lower foundations all the way down). The point is that when something is technically possible people will start doing things with it.
I’ve been playing around with web controlled “things” for years. For most of that time, particularly in Melbourne, it has felt very much like I was the only person doing it. There have been others dabbling from time to time but they were mostly coming at it from the engineering side (eg make a thing simply shift data over the network etc). Internationally this was reflected as well – those working truly from a web perspective on hardware design for the last several years could be numbered in the small hundreds at absolute best.
I used Web Sockets to talk to hardware devices very early on and was consistently dismissed (even ridiculed) because HTTP & WS are heavy protocols and there are technically better ways to do it (there are eg MQTT). Now this is nowhere near an extreme position for these types of comms. Why? Because immediacy gives you the ability to prototype rapidly. A web sockets server in JS can be implemented in 15 lines of code plus “npm install express socketio firmata”). Accessibility means that you can find a LOT of developers who can do exactly that code above and actually know how it’s going to work even without hardware knowledge. Try and do the same thing with tech like MQTT or Protocol Buffers and your pool of talent drops spectacularly.
So as this hardware has become more accessible, more developers are attempting to work with it. This is a GOOD THING because through exploration of a design space we get more coverage with the more practitioners. This is why the web has taken over just about every facet of our lives, because we have designers and developers tinkering on new ways of doing things or new ways of conveying information all the time. This effect should not be underestimated and we are only at the start of it.
One of my more contentious views is that your average web developer or designer in 2013 would have been a cabinet-maker, smith or instrument maker in 1913. I won’t get into all the details of this but suffice to say that most developers and designers who work with the web have an intrinsic desire to “make” things. Most of them even refer to web work as a “craft” as much as a profession.
Once you couple the skills of a few hundred thousand web developers and designers with the ability to design, build and fabricate actual physical things that talk to the web you start ending up with interesting things. Robots controllable from mobile phones, house lights you can interact with, art where data from a buoy in the middle of the ocean is tele-present in the middle of a gallery in Poland.
Making hardware available to web developers is a desirable goal. Much of the web is given over to entertainment and solving first world problems. Being able to affect the real world provides an opportunity to fix actual problems and enable better quality of life for many. Web developers and designers intrinsically understand the “hard place” between systems and humans – making them uniquely placed to have a tangible impact in the real world.
Abstraction creates magic
So far I’ve painted a picture of how desirable it is for web developers to be working with hardware so you would assume that I’m entirely for this idea. Here comes the grey side of my argument and the areas I believe we need to be wary of.
In working with developers coming across to hardware from software the single biggest knowledge gap is to do with the actual electronics. Many have never touched an electronic circuit of any kind (especially those that are younger).
Whilst electronics is a completely learnable skill, it is a barrier to entry that needs to be overcome before being able to design something non-trivial. Time after time I see posts from people saying, “I don’t understand why it won’t work” and 99% of the time it’s due to a fundamental knowledge failure of how a circuit or a component works. Nearly every one of my own problems falls into this category as well.
Electronics components often either work or not and are much less tolerant of failure than code – not least because you can destroy a component, not realise it and then spend days debugging before you understand you have killed it.
It is this facet of electronics that the embedded systems camp are coming from when they say “do it in C”. Not necessarily because the language is better but because you are working at “the metal” and as a result you will get a much more visceral understanding of the electronics. I totally appreciate this position and my fundamental electronics understanding comes from a combination of this as well as building analog circuits.
So now we get to technical.io and my concerns about this project and others like it.
Fundamentally I think there’s too much magic here and not in a good way.
Abstraction is useful when it removes the need to do tasks that are low value or highly repetitive (eg finding the location of a character in a string or providing the routing for a URL to a page in a web app).
For the record, what I’m about to say next is based purely on my observations of technical.io’s public code, poring over images of their boards and reading spec sheets for the chips they are using and reading all of their blog posts and commit logs. I have not talked to any of the team (though I’d love to – I expect they are insanely busy). IE: I’m making some educated guesses, doing some speculation and reading between the lines.
My bigger concern with this is that it would appear the libraries (and the plug in modules that provide additional functionality) ultimately wrap C libraries (which is pretty common in the node community anyway) however because this is a custom designed board with seemingly little access to lower levels, the ability of non-core developers to add functionality will be significantly reduced. Thus we land ourselves in the “app” world where the capability of our design is firmly based on the ability of the hardware developers to expose APIs for it (this will sound familiar to anyone that has dealt with Android or iOS?).
I also have some concerns that there’s some kludging going on with both the hardware and the software. This always happens to an extent, but when you’re dealing with inexperienced hardware developers who will be using this there may be some problems. Consider the “Servo” library which you would use to control servo motors. Servos look simple but they are relatively complex devices. Unlike a standard motor which can just go forward or backwards, servos use pulsed signals (PWM) to tell the servo where to position the servo head. For example a signal of pulses that go high for 1.5ms usually means align the head to the centre – longer and shorter pulses moves the head in ranges away from that centre point clockwise or anticlockwise.
The tessel board is using a chip designed to PWM LEDs (to make them brighter or dimmer or control RGB LEDs) in order to do servo control duty. This is a neat hack as it means you can control a range of different things with the one board but the biggest problem comes when a novice developer comes along, plugs in a high current servo, loads it up with something heavy and blows the board. Admittedly this can happen with an arduino (and I’ve done it) but it is a bit harder because you have to read more and you’ll come in contact with good materials on using servos – most likely before you blow it up.
Arduino is an excellent example of this approach from a C perspective. The reason for this is Massimo, David and the rest of the team are all educators – as such they fundamentally understand that you need to provide opportunities to experiment and grow your capability with every step and not lock someone into a dead end. With an arduino it is extremely easy to do simple things. You can copy and paste code from the examples and it will work. Due to the framework it’s easy to see that the LED is blinking because you’re turning pin 13 on and off every 1000 milliseconds – you don’t even need to be a programmer to understand that as a concept. This is why arduino has been successful with students who are not naturally inclined to try programming.
However once you get beyond this level of understanding it’s perfectly fine and possible (and encouraged) to start writing “real” C code that manipulates registers and memory. Thus the pathway from novice to embedded system programmer is entirely visible.
The “Internet of Things” needs web designers and developers
At the moment, hardware devices that are being connected to the Internet are mostly being built by embedded systems engineers. Whilst these devices may be technically excellent, they often lack an understanding of good web design practice – particularly from the point of view of good user interface design, API creation and consumption as well as openness and extensibility.
This may be perfectly acceptable for M2M type applications (at a stretch from my perspective) however for anything remotely consumer oriented, web designers and developers understand the human part of the Internet of Things. As designers and developers, getting a good grounding in electronics and hardware gives us an advantage when it comes to building these types of applications and there is a huge future in it due to the cheapness of computation and ubiquity of networks.
If you’re a web developer and you’re looking at playing with hardware, don’t shy away from the electronics. There are no magic bits of hardware that will give you full control of the physical world in a box – though there are plenty of attempts at this. Develop your knowledge the same way you do with the web – by reading, tinkering, playing with code and breaking stuff. Go join a hackerspace, get some learning materials, visit electronics shops, pull things apart and learn how they work.
Update: There were some concerns expressed that my original fictional intro was a bit FUDdy. On re-reading I tend to agree with that sentiment – it was an artefact of my original version of this post due to me explaining my concerns to another JS dev using a similar story. I’ve kept the core element but removed the death and destruction.