Why I’m Building a Robot

I’m building a robot. It’s gonna be a little two-wheeled thing. It will move around on its own and (hopefully) avoid obstacles. And maybe beep or flash an LED. That’s it. It won’t make me coffee and there’s no risk that it will rise up against humanity. But hopefully it will be a great learning experience.

I want to share some of the reasons why I’m doing this.

Working at the edge of my knowledge

I wanted to do something challenging — something at the edge of my knowledge. I don’t have all the requisite skills or understanding at the outset. There are a lot of gaps.

For a long time, I’ve been a ‘just in case’ learner. I thought that before starting a project like this, I needed to acquire as much theoretical understanding as I could in case I would need it. But I’m realizing that there‘s so much more to learn when you actually start building something. I’m trying to cultivate a stronger bias towards action.

I still think acquiring some theoretical knowledge—in this case, a basic understanding of electronics—is essential before starting. And all that ‘just in case’ learning helps to quickly know where to look for the answers when I‘m stuck. But for this project, I’m trying as much as possible to learn ‘just in time’.

Making something physical

As a UX designer, I spend a lot of time working in software. I wanted to build something tangible. Building a robot lets me work with my hands. Screws, wires, fragile little components, soldering. There’s something so satisfying about this compared to moving things around a screen. There’s something so real about it.

Problem solving

Building a robot provides the opportunity to experience many types of problems and explore possible solutions.

Rapid acquisition of technical knowledge. How does this component work? How exactly does current operate? What does a capacitor do? Looks like I need an audio amplification circuit — how do I build that? Along the way, I need to quickly learn and apply knowledge.

Ingenuity and resourcefulness. When I run into problem or constraint, how can I accomplish the same goal in a different manner? How can I use the materials I have at hand to make up for those that I don’t? Can I improvise a makeshift solution to keep moving when I get stuck? Where can I get help when I can’t seem to proceed alone?

Experimentation. Plug this component in and see what happens! Try not to burn things out. Learn from the results either way.

Industrial design. What will be the robot’s outer casing? How can I make it attractive and also practical? How can I protect the robot from damage? How can I give it personality?

Build or buy decisions. I’m using a lot of off-the-shelf elements, including the chassis, an Arduino microcontroller, a motor driver board, and a proximity sensor unit. For each part, there’s the opportunity to ask: does it make sense to build it myself using basic components like transistors, resistors, or capacitors? Or does it make more sense to buy and integrate a pre-built module? I would certainly learn more building things from simple electronic components, and it would probably be cheaper, but there’s also a cost in time and effort. This is a frequent question.

Functional Cartography. In addition to getting more experience working with the C based Arduino language, there’s the opportunity to explore what Dan Saffer calls Functional Cartography. Saffer describes this practice as follows:

One of the great things about working at a company with both interaction and industrial designers is that when collaboratively designing a device, you have better control over where bits of its functionality are located: in the hardware or the software. At Kicker, we call the activity of figuring out where a feature “lives” Functional Cartography.

As an example, take turning off the ringer on your mobile phone. In many handsets, that functionality lives digitally, onscreen (sometimes via far too many menus). On the iPhone, it’s a physical switch on side of the device. The feature is the same; its controls can live in either place depending on what the designers (and manufacturers) decide.

I’m using this concept a little more broadly here, for functionality beyond the user interface. But the question remains: should I implement this feature in hardware or in software (code)?

Finally, I’m making a robot because it’s fun. I hope to share more insights and reflections as the project continues.