It was only a matter of time...

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

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

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

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

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.