The first issue is with compatibility. Open source advocates often claim that, because the source code is available, one can make the program to run on any system they desire, even if the original developer does not want to, or is even completely unavailable. You could take a long dead project, re-compile it on your new platform, and it works. At least that is the theory. And the idea goes the same in reverse: take a new project, and re-compile it to run on an old system that no one wants to support anymore. But there is a catch. To do either stunt, one has to be rather knowledgeable about programing, and possibly the software they are working with. Then they would probably have to spend a long while porting that software (possibly creating new bugs, removing features, or breaking it entirely) just to get it to compile and run.

Case in point: I recently had a need to run a SIP phone on a Red Hat Enterprise Linux 4 machine at work (for those that don’t know, RHEL 4 is rather old, about 3 or 4 years old, I’d estimate, and they are up to 5.4). My first thought was to try and find out if the rather new Ekiga project was available as an RPM that I could easily install. All available RPMs would not install due to the old version of RHEL. So I tried to grab the source code and compile. After updating numerous libraries as far as I could with RPMs, I attempted to compile Ekiga, only to have it fail because I still lacked some libraries or versions of them. After spending hours attempting to get it to work, I finally gave up and found another way to do what I needed to do. I’ve also had a similar experience trying to build an old program for a new system. There are so many dependencies that it becomes next to impossible.

Windows people usually don’t have much of an issue with this with commercial software, as they often pack in the necessary versions of everything, and manage to make sure they don’t overlap, usually. Running newer software on older machines may work less well because of some libraries and the like, but it usually works ok, at least for a few versions.

So this idea that, because the source code is available, it should always be able to work how you want it is more theory than reality. Closed source software also has this issue, but, because of other workarounds and the like, usually sidesteps it. It does mean that, if someone happened to come along years latter to find some ancient program still running, that they could figure out the bug easier because the code is available to him.

The other issue is related to that last note: that the source code is always available. Sometimes projects die, and, despite attempts to make sure that the source stays available, it might get lost though hardware failure, or server neglect, or some other issue. Most of my projects are only available on my site, sometimes with source code included or available. Some of them are mostly abandoned, meaning I have no intention to work on them in the foreseeable future. If my server died a horrible death, it would probably take my projects with it. I have backups of them, but if I moved on completely and just had this site for historical reasons, I might deem it not worth my time and money to put back up. Or, if I passed the reigns to someone, they might not want them back up, or forget about them and not know they disappeared. I’m not saying that it will happen, but as a what if. Then, if someone finds a link to a project of mine down the line, and realizes he needs the source (or even just the binary), he can’t get it. He searches for a backup, or someone that had a copy at some time, and can’t find one. Then my project, despite being open source and available to anyone, is gone for good, and that’s the end of the line. The guy is out of luck.

I’ve run into that issue before with closed source programs. A binary library I used for one version of my web server had a bug where it wouldn’t release a graphic handle correctly, and thus the system would run out of handles and the computer would have to be restarted. I had found the library about a year prior to when I found the bug. I went back to the site to find it exactly the same. I sent the owner an email though the site, asking for either a fix or the source to fix it myself, if he was too busy to be bothered. No response. I went back a few months latter, and found the site completely gone. Not even a parked page. I probably have one of the few copies of the library left. The only difference this being open source would have made is that I could have gotten the source when I went back the first time. But I could have just as easily missed my chance had the site closed a few months earlier.

I don’t think there are any solutions to these issues. I merely want to bring them to light so that people are aware that open source is not a panacea to possible future issues.

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.

On the conceptual front, though, I’ve been working through some issues and new ideas. First, the original plan was to have just a web of concepts represented by words, and have connections between these concepts. It would start with a few base concepts pre-programmed in, and the program would deduce meaning from the connections between words, and the base meaning it found. But I realized that it would be impossible to program in kind of meaning other than, say, yes or no. Numbers might be do-able, but how would I program the idea of a car, for example, or even the idea of an object?

