µKubik quadruped robot

You can see it walking on my desk here:

It's still not perfect, it will sometimes trip over its own legs or get them tangled up, but that is going to be fixed in software with proper bounds checking.

There is a number of lessons I have learned with my first attempt at a quadruped robot, Kubik. I think that the most important one is that the size does matter.

You see, if you double or triple the size of a robot, its weight is going to increase 8 or 27 times, respectively. That's because it grows proportionately to the volume, and volume grows proportionately to the third power of the size. This has consequences.

The first consequence is that suddenly you need eight times more powerful servomotors. Obviously they are more expensive, heavier and require more power. They are also slightly more dangerous, as they might have enough power to pinch your finger or break one of the parts. The second consequence is that you will need stronger materials. The cheap plastic servo horns will no longer be sufficient, you will need to use much heavier plexiglas, wood or metal. And because they are stronger, it's also difficult to cut them. The third consequence is that you are going to need better mechanical design. You can no longer just attach the servo to the body, and have the leg attached to its horn only. You will need to use proper servo brackets, possibly with ball bearings. That also adds to the weight. The fourth consequence: your more powerful servos will need more power, so you need larger and heavier battery, plus a stronger voltage regulator. It will also heat more.

But that doesn't end here. Once you have all those things, you can see that the weight of your robot increased even more! So you enter a vicious cycle of replacing part after part and redesigning your construction until it can barely bear its own weight and kinda limp about for several seconds until the battery runs out.

Now, let's consider what happens when you shrink your robot by half. It means that it became 8 times lighter. Of course, you had to make some sacrifices.

Your servomotors need to be smaller, but can also be weaker. The good news is that they get small faster than they get weaker, so you get quite nice amount of spare power. Also, until you pass the micro-servo size, the smaller ones are going to be cheaper (they get slightly more expensive when you get smaller than that, though). Your battery needs to be smaller and lighter, but it doesn't have to be as large anymore, so it gets cheaper. If you get down to 1S, it's also much easier to find charger modules and such for them. You can use practically any materials, so you can reuse parts that you already have, or easily make new ones. Your mechanical design doesn't need to be perfect. Sure, you will need more precision in some places, but you can also get away with just attaching something with a single screw. And you can just glue everything together anyways. Finally, you have to use smaller electronics. Your Raspberry Pi won't fit there anymore, so you have to look at the small micro-controller boards, or maybe something like the Vocore. You will have to program them in C or assembly, and you won't be able to do much processing on them.

All those pros and cons change non-linearly with the size. That means, that there are certain "sweet spots", sizes which are easier to design, build and handle, and there are areas of pain. I believe, that with Micro-Kubik I hit a sweet spot for the price and ease of building. It uses the cheapest servomotors available, and the cheapest available Arduino clone. Its legs are just the plastic horns that came with the servos, held together by the screws that came with them too. It uses a 2S lipo battery that is very popular for the cheap RC airplane models. The most expensive part is the Bluetooth module, but I used a cable just fine before. And you can have it walk on your desk, without the need for a workshop and a storage space. Oh, and you can drop it on the floor from your table without any damage. Mostly.

Sure, it's not a sweet spot for the processing power, or the number of sensors that I can fit inside (although I could have picked a bigger box for the body). But that can be worked around, and we see a lot of new small electronic parts appearing all the time, so it's getting better.

So my advice is: if you are just starting building robots, build something that fits in your hand and on your desk.

While I still can't get myself to write the code for using the accelerometer+gyroscope properly, I did recently do a small modification to this robot. I got myself a bunch of coin-sized 3A voltage regulators, so I replaced the UBEC that I used in this robot with one of those. That, together with shorter wires, saved me some space inside, which I used to add a Sharp distance sensor, and to position the accelerometer module a little better.

Now I can at least try to write some simple obstacle avoidance code...

I finally had some time to program a simple behavior using the new distance sensor. The robot follows whatever is in front of it, trying to keep a constant distance. When the object disappears, it stops and looks around for it. See the video:

One thing that made it a little challenging is that the output from this sensor is very noisy. I worked around that by keeping the last 10 measurements in a queue, and using the average of them -- a kind of a low-pass filter.

