SKYAID
New 
Mission
Overview   
Details    
Medical   
Watch   
Heart attack  
Stroke    
World health  
Emergency
Cost effective
Media 
- Site Map 

SKYCAR   
Details   
Overview  
VTOL   
Airline   
Military   
Transportation
Images 
- Site Map

Search

Translate 
  8 languages
 

VTOL ATC  Sept 2000 a possible class project  added 06/07/01

http://wiki.cs.uiuc.edu/SEcourse/VTOL+Air+Traffic+Control+System+(Revised)

VTOL Air Traffic Control System (Revised)

For a project that is feasible in this class, I propose that a group write a Prototype of an air traffic control server that manages a limited section of airspace by providing routes from one point to another within that airspace. The system will be real-time in providing current information about all skycars enroute. The skycars will be simulated in input or driver files as requesting routes, and the GPS services will be simulated with basic, local interfaces.

Since the air traffic control is the hardest to simulate of the puzzle pieces here (from my line of thinking anyway), I have chosen to focus on it in submitting this idea. It would also be entirely possible to focus on a lesser section of the infrastructure such as the skycar software handling route requests and updates. Another possibility would be a graphical representation of the airspace being managed in real-time.

Go to www.moller.com to see the type of vehicle used in such a system.  

Greg  milford@uiuc.edu

This is rather vague, so here are some more details, as well as some short stories which describe various phases of the project:

Possible customers: Generally, any company or entity with a controlled airspace that needs to test new aircraft of all types with automated control. Vehicle companies, the military, small nations, etc.

Stories (in approximate order of priority, with ** next to those that should be completed in full within the duration of the school project, and * next to those that at least should be examined):

1.** Customer goal: directs vehicles through airspace correctly. Technical description: provide routes through three-dimentional space given randomized but reasonable loads, starting destinations, starting times, and exit destinations. Priority: highest, this is the heart of the project. This is the one thing that must be done.

2.* Customer goal: do goal one not only with correctness, but with certain degrees of quality. Technical description: These paths should be smoothly reachable for the vehicle, not too violent for the passengers, and as close to the optimal shortest path as appropriate, given the situation. Priority: nice to have, really makes goal number one more usable, but can be done gradually and to different degrees of quality depending on available resourses.

3.* Customer goal: do goal one when the vehicles ask for it, as compared to some other time. Technical description: make goal one as fast as possible, and take response latency into account when calculating the path. Priority: about the same as goal two. This will take a little research, and each vehicle request will also have to include its current vector.

4. Customer goal: make goal one physically realistic. Technical description: this includes such information as taking the inertia of the vehicle into account for changing paths, scaling together sections of airspace for longer paths, and more physical modeling. Priority: A little lower. I think that 2 will generally take care of this problem for as low a granularity as we'll need. It's hard to say, though.

5. Customer goal: make the vehicles autonomous. Technical description: Develop the vehicle control system such that it can generate the physical events necessary to conform to path. Priority: A little lower. This is really vehicle dependent. However, this is really a key chunk for utilizing the earlier work.

6. Customer goal: add take-off and landing within the airspace. Technical description: model some flat area with 3 types of terrain for landing/take-off 1. designated (where you plan), 2. emergency (where you can), 3. hostile (where you can't). Include landings/take-offs and their physical constraints in the path description. Priority: makes it more real, but only if we have time to spare.

7. Customer goal: have plans for safety in case something goes wrong. Technical description: create procedures for communcation failures, control system failures, vehicle failures, route planning failures. Include these failures, with appropriate failure rates, into the testing model. Priority: makes it real, but only if we have time to spare.

8. Customer goal: make it pretty. Technical description: add graphics. Priority: makes it sellable, but we assume we already have a client. We are after functionality. This is eye-candy.

9. Customer goal: implement this. Technical description: actually have a physical implementation. Priority: we don't have the resourses, nor the time. Not even considered.

John Benjamin Cassel