Antipasto Hardware Blog

Android Hardware Development Environment

2011-11-17T17:46:00.000-08:00

My favorite part of the Android Hardware Development Environment is that I can easily connect to a serial port/ use the USB host capabilities with Android. When I'm done with my project I typically burn my custom image of Android to a microSD card so I can reuse my operating system!

Maker Faire 2011– Bay Area Recap

2011-06-08T09:37:00.001-07:00

Each year, I head out to Maker Faire, thinking I’ve seen it all, but I know that can’t be true. And year after year…well, I haven’t been disappointed yet! Besides enjoying some quality time in the gorgeous California sun, we managed to get our project demos up and running for the event.

Here’s the booth, with Will and Francis doing some final setup work on the projects.

Of course, it wouldn’t be Maker Faire without Gerard’s Paella, which also makes for a great excuse to meet and mingle with some fellow makers:

By Saturday, we had a chance to deck out the booth with the RC “street view” car, affectionately named Zippy :)

The car had a PS3 Eye camera strapped on to stream video out onto the BeagleBoard and BeagleTouch, which was something I only dreamed of doing as a kid. DIY tech has come a long way since!

Speaking of DIY (and open source) tech, it’s pretty neat to see that the Arduino hasn’t lost any steam. Google put together an Android Accessory Development Kit that they were giving out.

It comes with an Arduino Mega-based board with an onboard USB host and USB OTG port, and the Accessory Demo Shield (bottom). The Accessory Demo Shield is especially neat…it’s like the ultimate controller/debugger shield, all in one. Buttons, relays, servo connectors, joystick and even a touch sensor! It puts a whole new spin on the kinds of Android/Beagle/Arduino projects I want to do…

Microchip and Digilent came out with a PIC32 that Mark shared with me. Pretty cool, since I can now drive all sorts of Arduino shields with a PIC controller…

Back at the booth, Will, Francis and I met a lot of hackers who stopped by to play around with the projects.

Each of us had a few moments to sneak away from the booth (in shifts) to wander through the Faire and check out what everyone else was up to.

I think this was the best country stage ever…the front porch if an old Western house.

A little steampunk and futuristic in a video-game kinda way, there’s nothing that stops you in your tracks like a robot sculpture that shoots fire. All I could say was…wow!

And the most efficient four-wheeler ever- a new take on the tandem bike. I would love to have one of these, and maybe even mount an enclosure on this. I wonder what a cross-country road trip on this human powered car would be like. Probably fun and a great exercise :)

That’s all I pulled off the camera for now, and I’ll upload more pictures to Flickr when I get them. Thanks again to all the makers and hackers who stopped by, and I’ll be on the edge of my seat waiting for the next Maker Faire!

I’m off to Maker Faire (2011 Edition)!

2011-05-19T17:54:00.001-07:00

It’s that time of the year again! Some folks call in summer – I call it Maker Faire. So next week, I’m packing up a few of my favorite new projects, and hopefully show off something interesting at my table out in San Mateo.

One thing I’m really excited about is the stuff I’ve been hacking around with in Android. I always felt like Android was one of those hardcore engineering things, but I’ve been able to get it to work with the BeagleBoard and BeagleTouch to do some pretty fun stuff.

Last week, Will, and I were sitting in the lab playing around with the old RC car and some of Playstation cameras we had from a project last year. Will always thought it would be cool if we could control the car without having to follow it around, so we gave it a whirl. Loading up the car with a couple hacked PlayStation 3 cameras, Will was able to drive the car around the house without leaving the room.

By hooking up the PS3 camera to the car, Will and I were able to bring up the camera to the BeagleTouch and see exactly what the RC car was seeing. I’ve always wondered what it would be like to be driven around on a little RC car (think Honey I Shrunk The Kids :) and this is just about the closest I’ll get. Using the same hack, I hooked up four PS3 cameras to the around my desk to make a “BeagleBoard Security System”, complete with split-screens and everything. It made me feel like a security guard/command-center operator of sorts, and plus, no one could sneak up on me.

Not to say I’ve forgotten all about the Arduino - I’ve also been playing around with a low power, portable, WiFi/GPS/Arduino rig with the GeoShield, which I’m going to test out at Maker Faire Exhibition Hall when I get there.

I had some spare time on my hands the past couple weekends, and some cooler gear to play with, so there’s plenty more projects I’ll have to show off. I’ll be there the whole time, and would love to say hi to some fellow West Coast hackers…see you there!

Android Platform Distribution

2011-02-16T09:09:00.000-08:00

Thanks for all the emails and feedback over the last couple months on the Android Hardware Development kit, we're very excited to be using this advanced hardware platform. In fact, Matt has been busy hacking into nearly all our devices around the office that have exposed serial. Interestingly, Droid Does talk to quad CMOS sensor arrays to stream live video, but more on that later.

One of the common questions asked was: which version of Android does the Android Hardware Development Kit ship with?

The answer surprisingly turns out to be the in-line with the second most popular version on the market today, 2.1. This is great news because it shows a nexus of stable devices focused around Android 2.1 and 2.2 versions. This creates a stable base to upgrade from as the bleeding edge releases become more robust through aggressive software patch-work.

Current Distribution

The following pie chart and table is based on the number of Android devices that have accessed Android Market within a 14-day period ending on the data collection date noted below.

Platform	API Level	Distribution
Android 1.5	3	3.9%
Android 1.6	4	6.3%
Android 2.1	7	31.4%
Android 2.2	8	57.6%
Android 2.3	9	0.8%

Data collected during two weeks ending on February 2, 2011

From developer.android.com

Happy Antipasto New Year!

2010-12-31T23:59:00.000-08:00

Happy Open Source Hardware New Year!!!

Queue Lion King's theme song, the Circle of Life music... Elton John begins... rewind 15 years ago, I am a teenage boy living in Connecticut (not in the ritzy South-eastern part of CT, the farmlandish central/middle part). My parents both worked very late, so a family friend used to pick me up from school, and on the weekends, and teach and tutor me in mathematics in my spare time. Little did she know, many moons later, I would still find mathematics exciting, and constantly trying to apply it to my hardware hacking endeavors :-)

I'm home as I type this, and the irony is... my family friend sent a plate of antipasti for the holidays, and New Years. I couldn't help myself, I immediately placed the plate on top of my laptop, popped open the Liquidware website, and voila! Real antipasto meets Liquidware Antipasto Hardware Blog - the circle of life completes!

Delizioso!

The keen observer will notice the Java books on the right, and especially the Clojure book :-) I try to learn at least one new programming language during every holiday vacation - this time, it's clojure...

Introducing Antipasto Hardware Wiki

2010-12-31T16:57:00.000-08:00

Over the past two months, Chris, Will, Nick, and I have stealthily upgraded and migrated all of the Liquidware wiki content over to a new wiki... the Antipasto Hardware Wiki.

I decided it was finally time to upgrade the wiki to a higher end system, and using pbwiki seemed like a pretty decent choice. It'll still take some time to finish the migration, but until then, the benefits are quite nice - the new wiki has a lot more features than the original Liquidware Wiki (which technically was an upgrade from the formerly-original wiki, over at the www.liquidware.org site, which doesn't even exist any more).

Not a big deal, but thanks for all the help - and hopefully this will help address all those emails about folks wanting more help finding reference specs and documents for Liquidware hardware.

Cheers!

Writing Hello World on the Android with Eclipse

2010-12-29T14:38:00.000-08:00

I've gotten several dozen (!) emails in the past few days from DIY'ers, engineers, hackers, etc. asking for a very simple tutorial - a "hello world android" if you will. It then occurred to me that most of these emails are from people that just got an Android kit for Christmas (thanks to all the help from Matt and Will and Mike to get everything out the door in time).

So here goes. These instructions are summarized over at the wiki on this page.

Step 1: Install Eclipse
Download Eclipse Galileo-SR2 for Mac OS X-32bit or Windows-32bit or Linux-Ubuntu-32bit, and install it to the desktop or some location inside Documents.

Step 2: Install the Android SDK
This is the trickiest step... Download Android SDK Tools for Mac OS X-32bit or Windows-32bit or Linux-Ubuntu-32bit, and extract the archive into the /eclipse/plugins folder. Open Eclipse, select Help > Install New Software... Click Add, in the top-right corner.When the Add Repository dialog that appears, enter the following:

Name: ADT Plugin
Location: https://dl-ssl.google.com/android/eclipse/
Note: If you have trouble acquiring the plugin, try using "http" in the Location URL, instead of "https" (https is preferred for security reasons).

Click OK and then in the Available Software dialog, select the checkbox next to Developer Tools. Click Next. Then click through to the end until you're done, and then shut down and restart Eclipse.

Then, click the Eclipse -> Preferences Menu, click the Android category, and browse for SDK location: /eclipse/plugins/android-sdk-2.1_r1. Click OK to apply, and the Target, Vendor, Platform, and API columns should have values, then click OK again.

Step 3: Configure ADB
If you're running on Mac, you're already done. If you 're running on Windows, you have to do a couple extra steps. First, download the SDK from Liquidware - this one is specifically designed to work with the Android DIY Starter Kit and the Android Hardware Development Kit. To install the USB driver, just plug a mini-USB cable into the BeagleBoards USB OTG port, and manually install the driver from your_sdk_path/google-usb_driver into rowboat gadget.

Step 4: Create an Android App
Select File->New Project, and click Android->Android Project. You have options at this point - you can "Create a new project in workspace" and call it whatever you want. This will make a "hello world" template application. Or! You can select "Create project from existing source", and select SkeletonApp. I recommend you do this, and select SkeletonApp. If that doesn't work, then try to default app.

Now, plug in Android, select the main source file (in the left panel, under src -> com.example.android.skeletonapp -> SkeletonActivity.java) and press the Go button (the Green arrow on the top line of the menu bar), and you're ready to go.

Step 5: Customize
The most obvious thing to do is change the "Hello World" text. That's probably the safest way to go to start, just to make sure things are compiling properly. I've changed it to "Hello, inthebitz!" and voila - here it is, functionally working on the Android Embedded Hardware Development Kit:

Turns into this:

Bingo! Dino DNA!

Android vs. the Embedded Programmer Mindset

2010-12-27T09:26:00.000-08:00

Eclipse Apps Roasting on an Open Android
ADB nipping at your serial bus.
Yuletide GUIs being compiled through XML,
And freakin' complicated data reference schemes that make you call even a single string from an outside standalone strings.xml file by @string/hello or R.string.hello.

Everybody knows a compiler and some global vars,
Help to make coding simple and fast.
Local functions with their scopes all aglo(bal).
Will find it much easier than dereferencing every gosh-darn string text variable.

What the helloworld, Google! Whatever happened to:

char gButtonText[] = "Option On";

function mytoggle( void) {
strcpy(gButtonText,"Option Off")
}

Sure, it's ugly code. There's a better way to do it. But it's fast, easy, and simple, and intuitive to the C programmer's mindset. Welcome to the wonderful world of Java-inspired coding on Android. Everything is an object, and needs it's own varspace. Programming Android is like programming in Ruby on Rails' MVC stack. You aren't really writing a standalone app, you're just given the honor - and privilege if I say so - to glue on some function code on top of an existing framework. Programming Android is like programming Java - instead of thinking about building the app from the ground up, you're essentially writing a "diff" file on top of a massive mountain of existing code and functionality. The baseline app already does a bunch of stuff perfectly fine, thank you.

It's as if Android is constantly saying to me, "Oh, what, you want it to do something different? Overload my already perfectly-written function, why don't you. Pffft. I already thought of that. I have a better idea: why don't you *not* write your function, and instead use one of mine, and decrease the surplus population of crappy code!"

Bah humbugtracking
Programming in Android, like Java, I am constantly reminding of how little I know, because someone's already thought of that function, and it already exists - I just have to inherit and object and parent a class, @override a base class, and unprotect a final public method.

Want to make a toggle button change it's text? Duh:

android:textOff="Option Off"
android:textOn="Option On"

Herein lie the central difference in mindset between the Embedded Programmer and the Android Programmer:

Embedded (Arduino) Programming Mindset
In embedded land, we are trained to start from void main(void) and #include math.h and work upwards. From function control, application execution, to variable space definition, everything trains you to think about in a device-first mentality. You're thinking to yourself, "I have a device with XX megs of RAM, a YY MHz CPU, and a ZZ pixel screen." Optimization is the name of the game, efficiency matters, and resources are at a premium so it's worth taking the time to think them through.

Stretching the metaphor a bit for a minute, embedded coding is like heliocentrism - with the device at the center of the world:

Android Programming Mindset
In Android land, you are trained to start from a base, and extend some Activity class. You're writing diff code, pulling objects and their nested functions only when you need them. You are really writing *code*, you're just pulling and gluing together bits and pieces of functionality that were already written for you. The device doesn't matter, and why should it, because you're writing an app that might run on a tablet or a hand-held or an on-screen emulator. God only knows how many megs of RAM, CPU MHz, and pixels you'll have, so you'd better write your code abstractly and cross your fingers that it runs. Everything trains you to think about a user-first mentality.

All things considered, this isn't easy for an embedded programmer to embrace. Dare I say embracing and learning Android coding is the equivalent to the Copernican Revolution:

Device-first vs. User-first
Embedded programmers are more likely to build a new hardware device layer to push the performance envelope of a given piece of hardware. Android programmers are more likely to deliver a fantastic user experience that connects web-to-handheld-to-sensors first and foremost, and who cares if it sits and hangs for a few seconds while it calculates? The user will be stunned by the drop-shadowed jelly buttons, he won't even mind :-)

And the truth is... after several weeks of hacking my Android DIY Starter Kit, I don't mind either. I've found myself converting to a new religion, in the name of developing super-sleek looking GUI's in no time at all, it's really something. Doing the same in Linux would take weeks, maybe months (but that's another discussion for another time). Take my "void main( void)" from me, and give me my "public class extends Activity" any day of the week! But there are some downsides.

One major downside is the need for massively large reference manuals, or the need to constantly be connected to the web, for documentation, specs, and references. Try coding a rails webapp without access to the internet - impossible. On the other hand, all you need to code Arduino is a little cheatsheet - since you're essentially building everything up from scratch out of C primitive functions, all you need is the list of those functions. So what if you re-invent the wheel a few times? On Android, like Rails, you constantly need to know the top-down bigger picture. You need to have in your frame of mind the major high-level code objects, which you then reference down with the . dot-operator until you get to the method/function you were looking for. This means needing large amounts of documentation, and examples that are typically on the web.

Not better, not worse, mostly just different.

Have Yourself a Merry Little Android ADB Rootkit

2010-12-24T21:47:00.000-08:00

Quite a few people have emailed me about the post "The End of The Open Source Hardware Cambrian Age", and Chris had a few interesting observations and dialog about it on the Amp Hour - thanks (also a great set of casts in general)! Thank you... consider this the first installment of hackery to come :-)

It's one thing to have an Android. It's fun to download apps and whatnot, but at some point, you want to actually change the functionality of something, or make your own. That's the situation I found myself in recently, and so I've been hacking quite a bit on the Android DIY Starter Kit that I carry around.

The first thing anyone does when they get the Starter Kit or the Android Hardware Development Kit (more aimed at embedded programmers and engineers looking to learn Android) is... rootkit it, of course! I can honestly say that every device I have ever owned, I test on the basis of how quickly I can root it.

Now I just plug in the USB B mini cable into the side of the BeagleBoard. There's a USB B mini port on the BeagleTouch too, but don't plug into that one, since that's the serial debug port for the BeagleTouch.

Here's proof that it works, and it's powered on:

Now, it's as simple as popping up the "adb" debugger. Although I've mostly been a Windows/Linux guy up until now, I've been convinced recently to try out a lot of my development on Mac. One of the reasons, is illustrated here - all I have to do after I install the "adb toolkit". ABD is the Google set of command line utilities that allow you to communicate with an Android device at the low level - effectively "rooting it". Here's a link that describes what adb can do.

And that's it. This is a little windows showing the results of running:

./adb shell
ls

You can see the command line interface shows the root set of directories, including my personal favorite, "sdcard" which is a symlink to the sd card storage space on Liquidware Android port. Another fun thing to do is to plug in the Android DIY Starter Kit, plug in the usb cable to the Mac, reboot, and type:

./adb shell
logcat

"Logcat" is the debugging interface, which shows all of the details of the boot-up process, for those that are hacker inclined. It's 100% pure fun - and especially helpful given you can also do things like:

./adb logcat | grep usb

From the Mac command line shell, running this command let's you see any startup debug messages associated with usb. Powerful, if I do say so myself.

Try that on an iPod or iPad :-)

The End of The Open Source Hardware Cambrian Age

2010-12-21T01:22:00.000-08:00

This is the first time in almost 3 weeks I'm evenly lifting my head up to breath, after the massive chaos of Black Friday. Now, on to the fun stuff... my project back log, which I've been dying to blog about :-) But first, I spent some time browsing around the web at some recent OSHW projects, and I had a few thoughts I wanted to share...

Two years ago, Justin and I made a prediction… that the recent round of Open Source hardware was a re-invention of the same phenomenon that happened about 15-20 years ago, with the creation of DIY homebrew electronic computers. The recent round of open source hardware seemed to have been triggered by the advent of the ever-popular microcontroller, the Arduino.

