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...