Tremble before DISHZOR!

People are often surprised them when I tell them that my favourite robot is the dishwasher. Not Megatron or ASIMO or the roomba - just your ordinary, garden variety dishwasher.

You see, there isn't much of a consensus regarding what defines a robot as a robot. Some people think they need to be humanoid. Others feel that robots should include sensors and actuators. Computers and software are often mentioned.

One of the broader, but generally well received definitions is that a robot is a machine of some sort, capable of performing tasks on it's own. Begrudgingly, most people will admit that this would include dishwashers. And washing machines, printers and even modern cooking appliances.

Thats right - robots have already invaded your home and you didn't even realise! Insidious!

I think one of the reasons that these everyday robots have slipped under our radar is that we don't have such high expectations of them. We assume robots should be smart, since they are capable of performing the same tasks which humans can - but we tend to assume that tasks which are difficult for us are difficult for everyone.

Sci-Fi has led us to bestow a level of expectation on a robot which is based on their appearance. For example, dog shaped robots tend to be about as smart as actual dogs, despite the fact that their positronic brains could make them just as smart as a human. Robotic bugs will behave exactly like real bugs would, even though they have no reason to seek dark places or put on threatening displays.

In the case of dishwashers, we tend to assume that machines shaped like large bricks will have an equivalent IQ. That's probably why I find this so much less impressive than it actually is.



It's no small feat, but it just seems that a multi robot system like that should be capable of so much more.

This phenomenon also means that as soon as you give your robot a humanoid form, people suddenly have much higher expectations. I think this is why modern demonstration robots are given infant-like designs - if the robot reminds people of a five year old, then they will be that much more impressed when it walks without falling over or grasping objects.



So if you are ever trying to demonstrate how smart your robot artificial intelligence is, remember to make it look stupid so that people will be extra impressed. It also helps to avoid the uncanny valley.

Come with me - if you want to live.

I finally watched Terminator Salvation the other night.

I couldn't work out if the machines actually knew who Kyle Reese was or why they wanted to capture him - and also why they didn't just kill him when they had the chance!

There was also the matter of how lightly guarded skynet central was (despite apparently producing about 1 T800 per second), and how those motorcycle robots were supposed to get up if someone knocked them over.

What I really wanted to talk about though, was the Robopocalypse. Not so much the idea that robots will eventually rise up against their human masters, but just about how robots (or any machine) can be dangerous if people are careless around them.

I used to be vice-president of the Sydney University Mechatronics Organization, which held a yearly robot wars competition. Now, as you can imagine, robots designed to tear each other to bits would be equally (more?) effective at maiming pathetic squishy humans, so it was hard to disregard OH&S.

Despite a strong emphasis on safety, the university was in a difficult position when it came to allowing students to use their facilities. If we were injured in one of the workshops or laboratories, then the uni was liable - even if we were being properly supervised or if it was due to our own negligence. However, if we attempted to work on the robot outside of the university, we were without the appropriate tools and safety equipment and were significantly more likely to injure ourselves. This created many headaches and administrative woes, which ultimatley turned what should have been a fun and simple activity for students into a legislative nightmare.

This is why I am so much in favor of the smaller and safer robo-one style competition. I think it is a more elegant form of robot combat, for a more civilized age.





This video is from a new humanoid competition called RT Corp under 1kg Robot Fight. Like robo-one, it emphasizes lightweight robots which wrestle each other in a ring.

I think that this is a better direction for schools and universities who want to encourage students to learn about robots and mechatronics while having a bit of fun.

1. Robot wars robots are glorified remote control cars. There, I said it. Many designs, like wedges or saws don't need any additional circuitry to control their weapons. The design is primarily in the mechanical field, and students will learn very little about the electrical or software side.
2. It's so much safer. There are no dangerous weapons, and the weight limit is also much lower (unless you're these guys). The machining process is also much simpler (use tin-snips instead of table saws, solder instead of welding, etc).
3. You get to keep your robot at the end. One of the most annoying things about robot wars is that if you lost, your robot was toast. Nothing gets damaged or destroyed in a wrestling match, so you are free to upgrade and modify parts for next time.
4. The emphasis is on design and technique, not raw power. Software, real-time control, electrical systems and weight distribution are just as important as how strong your motors are.
5. It's just as exciting. Robots can take their inspiration from boxing, tae-kwon do, ju-jitsu, MMA, akido, pancrase or any other type of martial art.

