Trial and Error. Lots of it.

[This post started as a progress report and ended up being more of a mental progress report. My next post will provide details about the current hardware and software of the KR01 robot.]

I just got another package in the mail. A couple of pieces of plastic. 3mm black Delrin. Very nice plastic.

While building the KR01 robot there’ve been a few lessons learned. One is that any notion of a “final design” was pretty foolish. If anything I’ve been constantly changing things. Donald Knuth, author of The Art of Computer Programming, famously wrote that “premature optimization is the root of all evil”, but we’re not talking here about optimisation: I’ve simply been trying to come up with functional hardware and software. Even for a small robot that’s proven to be anything but trivial. And the mistakes I’ve made have been due to both complicated and very trivial reasons.

ThunderBorg connections
What’s wrong with this picture?

Here’s a simple quiz (one that I’ve failed, twice):

Okay. You have a motor controller with connections labeled M1+ and M1-, M2+ and M2-. I’ve designated the port (left side) motor as M1 and the starboard (right side) motor as M2. You connect the white wire of the port motor to M1+, the black wire of the port motor to M1-, the white wire of the starboard motor to M2+ and the black wire of the starboard motor to M2-, just like in the photo. Correct? BZzzZZttt! Wrong. Can you guess why, or what will happen?
Answer: If you connect both motors to the controller in the same way (same polarity) and tell both motors to move forward, well, they will do exactly as you ask. Except that “forward” for the port motor means forward around the central axis of the robot, so the robot will spin counter-clockwise in place. Like many things this seems perfectly obvious, in retrospect. In retrospect.

I’ve been a software developer for many years, and iterative design is something I’ve long believed in, or at least have (by default) practiced. That is, you don’t get it right the first time, or the fifth. You keep hammering away until some portion of the work is done and then just move on to the next bit. Perseverance furthers. This isn’t that silly waterfall vs. Agile argument. It’s good to plan ahead. You need to plan, as much as you can. But at the beginning you can’t possibly see the road ahead. A hypothesis, a direction, yes.

Unlike software systems, with robots we have both hardware and software to deal with, and the entire approach is different, compared with say, a client-server infrastructure for a national weather service (which I have some experience with). The latter is enormously more complicated, but writing a robot operating system for a custom-built robot is just plain tricky, both getting the hardware functional and getting the software to do what you want. The hardware is a myriad of compromises of space, weight, cost; the software is reacting to an ever-changing series of sensor events, in real time. The more sensors, the more complicated things become. The motor controller softare can itself be quite a challenge.

It’s pretty tricky to create even a simple line-following behaviour, where there’s a single program that reads the values of two infrared sensors and alters the speed of two motors.

NASA’s Sojourner robot, which landed on Mars in 1997, sported an 8085 8 bit microprocessor with a 2 MHz clock (rated 100,000 instructions per second), addressing 64 KB1 of memory, 64 KB of RAM for the main processor, 16 KB of radiation-hardened PROM, 176 KB of non-volatile storage, and 512 KB of temporary data storage2. By comparison, the Raspberry Pi 3 B+ in the KR01 costs all of US$35 but is many orders of magnitude more powerful — somewhere over 200 million floating point instructions per second — with a 64 bit processor, a 1.4 GHz clock and 2 GB3 of memory. Rather than an SD card I’m using a Samsung 250 GB SSD for data storage, which costs about US$80. The Raspberry Pi is running a Linux operating system and I’m programming the robot in Python, not assembly language. So even if my budget is miniscule, I have some very significant advantages over NASA in the mid-1990s. The limitations of my project are entirely me.

I have no idea how difficult it must be to design an autonomous robot like NASA’s Perseverence robot, where there are seven large scale instrument systems, a five-jointed robotic arm and 23 cameras. It’s not a remote controlled robot (called telerobotics, basically a drone), as while it can be commanded, it’s autonomous: it can “think” for itself. It also weighs 1 metric ton, its power supply uses 5 kg of plutonium, and its mission has a budget of US$2.04 billion. Of course, it’s going to Mars. My KR01 only needs to navigate my lounge.

Perseverence would just fit in my lounge, if I moved my sofa (photo: NASA)

As is my nature, I jumped in headfirst and built a robot with quite a few sensors and hardware that I’ve been changing almost continually since I started. The photo at the top of this post is testament to the number of changes: it’s the “motherboard” of the robot that held the Raspberry Pi and all of the sensors that weren’t attached to the front bumper, and I’ve been almost continuously shifting things around both under and over that 3mm plastic boundary. Lots of holes.