Along with this trend came the replacement of the old guard, the Basic STAMP, with the new guard, the Arduino. For the past two and a half years, it’s been chaotic, emergent, collective, and exciting. The modularity introduced by the simple decision to fix the headers on the Arduino led to an explosion in the number of “shields” that fit those pins (including that ridiculous but essential, non-standard “gap” along the digital IO side which prevents someone from accidentally inserting a shield backwards). Arduino drove a reinvention of Open Source Hardware, from an artistic perspective, and allowed projects and hacking to occur faster than ever before...

Open Source Hardware >= Arduino!

But “open source hardware” is not synonymous with “Arduino” … it stands for much more than a "breakout board" for an Atmel chip. It represents the lowering of transaction costs, cheaper hacking, faster physical computing prototyping. It’s much more. But I've noticed an increasingly disturbing trend: companies are moving in for the kill. Noticing the success of the recent Open Source Hardware movement led by Arduino, the "old guard" is striking back - but they're striking back with the same out-dated tools that made them irrelevant on the web over the past few years... proprietary tool-chains, Windows-only custom IDE's, serial debugging interfaces (not USB), and special ROM flashing hardware.

Are you kidding me? This is a complete reversion back to the horrible life we all knew hardware to be 5 years ago, before Arduino came along. I will argue a strong point: Embedded Companies Just Don't Get It(TM). ECJDGI(TM)? They don't understand the web, they don't understand what Arduino is, why it succeeded, where it is headed. They just look at Arduino, and say, "I wish that was my silicon chip on there, and not Atmel's" and *POOF* they cram out yet another crappy dev board that no one is ever going to build anything with. Shame on them. The world doesn't need more Arduino clones. I think it needs more kick-ass projects.

So I would argue that two and half years ago, we saw the Cambrian Explosion of Open Source Hardware. New shields came out regularly, expanding the Arduino platform and the system. They were sloppy, inefficient, unoptimized, and *that was the point*. That inefficiency was good - it promoted hacking, and tinkering. It forced you to NOT follow directions. And yet the entire time, the Arduino remained a bedrock platform, and projects spawned and reproduced, remixed, recombined. All was open, collaborative, and expressive.

But to what end?

The Cambrian Explosion of biological diversity came to an end (eventually - thank goodness) as the Paleozoic Era marched onward. And when it did, life forms evolved - some of them were smaller, simpler, and potentially (arguably) less diverse and more optimized in their use of energy (metabolic optimization, anyone?). Others, meanwhile, grew larger and more complex, monstrous if you will.

Is the same thing happening to Open Source Hardware?

Have we left the era of massive experimentation and entered an era of consolidation? I think so… unfortunately. I say unfortunately, because every growth spurt must steady and end, and with that end comes reduced inventiveness, less innovation, and … optimization and efficiency. Shields continue to be made, and built, and as DIY'ers venture into the world of running businesses (like my friends Limor at Adafruit and Nate at Sparkfun), they are stumbling into the dreaded theories of economics that have haunted 1000's of hardware companies before them: cost optimization. You can see this right now in the Arduino world ... instead of DIY'ers building crazy new shields that do new things, the "old guard" and "cost cutters" are moving in to mass produce the shields they think are the most profitable.

Don't get me wrong, cheaper and cheaper shields available to more people - that's FANTASTIC news! It means that the Open Source Hardware market is maturing - early innovation is being replaced with volume, efficiency, mainstream acceptance. We WON!!!

Out with the New, In with the Old

The Old Guard of embedded companies is back, and they're here to stay, displacing the temporary uber-innovative dystopian imbalance created for a brief period of time by the rowdy bands of individual DIY'ers. Open Source Hardware has reached it's full modern cycle, albeit faster than it did last time. Embedded companies, Chinese board houses, off-shore CAD designers, the industry is now in full bloom. Three years ago, I posted my first Arduino blog article - "Arduino, here I come!". I can barely believe it. The world has changed dramatically since that first article. Once a lonely, rogue band of hackers who once met in art space in the meat-packing district in NYC, the Open Source Hardware community now has a Summit, a massive annual Fair, and hundreds of suppliers and vendors!

But not everyone likes the "marketization" and "re-industrialization" of Open Source Hardware. Although costs of shields are plummeting, and a good dev board can be had for $5-10 dollars (!), not everyone is motivated just by low cost boards. Sure, many people are, but that's not the point. Just because you can get a 99 cent whopper doesn't mean you suddenly hate the taste of a char-broiled $10.50 Angus Beef burger.

Some people are motivated by kick-ass hacks, not mainstream projects.

Some people are motivated by ridiculousness, not rationality.

Some people like aesthetic design and balance, not just raw functionality.

Some people are driven by the thrill of the challenge, not just the systematization of the status quo.

Some people HATE rules and order.

Like me.

Bring on the Char Broiled Angus Beef Burgers!

Maybe I'm just hungry, but I’m going down with a fight. I don’t accept the end of Open Source Hardware innovation as the 99 cent whopper dev board. If the whole vision of OSHW just turns out to have created another excuse for a bunch of lowsy Windows-only dev boards with proprietary toolchains, horrible tech support hotlines, and mysterious libraries that have no documentation, I will be very sad.

I insist on fighting back, and making something new and different, and weird, strange, and unpredictable. That’s what makes Open Source Hardware fun and challenging to me. In fact, I think the fight itself is what it's about: constant reinvention, and pushing boundaries.

Now that that's out in the open, it's time to get back to doing what I enjoy most... hacking.

And that's what I'm all about.

Android^D^D^D^D^D^D^DCyber Monday

2010-11-29T11:01:00.000-08:00

I've heard a lot about this magical "Cyber Monday" effect, and never really believed it until today. I've sold almost as much Android hardware in the past 3 days - including today - than I have in the previous MONTH. And the day isn't even over... I can't figure out where all the traffic is coming from...

It's like the Slashdot Effect met the Digg and Reddit Effect, and got in a three-way love triangle. And then the bastard child grew up and wanted to program Android. I guess on the one hand, I'm happy that a lot of people like the kits I'm building, and on the other hand I'm thinking to myself,... I have a lot of work to do.

It's only 2 pm, and for the first time in a long time, I'm low on almost all of the inventory and products I stock at Liquidware... but especially on the Android hardware development kits. For those that don't know, this is a big deal because all of the kits are hand made, hand soldered, and hand packaged by Will, Chris, Matt and me. I usually like to keep enough kits built up so I can hack on a few of them myself, but today, I'm so low that I've had to cancel most of my plans for the next week so I can catch up (sorry Nick!)...

The next 10-14 days are going to be ridiculous, but I will do the best I can to ensure that I don't go out of stock on anything for too long. Here's my plan:

-I'm going to spend all day soldering and building
-I'm going to spend all night programming
-I'm going to spend all "meta-night" packaging

"Meta-night" is my name for that time of the night when you really ought to be asleep, but aren't, because the program isn't compiling for some reason, and you really want to get it done before the next day. Also known as 1 am - 5 am.

I guess all I can say is, thanks for supporting Liquidware, and for supporting Open Source, the Open Source Hardware movement, hardware hacking, Arduino, and Android.

Now it's my turn to work my ass off to make sure everything gets out in time!

Tron on Android Gadget Pack

2010-11-13T15:22:00.000-08:00

Reliving my childhood/young adulthood for just one minute, the only movie that even held a candle to Sneakers and Hackers was Tron. Fantasies of flying through the motherboard in search of missing ROM addresses and hexdumping around with light racing motorcycles is pretty much what gets me by some late nights while hacking. It sure romanticized the reality of actual programming experience, which typically consisted of gcc-make-vi-pico-repeat-success-segfault.

So when I found out that the new Tron movie was coming out, and that it had motorcycles, and modern interpretations of the flying-saucers-of-death meets-American-Gladiator game, I got excited. In fact, I think all the guys and I at Liquidware are going to take a full half day off just to see the movie together (ps if you're in the Boston/Cambridge area, and want to come along, just shoot me an email at inthebitz at gmail).

Anyway, I'm anxious. I think the movie is going to rock. And even if it doesn't, I'm going to see it anyway because of how influential it was to me, and many guys I know.

And in honor of that great movie, Will and Chris and I found an interpretation of Tron, called "Light Racer 3D", and got it running on the Liquidware Android Gadget Pack, running Android on the Beagleboard... enjoy!

Here's a video of it running on the Android-Beagleboard-BeagleTouch combination. It's surprisingly fast and snappy for a portable device like this - at first, I couldn't really believe that the 3D graphics were so fluid...

All of the modules and components are available at the liquidware shop, and some more pictures are up on the Flickr page. Enjoy!

Simultaneous Quad Charging Lithium Batteries

2010-11-12T10:11:00.000-08:00

In the past week, I've gotten a number of emails from people asking about the BeagleJuice module, and how you charge it. The BeagleJuice is a lithium ion rechargeable battery that snaps to the back of a Beagleboard, and let's you power it and any circuits or other modules like the BeagleTouch that you might have snapped on top of it for 4-6 hours depending on how much drain. If it's just the Beagleboard, it's about 6.5 hours.

Well, this is how *I* charge it - I typically charge 3-4 of them at once, running off of a USB "charging station", which is really just a 4-port USB hub that I've gutted, and wired up. The power is enough from this one USB hub to power 4 BeagleJuice's at a time.

Here's a video showing off my personal setup:

Arduino Uno launched and connected to the TouchShield Slide

2010-11-10T14:16:00.000-08:00

Hallelujah! Finally, an Arduino edition with a sufficiently Anglicized name that I can actually pronounce!

Introducing the Arduino Uno. Uno. Pronounced: "ooo-no"

Not "doooehmillahnoevuh" like the previous version of the Arduino. Just Arduino Uno. Arduino Uno. It's as if a million teachers, educators, students, hackers, and DIY'ers cried out out in unison, and were NOT silenced by the second syllable after tripping over their tongues!

Here's my first Arduino Uno, still sitting inside its box, with no idea what kind of heinous, mind-stretching, solder-busting torture it's about to go through in the coming months. If it only knew... it might stay inside it's little comfort box:

This is my first one, taken out of the box:

Here it is, sitting next to my trusty sidekick, the Illuminato Genesis. The Illuminato Genesis is still my go-to-board for high numbers of I/O requirements, and for a slightly faster speed:

Of course my first reaction was,... does it work with the TouchShield Slide? The answer was... yes, it most certainly does:

Justin just threw the Arduino Uno up over on the Liquidware Shop... and I uploaded some pictures over at the Flickr page. I'll be using the Arduino Uno in my upcoming projects, and will start seeing if there are any particular anomalies with my code samples, although I expect there not to be.

PS I like the new logo and color art too, nicely done, Team Arduino!

Skin Skeleton Guts (SSG) turns a TouchShield and Arduino into a Tricorder

2010-11-09T09:48:00.000-08:00

I met Dominic Muren at the OSHW Summit in NYC. To say he's a pretty smart guy is a dramatic understatement - he's ridiculously creative, plus he has a contagious energy! So I spent some time digging around, and a few emails later, I dug up his TED talk - which to me pretty much hits the nail on the head.

"Modular, Hackable, and Open components that could be reconfigured into a variety of components."

YES YES YES!!! (I think I just had a When Harry Met Sally moment for OSHW modularity...)

Dominic has this idea that skin-skeleton-guts can server as a powerful metaphor for connecting all of the pieces together of modular devices. I've been thinking about this for a while, but Dominic's ideas really push it further than I had thought. The "last mile" of modular gadgets so to speak is the enclosure, the case, and the "wrapping" around modular gadgets.

The problem is that while modularity is clearly the future of gadgetry, no one up until now has really found a satisfying solution to the problem of high-cost enclosure design. Enclosures are hard to build, and require long iterations of designs. Until 3D printing is really on everyone's desktop, the idea of fabricating an enclosure for Open Source Hardware and Electronics is an expensive idea. But moreso than that, even if 3D printing on the desktop were a reality, you'd likely want to minimize the amount of material you use in a custom enclosure.

To the idea of "Skin Skeleton Guts" or SSG by Dominic, is that we should build the skeletal components that hug the sides of modular electronics, and then build wrappers out of flexible fabric, e.g. "skin" to wrap around the skeleton. The modules - for instance, the Arduino modules in this case, serve as the "guts". The fragmented structural hugging pieces serve as the "skeleton", and the flexible, perhaps transparent, fabric material becomes the skin.

The result is... drum roll...

Pretty...

...darn...

...cool.

That's Dominic applying the principles of SSG to the MegaPalm Gadget Kit... stepwise heading in the direction of making it into a full blown device. That just made my entire week, seeing the concept of modularity and reconfigurable gadget components, getting pushed to the next level. It's one of those concepts that seems so straight-forward and natural, it makes me think, "why didn't I think of that?"

I'll have what he's having!

A Beginner's Tutorial to Programming Android on the Beagleboard

2010-11-07T22:21:00.000-08:00

Android is a fun development system platform - but you have to really enjoy googling around for relatively funky command line arguments if you're planning on making any progress in the course of one night. The google guys knew what they were doing, or at least did a great job building something pretty cool that works. Chris and I have been spending a decent amount of time learning how to program Android, and so I figured I'd write up a brief tutorial for anyone out there that doesn't want to spend nearly as much time as it took us to figure it out.

The first step in programming Android is to download the Android SDK: http://developer.android.com/sdk/index.html

On Ubuntu Linux, I downloaded the SDK into the home directory, and unzipped / untarred it. The next step is to get the Beagle Android Gadget Pack recognizing on the USB port. The next step involves plugging a USB cable into the side of the gadget. Once it's in, run the command:

lsusb

I get a bunch of Bus 001 through Bus 005, followed by Device blablabla information. Here's the trick. You want to find the ID of the Android device, so run lsusb while the device is unplugged, and then run it again. On my computer, the line that changes when the Android gadget is plugged in is:

Bus 001 Device 004: ID 18d1:9018

Ok. Now create a file called "51-android.rules". See the part in the line above that says, "18d1"? and "Device 004"? That's idVendor and idProduct respectively. So change those values in the file content below:

SUBSYSTEMS=="usb"
ATTRS{idVendor}=="18d1",
ATTRS{idProduct}=="0004",
MODE="0666"

Then copy the file here:

/etc/udev/rules.d/51-android.rules

This is a rather convoluted and manual way to get the Ubuntu Linux OS recognizing the Android Gadget as a native Android device. Now, you can cd into the SDK directory, and type:

./adb devices

And the device should show up. This is what I get:

List of devices attached:
20100720 device

Now I can use this command to get access to the Android Shell:

./adb shell

You'll get kicked out directly to the Android root command line, where you'll notice you can use ls, cd, cp, mv, rm, and cat. And that's about it. No text editor, no vi, no nothing. Pretty limited. Likely, you'll want to copy files on and off of the Android gadget, so you'll typically use these commands that come along with the Android SDK:

./adb push your_file to_location_on_android
./adb pull path_to_file_on_android
./adb --help

And most importantly... if you have an APK downloaded or compiled for Android, and you want to install it, just use:

./adb install blabla.apk

Voila!

Using the GeoShield to build an Open Source Hardware GPS

2010-10-26T03:27:00.000-07:00

I've been trying to get a GPS sensor working with my Arduino for a long time. And without fail, they just don't work. Don't get me wrong - the ones that other people have made work, but they're spotty, and you have to be in the right corner, the right place at the right time. And if a leaf flitters off a tree at just the right time, the dew moisture creates enough interference that the signal's lost. And just when the signal comes back, it fails again just as quickly and then I barely get enough data points to recreate anything interesting.

Not any more >:-)

There may be cheaper GPS shields out there, but that's not the point. The point of the GeoShield is that it works, and it's competitive with commercial off-the-shelf GPS's. Out of the box. No coding, no digging around, it just works. And if you combine it and a TouchShield Slide, you have a completely portable DIY GPS... that is as powerful as most of the mainstream GPS's out there you can buy off the shelf.
This is the only GPS shield I've been able to test reliably in cities, from cars, and inside cases. So the steps to create an Arduino GPS with the GeoShield are pretty straight forward. You'll need:

The Lithium BackPack goes in back of the DoubleWide ExtenderShield next to the Arduino, and the TouchShield Slide and the GeoShield go on top. Like this:

Here's a side angle:

And here's a funky perspective shot:

As you can see from the pictures, the GeoShield has a GPS sensor smack dab in the middle of the shield, with retro wireless solder pads emanating from it, as if to replicate a 1940's moving picture radio tower. On top of the GeoShield are a line of 4 user-controllable I/O pins (for debugging, of course), and then a GPS Rx and Tx pin, and finally a power white LED that tells you when it's powered up and has a signal. It's specifically designed this way because of all my hours of frustration with other GPS shields, wondering, "Does this thing ever work? Is it even powered on?" So this shield is designed to eliminate variables quickly, and get you up and running as quickly as possible. Oh yeah, and it also has a built in 3-axis accelerometer and compass, so it deserves it's name, "GeoShield".

Here's a link to the Open Source App Store app code that shows off a simple Night Rider program, plus polling of the GPS, Compass and 3-axis Accelerometer. The heart of the code is built into the Antipasto Arduino IDE function set:


void loop() {

   gps_msg = geo.readGPS();
   
   /* Print the GPS data */
   Serial.print(gps_msg);
   
   /* Parse GPS data and send to the PC */
   //for (int i=0; i< strlen(gps_msg); i++) {
   //  handleGPS(gps_msg[i]);
   //}

   /* Print the Compass heading, Accel X, Accel Y, Accel Z data */
   sprintf(out, "$GEO,H%d,X%d,Y%d,Z%d\n", comp, x, y, z);   
comp = geo.readCompass();
x = geo.readAccelX();
y = geo.readAccelY();
z = geo.readAccelZ();

//   delay(100);
   Serial.print(out);
   
   Sensor.print("co", comp);
   Sensor.print("xa", x);
   Sensor.print("ya", y);
   Sensor.print("za", z);
}

