Solar Car Power Management

Future Development

© 1996
Paul Vincent Craven
All Rights Reserved

The on-board computer that we used was designed by an electrical engineer here at UMR. As best we can tell, something in the hardware was not working correctly on the computer. Perhaps there was interference with the components while in the car, or the on-board software was faulty. All-in-all the computer cost us about $3,000 and hundreds of hours to build. For a third of that price, we can buy a commercial data acquisition computer along with a C compiler for it. While throwing out our old computer after so much money and time is not popular, it will end up being more expensive to keep it.

The HC11HC11 chip that we use for the on-board computer is a 8 bit chip that we programmed directly in assembly. There is a 16 bit counterpart to this chip, and C compilers to go with it. Buying a commercial computer should prove to be cheaper and more reliable in the long run. The 16 bit version should make programming easier, as 8 bit numbers are hard to work with and lack the necessary range.

Another possibility is to get a low-power x86 motherboard with a data-acquisition card. This would make programming the on-board computer even easier. We could then get a Liquid Crystal Display (LCD) screen supporting the standard VGA resolution most computers use, and mount it on the dash with some soft-menu display buttons. To do this we need a small-kerneled UNIXUNIX that can run without having to access a hard disk. Simultaneously updating the screen, handling sensor information, and perhaps handling some of the operation of the car would make having threads an advantage. There are several versions of UNIX that are created to run with little memory and resources. This would allow us to save weight and power by omitting a hard disk.

Communication to the lead vehicle should be easily replaceable. It would be advisable to look into using microwave transmission between the two vehicles. Perhaps trying to even write our own wireless network drivers would be possible. Our current communication method uses two donated Fluke radio modems. During the race one broke, and we had to drive to a Fluke office and get a replacement. It would have been beneficial to have a spare on hand during the race, but at $900 per modem, the cost was prohibitive. As the lead vehicle should never be farther than one hundred yards from the solar car, the range of the radio modems does not need to be great. Instead we should look at size and power consumption of the radio on the car. The lead vehicle does not need to be as concerned with these issues.

In order to get more precise information about the car's attitude, speed, heading, etc., it would be a good idea to see about getting an Inertial Navigation System. They are often used in conjunction with GPSGPS's to provide short-term positioning, while using the GPS as long-term. INS system use change in inertia to detect pitch, roll, acceleration, and deceleration faster than a GPS can. They do not have long term accuracy however, and need to be constantly recalibrated by the GPS. Having a fast, accurate live update of the car's pitch, we could immediately change how the car operates while going up a hill.

The query language that we use to create custom graphs and tables, could be expanded to include maps. Additionally, it could also be used to configure the menus on the system. Each menu item could have a query text attached to it, describing the window to be created. From here, the language could be extended into an interpreted programming language that would allow the user to do programming on the data system itself. This would help eliminate the need for modifying the source code for the power management system itself. When a new power management theory is introduced, the user could use the interpreted language provided in the power management system. Currently, the power management program itself has to be modified.

While working at the United States Geological Survey, I learned how to work with the Spatial Data Transfer Standard (SDTS). SDTS is a standard for storing geographical data. The entire United States is available in this format from the USGS. These maps are very accurate, and include elevation models. Including the display of these maps along with the GPS data would be an improvement to navigation, especially if the course changed. Using computer libraries like OpenGL, a three-dimensional perspective of the landscape could be seen. This would give the solar car team a birds-eye view of where the solar car is, and where it is headed. The biggest difficulty in this would be porting SDTS to Windows NT, as it currently only operates under UNIX.