While drilling all those holes, I learned a few things:

  • Everything is a compromise when it comes to the real world. Designs are abstract. Even if you know exactly what your goals are when designing a robot, the choice of materials, motors, batteries, sensors, and how they all fit together into a single hardware system, well, you’re not going to get it right the first time, and only by repeatedly failing will you arrive at a solution that kinda works. And it will only work some of the time. Then you go back and make some changes and try again. Repeat. And then once you’ve learned things by doing all that, your goals change.
  • You don’t know how things will go until you actually try it out. Design and its implementation are never the same. Robots and systems comprised of purely software are different in some rather profound ways. Rodney Brooks talked about two aspects of robots: situatedness and embodiment in his 1991 paper Intelligence Without Reason (see Some Notes on Artificial Intelligence ). This means that we’re not programming for an abstract system, we’re designing a control system for something that exists in the real world and has to deal with real world physical limitations and obstacles, where how long something takes to happen is affected by many factors, like floor surfaces, traction, and battery life. Things are often unpredictable. No two DC motors perform exactly the same, and are affected by things like heat and gear train friction. Sensors don’t perform exactly as we might think, and can be affected by bright lights, dust, radio frequency interference. There are wood floor to carpet transitions. Cat hair.
  • There’s going to be hardware and software bugs. I’m pretty meticulous, I like to think. But the number of mistakes I’ve made while building this robot, even after double- and triple-checking things, is rather humbling. To be fair, not everything was a mistake, sometimes it was trial and error, but there’ve been quite a few errors as well. For example, I’ve made mistakes creating wiring harnesses, forgot to provide power to sensors, drilled the holes for something and found it was too close to something else, and found a couple of push connectors that when pushed onto the connector pin just backed out of their housings and failed to make the connection. Sometimes these mistakes were obvious, some took awhile to discover and fix.
  • Things keep changing. Things wear out. You think you can bundle up those wires with a nylon wire tie? Think again. When you make a change tomorrow you’ll need to cut it off. This isn’t a reason to avoid the wire tie, just know that nothing is permanent, nothing lasts. This is also a central premise of Buddhism. Stay flexible, design for change.
  • Expect the unexpected. Robot hardware and software just doesn’t do what you think it’s going to do. It just doesn’t. Something always jumps up and grabs your ankle, and you’re sitting in your lounge with a mint julep, not prowling a desolate graveyard in a howling storm.
  • Learn from those who’ve gone before you. There’s little point in making mistakes others have already made. You can go it alone and make all those same mistakes, or do a bit of research to learn what to avoid, and also to seek inspiration.
  • Don’t be afraid to ask for help. Similar to that last item, there’s a lot of experience out there. If you’re polite people are usually happy to answer your questions, or point you at resources and documentation.
  • Try to stay organised. By this time I’ve got a lot of spare parts, nuts and bolts, sensors I haven’t yet tried out, or tried out and am not currently using. Just as in any shop, it’s smart to keep sort things out, keep things in divided containers, put your tools away when they’re not in use.
  • Stay within your budget. Have some idea of what you want to spend on your project, add a 20-50% percentage overrun, and design your robot to reasonably fit within that budget. All the miscellaneous adds up.
  • Be prepared. Make sure you have the right tools for the job. Have some spare parts handy. I’ve purchased extra 2.5mm, 3mm and 5mm nuts and bolts, washers, lock washers, nylon lock washers. A packaged set of 2.5mm nylon standoffs and a selection of LynxMotion 3mm aluminum standoffs in various lengths. I got a good quality soldering iron, and already had a multimeter and oscilloscope (the latter has proven pretty handy, if not strictly necessary). I have a well-lit, ergonomically-correct workspace. Power tools.

Hmm. I’m not sure if that list was really about building robots.