Here's a video showing it off:

The coolest part is that if you load up the pass-through sketch onto the Arduino, you can uncomment the coupe of lines that say, "print out to the PC", and then you can plug it in, load up a program like GPSFox, and get this:

Voila! Proof that it works - even from inside a friend's apartment!

Justin just uploaded the GeoShield over onto the Liquidware Shop, here...

Up and running on the Android DIY Development Kit in 180 seconds

2010-10-24T21:50:00.000-07:00

Android is a high performance open source hardware and software development system platform - but you have to really enjoy googling around for relatively funky command line arguments to get a device up and running for the first time. This post is meant to save anyone who's picking up Android for the first time some serious time... I really wanted to name this "in 60 seconds or less" but I timed myself, and I'm being realistic - it takes about 3 minutes.

The google guys knew what they were doing, or at least did a great job building something pretty cool that works. Chris and I have been spending a decent amount of time learning how to program Android, and so I figured I'd write up a brief tutorial for anyone out there that doesn't want to spend nearly as much time as it took us to figure it out.

The first step in programming Android is to download the Android SDK

On Ubuntu Linux, I downloaded the SDK into the home directory, and unzipped / untarred it. The next step is to get the Android DIY Starter Kit or the Hardware Development Kit recognizing on the USB port. The next step involves plugging a USB cable into the side of the gadget. Once it's in, run the command:

lsusb

I get a bunch of Bus 001 through Bus 005, followed by Device blablabla information. Here's the trick: you want to find the ID of the Android device, so run lsusb while the device is unplugged, and then run it again. On my computer, the line that changes when the Android gadget is plugged in is:

Bus 001 Device 004: ID 18d1:9018

Ok. Now create a file called "51-android.rules". See the part in the line above that says, "18d1"? and "Device 004"? That's idVendor and idProduct respectively. So change those values in the file content below:

SUBSYSTEMS=="usb"
ATTRS{idVendor}=="18d1",
ATTRS{idProduct}=="0004",
MODE="0666"

Then copy the file here:

/etc/udev/rules.d/51-android.rules

This is a rather convoluted and manual way to get the Ubuntu Linux OS recognizing the Android Gadget as a native Android device. Now, you can cd into the SDK directory, and type:

./adb devices

And the device should show up. This is what I get:

List of devices attached
20100720 device

Now I can use this command to get access to the Android Shell:

./adb shell

To copy files on and off of the Android gadget, use these commands:

./adb push
./adb pull
./adb --help

And most importantly... if you have an APK downloaded or compiled for Android, and you want to install it, just use:

./adb install blabla.apk

Voila!

Introducing the DIY Android Gadget Starter Kit

2010-10-19T09:28:00.000-07:00

This past weekend, Chris and I hacked Android onto the Beagleboard Embedded Gadget Pack. It was the culmination of about 3 weeks worth of working straight through, sleeping very little, and consuming many ASCII bunsen burner Red Bull's :-) The result is the DIY Android Gadget Starter Kit, which includes everything anyone would want or need to get started programming Android hardware and software applications, and to make a custom Android device.

Here's a picture of the Android DIY kit assembled:

The DIY Android Modular Gadget development kit uses the same base modules as the Open SciCal, which got written up on Wired (thanks!), and also as the Embedded Beagleboard Gadget Pack, which has been really popular with embedded systems engineers:

This is a nice perspective shot of the Android home menu, where the apps are typically stored and can be launched. The settings menu and options are fully functional, and the system comes preloaded with SL4A, a high performance scripting language that lets programmers write GUI's in Perl or Python (and a handful of other scripting languages):

Justin uploaded all of the modules, components, and preprogrammed SD cards onto the Liquidware shop over here... and here.

Breaking Hardware Barriers: Linux vs. Android Gadgets

2010-10-18T08:38:00.000-07:00

Here's a quick video showing off the DIY Android Modular Gadget I made with Chris:

Motivation
As it turns out, getting Android up and running on the Beagleboard is not too hard. Others have done it before. The hard part is doing it on a little modular gadget, that you can touch and type on the screen with natively, like any other Android gadget.

Ever since Google started controlling how many Android development kits are released, developers have had very few options for programming on Android. My goal was to make an Android Development Kit that significantly reduced the amount of time it normally takes to integrate custom hardware into the Android development.

Breaking barriers
Rapid prototyping with open source hardware isn't easy. It's certainly easier today than it was 5 or 10 years ago, and I like to think based on the emails and messages and calls I've gotten from friends and fellow developers, that projects like the Open SciCal and the Linux-based Beagleboard Embedded Starter Kit help.

In the last couple months, I've been hacking away on the Linux modular gadget platform, and for most applications, it's amazingly fast and sharp. The only time it's lacking a bit is when it comes to developing a quick and dirty GUI.

Linux vs. Android
Embedded systems development can take two very different forms. On the one hand, it can rely heavily on low level programming languages, and a native Linux cross-language, multi-compiler, shell-integrated environment. This is useful for building applications like scientific calculators, data loggers, industrial design and automation controllers. Basically, it's good for devices that don't need glitzy GUI's, but rather, need to do heavy duty analytical work.

On the other hand, sometimes embedded systems development is lighter on the analysis, and relies more heavily on sensor polling and on presenting real-time data readouts from sensors to a user. It might be a remote control, home automation gadget, LAN network diagnostic utility, etc. That's when Android shines, because it makes developing a clean GUI a piece of cake. I've been quite impressed as I've learned more and more about Android, over the past few weeks. As I've hacked away at the underlying codebase, I've learned quite a bit about how the developers of Android approached things, and I've been impressed.

The Best Tool for the Job
But that doesn't mean I'm leaving Linux behind... I now have 2 supertools: Linux for industrial and analytical work, and Android for more user-friendly, sensor-heavy apps.

I posted some more pictures up on the flickr page...

Android Hacked onto the BeagleBoard OSHW GadgetPack ... with avengance

2010-10-18T00:37:00.000-07:00

The time is 3:27 am on the East Coast as I write this. It's Sunday, I have work tomorrow morning.

I'm happy to say... Android has now officially been cracked onto the Beagle GadgetPack. Chris and I just finished hacking it onto the BeagleBoard, with a fully-integrated touchscreen OLED screen, overlay, and interface at the driver level to the BeagleTouch.

It connects to the internet.
It loads webpages, it runs scripts.
It reads and interfaces to sensors.
The touchscreen supports drag, drag and drop, sliding, scrolling, and gesturing.
It can download and run native Android APK files off of Open APK app stores.
It even runs the SL4A rapid prototyping environment that is scriptable in Perl and Python.

This was no easy task. Nick, Will, Chris, Mike all helped here and there with driver help and ideas for how to compile around the early driver problems. Thanks to the TI guys (esp. Gerald!), and the Google Groups community too for their help... and for the guys at embinux.org for a good starting point reference. And of course some special help from Google themselves (names will remain anonymous because I'd hate to see someone lose their job for supporting a hacker like me)... who came in at the last minute to help me crack open the driver access level, which allowed me to make a user-space display driver to the BeagleTouch... FROM SCRATCH.

Now the most important part of all of this is the question I got from Jake, when I talked to him 3 weeks ago: why?

Because I'm sick of the iPad. Every time you go into Starbucks, you see someone digitally frolicking around on their apps, clickety clacking around with glee, pinching and spinning their fingers around a million times just to do what you used to be able to do with CNTRL-+ or CNTRL-- to zoom in and out just as quickly, all the while being wholly restricted and unable to compile any of their own apps natively, and god forbid trying to access the driver level.

The problem is simple: I am fundamentally against the entire principle and idea of the phrase, "there's an app for that(TM)." (Are you serious?!?! I have to put a "Trademark" on that?!?) I think that little phrase is endemic of everything that's going wrong with the hacker world today. It symbolizes the end of an era. It is the antithesis of open, and the optimum of control and limitation.

I don't want an app for that. I want a programming language and access to some low level OS function for that.

I'm fighting back, and this Android hack is the first step in the war. The problem with the philosophy of "there's an app for that" is that it's training the new up and coming programmers and would-be hackers and developers that if you want some hitherto unavailable functionality for your device, you should go onto a tightly controlled ecosystem of apps (iTunes app store), and pay money for a limited, controlled, censored, channel monitored, Apple-sanctioned little app that took WAY too long to write because the darn specs are undocumented.

No thank you. I want to help teach, train, and motivate a new breed of far more open sourced and efficient hardware hackers...

Apple is going to lose. Because hackers are going to use the platform that is the most extensible, most hackable, and most fun to use. Programming the iPod and iPad and app store-compatible apps is an exercise in painful, torturous sacrifice. You start out development thinking you want to build a simple little functioning app. Then you find out, function by function, that Apple has restricted that functionality to a mere fragment of it's former self. Useless!

Android is where it's at. You get driver control if you need it, you have a multitude of programming languages, an Open Source app distribution channel, and raw sensor channels for interfacing with all kinds of sensors (stay tuned for some hacks on this to come). Android is literally the perfect rapid prototyping platform. It is just high level enough to be efficient, it's just low level enough to enable embedded applications development. And it's Open Source, so if you need to, you can just recompile the whole darn thing from scratch yourself if you want to.

And that's powerful. In the coming weeks, I'm going to do my best to integrate open source hardware and open source software together, using this newly cracked Android Gadget as my platform... bring it on!

How to turn a Beagle GadgetPack into a digital ASCII bunsen burner

2010-10-16T19:21:00.000-07:00

Time for a silly application of modularity... for no intent or purpose, simply demonstrating a Matrix-esque special effect on the front of the BeagleTouch module, running aalib's ridiculously cool aafire app.

Will and Chris put together a pretty cool little auto-loading script, and made sure all the aalib libraries were in place (which they were), and it just worked. The cool part is mostly how fast the demo seems to run...

Now time for the good part... as every hacker knows, the food pyramid contains 3 essential foods:

Yes, they are listed in that order because that is roughly how they stack up in order of mass consumed by me per week. I mean seriously, where would Linux virtual memory, Android's driver subsystem, and Ruby on Rails be, if not for these 3 food groups? I can personally attest to consuming my fair share... not because I particularly like the taste of any of them, but simply because generations of hackers before me have lived on exactly this, and who am I to challenge tradition? (This is getting ridiculous, I know). Many books have been written about programmer and hacker productivity, methods of development, etc. but I might argue that Red Bull, Pop Tarts, and Raman are a radically under-researched productivity tool.

But suffice to say, a digital ASCII blue fire bunsen burner - although non-functional - sure *looks* cool as heck underneath a can of Red Bull, doesn't it? It must be doing something... I swear it tasted better than my not-so-highly scientifically isolated placebo trial.

:-)

Ok, here's how to get it up and running on the Beagle Embedded GadgetPack:

Open up a terminal like xterm using the keyboard connected to the USB port on the side of the GadgetPack.

Then, either download this package onto the SD card, or if you have the Wifi Module or Ethernet Module, you can type this directly onto the command to download aalib:

wget http://sourceforge.net/projects/aa-project/files/aa-lib/1.2/aalib-1.2.tar.gz

Untar the archive:

tar xvf aalib-1.2.tar.gz

Move to the directory:

cd aalib-1.2

Run this command to configure:

./configure --host=localhost

Then compile the source code:

make
make install

And then run, sit back, and enjoy the digital fire that neither keeps you warm, *nor* cools you down, so at least it's not a negative fire, or put in other terms, at least the correlation coefficient between this digital bunsen burner and utility is not negative (R is at worst 0, so ha!):

export DISPLAY=:0.0
xterm -fg red -bg black -e "./aafire"

Voila!

For more pictures of the ASCII burner, I've uploaded some high res shots at flickr...

Maker Faire NYC Debrief

2010-10-14T00:33:00.000-07:00

I now live in Boston. I used to live in New York. Which made it all the more ironic when it came time to travel down to NYC to attend Maker Faire with Justin, Francis, Will and Mike. As it turns out, the night before we all headed down there, the construction crews decided to tear up a portion of I-95, which naturally meant some lane closures.

Nothing pumps up the DIY hacker spirit like sitting in traffic for 5 hours staring at this picture from the Main Street Danbury blog:

Hmmm, hmmm... I feel like that red card is a lot like the feeling I get when the bootloader doesn't load on the flash ram chip on the topside of the BeagleBoard OMAP, and I have to solder in my own debug cables to test the signal pins to make sure they work. And that truck is like the weight in my arm after 2 hours of solid soldering... and the right hand lane is the re-routing schematic of envy... yes.

But once we got to Maker Faire, the situation changed dramatically (it did take about a 30 minute detoxing whereby we desensitized to the intense traffic around Brooklyn and Manhattan). And here we were, to the right, and next to Nate from Sparkfun... Here's Mike and Will getting swamped with questions :-)

I like to try to construct a pyramid of TouchShield Slide boxes just for kicks:

I walked around, and saw a few fun pictures. Like this one, which although looks fun to some, is not really my cup of spinning tea. The whole time I'd be thinking, I really hope those welding points worked on the central axis tower:

Here was a view from outside the master tent:

I try to show up with as many projects as possible, and here are a few using the BeagleBoard and BeagleTouch:

I want one of these so badly, it's not even funny. I imagine I could do home delivery of DIY kits throughout New England on something like this. Would it be more time intensive and more expensive than UPS or DHL? Yes. Would it be worth it to do spin out donuts in street and driveway on the way to hand delivering a package of Arduino and BeagleBoard modules? Absolutely.

It only occurred to me after that this is a picture of everyone systematically walking away from me. The three folks on the left actually turned around right after this and started walking away too. Must have been something I said...

Here's a picture of Francis showing off a few projects...

I put a few more pictures up on the Flickr page in the original resolution...

Open Source Hardware Summit Debrief

2010-10-01T22:08:00.000-07:00

A week ago I went down to NYC and spent a few hours at the Open Source Hardware Summit. I sat on a panel and discussed with a number of pretty smart individuals, the merits of Open Source legal constructs and what Open Source Hardware is and isn't. A big, heart-felt thank you from me goes out to the organizers, sponsors, and creators of the summit.

Of course, there were so many more thoughts running through my mind than I could possibly share with the group, and I didn't want to monopolize the speaking time, so I took lots of notes. Here are a few of the notes I jotted down:

-What is the relationship between open source rights and intellectual property protection provided by the government?

-Is an open source design patentable? Is it copyrightable? Is it trademarkable?

-Open source hardware designs are getting licensed to hardware builders for rates around 5-10%, yet patented technologies have concepts like compulsory rates of 3%. Does that mean that patented designs might actually be cheaper than open source?

-Does an open source design have to be recursive and/or fractal? Can you have an open source design that uses proprietary integrated circuit chips? Can you use an open source circuit in a proprietary, closed device?

