The XR47 Robot

Bogies completed

2009-08-10T20:29:00.006+02:00

I finished making the four bogies. The picture below shows the parts for one of them. The only things I made myself are the two black plastic parts. Two of the holes are threaded to allow the wheel axes to be easily fastened. The lower holes are used for the screws for the distances that connect the two halves. Finally, a large M6 bolt is used as the top axis that connects the two sides and also holds the two ball bearings in place between two washers.

And here is one complete bogie on the thread.

Cutting Delrin for the bogies

2009-07-28T18:03:00.012+02:00

It was very easy to saw Delrin using my band saw but the cuts did not initially look very good. After spending an hour adjusting all the parts of the saw, the result became much better although it is still far from what you can get using the right circular saw. Some post-processing is necessary. The picture below shows the result of a machining operation compared to sanding. It is clear that the machined finish is way better than sanding. There is really no way I can avoid machining the edges now that I have seen how much better it looks.

To cut the corners at a 45 degree angle I put together a simple sawing rig. It made it simple to quickly cut the pieces.

Bogies

2009-07-21T09:56:00.011+02:00

The sketch below shows the final design of the bogies for the road wheels. This design will allow the robot to pass obstacles as high as 4 cm without tilting. The idea is to also put some form of sensor on it later to allow the robot to feel the ground.

While making a first copy of the bogies I learned two things: My saw is not at precise as I thought. Although the parts I made were definitely useable, the finish is not as nice as I would have liked. They look good after a light sanding, but it seems that I will have to machine all sides of the parts if I want the better look. Now I need to decide whether it is worth the extra work.

The second thing I learned is that you should always check the dimensions of you delrin sheets before cutting them. It was not until I had completed the parts that i realized that I had used the wrong sheets and the bogies turned out a few mm too thick. Well, it was a good exercise anyway.

Design Sketch

2009-04-21T00:20:00.008+02:00

After a number of redesigns I have finally decided on the design for the treads and drive mechanism. The sketch below shows the main parts. I settled for the inverted design for the simple reason that it looks great - not to mention that it has recently been popularized by Wall-E. The length of the robot will be slightly over 40 cm and the height of the thread package will be approximately 23 cm.

There were a number of complicated constraints that does not really show in the sketch. The bogies should not collide with each other or with the drive belt between the motor and the frontal drive sprocket. It is also necessary to mount the motor so that it does not come into contact with the wheels. Fitting a spring to the idler sprocket in the back also proved rather difficult since it should not collide with any of the other parts.

One nice aspect of this design is that a large part of the motors will be placed within the thread module. There will thus be plenty of place for other components in the rest of the robot.

Motor Control

2009-04-12T11:18:00.010+02:00

The control of the motors will use the Arduino board. It will collect pulses from the two motor controller to determine the current speed of the motors and it will send a pulse width modulated signal to the controllers to set the desired speed. The figure below shows the main components needed to control one motor. A single Arduino board will be used for both motors that communicates with the main computer using USB.

There are a number of things that will need to be solved to get this to work properly.

The SPEED OUT signal must trigger an interrupt on the Arduino so that the pulses can be collected.
The PWM output must probably be filtered to work as a speed control signal. This output has a frequency of approximately 490 Hz and the pulse width can be adjusted in 256 steps.
The USB must be set up to receive commands from the main computer and to send odometry information to it.
The code for a local PID controller must be written for the Arduino and it must be tested how interacts with the regulator in the speed controller.

Speed output

2009-01-21T19:37:00.009+01:00

The motor controllers have an output that produces 30 pulses per rotation. This signal will be used by the host computer to form a first estimate of how fast the robot is moving. Since a threaded vehicle turns by sliding over the ground, this signal will not be very exact, but it will still be useful. The signal will be used to produce an interrupt on one of the inputs of the Arduino for each pulse. To see what the signal looked like, I hooked up the output to an oscilloscope and the result is shown in the figure below.

It is clear from the picture that the signal is very noisy since the oscilloscope is not able to measure its frequency. There is also a number of overlapping pulses shown to the right. Because of this the manufacturer recommends filtering the signal using the small circuit below.

I have not yet tested this, but hopefully this will result in a signal that is clean enough to use as input for the microcontroller.

Motor Test

2009-01-20T23:27:00.008+01:00

