Solar Car Power Management

Multi-Programmer Support

© 1996
Paul Vincent Craven
All Rights Reserved


The choice of an operating system for this project was a difficult one. We needed a system that was capable of doing what we wanted, that we had the tools to program with, and the expertise to match. Many programmers stay with only one operating system because they become familiar with it. After that, it only makes sense to switch operating systems when another system's advantages outweigh the disadvantage of having to learn a new one. I have been fortunate enough to have had the opportunity to program 16 bit Windows, 32 bit Windows, and Motif applications. I have kept up with OS/2 functionality, and several years ago programmed a few small Mac sample applications. My preference runs with Windows NT™ as it seems to have the most power with the least complexity. OS/2 looks to be comparable, but I have not had enough experience with it to warrant choosing it as a platform. We needed a robust system with support for multi-threading.

When conceiving of this project in the fall of 1994, there were a lot of people that felt UNIX would have been the better operating system to use. At that time, I didn't know how to program X-Windows applications under UNIX. As leader of the power management group, I asked the UNIX people to come up with a basic sample program. No one was able to do that, so I started programming in the environment I knew best at that time, Windows NT™. It supported multiple threads, pre-emptive multi-tasking, memory protection, and had an acceptable interface.

Making the power management software in a Graphical User Interface (GUI) environment brings with it some problems. Few schools, including UMR, teach GUI programming. This means that there are few students available for development on this project. It is critical for the developer of the power management software to find a replacement for when he or she leaves. In order to keep the power management software supported, it is necessary to recruit a student with experience in C++ and who is willing to learn GUI based programming. This is difficult as most of the students who volunteer to help out with the solar car project are freshmen. Without experienced students already on the team it is hard to keep advanced portions of the solar car project going.

In a similar manner, using an on-board computer that can only be programmed in HC11 machine code also presents a maintenance problem. For the car to be raced in '97, we decided to go with an on-board computer that is supported by a C compiler. The '95 car could be programmed only by the two students on the team who knew HC11 machine code. One of those students quit just before the race began, leaving us partially stranded. Switching to C presents a considerable improvement in maintainability because students that can program in C are in abundance because it is now the language of choice for most programming classes.

The power management team needs to work extensively with other people outside their group. Other people that were involved in power management were: VP of Electrical Systems, Director of Power Management, Faculty Advisor of Electrical Systems, and three non-office holding individuals. In finding out how to minimize the power usage of the solar car, it would also be essential to work directly with the mechanical engineering teams once the electronics of the system are working.

REVISION CONTROL SYSTEM

For the '97 project, we are set up to support multiple individuals working on the same set of source code by using the RCS program. RCS is an acronym for Revision Control System. Using RCS it is possible to "check in" and "check out" code from a repository. Every time the code is checked in, RCS sees what changes have been made from the original. It keeps these changes so that you can revert the code back to previous versions. Proper use of RCS locking keeps people from working on the same source file at the same time. Keeping track of revisions allows programmers to revert to an earlier version if a bug was introduced into the code. The latter feature allows more freedom with programming, as the programmer need not worry that a change will break the code, and he or she will not be able to get it back to working order.

RCS works on almost any platform, so the central code repository can be put on Windows NT™ machines, Suns, or most other UNIX platforms. There is an account called solarpm on the computer science machines that allows students to access the Sun computers via Telnet, and then use RCS from there. Of course, this adds the extra step of having to transfer files back and forth from the computer science account using FTP. In the future, the UMR Solar Car Team can move the code and revisions to Windows NT™ computers in the office and forego FTP step.

To check out code, the programmer issues the command co -l file.cpp, where the -l "locks" the code and prevents other people from changing it until it is checked back in. When the code is checked in with ci -u file.cpp, the individual can leave a log message detailing the changes he or she made to the code. If there is a problem, previous revisions of the code can be checked out. Programmers can track changes to the code by looking at the revision logs.

NEWSGROUPSNEWSGROUPS

One new way that we decided to foster communication for Sunrayce '97 was to set up a newsgroup server. News servers allow messages to be "posted" to a newsgroup. We set up newsgroups for operations, mechanical, power management, and other branches of the solar car team. These newsgroups allow anyone on campus to see what ideas are being discussed in that area. This is more open than e-mail, where only the recipient is aware of what is going on.

We set the server up on the solar car office's Windows NT™ computer, solar-car-1.stuact.umr.edu. This allowed us to easily administrate our own groups, adding and deleting them as we saw fit. The software we used was NNTS version X2.06 by Jeff Coffler. It runs as a multi-threaded service under Windows NT™. As we were not using it to handle too many discussion groups, it ran acceptably with only 16 megabytes of memory. Before the server could really be useful though, it would be necessary to have it "push" the newsgroup information to UMR's main news group server. Since most people use the main server, it was too inconvenient to keep switching between both servers.