-Many of the successful open source hardware projects have in common that they rigorously protect one aspect of their business: arduino gives away the board but keeps the brand and trademark, beagleboard gives away the design by keeps the chip gate array design, bug labs gives away the schematics but restricts the inter-module snap-connect interface, liquidware gives away the hardware at cost, but keeps the analytical algorithms (e.g. you can buy a "military grade" IXM, but you can't get the code that turns it into a --CLASSIFIED--) Exactly :-)

-What do you use to base an open source hardware license on? Does it start from a contract that restricts freedom to operate, and use, or does it look more like wills and testament document, where it gives away rights and freedoms?

-Is the goal of open source to provide freedoms? If so, why does it need a license or contract to restrict rights?

-What is the relationship between the drivers and motivators of hackers, and the objective of a license? Could you have had open source software without the GNU?

-What came first: the license, or open source code?

-What is the "source" part of open source hardware? Does hardware have a standard "source" (no)? How long will it take to get there (a long time)?

All in all, I think - as always - I'm left with many more questions than answers, but I think that's the point. I don't really know why I do open source hardware, I don't even have to know what it is. But somehow, it feels good to make and produce open electronics, open source code examples that control those electronics, and devices that are in general far more accessible and hackable than previous generations of hardware.

So I'll keep doing "open source hardware" even though I have no idea what it means, whether the term carries any substance, because... it just feels right!

How to build a BeagleBoard-based Open Source Ebook Reader

2010-09-21T04:54:00.000-07:00

Ebook readers were hailed several months ago as the end-all-be-all of digital devices. They were supposed to put books out of business. In effect they have, they've put some book distributors out of business. But somehow, the Ebook itself is somewhat unsatisfying - after all the hoopla, we're left with "just" a screen tablet-like device, with a few buttons and a mini keyboard. It just doesn't feel like there's enough new to it... so I got inspired to build my own as a platform for experimenting with the "user experience" of Ebooks.

I got bored with my Kindle after about 20 times using it, and started wanting to hack it. I have a modern form of A.D.D. that makes me want to break open cases and solder memory expansion ports onto any device I touch. There's so much I'd do differently, yet you can't really do any development on it - I don't understand - they should just open it up, and let people like me hack away at it.

Since Amazon didn't, and doesn't, I decided to turn the Open SciCal into a hackable ebook reader, based on the FBReader source code. This means that it's hackable from the ground up...

It's not bad, but there are some things I'd change. Luckily I can, because the source is open and accessible... in fact, it's quite easy to understand - here's the important main function set, from FBReader, which gives a good idea of how approachable the code is (if you know C and C++, that is):

void FBReader::openBookInternal(shared_ptr book) {
    if (!book.isNull()) {
        BookTextView &bookTextView = (BookTextView&)*myBookTextView;
        ContentsView &contentsView = (ContentsView&)*myContentsView;
        FootnoteView &footnoteView = (FootnoteView&)*myFootnoteView;

        bookTextView.saveState();
        bookTextView.setModel(0, 0);
        bookTextView.setContentsModel(0);
        contentsView.setModel(0);
        myModel.reset();
        myModel = new BookModel(book);
        ZLTextHyphenator::Instance().load(book->language());
        bookTextView.setModel(myModel->bookTextModel(), book);
        bookTextView.setCaption(book->title());
        bookTextView.setContentsModel(myModel->contentsModel());
        footnoteView.setModel(0);
        footnoteView.setCaption(book->title());
        contentsView.setModel(myModel->contentsModel());
        contentsView.setCaption(book->title());

        Library::Instance().addBook(book);
        Library::Instance().addBookToRecentList(book);
        ((RecentBooksPopupData&)*myRecentBooksPopupData).updateId();
        showBookTextView();
    }
}

The Open Source Ebook reader is based on a handful of modules:

-BeagleBoard - the guts of my Ebook uses the TI OMAP
-BeagleTouch - it has a touchscreen OLED screen
-BeagleJuice - it's powered for 8 hours at a time with lithium ions
-FBReader - open source software, quite nice and hackable
-Liquidware Ebook Boot - an open source boot SD card with a tweaked version of Angstrom to integrate all the parts

The base parts are pretty straight-forward, they just snap together and go. If you're a hacker, you could build it all together pretty straightforward-like from source and use Angstrom. But if you're lazy, you can just buy the "Ebook Boot" SD card which took Chris and Will and me about 2 weeks of hacking around to build, from source, from scratch. It includes all of the drivers needed to get the touchscreen working within Linux, and a handful of libraries and scripts to make wifi, power management, screen control, etc. work right out of the box...

The fully combined stack of modules makes an Ebook:

Here it is from another angle, against a go table that I built by hand (those lines took forever, and were done with a heat iron, for wood carving, but it was so worth it):

This photo is probably the most "ironic" given it's a shot perhaps the most purpose-built hackable Ebook reader on top of the perhaps the most purpose-built non-hackable devices ever: a Mac laptop.

This is probably my favorite picture:

I haven't tried it yet, but conceivably, it could be connected to the net using the Wifi module, and then it could download Ebooks and free Ebooks from the various online stores that FBReader lets you connect to...

I've uploaded some pictures over on the flickr page, and the modules and finished EbookBoot SD Card are all available over at the Liquidware shop... I think I should run a timed contest against myself on how many different types of gadgets I can build within 4 minutes, like these guys that Make blog featured a little while ago...

:-)

I'm heading to Maker Faire NY!

2010-09-20T10:04:00.000-07:00

This week is Maker Faire New York City, and it holds a special place in my heart, for a number of reasons. A large part is because Maker Faire is where I started out, 3 years ago, with my humble little TouchShield Legacy and Arduino. At the time, I was traveling quite a bit for my day job, and barely had time to sit in one place long enough to do any serious development.

Maker Faire
New York
September 25, 26 2010

Fast forward to the present - now I live in Boston, and after three years of driving or flying myself out to San Mateo for Maker Faire's, I'm pretty excited to have one in my own back yard... relatively speaking, that is.

In the past, I've set up tables with some of my favorite hacks. But this time, I'm going to be joined by Justin, Will, and Francis, fellow hackers at Liquidware. And instead of showing off only just my Open Source Hardware hacks, all 4 of us are going to bring along demos and hacks using the latest gadgets.

And at least one of the projects hasn't really been blogged about, because it's still in demo form. Dun dun dun :-)

Ok, back to packing for a busy week ahead...

Book burning post mortem: digital destruction

2010-09-19T22:52:00.000-07:00

Lately I've been reading Joseph Schumpeter's writings on Creative Destruction, in preparation for the upcoming Open Hardware Summit this coming week. I know, some heavy stuff... So my head has been thinking about destruction and acts of purposeful damage.

I've gotten a handful of funny emails and comments in conversations over the past few days in response to my article about book burning, so I thought I'd give it a quick summary of my favorite additional ideas. Far be it from me to beat a dead joke any further than it needs to go (not really, I do it all the time), but I do think there's something worth contemplating here, about the future of book burning.

The essence is: digital desecration is far more nuanced than book burning. You simply have more options to be obnoxious.

In no particular order:

Burning isn't good enough, you also have to explicitly destroy some of the content
There is a close relationship between desecration and information defacing
Digital desecration opens up a more complex relationship between destruction of the physical object, the file, the creative medium, the idea, and the ideology
In the digital desecration world, each of these are explicitly different stages (in that sense, is book burning in the traditional sense more effective? will we one day pine for the good ol' days when book burning was as easy as applying incendiaries to paper?)
A corollary is that the more creative effort that went into a work of art, the more "satisfying" it is to desecrate (e.g. destroying that which took seconds to build is somewhat lame)
A further corollary suggests the ratio of time invested in desecration should somehow be far less than the time someone else invested in the act of creating
At the ASCII level, digital defacing might include something like taking a concept or idea, and overwriting or padding it with the word "sucks"
At the byte level, you could swap the Endianness of the double chars in order to make it unreadable by whatever chip it's on
At the binary level, you could AND or XOR the binary with a random binary sequence, in order to truly make it obfuscated and irretrievable (thanks Devlin)
At the file level, you could overwrite pieces of text with strategically identified counter-points or antithetical topics
At the archive level, you might rename the cover or title of the file to something misleading, in order to deceive the next potential reader
At the chip level, you could create a mechanism that actually made the chip on which bytes were stored burst into flames, moving into the real physical world for some tangible destruction (thanks Chris)
At the web level, you could Google bomb the concept or title of the Ebook or text, so that when it's Googled, other links come up at the top that are actually propaganda for something else
You could try to measure the performance of desecration by converting electron energy into mass using E=mc^2
Less heat is generated from digital desecrations, implying less "wasted energy", and instead there is a more efficient thermodynamic transformation, directing more energy at desecration than being lost as radiating heat

In closing, I'll just throw this out there, since it really got me thinking... we look back on the burning of the Library of Alexandria as a horrible thing, because of all the timeless works of literature that were lost. Do you think anyone would notice if Twitter turned off it's saved tweets archive feature? Will uber-nerdy future historians 1,000 years from now lose cryogenic nano-sleep over this, as they zip around on intergalactic hoverboards?

Probably not.

Book-burning needs to modernize

2010-09-15T21:37:00.000-07:00

To make things perfectly clear: I do not recommend emotional book burning. I think it's wrong and inefficient. I'm simply going to say this: If you're going to do "book burning" I believe you need to find a more modern way to achieve your goals. Use technology. Better yet, use Open Source technology to achieve your goals.

Something about the press release events of the past week or so has rubbed me the wrong way. But not because of the reasons already expressed by the "media". It's because the guy in Florida is doing it all wrong. We live in a world with headlines filled with stories about Barnes and Noble and Borders books going bankrupt or being sold. Ebooks are taking over. Who can afford to think about burning books at a time like this?

In order to have a serious book burning, there's a serious time investment. You'd first have to find the book you wanted to burn, order copies from 10 different retailers on Amazon, pick the most worthy copy, and then commence burning. You'd probably use some social media site to send out Evites or set up a Facebook event hoping people would pull themselves away from Farmville long enough to sit around watching a book burn. What a pain in the rear. If I think about some of my friends, I highly doubt that a book burning event would even hold their attention for more 30 seconds before they were checking their iPhones and Android phones, or sending email on their Blackberries.

When is book burning ok?

If I were homeless in the winter, in a cold climate, and had no other source of shelter, but had plenty of books and matches, I would hope people wouldn't judge me if I were to burn the books I had collected. Alternatively, if I were filming a movie about World War II, or a documentary about a time when books were burned, for historical accuracy, I hope people would appreciate that as art. I suppose if I were the author of the books, it's ok to burn them.

This last reason is cause for serious suspicion. It supposes that there is a relationship between the intellectual property and creative process of writing, authorship, and acceptability of burning books.

What happens when you burn books (or blogs)?

Books are actually not so easy to find that I would actually be willing to burn, so I'm burning something closer to my heart. But first, this is me burning a set of blank pieces of paper:

No emotion. Some heat felt. Fire consumed 3 sheets of paper within 62 seconds, for a rate of 2.90 pages / minute.

It wasn't easy finding books I was willing to burn, mostly because I like to take notes in the margins, which I find useful. So instead, this is me burning a recent article from the Antipasto Hardware Blog:

EMOTION!!! Some heat felt. Fire consumed 4 pages within 1:48 at a rate of 2.22 pages / minute. The pages were printed with 1622 words across 189 lines, or 7750 characters.

Another way to say this is, my book burning experiment consumed 143.5 bytes / second.

I'm going to assume that the way I folded the paper to allow oxygen in had more to do with the rate of burn than factors like wind (there wasn't any), flammability or not of the ink, or perhaps because my writing is so bad, it burns faster because thermodynamic principles are trying to undo the entropy I create.

What's the difference?

Thought Experiment: Why do people burn books?

I believe that books are burned for several reasons, not limited to the following list:

-Heat
-Light
-Waste disposal
-Publicity leading to social unity
-Desecration

I'll address each one in turn:

-Heat. Not great support for burning books. Modern heaters are known to be more efficient. Plus burning books isn't the quickest, easiest way to generate heat.
-Light. Also not great support for burning books. LED lights are a much more efficient way to achieve this.
-Waste. So so. Just throw it in a landfill, or plant it at the base of a tree to fertilize it. Burning many books, however, may save the time and energy to lug them all to a landfill, so it's a toss-up here for me.
-Publicity leading to social unity. Probably a toss up. This is a lot of effort, and you likely have to create significant consternation before you'll get noticed in the mainstream press.
-Desecration. Now this, I think, is the important point.

Measuring Book Burning Performance: Desecrations / Second

Steve Jobs would probably burn the second volume of my book. Because it's all about Open Source Hardware Strategy and Economics, like what Google uses. Steve hates Open Source, Google, and things that are Open Source like Android, so it's understandable that he might seek to desecrate ideas associated with them.

But here's the problem: if you're going for desecrations, why settle for mediocrity? Why not go all out and desecrate in a modern, digital way?

Here's some Arduino code I wrote to do desecrations:

void setup() {
pinMode(13, OUTPUT);
Serial.begin(9600);
}

void loop() {

Serial.println("Start");
Serial.println(millis());

for (int j=0;j<=30000;j++){
char a[] = "Open Source Hardware is the future.";
for(int i=0;i<=strlen(a);i++){
a[i]=0;
}
}

Serial.println(millis());
Serial.println("Done desecrating 30,000 times.");

digitalWrite(13, HIGH); delay(1000);
digitalWrite(13, LOW); delay(1000);

}

Running this sketch achieves 30,000 digital desecrations within roughly 800 milliseconds. This is an effective desecration rate of 1,440,000 desecration-bytes / second!

This Arduino should be ashamed of itself:

It instantiates an array with a phrase, filled with digital bytes of information, and then deletes it from memory. But it does so in the most desecratory way you could imagine: 1 helpless, bloody char at a time - and not even with civil memory management!? From a programmer's point of view, this is heresay. This is like torturing a person by pulling his fingernails out one by one, like every one of those Saw movies. It's like tearing out the pages of a book one by one, and then burning it. Couldn't you have just dereferenced the array pointer, and left the char array in memory? Or if you have to move on, why not just call memory purge?

Ladder of desecration:
Bad: Buying book and burning it (plain form desecration 101)
Worse: Stealing book and burning it (not participating in the economic incentivization system)
Worst: Stealing book, ripping pages out, then burning (physical acts included)

Likewise, here's the digital ladder of desecration:
Bad: Removing software or deleting an ebook from your device
Worse: Torrenting the software and Ebook, and then deleting it
Worst: Torrenting the software and Ebook, and then deleting it, one character or word at a time

Here's some plain R-code to do the same task:

R
x=readLines("OSHWBook.txt");
x <- NULL;

Eh, not a huge impact on my emotions. But this is a completely different story:

R
x=readLines("OSHWBook.txt");
for(j in 1:length(x)) {
for(i in 1:nchar(x[j])) {
x[j][i]="";

}}

x <- NULL;

Seriously?!?!! Is that middle step really necessary? If you're going to delete something just throw it out. There's no need to iteratively replace bytes in memory - without even a simple purge. That's unnecessary and ridiculous.

To me, book burning just doesn't have the same impact as it did when the scholars looked on as the Library of Alexandria was burned to the ground. But this R code hurts. And it's going above and beyond the call to destroy.

Benchmarking Digital Desecration Performance

One could argue that you could measure the strict word count (which is like page count). You could measure file size in bytes, but that's a proxy for document length. You could measure unique words. You could even measure Shannon complexity of the document.

I think there's an open question, perhaps requiring further research, to examine whether or not it makes sense to count bytes, characters, words, or perhaps on synonyms of a specific trigger word or phrase that is considered "desecratory". Perhaps there is an ontological argument to be made about the distribution of desecratory-capable phrases in a document (does it follow a long tail?).

I would argue you want to measure the entropy of the desecrations, which I will define as: number of RAM instantiations and removals of bytes associated with the topic to be desecrated.

Generalization

So I have established a relationship, which I will put in the 2x2 matrix below:

Implementation

Here's some Arduino code that runs on the Arduino and blinks a red LED every time a desecration takes place.

void setup() {
pinMode(13, OUTPUT);
Serial.begin(9600);
}

void loop() {

Serial.println("Start");
Serial.println(millis());

for (int j=0;j<=30000;j++){
char a[] = "Open Source Hardware is the future.";
for(int i=0;i<=strlen(a);i++){
a[i]=0;
}
}

Serial.println(millis());
Serial.println("Done desecrating 30,000 times.");

digitalWrite(13, HIGH); delay(1000);
digitalWrite(13, LOW); delay(1000);

}

Here's the Open SciCal running desecration.r desecrations script:

x=readLines("OSHWBook.txt");
for(j in 1:length(x)) {
for(i in 1:nchar(x[j])) {
x[j][i]="";

}}

x <- NULL;

Conclusion

I believe book burning is about the public destruction of intellectual property. In a world over-run with new forms of media, and open source software and hardware, however, we need to catch up with the times. I applaud people for having strong beliefs, but if you're going to desecrate someone's intellectual property or creative works, then do so with a modern toolkit!

And do it with Open Source Hardware, why don't you, so others can share in your destructive acts!

:-)

Learning PWM with Illuminato Genesis and TouchShield Slide

2010-09-14T23:56:00.000-07:00

With the relaunch of the Illuminato Genesis (which was featured on Make Blog a while back), I figured I'd whip together an app that showed off the what the Illuminato Genesis can do. I've been spending a lot of time with the BeagleBoard recently, and that's clearly a top end type device, but the Arduino and Illuminato Genesis plus TouchShield Slide make a nice gadget at the lower end of the spectrum, especially for smaller handheld apps.

I've wrapped everything up into an app on the Open Source App Store over here. The app includes 3 files:

SoftwareSerial_NB.zip - This should be dropped into folder: hardware\arduino\cores\genesis\src\components\library
TouchShield_Pulsing_Sleep.pde - This is a sketch that implements the PWM duty cycle value to the Illuminato Genesis, using the bling() function
Illuminato_Serial_Bling.pde - Listens for PWM duty cycle value from the TouchShield and controls the virtual bling LEDs on the front of the TouchShield Slide

The Illuminato Genesis has an array of gold-rimmed LEDs on the backside of the board, which can be called using a function in the Antipasto Arduino IDE library called bling(). bling(1) turns the LEDs on, and bling(0) turns them off.

So the first step was to implement PWM light control, which is accomplished with this snippet of code:

/* Software PWM modulation routine */
void pwm_bling(char duty) {
int duration;

duration = (millis() - pTime);

if (duration <= duty) {
    bling(1);
} else {
    bling(0);
}

if (duration >= period ) {
    pTime = millis();
}
}

Then, using serial communications between the Illuminato Genesis and the TouchShield Slide, the PWM'ing is synchronized so that both boards are pulsing at the same speed. The effect is pretty cool looking, if you ask me. On the one hand, you have real LED's on the back of the Illuminato pulsing, and then you have virtual LED's on the TouchShield Slide's OLED pulsing.

Here's the video:

And here are some other pictures:

How to make a BeagleBoard Elastic R Beowulf Cluster in a Briefcase

2010-09-07T08:10:00.000-07:00

