Mini Mac Robot

Detour

2007-09-26T21:10:00.000-07:00

I am always getting sidetracked, but this time it is for a good reason. The other night I got the idea that we need something a little more fun and possibly easier project for younger people than the Robocup. So the journey in the spirit of robocup, is to build an autonomous vehicle that will win a NASCAR event by the year 2050. Since, we have to start somewhere, autonomous R/C racing seems to fit the bill. Roboracer version 0.1 is just about ready. The hardware is all setup and this week we will begin software development. The first version is going to be as simple as possible and we will attempt to traverse an empty oval racetrack. This will be accomplished by following the wall around the racetrack with only forward looking sonar and infrared distance sensors on the side to follow and keep parallel to the wall. Passing other cars will of course be the most difficult and version 1 of the Roboracer will get a few more sensors to accomplish this. Things to do: find out how to "stiffen" the shocks, take a closer look on how the CMUcam could be utilized and ground the servo power supply pins on the brainstem so the steering servo, throttle (ESC) and all the sensors will run off the same battery.

brainstem setup in eclipse

2007-09-20T14:27:00.000-07:00

The goal is to get a simple Hello world example to work with the brainstem c development. The code to get compiled is

#include "aStem.h"

int main(int argc, char *argv[])
{
printf("Hello World!\n");
return 0;
}

Project Settings:

1) GCC C Compiler -> Symbols -> Defined symbols

Add

aUnix

2) GCC C Compiler -> Directories -> Include paths (-I)

Add at least the following paths

/home/bloftin/code/brainstem/aStem/aCommon
/home/bloftin/code/brainstem/aIO/aCommon
/home/bloftin/code/brainstem/aIO/aUnix
/home/bloftin/code/brainstem/aCommon
/home/bloftin/code/brainstem/aStem/aUnix

3) GCC C Linker -> Libraries

Add at least the following Libraries

aIO
aStem
m

4) GCC C Linker -> Miscellaneous

Add at least the following object files

/home/bloftin/code/brainstem/aStem/unix_aStem_Data/ppc/aDebug/aStem.o
/home/bloftin/code/brainstem/aUI/unix_aUI_Data/ppc/aDebug/aAssert.o
/home/bloftin/code/brainstem/aIO/unix_aIOTests_Data/ppc/aDebug/aUtil.o

Note that some more files may need to be added to the above steps depending on what parts of the c development kit you are using

Enough Vacillating, Linux Wins

2007-09-17T11:36:00.000-07:00

I was pulled in by the elegance of Cocoa programming for the Mac. It is actually fun to program with. Kudos to Apple, however there were two major drawbacks when I started testing systems for the robot. I could never get off the ground. For some reason the Iogear's feature mac product, "USB to Serial/PDA Converter Cable
Model # GUC232A" has failed me. It worked perfectly connecting to the brainstem on my windows laptop and on my wife's iMac G5. But for some unknown reason, I could not get it to work with the Mac Mini. I got a bunch of strange USB errors in the system log and after two days of troubleshooting I gave up. It also did not help that older usb cameras are not fun to deal with on the Mac.

Anyway, the decision to go back to PPC linux on the Mac mini turned out to be a great. Within, no time I am up and running using ubuntu PPC 7.04 (feisty). Talk about easy, OpenCV was in the package system. So the two most difficult things: connecting to the brainstem boards and the vision cameras (quickcam 3000) worked 'out of the box'.

Test 1: OpenCV

After installing all the OpenCV packages in Synaptic, I downloaded the latest OpenCV off of sourceforge and recompiled it and ran the samples. Just like that the vision system is up and running. I ran the camshift demo and had it track by arm by selecting my arm in the image, see the following sequence of images that shows it tracking my arm.

Test 2: Brainstem

