First Pictures of Colin

I have an increasing number of friends and family members who use Facebook mainly as a vehicle for posting pictures of their toddlers. I try to counterbalance that by posting lots of pictures of Colin. Here’s Colin at 11 months old:

Isn't he adorable?

11 month old Colin!

Look at his cute little bluetooth radio!

Look at his cute little bluetooth radio!

I’m going to add more ultrasonic sensors soon, but this is what he looks like for now.

So far I’ve gotten him to avoid obstacles, follow walls, and I’m working on a PID motor control library. I’ll be doing a post with the technical details of motor control very soon. Stay tuned!

ICRA 2015 Day One

I got extremely lucky this week. First of all, the IEEE Conference on Robotics and Automation is in Seattle this year. Second, I managed to convince my manager at Boeing to let me attend! So, for the whole week I’m going to be attending lectures and workshops on advanced topics in robotics rather than going to my regular job. I seriously cannot articulate how thrilled I am about that. Also, just as a little bit of icing on the cake, the conference venue is a fifteen minute bike ride from my apartment. A whole week with no commutes and a lot learning and talking about robotics? Only one word applies: jackpot.


Dynamic Locomotion and Balancing of Humanoids:

I’ve only been through one day and it’s already pretty clear that most of this stuff is over my head right now. I spent the morning in a workshop titled “Dynamic Locomotion and Balancing of Humanoids.” I was able to follow along with the high-level concepts like the discussion of the differences in stability and efficiency of different movement strategies but whenever a presenter tried to explain the particulars of the extended Kalman filter they used for torque control of their ankle-joint motors my eyes glazed over.

I found the discussion of the inverted pendulum and linear inverted pendulum models for walking to be pretty interesting. Both models represent the robot as an inverted pendulum that repeatedly falls forward, switches its foot position to catch itself and then falling forward again. The main difference is, in the inverted pendulum model (IPM) the robot’s center of mass moves up and down. In the linear inverted pendulum model (LIPM) the robot’s center of mass is nearly stationary in the vertical direction. LIPM is stable but it’s not as energy efficient as IPM. ASIMO’s gait is a good example of LIPM. The video below shows it around the 0:30 mark.


Mobile Manipulators for Manufacturing:

One of my afternoon workshops, “Mobile Manipulators for Manufacturing,” gave me a much greater appreciation for the non-technical roadblocks to wide deployment of robotics. For robots to work effectively with humans, they need to be able to map and navigate their environment, recognize and manipulate objects, and interact with humans in a safe and predictable way.

Although none of these technical problems have really been solved to the extent required for large-scale use of autonomous robots in the workplace, there are other problems that present bigger difficulties. For instance, there are no unified standards for robot programming, communication, or interaction with humans. This makes plug-and-play robotics solutions impossible. Every time a workplace, be it an automobile factory or a hospital, wants to integrate robots into their workflow they need to get a custom designed system. This is not only expensive in terms of setup cost but it makes maintaining, reconfiguring, and adapting the system to new conditions needlessly difficult. You can’t just call up customer support when you have a problem, you need someone who is intimately familiar with your system.

There are other safety and regulatory hurdles for mobile industrial robots to clear before they are widely implemented but, to make a long story short, the non-technical problems make the technical ones look simple. Technical problems have definite solutions. Regulatory and business problems don’t.


On my first day at the ICRA I learned more about the existence of a whole range of topics I wasn’t previously aware of than I learned about the particulars of any one topic. I’m expanding my realm of “things I know I don’t know” more than I am expanding the things I know.

There’s so much that goes into a seemingly simple task like making a robot walk like a human or recognize and pick up an everyday object. This is what I love about computer programming in general though: to teach a robot or computer even the most simple task requires an incredible understanding of the task itself.

Designing Colin

I had wanted to build a robot for years and my friendly competition finally gave me a motivation: to complete my robot before Jacob’s and throw my success right in his face.

Our Problem:

It seems simple enough at first glance. We just need to create robots capable of autonomously mapping a small, indoor space such as a 1 bedroom apartment. The robots need to determine the outline of the room and map all of the obstacles (furniture, tool boxes, piles of clothes, etc) within the room. We even made a couple of concessions to speed things up: The robots do not have to operate on carpet and they are allowed to use fixed points (such as RF beacons) for navigation. Easy, right?

Of course, neither of us know very much about robotics or programming, but learning-on-the-fly is sort of the point of this exercise.


Physical Requirements:

An abandoned early design.

An abandoned early design.

I decided to sort out my robot’s physical design before worrying about software, which would likely be far more difficult. So I need to ask, what does my robot need to do?

  • Move around
  • Control its own movements
  • Power itself
  • Transmit map data to a remote computer
  • Sense its surroundings
  • Sense its location

I realized from the outset that I would probably need to change the design in response to unforeseen problems, so I also wanted my robot to be easy to rewire and reconfigure. Also, I’m not a rich man, so I need a robot that will fulfill these requirements without being absurdly expensive. This means I need to use cheap, off-the-shelf parts as much as possible and keep custom fabrication to a minimum.

