Build The Robot

Now 80% more Handy!

2011-02-08T02:20:00.001-08:00

I had a birthday not long ago. I've always valued practical gifts over expensive ones, and this year I made a special request to friends and family for things which would make working at my new job just a little bit easier.

When it comes to gadgets, there is a thin line between practical and gimmicky, but I am pleased to report that I couldn't be happier with everyone's choices.

Topping the list are the leatherman multitools. One might expect that two would be one too many, but they complement each other nicely. The first one is a full sized tool which finds use primarily as a bit driver (I am forever absent mindedly putting down screwdrivers and then not having the right size), but which also has pliers, wire cutters, and absurdly sharp knife. I believe it has wire strippers too, but years of incomplete toolkits from university labs have taught me that there is no substitute for teeth.

The other multitool is a keychain sized leatherman which (in addition to another set of smaller screwdrivers) I mainly use as scissors. "What?" You exclaim, "Are scissors at such a premium that you need to carry a pair with you all the time?" Sort of. Next time you are opening a package - food, electronics, shrink wrap - stop and think about what your options are. You can:
a) walk to the kitchen/study and hope whoever used the scissors last has remembered to put the back,
b) use a knife/pen/teeth to bludgeon you way in (god help you if you want to repeal it again), or
c) assault the packaging like an enraged gorilla.

I've put my keys on the keychain one, and I carry the full sized one with me whenever possible. Combined with my other two "tools" which I have on me at all times (a smartphone and a 16gb USB stick), I find that there is almost no problem I lack the equipment to handle. The other day I was able to field strip my ps3 (along with the warranty) in less than an hour.

Obviously my technical experience as a hobbyist plays a large part in making good use of the tools at hand, but I didn't realise how much of a difference it makes having good equipment at you fingertips. Obviously, having a workshop and a full toolbox would be a further improvement, but as a hobbyist living in an apartment these tools have really boosted my productivity.

As a side benefit, I'd say that my zombie apocalypse survival rate has at least doubled.

Published with Blogger-droid v1.6.5

Artificial Intelligence for Fun and Profit!

2010-12-15T16:36:00.000-08:00

AI is one of those buzzwords which get's thrown around without people really understanding what it means.

Before I continue, I would like to mention that "Cloud" is by far my least favorite word du jour. There is no such thing as the Cloud! Just because you can't see it doesn't mean it is some kind of panacea! Everything still happens SOMEWHERE on SOME COMPUTER, and that computer can still fail!

Sorry, side-rant over. Where was I?

One of the biggest hurdles is defining "Intelligence". Even wikipedia doesn't have a simple answer. whenever I'm asked the question though, I usually go with:

"Intelligence is the ability to solve a wide variety of problems with a limited set of tools"

Which applies very nicely to robots.

Robots need to be more than just state-machines. Generally, robots have tasks or missions, and they are given a set of tools to complete the task. An intelligent robot needs to have the capacity to alter it's behavior to complete it's mission even if the environment changes. This is where artificial intelligence and machine learning play a role.

Many AI techniques can be thought of simply as optimizing techniques. There is a feedback loop (which may be supervised or unsupervised) and an algorithm which is capable of altering itself to satisfy some condition of the feedback.

In a previous post, I mentioned using Genetic Algorithms as a method of creating "intelligent" (per the definition above) robots. Every individual in a population is a "pilot", which takes turns to "drive" the robot. The pilots who are most succesful at the mission get to "train" the next generation of pilots.

Conceptually, this is not a bad way to get a basic adaptable AI working for a robot. Every individual's genetic code is represented as a decision making algorithm which decides what action the robot should take given the input (if any) from the sensors.

My somewhat clumsy implementation involved a 2DOF robot "inchy the inchbot", which learned to crawl forwards using a distance sensor mounted at the back. Every individual had 100 actions in which to move the furthest possible distance - after a few hundred generations, this is what happened:

My sincere apologies for the horrible webcam video. This was a good proof of concept for me, but there were a few things which need improvement:

All individuals get a chance to "drive", even if they suck at "driving" particularly in the early generations, this meant that the robot was just as likely to go backwards as it was to go forwards. On a real mission, this would be unacceptable, since a bad driver might put the whole robot in harms way.
The method of encoding the pilots in the GA was too prone to sudden changes. I used a heuristic function which evolved by swapping and switching operators in a tree format (more on this later), and this meant that even in later generations there was no shortage of evolutionary throwbacks.
The combination of 1 and 2 meant that even though the population as a whole did get fitter, the robot would sometimes spaz out or just stall for apparently no reason.
Another huge drawback was that each individual was very selfish. The individual had to regard for the (sometimes awkward or precarious) position it would leave the robot in for the next individual who drove the robot. The next individual would then have to waste some its "actions" to extricate the robot from a weird configuration - this mean that sometimes even the best individuals would under perform unnecessarily.
In this particular application, the tendency for genetic algorithms to "Cheat" was very apparent. The sensor was mounted on the back, and early tests resulted in the robot simply pointing the distance sensor at the ceiling to maximize the "distance traveled" =)

This was a good proof of concept test, but I might need to re-examine some of the details. I don't know of many applications of GAs to do this kind of robot decision making, but if someone has some references I would love to hear about them.

Where I've been

2010-11-27T15:54:00.000-08:00

It's been a very long time since I posted anything, hasn't it. In case you were wondering if I had a good excuse or not, here is a list of things that have happened since my last update:

Got a part time job,
Got a full time job,
Learned lambda calculus and LISP,
Wrote a programming language and a compiler,
Learned to sing,
Sang on stage,
Held some more Robot Wars competitions,
Handed over the society to next year's president,
Put together a tender bid for work,
Won the contract,
Bought and built a new computer,
Set up a home file server and uPnP media server,
Accidentally erased my MFT and boot sector,
Managed to restore them,
Built and programmed a robot for the New Inventors TV Show,
Appeared on TV,
Studied for exams,
Finished university

So yeah. I've been busy. Fortunately, each of these is an excellent story which I hopefully will be able to recount here in the future.

But now that that's out of the way, we can get back to talking about robots.

I've been following the Google AI challenge (http://ai-contest.com/) and I highly suggest you check out the forums. Were it not for the aforementioned points, I would have loved to put an entry in, but as I write this there are only 6 hours left to go for submissions. Ooohhh.... now there's a challenge....

I also wanted to bring your attention to this amazing post. Give it a read while I go beat my head against the wall for even considering giving myself MORE things to do.

Hungry Hungry Robos!

2010-07-05T21:07:00.000-07:00

Hungry Hungry Robos was an event for the 2010 Sydney University Robot Wars teams to get a chance to test their robots before sending them into battle. It was the first chance teams had to try out their robots and it was also heaps of fun.

The rules are very simple: The robot with the most marbles in their corner (taped off squares) when time runs out is the winner!

Below is the poster I designed to promote the event. As you can see from the dates, this actually happened ages ago, but I've been to busy to cut everything together until now. The next event will be some time in August.

Edit: Fixed the broken encoding on the video. Fun fact: This video took longer to encode than the entire event took to organize! Peas out.

Sweet Zombie Jesus!

2010-05-29T16:18:00.000-07:00

This was too cool not to post.

I was also reminded of this single bladed UAV. Unfortunately, this design is pretty useless, since any efficiency gain you get from the one large blade to provide lift is overwhelmed by the tiny, multibladed propeller doing all the work. Still, it looks cool.

Coming up next: Sydney University Robot Wars videos!!

Bayesian Classifier Answers the Question: "Is it art?"

2010-05-07T00:01:00.000-07:00

The title is a joke, by the way. Although I would be interested to see what the results of such an exercise would be. "Statue of David... *beep*: ART!", "Justin Beiber's Music... *beep* NOT_ART!".

Almost as exciting as my 0-R Spam filter. Catches 100% of spam with a 97% accuracy rate! Oh mercy.

The reason that I mention Bayesian Classifiers is because I wanted to talk about machine learning. This is the other branch of artificial intelligence and what most people think of when the topic of Skynet is brought up.

Fear not though. Bayes rule, decision trees and rule based learning are actually pretty mild. They are simply statistical methods of attempting to classify data by using the results of previous observations. Mostly harmless.

However, today I'm going to talk about genetic algorithms.

A genetic algorithm is an abstract representation of a mathematical function. They can take many forms, such as a string of bits which might indicate the presence/absence of a set of inputs, or a literal mathematical function "y = cos(x) - 2*z". The range of variables which is represented by the function is called a genome.

This can get a bit hard to visualize, so I often just settle for imagining genomes as Taylor polynomials. Therefore, a single genome consists of "x = A*input1^a + B*input2^b ..." where the values of A and a can take any real number. If some of the inputs are simply a higher derivatives of other inputs, then any arbitrary function can be represented in this way. There is also a rather nice representation involving trees.

If we start off with a population of individuals with random valued variables in their genomes, then we can evaluate each function to see how well it 'fits' a set of training data. The individuals which produce the minimum mean squared error for the training data are declared the 'fittest', and are allowed to survive into the next generation.

