Well, if anything, count GPS out except as a "nice thing to have". As mentioned in the navigation thread, GPS, well, don't count on it in wartime situations, don't count on it now. I'm sure you'll be able to use it during times on the course, so definitely spend time working on a system that includes it, but make sure it's not built around having GPS, cause otherwise it will probably die in the middle of the desert.
Ultrasound/RADAR is probably the best way off the top of my head to do stuff within a couple of miles (I'm not sure of the resolution of either). It would easily detect large obstacles that must be avoided, as well as hopefully detect the road/track that we'd have to follow.
Image processing would come in for close range applications, for now, and definitely extend further on. One idea I have, small obstacles, gullies, people, etc, may not be picked up by ultrasound/RADAR/etc. To serve as a redundancy check, take images, minimum, one per second, to determine the lay of the land. I know for instance, RADAR will not detect a cliff edge very easily. Camera would, if you know what to look for. Yeah, it's not easy, but I'd rather spend a few weeks working on something like that, than having the entire project dive off a cliff at 40 MPH. It'd look really cool, and probably make some sort of explosion, but yeah, we wouldn't win
.
As for oganization, pick like, say, 5 (random number) main programs. Something RADAR/ultrasound, something Visual, something GPS, something based on the Sun/Stars (?) and something else that I can't think of now
.
Steps needed...
1) Figure out the main program that calls each other one (probably a bash script, at least in the beginning)
2) Figure out the main navigation method
3) Figure out each navigation check and weight (like, GPS is better than RADAR, so if there is inconsistency, GPS wins)
4) Figure out how information will be shared (files?)
5) Assign people code
6) Set up code depository
7) Start coding
I'm sure there's extra steps, but thats all I could think of on the spot.