The motor is controlled through a speed control driver that allows it to be precisely controlled. It has a number of inputs and outputs that allows the speed and direction of the motor to be set. There is also an input for braking. The speed can be set by an external potentiometer or by setting one of the inputs to a voltage between 0 and 10V. There are also two outputs that can be used to determine the speed and the direction of the motor. One output is a binary direction signal and the other produces 30 pulses per rotation.

Unfortunately, the controller needs a few external components to be interfaced with a microcontroller. Because of this, the first test used used manual control of the different inputs while the speed was set by a potentiometer. This worked fine and the motor could be precisely controlled. With the controlled, the motor is very strong also at a slow speed and this is promising for the future.

I plan to control the motor drivers from an Arduino card which in turn will be connected to the main computer through USB. There are two inputs that generate interrupts that can be used to integrate the pulses from the drivers. The pulse width modulated outputs of the card can probably also be used to provide the speed for the drivers. The idea is to use a MOSFET in place of the potentiometer to give the reference voltage for the motor driver. It remains to be seen if a PWM-signal will work or if some filtering is necessary.

Final Motors

2009-01-07T16:09:00.004+01:00

I finally made a choice of the motors to use. They are heavy, expensive and require special control hardware, but they will probably do the job. The motors are two geared brushless DC motors that runs on 24V. They each deliver 1.6 Nm continuously and have a top speed of 185 rpm. This means that I went for speed instead of torque, but it will be possible to replace the gears if the torque is not sufficient. With alternative gearing, the motors can deliver 2.8 Nm at 95 rpm and 4.1 Nm at 65 rpm.

Now it is time to figure out how to get the motors to run. Unlike ordinary DC motors, brushless motors need a dedicated control box. In the best of worlds, this box would contain an USB interface, but in reality all systems like these are controlled by a range of different analogue and digital control signals. The main problem with the motor controllers will be to generate these signals from a computer in a way that is not too complicated.

Stereo Vision

2008-05-13T00:19:00.006+02:00

In a flash of sudden inspiration, I put together a stereo vision head for the robot from parts that I had laying around. The neck is a pan-tilt system from ServoCity. I realized that I could turn the pan-tilt upside down and add a single piece of plastic to mount the two servos for the cameras without too much effort giving me an instant 4-degrees of freedom stereo vision head.

The two cameras are Apple iSight which are mounted directly on the servo shafts. This is obviously not the best solution as it is hard to get the orientation of the two cameras perfect. It is likely that I will have to build a more accurate adapter for the cameras in the future, but this will do as a first prototype. Another limitation is that the center of rotation of the cameras is a few centimeters behind the lens. This means that a camera rotation will also include a translation of the image.

It remains to be seen how useful the images from the two cameras are for stereo vision. As they are not at all calibrated, it will be necessary to use algorithms that can compensate for this. The plan is to also add the accelerometer to the camera head, but this will have to wait until I get complete control of the accelerometer kit.

GPS Accuracy

2008-03-09T10:16:00.007+01:00

My first attempt to use GPS for localization were very positive. It seemed that it would be possible to recognize the part of the house the robot was in based on the GPS fix. However, it turns out that the fix drifts considerably over the course of a few hours. The graph below shows the drift in meters for a stationary GPS receiver that was placed indoors on my computer for ten hours.

At some times the fix is as much as 14 meters away from the initial estimation. Most of the time, the fix is within five meters of the initial position, which is up to specification, so I have no reason to complain. Unfortunately, this is not as good as I would need for my application

There are several ways to increase the accuracy of the localization however. My GPS receiver is supposedly prepared for WAAS and EGNOS that are two systems (US and European based) that use stationary reference stations on the ground to correct for drift in the GPS signals. This is supposed to give 7 m accuracy 95% of the time which is good, but still not sufficient for my purposes.

These systems are instances of something called differential GPS (or DGPS). Since each reference station knows its absolute position, it is able to measure the accuracy of the GPS signal that it receives. The deviation from the correct location can then be transmitted to a GPS received to correct for these inaccuracies

This gives me an idea. Why not set up my own correction system within my house? It would be possible to use one or several stationary GPS receivers at known locations in the house to measure the accuracy of the fix. These measurements could then be transmitted to the robot using the wireless network to correct for the fix from the GPS on the robot. This could work if the drift is the same for all GPS receivers in the house. Although this method would certainly work outside, it is not at all clear that it will also function indoors where there are many reflection from walls and other objects. There is only one way to find out: time to get a second GPS receiver.