This is where the 'genetic' part comes in. There are many ways of 'evolving', 'mutating' and 'breeding' individuals, but the easiest to understand is the asexual method. This means that all individuals except the best performer are killed off (ie, deleted) and then their places are taken by the offspring of the remaining individual. However, tiny random 'mutations' are introduced to each of the new individuals variables - such as doubling/halving the values of A or B, or incrementing/decrementing a or b.

Anyway, thats the 30 second version of genetic algorithms. They can be used to find a semi-optimal solution to many problems, provided you can throw enough generations at them. I have been working with a C++ implementation called GAlib. If you are interested, I highly recommend going through the examples.

Now, some of you may be wondering what all this has to do with robots (actually, most of you are probably already filling in the blanks and peeing your pants in terror).

I've spoken on several occasions about using Robobob as a platform to investigate dynamic balance and movement. I plan to represent the control state of the robot as a search tree, with the robot beginning at a starting node/state and attempting to plan a path of control actions to reach a goal node/state. To navigate the tree, I want to implement a greedy search heuristic which will choose which control actions are most likely to lead to the goal state.

Now here's the tricky part - I intend to implement the heuristic as an evolutionary algorithm which can then be rewarded or punished depending on the outcome of executing the control path on the real robot. ie, if the heuristic gets stuck or can't find the goal state, it will be disfavored whereas successfully reaching the goal will be favored. After a series of generations, I will be able to study the path planning method which has evolved from this process.

Cool? I hope so.

Terrifying? Definitely.

Algorithm eats sandvitch in O(mn)O(mn)O(mn)O(m) time

2010-04-18T01:22:00.000-07:00

I've been doing a lot of research on artificial intelligence recently. I'm toying with the idea of using it to help solve the inverse kinematics problem of a humanoid robot. I've already started work on extending robobob's firmware with some AI functions, which I'll share in a few updates. I don't know how well this will work out, but since future topics will probably include a fair bit of artificial intelligence talk, I thought I would put up a brief intro to AI and some common search strategies.

Many people are underwhelmed when they start learning about AI. Sci Fi has delivered promises of robotic servants, androids, and positronic brains - but even state of the art AI still struggles with simple real-world problems that humans find trivial. However, AI still as much potential if you are able to appropriately abstract the problem into a form that an AI strategy can handle.

One of the most basic methods of problem solving is searching. If you break the problem down into a starting state, a goal state, and a set of operations allowing traversal between states, then you simply search the tree until a goal is found will provide a method of solving the problem.

This is why AI excels at games but fails at life. Games are easily distilled into a set of rules with clear conditions for victory. Using a searching strategy, possible configurations can be tested until one set of moves leads to a win. However, attempting to distill real world problems into a 'game tree' is even more complicated than it sounds since there are far too many options at each planning stage.

Below are some commonly used searching strategies. This is just a quick summary of each one, but it is important to know a little about how searching works in order to appreciate the more intricate levels of AI.

Breadth First Search

In a Breadth First Search, children of the most recently expanded node are added to the end of the fringe. Since nodes are explored one by one in the order they are placed in the fringe, nodes closer to the root of the tree will always be expanded first.

Since nodes closer to the root are expanded first, the algorithm will terminate when it finds the goal which requires the fewest operations to reach. In cases such as pathfinding, where the cost of traversing from one square to the next is constant, the solution closest to the root is the optimal (shortest) solution. However, every node which is closer to the root than the goal will be expanded before the goal is found, and this can lead to breath first search can opening an excessive number of nodes.

Depth First Search

Algorithmically, this search strategy is identical to Breadth First Search, except for the order in which the children of expanded nodes are added to the fringe. When a child node is discovered, it is added to the front of the fringe instead of the back. This means that the next node to be expanded will be one of the children of the open node and hence nodes which are further away from the root are explored before closer ones.

Depth First Search will keep traversing down the tree until it finds a terminal or a goal node. If multiple goals a present (eg, all terminal nodes are goals), then this strategy may find a solution much faster than Breath First Search, but it may not be the best solution. However, if the tree is particularly complex or has a very high branching factor, finding any goal quickly might be a better outcome than finding the best goal too late. On the other hand, some paths may have an infinite depth which will cause Depth First Search to never find a goal.

Greedy Search

Unlike BFS or DFS, where the ordering of nodes remains unchanged as the algorithm discovers new nodes, the greedy search method maintains a continuously sorted fringe of unopened nodes. The metric used to determine the order is known as the heuristic function, which is used to estimate the best node to open next. It doesn't matter how far away a node is in the tree or when it was discovered – the node opened by a greedy algorithm is governed only by the heuristic value of that node.

The effectiveness of greedy search lies in the strength of the heuristic function used. A good heuristic function should estimate the cost of reaching the goal from the node. Every time a new node is opened, it will be the 'best choice' to find the goal according the heuristic. Of course, if the heuristic is poor then there is no guarantee that the path will be optimal or that a goal will even be found at all.

A* Search

Like greedy, A* maintains a sorted fringe using a heuristic function to estimate the value of each node. In addition to using the heuristic to determine the order of the sorted fringe, A* also includes the cost of reaching the node from the root of the tree. Therefore, if two nodes are evaluated equally using the heuristic function, the node which is closer to the root will be opened first.

A* combines the predicted (heuristic) cost of reaching the goal from a node with the true cost of reaching that node from the root. This means that the nodes are explored in terms of their overall path cost, unlike greedy which sorts the nodes only according to their distance from the goal. If the heuristic used by A* never overestimates the distance from the node to the goal, then A* is guaranteed to find the optimal solution by opening fewer nodes than any other optimal strategy.

Hill Climber

Hill Climber searching is slightly different to all the other algorithms presented here due to the fact that it doesn't maintain a persistent fringe. The next node opened is simply the child of the open node with the best heuristic cost. Hill Climber differs from greedy because it 'forgets' about nodes which have already been discovered (regardless of how good they were), and focuses only on the immediate children of the open node.

Sometimes, the tree which needs to be searched is simply too large or too complex to be handled by an optimal searching strategy. In this case, using Hill Climber to find the 'local minimum' of the tree is often the best way to handle such situations. The algorithm is very easy to implement, since there is no need to maintain and sort a fringe of all the nodes discovered so far. However, the algorithm may completely miss the goal node if the heuristic leads it into a 'local minimum' where every node in the fringe is valued to be 'worse' than the current node.

Hark! An update!

2010-04-03T16:38:00.000-07:00

About time too. I have recently been busy organizing a Robot Wars competition for Sydney University, and haven't had a lot of time to work on Robobob. However, this will ensure that there will be plenty of cool material for future updates, so I hope you are all looking forward to it as much as I am!

Things are still in the concept phase at the moment, so it will be a while before I can post something tangible. In the meantime, here are a few videos to get everyone motivated:

Also, if you would like to contribute to making this Robot Wars competition as exciting as possible, click on an Ad! All proceeds from this blog will go towards the construction costs!

Honour thy compiler and thy linker

2010-03-07T14:48:00.000-08:00

Remember how when you were learning to program, your tutor/teacher/zen programming master always told you turn on all compiler output and to make sure that you dealt with all the warnings?

It's vaguely possible that they knew what they were talking about.

In the most recent version of the code, I wrote a wrapper function to streamline the procedure for executing a set of actions. As I explained in this post, the tables for robobuilder's actions consist of Nx16 unsigned char multidimensional arrays which are in the PROGMEM area of the chip.

A multidimensional array can be expressed in two ways. Interestingly, most of the time the two types are functionally and syntactically equivalent - they only differ by the method by which they are stored in memory. However, these subtleties can make all the difference when you are performing low level operations.

The first way is as an indexed array, which stores all the data in a sequential memory block. A matrix of data declared:

int matrix[3][2]; 

You address the elements of the matrix by row, then by column:

matrix[2][1] = 6;

Assigns the value 6 to the last element in your matrix. Because the compiler knows that the array is supposed to be 3 rows by 2 columns, this statement is equivalent to:

((int*)matrix)[(2*COLUMNS)+1] = 6;

