Programming

[randomperson]

Ok.. obviously this isn't going to be a simple programming job. So here's what I propose:

-following the example of the Linux kernel and other excellent open-source products, lets establish a CVS or some other type of development system so all the programmers involved can contribute at the same time (someone said something about a website.. ). Following this example further, appoint project directors and code reviewers who make sure everything is up to par. (now of course this is assuming we get enough interest of more than 5-10 programmers). Now since this isn't going to be an open-source project, we need to make sure that access is only available to developers and not competitors

-At the heart of the system, lets use a very powerful PC (or two) running a Linux kernel. give the system a RAID array with lots of room for stuff, 512MB+ of memory, and like an Athlon or P4.. and whatever else we will need (lots and lots of communication ports!). There are many I/O devices, and methods of communication available for PCs. Linux is easily modified, and can run many types of programs and can be programmed using many languages. This opens up our project to myriad's more programmers.

-We use embedded systems to handle "small" tasks (such as coordinating sensors) and then feed that data to/from the central system

-Let's use a LAYERED approach. People are talking about using StangPS and etc.. (and I haven't seen the code so I don't know), but while I recognize its genius.. its just a single program. We need to use a layered approach, such as the OSI model or Win32 API or any other similar model. We need to figure out what layers are needed, communication between layers, and appoint a function to everything.

On that note, each function or data crunching/handling should be handled by a separate process/program. The processes communicate to the master process through some sort of mechanism to be determined later. I definitely think a layered approach will promote stability and will allow each function to be programmed in a different language (one can be C, another be a Perl script, etc) according to its need for speed, and so we can allow as many programmers in as possible, instead only limiting it to C/C++ programmers or BASIC or etc..

(and really, isn't the whole project kinda just a huge StangPS system anyways? But yes, stang's assistance in these navigational principles and stuff they learned from developing it would be greatly appreciated obviously.. )

-Simplicity. As this will be huge, a simple approach is necessary. Let's not overcomplicate it. Layered programming will contribute to this. (ok, maybe it sounds like I'm complicating it.. but really if you think about it I'm not. lots of thought )

-Redundancy redundancy redundancy.. as someone else mentioned, we don't want a wire or something stopping us dead in our tracks.

-Abstraction. I think we need to make the programming as abstract as possible, to allow more generic development. The layered approach will allow this because the lower levels will translate the abstract into the real for the robot.. or something like that. Basically, instead of concentrating on actual places or coordinates the programming system needs to have an abstract system that gets translated into what the robot does and is coordinated to get it where it needs to go. Heck, we could make a video game AI.. lol. Thats essentially what it is.

-Modularity. I don't think this can be stressed enough! Just about every part of the program should be easily reprogammed, replaced, upgraded, etc... I am very convinced through my own experiences (and im sure others will agree) that having a modular design from the start will be very helpful. Like I said before.. layers.

Ok, once again those were my two cents worth.. everyone fire away with better ideas and improvements to mine.

[Matt Krass]

Good idea, except for the powerhouse computer. Linux is designed to run on a small computer and it should, thats money saved in the long run and how much computing power do you really need? Also you have to think about electrical power, an old laptop running a modified linux system draws a LOT less than a big desktop screaming along with a P4. Other than that I like it, and I think we should work off the Linux-From-Scratch project. Linux-From-Scratch.org. There's a few cents in the bank. Oh yeah and for modularity, check out my Sig

[Andrew]

Save yourself some hassles. Dont' go down the Linux from Scratch route.

Joel tried this this past semester as part of a similar project to the one you're attempting.

You probably want to use something like PeeWee linux or you want to customize the installation scripts of a standard distribution.

Joel did the PeeWee thing and there are some problems with it. But, they seem to be workable. If he and Traig ever finish comprehensive documentation on their project, I'll post it.

On the customizing a distribution size, our network Guru has done this. I'm planning to investigate as the summer progresses. Once I know the general approach (ie where to start) I suspect that customizing installation scripts is a far superior approach than PeeWee.

[Andrew]

On the computing platform that you use, I would advise against using a standard laptop. You'll definitely crash the hard drive.

You might want to investigate a mini-ITX motherboard along with flash drives as the core computing platform.

[mtrawls]

If there's going to be a lot of different programmers working on the code, then definately some orginational technique will be required. You'll obviously want consistency; naming conventions, coding styles, etc. should be similar so that it is easy to look at what someone else has done and get right into it.