Accelerometer Frustrations

2008-03-05T09:52:00.014+01:00

I had some progress with the EK3LV02DL accelerometer. It turns out that drivers are not necessary for OS X. The device that shows up as /dev/cu.usbmodemfd411 is in fact a serial device that can be read from and written to. (The actual device name will vary. You will have to check what shows up in the /dev directory). I use the screen command to communicate with the device like this:

screen /dev/cu.usbmodemfd411 115200

This is a very useful and little known command that sets up serial terminal. It turns out that it is necessary to first turn the device on. With a logic that only a hardware engineer can understand, the required command is called "*Zoff". If you do anything else initially, like trying the other commands in the documentation, nothing will happen. The "*Zoff" command also turns on all the little green LEDs on the device. Now everything will work as long as the accelerometer is run from the screen command.

The next step was to write my own program to communicate directly with the accelerometer. This turned out to be far from easy. After several hours with different strategies. I eventually realized that it was necessary to make a small pause between each character. By waiting 10 microseconds after writing each character, the communication would work more often. Making the delay longer does not seem to change the situation. This explains why everything worked when I was typing in the terminal emulator, but not from my program that would send out characters much faster.

The sad thing is that even with the delays, the communication is not reliable. Sometimes it works, sometimes it doesn't. So far I have not been able to figure out why, but I would say that this device would seriously need some handshaking. This will need to be systematically investigated. One more day to go.

Converting latitude and longitude to meters

2008-03-03T01:42:00.007+01:00

The GPS coordinates given as latitude and longitude are very useful if you are navigating over long distances, but are not necessarily in the best form for short range navigation. It would be useful to instead use a coordinate system based on meters from an arbitrary origin. Such values can be easily found using a two step procedure.

First we calculate the size in meters of a degree at our current locations. There are several equations around the web that pretend to describe how this should be done. Unfortunately, they all give slightly different results and since I am using Google Earth as ground truth, I decided to instead estimate these values from the maps in Google Earth around my current location. It turns out that where I am, the length of a degree of latitude is 111116 meters and the length of a degree of longitude is 62740 m. Armed with these values and a location that we want to use as origin, we can transform any location into our new coordinate system where will will use the variables x and y instead and measure distances in meters.

The simplest way to make the calculations comprehensible is to convert the latitude and longitude into decimal degrees. We may also set the signs so that N and E are positive and S and W are negative. This is done in the following way:


lat_dec = lat_deg + lat_min / 60 (for N)
lat_dec = - lat_deg - lat_min / 60 (for S)
long_dec = long_deg + long_min / 60 (for E)
long_dec = -long_deg - long_min / 60 (for W)

Here lat_dec and lat_min are the degree and minute part of the latitude. We can now easily subtract the origin and then multiply by the size of a degree to get the position in our new coordinate system


x = 62740 * (long_dec - long_dec_origin)
y = 111116 * (lat_dec - lat_dec_origin)

That's it. Now we have nice workable coordinates that can easily be used by the robot as long as it stays reasonably close to the origin. Once I figure out to do this correctly I will calculate the size of a degree in a way that makes the navigation valid everywhere on earth. For now, the robot will have to stay close to home.

GPS

2008-03-02T00:12:00.014+01:00

As a help for localization, the robot will use GPS. The plan is not to use GPS for any detailed navigation, but I hope that it can be used to give a first rough estimation of where the robot is. I will use the BU-353 which is based on the SiRF Star III chipset and is equipped with a USB interface.

Communication with the GPS is very easy. The only problem is to set the communication speed correctly. For GPS devices, the default serial speed is 4800 baud (8 bits, no parity, one stop bit), which is very very slow, but still sufficient if all you need is a new fix every second. For a USB device, you still need to set the communication speed correctly for everything to work. One would have thought that the USB drivers could do this for you, but apparently that is too much to wish for. After setting the parameters, you can open a connection withe the device and start to read data from the it

The data comes in the form of NMEA sentences that consist of one line of ASCII terminated by CR+LF. Unfortunately, the NMEA specification is proprietary. It is apparently from the old days when it seemed like a good idea to keep a standard secret (or rather at $270). Luckily, the information is available on the web anyway.

