It's Gonna Be a PVC Christmas

This isn't a robot or electronics post, but it was a fun project nonetheless, so I'm putting it here in case it can benefit anyone else...

To start - I like to build things and my children do, too. And when we build, BIGGER is better. And after working on a couple of projects using PVC pipes as the primary component, I realized that a playset made of PVC would be both feasible and (child) life-sized. Since Christmas isn't too far away and the kids enjoy building forts, this seemed like a great idea for a Christmas present, so I took the van to Lowes, bought a bunch of 1" diameter PVC pipes...

... cut them using a miter box

... and put them in a box

Got some PVC connectors, too...

... here are the different kinds available

... all of these PVC pieces made this possible!

You might say, OK, so you've got the frame there, but who wants to only live/play in a house frame? And I might say, you're right! That's why the kids will also be getting a bunch of flat bedsheets to cover things (and since they're white, the kids can color them to make whatever they need!). Unfortunately, secrecy requires that we don't put the whole thing together until Christmas Eve - hopefully I'll put some pictures of completed structures once some cool things have been built!

For some more detail... I cut pieces into the following lengths:

• 4'
• 5'
• 3' 6 3/16" (for tops of roof trusses)
• 2'
• 1.5" (to join connectors together)

I expect that once the kids start doing their own thing, I'll end up cutting some of the longer pieces down to sizes better suited for what they need.

Battery Blanks - a Lego Mindstorms NXT Power Supply

One of the things I want to do is leave my robot running while I'm not at home. Robot systems typically assume you will use batteries, which is fine if the robot's only on when you're actively engaging it or if you've invested time/energy for a charging station. However, for some of the work I'm doing, I'm willing to tolerate a tethering solution so that I have an "always on" option without having to figure out tethering logistics.

I want to do this "always on" option with a Lego Mindstorms robot - I looked online and could not find a power supply to buy. I did some googling for other solutions, and the only relevant links I could find were this project, which was more involved than I wanted, and this Kickstarter project that didn't go anywhere.

So it was up to me to come up with a solution. The NXT brick uses 6 AA batteries, which means the NXT brick uses 9 volts. So I did a little thinking - all I really need is to get 9 volts between the battery terminals inside the brick. I didn't want to alter the NXT brick in any way, which meant soldering to the brick wasn't an option. I realized that as long as I'm careful, I can get away with something that has the form factor of a battery. (Warning, if you decide to do this, make sure you make your connections properly and don't get the polarity wrong! I can't be held responsible if you plug things in backwards or don't use the right voltages! Do this at your own risk!)

This path led me to wooden dowels, and I did a little research - AA batteries have a roughly 1/2" diameter, so I got a 1/2" dowel and cut it into a couple of battery length pieces. Wood won't carry current, but screws and washers will. With this knowledge, I devised a plan...

Battery-length dowels

Screws will conduct electricity

Screw head acts as button terminal on + side (not shown, washer acting as negative terminal)

It fits!

Cut some notches in... then solder wires to the screws...

Battery blanks in place - give it some juice

It works!

All sealed up

So there you have it - with this set up, a Mindstorms robot can run until you turn it off, not until your batteries run out!

A Brief Interlude - the Arduino Insaninator

I've taken a break from messing with robots to messing with people using embedded technology. At work, we've had some practical joke success by plugging a second mouse into a co-worker S's workstation and putting it on the floor. Then, at random intervals, B, who sits adjacent to him, gently nudges the floor mouse. S then picks up his mouse (the only one he's aware of), looks at the bottom of it in a little bit of confusion, and proceeds to slowly go insane. This is, of course, highly amusing to those who are fortunate enough to witness it.

It's time to take things to the next level. The new Arduino Leonardo runs the USB host on the microcontroller itself (http://arduino.cc/en/Guide/ArduinoLeonardo#toc2) - this means it's easy to get a computer to recognize the Leonardo as a USB device. Once I realized this, it is only logical to make a faux USB "mouse" to replace B's fancy footwork. Enter the Arduino Insaninator!