The BeagleBoard's OMAP chip has some serious computing chops, and this project set out to prove it. Ever since I built the Open SciCal, I've been showing it off to nerd friends of mine (that's another way of saying, if I've showed your the Open SciCal in the past 2 weeks, I think you're a nerd that would appreciate it - ha). Granted, a single Open SciCal is nice. But the real impressive part is the combination of serious floating point horsepower with low power.

I figured I'd do this project to respond to all those people who were skeptical that the Open SciCal had any utility in the modern world. Well... my answer is yes.

I took 10 BeagleBoards and turned a suitcase into a wifi-accessible, on-demand, elastic R computer cluster that runs at 10 Ghz, 40 Gigs of disk, and 1,000 megabits of networking bandwidth. I did this all for less than $2,000, and spent less than 5 hours building it, and now I have a scalable compute resource that is portable, has performance comparable to mid-range and high end servers that cost $15,000-30,000 from IBM or Sun. And better yet, it all runs at 30 Watts. That's less than most of the incandescent light bulbs in my room right now.

I've also made the whole project Open Source, for anyone who wants to replicate it on their own. Personally, I'm going to build another one out of 32 of these suckers, and rent it to the trading firm that bought dozens of Open SciCal's from me in the past couple weeks.

Step 1: Get 10 BeagleBoards

I took 10 BeagleBoards, and used the same standoffs that I use in the Embedded Gadget Pack. I used an offset pattern so they could stack as high as I wanted them to. I built them all the way up to 10, and then decided it wouldn't fit in a suitcase, so I split them up into 2 mini-towers of 5 BeagleBoards each.

Step 2: Buy 3 cheap, low power hubs

I went to Radio Shack (begrudgingly because they sold out to the cell phone man in 2000 and have sucked ever since), since they were the only ones open. I bought 1 wireless router with 5 ethernet ports in the back, and then bought 2 netgear hubs (each had 5 ethernet ports).

Step 3: Wire the "interconnection backplane"

I've been reading old literature about multicore, multi-processor, scalable computer architectures, and they have a funky way of making simple concepts like "network" sound really complex like "Fat Tree Fishbone N-Way Scalable Interconnection Backplane".

Oh so you mean I plugged the two hubs into the wireless router, and then put 4 wires into each of the hubs, and 2 from the router, and connected them to the BeagleBoards with USB-to-Ethernet modules.

Like this:

I have this new mantra that things I read in hefty academic papers are written in language way too fancy for what they're trying to do. I get the sense that this is intentional, to hide the fact that what they researched could be replicated for $2,000 and 5 hours in modern times. I kid, partially. I'm reading papers written in the 1980's and 1990's, when the idea of doing what I just did would have taken a $10,000,000 DARPA grant.

Step 4: Set up the Open SciCal Slave Nodes

Each of the BeagleBoards is running the Open SciCal SD card from Liquidware, with a few notable additions:

-Each card is configured to allow passwordless logins over dropbear SSH
-Each card auto-configures itself to a static IP address
-The cards have a slightly trimmed down set of background apps to make R more responsive

I then replicated the card 10 times, onto each of my SD cards.

Step 5: Build the Power Backbone

This was an easy step conceptually, but a pain to do in an organized manner. So I gave up the organization, and just hacked through it. I took 10 BeagleBoard power connectors from the Liquidware shop (specifically those because they're low wattage). And connected them into two small outlet strips.

I then routed those power cables around and through to each of the 10 Open SciCal BeagleBoard Compute Nodes.

For kicks, I got one of those "kill-a-watt" meters and put it in front of the whole set up, so I could measure how much power the whole thing consumed.

Step 6: Configure the Master

Parallel architecture guys are always labeling nodes "master" and "slave". I think it's some hidden repressed anger at the fact that most of us "nerds" never got picked first for kick-ball and 4-square (the game, not the GPS website) when we were kids. Take that, 2nd grade. Now look who's deciding who's "master" and "slave". Me.

In all seriousness, at this point in the project, I had 10 networked Open SciCal nodes. But no way to issue code to them. So I took out my trusty Ubuntu Linux laptop, and quickly got it to connect to the wireless G router I'd set up to be the master switch for all 10 of the BeagleBoards.

Since the system is running on R, I naturally tried to get some of their default environments running, like Snow, Snowfall, svSockets, and even MPI. But each of those turned out to be serious overkill. Sure, they're easy to use if someone else is installing them for you and you don't have to think about it, but they didn't really get the job done in the amount of time I was willing to dedicate, so I wrote my own scripts.

Here are all of the programs I wrote, in one "app" on the "Open Source App Store".

Step 7: Write Elastic R Programs

I was hired by a company a couple months ago to write data mining algorithms to run on the Open SciCal. Most of them were top secret, but a few were pretty elementary. For instance, one function that is used often in text data mining is a function to extract all capitalized phrases. For instance, Amazon uses this on their website to summarize books with a few phrases.

Here's the R code that extracts the indexed location of any capitalized word in a piece of text:



x=readLines(file("data.txt"));

y=(unlist(lapply(x,function(x){lapply(x,function(x){strsplit(x," ")})})));

z=y[y!=""];

out=which(lapply(z,function(x){grep("[A-Z]",unlist(strsplit(x[1],""))[1],value=FALSE,invert=FALSE)})==1);

write.csv(out,file="out.txt")

This is a piece of code that you'd often want to run against 1,000's of pieces of text at a time, to extract important pieces of information. I wrote this into a program called "upper.r".

I then wrote some "administrative" functions for my homemade Elastic R Beowulf cluster - you can download them here:

"esh" - "elastic shell" - this runs a command on all of the slave nodes, and kicks back the output
For instance: esh "uname -a"

"ecp" - "elastic copy" - this copies a file to the home/root/ directory of each of the slave nodes

"epush" - "elastic data replicate push" - this takes a set of data files in the data/ folder called "1.txt" "2.txt" "3.txt" etc. all the way up to "10.txt" and copies them over to each node as /home/root/data.txt. This is important if you want to parallelize different data across to each of the nodes.

"epull" - "elastic data extract pull" - this does the inverse of "epush" in that it pulls a single file called /home/root/out.txt off each of the nodes, and renames them locally into the "out/" folder as "1.txt" "2.txt" "3.txt" etc. according to which node it came off

A typical session would look something like this:

esh "uname -a"
ecp upper.r
epush data.txt
esh "R BATCH < href="http://en.wikipedia.org/wiki/MapReduce">Map/Reduce". If you wrote about parallel computing in the 1980's, you would call it "Distribute/Evaluate/Collect". If you worked at Wolfram Media, you'd call it "ParallelDistribute/ParallelMap". Or if you hacked on the Cray, you'd call it "LoadVec/ParVec/PopVec". At NVIDIA you'd probably call this "CUDALoad/CUDAExecute". Or if you were the CEO of Amazon, I supposed you'd call it "Elastic Cloud Map Reduce" and then you'd make the programming API really obscure and difficult to develop for, and then charge a god-given arm and a leg to use it.

They all do the same thing: copy data to nodes, run them, and copy the output back.

Step 8: Benchmark and Go!

I wrote a couple of benchmark programs that basically run the upper.r code 40 times on a large chunk of text I downloaded from Project Gutenberg. The benchmarklocal.sh script runs the test 40 times serially locally on my laptop.

The benchmarkparallel.sh script runs the test 10 times in parallel, then repeats 4 times.



#!/bin/bash

./ecp data.txt

./ecp upper.r

./esh "R BATCH --no-save <>



The results are surprising to me, at least. The punchline is that, on average, the Dual-Core Intel chip takes ~30-35 seconds to complete the tests, while the BeagleBoard Elastic R Beowulf Cluster takes around ~20 seconds.



benchmarkparallel.sh is faster than my top-of-the-line $4,500 Lenovo work laptop running benchmarklocal.sh. Now there are always going to be skeptics saying, I could have optimized this or that, but that's not the point. I built it much faster than I could have normally...



Step 9: Take lots of photos



The sky's the limit. Or rather, the practical limit is my ability to appear socially uninhibited as I bring this suitcase into a conference meeting room, pardon myself as I plug it into the outlet (until I get a battery backup unit), and then run the thing at max speed as I calculate floating point math, and extract long capitalized phrases from anything in the room.







I uploaded the rest of the pictures I took in much higher resolution over on Flickr...



:-)



Enjoy...



If the Old Spice Man were an Arduino
2010-09-05T08:17:00.000-07:00
I worked fairly late last night on one of my projects, so I'm in a silly mood as I type this. Justin just mentioned to me that he built some more Illuminato Genesis boards, and that I should mention that they're now in stock for the first time in months. But that would be boring, so I figured I'd "spice" up the public service announcement... and Chris and I have had an inside joke with Chris that the Illuminato Genesis is the Old Spice Man of Arduinos :-)

The Illuminato Genesis has a lot in common with the Old Spice man:

It's ripped - with 42 I/O pins
It's built - by hand
It's tall - with 64k of memory
And it's suave - with custom LED's

So naturally... 

Look at your Arduino.


Now back at me.

Now back at your Arduino


Now back to me.

Sadly, he isn't me.

But if he had 42 I/O pins, and had twice the memory, he could function like he's me.


Look down.

Back up.

Where are you? Your in a lab with wires.


With the Arduino your Arduino could look like.


What's in your hand?

Back at me.

It's an oyster (or 2 shells) with two USB mini B connector cables to interface that thing you love.


Look again.

The cables are now a TouchShield Slide!

Anything is possible when your Arduino is an Illuminato Genesis and not a Duemilanove.

I'm on a horse.

You have no idea how hard it is to find a horse these days. :-)

By now, almost the whole world knows about the "Old Spice Man":




The emergence of "instant prototyping" vs. "rapid prototyping"
2010-09-01T16:04:00.000-07:00
A couple days ago, I talked about why I liked using and programming modular Linux gadgets. Mike wrote me a long email in response to my comment about "rapid prototyping" vs. "instant prototyping" which I thought I'd share.

With the growing popularity of MakerBot, the reduced transaction costs of interfacing with sensors and digital circuits that the Arduino allows, and the emergence of modular prototyping platforms like Liquidware's Beagleboard-based gadget packs and Bug Labs, it feels like there's been a fairly dramatic increase in single-programmer productivity.

I re-read one of my favorite books of all time, "The Mythical Man Month" by Frederick Brooks. Normally I don't get too excited about dense, heavy, cerebral books that don't have any practical advice unless they teach a new programming language (or algorithm). But in this case, I make an exception, because it's just a decent book that questions the process of engineering.


Well, lo and behold, I decided to amazon around for comparable books, and I discovered that the author has written a new book, which sounded even more cerebral and pie-in-the-sky, "The Design of Design". As an aside, I wonder how much more "meta" you can possibly go. How about: "The Process of Thinking about Writing about the Design of Design" ? I mean, even the Greek philosophers had a limit. (Actually, then you'd need to write a book about a "Formalized Grammar and Metaphysics to Document the Process of Thinking about Writing about the Design of Design.")

At some point, for the sake of humanity, I just hope someone remembers how to actually do something tangible! But I digress. Turns out, I enjoyed the book.

It got me thinking. The Matrix movie got me thinking, as did the movie Inception (actually the 13th Floor did too but fewer people saw that one). So the fact that a book held such high company in my mind as the Matrix, Inception, and 13th Floor is high praise coming from me. Much of the book was focused on the process of designing design processes.

How many designers are too many, how should they work together, how do you organize to solve problems? I had a thought while reading the book: design exists because planning for engineering is an important and valuable step in communication and preparing to optimize problems. This is largely because engineering takes time.

Engineering, or building, or solving problems takes time.

But what happens if you break into a new plateau of productivity? What if that time is reduced significantly?

I've hit a personal plateau and breakthrough in productivity twice. Once in software, once in hardware. The software one happened a few years ago, and the hardware one happened about 2 weeks ago.

Software Productivity

My personal software productivity came when I moved from C programming to purely Perl. I realized that I could write an algorithm faster in Perl, and make a functional program faster, than I could in C. Because of that, I could iterate on the program faster, add new features, in less time. The next bump came when I moved from Perl to R. I could do almost everything I could in C in R, except that R also let me access tons of higher level math building blocks. I became really fast at writing code in R... although it took the code longer to execute, I focused on optimizing the algorithm or the way I wrote a function, as opposed to spending lots of time debugging Perl data structures, or C memory leaks.

The common thread was that R allowed a higher level of functional modularity, but still exposed the lower level functions and data types for me to use when I needed them.

Hardware Productivity

Recently, I've felt similarly faster at building hardware than I used to be. I used to have to write PIC chips into protoboards manually with wires that I stripped and cut myself. Then I got excited about Basic STAMP boards because they let me focus more on the code, and on a few simple digital IO pins. Then the Arduino completely changed the way I thought about accessing sensors, switches, and digital interfaces in general - it significantly lowered the "hardware access barrier" if such a thing exists. In practical words, it let me sit down, and hack the E-Ink screen on the Esquire magazine cover in a matter of hours, rather than days. Now, I'm hacking away on Arduino gadget shields and BeagleBoard Gadget Packs... and the time it takes to go from "I have an idea for a gadget hardware that does XYZ" to actually having one in front of me is measured in minutes.

I think I've found the critical pattern... just like in software, the biggest productivity improvement came as the hardware allows a higher level of functional modularity. I'm interfacing with sensors now, as opposed to I2C buses, so I'm able to build a hardware device even faster using a new sensor, for instance. But the important part is that as the hardware gets higher and higher level, it still gives me access to the basic bit-banging serial and data IO ports and buses, just in case.


Open vs. Closed Design Philosophy

That's the biggest difference in my design philosophy and that of Apple. While Apple *hides* digital IO and obscures interfaces, everything I've ever built *opens* the digital raw interface, and keeps that exposed and really easy to access from Perl, R, and C, even as the modules higher level.

The result is much faster hardware and software development.

As this continues, the time it takes to prototype decreases.

At some point, the time it takes me to prototype a device might reach the time it actually takes for me to just build it anyway.

And maybe that's some new concept or field of "extreme" or "agile" instant hardware prototyping.

...and naturally, this is accelerated by the existence of Open Source Hardware...

Why? Because Open Source Hardware is about lowering design barriers, exposing underlying schematics functional blocks, and the result is that prototyping with Open Source Hardware - in my experience - is orders of magnitude faster than traditional dev kits, and proprietary hardware.

... 

Wow. Where did that come from? I suppose this is an example of the kind of high level, head-in-the-clouds type thoughts you walk away with after reading "The Design of Design". I feel like the reading rainbow guy: I recommend that book for any design engineer. I think the kind of design discipline I learned will make me a better hardware hacker - or at least a more efficient one (I wonder if anyone's ever done a study on hacker efficiency?) And the honest-to-goodness truth is that I'm not paid to endorse it. I'm not getting any kick backs (ha), nothing. I simply enjoyed the book, and it made me realize something about my own design process I hadn't thought about before...



Ok, back to hacking hardware, I promise...


Why I like building with modular Linux Gadgets
2010-08-30T23:04:00.000-07:00
With all the talk about iPhone vs. Android wars, it's easy to forget that Linux was once discussed as a popular platform for rapid prototyping gadget development. The more projects I do with the BeagleBoard, the more emails I seem to get from fellow engineers and programmers - many who work at embedded systems companies around the Boston, New York, (and California).

Oddly enough, a lot of programmers still favor Linux development over iPhone apps because of how many programming languages you have available, and the fact that you don't have to load up massive amounts of dev API's to start hacking, you can just pick it up with gcc or Perl and run. And Linux gadgets in general are a little different from Android too, because while Android focuses more on the GUI and user interface and experience, Linux is much lower level, and therefore tends to be more useful for industrial design, control, and engineering applications like sensor and motor control and industrial automation.


I suppose you could say Android is "consumer" focused, and Linux is "industrial" focused.


Anyway, I've been programming a number of apps for folks who have asked for help recently, and I've been learning a lot about the design process of building modular gadgets with the BeagleBoard from TI, and the BeagleTouch and BeagleJuice from Liquidware.






The first thing I've realized is that having raw exposed digital IO pins is a life-saver. I use these to hack in switches and LED's without having to completely reverse engineer schematics and pin diagrams. Literally I can just solder into the general purpose IO and I'm off and running. Alternatively, I use the Arduino to wire in a sensor like the Compass Sensor or Temp Sensor or Gyroscopic Sensor, and then plug it into the USB port (I'll blog about this soon).




Practically speaking, being able to disassemble the device and reassemble it on the fly in a modular way, is a pretty useful skill in making gadget or hardware demos. This is because I can change the form factor around on the fly. I was in a meeting earlier today (which inspired me to write this article), when the project manager guy asked how hard it would be to turn the Gadget Pack handheld into a terminal with a keyboard... so I unscrewed the demo and within 60 seconds, had something that looked like this:




Then, one of the engineers said, "yeah, that's cool, but we really ought to have an on-screen keyboard." So I clicked around twice, and using the fact that it's a touchscreen, I loaded up the Linux onscreen keyboard app that Will converted for the Beagle Gadget Pack, and then turned it into this:



That's pretty powerful, because it's *real time prototyping* not just rapid prototyping. As in, it happened instantly, almost as fast as it took for someone to finish the sentence, it was done. I've observed that "business guys" and "customers" that embedded design companies build devices for often like to change their mind in the middle of the project as they learn more about what they're trying to build, or the aesthetics, or design or interface needs. It's quite expensive to a project to have to re-engineer the whole thing from scratch every time the form factor needs to be changed. Making something 100% modular makes changes like this really fast. Plus, I've pretty much found a way to cut out the part of the prototyping process that involves making a "non-functional prototype" and just jumped right into making a functional prototype...




So I've been living with the Open SciCal and the Gadget Pack for 2.5 weeks now, and so far I've showed it to half a dozen folks, and gotten 3 assignments to build custom gadgets using the platform. I'm not going to become a millionaire by any means, but I'm at least getting paid to do what I love doing... which is hacking open source hardware into gadgets, and if you had asked me 3 years ago when I started this blog if that would ever be a possibility, I would have said fat chance...




So anyway, thanks to Will and Chris, Mike and Justin, and Matt, John for all the support and help along the way... and here's to some happy hacking over the next few days and very very late nights as I work on my top secret project...


"Project C".


Dun dun dun....


:-)