After downloading the c development kit from acroname's website for the brainstem, I needed to install a bunch of prerequisites. I think most of them are: build-essential, xorg-dev(?) and something with ncurses in it. I also had to move the libraries libaIO.so and lib.so to a new ppc folder in the brainstem directory structure. I do not think they anticipated their code being compiled on PPC, I'll send them a note to double check with them. However, all compiled and I was able to run the aSimpleRange example (./aSimpleRange) in the aRelease/aUnix folder. I placed my wife's iMac G5 about 68.5 cm from the GP2D02 sensor and got back good readings (104 -105=> 70 cm) considering I have not calibrated the sensor yet.

The next step is to test each robot component one by one in their own test program to help calibrate and make sure all are working well before trying to combine them into one large program. Items to check first:

Completed

1) OpenCV: capture complete
2) Connect with brainstem: complete

Todo:

3) IR sensors, GP2D02
4) IR sensors, analog Sharp GP2D12
5) Sonar sensors
6) DC motor control (PWM out to Motor controller)
7) Read DC motor encoders (tested under windows, worked great)
8) Read R/C signals coming in from Futaba receiver and control motors with brainstem, currently had it working under direct control from transmitter
9) Connect Mini to DC-DC converter and run from battery
10) Have Mini autonomously control motors
11) Implement PI or PID controller and test accuracy
12) Speech system (this is where Cocoa on the mac was great, easy to do, linux will be much more difficult), I have used festival for speech synthesis, but I have not yet found a speech recognition engine to use.
13) Finally, combine everything and start working at the architecture level

usb to serial device

2007-09-02T19:22:00.000-07:00

This is just a reminder to install the usb to serial device for the brainstem from iogear's websit e and not acroname. The link is

http://www.iogear.com/main.php?loc=product&Item=GUC232A

Fedora on the Mac Mini

2007-01-18T22:57:00.000-08:00

After a long period of evaluation, I have decided to develop the robot for Linux. I just felt that development under the Mac felt too restrictive, somewhat like developing for Windows. This will also have the most flexibility for future platforms. The Fedora 6 install (make sure you download the PPC install iso) went smoothly, but take note to get the wireless Airport card to work you need to copy a file from Mac OS X system. Save this file to copy later after install:

/System/Libraries/Extentions/AppleAirport2.kext/Contents/MacOS/AppleAirport2

You need this firmware file to have the bcm43xx module work. So after install and your computer is up to date then copy the firmware and reload the module

bcm43xx-fwcutter AppleAirport2
mv *.fw /lib/firmware/
depmod -a
modprobe bcm43xx

Now configure the wireless card as normal using System->Network.

If your video comes up with only 800x600 resolution use this file for your xorg.conf

Encoder Sensor Analysis

2005-06-06T20:24:00.000-07:00

The goal of this analysis is to make a decision on buying the Lynxmotion SingleLine Detector (SLD) or the Hamamatsu Photoreflector (HAMP) to use in detecting the encoder pattern. Even from a qualitative point a view the decision is still not easy. The SLD is $14.95 and the HAMP is $2.20. If I go with the HAMP, I can purchase 2 more IR distance rangers. However, minimal external circuitry is needed to interface with the brainstem. While the SLD comes with three convenient wires that can be directly plugged into the brainstem. As far as mounting issues, the HAMP will be a little more difficult, since its pins are small and may need to be first mounted on a PCB.

The quantitative analysis will focus on the frequency response of the 2 sensors because I have mounted the encoder disk onto the high RPM shaft of the motor. I do not know the RPM of this shaft, but it is fast! First take a look at the 2 datasheets, HAMP datasheet and the SLD datasheet. Note that what I call the SLD datasheet is the datasheet for the IR sensor and not the User's Guide given here. After all the circuit will not be faster than the IR sensor.

Looking at the rise and fall times shown in the graphs of the datasheets, the worst cases are 1 milliseconds for the SLD and 4 microseconds for the HAMP. Figure 1 depicts the relationship between the pulses and the encoder.

figure 1

