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!

The Robotic Middle Ground

Robot systems are either expensive or have to be cobbled together. There's got to be a way to have neither - some type of middle ground. Some set of principles brought together and made practical, maybe updated a regular release basis. Something that can give the casually interested or time-short a cost and time-effective, predictable entry into the fascinating blend of mechanics, electronics, and software that make robotics the ultimate system design project.

The robot I have in mind for this project is something in the vein of the original Mars Rover (Sojourner) - a mobile platform that can make the operator be present and capable in a remote environment. Communication and sensor technologies won't be as exotic - Wifi, web-browser based control, and basic video are what I have in mind. The main components for such a system might include:

1. Chassis
2. Motor controller
3. Wifi communication
4. Embedded computer system (e.g. Arduino, Raspberry Pi, gumstix, other)
5. Battery
6. Video camera
7. Payload shelf

Some of my goals are to (in no particular order):

1. Develop a part list and instructions for a platform that can be driven around remotely and carry sensors and maybe a payload. This should be something that can be followed without much technical knowledge.
2. Evolve a set of open-source computer system conventions that focus on:
1. Minimizing steps and frustration to go from zero to robot software installed
2. Supporting multiple hardware interfaces with a set of software libraries and keeping the software/communication interfaces
3. Using web-based technologies and standards for communicating with the robot system
3. Support extending and customizing the robot/computer platform to multiple applications with minimal configuration and hassle.

I've been thinking about this perspective for a long time and believe the "big-picture" mentality has a lot of value for re-vamping how these types of systems are put together. Kind of like Arduino or Raspberry Pi, but at the mobile robot level. I'm going to blog as I go so follow along, make comments, mention ideas, and we'll see where things end up...