Thanks Hackaday :-)
2010-08-29T10:16:00.000-07:00
I must have totally missed this, but I looked back at my RSS reader, and noticed that the Open SciCal project got onto hackaday. Thanks a lot! It's definitely no secret that I have a nerd crush on hackaday, since I've read that blog since middle school, and aspire to recreate everything they mention and talk about.




Here's a link to the post, and thanks again, hackaday...








Top 5 Things Microsoft Should Open Source
2010-08-28T21:15:00.000-07:00
I don't typically go on rants, but when I saw this article about Microsoft being Open Source, it got me thinking..

If we take them at face value and assume this is a serious statement of fact, and not a clever PR campaign for OData by Jean Paoli, then we have to assume that Microsoft is stupid. Microsoft makes money from being proprietary, and capitalizing on two things:


The integral nature with which their products exchange information with each other
The firewalled nature with which their products do not exchange information with other products

The most important element of their successful software platform is not so much that it is "Open Source" or not, but rather that it only plays well with themselves, and doesn't play well with others! Microsoft software is like a monstrous horrible clique of software programs that hangs out in the corner of the playground by itself, gossiping about everyone else, and thinking they're really awesome when really they're not. Microsoft Office is like Zac Efron's character Troy Bolton: a huge tool.

In the words of Mike Posner, and the lyrics of "Cooler than me", this is what I think of Microsoft:


you got designer shades,          (closed ridiculous XML standard files)
 just to hide your face and        (poorly written code)
 you wear them around like    (all your apps have the same VB code that isn't open source friendly)
 you're cooler than me.
 and you never say hey,             (how do I get data into an Excel sheet from a Perl script, eh?)
 or remember my name.           (when's the last time you updated your MySQL import code? HELLO!)
 its probably cuz,
 you think you're cooler than me.      (But you're not.)

Don't get me wrong: I've been a user of Microsoft products for some time, not only because I have to, but because a lot of analytical and information based tasks just happen quicker when tools talk to each other, and you can transparently export and import data from one tool to another. This isn't necessarily an argument for Open Source, but it's close.

I would argue the single most important and "open" commitment Microsoft can make is not about their source code, but about their architecture. "Open architecture" means playing well with others, which Microsoft doesn't do right now.

So without further ado, this is my list of my top 5 things I think Microsoft should "Open Source":

1) Excel functions
I would obviously integrate them into R, make a much more powerful library, which would add and build up functionality into Excel. This would then make Excel even more useful than it already is, and allow people like me to use it for more than just simple stuff. The visual basic engine is horrible, it was never meant to write algorithms in, and so it shouldn't. Other languages do that better.


2) Powerpoint macros
Slides are quickly becoming a new hieroglyphic / pictorial-based written language to business folks, just as "early" languages mostly started from simple graphics. But Powerpoint should have a way to make these graphics "go meta" so that scripting could be done easily and more natively. I have tried doing this with Visual Basic, and it feels a lot like what happens when you fall off a motorcycle while not wearing protective clothing, going 60 miles an hour. Only more bloody.

3) Charts and graphs
If Microsoft doesn't make their engine available to do this, and use and import from other graphing platforms more easily, other people are going to do it for them. And then they'll be sad. There's so much potential here, and they ought to be web-postable in normal formats, not stupid .NET ridiculousness. Earth to Microsoft. Your dream of owning the enterprise business web never happened, and the world got over how insanely difficult your code was to post on the web, and did something about it. It's called Ruby on Rails. Look at how easy this is compared to your .NET obfuscation here. 5 minutes for Rails vs. I don't even know where to begin for .NET.

4) Microsoft Word doc format
I use the outline feature all the time, and the truth is, I'd love to be able to use .doc to txt converters for all my own files without having to venture into some insane XML format parser or pay $60 for some shareware app that doesn't even work on Linux. I just want a straight .doc to text converter. C or Perl script. Simple.

5) Access data files
I'd argue Microsoft already missed the boat on this one. On the one end, you've got FileMaker Pro spinning circles around Access, and on the other database hand you've got MySQL doing a much better job. So what's left? A mediocre combination of the worst of both worlds. If you don't Open a reasonable, Perl-like interface to Access files, you can kiss the entire tool goodbye. I know a lot of coders, and I don't know a single one that uses Access any more. Period.



I've said my piece. Like I said, I don't make a habit out of ranting, especially not about software, but I couldn't contain myself. Now back to hacking open hardware...



Carbon Fiber meets the LCDash
2010-08-24T17:11:00.000-07:00
I don't know how many of these I'll be able to do, but every time someone install one of the LCDash's into their cars, I get pretty excited. The LCDash was a project a long time ago to control the MegaSquirt. And here's what it looks like in a real dashboard, surrounded by custom made carbon fiber - you can see it in the middle of the central dashboard, with the blue backlight effect:



 There's some more discussion about it over here on the teamsolo.net forum.


This may get the award for the coolest looking LCDash installation I've seen yet (on the web of course).




Arduino meets Sniper Training
2010-08-21T18:21:00.000-07:00
Maybe I've been watching too many movies featured old guys past their prime shooting at evil faux-communist puppets ruled by evil capitalistic interests. Or maybe I haven't been watching them enough :-)

Anyway, Bjorn sent over a few weeks ago some really cool cases that he built for the Arduino, and one of them was camouflage. The second I saw the case, I had the same idea that anyone would normally have, when they see a smooth, camo Arduino case... time to make a sniper training ballistics tracking app for the Arduino.




So I did some research, and learned that there are actually a number of different, and sometimes conflicting theories about how sniper's should train, and how much thought to put into ballistics tracking. As an aside, I really want to go to the GPS Sniper Training School - I am not in any way endorsed by them, but it looks fun. It didn't take long for me to get in over my head, and then I figured, that probably the most helpful app I could write, would be one that helped me calculate spread, grouping density, and cluster metrics for accuracy training.

I really liked the look of this target, inspired by the Aguilar training system:

So I decided to program it into the TouchShield Slide:


The app is pretty straightforward, it lets me keep track of the shots I take, and then I can do analytics and measurement stats on the Open SciCal calculator. This is a pretty sure-fire guaranteed way to look like the biggest nerd at any firing range across America.


It took me less than 15 minutes to write that code for the Arduino and TouchShield Slide, and I had a lot of help using the function reference over here at the liquidware wiki. The functions are all inspired by the Processing programming language, so it's intuitive to pick up if you've ever written graphics for Processing.

And then I went to the shooting range, and set up at the prone position station, with the Open SciCal, and the Arduino Sniper Bullet Tracker gadget:

Here's the source code for the program (it's available at the Open Source "App Store" too):


int q;
int bulletx[30];
int bullety[30];
POINT npoint;
int debounce;

void draw_sight(void){
  background(0,0,0);    stroke(128,128,128);   fill(0,0,0);

  rect(5,5,40,25);   text("New",7,12);

  rect(5,210,40,25);   text("Clear",7,217);

  noFill();   ellipse(199,120,120,119);
  ellipse(199,120,100,100);
  ellipse(199,120,80,80);
  ellipse(199,120,60,60);
  ellipse(199,120,40,40);   fill(0,0,0);
}


void setup()
{
  q = 0;   draw_sight();   debounce = 1;
}


void loop()
{
 if(touch_getCursor(&npoint)) {
 
 if (npoint.x > 5 && npoint.x <> 220 && npoint.y < q="0;"> 5 && npoint.x <> 5 && npoint.y < debounce="1;" q ="="" q =" 0;"> 60) {
   draw_sight();    debounce = 0;
 }

 if(npoint.x > 60) {
   bulletx[q] = npoint.x;    bullety[q] = npoint.y;
 }

 fill(200,0,0);
 noStroke();
 for ( int j = 0; j <= q; j++) {         if (bulletx[j]>40) {
     ellipse(bulletx[j],bullety[j],5,5);
   }
 }

 }
 
}


Here are a couple videos:






I uploaded some other pictures onto my Flickr page... in case anyone's interested.

I also put all the parts I used together into a kit, called the Arduino Field Gadget.

Enjoy!



How to make a BeagleBoard Wardriving Gadget
2010-08-20T01:38:00.000-07:00


War driving is fun. It is the process of driving around the neighborhood in a car, FBI van, or bicycle, looking for unsecured wifi networks, and then checking out what might be on those networks. There are plenty of legitimate reasons to do this, for instance:
Checking a company's various office locations to make sure that the wifi networks are secured
Making sure that someone hasn't set up a rogue wifi router where don't expect one to be
Demonstrating to friends and family why it is important to secure a wifi router with with passwords

But more often than not, there are slightly less legitimate reasons, including:
Finding places to park where you can get free wifi to send emails or visit websites without being tracked
Find wifi networks that are fun to hack around, and see what types of services are available
Snoop traffic to watch people type in AOL instant messenger conversations to each other when they should definitely be working
Note: On the record, I have nneeeeeever done any of these things. Neeeeeeeever. Not me, nope. Nada.








So without further ado, here's how to make a BeagleBoard-Based Wardriving Gadget... the parts that I used for mine were:
BeagleBoard
BeagleTouch
BeagleJuice plus standoffs
BeagleJuice Power Splitter (handmade)
Small 5V USB hub from the Beagle Accessory Pack
Compatible Wifi Module
3 pieces of black electrical tape
Many of these parts are available in one kit. The BeagleJuice forked splitter basically just took the power cable from the USB hub, and spliced it nicely into the BeagleJuice power cable. This is what it looks like, compared to the basic BeagleJuice power cable:


Beautiful hand writing! Why thank you. No problem! My pleasure! It's way too late... I need sleep...


There really wasn't much to do, but in case it isn't obvious from the pictures, it was mostly just mechanical snap assembly:
I put the BeagleTouch onto the BeagleBoard
I mounted the BeagleJuice onto the back of the BeagleBoard
I wished I had done it in the opposite order, since the standoff screws would have been easier to mount if I had put them on the BeagleBoard-BeagleJuice first
I plugged the BeagleJuice Power Splitter into the BeagleBoard
I plugged the other end of the BeagleJuice Power Splitter into the USB hub
I plugged in the compatible wifi module into the end of the USB hub
Then I used electrical tape to connect everything together
When everything was mechanically connected, and assembled, the software was pretty straightforward... I used Kismet, which need a few extra packages to be installed, but these commands work start to finish:


$ wget http://www.kismetwireless.net/code/kismet-2010-07-R1.tar.gz
$ tar -xvf kismet-2010-07-R1.tar.gz
$ opkg install ncurses-dev libpcre-dev libpcap-dev libnl-dev
$ cd kismet-2010-07-R1
$ ./configure
$ make dep
$ make
$ make install


Then to get kismet up and running, I needed to first get wlan0, the wifi module operating and turned on, and then I just ran kismet:


$ ifup wlan0
$ kismet -c wlan0


The instructions are also on the Antipasto Wiki over here. Here's a video of me showing it off:





And here's a set of videos I took while walking around outside an abandoned office building very late at night (aka 2 hours ago)... you can see a bunch of wifi networks popped up:











I uploaded a few other pictures onto the Flickr page, and of course all the parts and source code is over at the Liquidware shop...


How to program the BeagleBoard
2010-08-16T17:27:00.001-07:00
I've gotten a lot of questions over the past couple of weeks of people asking me, "how do I program the BeagleBoard?" It's not that silly of a question, actually, and it reminds me that I once asked this question too, only a couple of months ago.

The answer is: you don't! The BeagleBoard programs you! (just kidding, this isn't Russia)

In all seriousness, the BeagleBoard isn't like the Arduino, in that it doesn't have an IDE program that sits on the desktop and communicates with the board. Instead, all of its files exist on an SD card.

The BeagleBoard SD card is the easiest way to get programs and files on and off of the BeagleBoard. Just popthe SD card out of the BeagleBoard, pop it into a multi-card SD reader, plug the reader into the desktop USB port, and then copy files onto the SD card that you want to make available to the BeagleBoard.

Ok, here's a step-by-step guide:

Step 1: Turn BeagleBoard on it's side

In my case, I always leave the BeagleTouch on the front side of the BeagleBoard, so it can display graphics and the Linux OS on the screen.


Step 2: Locate the SD Card in the BeagleBoard

Every BeagleBoard is operated with software that is loaded on an SD card. This is different than the Arduino, because the Arduino stores all of it's data in a small area of Flash memory on the Atmel chip. The Atmel has something like 128-256K of space. The BeagleBoard SD card that I use (and sell pre-programmed) has 4 gigabytes of space. That's a huge difference...



Step 3: Remove SD Card from the BeagleBoard

This is not a very hard step:


Step 4: Plug SD Card into SD Card Reader

I use a Sony or Ultra one, only because I like the brushed silver / aluminum look.


Step 5: Plug SD Card Reader into PC

Using a USB cable that came with the reader:


Step 6: Copy Files to the SD Card

This is the hardest part of the whole thing, which isn't saying much. Basically it's really easy. You copy the files from your computer onto the SD card.

On Windows, it looks like this:

On Linux (and MacOS X), it looks like this:


Step 7: Install an Ext2 Partition Reader on Windows

Windows users have one extra step. The SD Card that runs the BeagleBoard has two partitions on it. One of those partitions is formatted in "vfat" which is the native format that Windows can read. This is the partition that stores the boot-up data.

The second partition is in a format called "ext2". That partition is where you want to copy the files on to the BeagleBoard. I'm not going to try to recount an explanation of ext2 here, but instead, there's a really good, easy read about it on wikipedia here. Here's the catch: Windows 7 can't read "ext2" out of the box, so you need a program to access the partition.

So to access ext2 on Windows 7, in theory, you have 3 options: Install Explore2fs (open source, free) from here, Install Diskinternals (freeware) from here, Install "Installable Ext2 File System for Windows" (freeware) from here.

I've only ever gotten it to work by following these instructions for the "Installable Ext2 File System for Windows". Here's a tutorial on how to get that working.

After you've installed one of those programs, you can now access the ext2 partition, and copy data to and from it.


How to make a BeagleBoard MP3 Player
2010-08-09T20:07:00.000-07:00
I was looking around at some comments and articles about the BeagleTouch-based Linux Tablet, and I noticed that there were a few people that mentioned that a Linux-based Open Source hardware tablet is the antithesis, arch-nemesis, ying vs. Apple's yang. While Apple is super secret, closed source, proprietary, and hidden, a Linux OSHW tablet is transparent, hackable, open source, and visible.


PS... I don't think this title is long enough, I think it should be, "How to make a DIY Open Source Hardware Beagle Board and Open Source Angstrom Linux Software MP3 Media Player in 10 Minutes Or Less with 5 Easy Steps and 6 Easy Payments of $9.99" Ha.


Sooo....


I figured I'd take that metaphor to the extreme, and make a quick tutorial about making a super-overkill, overqualified Open Source Hardware MP3 player, called the "Anti-iPod". Naturally, the best part about this MP3 player, is that it actually plays MP3's, not weirdly-encoded, proprietarily-coded music format with DRM protection. The second best thing about this MP3 player is that no one will ever try to make it a criminal offense to hack into it...

Closed:


Open:



Step 1: Assemble a Beagle-board based Gadget


Probably using something like this or like this, I just snapped a BeagleTouch onto the Beagleboard, plugged in power, and connected a USB cable from the BeagleTouch to my computer. This is what I call a Beagle Gadget Sandwich (BGS):



Step 2: Connect it to the Internet

Either with a wifi module (as I wrote up in these instructions or over here), or an ethernet module like this one.


Step 3: Download and run the install script



$ wget http://www.liquidware.com/appfiles/83/original/linux-ts-mediaplayer-1.0.sh 
$ chmod 777 ./linux-ts-mediaplayer-1.0.sh
$ ./linux-ts-mediaplayer-1.0.sh



Step 4: Pirate music

From your own collection, OBVIOUSLY.


Then save it to the home directory, in the /home/root/Music folder. You may need to "mkdir Music" from the home directory just to make sure the directory is there.

Step 5: Launch the MP3 Player

Then, start up the MP3 player application, with skins, and exported to the display, with these commands:



$ export DISPLAY=:0.0
$ vlc -I skins2 --skins2-last  /home/root/Night.vlt ./Music


It should look like this:




Done!


Turning the Open SciCal into a handheld hedge fund tool
2010-08-08T23:26:00.000-07:00
Shortly after the handheld Open SciCal got picked up, I got an order for a few Open SciCal's, hand-made, with the wifi-attachment, and to be delivered to an address in downtown Manhattan. I did a little more research, and it turns out that they're going to be used by an actual trading firm on Wallstreet. I don't know how to verify this, but it may be one of the first documented cases of a super-secret Wallstreet firm actually using Open Source Hardware.


I also got a handful of emails from people asking what on earth stock auto-correlation is, and why it's interesting. Although I'm not a professional trader, I emailed a couple of old friends of mine who are programmers at quantitative finance trading firms, and this is probably the simplest explanation I got back:


"Correlation is a popular tool for hedge funds, because it tells you whether the returns from one stock are closely linked to the returns of an industry or another stock. Auto-correlation is when you compare the returns of one stock on a given day, with it's historical returns 1, 2, 3, ... n seconds, minutes, days. weeks into the future. It helps you determine whether the stock's performance at one time can predict it's performance at some time in the future, or vice versa."