The sentence I am primarily interested in starts with $GPGGA and is followed by the time, longitude, latitude and altitude, together with some auxiliary data. Each sentence ends with a two-byte hexadecimal checksum

The latitude and longitude are given in degrees with decimal minutes. This is different from the alternative model where degrees, minutes and seconds are used. For example, I read the following sentence from the GPS:

$GPGGA,100753.000,5543.7019,N,01301.2776,E,1,09,0.9,8.8,M,40.6,M,,0000*51

This means that the fix was taken at 10:07 UTC, at latitude 55° 43.7019' N and longitude 13° 1.2776' E. Putting these coordinates into Google Earth, I get a cross just above the room where I am writing this.

This is good news. If this precision is not just an accident then it means that GPS has sufficient precision to be used for my purposes even though I am indoors. Something GPS was never intended for.

By the way, the number 09 in the sentence indicates that the GPS is currently using nine satellites to make the fix.

Motor Calculations

2008-02-20T00:42:00.027+01:00

I started to do some calculations for the motors that will drive the treads. Ideally these should be fast, strong and light. To select the right motors it is necessary to calculate the required speed and torque of the motors.

I want the robot to have maximum speed somewhere between 0.5 and 1 m/s. The diameter of the sprocket wheels driving the treads is 9.5 cm including the treads, which is the equivalent to a circumference of 30 cm. This means that the motor must rotate between 1.7-3.3 rotations per second or 102-198 rpm (rotations per minute). There are plenty of gear-motors with these speeds so this should not be a problem.

The second thing to consider is the torque that is needed. A main factor here is the weight that the final robot will have and the maximum inclination that it will be able to handle. It is hard at this point to be sure of the final weight, but my previous robot which has slightly fewer components but uses a too heavy aluminum frame and a very heavy battery is 14 kg. I will try to make this robot lighter, but let's assume that the final weight will be 20 kg just to be on the safe side.

I will assume that it is enough if the robot can climb a 10 degree slope. This means that it will need to counteract the effect of gravity at this angle which is g * sin(10) = 9.81 m/s² * 0.17 = 1.7 m/s².

If we want the robot to accelerate to its top speed in 2 seconds, it must in addition be able to accelerate with 0.25-0.5 m/s². That is, its total acceleration must be between 2.05 and 2.2 m/s². It is interesting to note that almost all the needed acceleration has to do with counteracting gravity. If the robot would only need to handle inclined surfaces of 5 degrees, the acceleration range would be between 1.1 and 1.6 m/s² instead. If it was sufficient for the robot to move on a flat ground, the required acceleration would be just 0.25-0.5 m/s². I will only look at an acceleration of the intermediate 2.1 m/s² below.

To calculate the required torque, we need to multiply the desired acceleration with the radius of the drive sprocket (with the treads) and the weight of the robot. This gives us a torque of 2.1 m/s² *(0.095 m/2) * 20 kg = 2.0 Nm.

There are several thing that I have not considered here like the extra torque needed when the robot starts, but motors are usually able to produce a much larger torque for a short time so this problem can safely be ignored. Now it is time to look for an appropriate motor which can produce a torque of about 2 Nm and a speed between 100 and 200 rpm.

Let's look at the motor to the right in the picture below from since I happen to have a number of those already that I bought from ELFA. It is manufactured by Micro Motors and is called type E192 and its weight is between 385 and 480 g depending on the model. It can be ordered with different gearing and for a motor with a speed of 155 rpm it will have a torque of 600 Nm. For a slightly slower speed of 105 rpm, the torque will be 900 Nm. These motors are fast enough, but have too low torques. To get a torque at 2.2 Nm, the speed needs to be reduced to 40 rpm which will give a speed of the robot of only 0.2 m/s.

Of these motors, the best choice is probably the motor with a speed of 105 rpm. The torque is less than half of what I need, but the robot will have two treads so as long as it is moving straight ahead with both treads moving the torque will be doubled. However, the robot will not be able to handle an incline of 10 degrees although 5 degrees will not be a problem. Considering that the robot will mainly be used indoors, this may be sufficient.

There is an alternative however. Many smaller robots use modified R/C-servos to drive the wheels and initially I though that this would not be possible for a larger robot, but if we look at the data for a strong robot servo, the picture changes.