Finally, I my robot needed a name. Referring to it as “my robot” is just too cumbersome. I named it Colin, after the happy security robot from Mostly Harmless by Douglas Adams.


Design

For movement I elected to go with a differential drive system, like you would find on a Roomba. It has two parallel wheels, each with its own motor. Colin can move forward or Differential drive diagram from wikipedia.backward by running his motors at the same speed and he can rotate by running them at different speeds. I also considered omni-wheels for added maneuverability but the extra complication in design and programming did not seem to be worth the benefit. I chose a pair of gearmotors and wheels from Pololu. I made sure to get motors with extended backshafts so they could be used with encoders. This will be important later. Also, most controllers can’t directly power a motor, so a motor driver circuit will be necessary as well.ArduinoDuemilanove

For control I decided to use an Arduino Duemilanove. It is functionally equivalent to the newer Arduino UNO and I had one lying around from a previous project. The computation requirements of this project are probably greater than the Arduino’s ATmega328 can handle, but it will suffice for awhile. I can always change it out later.

For power I’m using four AA batteries. I badly wanted to use a lithium polymer battery like one of these from SparkFun but the extra expense did not seem worth the slight convenience.

To transmit map data I’m using a bluetooth radio. It probably would have been easy enough to do this via USB but bluetooth gives more versatility. Colin can’t be tethered by a USB cable while he’s mapping a room, but bluetooth presents no such problem. He can send back error messages and status updates to let me know how his job is progressing. Also, it seemed like a good idea to learn how to use bluetooth.hcsr04_hires

For sensing I decided to start with HC-SR04 ultrasonic sensors. They’re fairly accurate and Arduino already has a good code library to handle them thanks to Tim Eckel. The main advantage though, is that they’re dirt cheap. If you shop around on amazon you can get them for 2 or 3 dollars apiece including shipping.

For localization (telling Colin where he is) I’m using shaft encoders on my motors. These can be used to record how far the motor shaft has turned or how fast it’s turning, allowing Colin to calculate his present position relative to where he started.

To hold everything together I’m using a very simple chassis made from laser cut ABS plastic. I made my own designs using Inkscape and had the plastic custom cut at Metrix Create:Space in Seattle.

Lastly, to ensure my design is easy to reconfigure and rewire I’m doing all of my connections using a breadboard. If you’ve never used a breadboard I suggest you make learning to use one your first step before starting any electronics project. They allow you to build circuits without soldering, so rewiring is a snap.

I’ll include details on how to put these elements together into a functioning robot in later posts. Also stand by for tips on programming and example code!

Friendly Competition

Almost a year ago my old friend Jacob and I were hanging out at Lake Samammish, waiting for another friend, Dan, to arrive with his boat so we could go water skiing. Dan was running late and Jacob and I killed time by talking about robots. We both wanted to build a robot, but neither of us could think of a useful task we could build a robot for, especially with our limited budgets. We talked about other peoples’ robots we’d seen on the internet. Other homebuilt robots did simple obstacle avoidance routines or balanced on two wheels like a Segway scooter. They did things that were mildly interesting but they didn’t really accomplish anything useful.

It was at this point we hit upon an idea: a robot doesn’t have to directly do anything useful in order to accomplish a worthy goal. For us that goal would be competition. We would each design, build, and program a robot to accomplish a simple task. Whomever’s robot completes the task first would be the winner.

I should mention that Jacob, who is a great guy in most respects, is also totally infuriating sometimes because he seems to have a natural talent for almost everything. I showed him how to wakeboard one spring and by the end of the summer he was doing better than most people who’ve been wakeboarding for years. He is a man who is difficult to beat. This is why I wanted to compete with him. This is a rare chance to be quantitatively better than him at something.

The challenge we set ourselves is as follows: to design, build, and program a robot capable of autonomously exploring and mapping a small, indoor space such as a one-bedroom apartment. The map must be accurate to within +/- 5 centimeters and it must be output in a common file format. All of the data collection and processing must be done by the robot itself. It cannot be controlled by a program running remotely on a separate computer.

Jacob and I both thought this would be a much easier task than it has turned out to be. It is one year later and there’s still no end in sight, although good progress has been made. Our problem: autonomous exploration was once a major issue in robotics. This wikipedia article on simultaneous localization and mapping (SLaM) does a good job of describing the problem.

I’ve been working on my robot for nearly a year now. It’s a small, differential drive robot that’s quite similar to a Roomba. I decided to name it Colin after the helpful security robot in Mostly Harmless by Douglas Adams. At the moment he’s controlled by an Arduino Duemilanove I had leftover from a previous project but I’ll probably need to upgrade to something like an Arduino Mega or Intel Edison before the project is done.

I’ll include info on Colin’s design and development process in subsequent posts. I will post design details and make my code available through GitHub so anyone can use and build upon my work. If you use my work to make something cool of your own I would love to hear about it. If you make improvements to my designs or code definitely tell me what you did and how it worked for you!