The first solution I had was to forget about storing meanings at all, even the base ones. Just feed it sentences, and have it graph out connections and study those patterns to find out what to say. This would work fine for a chat-bot style AI. Given some input sentence, it would generate appropriate output. It might be unique output, but it would not be creative output. There would be no understanding of meaning, or any real drive for intelligence.

But out of this came two good ideas. First, forget about the base meanings. They will be impossible to program. The computer can analyse the connections to find similarities and patterns and find some meaning. The second is multiple layers of connections. The system can graph out relations between words in terms of how they are used, and what words they are used with as two separate graphs, then analyse the patterns in the two to create a third graph that would map phrases or sentences to other phrases that would provide the output.

I also thought about how people learn to communicate. At first, I concentrated on how we learn words and such. I realized that we learn by associating a particular sound/letter set with an object or action. We realize that a car is a “Car” when someone shows us a car, and tells us that it is called a car. This came partly from watching “Dances with Wolves”, but that’s another matter. The point here is that we, as people, can observe things better than a machine, and we have a built in understanding of what an object is. We can see a car, without knowing what it is or does, and know that it is some object. We see it move, and we might think it is an animal, but it is still an object. Computers, on the other hand, don’t have that advantage. We can’t just show a computer a car and expect it to figure out it’s an object. Image recognition is a whole new challenge, and even then, who says that it won’t recognize the background over that of the car?

The more I thought, the more I realized I was off course. I was not trying to develop a chat-bot AI, or teach a computer how to speak, but use that facility to teach, training, and provide an outlet for that intelligence. What drives people to communicate, or even thing through a problem? They have to have some kind of need or desire.Babies cry to get attention that they need help, or are hungry. As intelligence grows, the needs and desires grow more complex, so that it becomes a desire to find out what something tastes like, or be near people they recognize. They figure out, through trial and error, as well as by example, how to communicate that need.  But the need itself is not to communicate, but communication is necessary to achieve that goal.

So the idea is that we setup a multi-layer graph of connections, starting first with similarities in what words are used together, then similarities in how words are used. This would then build a graph of what it thinks are meanings. These might simply be abstract nodes that the computer assigns meaning to. This will facilitate the communication. Then, to have the computer communicate, we present it with a goal, in the form of an evolutionary algorithm goal. To begin with, something simple could be used, such as atempting to get me, the user, to type a particular word. It won’t know the word to begin with, but will know it when I say it. Feedback controls will allow some measure of how the AI is doing solving the problem. The goal should be one that can be changed on the fly, if possible, so that, eventually, only a generic goal has to be set, and the AI can deside how to meet that goal. Having this need driven system makes the AI try to be intelligent and grow. By contrast, the chat-bot sytem would only grow and learn based on if it said the right thing, not if it tried to learn.

First up, here is an archive of the code and schematics. I’ll try and post a full page detailing everything latter, but here’s the initial release. Please note that I take no responcibility for it’s use. If you try and make a robot using it and it somehow kills you, it’s not my fault. You made it. How you made an RC car kill you, I’d be interested in knowing, but that’s another matter. Also, assume all this is under the GNU General Public License, aka, the GPL. Meaning, you can use it, give it, change it, and give away your changes. But it means that if you do change it and try and give it way, you have to include all the source code, and you have to give us credit somewhere. Not hard to follow, but just a heads up. This is an open source hardware/software project, you know.

Download: swarm.zip

Note that you will need the mipsel gcc/g++ toolchain from ddwrt’s site to build the router’s code. You also will need the avrgcc toolchain, avrdude, and a programmer for the AVR’s code. Also helpful would be ddwrt/openwrt’s firmware modification kit, which will let you extract existing firmwares and build up custom ones. I would attach a firmware I made up, but it is too big to post. If you have any questions, let me know.

Next, we have a series of pictures.

Car and shell

Overhead view of Car

