An attempt at starting this thread…
As to how the autobot will navigate, there have been several methods proposed, and to win I believe we should include several of these systems to work with each other and provide the most accurate navigation.
Which ones do you think you should be included and how should these be implemented?
Also, if these systems gradually gather different data and thus provide very different readings as to where the autobot is and should be going, there will have to be a single dominant system and some good way integrate this data into a finished product. Any ideas on this front?
(bwah! with all of the war overtones and The DARPA in control of this, it makes me feel like a soldierina war on misinformation.) *
I don’t know much about programming or GPS but I think something similar to Wildstang’s awesome navigation system would rock. Not the wheel revolutions, but the waypoints. If you could set up a GPS system with waypoints to go around some known obstacles, then divert course according to it’s GPS feedback of current position, see image
I agree, I recal lGPS untis with serial feedback, if we can get our hands on those that’d be great, a little tweaking and we can probably adapt the StangPS system. Maybe some of 111’s coders can give us some insight?
Keep in mind that according to the rules, GPS signal is NOT guaranted at waypoints. GPS would be a great tool for course correction and verifying your location, but may not always be available. I’m taking a stab in the dark at this, but I’m guessing DARPA has some sort of sneaky plan to ensure that GPS navigation will not be available at waypoints. [My experience with any competition is that when told “may not” assume “will not”].
Thats my 2 cents as far as sitting here in class is concerned…
He has a point, military scenarios may not allow GPS signals. It would be a great twist to generate some form of interference. While GPS is great, we should start looking at accurate ideas to replace it. Design it like we’re planning on the obvious solutions to fail.
Yeah, as Matt pointed out, this is a military competition. They’re looking for a new technology, and we’re here to build it. Now, imagine a World War III scenario in which the GPS is strategically taken out by an opponent of the war. Now, all you’ve got to rely on is whatever insturmentation you’ve designed for navigation.
Whereas this whole scenario sounds farfetched for something like this competition, this is what the military wants, and they may throw in variables to counteract it. I mean, whats to stop them from having us travel through some granite tunnel just for the purpose of cutting off all line of sight into space.
I have a Garmin eTrex Vista handheld gps which includes a data cable to interface with a PC. The output follows a standard format but is only updated maybe once per second. There is an article on the Parallax web site that has sample code to use a Stamp as a data logger for a model airplane. I have no idea whether WAAS is active out there, without it you’ll need a DGPS receiver.
There is another Garmin product called MapSource that has very detailed topo maps of the whole United States. I don’t think they include metadata though, I’m pretty sure they’re just maps. You’ll need to find or build a detailed metabase to go with the maps.
Based on the presentation I saw on the contest website, there are some rough roads and trails. You might want to consider using them to your advantage. If you analyze the terrain you will probably find corridors that are easier to navigate than others. Your low-level behavior will be to avoid dynamic obstacles, but your high-level behavior will follow a map. You’ll need a pretty solid application to take a set of raw waypoints and find the optimal solution between them.
As Sean brought up, there will be two large parts to navigation. A) Finding the Optimal Route for the entire journey and B) Avoiding smaller obstacles along that Optimal Route.
A)The Optimal Route. By using one of these Garmin topographical maps or a similar map, we could create a program to determine possible paths based on specifications such as extreme altitude changes over short distances, waypoints, and the boundaries. This program should simplify these infinites paths into several unique paths, then rate these paths on difficulty to traverse (with determining factors such as total distance to travel, altitude changes, and materials *). During the race, the program would determine which of these paths would be easiest and whether or not it should switch from one path to another based on things like whether it had been damaged and needed a slower, easier path, or whether it could risk a more difficult path because it was shorter and the autobot had not had any trouble with obstacles so far (this would probably be a bugger to code, but I"m a mech, so I"m just throwing out ideas for you coders).
B)Obstacle Aversion. Using loads of sensors, the autobot wouldhave to get a fairly god idea of it"s immediate surroundings and decide based on that what the easiest path would be that would stay closest to the Optimal Route it was trying to follow on a whole.
Please add to, subtract from, divide, and conquer these ideas.*
Yes, one of the mentors from team 980 was on the team that built Urbie. I even know which member it is. I’m not sure if this person comes here at all or is aware of these discussions.
I don’t think I’ve ever seen them post though. So I’ve taken the liberty of e-mailing them and asking them to join us.
In case they should decline, I’m keeping their identity confidential for now. If this person should join us, then all can be revealed. If not, I don’t think it would be in anybody’s best interest for that name to be widely known.
The visual navigation system used by Urbie could be quite useful for the current problem. But in the application on the website, it seemed to require a human operator to designate the destination which apparently had to be in view. While this ability could be useful, we would still have to designate “targets” from within the control system. NO outside communication with the vehicle is allowed. Reading the rules, even recieving simple telemetry from the vehicle is questionable.
<<edit: I recieved a reply from the aforementioned individual. They are already commited to another team in the competition though they might be available for reviewing plans and similar limited involvement. Whether we want to do this with a competitor is an interesting question. >>
Hrmm, I remember reading about a pre-GPS system pilots used for navigation, often using several of these units together. The more you add the more accurate and I don’t believe it’s based on outside comms but I could be wrong, I’m gonna try to track down the book it was in.
I think you’re talking about LORAN for LOng Range Navigation or some such. If you can pick up the signals, and get a good bearing on their origin, then it would work for an approximate location.
I’m not sure about how well the system would work for ground vehicles as clutter and reflections would be more of an issue. Basically it works by figuring out the bearing to a known radio transmitter location. Transmitters are distinguished by frequency. You would have many of the same problems as with GPS, but I doubt they’d try and spoof it or interfere with it other than the normal obstructions by mountains etc.
I would be most worried about getting a bearing on a echo. Better no signal than a wrong one, at least with no signal you know you can’t rely on it.
I’m by no means an expert on this, I just know some of the general principles. Any pilots out there who want to comment?
This type of systems relies on "line of site"and may or may not be useful in this project.
Another thing to think about is where they are going to run this race.
This subject has confused some Old timers that remember another race along almost the same route,
“The Barstow to Las Vegas” MC race was killed by environmentalist,
So I’m thinking that it will be mostly on Government / Military land,
some Map research maybe in order?
Just to let you guys know… started a new thread devoted to the programming of the bot. I’m thinking this thread should be devoted (as it has been pretty consistantly) to the devices needed to navigate and how to navigate and other stuff… while the programming thread should be devoted to well… programming. Basically how to control the robot, or how to coordinate the system… or whatever.
Yeah… I wrote a nice long proposal on what I think should be done… not going to repeat here.
To be brief, don’t count on any outside communications. That means, don’t count on GPS, radio, hell, even knowing what the weather will be.
Everything should be self contained. Include GPS, as a “nice to have thing” but a thing that is only used when possible. I would assume you have some sort of coordinates to the next checkpoint, store those, use compasses, the sun, the stars, whatever, but try to make it all self-contained. We want something that will go by itself to a pre-selected destination.
I don’t know if something like that is possible, but you have to think minimalistic (if that’s a word) here. GPS and radios are great, but in war, radio silence and the weak GPS signals quickly remove those as options. Think of how troops navigate. Granted, they don’t navigate while flying along at 30 MPH, but you gotta have some sort of challenge somewhere :p.
Ok… so how are we going to tell if theres a huge rock in front of us… or a little one? Or etc.
Can anyone get this stuff? Does anyone have experience in using it? Myself I’m thinking Radar of some kind would be very useful to use… but I have very little experience using it, and I certainly have no resources on obtaining it. But let’s start coming to concrete details I think… we need to draw up a technical paper of some kind I think soon. I dunno. Ask George