Uploading sketches over the Internet

Things are pretty busy here, but I wanted to take some time out to report on our progress, and update the previous blog post.

We uploaded a sketch over the internet, which I’m very pleased about. Vic controlled the server end at his place, and I had the Nanode. After flashing Vic’s latest bootloader onto a Wicked Device Nanode, everything was controlled entirely at the server end. The Nanode resolved DNS, found the sketch, and downloaded it. All I had to do was press reset.

We chose “Blink” from the Arduino examples, and then “Fade”. As far as I know, this is a world first.

Uploading sketches over Ethernet

As you may know, we have been working on a new bootloader which lets you upload sketches over Ethernet. Being able to upload a sketch from anywhere has a bunch of obvious advantages. Here is a video of an early version bootloader which goes and fetches a sketch from a TFTP server and burns it.

Ethernet Bootloader from Wicked Device on Vimeo.

It’s worth emphasizing this is an early alpha build. It currently only works over a local area network, not across the internet, and also requires you to press the reset button on the Nanode**. Still, it seems a good milestone. Next steps are to clean it up a bit, make it a little bit more robust.

** A Nanode is an ethernet enabled Arduino clone available here as a kit.

We’ll see you at MakerFaire NYC

We have a booth at MakerFaire NYC – Maker #6511.

See you there!

Africa’s Technology Futures scenario piece

My paper has been published by the Pardee Center at Boston University: Africa’s Technology Futures: Three Scenarios

“Technology has critical impacts on the future of nations and regions around the globe, and it can be especially important in developing countries by enabling increased efficiencies and rapid development.  This paper uses a scenario planning approach to explore two questions about Sub-Saharan Africa: 1) Can this region be effective at creating, owning, developing, and harnessing homegrown technology, and 2) can it successfully adapt non-African technologies into innovation cycles?  The situation today is discussed as a baseline, and the risks of assuming that Africa will take the same trajectory to technological sophistication as the West are noted. Three feasible technology futures are presented and discussed: “Use, don’t own”; “Pockets of innovation”; and “Leapfrogging.”

Ants carrying a Gecko up a wall

CERN OHW licence in plain English

In July CERN published a new open hardware license update to their March 2011 initial release. Let’s take a look. It is quite short, only  2 pages. In plain English:

• You get to use the product, but you can’t claim any ownership to trade marks, etc. Standard stuff.
• Code / software is specifically excluded. It’s just the hardware.
• It includes limitations of liability and disclaimers, which is nice.
• You have to ship with documentation if it is provided by the creator, but you can modify the documentation as much as you like. Except you can’t modify/remove any disclaimers. Also, you automatically get a right to copy documentation.
•  If you modify the documentation, you have to send updates to everyone who contributed to the documentation. (3.3d)
• It doesn’t actually say you can make derivative works, but this is implied as you are given license to relevant patents and registered designs.
•  They threw in a paragraph for their own benefit: If you are a government, you have to use arbitration to settle disputes.

So does this comply with an open hardware license? I think the answer has to be “kinda”. For example, the OHW license principles stipulate that any OHW license should either include software under an open license, or include interfaces to it so you can use it. This is not part of the CERN license, which I feel on balance is probably a good thing.

Some differences? It’s shorter and easier to understand than the TAPR OHW license, and seemingly less restrictive. The TAPR license has more details – it speaks to how you should go about executing the license as well as just the high level principles. For example, including a file that says license.txt. It also says you need to distribute documentation unmodified, or release any new hardware under the OHL (and then modify the documentation). The TAPR document also has a long (2 page) preamble, and I don’t know if this is legally part of the license or not, which makes it confusing for me.

Note: I’m not a lawyer. If you’re using this for anything legal, you’re nuts.

Solving problem solving

Swarmanoids are a set of little robot groups that have “foot”, “hand” and “eye” robots, all functioning together as a distributed system. It looks very cool and fun, with lots of colored lights. But their cooperative abilities are not what impresses me most. What I really like is that the designers have gone some way to making it easier to solve the robot problem set. I like how they have modularized the robots by function. This allows development of each part to continue somewhat independently of the other parts. And that means that you can iterate faster, have less dependencies and keep groups of experts together in small teams. I wonder if that was a deliberate goal.

