The Larry Project

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.

Here are the slides from a presentation a few weeks ago. Presentation 1

I worked for 3 hours today. I finished the electronics. The next step is testing, calibration, and more software writing.

I put some lights in the computer box. Now the computer can tell me how it is feeling. A blue light for ok and a green light for not ok. I’m using the analog outputs on the computer to drive the lights, since this looks like the simplest way to wire it. It also gives me the ability to have variable light intensity, which might be useful if there was a need for it for some reason.

I need to remember to be careful with the pressure tubes. I have a software shutoff if the transducer outputs are too high, but even temporary voltage spikes could be bad.

I had to weigh all of the gear. It was a bit like building a sand castle.

The old pilots had to make way for the wave of the future. They were bitter, but when faced with the possibility of being used for shotgun practice, they were happy to move over.

I spent about 4 hours working on the project today. I wrote a routine to handle the acd’s on the computer. Right now it takes 16 readings on each channel, then returns the averages. This makes the outputs fairly noise-free.

Then I went home and finished the airspeed/altitude/infrared/temperature box. It is ready to go except that I need to add tubing for the pressure sensors.

I also took a bunch of pictures of stuff, and weighed all of the onboard gear. The whole lot weights a little less than 4.5 pounds.

I spent 13 hours today working on the serial interface programming for the IMU-flashlite connection. I have a fairly reliable working code at this point. I don’t have any validation screens on the incoming data yet. There are a few misplaced characters and a “soh” character that pops up from time to time. Either this character is resulting from a binary error in the signal, or the tsr driver is adding it for some reason. It appears to replace a zero in the stream. That doesn’t seem to make any sense because the ascii for zero is much different than the ascii for “soh”. If anything, I might think it was a null character with an error in it, but the IMU doesn’t send null characters. Oh, well. I’ll figure it out. I have a suspicion that I am bothering the serial driver so much that it is getting a bit out of whack. I think I will resrict calls to it and rely more on the buffering. This will add a bit more lag to the measurements, but not too much.

I spent about 5 hours programming today. I’m working on the routine that assembles the IMU outputs into a useful structure in the flashlite. It would help to have a good timer, but I don’t. As of now I think I can get away with using the serial driver that I had already started with.

Some windows updates screwed up the avr c compiler on my computer. I got that fixed, but now the loader section of the avr chip is fried. It probably got corrupted from all of the reprogramming I was doing. So now I’ll have to either try to totally reprogram the chip or program a different one. I don’t really want to pry the old one out of its mounts, though. At least the main program that’s already on the chip is a good one. I was going to simplify the serial communications a bit, but that’s out of the picture for now.

I have been using a sort of prepackaged serial driver on the flight computer up until now. I see that it isn’t going to work well because I will end up having to poll it even though it uses interrupts internally. Instead I will have to write some interrupt-driven routines which I can control directly. The transmit can still be polled. I don’t know if I’ll be able to use interrupts for the GPS, though. I might just hook the GPS up to the console port and use interrupts that way.

I spent 7 hours today fine tuning the IMU software. Since the flashlite doesn’t have a high resolution timer, I had to use the atmel computer to make a timer. It uses one of the 8 bit timers on the controller and an interrupt handler. The timer has a resolution of 1/125 seconds. I did some testing to see how consistent it is. I made a plot of timer cycles vs time in excel. The plot showed a linear trend with a consistent slope. That is good.

The IMU sends the timer ticks over the serial interface to the flight computer. This will provide a time reference for all the measurements.

I spent 1 hour tonight writing functions to send servo commands and the reset command to the imu from the flight computer. Next I need to write the parsing functions for the imu outputs. Then I need to write the parsing functions for the GPS, or maybe just modify the one I wrote for the guided missile.

That brings me to the question of what coordinated system I want to work in. The guided missile used a local flat earth approximation. I probably will also do that. I think the velocity outputs of the GPS are in a topocentric-horizon system, so it should work without any significant real time coordinate transformations. The trigonometry to generate the transformation matrix can be done at startup. It could even be hard coded for a particular region, if I wanted to do it that way.

