Two Wheel Base

With the IMU ready to use it is time to make the rest of Godfrey's wheel base.  Godfrey's Phase I motor base is a two-wheel balancing design. It contains all the elements necessary to detect the robot's position and balance and move the robot in its environment.

Here is a block diagram of the system:

At its heart is an Arduino Leonardo board. Connected to this board's serial port is the Sparkfun 9 Degrees of Freedom IMU programmed to continuously report the accelerator and gyroscope data. Also connected to the Arduino through PWM lines is the Pololu two channel motor driver which itself is connected to the drive motors. The motor current reporting component of the motor drivers are feed back to two Arduino analog ports. The motors also have built in rotary encoders and their signals are feed to the Arduino to measure rotation. A full schematic can be found here on Upverter.

It is constructed on a wood base using wood screws and hot glue. Here it what is looks like:

With all of this hardware, the base can:

1. It can move with left and right wheel independently in both the forward and backwards direction.
2. It accurately measures wheel rotation. This is used to accurately determine the ground path. It also helps balance the natural variations in motor speed.
3. The base uses it gyroscopes to determine how fast it is pitching in any direction. This is use to balance the robot.
4. It measures acceleration in all directions. Its primary use is to determine when Godfrey is upright. The gyroscopes are the primary actors in balancing, but they drift. The accelerometer measure the downward direction in a stable manner.
5. It is able to communicate with other computer elements through its serial port.
6. It measures the current usage of each motor. I am not sure I will use this.

A details parts list can be found here.

I will discuss the testing program and what I have learned in the next post.

IMU software

The code for Godfrey's IMU can be found here on GitHub.

This code is intentionally simple. It initializes the accelerator and gyroscope chips and then queries their values at 50 times a second and outputs the results. The values are output in the order of accelerator X, Y, Z followed by gyroscope X, Y, Z. All values are signed 16 bit two's complement quantities.

The output looks like:

  252 108 -63 44 -30 17 

This code currently outputs data at 50Hz and 57600 baud. Both these may be too slow for the operational system.

To burn this code into the device I used the FTDI Basic Breakout connecting the IMU to a serial port. Set the Arduino IDE device (>Tools>Board) to Arduino Pro or Pro Mini (3.3V, 8 MHz) w/ ATmega 328.

I had a problem programming my device with the FTDI Basic Breakout. I would hit upload in the Arduino IDE and it would hang or I would receive an error message. I discovered (through web searching and some experimentation) that I could program the device if I started the upload and then hit the reset button on the IMU.

Use FTDI Basic Breakout and connect the device to a serial port and watch the values as you move the device. Set your terminal program to 57600 baud to see the results.

The Need For Balance

Umashankar Nagarajan's thesis explains why robots in human environments should be dynamically balanced. Simply put, it is because dynamically balanced robots can be of human-like heights and still move nimbly in human spaces whereas statically balanced robots require larger bases to support any given height. To be able to balance, Godfrey must have an Inertial Measurement Unit (IMU) to measure the linear accelerations and angular changes as he moves. I choose to purchase a Sparkfun 9 Degrees of Freedom - Razor IMU.

In addition to a 3-axis accelerometer, 3-axis gyroscope and 3-axis magnetometer (to find north) the IMU has a built-in 8MHz ATmega328. This allows embedded software that initializes the sensors and then communicates their values through a serial port. Sparkfun has preloaded it with some firmware goodies that make it immediately usable. They also supply links to other projects with additional software you can load into the IMU. I connecting the IMU to my Mac using a FTDI Basic Breakout.

After playing with the Sparkfun firmware, I read and loaded the software from AHRS/Head-tracker using 9DOF Razor IMU. Even though I am not interested in a head tracker, its software is extremely helpful for getting a feel of the IMU and where the limitations are in these devices. I highly recommend their graphical test app. It lets you move the device around and see the results of the gyros on your screen. One important thing to notice is that the gyroscopes drift over time and will not come back to the exact same starting location after many motions.