(Given that COLUMNS = 2. Don't forget that C arrays start at 0.)

The second way of defining a multidimensional array is as an array of pointers or an array of arrays. In this case, the blocks of memory are not necessarily arranged sequentially in memory. The following declaration:

int r0[2], r1[2], r2[2];

int* matrix[3] = {r1,r2,r3};

will create an array of three pointers, which point to the start of the row arrays. However, r0-2 may not be in sequential memory. Some compilers will make an effort to put them together, but there are no guarantees.

Elements can be referenced exactly the same way as before:

matrix[2][1] = -6;

Assigns a -6 to the last element of the array. This works because of the order of evaluation: you dereference the third pointer in the array 'matrix' first, and then address the second element of THAT array. No matter how you define your array, you can use the same syntax to manipulate it.

So far so good, but here comes the tricky part.

When you pass arrays as an argument to a function, you always do so by reference. For one dimensional arrays, it doesn't matter if you use:

void func(int * array);

void func(int array[]);

in either case, what is being passed to the function is a pointer to the start of the data block.

People are also introduced to the concept of a "string as an array of characters", so an array of strings has the type "pointer to a pointer of chars" (char **). Because C uses null terminated strings, this will work fine and you shouldn't receive any warnings.

All this leads to the mentality that arrays and pointers are interchangeable - but this is only sometimes true. This is exactly the trap that I fell into when I declared this function:

void runAction(unsigned char ** flashpos, ...);

Officially, this is not a problem as long as I dereference the variable flashpos correctly - after all, it is pointing to the start of an array somewhere. It points the start of a sequential Nx16 table of chars. As long as I use the correct number of dereference operators in the right order, I should be able to access it's delicious chocolatey elements.

Hence, there was no compiler error.

What I got instead was the warning: "Incompatible data types in arg 1 of blah blah blah."

Warnings are usually thrown when the compiler is letting you know that you might be doing something you didn't intend, but it's not something illegal so it figures you know what you're doing.

Foolishly, I assumed that the error was being thrown due to a signed vs unsigned conflict and went ahead and cast the argument being passed into an (unsigned char**).

Then, I proceeded to access the data like the multidimensional array that it was:

x = pgm_read_byte(flashpos[i][j]);

Robobob went haywire. Can anyone see what went wrong?

The problem was that the compiler didn't know how many columns the table had. It's the equivalent of me giving you a book and asking for the 4th page in the 10th column. It doesn't make any sense unless you know how to arrange the pages!

You see, it would have worked fine if I had just used the form:

x = pgm_read_byte(*(flashpos+(i*16+j)));

But in the absence of the necessary metadata, the compiler had attempted to use the second form of referencing described above - i.e., the jth integer pointed to by the ith pointer in the variable flashpos. Which of course sent it searching for arbitrary values all over the place.

After I realised what was going on, all I had to do was simply change the declaration to:

void runAction(unsigned char flashpos[][MOTORS], ...);

Which informed the compiler of the subtype and dimensions of multidimensional array being referenced.

Always remember that warnings are there for a reason! Maybe you do know best, but the compiler is letting you know that you've done something ambiguous or potentially dangerous.

Robot destroys car, house, you

2010-03-02T19:25:00.000-08:00

I think it's supposed to be a bomb disposal robot, but I think the bomb might do less damage.

Congratulations! You're our 2000th visitor!

2010-03-01T04:39:00.000-08:00

Thats right, today marks the day that over 2000 people have visited this blog! I would like to thank you all for your interest in my work, and I hope I can look forward to many more visitors over the coming year. I've added a variety of social media links to the right sidebar, so please share this with your friends!

To commemorate this occasion, I present to you version 0.4 of the custom robobuilder software. This version includes timer-based scheduling of movement, battery recharging capabilities, microphone operation and the ability to change state based upon button presses. A few small bugs have been fixed since last time, but as usual this is still a beta release - don't expect flawless operation just yet. Compiling instructions are here.

Unfortunately, this release does not contain the FFT or leet dancing skillz. I've decided that I'm going to put a bit more work into improving them before I make them available for download. I'm sure you are all eager to get your groove on, so check back soon for updates.

In related news, this guy has given me many ideas for how to expand robobob's repertoire of dance moves.

And he's not even in time with the music! Of course, that's just the beginning...

Robobob: Life of the party

2010-02-23T23:21:00.000-08:00

Dancing robots have been around for some time now, I'll give you that. Generally they are simply scripted lists of moves which are synchronized (or not) to a particular song. It took some hard work, but I've managed to take a different approach:

This dance isn't scripted! It's being generated based on the music being played, which means that Robobob will dance in time with any music you care to play to him!

Well, most music. The tempo is detected using a Fast Fourier Transform, which can separate beats and bass-lines from the rest of the music. This works great for songs with a strong bass component, but doesn't work so well on music composed of higher frequencies or vocals.

Simply place your robobuilder on the nearest sub woofer though, and you should be in business!

Watch in amazement as your robotic buddy dances along (almost) in time to the beat!

Impress your friends with his funky dancing styles consisting of over TWO distinct moves!

Computers 103

2010-02-13T23:58:00.000-08:00

The gnome is back! This time, he has a very important message for you about registers. Please give him your undivided attention, or there may be consequences. 0_o

I hope you are enjoying these comics. I will be making more of them, but I am also working on upgrading Robobob. I think you will be pleasantly surprised, so check back soon!

Computers 102

2010-02-10T15:12:00.000-08:00

For your amenity, the next installment of "inside your CPU" is avaliable below. If your screen is big enough, you shouldn't even need to scroll. The previous issue can be even be found here. Convenience!!

(If you don't get the joke in the last panel, it is because the "take one down" action will eventually set the zero flag in the status register, but the "pass it around" line will never set the zero flag. The branch instruction can only know about the results of the operation immediately before it, so the gnome will eventually die of alcohol poisoning. THINK OF THE GNOMES!)

In other exciting news, the source code I used to make this video is now avaliable. You can find it here. There are a few improvements and bug fixes.

Computers 101

2010-02-09T19:24:00.000-08:00

I'm taking a little hiatus from the epic how to build your own robot series for a few reasons.

Firstly, there is a LOT to cover. I'm writing this as a sort of trial run for how I might explain it to first year university students, and as we all know - firsties are only marginally more intelligent than the rats they experiment on. With so many topics to cover, I'm faced with either giving 10 second "just take my word for it" style advice, or deviating from the topic every paragraph to explain the reasoning behind the statements I've just made.

The other problem is that it isn't fun to read. It's very technically dense and wordy, and I feel that if I can't hold the reader's interest then there isn't much point in me spending all this time explaining it. After writing the how to choose servos article, I really felt that I should have introduced it with an earlier article about exactly how they worked and what they were used for.

So to remedy this, I've decided to take a different approach to the rest of the series. Before I start spouting off about software and microcontrollers and interrupts, I'm going to give you some background on the subject in general – just so that everyone is up to speed when I use terms like instruction set, word size or stack overflow.

What's more, to keep things interesting the lessons will take place in funky 8-bit comic style! Enjoy!

Build your own humanoid - Part 2

2010-02-09T14:55:00.000-08:00

Last time, I started going over a basic outline of how you might go about designing your own humanoid robot.

After I finished writing part 1, I realized that there is a lot more to cover on each topic than I am able to explain in a single post. All I am covering here is a design methodology - one of many possible procedures. This means that if I skim over a topic or don't go into sufficient detail, you will need to do a bit of research on your own to fill in the blanks.

After deciding upon the number of degrees of articulation you intend to build into your robot, I suggested that the next step should be to draft up some approximate measurements for the arms, legs and body.

Some people find this difficult. Coming up with a number for a length or a weight almost without any input information seems pointless and arbitrary, since there are so many variables which affect and are affected by your decision. This is why I emphasize the inexact nature of these dimensions at this stage. We will come back and refine them once we have more details.

If you have the time, the tools and the expertise required to draw up an exact model of all the designable variables and how they correlate to each other, then this is a perfectly acceptable method. I personally find the iterative method is easier and less prone to mistakes.

At this stage, you would do well to open up a spreadsheet and enter all the values you have chosen so far. You can quickly sum up all the masses and lengths (warning: trigonometry), and it will help you quickly calculate your servo requirements.

Servos

Servos are not the only type of actuators you can use, but they are certainly the most commonly used. I'm going to assume most people will choose to use servo or stepper motors, but don't feel limited by this. You might want to use a combination.

There are two main alternatives to electric motors. The first is pneumatic actuators, like the ones used here:

The other option is shape-memory alloy, known as muscle-wire or nitinol:

Both of these have niche uses, but you will find that servo motors are more general purpose.

Unlike normal DC motors, servos are motors which can be commanded to move to a specific rotational angle. To achieve this, they contain a feedback loop which will keep turning the motor in the right direction until it reaches it's destination.

I could go on for pages about the specific inner workings of a servo (and I probably will someday), but right now we need to concentrate on three technical specifications:

Torque. When searching for servos, they should all report a stall torque in kilogram-centimeters or ounce-inches. These numbers represent how much weight they will be able to lift (on planet earth) at a distance of one centimeter or one inch away from the axis of rotation. More is generally better, but will come at a higher price.

How much do you need? This is why it is so important to have a rough idea of the proportions of your robot. I forgot to mention it before, but now would be a good time to also estimate the weight of your batteries and other heavy components.

Lets assume you want to choose an appropriate servo for your knee. The knee servo will be required to lift the entire weight of the robot from a crouched position to standing.

To calculate the torque, you multiply the weight by the horizontal distance between the axis and the center of mass.

T = Fxd

In the above example, the robot's body weight is centered over it's hips, which is 5cm from the knee. His upper body is about 750g, so 0.75kg*5.0cm = 3.75kgcm is required to get the robot stand up.

He also has two knees which can work together, so really each servo only needs to have 1.9kgcm to stand up. However, when he walks we can assume each leg will need to work independently, so we should stick with the original value.

So use your estimated lengths and masses to come up with some numbers for the torque on each joint. You will have to imagine the most difficult movement your robot will be required to perform in order to find the necessary values.

If you aren't sure how much your robot will weigh, remember that we are trying to build an under 1kg robot. If you know it can move 1kg, it will be enough.
Similarly, the time your robot will be required to deliver the most torque is when it has fallen over. If you are unsure, use half of the robot's height as the distance, since this is representative of the single servo being used to stand up.

There are much more complex methods of calculating the required torque, but there isn't much point in going to the trouble since you mostly just estimated values anyway. If you're having trouble, here is everything you ever needed to know about everything.

Now you should have an estimate for the value of each joint. This is the minimum torque you will need to move the joint. Since your estimates were pretty sketchy to begin with, you should add a factor of safety to ensure you've got enough. I would suggest increasing all your estimates by 50%, or even more if you don't feel confident about your calculations.

Mass. Servos which deliver more torque are generally larger due to the fact that they contain more gears and heavy duty parts to withstand the extra forces.

Heavier servos will increase your requirements for torque. Sometimes, this will be unavoidable, but it's effects can be alleviated by making your robot shorter.

You can also reposition heavier parts so that they are closer to the axis you are rotating around. This will reduce the power of the servos you need and make your robot lighter overall.

Speed. The price of a servo is usually determined by it's torque and it's speed. Fast, strong servos will be particularly expensive, so it's important to only get what you need.

Rotational speeds are measured in seconds per 60 degrees. This is the time it takes to complete one sixth of a full revolution - lower means faster.

Not all of your servos will need to be lightning fast - only walking and balancing will require a lot of agility. The proportions of your robot will multiply how fast the limb will move. If you've designed longer legs, you won't need such speedy servos to walk at a reasonable pace.

In particular, the ankle joints usually only need to move through about 10 degrees in a step, which means they can be much slower than the rest of the servos in the legs without impacting the performance.

Now that you know what properties each servo needs, you will have to search around to find one which matches.

It's pretty unlikely you will find exactly what you are looking for, but thats fine. Near enough is good enough - up until now everything has been pretty approximate, so no reason to stop here. Remember that the point of this exercise is not optimization - just getting a robot with two legs on the ground is all we want for now. Here are a few more things to consider when choosing servos:

Metal gears will save you a lot of trouble.
A lot of robots simply get one type of servo for every joint. The advantage of this is that it's easier to repair and easier to build since you only use one set of parts. However, your robot will be heavier and more expensive than it needs to be.
There is more than one way to control a servo. Digital and analog servos require 50Hz PWM control, but some robotics servos use RS232 or RS485 protocols. Right now it doesn't matter which you choose, but make sure all of them use the same method.
Many servos offer extra features like adjustable PID parameters, overload protection and position feedback. These are valuable additions, and you would be wise to take advantage of them.
Most servos have a limited range of rotation. Often, this is around 270 degrees, but can be as little as 90. For most joints, 270 will give you a sufficient amount of freedom, but check you have enough.

Here comes the important bit. Having chosen a servo for every joint on your robot, go back and do the torque calculations again. This shouldn't be hard if you've put everything in a spreadsheet - just use the new torque and mass of every servo you've chosen, and make sure that your requirements are still met.

Chances are, you will find that most of your initial estimates were reasonable. If you find that one servo doesn't have enough power to move the robot anymore, you will either have to upgrade that one, downgrade one of your heavier ones, or adjust the dimensions of your robot. This may cause a cascade of other things to change, but that's just the catch 22 of design. Keep adjusting and recalculating until everything fits.

Wasn't that fun? No, it wasn't really. But at least now you know that the money you are spending on parts won't be wasted.

Build your own humanoid - Part 1

2010-02-04T19:25:00.000-08:00

Not long ago, I spoke about the advantages of humanoid robo-one style combat over battlebots/robot wars matches.

I started thinking about how difficult it might be to start up a competition at my university. Would people be interested? Would it be too expensive? Too complex? Perhaps I would be wrong about people appreciating the tactics and design over brute force destruction.

So I thought I'd walk myself through the process of designing and building a small (under 1kg) humanoid robot, to see how it might play out. Keep in mind that while I do know a lot about humanoid robots, and I also own one; I have never build one from scratch before. I do have experience building other robots, but not walking ones.

Design

First of all, lets have a look at how other people have gone about it. This is often a very good first step when you are uncertain about a project.

One of the first things I notice about these robots is that they are humanoid, not human. When it comes to designing robots, people often get very caught up in biomimicry, without stopping to think about why they are imitating nature's design. In the case of both these robots, the proportions have been modified to make it easier for the robot to balance and walk.

As a general rule, shorter and squatter will make your life easier later on down the track. Keeping the robot's center of mass low will also make him harder to knock over.

At this stage, you will also need to decide how many degrees of freedom you want your robot to have. To robotologists, a degree of freedom is a controllable aspect of the robot. In this case, it refers to the number of joints your robot will have and therefore how complex his actions can be.

Bottom line is, more degrees of freedom means more versatile actions, but at the additional cost of more servos/actuators.

Now, since we are trying to build a humanoid robot, the most attention needs to go to the legs. Robobob has 5 degrees of freedom in each leg. He has two ankle servos, one knee servo, one thigh servo and one hip servo.

I would consider this a pretty good number, but you could get away with removing either the hip or one of the ankle servos and manage.

So that's 10 controllable degrees of freedom just for the legs.

The torso doesn't need to move at all, but giving it the ability to rotate will help allow your robot to shift it's weight quickly to maintain it's balance. Adding one additional servo won't break the bank, and it will contribute a lot to the moves you can perform.

Arms can be as simple or as complex as you like. They do contribute to balance and walking a little, but far less than the torso or the legs. If you are building a robot to fight or wrestle, you will need arms to achieve this. However, if you have a torso which can rotate, all you will need to do with the arms is to raise and lower them in a flapping motion and rotate. If you take this approach, you can get away with as little as 13 servos.

Of course, the exact implementation is up to you. It will depend on your budget and your requirements.

Robobob has 16 degrees of freedom. 5 for each leg and 3 on each arm. This has worked out so far for me, and 16 is actually on the low end of kits available.

If you want to have more than this, I would definiately consider adding them to the legs. A lot of robo-one robots use the double-knee joint, which allows them to stand up and walk twice as fast. The ankles also have a very big impact on how your robot will be able to walk, so if you can get x, y and z rotation on the ankles you will appreciate the advantages.

The next stage is figuring out the approximate dimensions of your robot. I say approximate, because there is every chance that a design decision you make a little further on down the track will will require you to rethink his shape (eg, servo, battery size and weight).

Draw up a skeletal model of your robot and come up with some trial values for the distances between joints. Here are a few things to consider:

Taller Robots are easier to knock down because of their higher center of gravity
Longer legs mean faster movement.
Shorter distances between joints will require less powerful servos.
Longer distances between joints will move the limb much more quickly.
Leave room for your batteries and circuitry.
Make it look cool! It's not all about optimizing numbers.

At this stage, keep it simple. These dimensions will help you select appropriate servos for your needs. If you aren't sure, have a look at existing humanoids and see what works. I will go over a more detailed design in the future.

Next time, I'll talk about choosing the right servos. As you can tell, there is a bit of a catch-22 about design, since your choice of servos depends on your dimensions, which in turn will depend on your servo choice.

Robobob

2010-02-02T03:15:00.000-08:00

Ladies and gentlemen, I give you: Robobob!

You may recall that awhile back I opened my inbox to email suggestions for a good name. I actually intended to draw the name randomly or put up a poll, but once I started calling him Robobob the name sort of just stuck.

So here he is, in all his 16DOF glory standing up to a withering barrage of socks from all directions.

Once again, he has no gyroscope or accelerometer - he is simply using kinematic feedback from his servos to keep himself stable. The algorithm is almost identical to the one I used way back in this post - but he can now withstand attacks from all directions.

You may notice that he always moves with the force that he is being subjected to. This is the same way that humans usually react - recoiling from a blow or a source of pain. I think it gives him a bit of a personality.

Tremble before DISHZOR!

2010-02-01T01:51:00.000-08:00

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.

2010-01-29T15:49:00.000-08:00

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.

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.
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).
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.
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.
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!

It's not a bug, it's a feature

2010-01-27T17:14:00.000-08:00

Mystery solved!

Here is a quote from the avrlibc documentation (which I probably should have looked at earlier):

In order for these functions to work as intended, compiler optimizations must be enabled, and the delay time must be an expression that is a known constant at compile-time. If these requirements are not met, the resulting delay will be much longer (and basically unpredictable), and applications that otherwise do not use floating-point calculations will experience severe code bloat by the floating-point library routines linked into the application.

This describes exactly the symptoms I was experiencing - if the function was passed a constant, it worked flawlessly. If I was using a value fetched from program memory, then the compiler was unable to determine how many NOPs should be performed and the delay was unpredictable.

I don't really know why the library function requires prior knowledge of how long a delay should last. All a spin loop does is keep the processor busy for a set number of cycles. If you need longer, you can simply put another loop around the first loop to multiply it's effects. Sure, without careful calculations you can lose your nanosecond accuracy, but when you are working in the millisecond range it is usually unimportant if you are off by a few clock cycles.

If you want the best accuracy, you should be using a timer or counter interrupt anyway...

..but that's a story for another night. I don't intend to be using spin loops for future versions anyway.

Thanks to the people who emailed me and suggested that I might be accidentally passing the value of the pointer to the function, instead of the dereferenced value. That would also explain the strange behaviour, but it would also have shown up in the compiler output.

In other news - what's up with the horrible popup?

If you don't live in Australia (or perhaps even if you do) you might be unaware that the Australian government is considering introducing mandatory filtering of internet sites.

Much like draconian airport security, national identity cards and racial profiling, this filter is supposed to be being put in place for our "protection". Because apparently Australians can't be trusted with unregulated free speech and freedom of information.

I understand that some people are willing to sacrifice their personal liberties for the comforting feeling of saftey, but the problem is not with the filter as it exists now, but what it could become.

First they came for the communists, and I did not speak out—because I was not a communist;
Then they came for the trade unionists, and I did not speak out—because I was not a trade unionist;
Then they came for the Jews, and I did not speak out—because I was not a Jew;
Then they came for me—and there was no one left to speak out.

Byte by byte

2010-01-25T17:34:00.000-08:00

Here are a few things which might aid you in your detective work.

First of all, I am still using avr-gcc and avrlibc to build the code. To achieve this, you first need to:

compile,

avr-gcc -mmcu=atmega128 -I. -g -Wall -Os -c *.c

link,

avr-gcc -o main.elf -mmcu=atmega128 *.o

and then pack

avr-objcopy -j .text -O ihex main.elf main.hex

Then download the resulting .hex file using the RBCUpgradeTool. Note that you can simply switch the RBC block off and on, rather than messing around with the reset pin.

This should help anyone who is trying to get to the bottom of the mystery I spoke about earlier. I also promised to talk a little about transferring data from the program space into working memory.

Unlike desktop computers, embedded systems are built according to the Harvard Architecture which keeps the program instructions separate from the working memory. They even have separate buses, which means that an opcode and an operand can be fetched on a single clock cycle. In normal operation, there is no need to exchange data between the two areas of memory, since self modifying code has been all but banished to the history books.

Sometimes, you find yourself running out of working memory especially if you are storing large tables or arrays which will eat up the free addresses very quickly. Also beware of memory leaks. Unlike a desktop with an operating system, your program won't segfault or blue-screen to let you know something is wrong - it will probably just start suddenly spewing garbage.

However, if you absolutley must use giant arrays or matricies in your program, you can keep your RAM free by storing them in the program memory and then copy it out only when you need to use it. This is done by using the LMP (LoadProgramMemory) instruction, which enables a special register which shifts the data from the program bus onto the data bus.

Unfortunatley, because the data bus is still only 8 bits wide, memory has to be loaded one byte at a time - so ints (which are 16 bits) need special routines to make sure that the high and low bytes are stored in adjacent locations. Also, reading a byte from flash memory (where the program is stored) takes more than a few clock cycles, during which execution needs to halt. Reading a large table could take up to a second.

Most of the details and heavy lifting are handled by special hardware and instructions on the microcontroller, and core data types like floats have library functions in avrlibc. It is still the responsibility of the programmer to know when to load a table, and particularly to make sure that any memory loaded goes out of scope or is free()d when the operation is complete.

The canned actions which are made using the robobuilder software suite can be exported as 16xN tables, where N is the number of poses (there are 16 servos for the basic robobuilder). For a complicated action, this could be many, many bytes - so the tables are necessarily stored in the flash memory. And of course, since only one action can be performed at a time, you can store dozens of actions in the 128kB of flash and simply swap them out when one needs to be performed.

A puzzle

2010-01-22T18:49:00.000-08:00

Boy do I have a good one for you today!

First off, version 0.2 pre-pre-alpha-alpha-etc is available. Please download it and try it out - report any bugs or suggestions in the comments.

The improvements in this update focus on enabling the execution of pre-generated actions, such as those from the robobuilder site. A few are included in the Hunobasic.h header for demonstration purposes. I have also written a few useful functions to transfer data from program memory to working memory (which will probably be the subject of the next update).

In keeping with the philosophy of not trying to rewrite the default firmware, I've broken the procedure for executing an action (which is a series of poses) into much smaller steps, which makes it much more intuitive.

Here is the method of making the robot walk forwards:

        getPGMWordArray((int*)HunoBasic_WalkForward_TrTime, (int*)delay, HUNOBASIC_WALKFORWARD_NUM_ACTION);

//Load transition times

        for(i = 0; i <= HUNOBASIC_WALKFORWARD_NUM_ACTION; i++)
        {

//For every pose in the action,
            getPGMByteArray((char*)HunoBasic_WalkForward_Position[i],(char*)position,16);

//Load the angle for each of the servos
            setPose(position,torque,16);

//Tell each servo to move
            if(i < (HUNOBASIC_WALKFORWARD_NUM_ACTION))
            {

//After each frame, except the last,
                j = delay[i];
                while(j > 0){_delay_ms(1);j--;}

//Pause for the required transition time.... 

//wait... 

//..WTF??
}
}

What's up with that last part? Why would you loop ten times and each time delay for 1ms, when you could just delay for 10ms in one go?

Well, here's why - it doesn't work!

Substituting the line with:

_delay_ms(delay[i]);

will pause for a much longer time than it should. If you have a AVR, please test this out for me and confirm it. However, passing a constant value to _delay_ms() works exactly as intended. I've tried it many ways, but this is the only method which works so far.

_delay_ms(25);
works, but
delay[i] = 25;
_delay_ms(delay[i]);
does not.

Mysterious.

As I've mentioned before, this solution is hacky and unattractive. But I thought I might upload the code (the rest of which is working fine) and see if anyone has any suggestions as to why this might be.

One step back

2010-01-15T20:27:00.000-08:00

That wasn't so hard.

I think that this code will be more useful to anyone who is trying to use the robobuilder for educational purposes. My goal is not to rewrite the official firmware, but to let programmers have access to the functionality of the RBC and the wCKs.

Code can be found here. It is in pre-pre-alpha mode at the moment, so use it at your own risk. You might want to read this before you test it out.

Bear necessities

2010-01-15T01:10:00.000-08:00

I was recently stumbl'dupon - which was appreciated. I'm glad to know that people out there are finding my work useful.

Along with the increased traffic came several requests for the source code for some of my more interesting achievements.

I am, of course, more than happy to provide it - you may have noticed that source code is one of those things which I often promise but seldom deliver.

However, there is a good reason for my apparent reluctance to upload my work as of late, and it can be fairly accurately summarised in two words: self confidence.

For some reason, programmers have an ingrained tendency to look at any code written by someone other than themselves and immediately write it off as garbage.

In some cases, this is probably just good old fashioned hubris. But my current working theory is that in programming there are so many levels of mastery and so many potential solutions to any problem. Code using paradigms which are advanced and unfamiliar seem needlessly complicated, while basic (but probably equally effective) methods of performing a task are often written off as trivial and inelegant.

So I tried to be understanding. Sure, I might not have done it that particular way myself, but with a positive mindset I could see the logic behind most of the design decisions.

But try as I might, I kept having to resort to ugly hacks to get the code to do what I wanted while still maintaining it's original functionality. After awhile, I had to sacrifice the default behaviour altogether. Eventually, I found myself rewriting huge sections of code in order to make even the most basic functions work reliably. But I figured that I had come this far with the official code, and it would just take me too long to find an alternative.

Until I saw this:

ISR(TIMER1_OVF_vect)
{
    if( gFrameIdx == gNumOfFrame )
{   // are we at the end of the scene ?
           gFrameIdx = 0;
        RUN_LED1_OFF;
        F_PLAYING=0;                        // clear F_PLAYING state
        TIMSK &= 0xfb;                     // Timer1 Overflow Interrupt disable
        TCCR1B=0x00;
        return;
    }
    TCNT1=TxInterval;
    TIFR |= 0x04;                            // restart timer
    TIMSK |= 0x04;                            // Timer1 Overflow Interrupt enable
    MakeFrame();                            // build the wCK frame
    SendFrame();                            // send the wCK frame
}

void MakeFrame(void)
{
    while(gTx0Cnt);            // wait until the transmit buffer is empty
    gFrameIdx++;            // next frame
    SyncPosSend();            // build new frame
}

//------------------------------------------------------------------------------
// Start sending the frame
//------------------------------------------------------------------------------
void SendFrame(void)
{
    if(gTx0Cnt==0)    return;    // return if no frame to send
    gTx0BufIdx++;
    sciTx0Data(gTx0Buf[gTx0BufIdx-1]);        // send first byte to start frame send
}

void SyncPosSend(void)
{
    int lwtmp;
    BYTE CheckSum;
    BYTE i, tmp, Data;

    Data = (Scene.wCK[0].Torq<<5) | 31; // get the torque for the scene

    gTx0Buf[gTx0Cnt]=HEADER;
    gTx0Cnt++;

    gTx0Buf[gTx0Cnt]=Data;
    gTx0Cnt++;

    gTx0Buf[gTx0Cnt]=16; // This is the (last ID - 1) why is it hardcoded ?
    gTx0Cnt++;

    CheckSum = 0;
    for(i=0;i
        if(Scene.wCK[i].Exist){    // if wCK exists add the interpolation step
            lwtmp = (int)Scene.wCK[i].SPos + (int)((float)gFrameIdx*gUnitD[i]);
            if(lwtmp>254)        lwtmp = 254; // bound result 1 to 254
            else if(lwtmp<1)    lwtmp = 1;
            tmp = (BYTE)lwtmp;
            gTx0Buf[gTx0Cnt] = tmp;
            gTx0Cnt++;            // put into transmit buffer
            CheckSum = CheckSum^tmp;
        }
    }
    CheckSum = CheckSum & 0x7f;

    gTx0Buf[gTx0Cnt]=CheckSum;
    gTx0Cnt++;            // put into transmit buffer
}

That was probably a bit on the long side. But here's a quick tip for programmers working on embedded systems - if it's too long to post on your blog, it's too long to put in AN INTERRUPT!

Interrupts need to be short. When an interrupt fires, everything else is put on hold until the RETI (return from interrupt) instruction is performed. If your code spends too long in an interrupt, you risk missing other important events such as sending instructions to servos, receiving serial transmissions, or responding to any other interrupt.

What's worse: since all these events have been put on hold when the RETI instruction actually is received, all these issues now have to be dealt with at once. It's not easy to predict what order they will be handled in either. This can lead to unpredictable behaviour which is very hard to debug.

So to summarise: bloated interrupts = bad.

To return to my original point, I had been doing some very dodgy things in order to just get the darn thing to work. Things like arbitrary delays in the middle of functions (to make sure that whatever interrupt was expected had time to get itself sorted out), and lots of polling to ensure that the state of the program was predictable before I went and altered the global variables (of which there were many). Plus a not insignificant amount of arcane deep magic.

Not the sort of work I wanted to put my name on.

All that stuff I said about respecting other people's code remains valid, but only if it's actually doing what it is supposed to. So after a short meditation, I realised something very important: I didn't need all this stuff.

I had a very specific goal in mind, and 90% of the code I was having to circumvent was simply getting in the way. I only needed a few basic functions to achieve what I needed to do - and at this stage I was spending far too much time patching things up instead of fixing the problem at the source.

With this in mind, I've begun working on a very simple library of functions which will deal with the simple, low level things that I am trying to achieve - without all the non-essential tasks getting in the way. With any luck, I will be able to make far more frequent source code updates now, since the releases will be far more minimalist and focused on a specific task - instead of trying to be a replacement for the default firmware.

Until next time - keep it simple.

A robot by any other name

2010-01-10T14:55:00.000-08:00

I've been a bit serious recently, so lets have some fun.

First off, I've realised that my robot is more than a month old now, but still has no name! I'm not good with names, so I thought I'd open it up to the floor and see if anyone had any suggestions.

If possible, it should be a name which conveys his gentle nature, effervescent personality and love of outdoor sports.

Next, it's time for the cool robot of the week!

I've been talking about control theory quite a bit recently, and I've been doing some research into different methods which might be applicable to my dynamic balance problem. This video is of an inverted pendulum - the arm is free to rotate on the cart, and only the cart is free to move along the x-axis. The cart has a model of the system which it uses to swing the pendulum into a stable inverted state. This is a well studied area of control theory, and today's modern robots (and humans) have been doing this for awhile.

Not impressed? What about this:

Same problem, but with an extra degree of freedom. Now there is a compound pendulum (one pendulum free to rotate off the first pendulum), but still only the one cart. This is a non-holonomic system, which is much harder to control using conventional control methods.

Still not enough?

Here is the double pendulum problem again, but this time the cart has been replaced by an arm. Instead of being constrained to two dimensions, the control algorithm now has to cope with the non-linearity of moving the control arm in a 3D rotational space.

I know it's not the cute little humanoids you are used to, but from an engineering perspective this is significantly more impressive watching robots dancing.

Ok, maybe not.

Robots are our friends

2010-01-08T16:36:00.000-08:00

A while ago, I watched a news story about military robots. The tone was factual, but their "expert", so to speak, came off as a little bit alarmist (pro tip: remember to include more than one expert if you're trying to come off as unbiased).

I can understand that to someone unfamiliar with computers and robots might see something like a Predator and begin to feel uncomfortable. People always fear what they don't understand, so if a person believes that their car is trying to kill them or their computer is alive - surely anyone should be able to see that arming robots to the teeth is a bad thing (TM).

The bottom line is though, that despite the layers of mechanical and digital abstraction that make up the robot, there is always a human at the other end who pulls the trigger.

Today's military robots are really nothing more than glorified remote control cars with cameras attached. If only robots were as advanced as movies and the media make them out to be. They have degrees of autonomy, such as navigating obstacles or maintaining a fixed altitude flight path, but when it comes to the grizzly business of actually fighting, robots will always surrender control to an individual who is better suited to the task.

The reason for this is simple - robot's can't interpret the world in the same way that people do. Sure - they can "see" with 5 megapixel camera, and "hear" with microphones, but all this data still needs to be interpereted in order for the robot to understand what the images and waveforms mean. The science of interpreting data into meaningful information is known as perception.

Perception remains one of the hardest and least solved problems in robotics. There are videos of prototype robots like ASIMO who can see an object and remember what it is, but the robot is still only parroting what it has been told. Artificial intelligence still lacks the ability to process semantic information about it's environment.

As humans, we have tens of years of experience which we can draw upon to derive the meaning of events going on around us. When confronted with an alien situation, we can look back into our vast database of knowledge and see if any of the information we have collected is relevant to understanding what is going on. Sometimes it's hard. Even humans make mistakes. And unless the robot has access to a human-like reservioir of knowledge about how to differentiate between a friendly and enemy soldier or a soldier who is surrendering or a Sharnaff bull, the risks of friendly fire are simply too great. And the engineers who build robots understand this.

So if a robot can't correctly interpret the environment around it, it becomes no more useful than a land mine.

A very complicated, fragile and above all expensive land mine.

If an army wants to indiscriminately kill civilians, non-combat personnel and soliders from both sides, then there are much more efficient methods of achieving it.

But, in the hands of an intelligent operator, the robot becomes an effective battlefield participant who is far more expendable than your average squishy human - but just as much of a threat.

From this perspective, you can see how military robots actually save lives. There are simply less humans exposed to danger. Nobody is going to get upset if a robot gets shot to pieces (except maybe the accountants).

I think I should make it clear that I am not pro-war: just pro-robot. We've already tried the land mine thing, and it failed. We don't need another generation of weapons which cannot discriminate between a soldier and a child. But if the robots are being used responsibly to keep humans out of dangerous situations, then it might be a step forward.

Form vs Function

2010-01-06T16:22:00.000-08:00

I thought you might appreciate this video of my robot falling over.

At the end, you may notice that his legs get stuck together like an imperial walker during the battle of Hoth! Ah, memories.

The instructions in the manual indicate very clearly that the nuts should be placed on the inside of the leg - presumably for aesthetic reasons. However, the short section of bolt which sticks out of the inside has a nasty habit of getting hooked on the opposite foot.

If you can tolerate your robot looking a bit road warrior themed, I suggest reversing the direction of the bolts to avoid having your robot flail about like a memermaid, and also the internal damage to the plastic casing:

I do often complain about the robobuilder design, but I think I should make it clear that I am by no means unhappy with it. These are small complaints which (I hope) will be addressed by the robobuilder community and also allow others to avoid my mistakes.

The wCK servos are actually the best robotics servos I've used for their price. You can skip the durability issues I've been having, simply by getting the wCK 1111 version, which has 3 metal gears and a higher torque! They have a suite of extra features, such as brake mode, 10bit positioning (360/1024 = 0.35 degree accuracy!), runtime adjustable PID settings, continuous rotation mode, and the ability to write simple programs to run on the servos themselves.

I have yet to use these features, but I can already think of a thousand uses for them.

One step at a time

2010-01-05T18:43:00.000-08:00

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.

Merry Christmas

2009-12-24T17:28:00.000-08:00

Have a safe and happy holiday everyone!

Phase 1: Collect underpants.

2009-12-21T02:09:00.000-08:00

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: "???"

Two steps forward...

2009-12-18T03:12:00.000-08:00

I did a lot of work today, improving the robobuilder motion system and writing some custom functions to take advantage of the special features that the wCKs have to offer.

Unfortunately, my efforts were met with a minor setback when I managed to strip another gear - this time in the poor robot's knee. Unlike the first time, or the time after that, the gear which needed replacing was the first gear in the set - the one which is driven directly by the motor.

This leads me to believe that it broke simply due to regular wear and tear - not because of any specific negligence on my behalf.

Gears tend to be under more stress the further away from the motor they are, because they rotate slower, but with more torque. This is why (I assume), I didn't receive any replacement #1 gears with my kit.

Therefore my plans have been put on hold until I can get my hands on a replacement. This should serve as another important selection criteria for servos - metal gears are worth the extra money.

So today's post will not, as I had intended, consist of more awesome videos of my robot doing awesome stuff.

Instead, please enjoy a variety of other people's robot's doing other people's stuffs.

Above is an earlier version of HINA, doing demonstrations for the robo-one competition. I'm fairly sure that the bottle of water is full, which means that there is quite a lot of power in that little robot. As usual, mujaki has put a lot of effort into the custom body parts and it looks absolutely stunning.

In the not too distant future, I'd like to have a go at customising my servos - particularly given the problems I'm having with these plastic gears.

From cute to creepy.

This is phoenix, a hexapod with an amazingly lifelike gait and behaviour. It looks like a real insect, especially when it goes into attack mode!

Phoenix is able to move so fluidly due to an inverse kinematics engine (another interest of mine). This enables fine control over the body and individual limbs of the hexapod, without compromising the balance or posture of the rest of the robot.

When I can get this servo fixed, I'll upload some more videos of my own - please bear with me. If anyone knows where I can get replacement wCK gears (preferably metal) in Australia - let me know.

Mirror Mirror

2009-12-17T00:35:00.000-08:00

When I first got it into my head that I wanted to build a humanoid robot, I spent quite a lot of time researching various types of servos I could use. They needed to be high-torque, not too big and above all cheap - other features were just gravy.

This led me to consider a number of things, such as using unbranded RC hobby servos, buying unbelievably cheap micro servos and upgrading the motors, and even building my own.

These are not bad options, per se, but what I failed to consider were just how useful those extra features that high quality servos include can be.

Fortunately, I was saved from myself by the timely arrival of my birthday (which I have written about previously).

Though the wCK servos have many additional features, the one that I am finding particularly useful right now is the ability to query a specific servo for it's current position. Although it doesn't seem like much on it's own, it has enabled me to do cool little tricks like this:

The video simply shows me moving the robot's left arm, and having the program mirror the actions on the right arm.

Non-robologists don't seem to find this very impressive, but hopefully the implications of this are apparent if you are in the robot game. Effectively (although crudely), the robot now has a sense of touch.

Don't have a distance sensor? No problem - just set your robot into zombie posture and wait until one of his arms is bumped by a wall.

Worried that you'll damage a servo? Just check to see if it's stuck and turn it off to avoid stripping a gear.

Oh, and before you ask - yes, that is Donatello in the background holding the power and serial plugs.

Here's another video of him with his arms attached (the robot, not the turtle).

The servos are placed in passive mode, which is another special feature of the wCKs, which powers them up but turns off the PID control. Because the servos use an RS485 type bus, they can then be queried by the RBC and then take control of the bus to report their current position.

Although it is a minor achievement, this is another important step on the road to my grand plan. What plan, you ask? You'll just have to wait and find out.

The code is a bit sketchy at the moment, so give me a chance to clean it up before I upload it. Watch this space.

Saftey First

2009-12-15T14:41:00.000-08:00

After what happened last time, I've become significantly more paranoid about damaging my robot.

Recently, while doing some more hacking of the wCK motion timing system, I decided to simply remove the element of risk altogether.

So far, separating the arms and legs from the body has been a good move (tm), and I encourage you to do the same if you start changing low level parts of the code.

You see, I am rapidly running out of those spanner shaped connectors.

I mentioned in a previous post how careless control over pointers can cause your robot to flip out like a hyperactive kid tripping over a beehive. The wCK servos have just over 11 kgFcm of torque, which is more than adequate to cause your robot to tear itself to pieces when a rogue pointer starts issuing random commands. I speak from experience.

Serial transmission of commands to the servos can be performed in two ways. The most common method is to use the "Transmission Buffer Empty" interrupt, to send a new character whenever there is nothing waiting to be sent. A transmission is initiated simply by unmasking the interrupt, and the interrupt is set to disable itself when there is nothing left to send. This is the preferred way of sending RS232 communications, as the interrupt will continually fire as long as as something remains to be sent.

The second method of transmitting the message is to use the "Transmission Complete" interrupt. If enabled, this interrupt fires whenever a character has finished being sent. This requires a single character to be manually loaded to "prime the pump", but transmission simply stops when no more characters are available. Since the next character is sent immediately, tighter control over transmission states can be achieved, such as when using an RS485 protocol.

The wCK servos use an RS485 protocol.

The reason that the robobuilder has a tendency to spaz out is due to two things. Firstly, the transmission buffer is circular. This means that messages can be added to the buffer at the same time as they are being sent. When the pointer gets to the end of the buffer, it simply returns to the beginning and keeps sending until it reaches the end marker.

Secondly, memory is never truly empty. A byte in memory simply contains the last thing that was stored in it. On reset, unallocated space usually contains junk data. Even if you set up your program to zero out your memory before you use it, it will still contain a zero. Therefore, even a small mistake which results in one of the transmission interrupts not being disabled correctly will cause a vast number of arbitrary commands being issued to the servos, causing the aforementioned spastic behavior.

Aaaaanyway, now that you know why it happens, you know how to avoid it. I still recommend detaching your arms and legs while you're testing though.

All work and no play

2009-12-14T14:29:00.000-08:00

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.

Son of Voltron

2009-12-10T19:30:00.000-08:00

Enabling the robot to recharge it's own batteries was something I wanted to get done sooner rather than later. One of the primary reasons for this is that it meant I needed to periodically switch back to the default firmware if I wanted to charge up the batteries. The second reason though, was that it was a very appropriate stepping-stone on the way to getting several other features working.

You see, the atmel 128 Analog to Digital Converter has a built in multiplexer which allows the single peripheral to measure up to eight different voltage nodes relative to ground potential or other nodes, at various levels of gain. Even better, these sources and configurations are software selectable by the use of a 5-bit multiplexer.

If all that sounded like technobabble to you, the long and the short of it is that the same basic code which measures the power left in the batteries can be used to get distance readings from the IR sensor, and sound input from the microphone!

But back to the power level sensor. This version of the code uses the debug info LED configuration to report the current level of the battery. If your robot is not plugged in, you can actually see the voltage drop when PF1/2 are pressed and the servos are moving. This is achieved by setting the multiplexer ADMUX to channel ADC1, and enabling the AD conversion complete interrupt in ADCSRA, which saves the voltage to the global location gA2D. It is only occasionally necessary to know the voltage, so conversion requests are triggered manually (as opposed to continuously) by setting the ADSC bit.

Recharging is enabled by setting bit 4 on PORTB, which digitally connects the battery to the external power source. Pressing and holding PF1 and PF2 for 2.5 seconds enters recharge mode, which trickle charges the NiMH batteries. Because I'm paranoid after the previous incident, the default setting is to only charge the robot for 10 seconds at a time. If you want to fully charge the batteries, pressing PF1 while the robot is charging will keep the batteries charging indefinitely.

"But Alex!" hear you cry. "If you can measure the voltage, why not simply disable charging when it's maxed out?"

Unfortunately, it's not that simple. When the external power source is present, the RBC automatically changes over the V++ supply to the power pack and becomes the voltage source. This means that whenever the plug is in, the value of gA2D will be that of the power source - even when the battery is low. I haven't figured out a way around this - you might also have noticed that there is no automatic recharge cut-off for the default firmware either.

The code is here. I'm looking for a better hosting service, but in the meantime, remember the click the "free" tab.

If I only had a brain

2009-12-03T02:02:00.000-08:00

As promised, I have made some changes to the robobuilder source files so that movement commands execute properly.

The problem seemed to be that the wCK transmit interrupt was being disabled prematurely, before all of the instructions could be sent. General defensive programming practice on behalf of the designers meant that any function which placed commands into the transmit buffer intentionally waited patiently until the buffer was empty. This avoided accidentally fragmenting the instructions due to the limited size of the buffer, but meant that the program would just freeze up if (for whatever reason) the transmissions were not being sent.

With a little debugging, I identified the MakeFrame() function as the culprit, which was causing the program to get stuck waiting for the transmit queue to clear, but since the interrupt was disabled it stayed in an infinite loop. Simply placing a few lines inside the while loop making sure that the interrupts were enabled fixed the problem.

I also made a few other aesthetic changes - mostly making things more readable by replacing "magic numbers" with the names of registers. For the uninitiated, A |= (1<<X) means 'set' bit X in register A, while A &= ~(1<<X) will 'clear' the bit. The header file iom128.h in avr-libc contains the names of all the registers.

Overall, the code here is a very good starting point if you want to start messing around with your robobuilder's brain. However, the functions do a LOT of polling, which should be replaced with interrupt based timing control if you plan to implement more complicated functions.

The files can be found here. I apologise for the horrible free hosting service. Be sure you click on the "Free" tab before you hit download.

My next goal is to figure out how the recharging procedure works, and give the robot some sort of power management routine. Perhaps eventually he will be able to detect when his batteries are dying and go recharge himself.

It was only a matter of time...

2009-11-30T17:21:00.000-08:00

It was inevitable, really.

While chasing a guinea pig under a table, I managed to cause enough vibrations for the robot to topple off and land face-first on the ground. Although this may sound both comical and adorable, I was not amused.

At first, everything seemed OK, but closer inspection revealed that one of the spanner shaped connectors had snapped, and more thorough testing revealed that one of the servos was making a grinding noise.

Disappointed, but not discouraged, I voided my warranty and opened it up to see what the problem was.

As it turns out, I had stripped some teeth of a plastic gear, which meant that the motor was spinning uselessly as the feedback loop was broken. Fortunatley - in one of the more pleasant customer experiences I have had - it turns out that the robosavvy people had included a bag of spare servo gears.

So fixing it was just a matter of unscrewing the case and feasting on the delicious goo inside. If a screwdriver was included in your kit, don't use it to open the servo cases! It's just a shade too big, and I ruined the tip by trying to get the screws out. Just one size smaller should do it, but be sure to push down hard against the screw so that you don't strip the head off.

Included in my kit was an instruction sheet (the backdrop of these photos), which explained how the wCK modules can be re-assembled. I don't know if this is because the expect them to need servicing at some time, or just because they had the CAD models lying around. Either way, there isn't much to the gear assembly, so don't be afraid to open one up if you are curious. After replacing the damaged gear, I simply slid the bearing back on to the drive shaft and put the case back on.
At this stage, I was worried that I might have not oriented the output shaft correctly, resulting in the servo position being slightly out of phase with the desired angle. However, the wCKs must use optical encoding or something to establish their position, so after putting the case back on it just worked straight away. [UPDATE - The servos actually use a potentiometer, but the shaft is designed to only fit correctly].

So there you go - a potentially disastrous situation was averted thanks to the inclusion of some spare parts. Since nothing lasts forever, I would recommend you order from robosavvy - their service so far has been exemplary.

[UPDATE - the official servo repair instructions are available]

Debugging robots for fun and profit

2009-11-30T13:41:00.000-08:00

More astute readers who followed the procedure in my last post may have noticed that it didn't actually work.

That's not to say that the instructions were wrong - those are still the steps to build the robobuilder C source files and upload them to the RBC. The problem was that the code which I linked doesn't actually do what it says on the side of the box, so to speak.

The execution of the code posted on the robosavvy forum (which is primarily an english adaptation of the official code) should result in the robot performing the RIGHTPUNCH action when the PF1 button is pressed. However, when the files are built and installed on the robot, no amount of button pressing will elicit a response from the robot.

I'm working on producing an updated version of the code which is nice and flexible, which I will upload here when I'm satisfied with it. In the meantime, for those of you playing along at home, I thought I would share a quick debugging procedure known only to a secluded group of embedded systems programmers.

There are on-chip debuggers available for the AVR family of microcontrollers, however I don't have one. There are also situations when the debugger causes more problems than it solves - ie, by hogging certain pins on the board, or restricting the flow of real-time interrupts. The poor mans solution to this is to set up a quick method of stepping through your program and seeing where it gets to and where it gets stuck. The easiest way of allowing your program to communicate back to you is using the onboard LEDs.

#include "macro.h"
#include "main.h"

WORD gDebugMode = 1;

void Debug(BYTE code)
{
if(gDebugMode)
{
CHK_BIT7(code)? RUN_LED2_ON : RUN_LED2_OFF; //Green
CHK_BIT6(code)? PF1_LED2_ON : PF1_LED2_OFF; //Red
CHK_BIT5(code)? PWR_LED2_ON : PWR_LED2_OFF; //Green
CHK_BIT4(code)? PWR_LED1_ON : PWR_LED1_OFF; //Red
CHK_BIT3(code)? PF1_LED1_ON : PF1_LED1_OFF; //Blue
CHK_BIT2(code)? RUN_LED1_ON : RUN_LED1_OFF; //Blue
CHK_BIT1(code)? PF2_LED_ON : PF2_LED_OFF; //Yellow
CHK_BIT0(code)? ERR_LED_ON : ERR_LED_OFF; //Red
}
return;
}

The input to this function is just a number you can assign to a particular error/state code: ie, Debug(3) would have the error and PF1 LEDs lit, while DEBUG(0) turns all the LEDs off. Combined with the use of the _delay_ms(1000) command, you can sprinkle these throughout problem areas and observe how your code branches or if it gets stuck anywhere.

The ordering of the LEDs may seem arbitrary, and it can be a little hard because the ordering zig-zags upwards from LSB (error) to MSB (power), and then zigs back down again. The reasoning behind this is because I wanted to make the lower numbers easier to read, since three of the LEDs have two possible colours. Hence, it's just normal binary for error values up to 2^5 = 32, and only mildly more complicated for bigger numbers.

C is for cookie

2009-11-25T19:41:00.000-08:00

The robobuilder kit comes with a suite of tools which can be used to easily create poses and moves. Unfortunately, the overall impression they gave me was that they were useful for little more than making the robot dance. There were some useful features, such as being able to record the current pose of the robot and save it to a file, so I will probably play around with them later.

One of the most attractive features of the robobuilder system is that the firmware can be reprogrammed in C. If that doesn't send shivers down your spine, the rest of this post will probably be over your head. Go watch tv until the grown-ups are finished talking.

The tools to customise the robobuilder firmware are available for download. It comes with a 70 page PDF tutorial which walks you through the process of using the CodeVisionAVR IDE to customise the example builds included. The CodeVision IDE is not free, but I would recommend following the official procedure if: a) You are new to the C language or microprocessor programming and b) you use Windows.