Guidelines should be developed that reflect the coding preference of the programmers and the project, obviously, but for a start might I suggest looking at the guidelines for Perl6? Not that these should be followed. But it does provide a good framework and understanding of what is needed.

[Matt Krass]

He's got two good points, I haven't yet finished LFS but it is tricky, and a HD + Bumpy ride = Big Mess. Also maybe Debian linux, Debian can be very slimmed down and configurable. Any other thoughts?

[randomperson]

LoL.. im tim allen.. more power! But yes, good point. Not too much computing power is needed.. maybe. We don't know yet. Definitely going for the trade-off between power and power consumption is good..

Why use a laptop?

Ok, yes laptops are designed to consume less power, and they are just as powerful as their desktop counterparts.. but we need to communicate with all the sensors and electrical equipment. If someone can figure out how to do all that with a laptop then lets use one.. otherwise we should probably go for easy expansion, etc..

Now maybe if all our electrical devices ran off USB..

Hmm.. maybe the laptop can communicate with some box that gathers all the data from the devices.. not sure.

Flash drives.. yeah, no hard drives. Or we load everything from flash and use a large ramdisk to store temp data... although we should have some kind of logging function so we know what went wrong during testing.. unless by some miracle we get it right the first time.

[Ian W.]

Looking at this, it's cool, but there's a few suggestions I'd like to make.

1) If you're using Linux, you (almost) HAVE to go with a distribution like debian (www.debian.org), gentoo (www.gentoo.org), slackware/LFS (don't know the websites). Just thinking for a minute, Slackware and LFS seem a bit too much for it, leaving Gentoo and Debian as the best choices (IMHO). The biggest difference between Gentoo and Debian is that Gentoo compiles everything for you, instead of downloading binaries, you download source, which can sometimes increase the power of the computer (more optimized instructions). I've used both Debian and Gentoo, have to say I like Gentoo a bit more (running it now, in fact).

2) You need a whole RAID array of Compact Flash cards, coupled with some sort of tmpfs RAM Drive. Then, I would also suggest trying to mount some IDE/SCSI/SATA hard drives, so they don't bounce, and store ALL of the data collected, meaning you need a lot of space. This would be, so when we win, we can show everyone else how our data was processed (We gotta think ahead, no? ).

3) We'll be doing a lot of image processing, as we have no way to see what's ahead without that. Image processing at 30 - 40 MPH. That means you need to take like, I'd think, 10 - 20 images a second, and process them all just as fast. Reason being, at 30 - 40 MPH, a rock 40 feet away will make a big hole if you don't steer around it. One interesting idea, if you can't get a fast enough computer, maybe a Bewoulf (is that how you spell it?) Cluster. Even made out of 3 or 4 machines, it'd give you that much extra power.

4) Based on suggestion #3, Neural Network are your friend. I mean, we're driving a car, why not mimick what we use to drive a car? They're efficient, fast, and while hard to program, will definitely be a big help once created.

5) Just make sure that everyone knows what everyone else is doing. If someone is making a program, make sure they know how it will interface with the rest of the car. If someone is creating a computer system, make sure everyone else knows what they're making it out of (Don't program stuff for x86, when you're building a PPC).

This is a very cool project, and if FIRST puts forth a team, and even comes close to winning, that'd be truely amazing. Imagine the publicity....

[Matt Krass]

Wow. That's exceptionally overkill in my opinion. We don't need to make a working Johnny five, we just have to get it there. And Gentoo does have that advantage of performance so I think it should be considered. But having a neural network seems a little extravagant given the situation. We need to conserve resources, electrical power is one of them. Also, moving parts should be avoided, and a SCSI rack costs a lot of money. I think flash memory is a good idea though. Also, what image processing, I dont understand why we need that, anything worhtwhile to obtain would require much more power and time then worthwhile.

Some good points and some bad (IMHO), keep em coming guys.

[Ian W.]

Unless you can program the exact route into memory, every rock, bird, cactus, etc, you need some sort of image processing to see where you are going. Remember, you CANNOT depend on GPS, hell, the rules even tell you that. My friend worked on an image processing program last summer, for use in the National Syncrotron Light Source at Brookhaven National Laboratories. It would take images and compare them as to what should be seen, and if it differed too much, it was thrown out. He tried a few approaches, and wound up using neural networks, because they were most efficient. Probably not the easiest, but easily the best choice overall.

Yes, you could get away without any image processing, but I think that if you used it to check for large obstacles while far away, and then used other things like proximety scanners for up close work. Just remember though, you will be traveling at a very fast pace, too fast to rely on one system.