So I ordered me one of these Leonardos here from Amazon and made sure I had a USB to USB-mini cable available. Once my Arduino was delivered, I downloaded the Arduino software, ran through a Hello World tutorial (http://www.ladyada.net/learn/arduino/lesson4.html), and got familiar with the mouse library documentation, then got cranking.

How does an Insaninator operate? I'm opting for simple based on random... lots and lots of random - random X motion and random Y motion at random intervals.

• Action delay - delay for 1 minute to 60 minutes, then do a twitchy behavior
• Twitchy behaviors - 2-10 motions, 50-1500 milliseconds apart
• Motion selection - use only horizontal, use only vertical, or use both
• X movement - 0-50 seems reasonable after a little experimentation
• Y movement - 0-50 seems reasonable after a little experimentation

Check out the source code from github - try to make someone you know think they're going crazy.

Future options could include:

• random mouse-button clicks
• configurable behavior with DIP switches or jumpers to remove need for reprogramming

This list is by no means exhaustive - additional ideas welcome!

First Steps - the Raspberry Pi

This post is an introduction to the hardware and software components that make up the computational guts of the Devalbo Robot. If you're familiar with the Raspberry Pi, this might not be necessary. If you're not, or you just want a quick tutorial on how to get a Raspberry Pi up and running, read on! If you have any questions or feedback, make comments.

Hardware - Raspberry Pi

The Devalbo Robot uses the Raspberry Pi as the creamy computer nerve center. It is the hub of all robot communications - between robot components and the outside world. Since it was introduced, it has become a hugely popular ingredient for many hacker projects. If you want some more introductory information, this is a decent reference: http://elinux.org/RPi_Beginners

You will need a Raspberry Pi. Get one!

Hardware - SD Card

You need to put a Linux image on an SD card, which gets plugged into the Raspberry Pi (you can think of it as the Raspberry Pi's hard drive). I'm using this one.

Software - Raspbian

The Raspberry Pi is a low-cost computer board, but it doesn't come with an operating system pre-installed. You will need to download a copy of Linux to put onto the SD card from above. The Devalbo Robot uses the Raspbian distribution - you can download the version I've been testing with from here: http://downloads.raspberrypi.org/images/raspbian/2013-02-09-wheezy-raspbian/2013-02-09-wheezy-raspbian.zip

We will be following the installation procedures described here: http://elinux.org/RPi_Easy_SD_Card_Setup. The steps you follow and tools you use will depend on your operating system. Here is the console output from when I followed the installation procedure using OSX.

~ >cd Desktop/
~/Desktop >df -h
Filesystem      Size   Used  Avail Capacity  Mounted on
/dev/disk0s2   112Gi  107Gi  5.2Gi    96%    /
devfs          182Ki  182Ki    0Bi   100%    /dev
map -hosts       0Bi    0Bi    0Bi   100%    /net
map auto_home    0Bi    0Bi    0Bi   100%    /home
~/Desktop >df -h
Filesystem      Size   Used  Avail Capacity  Mounted on
/dev/disk0s2   112Gi  107Gi  5.2Gi    96%    /
devfs          185Ki  185Ki    0Bi   100%    /dev
map -hosts       0Bi    0Bi    0Bi   100%    /net
map auto_home    0Bi    0Bi    0Bi   100%    /home
/dev/disk1s1   3.7Gi  1.6Mi  3.7Gi     1%    /Volumes/NO NAME
~/Desktop >sudo diskutil unmount /dev/disk1s1 
Password:
Volume NO NAME on disk1s1 unmounted
~/Desktop >df -h
Filesystem      Size   Used  Avail Capacity  Mounted on
/dev/disk0s2   112Gi  107Gi  5.2Gi    96%    /
devfs          185Ki  185Ki    0Bi   100%    /dev
map -hosts       0Bi    0Bi    0Bi   100%    /net
map auto_home    0Bi    0Bi    0Bi   100%    /home
~/Desktop >sudo dd bs=1m if=~/Desktop/2013-02-09-wheezy-raspbian.img of=/dev/rdisk1
1850+0 records in
1850+0 records out
1939865600 bytes transferred in 158.045257 secs (12274115 bytes/sec)
~/Desktop >sudo diskutil eject /dev/rdisk1
Password:
Disk /dev/rdisk1 ejected
~/Desktop >

Connect and Configure

At this point, you have a Raspberry Pi, an SD card with Linux, and it's time to start making connections:

• Plug the Raspberry Pi into a TV or computer monitor
• Plug the SD card into the Raspberry Pi
• Plug a USB keyboard into the Raspberry Pi
• Plug the Raspberry Pi into your local network using its Ethernet port (Type B has an ethernet port)
• Lastly, connect a USB power supply to the Raspberry Pi's power port

Once the USB power supply has been connected, the Raspberry Pi will boot up. It will eventually give you the chance to set the following options.

• Desktop on boot (make sure it is set to selected)
• SSH Server is enabled
• Finish booting

Now, you can use the "desktop" or an SSH client to login to the Raspberry Pi (default username/password will be pi/raspberry). Your tiny computer is ready for action. 

In the next post, the Ethernet cable will go - we'll go WiFi for about $10 with this little guy.

The $200 Do-It-Yourself Robot

At this point in the project, I've achieved the goals I set out for without much budget consideration (though having a wife who monitors the finances always kept price in the back of my mind :) ). As I think about what comes next, I've come to the conclusion that a price target of $200 for the Devalbo Robot will make it more interesting. The goal of this project has always been to drive things along each of the faster, cheaper, and better design axes by cherry-picking and integrating external ideas, components, and software as they become available while keeping things simple enough to build your own. It's just that now, the requirement for cheaper is $200 or less and this will have an effect on faster and better (the original goals are here).

Faster...

How long does it take someone who is not me to follow these instructions and end up with their own robot? The quality of the design, assembly process, and instructions all play a part in this. In theory, the more one pays, the easier these steps should be. Keeping things user-friendly while affordable has a big impact on component selection.

Better...

...the most subjective principle. I'm valuing steps simple enough for you to build copies of the Devalbo Robot without requiring a lot of your time. I'm placing emphasis on supporting substitution as you see fit - like building your own computer. The path of least resistance is to use the vanilla components, but you could also customize parts to maximize performance, or emphasis can be placed on using budget-friendlier parts. So for now, focusing on being the best value in a class of similarly capable robots is "better". Here are some other robots I consider to be in the same class as the Devalbo Robot:
* Brookstone Rover
* Romo

Cheaper...

This is the most interesting challenge. Having this design constraint influences the faster and better parameters - the "betterness" of a robot will be influenced by how long it takes me to do a step vs. paying for someone else to have already done that step. Based on what I've done so far, $200 for parts (excepting batteries and power components) for an indoor, "open-source", extensible platform will be interesting and achievable without being unfeasible.

The Grand Total

Here's the parts list for the current configuration. Let's see what the tally is...

The Devalbo Robot Angle

This robot thing is starting to come together. I should be able to run a robot I built, from components, and drive it from my couch.

I've got some early software commits - see https://github.com/devalbo/roboplexx-bot-python.

I've gotten parts delivered.

I've been connecting electrical components.

I've been putting all of the pieces into a single package, untethered, like this - now I am getting it to work.

As I've been doing these things, I've been thinking about what this "Devalbo Robot" is. This is what I've come up with so far as a feature list:

• The robot provides a user interface via web-browser/WiFi: users can connect to the robot via their WiFi network and navigate via camera and virtual joystick
• Each sensor and actuator on the robot can be addressed individually via WiFi/HTTP, making REST-clients possible - a robot is essentially a group of sensors and actuators in close proximity to one another
• Electrical assembly/connections are minimal effort (I'm using USB and terminal blocks for connections as much as possible - power connections are the most challenging at this point), and hopefully no soldering will be required; a Plug-and-Play mindset should be respected and valued
• USB has simplified integrating sensors/components; the server software will make exposing them to web clients possible - hopefully this will continue to be the case as more devices can be supported

Once these goals are met, this version of the "Devalbo Robot" will be complete and ready for some shake-down cruises. With a couple of nights' effort (after all physical parts have been procured), it should be possible to run your own robot - in your own home - from your own couch.

Beyond Romo

Well, I'm disappointed. I've been using the Romo (http://romotive.net/developers) robot chassis for the past 8 months with an Android phone as the controller. One of Romotive's original goals was hackability, openness, developer-friendliness, and all that entails. I even got around to writing some software to control my Romo (see https://github.com/devalbo/roboplexx-bot-android) via web-browser (over a local network and via the internet) using their software development kit.

However, things have changed from what I can tell. Now, it looks like Romotive's current intention is to use iDevices as robot controllers going forward. They cite difficulties with Android as one of the reasons, and I really can't fault them for that. (They used audio signals to control the motors - I suspect it was challenges with audio systems from different Android handset makers that made the control aspect difficult.)

This mens a platform shift is required. Some level of hardware standardization is one of the things I hope to achieve with this journal. I'm basing the robots I build on open source software and hardware components as much as possible, with the aim of keeping things extendable, reproducible, and low-cost (you know, hacker friendly). I'm feeling good about the choices between Arduino and Raspberry Pi for the embedded piece. Using Linux on these platforms will give me (and everyone else) lots of choices about software systems. The next step is to find a way to get commands from those platforms to motors to make things happen!