The webpage also explains how to calibrate your IMU. The reason to calibrate becomes clear as you do the process and read their source code. These devices do not give the same output value for the same physical input. For example, if you point one accelerometer axis straight down you can measure the 1G pull the earth is making on the accelerometer. If you invert the axis 180 degrees, you measure its inverse. Ideally, these numbers would have the same magnitude of input (1G in this case). Sadly my device gave 258 and -270 for the X axis, 282 and -248 for y and 221 and 294 for the z. On some of these axes there is a discrepancy of over 20%. Looking at the head tracker code you can see them use some simple algebra to compensate for the differences using calibration values.

Eventually I will carefully go over each of the spec sheets for these devices to better understand their behavior. For now I have a basic sense of what they do and their limitations.

The next post will talk about the software I wrote for Godfrey's IMU.

Lessons Learned

• Gyroscopes drifts over time and therefore cannot be the sole input used to balance Godfrey. If it was used as the sole input, Godfrey would start out vertically and slowly drift and fall over as the errors in the gyro added up. I will need to use an accelerometer to measure the direction of the center of the earth and use that to compensate for the gyro drift.
• Any algorithms I use will either have to handle the innate errors in the sensors or I will have to calibrate to the specific instances of the chips I am using. I would prefer handling the innate errors because that will be easier to build and deploy.
• Having the built-in ATmega328 is great for learning and testing, but in the final product it is unnecessary. Having the CPU adds an unnecessary piece of code to to written and programmed into the device. It also consumes a serial port on the motor base CPU. This CPU should be able to talk to these chips directly and still have more then enough computer cycles to handle its other tasks.

Project Plan

My plan is to build a crude end-to-end Godfrey and iterate over time to make him better. Designing and building the crude version will supply valuable real-world insights on Godfrey's actual requirements. This will help me limit wasted time and money on unnecessary and expensive features (although Godfrey does deserve the best).

Phase I

Phase I will build a simple robot that meets Godfrey's basic requirements and has all the hardware and software functioning together in one system.

The overall hardware architecture will have a power train based on a two-wheel, Segway-like, balancing design controlled by an Arduino processor. The face will be constructed using standard RC-servos and controlled by another Arduino. Godfrey will have movable eyes, eyelids, eyebrows, and ears.

A PandaBoard will provide higher level intelligence and control. It will be connected to the Arduinos through serial ports. I am hoping that a single Pandaboard will have enough computational power to support speech recognition, natural language processing, and run the reactive planner. How Godfrey will sense the environment for navigation and collision avoidance has not been decided. This version will have no docking port.

The Phase I construction techniques will be wood, wood screws, hot glue, duct tape, etc. Simple and cheap rules the day.

Phase II

Phase II will take the learnings from Phase I and make Godfrey more realistic in all dimensions. This means making an artistically interesting the body and face. It will also require upgrades to the software components. The motor train will be a Ballbot design. This version will have a docking port and the necessary hardware and software to find, dock and charge itself.

This phase will explore building custom parts and frames using specifically designed PC boards, 3D printing, CNC, laser cutting, etc.

Godfrey's Goals

Godfrey will be a challenge to build. Here are my goals for him:

