CSci

250 Fall 2014 team avionics development

Assumptions:
Youll be doing short development sprints. At the end of each sprint, each team
will produce a common pdf document and each team member will submit the teams
document through the Blackboard assignment. So, each team produces one pdf
document per sprint, and each member of that team turns in the same document.

You can develop the system to run as a stand alone Java app, or a mobile app, or a
web app.
I prefer that you use Eclipse, Java, and JUnit.
Your team must use revision control (git or subversion, your choice).
Your code must be hosted online so that all team members have access.
There are many free places to host your code. Google code is one of them:
http://code.google.com/hosting/createProject
Part of the development will be a testing environment to generate test cases.
Youll need to think about how you will know if the answer is right or wrong
(i.e., a test oracle). Could you exhaustively test the system?
The finale will be a 5 minute video demo of the system.

Application:
Pilots, whether in the air or on the sea, have multiple navigation aids. Some of them
work even during a power failure (compass, or handheld GPS). Since I havent flown
in a while, I talked to one of my colleagues who is an avid pilot. He said when he
flies he uses the compass, two GPS units built in to his plane (with a handheld GPS
for backup), and something called VOR.

VOR caught my attention when I took my ground school in preparation for the FAA
examination. In many ways it is incredibly simple: a radio station is built
specifically for navigation. This is how they look:
http://www.ultraflightradio.com/segmenthelpgraphics/VOR/VOR_Real_Life.gif

A VOR station has 360 radials (one for each degree of a circle), and also a three
letter Morse code identification. Airplanes have a corresponding VOR receiver to
receive the signals and compare the intercepted radial with the pilots intended
radial. This is what the pilot looks at:
http://www.langleyflyingschool.com/Images/Commercial%20Pilot%20Program/V
OR%20display.gif

If the pilot needs to turn left to get on the intended course, the cockpit instrument
will essentially say turn left, and vice versa. There are some things to watch out for,
since VORs dont know the airplanes heading (youll see what I mean). There are
even ways of using two different VORs to find a virtual intersection in the sky.

Sounds easy, but there are twists: if the plane is directly over the VOR station,
navigation doesnt work. Also, if the plane is abeam the station (90 degrees to
either side of the intended radial), navigation doesnt work.

There are many, many places on the web to learn about VORs. There are also good
simulators, like: http://www.luizmonteiro.com/Learning_VOR_Sim.aspx

Navigation aids like VORs are listed on the charts published by the government. If
you are curious, you can download charts here:
http://www.faa.gov/air_traffic/flight_info/aeronav/digital_products/vfr/
Ive also uploaded two charts, including the basic Hawaiian islands chart. You can
see there is a VOR on Lanai with identifier LLD (in More code .-.. .-.. -..)

Your task is to create software to implement a cockpit VOR instrument. Input will be
the OBS (desired setting), and information from a simulated radio. You will need
to implement a simulated radio to generate the intercepted radial (0-359), a station
identification (in Morse code), and an indication if the radio signal is GOOD or BAD
(i.e., the plane is over the station or too far away to receive a signal).

VOR instruments have a needle that swings left and right, or a bar that moves left
and right. Usually there are four dots to the left in addition to full-left, and
similarly for right. Each dot represents two degrees off the desired radial, with full-
left or full-right being ten or more degrees off. There is also a TO/FROM and
Good/Bad signal indicators.

Your program must calculate the deflection of the needle or bar, and the two
indicators (TO/FROM Good/Bad signal) based on the OBS input from the pilot, and
the intercepted radial (and other information from your simulated radio). The for
the needle deflection you need to calculate whether it is centered, or the number of
dots to the left or right. Assume that the plane is abeam the VOR station if the
intercepted radial is within one degree of 90 degrees from the intended radial.

You have three check-ins, plus a demo. Each document starts with the
following preamble:

Total LOC created to-date, broken into:
LOC for the simulated radio
LOC for the calculation
LOC for the user interface

Estimated LOC at completion, broken into:
LOC for the simulated radio
LOC for the calculation
LOC for the user interface

Total effort to-date (person-hours, 15 minute increment) broken into

Effort to-date for each team member

Additionally, for the first check-in you need to address:
Any questions about the requirements.
Where you are hosting your code, and the configuration management system
chosen by your team.
Your teams initial thoughts about how the entire system is designed.
Your teams initial thoughts about how the system will be tested.


For the second check-in, in addition to the preamble your document will address:
The number of versions checked-in to-date. Note that you do not need the
user interface completed to do the other parts of the system.
Any questions about the requirements.
An update on your teams design.
How your team is using JUnit, or other test technique, to do test driven
development (TDD)

For the third check-in, in addition to the preamble your document will address:
The number of versions checked-in to-date.
Progress implementing the user interface
Details about how you are using the simulated radio to test the calculations.
What is your test oracle?

The fourth check in (finale) will be a five-minute narrated demo of the completed
system. The video shall show the required functionality, as well as briefly discuss
why we should believe it works correctly. You can use jing or screencast-o-matic to
create the video demo (or QuickTime if you are using a Mac).