I spent 10 hours today pondering, designing, and building a voltage limiter circuit. It uses diodes on three of the analog channels and an offset voltage on the other side. The offset voltage is driven to 3.3 volts by an op amp. When the analog channel levels are above approximately 3.3 + 0.7 volts, the diodes allow current to flow. The power is dissipated in a resistor.

After experimenting with this limiter, I think it is working as expected. I don’t think I will use it, though. Looking at the absolute pressure sensor data sheet, it can’t be run on a 4 volt supply. If it could, then I could just change supply levels and correct the offset and gains, and the overvoltage problem would be cured. As it is, I think I will wire the power supply for the board through one of the computer’s digital drivers. The computer will shut the board down if any of the adc voltages are 4095 for more than one measurement. There won’t be any problem under normal conditions, the only time the voltages should get that high is if the physical inputs are out of the selected range. And that’s all I have to say about that.

It is quite possible that my voltage limiter plan is retarded. I think I will at least try the zener diodes first.

Since things haven’t gone according to plan today and yesterday, I am now behind schedule by one week. Maybe I can catch up tomorrow, but I might have homework to do.

I’ve spent about 7 hours this afternoon designing an active voltage limiter for a couple of the sensor outputs. I thought about using zener diodes, but I’m not sure what effect they would have on the signals, and there aren’t any of the right kind at radio shack. The circuit that I designed uses comparators and voltage dividers to keep the output voltages in check. This is to prevent damage to the adc. The voltage dividers will drive their outputs to some very low voltage if the sensor output is above 4 volts. Since the flight controller doesn’t expect near-zero voltages on these channels, it will know that the sensor cannot be trusted.

Here is the layout.

I was going to use a flip-flop along with a couple of comparators to make the sensor board shut down when sensor outputs are too high. The flight computer could then reset the board as needed, but the board would only come back online if the voltage outputs were ok. This idea seemed like it would be fun to play with, but it was too complicated.

I’ve spent about 10 hours today and yesterday working on the project.

Last night I etched and soldered the new circuit board that has the pressure sensors, the thermistor, and the infrared sensors. The board works. Remind me not to hook stuff up backwards. That is getting annoying. I rewired the computer box. I removed the wiring for the lights, and completely reworked the power wiring and the adc hookups. It is much less cluttered in there now.

I spent about 3 hours tonight working through some simplified calculations to see if I will be able to extract useful information for attitude control from the imperfect inertial sensors alone. This would be used in a backup controller that the IMU computer would run in the event that the main flight computer failed. Some of the details are posted in the forum: forum topic.

My initial conclusion is that it is possible to get attitude information, but it depends on the ability to drastically reduce any angular rates using a gyro-based controller.

For this reason, the backup controller would have two loops: a fast innner loop to control angular rates, and a slower outer loop to control the actual attitude based using the accelerometers somewhat like tilt sensors.

I finally registered for the independent study class that goes with this project. It took this long because I had to track down the wily and ellusive Dr. Vogel to sign the form. Then I had to bite the bullet and brave the evils of the front office in the aero department.

I modified the board slightly. I added a series resistor to the voltage divider to give finer control of the supply voltage to the FMA sensors. I also removed the RC low pass filter from the FMA supply line. I don’t know why I put it there anyway.

I did a rough calculation of the data rate the IMU is using on the serial port. It is using about 22,000 bits per second out of the 38,400 bits per second maximum allowed transfer rate.

I spent another 3 hours testing programs on the IMU. I finally have a code which seems to work really well. The servos don’t jitter except for radio interference. The manual/computer control switching and failsafe works in all cases now. I’ve decreased the control overide lag by a factor of three. I did not end up using a separate signal counter for renewing trust in the PPM signal. If there is an updated PPM signal coming in at about 3 Hz or more, the PPM signal is trusted. I have disabled the high-speed servo driver. The control handoff code is now much simpler.