The Larry Project

I spent another 5 our 6 hours last week programming. Now I have a functional GPS interface and parser. I have a small problem with the coordinate transformation to the local flat earth. The position information is not in the same scale as the speed information. I think I might have a bad number or equation or something. I’ll have to go through it again. Otherwise, I can just change the earth size/shape parameters until the speed and position scales line up.

I spent about 15 hours so far this week on the project. I’ve calibrated the accelerometers. The gyros, infrared things, pressure sensors, and thermometer all still need calibration. I’ve been working on getting the GPS information integrated in the software. It mostly works now, but I had to let the GPS take up the console port on the 386. I still need to correct the parsing subroutine to make it work right. I need to build a pitot probe. Then I will test everything on the ultralight.

I had a problem with the radio signal getting garbled in the conversion process. I found that the problem was with a timer interrupt that I was using as a system clock. I had to get rid of the timer and replace it with something a bit less accurate.

Note to self: don’t turn GPS on before 386. It can trigger the backup boot mode on the 386 if it is running at 9600 bps. I might have to go back to 4800 bps to avoid this problem.

I spent about 3 hours today working on software for the GPS interface. I tried a few different things. The last thing I tried was to poll the port in the main loop of the data logger. I could get some of the GPS strings, but usually only about 2 or three characters out of 56. The problem is that the fifo buffer on the UART is only 8 bytes. With a 30 - 60 Hz main loop, it just doesn’t get to the buffer fast enough to get all of the characters. I need another interrupt-driven serial interface. The problem here is that I don’t know the address of the UART. I can’t go any farther with this, so I emailed jkmicro. Hopefully they can either tell me the correct address, or hook me up with a driver set that will work.

I worked for 5 hours on the project today. I totally reworked the communication routines for the imu-386 connection. Now I have a program which records the inertial measurments and the other six voltage measurements. In order to get approximately 30 Hz out of it, I had to scale back the voltage sampling to 8 samples per record. It was 16 samples per record. This will make the random errors show up a bit more, but it should still be ok. In the actual flight controller, it may turn out that certain measurements need to have more averaging than others. Altitude, airspeed, and temperature probably don’t need to be measured at 30 Hz. This will allow some flexibility and still allow for good precision.

The next step is to add serial routines and parsing for the GPS inputs. Then I will decide what coordinate system to use. I am tempted to use the same type of flat Earth approximation that the missile used. Otherwise an Earth-centered Earth-fixed Cartesian system might be fairly easy to do, as well. I’ll have to look at the GPS outputs again to see what makes most sense. I think the velocity outputs of the GPS are in a topocentric-horizon Cartesian format, so local flat-Earth system for position might be really easy to do.

I spent 3 hours today trying to get the serial link between the imu and the 386 working. I’m still getting much garbage. Note to self: switch to the rs232.c driver.