Here are some robot-specific ones (though suspiciously still generally-applicable):

  • Balance is important. You need to position the heavy objects (like batteries) so that the weight is over the center point of the robot, or if your robot is two wheeled with a trailing ball or wheel caster, low and slightly behind the main axle. If the weight is not on-center the robot’s motion will be affected.
  • Make sure you have enough power, and the right power. The Raspberry Pi needs a regulated 5 volt power supply: you’ll either need a USB “power bank” or a 5 volt regulator running off of a higher voltage battery. Your batteries might be lithium ion or lithium polymer supplying 3.7 or 7.4 volts, or nickel metal hydride (1.2 volts each) or alkaline AA batteries (1.5 volts each). An AA battery holder can hold four, six or more rechargeable or alkaline batteries supplying anywhere from 4.8 to 12 volts. Four AA rechargeable batteries provide 4.8 volts (not enough) and four alkaline AA batteries provide 6 volts (too much). Or like the KR01, you could use a power tool battery supplying 12 or 18 volts (which in reality seems to be around 20 volts). Your motors will likely need 6, 9 or 12 volts. Many of the motor controllers are configurable to handle a larger input voltage than the motors can handle, but this still requires care and proper configuration. Beyond voltage is current: how long your robot will run depends on the capacity (in amps or milli-amps) of your battery supply. Do you use a single battery for both the microcomputer/microcontroller as well as the motors? If you only want your robot to run for a few minutes at a time your battery capacity can be significantly lower.
  • Measure three times, cut once. Even with careful planning it’s easy to cut something the wrong size, or drill a hole in the wrong place. As you can see from the photo of the KR01, there’s not a lot of extra space anywhere on the robot, and I had to shift things around a lot to get things to fit. If there are any moving parts (like a servo-mounted ultrasonic sensor or camera), you need to be sure there’s enough clearance so that it won’t run into some other part of the robot.

Hmm. I might add to this list as time goes on but I can’t think of anything else right now. My beer is still cold, and only half full.

My next post will provide a progress report on the KR01 robot.

From Failure, Success

KRZ-01 Robot

There’s been another mishap around here. I guess building robots has its ups and downs and last week was no different.

I’m kinda ashamed to say that while I was working on the KR01 robot I’ve now managed to burn out two Thunderborg motor controllers and one Ultraborg servo controller. Well, not quite “burn out”. The motor controller parts of the Thunderborgs still work but the RGB LED used to display the battery level has somehow gotten fried on both units, and the Ultraborg (which is used for sonar and servo control) seems to have died during the first Thunderborg catastrophe (sympathetic death). I have no idea really how this has happened, but of course the only real possibility is that I’ve done something wrong. I mean, I’ve been very careful with checking my wiring before applying the power, but at some point I must have got my wires crossed. The PiBorg folks who make these boards have been quite helpful and I’m sending them back to the UK to see if they can figure it out. But that will take awhile.

King Ghidorah anatomy by Shoji Phtomo
Not to be confused with Monster Zero 1

This means that for at least a few weeks I would be without a robot (the horror)! I really can’t have this happening just as I’m getting the robot operating system up and running. So last weekend I went ahead and built out one of my design prototypes, which I’ve been calling the KRZ-01 (Kiwi Robot Zero), as it’s based on a Raspberry Pi Zero W. It uses a Picon Zero for a motor controller, a Pimoroni Breakout Garden to mount some of its sensors, and a trio of infrared detectors rather than a front bumper.

Happily, the build posed only a few problems and I had it up and running rather quickly. I rewrote the Python modules that had been used to control the KR01’s motors to instead use the Picon Zero and I had it dancing around on the carpet today for the first time:

KRZ-01 Motor Control Demo

The KRZ01 is meant to be small and relatively cheap, but still have the ability to carry some impressive sensors. It actually isn’t a whole lot less capable than its larger sibling, the KR01. Without including shipping the parts come out around NZ$250, so it’s not the cheapest robot you could build but it’s got a lot of functionality2.

Side View of KRZ-01
Side View of KRZ-01

It’s based on a Raspberry Pi Zero W, which has 500MB of memory and supports both WiFi and Bluetooth. The OS is Raspbian Linux. The Picon Zero motor controller and a Breakout Garden Mini are both mounted on a Mini Black HAT Hack3r breakout board. This is an extremely compact setup. You can see this on the side view photo.

The sensors include: three Sharp infrared detectors; a VL53L1X Time of Flight (ToF) distance sensor mounted on a micro servo, which can measure distance up to about 4m with a 25mm accuracy (this is the same sensor I used on my night light); and two 298:1 ratio micro gear motors with encoders so we can measure how far we’ve travelled.

Bottom view of KRZ01
Bottom View Showing the Motors and Motor Encoders

There’s still two free I²C Breakout Garden sockets so additional sensors can be swapped in and out without any soldering. I added a couple of 11×7 LED Matrix boards as status displays but they’re hardly necessary. The whole thing runs on a common USB battery. The chassis is made out of 3mm Delrin plastic. For locomotion it uses a pair of Moon Buggy wheels, a lightweight plastic ball caster in the front, a heavier stainless ball in the back (so its balance is towards the back caster).

Since the robot supports WiFi I connect to it remotely using ssh, which is how I’ve been installing and loading its software, starting and stopping programs, and shutting it down 3. Remarkably, the Raspberry Pi W includes a tiny HDMI connector so I could plug it into a monitor, but that hardly seems necessary. This seems like a command line robot.