The Hitec servo HSR-5995 TG (shown to the left above) delivers a maximum torque of 2.94 Nm and has a maximum speed of 83 rpm. This is slightly too slow, but the torque is more than sufficient. It also weights almost nothing (62 g) and could theoretically be mounted inside the treads. The tricky part here is that these figures are maximum values so it is hard to know what this means in practice but it looks tempting to use modified servos instead of the huge traditional motor.

One advantage of the gear-motor is that it has a very robust design. Although the servo has titanium gears, it is not designed to take any load in the direction orthogonal to the axis so this needs to be accounted for if the servo is to be used.

It is also worth considering slightly faster servos. For example, the servo HSR-5925 MG has a maximum speed of 125 rpm, but the torque drops to 0.9 Nm. It may be a solution to use two servos for each thread which would double the torque, but I am not sure what will happen if the two servos act on the same thread but are controlled by different control circuits. It is possible that they will accidentally counteract each other.

Here are the equations used to do the motor calculations:

r: radius of the wheel (or thread) in meters

w: weight of the robot in kg

v: maximum incline of the ground

s: desired speed of the robot in meters per second

a: desired acceleration of the robot in meters per second squared

g: gravitational acceleration (= 9.81 m/s²)

We can now calculate the require speed S of the motor in rotations per minute as

S = 60 s / 2 π r

The required torque M (in Nm) is calculated as

M = [ a + g sin(v) ] r w

Remember to check that the sin-calculation uses degrees if the incline angles are given in degrees.

First Pictures

2008-02-18T16:00:00.007+01:00

Here are some first pictures of the different parts that I have so far. The image below shows a part of the treads and the sprocket wheels together with one road wheel. Each part of the plastic treads has rubber on one side. The friction to the ground is very high. The other gray side shows the holes where the sprocket wheels will go. The only limitation I have seen so far compared to other solutions is that the treads do not have central guide teeth. It remains to be seen how much of a problem this will be.

The wheels where removed from the brackets which also gave me a perfect axis that will be used to fasten the wheels to the bogies. As can be seen in the picture above, these wheels are nicely color matched to the treads. Now I just need to find some use for sixteen pivoting metal brackets.

Tread Anatomy

2008-02-18T02:46:00.024+01:00

One thing to think about in designing a tracked vehicle is the different types of wheels and sprockets that are needed. There are at least four different kinds of wheels.

The first is the drive sprocket that is connected to the motor. This sprocket typically does not use any suspension since this would make the design more complicated. For a robot project, the only problem is finding the appropriate method for connecting it to the motor.

The second type of sprocket is the idler sprocket that is often found in the back of the vehicle (although earlier design often placed the idler in the front). This sprocket may use some form of suspension to keep the treads stretched. The treads can also be stretched by an idler at some other place.

The third type of wheels are the return rollers that helps the transport of the treads to the idler sprocket. These are not always necessary and it may even be possible to let the treads return over the road wheels.

The final type are the road wheels. These are the ones that take up the weight of the vehicle and they should have some form of suspension. Some projects have used individual suspension for each wheel. The picture below shows a design with pivoted bogies with two wheels each. This solution has also been used in tank models. This is a simple design that may be easier to build than road wheels with individual suspension. For a smaller robot, it may also be possible to not use any suspension at all.

There can be many variants on this design. For example, it would be possible to have two drive sprockets driven by two different motors. This is the design for the HD2 robot.

Although I have not decided on the exact design yet, I managed to buy sixteen wheels that will function as road wheels for the robot. These are black plastic wheels with gray rubber tyres. They fit well with the design of the treads and do not make a sound when rolled on the threads. The wheels have a diameter of approximately 5 cm. So far, I am planning to use pivoted bogies without any springs. This will both look very good and will also help the robot when it passes over smaller objects such as thresholds.

Accelerometer Troubles

2008-02-11T01:07:00.005+01:00

I tried out an accelerometer from ST Microelecronics today. It is an evaluation kit for a sensor poetically named LIS3LV02DL. The kit itself is called EK3LV02DL. This probably means something to someone, but too me it is just short for 3-axis digital accelerometer.

The evaluation kit has a USB connection so it seemed that it would be very easy to get the communication up and running. I do not have a Windows machine so I could not test the demo programs that came with the kit. Instead I hacked together a small program to communicate with the device using the fairly simple communication protocol.