At the 'start' where the red arrows are and going in a counter clockwise direction, the voltage will be 0 corresponding to the reflectance of the white. There are 2 quantities of interest here. One is the rise and fall time of the pulse and the other is the length of the pulse. Since the SLD could take 1 ms to 'rise' to 5 volts when it goes into the black area and then 1 ms to fall back down to 0 volts, there could clearly be issues if our pulse was 2 ms wide. This could create either a triangle with an analog input or a missed pulse for a digital input. So without caring about the pulse width, I'll call this 2 ms for the rise and fall the theoretical limit. It should not be attempted to use the SLD sensor for anything near this speed or faster. The HAMP sensor had a rise and fall time of 4 microseconds, so each pulse will have a limit of 8 microseconds.

Next, we are concerned with what this translates into the fasted RPM that the sensor can deal with no regard on how the microcontroller will sample the signal (this will come later). For my case (and this will change based on encoder disk), I have 4 pulses per revolution as you can see in figure 1. This means the limit for the SLD will be 8 ms per revolution and for the HAMP it will be 16 microseconds. There are 2 rises and 2 falls for 1 revolution so multiply the rise/fall time by 4.

Finally, to get the RPM limit we need to convert microseconds and ms to minutes. Essentially, think that there are 8 ms per revolution so how many revolution can be done in a minute. First convert to seconds so this is 8 x 10^-3 seconds. Then convert to minutes so divide by 60 to get 1.33 x 10^-4 minutes per revolution, but we want revolutions per minute so take the inverse, which yields a theoretical limit of 7500 RPM. Doing a similar calculation for the HAMP, yields a limit of 3,750,000 RPM. Clearly, we want to stay away from this limit so choosing a 50% 'safety' margin gives a max of 3750 RPM for SLD and 1,875,000 RPM for HAMP. If I choose HAMP, the limiting factor will be sampling the sensor and not the sensor itself. However, the SLD is too close to risk so I'll be ordering the HAMP. Look forward to an article on interfacing this to the brainstem in the coming weeks.

Test 1: Mini Power Draw

2005-06-03T18:42:00.000-07:00

The mini ran for 4.33 hours using an inverter on a 12 volt 18 aH battery. Divide the aH by the time so 18/4.33 and then multiply by the 12 volts to get an approximate 50 Watts of power. I had iTunes playing music and SETI running the entire time to tax the CPU and then 2 usb cameras plugged in. Overall, I think this is the upper bound because the battery I was using is quite old (4 years). I am going to pick up another battery and run the test again. Also coming soon will be CAD drawings of the robot layout using Sold Works. In the future, I'll try to convert this to an open source cad program, but for now I am trying to brush up on my SW skills.

Cold Feet

2005-06-02T18:03:00.000-07:00

On the eve of the operation I realize I do not have the heart to splice the mac mini's power cord to accommodate the CNX-P1900. Carnetix says they are trying to acquire the funky power plug (estimated to be around Aug/Sep), which will leave the power cord intact. Since I have a long way to go before full operational capability, I will use an inverter for now. Tonight, I'll try and run an endurance test.

Return to Power

2005-06-02T17:58:00.000-07:00

The mac mini is back from the shop. Apparently, the optical drive broke and they replaced it. The DC-DC converter also arrived so it is time to begin.

The Shaft Encoder Debacle

2005-06-01T20:02:00.000-07:00

Someone once said that you should look before you leap. Clearly, he did not have the robot tinker gene. What started as a simple layer add on to accommodate the mac mini with a big battery, turned into a complete robot redesign. Ok, maybe not a complete redesign since I like my stacked platform layout (see picture below), but every system is getting a thorough examination.

Starting at the bottom I decided to upgrade my motor control capability. Originally, I thought my robot could do without precise relative positioning (i.e. dead-reckoning, INS). After all do you whip out a ruler and measure the distance to the door before opening it? I was convinced navigation could be handled without 'counting the inches'. Then I read the technical report "UMBmark - A method for Measuring, Comparing, and Correcting Dead-reckoning Errors in Mobile Robots" and realized I needed to come up with a better navigation plan. The paper made it clear that one must take advantage of absolute and relative positioning.