The biggest drawback is that it can be quite expensive to build these little guys, but probably not by a huge margin. Our 13kg Robot wars Robots cost $300-500 (excluding the remote controls, which were borrowed), but I can see a under 1kg robot being build for a similar amount.

If that doesn' convince you, just look at how much fun these guys are having!

One step at a time

Happy New Year Everyone!!

I'm back from a short holiday down to the Melbourne Cricket Ground to watch the Boxing Day test. It was very relaxing, but now that I have returned I have lots of robot news to share!

Firstly, despite being unable to find wCK gears anywhere in the southern hemisphere, I have sort of fixed the broken knee servo. Thanks to an emergency surgical field graft, he can now walk fairly normally but has lost the use of his right arm. Apparently I'm not the only person who is having problems with the plastic gears. If you are concerned about damaging your own servos, I suggest you set them to the lowest torque setting. Note that 4 is the LOWEST torque setting, and 0 is the HIGHEST - the manual could probably be more forthcoming on this point.

Now that he's up and mobile again, I've resumed work on getting him to keep his balance while standing.

Whenever I start work on an ambitious project, I find that the only way to keep on track is set myself small targets along the way. I am always coming up with ideas that are easy enough to design, but take far longer to implement - and more than a few of them have fallen by the wayside because my eyes were bigger than my stomach.

So having small, short term achievements keeps me motivated to move on with the long term goal. A very simple method of controlling complex systems (particularly when computing power is limited) is called discrete state-space control. Rather than trying to model the system and predict how it will behave, the system is manually broken down into a discrete set of inputs and outputs. Then, using some very basic rules, the behaviour of the system can be described in very simple terms like: if A, then B.

In the case of the robot trying to maintain it's upright position, you can simplify things by firstly holding most of the joints rigid. Using the feedback information from the ankle servos (04 and 00), you can predict if the robot is tilting too far to the left or right. Then, depending on which state the robot is in, it can take the appropriate action to regain it's balance. Simple, no?



In the video, you can see the robot measuring the angular velocity of it's ankles, and detecting when it's balance is being compromised. It simply steps away from the force to maintain it's stability - just like a human would.

Right now, it only work for left and right - simply because the canned robobuilder animations for forwards and backwards consist of several steps, meaning I will have to write my own motions.

I should probably start putting together my own library of poses anyway, since I'm not too happy with the default ones. The walking and turning motions have a real problem on many surfaces - polished wooden floors are the best so far, but far from perfect.



Here you can see that the robot is having problems moving in the right direction with the stock SidewalkRight/Left actions, to the extend that he goes the wrong way! Because he was off centre to begin with, one foot is carrying most of his weight, so he pushes against the ground and towards my hand.

Code will be available soon, once I've cleaned it up a little and found a nice place to upload it. I think that robosavvy has personal file space for it's members, so I will see if I can make the files public.

Phase 1: Collect underpants.

In the absence of a robot capable of supporting it's own weight, I've started planning my next move.

The purpose of writing my own firmware for this robot is purely academic. I don't have a specific goal in mind for this project, even though I'm sure we would all enjoy a robot which could clean our house, bring you drinks, or make us coffee.

As I develop more and more features, I can share them as code snippets which will help other people with their projects. Of course, when I decide I want to revolutionize the coffee robot industry, I will be adequately prepared.

Now that I have figured out how to use the servos as sensors to get feedback about the robot's position, I plan to implement an inverse kinodynamics engine to enable balance without an accelerometer.

For those who aren't down with the lingo, kinodynamics is a contraction of kinematics and dynamics.