AVR board while on the car

AVR board off the car

Motor control cable plugging in

The mouse wheel along the ground

You can see that we had to wire up the mouse manually. We used our own wire, and ran it to an old AT connector. We had PS/2 connectors, but they didn’t want to work. There was connectivity, but the mouse wouldn’t even respond correctly with the PS/2 cable attached to the mouse, let alone plugged in. The four colored wires you see are for the serial line. One is trasmit, one is recieve, and the other two are gound.  The small green board near the microcontroller is the magnetometer, or digital compass. The green terminal blocks are to route the car battery’s power over to the router. The seemingly unused 6 pin header is for programming the AVR. That is one thing not on the schematic as is not technically required. If you make this, you should probably extend the ISP pins to such a header to make reprogramming it easier. Finally, the mouse you see sticks out the back of the car, and you can see the wheel rolls along the floor. This proved much more accurate than the optical sensor. However, there is a speed limit with this, as the reported number is only -8 to +7, unlike the optical sensor, which goes from -253 to +254. But the number of points per inch is much less, so you can still travel at a good speed accuratly. This mostly stems from how often you poll the mouse.

Next, we have the movie.

You can see the first one go, then it seems to stop on it’s turn. I get the other guy in the lab to give it a push, and it finally finishes it’s path, and tells the other one to go. He didn’t expect that and jumps a foot. It’s rather funny.

Finally, we have the paper.

Download: Final Report (odt), Final Report (doc).

I sanitized it for names. “<Me>”, “<I>” and such refer to me, and “<Partner>” and such refer to my teammate on this project. I still don’t know if I like my name online yet, so I’m not going to, and especially not put someone else’s name up. I also removed the pictures that are above for size constraints. There’s a lot to it. We even had to break down the cost to make a production version and sell it. We don’t plan to, but it worked out to nearly $300 per car when you factor in labor, rent, advertising and legal stuff. Pain in the butt. Thus, this is open source everything. People that like it can copy it and further develop it. It’s meant to be a development platform for coordinated robots. Researchers and hobbyest alike can make their own and save money.

Which brings us to how I’d like to expand on what is there. First, it’d be awesome to make a web interface to control the car. Just one that would send commands or something. Second, better streaming of commands and status between cars. Third, more calibration on turning and distance measurement. Fourth, a better path calculation algorithm. Originally, I thought that each waypoint would have a goal x, y, and angle. Found out too late that you don’t need the angle, just getting there is enough. So some form of tagent that would determine one turning angle, and then a distance. Fith, driving would be so much easier if this was more tank stearing than car stearing. So it’d be awesome if someone made up a version on a different drive platform. Sixth, new sensors to do cool stuff. Seventh, port this to a router with a USB port for live streaming video. Eighth, we need new motor control circuits. Even the one that works probably will go bad soon. So much to do, and so little time, but I think it might be fun.

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.

To start with, I found I had to add some more lines to the linker flags. I found that dd-wrt mini, which we are using, does not have libstdc++ installed. The toolchains have a copy of the library for mipsel, but the read-only filesystem of the router prevents it from being loaded even if copied there to the writable part. So there are two ways of dealing with that. First, we could build our own version of the firmware and include the library there. Every possible and easy to do. The other option would be to statically link the library in at compile time. Normally, such a thing is frowned upon, as it makes bigger binaries and the point of the libraries is so that many programs can use them without having their own copies. But, this is a one off program, and statically linked programs are a little faster, and library itself would be larger when dynamically linked than the whole program with it statically linked. It also means that the program will run on standard firmware without issues.

You might notice from that and the makefile that the program is all in C++ now. I reworked a lot of code and added in a bunch of new functionality. The new code is the main reason for the make file. Three files is ok to deal with manually, but I knew that it wasn’t going to stay as three files. It has grown to 6 .cpp files, and I’ll probably end up with at least 2 more.