I understand power constraints, so maybe a cluster is overkill, but remember, you do need lots of processing power to drive a jeep across a desert. Mimicking the human brain is NOT something you do with a 486 . Also, to deal with power constraints, would solar pannels, alternators, etc, provide enough power to power what you want? No, this is not electical, but it's something you MUST consider.

We don't need to make a working Johnny five, we just have to get it there.

Just remember Matt, Johnny Five did a lot of stuff. This will be doing a hell of a lot more, except for the talking bit.

<EDIT>
Well, it could talk, but it doesn't have to talk. I did find a pretty easy way to make it talk though, if we wanted to. I know it works on Gentoo Linux, probably on any other distro as well
</EDIT>

One last thing, about moving parts. Unless you can continuously upload information back about progress, you should have some way to backup EVERYTHING. This is another place where a image processing system may actually come in handy and be cool to implement. Check the road ahead for smoothness. If it looks smooth, powerup IDE/SATA (yeah, I guess SCSI is out) harddrives, and save everything from RAM/Compact Flash to the harddrives, for later review. You will definitely want to see what happened every second of the way, especially if you come in a top place, because then it makes it much easier to show how it works, and see exactly how well it performed.

[Matt Krass]

Ok, what you're saying makes sense, but you're not relatign ths situations. you're already delving in ot the cool addons, lets get a working system first. Many a projects failed because they started blimped up, start small and build this up, it isn't due tomorrow. I don't udnerstand why it needs a nueral net, it seems overkill, and once again POWER. A favorite quote of mine is "Those are just numbers", it makes sense, we have to plan for as little use as possible. If we can get by with a 486 then we do it, I dunn oabout you but I don't wanan have to drive four an hour to pick this thing up cause the computers sucked the batteries dry. I'm jsut saying, tone it down, let's wait and see what coms out, maybe we can implement those, but you're jumping ahead.

[EDIT]
No talkie! heh, save power dude, there is no AC outlets nearby.

[Ian W.]

One other very important thing to consider...

If this submission is built and does win the competition, or places high enough to warrent additional examination by DARPA, a design that includes everything, even the kitchen sink, through the use of modularity, will win.

Remember, this competition is simple to drive (ha, simple...). Think 20 years into the future. This technology must realize between friend and foe, human being and tree, clear road and obstacle. Yeah, you don't need to go crazy now, but the whole idea is that you think ahead, to what would be needed. This is sponsered by DARPA, they don't want any half-assed solutions, they want something that will work, and that they can add to. Look at the TCP/IP protocol suite. It was never intended to be as widespread as it is now, but due to how it was built, including everything, that you would ever need, it has survived much longer than many other things in the computer world.

So yes, while my ideas and suggestions may be a bit overboard now, it's stuff you have to keep in mind. Don't throw it away just because you don't like me, my ideas, the fact that it's a Monday, that the sky is blue, etc. Well, I'll give it to you that it's a Monday, but nothing else .

[randomperson]

Yeah.. all these system ideas are great, but...

But we're getting off topic a lil bit.

We shouldn't worry about the system right now. This is the programming thread We should build the system around the program, not the other way around. As far as I'm concerned, the system isn't an issue, because we don't need a system yet as there is no program. As I see it, we should be doing the following:

1) Figuring out how we are going to detect stuff.

Is it radar? GPS? LORAN? Ultrasound? How are all these going to interface with the program(s)? Image processing was mentioned.. can we implement this? Can we implement any of this? Does somebody have experience that can help point the way for others?

2) Block diagrams/Outlines/etc

Ok, we need to come up with a basic guideline of how this system is going to work, communicate, and etc. As I said before, a layered approach seems to be best in my mind. What elements to the program do we need? What needs to be in the program for it to do its task? What exactly is it going to do anyways?

3) Development

How are we going to coordinate development? Who's going to be in charge? Where is the code going to be stored? I think we've pretty much established we're going to use Linux for the central command system because I dont see any arguments for anything else, so what programming languages are we going to allow development in? Coding guidlines. Other stuff. More coordination.


There are so many questions that need to be answered, so let's keep it simple for now. Lets figure out how we're going to make this beast and then let's make it.

[Ian W.]

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.

[Matt Krass]

I can see you're point on the imaging. In fact I have an idea. Ever hear of the CMUCam? I don't have the link but google it. Really ncie, fairly cheap, easy to build and it's packets are well documented, we can write our own client.