The procedure should be easy, the USB device shows up on my Mac as a device in the /dev directory and all you have to do is open it and read and write to it - or so I though. This has worked well for every other USB device I have tested, but in this case nothing happens. Well almost. I managed to get my program to crash by pressing the reset button on the kit. Always something.

I suspect that I do not have the correct drivers. Most other devices use the FTDI USB to serial converter chip, but this is not the case for this evaluation kit. Instead it uses something called the ST7-USB bridge. ST7 is the microcontroller on the evaluation kit and apparently it comes in variants with USB on the chip. I am not sure there exist any drivers for OS X so I might be out of luck on this one. But who knows. A colleague of mine who had tested a similar evaluation kit tried to convince me that it takes at least three days of hard work to get it to work, so I still have two more days to go.

Track Designs

2008-02-09T13:56:00.005+01:00

I received the Lynxmotion treads today. They look much better in reality than in the images on the web. I think the dimensions of the larger size treads look more right than the smaller ones. I also received a number of sprocket wheels and hubs used for connecting the sprockets to axes and it all look very promising.

I know you are supposed to make your design first and buy part later, but I have learned that this only works the second time you are building something. You really need to see and feel the parts to realize how they can be used. I am hoping for a design where the motors can be places inside the tracks, but I am not sure whether they will fit. It will take some thinking to get it right.

First, however, I will need to decide on which type of tracks the robot should have. There appear to be essentially five types around that can bee seen in the figure below.

Type A is used in many robots and is obviously the simplest one to build. For example, it is used by the military Swords robot by Foster-Miller, as well as the Trackster and the MMP-30.

Type B is used by the PackBot robot. The flipper allows the robot to climb stairs and negotiate rather complicated terrain. Although it would be tempting to build something like this, the mechanics of the flipper is probably a bit too complicated. Since my robot will be too small to climb stairs anyway, this extra complexity may not really be needed.

Type C and D are the kind you would find in most military tanks. Type C seems to have fallen out of fashion after World War I so we can safely assume that type D works better - probably since it allows for backward driving as well.

Type E probably does not have any advantages over A except that it looks much more interesting. It is also the track design for everyone's favorite movie robot Johnny Five, which is almost enough reason on its own to use this design. One possible role for the top wheel may be to stretch the treads. This is often the case for the top back wheel of design D.

Where to Find Treads

2008-02-09T12:23:00.004+01:00

It appears that treads for robots come in two sizes: too large and too small. I am planing to build a robot that will be around 40-50 cm long and I have been looking for a suitable solution for several years. The rubber treads that can be bought are either for small excavators and are much too large even if you were to use the smallest available size. Another alternative that I came up with was to use treads from a snowmobile, but these too are a bit on the heavy side although I know of at least one project that has used them for a 400 pound robot (movie here). Other alternative methods of designing treads are described at the R/C Combat site.

Since I had something a little more lightweight in mind, I have been looking around for an alternative solution. My first stream of hope came when I saw a threaded model sold by Conrad which was about the right size and seemed to be very robust. Living in Sweden made ordering extremely complicated. It used to work well, but now that they have a Swedish distributer everything seem to be a mess. After too many frustrations to mention, I eventually received a package, which to my surprise contained a completely different model. Apparently, the one I had ordered was discontinued and they thought I would be just as happy with some other random model. Needless to say, I will never buy anything from them again.

It may have been possible to start with something like the Traxter platform, but it would have been a little too small for my purposes. Fortunately there are several alternatives. Another possibility would be to use the sprocket-driven conveyor belts that are available from McMaster-Carr. These have been used in several tank models and seem to have all the desired properties. The only problem may be the cost and the fact that they lack a rubber surface that may be needed for sufficient traction. I was almost about to order these when I came across the track system manufactured by Lynxmotion. These are very similar to a conveyor belt, but contain a rubber pattern on one side. They come in two widths and I ordered the larger size which is 75 mm wide. They can be put together to any length. It remains to be seen how well they work in practice.

Basing a Robot on an R/C Tank

2008-02-09T12:07:00.004+01:00

