I’m sure you where all excited with that makefile from last time. Reading between the lines (well, actually it had it’s own whole line, but that’s beside the point) about the progress on the robot project. Well, I’ll tease you a little more.

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

It’s spring break, and you know what that means: school projects!

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.

I don’t know if anyone noticed or not, but I’ll let you all know anyway. Some of the wordpress include files got corrupted and so things where hairy for a while. No data was lost, but I had to reinstall the files. Nothing worse than that update the other week, but it was dicey if it would work. If you where getting blank pages for a while, that’s why. It was reporting an error code 500: Internal Server error. PHP was logging parse errors, and fixing the few that I tried didn’t do anything but find another one. So I just replaced the whole thing.

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.