Well, what does it do? First, we have some sensor classes. These serve as objects that can handle the different types of sensors. As of now, we have the magnetometer, the accelerometer, and the mouse. I can’t say that the accelerometer functions will accurately calculate distance yet, as I haven’t been able to get good data to test with, but in theory it should work. These objects will be shared between the sensor reader functions and the position update functions. Secondly, there is the serial functions. This is just a set of functions that open, read, write, and close the serial port. These where all mostly written before, but now it’s packaged up nicely. Thirdly, there is the position update file. This provides a position class that has functions to keep track of where the car is and where the goal location is.

We can pause here to look at the main file, which drives this system. It opens the serial port, and attempts reads, at which point, it will feed that data into the position system. The position system will calculate an X and Y and angle relative to the starting point. I tested this code with a small test that spit out a few angles and distances (not accelerations). I then had the positioning system spit out an X, Y and angle in comma-separated-value format, which can be imported into a spreadsheet. Plotting this, I saw the angles and the movement that I roughly expected. This was rather exciting.

I have since added a class for a “movement” or a simple step (a long the lines of “move forward 2 feet” or “Turn right 40 degrees”), some functions that read that in a queue and execute them, testing for when it’s done, and as part of that, code that will send the one byte commands to the microcontroller to drive the car. This portion has not been tested yet, but will be soon. We are working on getting the microcontroller powered by the car battery and working on getting good distance data from something.

The next piece that I haven’t quite cracked is point to point drive. I have some equations and some code, but that will have to be re-written for C++. I also need to work out the inter-router communication. But if I can’t get one car to go, I can’t get 4.

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.

Just kidding, somewhat… I had a presentation about the RC car project this past week. I covered lots of details of the design so that the professors could try and find weak points, and boy, did they ever.

One of the major weak points they found was with the accelerometer. Many projects use them to determine location on a small scale. Add in a gyro and a compass, and maybe a GPS, and you know everything about your location. But what they dont’ tell you is that it involves a lot of math. To determine distance from acceleration, you have to have the complete acceleration curve over time, and do a double integral over it. The integral can be done using just sums, but without enough readings from it, you can’t get good information.

So they suggested using rotary encoders on the axles. Not a bad idea, but that would involve finding good ones and ording them. Then they would have to be mounted, and we would probably want at least two per car, and the list goes on. We could put some Hal effect sensors by the wheels and put little magnets on the wheels and thus count revolutions. This could also work, and is slightly better than the rotary encoders, but not by much. Jokingly, one professor suggested dragging a mouse behind it, thing about ball mice.

Well, that got me thinking. Mice are essentially linear encoders. Ball mice do so by converting the linear movement into rotational movement in the encoders. Optical mice do so with small scale image processing, essentially.  They take this data and send it serially via RS232, PS/2, or USB. So, if you take the guts of an optical mouse, attach it to the bottom of the car, and you run the cord up the the microcontroller, couldn’t you fake it and thus get distance measurement directly?

So I took apart a mouse that is a USB mouse that also supports PS/2 adapters. PS/2 is a much easier protocol than USB, both in terms of electrical signals and in the protocol itself. I also found out how PS/2 is suppose to work, and hooked up an oscilloscope to test it out. I didn’t have much luck, but I have since found some code that I want to try. I just need to get to the school and try stuff out. I really wish I had an oscilloscope at home….

On that note, I saw on eBay a pre-made dev board for AVR microcontrollers that can be used as a low end oscilloscope! I thought it was amazing, but still over my budget. The guy that made that is also working on one that can measure inductors and capacitors, and be a function generator, not to mention a logic analyser. That would be amazing. Like an electronics lab in a box.

Finally, as I was on my way home from school on Friday, a girl sideswiped my car. Both of us are ok, but my car is in bad shape. Luckily she’s insured, but I still might be out of a car for a while, and it might have been totalled, so…. I might have difficulty getting to school to work on these mice anytime this week.

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.