If, like me, you fall into neither of the above categories, I suggest you save your money and have a go at using the avr-gcc compiler and/or WinAVR (which is just a Windows implementation of avr-gcc).

But first, a short rant.

When did motherboard manufacturers stop including serial ports?! I know that they are an aging technology, but they are damn useful. And you, robobuilder - you knew this all along but you didn't ship with a USB adapter or anything. I'm very disappointed. So here I am, forced to write code on the only computer in the house with a serial port - an old Dell Latitude D600. It runs Ubuntu 9.04 and was being used as a media centre PC, but I've since commandeered it in the name of the robot uprising. FYI, all of the robobuilder tools and software will run under WINE.

If you are compiling your code in linux, you will need to install avr-gcc and avr-libc. For reasons unknown, avr-gcc will not detect that avr-libc is installed and include it's headers when you compile. If you get an error message like:

error: avr/io.h: No such file or directory

You may need to copy the contents of /usr/lib/avr/include to /usr/lib/gcc/avr/4.3.2/include.

This robosavvy thread contains a port of the official robobuilder example source files which use the standard avr-gcc headers (also, comments in english!). Details about converting headers to gcc can be found at the avr-libc page. This is the skeleton code you need to edit. Use the command:

avr-gcc -mmcu=atmega128 -I. -g -Wall -Os -c main.c