• Godfrey's primary goal is to pull humans into a relationship with himself. This means he must be able to respond to human emotions and generate emotional cues that humans can understand. He must also pursue independent goals and generally seem like a cognitive agent. A reactive planner similar in design to the CMU Oz project will control Godfrey's overall goals, behaviors and emotional responses. Oz's HAP has the advantage of being pragmatically engineered and very compatible with Godfrey's natural language component (see below). A. Bryan Loyall's thesis Believable Social and Emotional Agents shows how to augment HAP with mechanisms to infer and act on emotional states. Godfrey will use this overall design.
• Godfrey must understand and speak English. His design will make no attempt to solve the difficult speech recognition or the natural language understanding problems. He will instead use preexisting products and live within their limitations. He will use PocketSphinx to convert speech into text and Flite to convert the response back into audio for human hearing. He will approach human language processing like a chatbot on steroids. Bruce Wilcox's ChatScript is a great example of a modern chatbot design which, with some modification, can handle PocketSphinx's more limited vocabulary, perform weak natural language understanding and generation of responses. ChatScript's topics and rules are very similar and compatible with Oz's plans and goals.
• Godfrey will have an expressive face with which humans can identify. These eyes will open and close and track people in his room. His face will emote his feelings and in his final form his face and body will be designed to be artistically attractive. His inspirations are Kismet and the many robot's that have followed him.
• Godfrey should to be physically nimble in a domestic environment. I am defining nimble as being able to start, travel and stop across 15 feet (4.5 meters) in 4-5 seconds without damaging himself or his household. This makes complex demands on motors, propulsion, navigation, rapid decision making and balancing mechanisms. I believe Umashankar Nagarajan's thesis makes a very strong case that Godfrey needs to be a balancing robot if it wants to act realistically in a home environment. Godfrey will not be able to handle stairs or rough terrain.
• Godfrey should be of a height that humans feel comfortable interacting with and one they will take seriously as an independent agent. I will loosely define that to be 3.5 to 5 feet tall (1 to 1.5 meters). To the best of my knowledge there is no science defining an optimal height. However, my gut tells me if he is too small he will be perceived as a toy or a pet and if he is too large is will be scary and dangerous.
• Godfrey needs to avoid the uncanny valley. One way to avoid this valley is controlling Godfrey's external appearance. There are several possibilities to explore. The first is to make Godfrey look like a robot. For example Serge in Syfy's Caprica TV series is of the approximate size and shape I am imagining for Godfrey (here is another picture). Another option is to use puppet construction techniques to create an alien from another world (who for some strange reason decided to live in my home). Examples of this approach would be Rygel XVI, Yoda or even like Kermit the Frog. Finally, a good solution might be to blend tech and natural looks like in this Skyrim Dragon Priest Mask.
• Godfrey should be relatively light so accidents, collisions or loss of balance don't cause too much damage to his home, its occupants or my marriage. I know of no objective way to decide the ideal weight so I am arbitrarily deciding on 15 to 20 lbs (7 to 9 kg).
• Godfrey will be self-contained. He will be able to go about his business and interact with family members without requiring the use of the Internet to access external data or computational resources. His WiFi will be primarily used to load software, monitor his performance and to send out alerts. Godfrey can optionally use the Internet to lookup reference material. For example, if I were to comment "I am going to London," Godfrey could look London up on the Internet and respond "That's a long trip. How long will it take you to get there?" However if the net is unavailable he might instead say "When do you leave?" My plan is to use Freebase and their REST API for reference queries. This will require some translations between Oz/ChatScript-style knowledge and its Freebase equivalent.
• Godfrey will be able to manage his power and recharge his batteries without human help. A custom docking station will be built for him to use.
• Building Godfrey will support the exploration of the open source and for-pay tools to design and build hardware. The technologies to be explored are electronic design, PC board manufacturing, CNC, laser cutting and 3D printing. These technologies have had explosive growth in the last few years and are ripe for exploitation in robot design. One website that has personally inspired me on these opportunities is Michal Zalewski's amazing Guerrilla guide to CNC machining, mold making, and resin casting. It is a new world out there and building Godfrey will give me a chance to experiment with some of it.
• Godfrey should be simple to build and repair. This means trying to use parts, designs, and software that are reasonably simple and can be stable for long periods of time. I will attempt to use self contained hardware and software components connected by simple protocols and connectors. This is so easy to say and so very difficult to achieve. Maybe I will succeed.
• Ideally Godfrey that will cost less than $2000 to duplicate. Serious bonus points for a design that can be built under $1000. This is another goal that is simple to say and hard to achieve.

There is a robot in my future

Over the last few months I found myself seeking a new challenge and one that specifically blends of hardware, software and art. After much soul searching, the challenge I ultimately settled on is to build a robot with social intelligence similar to the robots talked about in Cynthia Breazeal's TED Talk.

I plan to name my robot Godfrey. He is an agile robot designed for natural interactions with humans in their household environment. He will gracefully move around the home while answering questions, making small talk, and telling stories. Godfrey will wears his emotions on his sleeves.

Godfrey is designed to experiment with how humans interact with intelligent agents. He is not an attempt to build a domestic servant nor is he an effort to build the one "true" AI architecture. I will leave these important goals to other, more capable, hands.

Godfrey's design and development are in its early stages. This blog will outline my journey in designing and building Godfrey.

The design data and source code for Godfrey can be found on GitHub.