In this conversation, we talk about our plans for the first chapter, on prototyping. This was quite a long conversation, so we've split it up into 3 parts
Adrian: Let's think about prototyping... for 20 pages
Hakim: So we split up our original "Prototyping" chapter into 2 chapters: the "thinking about prototyping" one and "protyping for specific devices". So... what are we thinking about with "thinking about prototyping"?
Adrian: (laughs) I can't remember, why did we split it? Probably because...
Hakim: ... because our publisher suggested we did... The way I was thinking about it, the second part was quite detailed information about platforms that we know exist now. And the first part is almost future-proofing the book or the ideas, because if you know nothing about What is Arduino? or What is a Raspberry Pi? How would you you go about choosing a platform?
Adrian: Yes, I think you're right. One of the things this first chapter can do is all the overview stuff before you get into the details of exactly what you need to do. So you might read it and decide that, OK, I can discount the Arduino, but I need to look at the SheevaPlug or whatever. You could almost read this chapter to see what the issues are, and then come back at a later date to read the next chapter. When you have funding for your Grand Idea, you can come back to it.
And in the meantime you've got enough information to not look stupid when people ask you details about your platform. You can say "Well, I've thought about how much RAM I need", or whatever.
Hakim: Hmmm, well. If you think about the kind of chapter you can skip... it's usually known as "an appendix" isn't it?
Adrian: True.
Hakim: But then, for the market for the book, and what the publishers are looking for, then the "specific platforms" chapter is actually quite a core chapter too. Which is why we've got 40 pages on it. It is almost the "infodump" part of the book. Well, there's a risk of it being an actual infodump, but hopefully we can do more with it, make it more engaging and fun than that.
Adrian: Well, that will be all the great examples and case studies of the different platforms that you're going to be writing up...
Hakim: Yes, it will be fun too. But it'll also be optional, in that you could drill down into say, just the Arduino chapter?
Adrian: Yeah, I guess one of the markets is product designers or similar. People who'll be interested in knowing about this stuff, but not needing to already know which particular device they're going to be using. People who are looking for the overview-of-the-overview, almost.
Hakim: what we've got here in our Table of Contents is "Introduction to the available microcontrollers and embedded boards", so is it a bit of a whistlestop tour?
Adrian: Well, some of it will be what is a microcontroller or an embedded board? You need this initial information about hardware in general, to explain what this all is. So it's not just a lot of words that a product designer or whoever won't necessarily know. Even if you've maybe heard of Arduino you don't necessarily know that it's a "microcontroller platform" or "embedded computing".
Hakim: So it is fitting our manifesto of "IoT for humans" isn't it? If you give the book to a 21st century human with.. well, certain assumptions about education and computer literacy... we still have lots of assumptions, but someone like that, even not a specialist in IoT or computing should be able to read the book and get something out of it. A manager, a lecturer, a parent, an interested hobbyist...
So we've got "Choosing the platform". We're talking about parameters like RAM, and capabilities?
Adrian: Processing power. What inputs and outputs are available. Sensors maybe.
Electronics... which seems to be more in the 2nd chapter. But in the Choosing your Platform section, maybe something about digital versus analogue. For example the Raspberry Pi has several GPIO (General Purpose Input/Output) pins, but they'll be digital. Because if you were going to do analogue stuff, you'd need Analogue/Digital converters. And if you needed proper Analogue Outputs, as opposed to the PWM stuff that the Arduino does, then you'd need a DAC (Digital Analogue Converter... just the opposite way around). So that's about the capability of the boards, and not all boards are the same.
So, for example your phone generally won't have any GPIO pins. You'd end up interfacing to it through bluetooth etc. So a lot of this is about interfaces. Do we cover things like I2C or SPI?
Hakim: I don't know what those are...
Adrian: They're electronics protocols or interfaces for electronics boards to communicate at quite a low, electronics level. So similar to a PCI bus, but at an electronic level, rather than a code level.
Hakim: Well, if you think of something like the Gadgeteer from Microsoft. That had quite a high-level protocol for the electronic components and connectors.
Adrian: Yeah, some of this is about giving an idea of the possibilities that platforms might have. So you can think about what your big idea is, and what it needs to do... is it an input device or an output device... what does it need to do?
So Bubblino has a motor, so he needs to be able to drive some electronics. What computing stuff does he need to talk to the internet and control a motor and interface them? Does he need to be wireless or wired?
So yeah, the question of what networking capabilities you need: do you need to be a phone, which can work anywhere, but will need contracts with a provider. And that's very different to being WiFi, or ZigBee, or Ethernet... So there are those sorts of capabilities.
And if you're using sensors then how do you connect the sensors to it? What possibilities does it have for that. What processing power does the chip have? How much RAM does it have, if you're going to have to do buffering. It's hard to tell "is it going to be fast enough?" but some boards are faster than other. An ARM, especially a high-powered ARM is going to be faster than an Arduino, and a lot more capable. But also more expensive. So those are the things that you need to know, and how they affect what you're going to build. Some of them will just affect the cost.
Hakim: And also the size, which is a big issue. Will if fit? So if you think about one of the IoT connected devices we've got here at DoES is our Doorbot. Which is a screen, and it's a computer... so at the heart of it, it's a computer with a screen. And the only reason it's a "Thing" is that it's in one place, and it's doing a very specific job.
Adrian: And it has sensor inputs too. Like the RFID reader, which is plugged into it by USB. Having it based on a computer would make it more expensive if you were going to try to sell... thousands of them. But for 1... it's a computer, it's commodity hardware, and you've got it just lying around, so it's effectively free.
And it can do the outputs on the screen and its speakers.
Hakim: So that's our biggest Thing, I guess, so far. Though there was that Internet powered bus...
Adrian: That's not actually that big, I think.
Hakim: Oh, it's a toy bus? (laughs)
Adrian: Yeah, that was the idea I think. It's a toy bus that sits, telling you when the next real bus is going to be...
Hakim: Ah, I thought they'd actually got hold of a real bus and converted it...
Adrian: Well, we could go to the Wirral transport museum and offer to upgrade one of their old buses with a screen on a rolling canvas display... because they're all old buses. It'd take forever to display all the info!
Hakim: I did wonder if we could use hamsters to power some sort of motor device. But that's possibly getting more into biohacking?
Adrian: You can definitely get some sort of microbial fuel cells. There was an art project I saw where there was some flypaper that turned around, and powered itself by digesting the flies that it caught. So when it had caught enough flies it would move, and scrape off some of the flies that dropped into a fuel cell that then gave it just enough power to move a bit more.
Hakim: That's brilliant.
Adrian: And I guess power is another factor for thinking about prototyping. If you can drop something into a really low power mode it has an impact on the cost. Especially if you think about networking protocols and wireless networking. Is power an issue, and how are you going to power it. These factors do come into play when choosing the platform.
Hakim: Our next subheading is about costs versus the ease of prototyping. We've already touched on costs... but why is that a trade-off against ease of prototyping?
Adrian: On one level, if you want the cheapest possible way of prototyping stuff, you can by the AVR chips from Farnell (DoESLiverpool affiliate link), and work out how to flash them yourself. And that's harder than programming an Arduino... but you havent' had to buy the serial ports and so on. So that's a couple of quid for an AVR chip. Versus £20 for an Arduino. Versus £90 for a BeagleBone which runs linux and has node.js on it, and you write Javascript in order to access whether the pins are on or off.
So there are different levels... and some of it depends on what your skillset is. You could argue, reasonably, that if you're not a coder, then actually an Arduino is easier to program than a BeagleBone. Because an Arduino is really limited and so it has a setup() function and a loop() function that run, and that's all there is. There's nothing else to worry about, just those two little bits, and you need to fill some stuff in, and it does things. And as long as that's enough for you to achieve what you want, then that's probably the easiest prototyping that you can get.
Compared to the BeagleBone, where you need to learn about Javascript, and how to use a whole Linux system. How do you make sure that your code runs when it boots up and so on... Those decisions are made for you on the Arduino, because it just runs setup(). Whereas... I imagine, though I don't know, because I haven't yet played with BeagleBone enough, that there are choices, just because it's booting Linux. So you might have to stick a script somewhere if you want your program to run as soon as it starts. And that's actually harder than the Arduino for those things. So if you're not a coder, perhaps the Arduino is easier for you than the BeagleBone. But if you're a coder, and you know Javascript, and you can't do C++, and you're used to having shedloads of memory, so that if you need a web-page, you can just download the whole thing and sift through it in place... then a BeagleBone will be much easier. Because the Arduino has more limitations, so you have to think about, and do things quite differently.
Hakim: It was funny, on the course at MadLab, there were some things that people were doing that were quite easy. And then there was one guy that was doing some parsing ,and I was thinking that would be quite difficult using C, and not having done memory allocations and so on...
Adrian: It depends. It's either really easy, or it's really hard. And if you can do it in one pass, and just search for things you're interested in, then it's really easy. And sure, it would've been easier for him if he could have just read it in and searched it in some high level scripting langauge. Or even in C++ but with enough memory to do dynamic allocations and searching through a string. Rather than having to do a single-pass search where you can't go back on yourself.
But really, doing things in a single pass isn't as hard as it sounds. But you end up writing fairly dumb parsers that can't cope with things appearing in a different order. And they don't notice whether they've been fed syntactically correct XML for example.
So Bubblino downloads an Atom feed, which is XML. But all he does is throw
everything away till he gets to "published>" and then reads
everything till the next opening "<". Then he has a date, and
he can compare it to the other posts he's seen, and if it's newer, then he adds
one to a counter. And then he just carries on and does it again. So he could
have been fed any crap in between and he doesn't care if it was well formed XML
at all. Which is... I'm not sure if it really matters actaully.
But if you were doing it in Ruby, you'd pull it into some XML parser and it'd complain if there was a space out of place.
So, ease of prototyping. Often, if you spend more money, you can get something that's nearer to a computer. You could imagine an if this then that app for your phone that you could tell "if the microphone goes above this level, then send a text message..." in a drag-and-drop interface. And you're more likely to get stuff like that on higher end, more powerful devices. But they often cost more.
Hakim: well I guess that's on the other end of the scale for many tasks, if you have an iPhone or an Android, or a high end Nokia... or a computer, say, you could prototype something and almost pretend that it was a physical device. In the case of phones they already have lots of sensors and so on. And even a computer has a microphone, a webcam... it has lots of sensors available to it. Perhaps not the same ones as an Arduino. It might not have a motor output, though you could have a USB controlled motor.
Adrian: Well, you could always plug it into an Arduino, which is the other way to do it! But one option is to do all the hard processing on the computer or phone. So for example, the Android Dev Kit is a good example of that, in that you've got an Android phone and then basically you plug it into an Arduino that's got the USB host shield... so the Arduino essentially pretends to be the computer end of the connection, because the Android generally has the "device end" connector, and there's a protocol that you can talk over USB that you can talk from the phone. So the phone does all the complicated stuff, and it talks to the Arduino to ask it for sensor readings or whatever. Then the phone uploads things to the web, or sends texts, or whatever.
I guess the first version, or the plan for the first Bubblino was that, to some extent. It was a bluetooth Arduino initially, which talked bluetooth, originally to my phone, because I was trying to write Python for S60. And I was thinking Python would be easy, because it's just a little scripting language. So it was going to search twitter for the number of tweets, and just send a number to the Arduino, which was the number of tweets to blow bubbles for. But I couldn't get Python for S60 working properly. That was one of the times I struggled and failed with Python. Though these days I'm getting paid to write it professionally, so I can't be that bad at it...
And you'll be happy to hear that I fell back on Perl. So the first iteration was a Perl script that ran on my laptop, opened a COM port that was the bluetooth connection, and then sent the number of tweets over it. Then the Arduino just looked for numbers on the serial connection... nothing... nothing... oh, a number! What's the number? OK, we'll blow bubbles for that many seconds.
But it did mean that it only worked when my laptop was in the same room as Bubblino, which wasn't ideal, but worked.
And I guess that leads into the ease of scaling up. You have this cost versus ease of prototyping trade-off, where often you can use more powerful computing devices. Whether it's just a BeagleBone, which is a more powerful embedded board, or a mobile phone, or a computer that's doing stuff. And that makes it easier to get something up and running. But at the expense of making that one, single device more expensive. But then it depends... so the example of the Doorbot is quite good. Because it is Just A Computer. Which meant that the ease of prototyping on it was... well it runs Ubuntu, so you can do anything that you can do on Ubuntu. You can run Ruby scripts and play around with stuff like that. And it doesn't matter, because it's a one-off.
So there's no concern in scaling up, because you don't need any more, unless you get more doors... which we might do if we expand into the room next door... But even then, we'd only need two devices. Or a device with 2 screens, and a cable to the second room. But it's still not vital to think about turning it into a BeagleBone... or a Raspberry Pi would be quite a good choice with its HDMI output to talk to the screen quite easily. But then you'd have to work out how to program for a new device. And maybe it's still cheaper to just buy a PC than the time for one of us to figure out how to port it to Raspberry Pi.
And again there are tradeoffs where that porting might be a good learning exercise to play with the Raspberry Pi.
But of course if you were going to start selling thousands of them... at that point you might think, say the Arduino would have been harder to prototype on, but it would prove that the concept would work on a cheaper, more limited device. So the problem with developing on a more complex board, like a BeagleBone is that if it turns out that you've made assumptions and relied on memory allocation... then either you're doing a complete rewrite onto Arduino, or perhaps it's just not possible to do it, so you then find that you need a more powerful ARM platform, which turns out to be more expensive than the couple of quid that the Arduino processing power costs (if you do it in bulk).
So scaling up is a big issue. But even if you are, maybe doing it on a more powerful device makes sense, because you just want a single prototype to help you get investors to show them, and want to do it as quickly as possible. And you can always talk around that and how you're aware that you'll later port it to a cheaper platform for mass production. So it doesn't have to be an issue to do it properly later, when you've got the investment.
Read Part 2