Kinematics is concerned with modelling the behaviour of a system given a physical and geometric configuration. In the case of the humanoid robot, this means calculating the relative location of the arms, legs, feet, etc, simply given the angular position of each of the 16 servos. This can be calculated (relatively) simply using basic (again, not something you'd find next to the funny pages) vector mathematics and trigonometry.

Now, dynamics. Kinematics merely describes the geometry and structure of an object. It's velocity, mass, angular momentum and behaviour when subjected to a force are all in the domain of dynamics. When your robot falls down the stairs in a hilarious but tragic accident, his dynamic behaviour determines how long you will watch in abject horror.

So, a kinodynamic model of a humanoid robot can be used to generate a fairly reliable prediction of the state of a robot at a future instant, given the current state and control space.

Put more simply, this model can be used to calculate "safe" actions, which will result in the robot performing a motion while keeping it's centre of mass over it's feet - in other words, balancing.

These are all quite lofty goals, and right now it looks complex, but I'll outline more details in future posts.

Stay tuned for Phase 2: "???"

All work and no play

I was just reading over some of my previous posts, when I suddenly realised:

They are really boring.

Useful - I hope - to those of you who are interested in building humanoid robots, but probably not that exciting to read.

There were two reasons I decided to create this blog. Firstly, I wanted to have what I have just now decided should be called a "blogbook". This is a collection of my notes on the project of writing software for my humanoid robot, so that I can refer back to it when I forget something, or at least a space where I can get my thoughts to sit down and stay in one place. Making it avaliable online adds the important contribution of allowing other people to read about my mistakes, and how not to make them.

The second reason for starting this blog is that I find humanoid robots completely fascinating. I find that enthusiasm is contagious - everyone has a favourite science/music/drama teacher who was so passionate and dedicated to their subject that they made learning something you wanted to do. I hope that reading about my endeavours will encourage more people to learn about robots and the field of mechatronics. Perhaps you will start your own robotics project.

Up until now, most of the posts have fallen very much into the former category, so the remainder of this post is dedicated to the latter. Lets look at some cool robots!



First up, we have HINA by mujaki. I personally love this video - when I first saw it, it set my imagination on fire. All of the servos and parts are completley custom made, and it reminds me of Plum and Kotoko from Chobits. Not only does it bridge the uncanny valley most successfully, but the video demonstrates exactly why we all should want a tiny robotic servant within the next 10 years.



The red robot is an early version of Omni Zero - before he put on all that weight. I find it interesting the way that he jogs in place, which I assume is a method of getting feedback for him to have dynamic balance. The best thing about Robo-one is that it tackle's the problem of bipdeal robots so casually - for decades, the problem of humanoid robotics seemed unsolvable, but now it's progressed to the level that robots can not only walk - they can wrestle.

It's Alive!!

The Robobuilder kit is actually really easy to put together. Inspired by similar robots, I chose to assemble the HUNO configuration.

The instructions are very easy to follow, but here are a few things that I learned which might make it easier if you are having trouble.

Firstly, whenever I build something, I assume I will make at least one mistake. This might mean undoing and re-doing several steps, so I never tighten anything down completely. This has the added advantage of making it easier to line up parts which are already attached to the assembly. Most of the wCK servos are attached to the frame using four screws, but only two are necessary to fully constrain the unit. Once I had fully tested the robot, I went back and put the other two screws in each of the servos.

I was glad I took my own advice when I realised about 4 steps in that the numbers on the servos actually matter. I should have realised this earlier, since the servos are daisy chained together, so they must need to be addressed in some fashion. It is possible to reassign the ID numbers on the servo, but all of the examples and tools assume you have assembled the model as shown in the instructions.

The little spanner shaped connectors have a tiny bronze threaded nut in one side of them. If the bolt you are using isn't exactly lined up with the hole, it has a tendency to push the bronze nut out of the plastic. Once out, it's really hard to get back in, so make sure that you can see right through the hole before you put the bolt in.

Finally, I strongly recommend attaching the arms (steps 15 and 16) before attaching the legs (step 14). The legs are very heavy and tend to flop around while you're trying to orient the arms to put the bolt in. The arms are much lighter and won't move under their own weight.

Anyway, without further ado, here he is!


Isn't he cute?