Believe it or not, the lack of updates is a good thing. It means I graduated and got a good job and I’m working hard. Ok, well, not good for the site or any of you people out there in Internet land, but good for me.

Anyway, I wanted to let people know some updates on what I’ve been working on in my own time. Remember all those AI post a few months back? Well, it’s not completely dead. I’ve been working through some AI tutorials that are rather practical, at least for games. The concepts are all there. I might post the project files if people are interested. (more…)

Well, here you go, folks! I’m posting everything here. Code, schematics, the paper, pictures, and a clip of the cars moving! Enjoy! (more…)

First, apologies for those people who don’t like the movie “Short Circuit”, the past few weeks have felt like that.

I’ll cut right to the chase: the robots work. Not as cool as we had hoped, yet, but still very cool.

After the last post, we where working on getting the optical mouse to tell us how far we’d gone. Initial tests where positive. The mouse was reporting change and such. But after mounting the mouse to the underbelly of the car, the mouse wouldn’t report data reliably. We suspect that it was something to do with the car going too fast. It might be that we where traveling out of it’s field of vision within it’s 200Hz sample rate. But even making the car drive slowly (which wasn’t easy) on carpet barely improved the situation.

So, with the accelerometer down, and the optical mouse down, what do we do? Well, with time running short, we turn the mouse upside down and use the wheel! This setup finally got us measuring distance reliably. very hacky, and not as cool looking, but functional.

I then worked up some TCP code that would have the cars talking to each other. The idea here was that there would be a lead car that would calculate how to drive, then share it with the other cars. To test, we set the one car we had built as a following car, and a router as a lead car, then adjusted the code so that the lead car wouldn’t try and go and wouldn’t hold up the other car. This setup showed that the one could tell the other how to drive. The following car seemed to drive accurately, too.

So we go on and try and do a full test of this. And then the car stops being controllable. The router still works. The microcontroller still works, but the car keeps trying to go forward. Apparently we are now down to two cars. So we build up car number 3. But my partner tells me he blew out the final car a while back. Dont’ ask me how, but he did. One car isn’t a swarm. We could do the router-car swarm, but that isn’t much either.

So with one working car, we continue to test accurate driving. My partner works out a replacement board for a broken car. We think the car’s board is a simple H-bridge, as it seems to work like one, but we couldn’t find the parts to fix it. He built a new h-bridge finally, but it drives weakly. But it will do.  On my end, I find out that the turning code is off. It isn’t always registering turns accurately. I add in code and find a whole bunch of math errors. Most of them involved the fact that our angle is always between PI and -PI radians (-180 to 180 degrees). This causes issues when the angle jumps from -3*PI/4 to +3*PI/4 (a turn of 90 degrees over that jump). I finally figure out an equation that compensates for that.

Now we finally have two cars to drive. I set it up so that one car still just sits there and the other car get’s it’s instructions, then goes. But it just sits there…. Turns out that my TCP code for that part shouldn’t have ever worked. It assumed that my TCP stack would tell me there was data even if I had already read it, so that if I got 3 instructions in one burst, I’d only read one of them and ignore the rest until I got another packet, where I’d read one more, and so forth. So how the code was working before was a mystery.

I fixed that bug, and it seemed to work again. I adjusted the code so that the lead car would drive and then tell the other car to go. The lead car (however slowly due to the H-bridge) would go, then say it was passing control. The other car would then crash. I added debugging and saw it crashing between two lines of code that it wasn’t crashing on before. I added more debugging to see if maybe I had a Null pointer in there. And it stopped crashing. I do more tests and it starts crashing again at random locations. This is a pain. I suspect what happened was that the lead car would send the go command repeatedly, and the follower would fill up it’s TCP buffer and segfault. So I made the go signal send once and it fixed the problem. Rather, I made the go code send once, and it fixed it, so I think that was what the problem was.

At this point we where suppose to demo it to the professor. We have it working in tests, but when he showed up, it stopped working. it would drive off into walls and not go and such. Not going and driving randomly seems to be noise in the serial line. So we filter that, and we send commands multiple times. Running away in a turn seems to indicate more turning math problems. Multiple passes through finds most of the math errors, but seems to cause more harm than good. Now it doesn’t turn correctly at all. I measured the compass data over a complete revolution and put it in excel and saw that the angle was always within a small range pointing mostly to the drive motor. Moving the compass to the front fixed it somewhat, so I measured the bias and just fixed it the rest of the way in software. Add in some noise filtering and it’s good to go.

More testing and a lot more time finally gets one car to do about the same thing as the other. It’s about a week latter than the demo date, but the professor said he’d still like to see it, even if it is late. I made a video of it on my camera, just in case, then show it to him. It finally worked right and it’s done.

Yes, that’s a long summary of about 3 weeks worth of work, but it’s done. When I get a chance, I’ll upload the video and some pictures to this post, so check back. I’ll also upload all schematics, code, and the final paper at a later date. The whole project will be under some open license so that people can make use of it. I don’t know about support or updates, as I don’t know the interest, but at least people can make free use of it.