The first mobile robot I ever built used treads. It was a modified R/C tank with a small HC11-based microcontroller to control the speed of the treads. This was made though the type of speed controller typically used for R/C cars. Although this looked like a good solution at the time, it turned out to be a disaster. R/C toys are made to run very fast and tanks are no exceptions. It was almost impossible to make the robot run slowly. The closest we got was to rapidly turn the power for the motors on and off which resulted in small uncontrolled jumps. I have since realized that I was neither the first nor the last to make this mistake. I have only seen a toy tank being used for a robot successfully once and they had replaced all part of the toy except for the actual treads. Even though it looks as if a toy tank is the ideal starting point for a threaded robot, it isn't!

Robot Locomotion

2008-02-09T00:23:00.002+01:00

One of the first decisions that needs to made when building a robot is the type of locomotion to use. There are essentially three possibilities: legs, wheels or treads.

Although it is tempting to use legs for a robot, it is clear that in this case most of the work will involve walking rather than anything else. This is especially true for robots with two legs. It is far from easy to build a two legged robot that can do anything more than walk, and even that is almost impossible. Yes, there are several biped robots around, but most of them do absolutely nothing apart from walking, and they do not do that very well either (at least not when they are off camera). Walking gets simpler if there are many legs, but many of the problems remain. Since my goal with this project is to build a robot where locomotion is just one of several abilities, I decided against using legs. This leaves a choice between wheels and treads.

Most mobile robots use a circular body with a differential drive with one wheel at each side of the robot. This has may advantages. One is that it is easy to control the movements of the robot by simply varying the speeds of the two wheels. Another is that the robot cannot get stuck while turing since it will always be turning around the center of its body. This is a really useful property for a robot that does not know exactly what its surroundings look like. As a consequence, this is the design of many mobile robots ranging from the small Khepera and e-puck to larger robot such as the Pioneer. If stepper motors or some form of encoders are used to measure the motion of the wheels, this design also results in fairly accurate odometry.

But there are also problems with this design. One is that differential drive depends on one or several caster wheels. These have a tendency to get stuck and usually require that the robot only runs on a fairly smooth surface. Another problem is that the success of this design depends on the distribution of the weight of the robot. Ideally, the center of mass should be on top of the driving wheels, but it is very easy to end up with a robot where this is not the case and this will reduce its performance considerably. One way to make a wheeled robot handle uneven terrain is to place the two driving wheels in the front. Although this works well, the robot will no longer turn around its center and it is very likely that the back of the robot will collide with obstacles when it is turning unless it has a good model of its environment.

The figure below show the difference between the turning movement of a robot with the wheels in the middle and one with the wheels in the front. The black spot marks the center of rotation. The wheel arrangement to the right could make the robot hit an object to the left while turning. In my experience, this happens just about every time the robot tries to avoid an obstacle.

Some of the disadvantages of a standard differential drive can be overcome by using several wheels on each side of the robot. A typical design will use three wheels on each side. This allows the robot to move over uneven terrain. There are two problems however. The first is that it is necessary to let the motor drive all the wheels. Otherwise it is possible for the driving wheel to lose contact with the ground which will make the robot stuck. This can be accomplished either by using one motor for each wheel (like the Predator Sumo) or with some form of power transmission from a single motor to all the wheels. In either case, it adds to the complexity of the robot. Another problem with this design that it shares with treads is that it depends on the wheels ability to slip on the round while turning. If there are too much friction, the robot will not move smoothly. This is in fact a problem with several commercial mobile robots when they are used indoors (for example the Koala). An obvious solution would be to design a robot with four wheels and to steer it like a car. The only problem with it is that it will look like a car rather than a robot.

A particularly interesting wheel design is to use a so called holonomic steering. This a design used for example by the Robotino and the PPRK. Typically, this consists of three wheels in 60 degrees angles to each other around the robot. These wheels are designed so that they can rotate in one direction and easily slide in the orthogonal direction. By controlling the different speeds of the three wheels, the robot can be made to move in any direction and even turn. In practice, this design requires a very smooth surface which is a problem if the robot is supposed to move over a rough ground.

Finally, it is possible to use treads. The main advantage of treads compared to wheels is that its is easier to produce traction on a larger area which ideally should be better in rough terrain and for climbing obstacles. The main disadvantage is the same as for six-wheeled robots: turning depends on sliding over the ground which is not always easily done. On the other hand, treads look incredibly cool which is why I decided to try a threaded design. The only problem is to get hold of some treads which is not easily done. More about that later.