I asked for an example in source code, and here it is - very simplified, and coded up for Yahoo finance, and posted on the "Open Source App Store". This is what it does:


Uses the Wifi Module to connect to the internet
Take a stock ticker, send it to Yahoo Finance's CSV downloader
Download it to R, save it to an array
Calculate percent change in price figures (returns) for each pair of consecutive days 
Run 1-10 day auto-correlations of the stock against itself
Kick out a simple little line chart showing the auto-correlation profile
To use it, I just opened R on the Open SciCal, and typed:

source("http://www.liquidware.com/appfiles/85/original/handheldhedgefund.txt");
stockacf("YHOO");

Now the obvious disclaimer: if you use this Open Source program, using free data from Yahoo Finance, on the Open Source Hardware calculator, and find that you lose a lot of money... you can't complain that anyone hid any part of this, since literally everything was open or free along the way. At least this way, you can see the entire inner workings of how you're gambling, as opposed to what might happen at a casino or in Las Vegas, where they do everything possible to hide the fact.

Here's a picture of Apple's stock price, on the Open SciCal: 



It looks a lot like the actual Apple stock price from Yahoo, except revered in time series order:




And then here's the result of the auto-correlation algorithm with a couple different stocks (I have it repeating with Apple AAPL, Texas Instruments TXN, Yahoo YHOO, and Google GOOG):






And this would technically let someone just walk around a building, running stock return auto-correlations in their hands, presumably downloading data from a more reliable and faster updating source than just Yahoo finance, and actually making big trades as a result.


Here's a full video:


 
And another, longer one:





Alright, now that that's out of my system, time to get back to hacking with a few of the new sensors Justin and Mike have been working on...


 






Thanks!
2010-08-06T01:34:00.000-07:00
I just finished writing emails back to everyone who emailed in ideas and suggestions for how I could improve the Open SciCal, and questions about the hardware. Over the next couple days, I have a LOT of projects to work on, and a lot of examples... I don't know how I'm going to sleep, there's so much to do... and it's already 4:40 am as I write this, and I haven't slept a bit.

But first, before I start those projects, I really wanted to thank the folks at Wired, Gizmodo, and Make for giving the Open SciCal so many hits and so much attention... it was so much, in fact, that the poor little server that hosts Liquidware slowed down to a halt with all the pagehits, and had to be rebooted.

I certainly learned a decent amount about server uptime and cache overflow errors.

Most importantly, though, I have a notebook now, filled with requests, ideas, programs people would like to see running on it, hacks for the hardware, etc. That's the fun part of Open Source - I probably wouldn't have come up with a fraction of that on my own, and now Will, Chris, Justin, Mike, John, and I are going to have a blast writing all these features into the app software and giving them back as improvements to the Open SciCal.

Thanks again...



Now I feel I need to comment on that last one... Nerd Excalibur. Ok, that's pretty funny... so I typed "nerd excalibur" into Google images to see what I'd find, and this was the first picture:

"Aye, program in TI-BASIC and you my die before your app finishes. Use R and you'll live... to see another function. And dying in your beds, many years from now, would you be willing to trade ALL the transcendental functions, from Sine to ArcTangent, for one chance, just one chance, to come back here and tell other  calculators that they may take our math functions, but they'll never take... OUR SOURCE CODE!"

Insert rowdy adrenaline cheers from face painted hardware hackers and electrical engineers...

I could live with that I guess :-)


Using the Open Source Graphing Calculator to predict sunspots
2010-08-03T16:59:00.000-07:00
With all this talk about solar plasma aurora storms, sunspots, I thought this would be an excellent opportunity to show off the Open Source Graphing Calculator's capabilities. Believe me, this is just scratching the surface...

First, I googled around, and read this article at theregister and this one at the examiner. Naturally, there was a big, ominous sun picture :-)

Scary! Here's a video of the class C3 solar flare happening in real time:



Naturally, after reading that article, I thought to myself, "I wonder what the statistical significance of this event is, and what the probability and co-occurrence bi-frequency distribution and temporal periodicity squared coefficient might be?"

I opened up my trusty iPhone... and... NO APP FOR THAT!!! What now, Steve Jobs, what now?!?! Oh no...! a mathematical question that deserves an answer, but didn't raise enough VC funding to make a bloated iPhone app that answers a simple question, but with slide-show effects, really pretty jelly buttons, and 3D shadows underneath it!


Luckily, as any good astro-physicist or geoscientist would tell you, one of the most famous data sets in the world is the Wolfer Sunspot Series, which is practically a rite of passage for starving astro-physics PhD students worldwide, and a great way to get published.

Thanks to Gareth Janacek, and his collection of data series, I was able to find the Wolfer data quickly, and used wget to pull it down to my calculator.

wget http://www.uea.ac.uk/~gj/book/data/wolfer.dat

Quite simple. Then I booted up R using a little script that I have automatically load when my calculator boots It basically runs this command:

export DISPLAY=:0.0
xterm -bg black -fg green -bw 0 -e 'R'


When R was running with the Matrix color theme, I then imported the data into a matrix (which is somehow nicely recursive):


Then I ran a command that launched up a little graphic:

dev.new(width=5,height=2.5);
par(mar=c(0,0,0,0),oma=c(2,2,2,2),bg="black);
plot(c(1:length(x)),x,type="l",col="white");
box("plot",col="white")


Literally this can be copied and pasted right into the Open Source Graphing Calculator's R command line:

And voila!


My iPhone is speechless. It can only sit there, black screened, wishing there was an app for that. I mean, technically, there is a $36 app call "Helios" that has funky graphics, but it doesn't answer my question: is this a regular thing, or really statistically random?

The answer: it happens all the time, and flares tend to be cyclical on a fairly predictable manner.

Open Source Graphing Calculator: 1
iPhone / Android / Ti-82 / HP-50g: 0

:-)



Introducing the 100% Open Source HW/SW R-Based Graphing Calculator
2010-07-31T21:18:00.000-07:00
The childhood geek inside me is running, screaming, jumping around with joy, and hacking it's way into servers it shouldn't even know about. I'm definitely totally nerding out over here, I can type this up, my fingers are jittering around so much.

I can die in peace, for the day hath cometh, wherein...


With Koen, Thom, Chris, Mark, and Will's help, I built this 100% Open Source Hardware-based, Open Source Software-based KICK ASS REPLACEMENT for my two most trusted allies in life: my TI-89 and my HP-50g scientific graphing calculators.

Don't get me wrong, the TI-89 and HP-50g are awesome. Some might argue, they're too awesome, since neither TI nor HP have been able to make a better calculator that I'd buy. And I know my calculators, so if a better one came along, I'd definitely buy it. (Just ask anyone who's ever been to the Liquidware Lab to see my calculator collection). And I'm not talking about the TI-200 "Voyage" (choke, gag), which came out around the same time the dot-coms were around, and IMHO is everything that was wrong about the dot-com era (plus the keyboard made it illegal on the SAT).

Also, there's two big problems with the TI-89 and HP-50g in my book:

1) I didn't make it myself
2) They're not open source and hackable



But this... calculator has 1,000,000 times the coolness factor of those two calculators above:

It runs Linux (HP: no, TI: no)
It runs R (HP: no, TI: no)
You program it in C or Perl (HP: no, TI: no)
It has a Wifi connection (HP: no, TI: no)
It runs a web browser (HP: no, TI: no)

The only sad part is that my scientific graphing calculator doesn't run HP's cool reverse polish programming stack which is not so much intuitive, but actually quite fun to program... especially with its list manipulations, inspired from the Forth programming language.

Oh wait. Just kidding, my calculator can run a full Forth stack using gforth, or a Fortran stack  (using gfortran)!

Here it is with a full keyboard and mouse, just for kicks... although obviously it doesn't need those because I can use the on-screen keypad because it's got a touchscreen OLED using the BeagleTouch module.


The colors got a little white-washed on this one, but it gives you an idea for the size:




The screen is plenty bright:


And here's a video showing my doing R matrix manipulations:





In my opinion, there is nothing nerdier or cooler than a pocket sized graphing and programmable scientific calculator that runs R. Nothing. Hands down. Like this is the kinda stuff that makes NSA Trekkies  jealous... bring it on! :-)

I've uploaded the Open Source R-Based Calculator it as a kit onto the Liquidware shop, as an option to the Tablet Pack, to make it come with R pre-loaded and pre-installed from Koen (I'm assuming people have their own keyboards and USB ports, otherwise I'd include those too).



Scooterputer, an Open Source Scooter Dashboard
2010-07-31T20:07:00.000-07:00
Open Source is awesome. 1 day after the announcement of the LCDash GT, and how it helps people hack car engines with MegaSquirt, comes a project from Kurt about a 100% Open Source Hardware-based computer that lets you see sensor read-outs, and realtime information connected to a scooter, which naturally make someone a better driver!




It's called the "Scooterputer" ... and it uses parts from Adafruit, Liquidware, and Sparkfun, and all the source code is open source (I uploaded it to the Open Source app store site).







Kurt used the antipasto arduino ide, which brought a tear to my eye, thinking that all those hours slaving away with Chris getting that to work was time well spent :-)



This is a custom, homebrew shield Kurt made to house and connect up all the sensors:

Kurt has a ridiculously well written tutorial on how he built everything up on his site over here... and Make blog even picked it up, and there's a funny conversation about it over at the Arduino forums.



Introducing the LCDash GT: Hacking Your Engine with Open Source Hardware
2010-07-29T21:10:00.000-07:00
Just in time for the Maker Faire Detroit, Justin, Jake and I have been working on the brand new LCDash Operating System, and hardware upgrade. This is the brand new LCDash GT. The GT edition has more memory, a faster processor, lighter-weight bootloader, a much more streamlined circuit design than the original LCDash. This means it's much more DIY-friendly, and hackable.

It's also the first time that a 100% Open Source engine controller and engine readout system has been available for people that are familiar with the OpenPort Cable, MegaSquirt EFI, or OBD2/OBDII Elm Protocol:



Each of those protocols allow you to read the output of the engine parameters, and even set them on the fly if you're using MegaSquirt. This means being able to change the fuel-oxygen-throttle mixture and fuel ratio, for either higher performance (more gas), or better gas mileage (less gas) at a given RPM of the engine.

A quick word of warning: OBDII hacking and EFI programming is a jedi art, for black-belt car guys, but there's actually a really lively, active community of hackers who have spent a bunch of time hacking their own engines using the MegaSquirt. And Justin and Chris are two such guys :-) It's amazing how much power you can pull off the line in a Mitsubishi that's been rigged up to a MegaSquirt...



Anyway, without further ado, here's an updated video that Justin made:



Here are two videos of the base LCDash in action, from timbo and MegaScott:










And here's a video that Mike made of the original (running a slower version of the OS, and green PCB representing the older schematic) connected to the MegaSquirt:




If you haven't heard of the MegaSquirt hardware project yet, it's a pretty popular platform for hacking the OBDII interface to the engine. OBDII is a protocol used by many manufacturers as an interface between the EFI and the main computer which distributes and runs the spark plugs, timing, and engine electronics based on a variety of sensor inputs (like O2, RPM, gas pedal depression, and sometimes even car angle, altitude, knock sensor, crank position, turbo boost, current speed, etc.). It's a pretty ambitious project, and can be a challenge to hack at times, having to constantly go back and forth between a PC, and the MegaSquirt, and reprogramming the Arduino. The LCDash GT presents a touch-screen interface that makes it really easy to see what the MegaSquirt is doing, and adjust ratios on the fly (e.g. at an autotuner, or dyno station).

For instance, here's a video by Danny showing the MegaSquirt hooked up to a laptop, the same way it would be hooked up to the LCDash:




The MegaSquirt basically let's you do crazy things (that are of obvious questionable benefit, but definitely cool) to a car's engine, like make it have sputtering launch control:








Here's a link to the MSruns forum of people that have hacked their cars using the MegaSquirt, for instance...
Justin just loaded the LCDash up on the shop, and it's available as a kit, or as a fully assembled version at the Liquidware Shop.


I'm headed to Maker Faire Detroit!
2010-07-28T18:50:00.000-07:00
This coming Saturday and Sunday are going to be pretty action packed for me... I'm driving from Boston to Detroit with Mike to go to Maker Faire. Talk about a long drive, but we're going to celebrate in style by listening to the new Eminem CD. Normally I wouldn't listen to his music, but I figured I'd try to get in the mood, so why not?


Maker Faire Detroit 2010 is taking place this Saturday from 9:30 am to 8:00 pm, and Sunday from 9:30 am to 5:00 pm, at the Henry Ford museum. This is cool on a number a levels, I think. Firstly, Henry Ford is to the Detroit auto crowd, as Eli Whitney was to the Northeast: an inventor who kick-started an entire industrial revolution.


That's inspirational to me... and Mike too, he's been talking about how badly he's wanted to go to the Ford museum ever since he was a kid. He and I are both pretty big into cars (if you've ever visited the Liquidware lab, you know that this is true!).


Anyway, here are some of the promotional pictures... please let me know if you want me to bring any special projects along with me to show you...






If you already emailed me, I'm looking forward to seeing you... and if you want to carpool, just let me know...


The Death & Rebirth of an American Geek Calculator
2010-07-27T14:42:00.000-07:00
The year: 1995. I’m in middle school. I have two calculators, TI-82’s to be precise. Why 2? Because on math tests and quizzes, I found that using Solve() was so slow that I’d start one on a problem, and then use the other while the first got the answer. Calculator-based multitasking in its truest form. The more calculators you had, the nerdier you were. Alpha-nerd, and nerd-cred if you will. It wasn’t just me, I was passing on a long generation of calculator-based nerd credibility:

Something has gone horribly wrong. Fast-forward to the epilogue future-present. The world according to my middle school dreams was supposed to be filled with calculators, and super-man-geeks and “not-men” (aka !men, or "women") were supposed to be walking around, carrying calculators, wearing super calculator watches.

Bling. Bling.

I used to have a tactical vest that I'd wear while programming in high school. Except instead of guns and ammo, my weapons were Sine, Cosine, and Arctangent. Full, semi-automatic Cot()-.45 degree Artangent, nevermind you. I used to use the vest to hold my TI and HP calculators. I dreamed of the day when I'd carry around a brushed titanium briefcase filled with top-secret, uber-hacker calculators for cracking crypto hash algorithms.

But alas, that future never came to be...

In the past few days of revelry while I’ve used my R-based scientific calculator, I’ve come to realize something. This is the first time in years that I’ve actually carried around a calculator again. It got me thinking… and I started to look around as I walked through Boston. No one carries calculators any more!

The calculator, as it turns out, is a casualty of convergence. In other words, the calculator got “OJ Simpsoned” … if it doesn’t fit (in your assortment of devices), you must acquit (and stick it in a box of old gadgets).



The next generation calculator device, and the calc-based society of the future I always dreamed about, never came about. This is why I think that never happened: at the low end, calculators have been absorbed into handheld phones. Blackberry, iPhone, Android devices all have apps that replicate the features of calculators, so why carry around a calculator anymore? At the high end, calculators didn’t have enough RAM or dataspace memory to prove themselves useful or capable as data analysis needs grew. Furthermore calculators were quite a pain to transfer data on and off of, so people just used computers with Excel, Matlab, Mathematica and R. The calculator just got squeezed out.



I collect calculators like some guys collect vinyl records and model trains. It’s a hobby, and it used to be an obsession. But ever since I went on my first date, it’s kinda gone away, sadly. Well, the girlfriend part wasn’t sad, but the diminished level of calculator collecting was.
 
It is very telling when you find a hobby of yours starts to pop up in museums and historical archives. That means you’re old:


It's even worse when there's a history paper written about it:


 
But something has changed, and I’m determined to figure out what happened. Since Koen helped me get R running on the BeagleBoard, I’ve been carrying my newfangled scientific programming open source calculator around with me, proudly, and finding reasons to pull it out and get R running. It’s wonderful, inspiring, and totally contagiously nerding out anyone who asks me about it, sort of like a virus spreading and zombifying people in an underground lab ... like these guys did:


I think calculators need to be re-invented, and I think I’ve stumbled on at least part of the equation. The Beagleboard / BeagleTouch – based R calculator is much more than “just a calculator”. It’s a hacker / calculator nerd’s (me) dream come true. It provides exactly what I need: a way to compute randomly sampled arrays, parallel compute transposed lists on the fly.
Instead of calculating the tip at the end of a meal, I can use this thing to calculate tips for the entire freakin’ restaurant!

In the words of Kirsten Dunst: Bring it on.

Naturally, she was referring to the re-invention and rebirth of the Great American Geek Calculator!


Naturally.



BeagleTouch meets Makerbot
2010-07-26T16:36:00.000-07:00
By now, almost everyone's heard of the Makerbot, it's a DIY 3D printing system made by the guys down in NYC (mostly notably, Bre Pettis, who Chris, Matt, and I met down in NYC a little while ago - and who we also met again at the San Mateo Maker Fair):





Anyway, while Koen was hacking away on the solution to getting R up and running on the BeagleBoard, he built a coaster, which happens to hold the BeagleBoard quite nicely, and also looks pretty slick with the BeagleTouch:





So without further ado, here's Koen's picture:



Pretty nifty... although I haven't tried my hand at running a Makerbot myself yet, this is definitely some solid inspiration... Justin has one in the back room, and maybe now it's time to play with it? :-)




R runs on the Beagleboad & BeagleTouch!
2010-07-25T20:07:00.000-07:00
On Wednesday, in the library, Chris and I talked about how impossible it would be to port R to the Beagleboard platform, given all the insane dependencies on obscure libraries, some java based, some fortran based, you name it.

On Thursday, I read Karim's most recent article with Ned Gulley called, "The Determinants of Individual Performance and Collective Value in Private-Collective Software Innovation". Naturally, this wasn't a wiki-like contest, but there sure was plenty of reuse (R is an established platform), code recombination (Chris + Will + Koen + Mine). In this case, however, I suppose you could say the goal was to increase the "free-rider" problem. That, or I just think it's cool to have a portable R-based gadget. :-)

Ps, totally random aside, this graph is awesome, it proves that multiple people working together for a common good get a lot farther than any one person by themselves (obviously this is true, but this is quantitative, numerical evidence):


On Friday, I posted a quick blog article about porting R to the Beagle & Angstrom platform. Chris thought it would be very difficult, I thought it would be impossible, and so I offered $1,000 to anyone that could help.


On Saturday, I got about a dozen emails, and 3 folks who said they were going to try (4 if you include me, since I figured maybe I could do it after all).

On Sunday, I got an email from Koen with the following picture, and code screenshot printout:


Total elapsed time since blog post: less than 36 hours

Naturally, I wanted to make sure I could replicate it myself, and so I was able to run the following commands on the BeagleBoard (with a wifi internet connection up and running):



wget http://www.liquidware.org/r_2.11.1-r0.5_armv7a.ipk

opkg install http://www.angstrom-distribution.org/feeds/2008/ipk/glibc/armv7a/base/tk-dev_8.4.19-r0.1_armv7a.ipk

opkg install http://www.angstrom-distribution.org/feeds/2008/ipk/glibc/armv7a/base/gfortran_4.3.1-r11.1_armv7a.ipk

opkg update

opkg upgrade

reboot

opkg install -force-depends ./r_2.11.1-r0.5_armv7a.ipk

opkg bash



And then I popped it up, and got this:


2shay, Koen :-)


UPDATE: I just Googled around, and there was apparently also another possible solution, cooked up by HNS, although technically not doable with Angstrom (which is critical given some of the drivers and whatnot I've patched into my version of Angstrom), it gets R up and running with Debian:

---Copied from the mailing list---

Does this qualify as well?

Install Debian Lenny, u-boot and a kernel on a SD card from

http://download.goldelico.com/ombeagle/20100715-lenny/

boot and login. Make sure the host works as a internet router.

Linux bb-debian 2.6.32 #48 PREEMPT Tue Jun 8 14:21:52 CEST 2010 armv7l

The programs included with the Debian GNU/Linux system are free
software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Jul 23 12:48:05 2010 from 192.168.0.200
bb-debian:~# apt-get install r-base
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  libgfortran3 libpaper-utils libpaper1 r-base-core r-cran-boot r-cran-
cluster r-cran-codetools r-cran-foreign r-cran-kernsmooth r-cran-
lattice r-cran-mgcv r-cran-nlme r-cran-rpart r-cran-survival r-cran-vr
r-recommended tk8.4
  unzip zip
Suggested packages:
  ess r-doc-info r-doc-pdf r-doc-html r-mathlib
Recommended packages:
  r-base-html r-base-latex r-base-dev
The following NEW packages will be installed:
  libgfortran3 libpaper-utils libpaper1 r-base r-base-core r-cran-boot
r-cran-cluster r-cran-codetools r-cran-foreign r-cran-kernsmooth r-
cran-lattice r-cran-mgcv r-cran-nlme r-cran-rpart r-cran-survival r-
cran-vr r-recommended
  tk8.4 unzip zip
0 upgraded, 20 newly installed, 0 to remove and 1 not upgraded.
Need to get 18.2MB of archives.
After this operation, 64.3MB of additional disk space will be used.
Do you want to continue [Y/n]? y
Get:1 http://ftp.de.debian.org stable/main libgfortran3 4.3.2-1.1 [211kB]
Get:2 http://ftp.de.debian.org stable/main libpaper1 1.1.23+nmu1 [21.9kB]
Get:3 http://ftp.de.debian.org stable/main libpaper-utils 1.1.23+nmu1 [18.3kB]
Get:4 http://ftp.de.debian.org stable/main zip 2.32-1 [110kB]
Get:5 http://ftp.de.debian.org stable/main unzip 5.52-12 [163kB]
Get:6 http://ftp.de.debian.org stable/main tk8.4 8.4.19-2 [1022kB]
Get:7 http://ftp.de.debian.org stable/main r-base-core 2.7.1-1+lenny1 [11.0MB]
Get:8 http://ftp.de.debian.org stable/main r-cran-boot 1.2.33-1 [458kB]
Get:9 http://ftp.de.debian.org stable/main r-cran-cluster 1.11.11-1 [343kB]
Get:10 http://ftp.de.debian.org stable/main r-cran-foreign 0.8.27-1 [154kB]
Get:11 http://ftp.de.debian.org stable/main r-cran-vr 7.2.42-1 [971kB]
Get:12 http://ftp.de.debian.org stable/main r-cran-kernsmooth 2.22.22-1 [51.7kB]
Get:13 http://ftp.de.debian.org stable/main r-cran-lattice 0.17-10-1 [598kB]
Get:14 http://ftp.de.debian.org stable/main r-cran-mgcv 1.4-1-1 [658kB]
Get:15 http://ftp.de.debian.org stable/main r-cran-nlme 3.1.89-1 [1346kB]
Get:16 http://ftp.de.debian.org stable/main r-cran-survival 2.34-1-1 [833kB]
Get:17 http://ftp.de.debian.org stable/main r-cran-rpart 3.1.41-1 [160kB]
Get:18 http://ftp.de.debian.org stable/main r-cran-codetools 0.2-1-1 [39.8kB]
Get:19 http://ftp.de.debian.org stable/main r-recommended 2.7.1-1+lenny1 [2208B]
Get:20 http://ftp.de.debian.org stable/main r-base 2.7.1-1+lenny1[29.7kB]

Fetched 18.2MB in 21s (842kB/ s)

debconf: delaying package configuration, since apt-utils is not installed
Selecting previously deselected package libgfortran3.
(Reading database ... 25829 files and directories currently installed.)
Unpacking libgfortran3 (from .../libgfortran3_4.3.2-1.1_armel.deb) ... Selecting previously deselected package libpaper1.
Unpacking libpaper1 (from .../libpaper1_1.1.23+nmu1_armel.deb) ... Selecting previously deselected package libpaper-utils.
Unpacking libpaper-utils (from .../libpaper- utils_1.1.23+nmu1_armel.deb) ...
Selecting previously deselected package zip.
Unpacking zip (from .../archives/zip_2.32-1_armel.deb) ...
Selecting previously deselected package unzip.
Unpacking unzip (from .../unzip_5.52-12_armel.deb) ...
Selecting previously deselected package tk8.4.
Unpacking tk8.4 (from .../tk8.4_8.4.19-2_armel.deb) ...
Selecting previously deselected package r-base-core.
Unpacking r-base-core (from .../r-base-
core_2.7.1-1+lenny1_armel.deb) ...
Selecting previously deselected package r-cran-boot.
Unpacking r-cran-boot (from .../r-cran-boot_1.2.33-1_all.deb) ...
Selecting previously deselected package r-cran-cluster.
Unpacking r-cran-cluster (from .../r-cran-
cluster_1.11.11-1_armel.deb) ...
Selecting previously deselected package r-cran-foreign.
Unpacking r-cran-foreign (from .../r-cran-
foreign_0.8.27-1_armel.deb) ...
Selecting previously deselected package r-cran-vr.
Unpacking r-cran-vr (from .../r-cran-vr_7.2.42-1_armel.deb) ...
Selecting previously deselected package r-cran-kernsmooth.
Unpacking r-cran-kernsmooth (from .../r-cran-
kernsmooth_2.22.22-1_armel.deb) ...
Selecting previously deselected package r-cran-lattice.
Unpacking r-cran-lattice (from .../r-cran-
lattice_0.17-10-1_armel.deb) ...
Selecting previously deselected package r-cran-mgcv.
Unpacking r-cran-mgcv (from .../r-cran-mgcv_1.4-1-1_armel.deb) ...
Selecting previously deselected package r-cran-nlme.
Unpacking r-cran-nlme (from .../r-cran-nlme_3.1.89-1_armel.deb) ...
Selecting previously deselected package r-cran-survival.
Unpacking r-cran-survival (from .../r-cran-
survival_2.34-1-1_armel.deb) ...
Selecting previously deselected package r-cran-rpart.
Unpacking r-cran-rpart (from .../r-cran-rpart_3.1.41-1_armel.deb) ...
Selecting previously deselected package r-cran-codetools.
Unpacking r-cran-codetools (from .../r-cran-
codetools_0.2-1-1_all.deb) ...
Selecting previously deselected package r-recommended.
Unpacking r-recommended (from .../r-
recommended_2.7.1-1+lenny1_all.deb) ...
Selecting previously deselected package r-base.
Unpacking r-base (from .../r-base_2.7.1-1+lenny1_all.deb) ...
Setting up libgfortran3 (4.3.2-1.1) ...
Setting up libpaper1 (1.1.23+nmu1) ...

Creating config file /etc/papersize with new version
Setting up libpaper-utils (1.1.23+nmu1) ...
Setting up zip (2.32-1) ...
Setting up unzip (5.52-12) ...
Setting up tk8.4 (8.4.19-2) ...
Setting up r-base-core (2.7.1-1+lenny1) ...
Setting R_PAPERSIZE_USER default to 'a4'

Creating config file /etc/R/Renviron with new version
Setting up r-cran-boot (1.2.33-1) ...
Setting up r-cran-cluster (1.11.11-1) ...
Setting up r-cran-foreign (0.8.27-1) ...
Setting up r-cran-vr (7.2.42-1) ...
Setting up r-cran-kernsmooth (2.22.22-1) ...
Setting up r-cran-lattice (0.17-10-1) ...
Setting up r-cran-mgcv (1.4-1-1) ...
Setting up r-cran-nlme (3.1.89-1) ...
Setting up r-cran-survival (2.34-1-1) ...
Setting up r-cran-rpart (3.1.41-1) ...
Setting up r-cran-codetools (0.2-1-1) ...
Setting up r-recommended (2.7.1-1+lenny1) ...
Setting up r-base (2.7.1-1+lenny1) ...
bb-debian:~# R

R version 2.7.1 (2008-06-23)
Copyright (C) 2008 The R Foundation for Statistical Computing
ISBN 3-900051-07-0

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> x <- c(10.4, 5.6, 3.1, 6.4, 21.7)
> y <- c(x, 0, x)
> 1/x

[1] 0.09615385 0.17857143 0.32258065 0.15625000 0.04608295
> q()

Save workspace image? [y/n/c]: n
bb-debian:~# uname -a
Linux bb-debian 2.6.32 #48 PREEMPT Tue Jun 8 14:21:52 CEST 2010 armv7l
GNU/Linux
bb-debian:~# cat /proc/cpu
cat: /proc/cpu: Is a directory
bb-debian:~# cat /proc/cpuinfo
Processor       : ARMv7 Processor rev 3 (v7l)
BogoMIPS        : 696.20
Features        : swp half thumb fastmult vfp edsp thumbee neon vfpv3
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x1
CPU part        : 0xc08
CPU revision    : 3

Hardware        : OMAP3 Beagle Board
Revision        : 0020
Serial          : 0000000000000000
bb-debian:~#




How to make a Linux Beagleboard Gadget Wifi-enabled
2010-07-25T12:47:00.000-07:00
It's been a busy past few weeks, but thanks to Chris and Will, the Beagle Gadget using the BeagleBoard and the BeagleTouch, can now use Wifi - and it's seriously fast! This means that this is the first official Beagleboard-based wireless handheld Linux device... that's a lot of buzzy words, ha. 

    
Here's a video of the Beagle Gadget communicating over wireless... and... browsing the web using ... drum roll ... Firefox. That's crazy. I remember the days when I was lucky to get a serial communication link going on my PalmOS Treo handheld, let alone wifi. But suffice to say, here it is, actually working:

                                      
Here's how I was able to do it:

                                      
Step 1: Format the SD card 
I followed the instructions here, and made a formatted BeagleBoard SD card with the updated OS that include the kernel module to get WIFI working.
                                      
For the more hackerishly inclined, here's a direct link to the kernel image and to the rootfs image. 
For reference, these links are also at the bottom of the BeagleBoard page :
 
Step 2: Attach the USB ethernet module
I used this USB Wifi module, so at least if you have this one, you're guaranteed to work... 
I took it out of the case by cracking it open with a screw driver - not because it added anything, but just because it looks a lot cooler that way.
I plugged it into the small USB hub, but only because I also wanted to plug in a USB mouse and mini keyboard. Otherwise there wasn't really any particularly good reason to use the USB hub - I could have plugged the USB wifi module directly into the Beagle Board.
 
 
Step 3: Configure the wifi settings 
There are also some more detailed instructions on the wiki for this next step...  
Once it was plugged in, and Linux was booted up, I edited the file at /etc/wpa_supplicant/wpa-supplicant.conf. This file contains the parameters for the wifi adapter module, and mine looks something like this:
ap_scan=1
ctrl_interface=/var/run/wpa_supplicant
 
network={
ssid="<your ssid here>"
scan_ssid=0
proto=WPA
key_mgmt=WPA-PSK
psk="<your password here>"
pairwise=TKIP
group=TKIP
}

Step 4: Turn on wifi

This is the easiest step of all... simply issue this command:

$ ifup wlan0

And then issue this command:

$ ping www.liquidware.com
or
$ ping www.apple.com

Viola! 

PS. If you're super lazy, I've put all the parts together in a big kit here and here.

And here's another video showing off Firefox actually browsing on the Beagleboard Linux Gadget:
 




Open Source Hardware Summit: OSHW Definition & License
2010-07-23T22:53:00.000-07:00
Like so many things in the Open Source World, concepts are defined by the community, the group, and the practitioners of a concept.

Open Source Hardware is an ideal, that many people have come to shape and grow.

Just recently, there's been a huge amount of energy put into building a common set of terms about what "Open Source Hardware" is, so that a license can be built. There have been fits and starts over the years, and even a recent attempt to try to find a way for the Free Software Foundation, and the Creative Commons to extend their licenses to include hardware... but they were ultimately unsuccessful.

Part of the reason they weren't successful, is because there's something kind of ironic with the idea of creating a license, which is usually meant to protect *against* something, for a set of schematic files which you're intentionally *giving away*.

But!

The first step, of course, is to at least agree about what Open Source Hardware actually is, because it's not that straight forward. So on September 23rd, later this year, a bunch of guys I know from Boston are going to head down to NYC to attend:

The Open Source Hardware Summit
World Fair Grounds
47-01 111th Street
Queens, NY 11368

And there, we'll beat up the emerging definition, which is listed here at FreedomDefined.org.



September 23rd... if you want to car pool with me down to NYC, just let me know, Justin and I will be there...




Help port R to the BeagleBoard / Angstrom for $1,000
2010-07-23T15:40:00.001-07:00
Ok... I've been fooling around with the BeagleBoard for some time now, and I have a couple observations to make. First of all, it's crazy powerful. You can do a lot more than you'd expect, since the processor is so fast. I mean, seriously, it's faster than most Android handsets out there. So every app that could run on an Android phone can run on the BeagleBoard (in theory).

The BeagleBoard has full Linux programming libraries, Makefile, gcc, perl, you name it, built in, and that makes programming a cinch in most cases. However.... some of my favorite applications on Linux are a little harder than others to port to the BeagleBoard. Including R, for instance. R is a statistical programming package that a lot of people use in the government and military and NSA to do advanced signal and data processing. I've been learning it in my spare time, and I think it would be really cool to have a portable version of it on a handheld.

I tried to get it running on my BeagleBoard, but alas, I'm not much of a software guy (I'm much more hardware). I failed to get past some of the java lib dependencies, and don't know how to install those on Angstrom without totally recompiling everything. I was over at MIT this past week, just reading in the QA stacks library (I sneak in from time to time and just camp out there for hours with Chris), and we started talking about how whether it was doable. Chris bet me $500 that I could do it. Then I joked, well I'll bet $500 that I can't.

$500 + $500 = $1,000

I would pay $1,000 in real dollars (not gift certificates and useless things like that, I mean actual cash) to the first person who can demonstrate it running, and provide links to either a tar, or zip, or image, so I can get it up and running on my own too. The solution has to be open source, and publicly shareable.


Personally, I think it's impossible. That's why I'm saying $1,000 and not like $200 or something like that.  But even I'm somewhat realistic, so here's a list of "anti-conditions":

R has a lot of built in libraries that do graphing, visuals, etc. it doesn't need to do any of that stuff
Command line only is fine, no need for to port the GUI, I don't even know if that's possible
Obviously it should run whatever can be run within the memory limits of the BeagleBoard in RAM, and that will probably mean some of the base packages won't auto-load
It should at least have a basic R command line, and be able to instantiate arrays and user defined functions, etc.

I don't really want to call this a "contest" because it's not, it's just a $1,000 check that I'll write if someone can help me port R to the BeagleBoard... if it's even possible.