The PCBs just came from DirtyPCBs, and I had the servos waiting since some time already, so I made a brother of the µKubik. It uses pretty much the same cirtcuit as the pKubik, my other project, but uses the much cheaper, but bigger, SG90 servos. I also added a socket for a cheap ultrasonic distance sensor (much cheaper than the IR one used in µKubik). The software is exactly the same as for pKubik (I didn't even tweak the leg dimensions in the code, although I should).

The result is a budget version of the µKubik, with all the parts together at about $25.

It's a nice starting point for building walking robots. The serial and I²C interfaces of the Arduino are free, so you can use them to communicate with anything you want to add to the robot -- whether it's a more powerful processor, additional sensors or a laser gun. The software is also very simple and leaves a lot of room for experimenting and improvement. And you don't need any custom parts, except for the PCB -- the legs use the servo horns and screws that are shipped together with the servos.

I will keep on working on better assembly instructions and maybe an improved PCB design (the current one has some tight spots, where order of soldering is important). Maybe I will manage to somehow organize some kind of a workshop, or even a contest for building them. We need more walking robots everywhere!

After showing the robots at PyCon.us, I had some great conversations about all the possible ways I could improve them. One particularly nice idea is to connect some extra wires to the servo pots, and by measuring the voltage on them get some idea about their actual positions and (indirectly) the force being applied to them. To do it with all 12 servos, I would need 12 analog input pins, though. I can think about several possibilities:

• Use two arduino pro minis, each controlling two legs, with 6 digital and 6 analog pins.
• Use a 16-channel analog multiplexer chip. That requires 1 analog and 4 digital pins.
• Use a 16-channel ADC chip, possibly through I²C.
• Use an additional board with lots of analog pins, like Teensy 3.1.
• Only do force-sensing on the 4 most important servos (the ones that carry the robot).

I think I will start with the last option, mostly because that doesn't require changing much and it will let me see how well this actually works. Then I can try one of the other options if needed.

I separated the Arduino-only version of µKubik as a separate project, called Tote, with comprehensive build instructions available at http://tote.readthedocs.org/

It's supposed to be a starting point for people experimenting with their own quadrupeds.

As I'm writing the guide for building and programming this robot, I need a way to test if the instructions make sense and are simple enough. So I've build another brother for µKubik, this time following my own instructions to the letter. It went well, except I didn't count how many servos I have available beforehand, and I ended up one servo too short. Oh well.

On the good side, the version with most of the parts mounted underside actually works very well and is very compact. Also, there was no servo reversing necessary, so the robot walks pretty much out of the box (you do have to adjust the default servo positions).

Now I will try and add an ESP8266 module to it, with Micropython firmware, and see if I can control it that way.

So I finally came around to testing this setup. A 9g hobby servo, with an additional cable hooked up to the middle pin of its pot, and connected to an analog pin on the arduino. Voila, now we can sense the position of the servo. Kinda.

Turns out that even with a lot of small capacitors all over the place, and software smoothing of the signal, I still can't get more precise than about 2°. Which is actually quite nice already if the only thing you need is to tell if your servo "got there" already.

But I wanted much more. In particular, I wanted to be able to tell the magnitude and direction of the force working against the servo. Then I would be able to tell if the leg is supporting the robot's weight at the moment (and hence wasn't put in the abyss beyond the table), or even implement compliant motion, like in this video:

Alas, turns out that it's not so simple. The pot measures the servo's position quite well when it's unloaded. but as soon as you put any load on the servo, the reading is going up -- and that's no matter in what direction you apply the load. That's not so good, and I think it may have somethig to do with voltage drop on a loaded servo. I will need more experiments.

So, a little bit of rethinking what I actually need, and the solution became obvious. I don't want to know the position of the servo, I want to know the force that is affecting it (and, at the same time, the force that the servo is using to counter that). So, it doesn't make sense to add the additional wire to the pot. I want to know how hard the motor is working -- so the additional wire should go to one of the motor pins. From that a couple of simple experiments, and I have my "compliant motion", more or less:

Of course, the code is very crude, so it's easy to get oscillation or runaway, but in the end I will use it for robot's sense, so it will not feed itself...