The only real option for relative positioning due to cost is dead-reckoning. So what do I do? I dive right in and start making shaft encoders without any analysis of the problem. I assumed there was nothing to worry about and the 43 pages in "Building Robot Drive Trains" about encoders equipped me with all the knowledge I needed. I should have known better. In all those pages there was no mention of how good an encoder needs to be to help feed dead-reckoning navigation. It may be elsewhere in the book but this is unacceptable. Before you decide to build shaft encoders, DO THE MATH!!! It is simple and can save you many hours of frustration. The technical report goes through the math, which is so simple Homer could do it. We will get to this later, but for now I will retrace my steps so others can learn from my misfortune. As the great philosophers at Despair, INC. informed us, "Mistakes - It could be that the purpose of your life is only to serve as a warning to others."

The first problem encountered and the reason why I so easily bypassed the need for encoders is how to attach a encoder pattern. I couldn't attach it to the 'rear' part of the shaft as you can see in figure 1.

figure 1

Although there appears to be room at the front of the shaft as seen in figure 2, the problem occurs when the wheel is attached.

figure 2

The wheel and hub assembly are shown in figure 3 and there is no room for adding an encoder wheel and a sensor because the air nozzle gets in the way.

figure 3

Luckily, a solution was available thanks to the one tool every robot builder must have, the dremel. I mounted the hub on this side of the wheel because the other side had some metal in the way as you can see in figure 4.

figure 4

I know I tried to remove this at one time and failed. Clearly, I did not posses the power of the dremel. I used up about 20 cutting wheels, but I sliced through that metal like a spork attacking a coconut. The upside to this modification, which otherwise would have been a waste of time , is that I can now easily pump up the wheels without removing them, since the air nozzle is now on the outside of the assembly. The intermediate result which is now obsolete is shown in figure 5. The details of making the encoder pattern was more onerous then dealing with Microsoft Windows, which is pushed on us by our evil IT overlords at work.

figure 5

Making the encoder pattern turned into the 2005 Memorial Day boondoggle. It has been a couple years since I used a graphics program for more than cropping pictures, but come on the pattern is simple. Well, I tried openoffice draw, power point, paint and a paintshop pro trial. I could not get the fill option to work. I created a circle with the correct dimensions. This is easy in openoffice and I could choose cm units from in the options. Then another joy happened when I found I could easily create a line segment, copy and paste it, then rotate to a desired degree. So 36 copies later I had a great pattern with a circle and 36 equal segments. So when I began to try and fill in the segments a thick fog of frustration settled in as I could not do it. I tried grouping and merging by selecting on 2 line segments and then the circle, but the fill never worked or it filled in the whole circle. The next course of action was to use the select tool and try to come close to selecting a 'pie piece'. No luck, it would never follow the line. After about 2 hours of frustrating trial and error with different programs I decided to print it out and color in the segments with permanent marker.

In the drive train book it mentions using transparency paper and a cdrom to help with reflection. So after gluing the pattern on a cdrom I built the circuit to test the IR sensor. For a while, I thought I was just choosing the wrong resistors but then I tested it with regular paper and the circuit worked. The problem is that the permanent marker still reflects. So I just replaced the transparency with regular computer paper and all was well.

Once the pattern was installed on the hub, I began to be curious about how good it will be. The simplest calculation involves the linear resolution. As one segment passes the IR sensor, how far did the wheel go forward or backward. First, look at the equation given in the UMBmark paper.