to compile the source. I do recommend the -Os flag, since there is only 128kB of flash memory on the chip. You may still get some error messages at this stage - I did.

The names of header files are case sensitive in gcc, so check that the names of the #includes match the filenames:

#include "macro.h"
#include "main.h"
#include "comm.h"
#include "dio.h"
#include "math.h"

This should get rid of the remaining compile errors. Next you must link the files together using:

avr-gcc -o main.elf -mmcu=atmega128 main.o comm.o dio.o

If you get linker errors at this stage, check that you used the same -mmcu values for both compiling and linking (otherwise, gcc will try to link to code intended for different platforms).The final step is to convert the instructions to hex using the command:

avr-objcopy -j .text -O ihex main.elf main.hex

The .hex file created from this step is the actual firmware which will be written to the atmega128 chip. To upload it to the robot, simply run the "RBC Firmware update tool", and connect the robot using the (shudder) serial cable. Select the appropriate .hex file, and click the "Click Here" button. Now, press the reset button on the robot, and let the download finish.

To start the custom program, press the PF1 button. BEWARE! If you've made a mistake in your code, your robot will spaz out like an epileptic kid during a fire drill! To prevent damage itself and nearby life forms, either hold it by the head or make sure it is on the floor before testing it. Also note that unless you've specifically prevented such actions, the robot has no idea of it's own kinematics - meaning that it is quite likley to try and put it's arms through it's body when trying to scratch it's back. Be ready to kill the power if you want to prevent damage to the servos.

Now that I have some skeleton code to play with, over the next few days I'll experiment with various useful functions of the chip, like loading pre-built motions and getting data from the IR remote.

It's Alive!!

2009-11-23T18:39:00.000-08:00

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?

Some assembly required

2009-11-22T17:10:00.000-08:00

Having a birthday close to Christmas can be challenging when you are young. Cool toys are released all year round, so it is important to put a lot of forethought into your letters to Santa if you are to weather the 11-month-drought until next year.

As an adult however, has it's perks. Despite the discovery of impulse purchases, knowing how hard you work for each dollar you can spare for indulgences usually sucks out all the fun. Hence, I restrict myself to cruising the interslice, imagining all the cool stuff I could buy and stopping just short of entering my credit card information.

Often, more than half of my open tabs fall into the "would love to have, but would never buy for myself" category. Sometimes, the right mix of unattended computer, exceptionally bright girlfriend and a wonderful family allows the Christmas-birthday combo to really pay off...

..like when your entire extended family pitches in to get you your very own robotic minion.

Now, as everyone has surely figured out, robots are cool. However, I find them particularly fascinating, and have spent 5 years of my life studying them. So I did what any self respecting member of the internet would do, and started a blog.