To create a fun or useful physical interface and the associated application software that deals with real-world sensors. You will use the Phidgets toolkit, which is described in this paper. The documentation, software and examples are located here. (Though for consistency, a common version will be stored here.)
Your system must react in "real time" (i.e., very fast) to the sensors, and must properly deal with noisy sensor data. If you do not include actuation that is tied to the sensing in real-time, your application program should have some graphical component that is tied to the sensors (beyond the status of the sensors themselves).
In either case, your program should have an interface that shows the state of the application, similar in spirit to the ActiveX controls included with the Phidget toolkit. Your visual interface can be limited to the set of sensors your hardware uses. You must also implement simulation mode, as is provided by the ActiveX controls (HINT: as with the ActiveX controls, you should implement this by creating a subclass of the interface kit and/or servo objects, so that they can be used by the rest of your program as if they were the COM objects. The phidget that corresponds to the simulation phidget should be changable at run time, and show be allowed to be "null", just like the ActiveX version). The state window should contain a simulation mode checkbox: when the box is checked, and the hardware is not connected to the computer, you should be able to simulate the state of the sensors and control the actuators using sliders or buttons. Your controls should have adequate functionality, but do not have to be as graphically interesting as the ActiveX controls included with the Phidgets package (e.g., the motor can be controlled by an appropriately labelled slider, you do not need to create a nice round image such as the one shown here).
You should do the program in Java. The TA will provide a set of Java classes that encapsulate the Phidget COM objects on Windows, and the COM objects will be installed on a set of the Windows machines in the teaching cluster.
Here are two simple examples of the kinds of phidgets that we consider reasonable. The defining characteristic is that the sensor data is non-trivial:
CS 4470 students are allowed to use one of these example, although we would prefer it if everyone came up with one on their own (if you are unsure of whether it is an acceptable project, send the professor or TA an email describing it: this is your responsibility!). CS 6456 student must come up with a different example.
Your files should consist of a README file which describes your device, how to set it up (which sensors to plug in where, etc.) and how to run things, as well as a set of java files that should be commented with your name (the name you are registered under!) and ID number. The java file should implement a class "A4". The files should be emailed to cs4470@cc.gatech.edu as mime attachments to a single message. You should turn in the hardware component to the TA in class on November 16th. Ensure your hardware is packed up in a way that ensures it will not be broken.
The time the mail is received will be used to determine whether or not the program is late, so be sure to allow a couple of minutes for the mail system to transmit your file if you are working right up to the deadline.
IMPORTANT: If the TA has to edit your files you will lose points. Similarly, the TA should be able to execute the class "A4", so using any other class as your main class will result in lost points.
This hardware is due on or before the beginning of class on Friday, November 16th. The software is due before the end of the day, which means it must be received by 11:59pm EDT to not be considered late. If you are turning the assignment in late, you must arrange with TA to get the hardware to him on the day it is due.
Your program should behave reasonably if the hardware is plugged in and unplugged while it is running. Furthermore, your program should provide an indication of the state of the hardware. If your program has a graphical component to it, you should have that in a separate window from the state information of the hardware.
When we say that the program must deal reasonably with sensor information, we are referring primarily to the fact that what would be a discrete event in the virtual world of the computer (e.g., something being pressed) will probably be a sequence of events over a short time interval from the sensor. You should make sure you interpret these event sequences reasonably.
For help you get started, the TA has programmed a sample
application. In case the Phidget COM package might change, we have
store a stable copy on this web site.
There is the following extra credit possibilities:
- Extend your phidget visualization to show the state of all possible sensors in the interface kit, and to have a nice graphical representation, like the ActiveX controls. It should also be structured as a nice, standalone Swing object, which has a method to set the current Phidget to monitor.
- Enhance the simulation mode by allowing sensor data to be recorded and played back. If you have multiple sensors, the data from all sensors should be recorded and played back together. You must ensure that the data is played back with the correct timing, so that the program behaves properly.
- Continue to enhance the simulation mode by allowing the recorded data to be saved to files on disk. You should then create an interface that allows a sequence of specified data files to be played back, and pauses of a user-specified length to be inserted between them.