C_m is the conversion factor to translate encoder pulses into linear displacement. D_n is the nominal wheel diameter. n is the Gear ratio of the reduction gear between the motor where the encoder is attached and the drive wheel. C_e is the number of pulses per revolution. For my case D_n is 8.25", n = 1 since my encoder is attached to the wheel and C_e = 36 pulses per revolution (Just count the number of segments on your encoder). Performing the calculation yields 0.72" for C_m. This means if I measure one pulse the wheel moved 0.72" inches.

Is this good? Assuming my sensor does not miss any pulses and I go 10 feet (120") and having everything else perfect (no wheel slippage, uneven floors, etc.) I should expect to be +/- 0.72" for 0.72/120 or a 1.4% error. Not too shabby. Unfortunately, this hides the real problem and that is rotation. If my robot is to perform the UMBmark test it has to do 90 degree turns so I need to find out by angular error.

This is a very rough estimate, but it should reveal the problem. Assuming the distance from one wheel to the other is 15", then this is the diameter of my turning circle since my wheels are on the outside of the base. So if I am off by 0.72" on a turn as shown in figure 6, I calculated the angular error associated with this by taking the inverse tangent of the angle.

figure 6

theta = 5.5 degrees. Now this is a significant error. After three turns in the UMBmark test, the robot could be off by16.5 degrees from intended heading. So back to the drawing board.

The dremel came to the rescue again. After taking apart the robot there seemed to be enough room to shave off some hopefully unneeded backing in the rear of the motor. By shaving off the back, I bought about 3 mm on the end of the shaft (figure 7 shows this nicely).

Yipee, I can attach an encoder to the rear shaft and obtain all the resolution I need. This means the dominant errors for dead-reckoning will not be the encoders, but other things like uneven wheel diameters. The weekend is now over and it is time to rest. Next will come a battery test to see how long the mini will run on an 18 ah battery. Of course the mini needs to return from the shop and the power supply from mp3car needs to come in.

Mini in the shop

2005-05-27T12:34:00.000-07:00

Its a sad day in the robot workshop (the bolts are only being threaded halfway). The mini mac is in the shop for a couple days and to add lemon to the wound Memorial Day is around the corner. The blasted computer 'ate' a cdrom and won't release it. I've tried numerous ways to make Kit regurgitate the disk but all attempts have failed. Since I cannot work on software, I'll try to add details about the hardware this weekend. The biggest pressing issue is during a redesign of the layout to accommodate the mini along with a larger battery, should I scrap the wood I am using for a prototype and machine its aluminum counterpart or do I stick with the easy to work with wood?

Mac Mini DC-DC Power Supply

2005-05-20T12:28:00.000-07:00

I thought I was going to have to use an inverter to get the power to the Mac from a 12 v battery source, but thanks to Carnetix they've developed the CNX-P1900 for $100. Also, Tom's Hardware Guide reports the mini's power draw to be around 20-28 Watts. I haven't shown the pictures yet, but a prototype of the mini mac mobile platform is nearly finished. I've used simple hobby wood for now until the design is finalized. The last nagging issue before the software code is developed is the USB camera issues on the mac. To my disappointment, I've only been able to capture from one USB camera. This may be enough for awhile, but I was going to have 2-4 cameras. I also may rethink this since the iSight is a lot higher quality than my quickcams and it uses firewire. More on the design and architecture will come this weekend. So long, until I post again.

The mini

2005-05-19T17:07:00.000-07:00

I invite you to come along with me on a journey to create robots based on the Mac mini. The mini's size of 6.5" x 6.5" x 2" begs us, no demands us to build an autonomous mobile platform around it. No self respecting robot hobbyist could possibly resist, so the quest begins.

This blog will serve a myriad of purposes. One is to create a place for rapid updates, pictures and descriptions as the building of Mini Mac aka Kit unfolds. Another is more of an experiment. I believe blogging can be an important if not a core part of projects for those of us who are not disciplined enough to document well as we work. Too often have I had to write documentation after the project is nearly finished. So enough is enough. I must blog while I work. Anyway, who can whistle when you're surrounded by cubicles?