I don’t know who all here may have used Makefiles before, but I can say that they are amazing. They let you do a complex compile with one command. Every major project has a makefile because it would take too long otherwise. But they are archaic in their syntax. There are tutorials on how they work, but none are really easy to understand, and always require major editing to work with your project.

I’ve used make files before. Usually when compiling some other program. I’ve looked at them before and knew the general format, but not really how to make one. But I found I needed one to work with my growing code base for my router project. After a lot of poking, proding and researching, I created the following makefile that is mostly generic for whatever source files you have and scales up fairly well to a certain point.

#define the programs and flags to use
CC=mipsel-linux-g++
CFLAGS=-Wall -c
LD = $(CC)
LDFLAGS= -lm
RM = rm

#the output executable
EXE=serial

#List all source files here
SRC = sensor.cpp serial.cpp position.cpp main.cpp

#that should be all the editing. The rest shoudl work based on the above
OBJ = ${SRC:.cpp=.o}

#defines suffixes and how to compile
#clear out any others
.SUFFIXES:
#define the ones we need
.SUFFIXES: .o .cpp

#how to get from .cpp to .o
.cpp.o:
        $(CC) $(CFLAGS) $<

#compile everything and create executable
all: prog distclean

#link all the object files and create executable

prog: $(OBJ)
        $(LD) $(LDFLAGS) $(OBJ) -o $(EXE)

#insert other header files here and uncomment
#$(OBJ) : header.h

#removes object files and the executable
clean:
        -$(RM) -f $(OBJ) $(EXE)

#removes the object files to make things pretty

distclean:
        -$(RM) -f $(OBJ)

Lets walk through that mess. First, when we hit “make” it goes and sets up the variables up top. There, we list which compiler to use (the wrt c++ compiler), the flags to use with the compiler (warn on all, and that we are just compiling, not linking), the linker and it’s flags (linking in libm for math stuff), and our remove command. We also setup with the final executable will be named, and list all our source files. These should be the only lines we have to edit. The rest should be handled automatically, unless there are specific things you need.

The OBJ line takes the list of source files and changes the .cpp ending with the .o ending to have a list of all the resultant object files.

Make then finds our first real rule: all. It sees that to do this rule, we need the prog target and the distclean target. To make the prog target, make sees we need all those object files first. To get the object files, it sees that suffix rule “.cpp.o”. Make knows that for each object file we need, there is a .cpp file that goes with it. So when it sees we need, say, serial.o, it compiles serial.cpp. The “$<” thing becomes the .cpp file when make is running.

So it compiles all the files into object files, and it comes back up to the prog rule.The next step is listed underneath and says to link them all and output the executable. It does that then comes back up to the all rule and sees it needs distclean. This just removes all the .o files to make things nice. That isn’t necessary, but I link it.

So, just by listing all your source files in one line, we can compile and link them all automatically. Much nicer than manually compiling, or doing the same just using a makefile. This helps when you add a new part to your code. you don’t have to do more than list it.

There is one portion where you might have to add things. Sometimes you need to include a header file, but you can’t in the source files themselves. The section near the end that says to list header files should be uncommented and you should place your header file names there. This will be sure to include them for you.

By popular demand, mostly by me, I have uploaded some pictures of my RC car robot project. First, we see a nice picture of the car we are using. Yes, it is a Mustang. It some cheepo car from Target. Nothing special about it other than the size. It is a fair bit bigger than normal RC cars. It’s about 16″ or so long. Enough room for all our gadgets.

Inside is a small circuit board that houses all the goodies that let the car drive, besides the motors. On board there is a voltage regulator, 2 H-bridge circuits (one set for Right/left using small transistors, one set for drive using the large ones on the right), and an IC that translates the RC signals to control the H-Bridges. That IC just has 4 outputs: right, left, foward, and reverse. It just puts a little power out on up to 2 of those pins at a time and the thing goes. It doesn’t have variable speed or turning, but whatever.

This is after we soldered up some wires. It was also taken after we fried the small transistors, but you can’t tell.

And the Underside

I have some more pictures of motors and such, but who cares? Let me know and I’ll post links to them.

Second, we have the brains of the outfit. Not not me. The router.

This is the replacement router, the WRT54GL v1.0. Inside we see all the goodies it has to offer, such as Serial, JTAG, the broadcom mipsel processor, and the normal wireless stuff.

We can zoom in on the serial port, which has the pins added in this picture. There are 10 pins. From what I can tell, 9 and 10 are ground, 4 and 6, and 5 and 7 are the data pins for the 2 serial ports provided. In DD-WRT they show up as /dev/tts/0 and /dev/tts/1, unlike the normal /dev/ttyS0.

Finally, I leave you with very zoomed up picture of our digital compass. Those 6 pins on the top are the same size as the ones on the serial header. The board is slightly smaller than your thumbnail. It can find 64 different angles from north. Not very detailed, but enough for our work. Considering how much anything better would be, this was a steal.