GoodRobot Prototype
Back in January, I posted the first video of our prototype Internet-controlled robot (thanks to Steve Guengerich for the mention of the video on the Wikinomics blog):
This fully-functional demo was controlled via a web page that used a virtual “joystick” which I used to control and steer the robot. These commands were sent to our web server (Amazon EC2) and then the robot received them wirelessly via a wifi connection in my home. Video was handled via an IP camera that served its own video, and this video stream was embedded into the “control” web page as well. For those who would like to know more about the robot, here’s some more detail on how this prototype worked and some updates on more recent improvements.
First, here’s some photos of the main robot itself, which is actually the lower half of a power wheelchair. After much experimenting with motors/gears/chassis, I found that used wheelchairs are one of the most affordable sources of a robust motorized platform that offered the precise control and high power that I was looking for. In the above video, all the hardware is loosely stacked on top of the robot. I didn’t like the look of that, so I now have an enclosure that can be used for the battery and electronics that looks much better. You many recognize this “enclosure” as a piece of carry-on luggage (note the wheels). I liked the smooth look of it, low weight, and the color matched the lower part of the robot almost perfectly. Here’s some photos of it:
The robot’s “brain” is actually a low cost linux PC called an Eee PC made by Asus. These tiny computers have flash memory (making them more impact resistant), can be ordered w/ Linux, and don’t consume too much power. You can also order special super-size batteries for them too (check ebay), which will give your robot many hours of running time. My Eee PC also came with a built-in webcam (meaning you can use skype video for navigation using the Eee PC if you wish instead). Using Skype also makes it easy for your robot to have a two-way dialogue with people in the vicinity too. The most important function of the EeePC is to connect to the Amazon web server to get the movement commands (the EeePC also has built in wifi), and then relay those control commands to the robot. Here’s a photo of the Eee PC I’m using:
The Eee PC communicates to the robot using a USB input/output device made by Phidgets.com. This company makes a wide variety of USB connected hardware that’s useful for real-world control (via relays, motors, actuators) and sensing (distance measurement, motion encoders, buttons etc). In this case, we use a PWM output signal to control the left-right and forward-backward movement of the robot. So we purchased a Low-Voltage motor control phidget that would accept commands from the Eee PC and then send them to the robot:
One of the next modifications we’d like to test is to generate a PWM control signal via a much cheaper set of hardware. From some limited testing we’ve done with the fantastic arduino microcontroller (about $25 on ebay), it looks like we ought to be able to get away with a much more stripped down “brain” using an arduino – especially if we use an ethernet shield to connect the arduino directly to the Internet.
The PWM signal generated by the phidget is then converted into a voltage control signal that the wheelchair can “understand”. At the moment, that task is handled by this circuit board:
But I’ve just ordered some more professional PCBs that’ll be a little more durable, and look at lot nicer too (happy to upload the schematic and details for anyone who is interested):
The voltage control signal then goes into something called an Omni +. P&G drives (the company that makes the motor controllers for many wheelchairs) makes the Omni + in order to accommodate other types of wheelchair controls beyond the standard joystick. That way, people with different disabilities can still control their wheelchair – so for example there’s one type of supported control that operates by breath pressure on the end of a straw, or you could add button controllers, or just about anything you can dream up. So in our case, this Omni + controller is an ideal way to hook up our own proprietary control system by sending the right set of voltage commands via our custom circuit board. The Omni + is also very picky about the ranges of voltages it accepts and to check that it’s always connected – and while this requires more careful design of the circuit, it’s designed with safety in mind which is just what’s needed for tele-robotic applications too. Here’s the photo of the Omni +:
The Omni + also has a connection for an emergency stop switch. While I (unwisely) didn’t make use of that during my early testing, I’ve since purchased a wireless emergency stop button that will activate it in the case of a runaway robot. Always good to default your switch settings so that shutdown happens automatically if the switch gets low on batteries or gets out of range. Here’s the wireless switch I chose for the task (it offers up to four remotely controlled relays, so I may have to think up uses for the other 3):
Last, is the video camera I used for the over-the-web navigation. In this case I tried a few different IP cameras that come with their own min-web server that can send video directly over the Internet. We then embedded this video stream into the control page for the robot (included the virtual joystick, and the live video from the robot). Because I wanted the video to also work wirelessly I chose a wireless Linksys PTZ camera for this task. The pan/tilt/zoom feature was nice, latency was moderate, and price wasn’t prohibitive. Here’s a photo of the camera:
The camera itself was mounted on a microphone stand that sat atop the wheelchair. I’ve since added a flexible gooseneck to the top of that microphone stand and that’s a dramatic improvement since it allows the camera to be easily twisted to get the desired angle. Overall though, this is the feature that I’m currently least happy with. The latency of the camera (time it takes between the moment of video capture and the time it arrives on the control web page) is still too high for my liking. And that makes it a bit difficult to steer and move around. The other limitation is that it’s very very difficult to perceive depth using a camera like this, and you really have a hard time knowing just how far things are in front of you or how much room you have to maneuver. It was difficult to guess the extent of this limitation until you actually tried navigating from afar. It does get better with practice however, but I think we still need more improvement in this area. That’s a big area of focus for the work we’re doing now, so the next version should be much more intuitive.
In my next blog post, I’ll describe some of the new work that’s been going on in the creation of our general-purpose robot control architecture, and where we’d like to take GoodRobot.com in the future.