The chassis is 75mm wide and 120mm long. Without a battery the whole thing weighs 120 grams. For comparison, that’s 17 grams less than my iPhone 5. I have a 5200mAh battery that weighs 136 grams and a 4400mAh battery that only weighs 40 grams, so unless battery life is an issue I’ll probably use the smaller battery. I have a 10000mAh battery (200g) that would last many hours but I can’t imagine leaving the robot alone that long. What kind of trouble could it get into?

For more information about the KRZ01 Robot, visit its NZPRG wiki page.

Note: as of today the NZPRG has its own YouTube Channel.

Edit: after some back in forth in email and finally posting the boards back to PiBorg in the UK, I learned from them that what seemed to have happened was that the UltraBorg tested as faulty, and that was apparently what was burning out the LEDs on the ThunderBorgs. They’ve since sent me replacements for both and all is working well now. A well-deserved thank you to PiBorg for their patience and help!

The KR01 Robot Project

This article is the first in the multi-part series “Building the KR01 Robot” ( 1 | 2 | 3 | 4 ), and describes some of the background leading up to the project. Further posts can be found under the KR01 tag.

About a month ago, when I started, I hadn’t really thought much into the future of my rather humble robot project, certainly not enough to consider where it might lead. Certainly not enough to think about starting a robotics group. At this point I have no idea where that group will lead (if anywhere), but I can at least blog about the project itself.

A Little History

Z80 Single Board Computer, ca. 1979

In my senior year in high school in 1979 I designed and built a robot. It used an 8 bit Intel Z80 single board computer1 with 1K of RAM memory running at a whopping 2MHz. The PC board was about one square foot (30cm), had a hexadecimal keypad and a six-digit red LED display. It sat on top of a chassis I built out of aluminum and some large circular PC boards I found in a surplus shop on the outskirts of Des Moines, Iowa, that apparently were from the insides of a missile. It used two large DC motors, a wheel caster and a 6V lead acid battery. It was an ambitious project for a high school student and I never quite got the ultrasonic sensors working properly (the schematic was from a fish finder), but it was a good learning experience, a lot of fun, and led eventually to an IT career.

Over that career I had the fortunate experience of working at NASA Headquarters for a few years, where as a fellow Mac enthusiast I met Dave Lavery, the head of the robotics division. At the time he had a prototype of the Mars Sojourner rover sitting on his desk. I remember marvelling at the beauty of the machining of the wheels, and wishing I had that kind of budget (and a machine shop). While helping to set up a public demo I also had the opportunity to pilot a telerobotics sled under the ice in Antarctica. Not surprisingly it was an amazing place to work.

NASA Sojourner Mars Rover
Photo courtesy NASA

Years have passed and I now live in New Zealand, where most of my creative energy has over the past few years been in music (I have an improvisational abstract band named Barkhausen; we just finished our second CD).

The combination of experimenting with some DIY microcontroller-based Eurorack synthesizer modules and the advances in the world of Raspberry Pi has found me back into robotics. For the past few months I’ve been purchasing various playthings from Pimoroni and Adafruit and doing some experimenting.

While browsing around doing research for the project I came upon a YouTube video “David Anderson demonstrates his method for creating autonomous robots“, where David showed a local group of people some of his robots:

David Anderson demonstrates his method for creating autonomous robots

Now, I wouldn’t say David’s robots are the most sophisticated ones I’ve seen, not walking around, not androids with faces that move, not MIT’s Shakey nor something from NASA. But they are remarkably clever designs. He also seems like a really nice, down-to-earth guy. What struck me was the fact that his robots were within the reach of normal people to build. Something I could build.

Following David’s trail led me to the Dallas Personal Robotics Group (DPRG), which claims to be “one of the oldest special interest groups in the world devoted to personal and hobby robotics”. Undoubtedly. They were founded in 1984, five years after I’d built my robot in high school.

I ended up joining the DPRG mailing list. In replying to one of their members’ messages where I mentioned I’d started building my own robot, he was very friendly and encouraged me to blog about it. Well, the only blog I had has been devoted to my band and that didn’t seem particularly appropriate. Then, last night we had some friends over for dinner and I was surprised to learn that their 9 year old girl was quite keen to learn about my robot project. So I proposed the idea of starting a Pukerua Bay robotics group.

It turns out there isn’t any national robotics group in New Zealand, nor even a local one near Wellington, so when I was shopping for a domain name it turns out that “robots.org.nz” was available so I bought it. We’ve gone national!

So, if you’re interested, you’re very welcome to follow me on this journey to build a robot…

Next: stuff begins arriving in the post…