Solving problem solving indeed.

Similar looking stuff

For those of you following the Apple – Samsung court case (summary: Apple says Samsung’s stuff looks too similar), below is a picture of the latest Sukhoi fighter (left). Hmmm …

As BoingBoing noted, they look awfully similar.

Nanode + WickedNode + DHCP + DNS + Pachube!

The other day I got my Nanode talking to Pachube! That in and of itself is pretty cool, and it was also pretty easy given that there are a fair number of examples out on the web and a well documented API for interacting with Pachube. I extended some of these examples to use our Wicked Node and post received data to a Pachube sensor feed. I think my biggest contribution here perhaps was a bit of refactoring of the code so that the major chunks are re-usable in future sketches. Maybe some of it can maybe even make it’s way into the EtherShield library. I’ll provide my sketch attached to this post for anyone who wants to check out the details. I also want to share some general knowledge about debugging networks and software that interacts with networks, which I’ll dedicate my next post to.

So part one – the general program flow goes like this:

setup()
   1. Set Serial to 2400 baud (for radio interface)
   2. Initialize the Ethernet interface with a MAC address
   3. Get an IP address using DHCP (optional)
   4. Initialize the IP/UDP/TCP stack with a MAC address, IP address, and WWW port
   5. Set the Gateway and DNS IP addresses
   6. Wait for the Gateway to recognize the Nanode
   7. Resolve "api.pachube.com" to an IP address using DNS
   8. Initialize the Web Client part of the EtherShield library
loop()
   1. Wait for wireless sensor data to be recieved
   2. When data is received populate a template string and post it to Pachube

Pretty simple, right!? Well there is an example with the EtherShield library for demonstrating DNS and a separate example for demonstrating DHCP, and another example that demonstrates Pachube (getting information *from* Pachube actually), but besides the DHCP example, nothing really tied in DHCP; the other examples just use static IP addresses and call it day. So I refactored the code in the DHCP example so as to make the acquisition of an IP address over DHCP into a function call that I could just call from setup(). I insightfully named this function acquireIPAddress, and I’m pretty sure it will be useful in many a sketch in the future (for me and others I hope). Similarly in looking at the DNS example, it was kind of hard to see how you ended up with a resolved address, so I made another function that I think is a little more intuitive from an API standpoint that takes a null-terminated string as the address to resolves and a buffer into which it puts the resolved IP address. I decided not to get too creative and named this function resolveHost.

I think factoring out these two functions really makes reading the setup and loop functions a whole lot more digestible to the average human. As a last step I tidied up my code and moved things around so that all the configuration for the sketch is up top, including whether you want to use static of dynamic IP parameters, your Pachube API key and how you format and populate your Pachube post template. If you want to use the sketch as a basis for your own application, you’ll have to download the EtherShield library and WickedReceiver library and drop them in your Arduino libraries folder to get it all to compile.

Have fun getting your Nanode onto the internet and let us know what cool things you’re doing it!

Download the Sketch Here: Pachube_WickedNode

Check out this other blog post for a variation on the sketch that doesn’t use the Wicked Node, but instead posts ADC inputs directly from the Nanode.

Update: 12/14/2012 – The EtherShield library was retired earlier this year in favor of the EtherCard library. At some point I may get around to making another update to this post, but the EtherCard library already comes with a pretty easy to follow Cosm (the new name for Pachube) sketch. As always, feel free to post to our forum if you have questions.

New Product: The Nanode

The Nanode is a cool Ethernet enabled Arduino clone all in one kit for sale at $39.95, including shipping, which is a pretty good deal. It Also includes a year’s subscription to Pachube Pro, a $25 value. So all it all it is great value for money.

We have been working with Ken Boak, the inventor of the Nanode, who is based in London and worked with the London Hackerspace to create the Nanode. It has made a big impact there, and is used in projects like the Open Energy Monitor, which I’ll be blogging about in the future.

If you want to find out more about the Nanode, this website has a step by step build, application info, IRC chat and more. We’re really looking forward to doing some fun stuff with it.