CIS 542 - Summer 2011
Group Project Description
In this project, you will work with up to two other students to develop a system with "embedded" and "mobile" components. The goal of the project is to create an Android application that is able to get data from and send control information to a remote temperature sensor.
Please note: This document will change over time as the requirements are refined and more details are provided to you. Please ask a member of the instruction staff if you have a question about anything described here.
The system shall consist of three major components, described as follows:
Note that because of firewall restrictions on the SEAS network, if you are running your middleware component on a Linux machine in the lab, you must use port 3001 for your server, and it can only be accessed by devices on the SEASnet network. Please be sure to discuss this with a member of the teaching staff if you are unsure.
- Temperature sensor: The sensor is to be a Gravitech 7-Segment Shield attached to an Arduino Duemilanove; both pieces of hardware will be provided to you. You may start with this Arduino program which reads the temperature and writes to the serial port once a second.
- Middleware: The sensor shall be connected via USB to a Linux or Mac machine, which will run a C program that handles all communication between the sensor and the user interface.
- User interface: The user interface will be an Android application running on an Android-enabled smartphone (one will be provided to your group if necessary), which communicates with the middleware over the Internet.
Your system must fulfill all of the following requirements:
- The user should be able to see the most recent temperature reading. If temperature readings are being reported by the sensor, the values should automatically update in the user interface.
- The user should be able to see the average, low, and high temperature reading for the past 24 hours.
- The user should be able to see the average, low, and high temperature reading for the past 7 days.
- The user should be able to see a graphical representation (i.e., temperature readings displayed as a function of time) for the past 24 hours.
- The user should be able to set a threshold, such that, if the temperature goes above the threshold, the user will be notified even if she is not using the application.
- The user should be able to decide whether to see temperature readings (and statistics) either in Fahrenheit or Celsius. Additionally, the user should be able to change the 7-segment display on the sensor to show the temperature either in Fahrenheit or Celsius.
- The user should be able to put the temperature sensor into a "stand-by" mode in which it is not reporting temperature readings. When the sensor is in "stand-by" mode, the user should also be able to tell it to resume reporting the readings.
- If the user interface cannot connect to the middleware, a helpful message should be shown to the user.
In addition to the functional requirements listed above, your group must come up with two other (non-trivial) features to include in your system. One feature must involve sending a control message from the user interface to the sensor; the other feature must involve the processing and/or display of the data that is sent from the sensor to the user interface. Please discuss your additional features with the instructor before proceeding.
In addition to satisfying all of the above requirements, your system should also meet these criteria:
You may assume that all components are "dedicated" to each other, e.g. that your middleware component will never need to serve a different user interface, and that your user interface will never need to connect to a different server.
- When displaying the most recent temperature reading, the data should be no more than five seconds old. If it is more than five seconds old, a message should be shown to the user (you can assume that the clocks on all devices are synchronized).
- The Arduino program must use no more than 32KB of memory, including space needed for the code (this is actually a physical restriction, not one we just made up!).
- The C program (middleware) must use no more than 256KB of heap space (okay, this restriction we kind of made up).
- If the Android device has less than 20% of its battery remaining and the user is viewing the most recent temperature reading, the reading should be updated once every 15 seconds.
- If the device has less than 10% of its battery remaining, the reading should be updated once every minute.
Because of the short schedule during the summer period, it is important that you make steady, continuous progress towards your final system. Each Thursday there will be a "milestone" that your group should meet, as described below.
Milestone #1: Progress Report (July 28)
During this evening's "lab session", your group will have a 10-minute meeting with the members of the instruction staff. You do not have to do a demo at this time (though you can, if you'd like), but you should by this point have most of the functionality completed, except of course for the Android user interface. That is, you should have an Arduino program that can communicate with your C program (the middleware), which in turn can communicate with a standalone Java application.
During this meeting, be prepared to discuss issues such as:
- where does data processing (e.g., calculating the average temperature) occur?
- what is the structure of your communication protocols between the different components?
- what code analysis have you performed so far?
- what sorts of error-handling have you included in your code?
Milestone #2: Front-End Prototype (Aug 4)
By this point, you should have completed a simple Android app that is able to use the Java code you've written for the previous milestone to get information from the middleware component. Your group will have a 10-minute meeting with the instruction staff in which you will demo the prototype your Android app (either running on the emulator or on the physical device). The prototype should, at the very least, allow the user to see the most recent temperature reading.
During this meeting, you will be asked about:
- changes you've made to your communications protocols
- code organization of your Android app (how you've designed classes, how you're using threads, etc.)
- front-end user interface design decisions
Milestone #3: Final Presentation (Aug 11)
On the last day of class, your group will present your application and discuss your implementation decisions.
Your demo and presentation should be a maximum of 10 minutes, with an additional 5 minutes at the end for questions and discussion. Please rehearse your demo/presentation and make sure you can complete it in 10 minutes! It is not necessary for every member of your group to speak during the demo.
The point of the demo is to show off your work, to impress the instructor, and to make your classmates feel bad because they're not as smart as you are. A boring nine-minute PowerPoint presentation followed by a one-minute demo of an application that only half works is a surefire way to fail to do any of those things. Try to keep the PowerPoint to 2-3 minutes, and then spend the rest of the time showing all the cool features of your application and discussing how it works. You should do a live demo using the Android emulator (since it's easier to project onto the screen) but also show the app running on the physical device so we know it really works.
After all the demos are completed, students will vote to decide which presentation they thought was best (no, you can't vote for yourselves). Whichever team has the best demo will receive extra credit points. And, obviously, the pride that comes along with being recognized by your peers.
All deliverables are due by Sunday, Aug 14, 11:59pm EDT. Late submissions will be penalized by 10% per day, and may result in a delay in posting your final grade.
Your final deliverables should consist of the following:
Submit all Arduino, C, and Java source code in three separate tar/zip files (as described below). If you use third-party libraries (which have been approved by the instructor!), only submit those in compiled form. Please be sure that all of your code is well-commented so it is easy for the grader to find where different features are implemented. Remember: happy graders give higher grades!
You must use the following tools to analyze your C program (the middleware):
To get meaningful results out of the analysis tools, run your system for at least one hour (yes, seriously) with each tool and exercise the middleware either by actually using your front-end app or -- to reduce insanity levels -- by writing a small Java program to simulate "normal" usage. Note that you may be able to combine the usage of some the analysis tools so that you don't spend five hours doing this.
- Helgrind: are there any issues with threading and synchronization?
- Memcheck: are there any problems with how memory is used?
- Massif: how much memory is the application using?
- gprof: what percentage of the time is the code spending in each function?
- gcov: how much of the code is executed?
In your analysis writeup, include all outputs of the different tools and analyze the results. If Helgrind or Memcheck reported an error, did you do anything to fix it? If not, how is the error mitigated/avoided? Does Massif reveal anything unexpected, for instance wasted (un-"useful") memory or potential memory leaks? Are the results from gprof as you expected, or can you improve performance by focusing on some of the more commonly run functions? Does gcov reveal any unexpected execution traces, e.g. error code that you did not realize was being called, or perhaps dead code that is not used? You can, of course, include "before and after" results of the tools if you use their output in order to improve your system.
This document should explain how your system "works". This should include:
- general system architecture (a diagram that will presumably be similar to the image at the top of this page)
- description of the functionality implemented by each component of your system
- communication protocols between components
- algorithms and data structures used to analyze and store data
- implementation decisions such as tradeoffs between different approaches, code organization, etc.
- error handling
- techniques you used to attempt to reduce power consumption, network bandwidth, memory, and CPU utilization in your Android application
This document explains how someone would use your Android application. Do not assume that it is "intuitive"!
Return all hardware
You must return the Arduino board(s), temperature sensor shield, USB cable, and Android device (if your group borrowed one) before you can receive a grade for this assignment.
You should be working with the other two members of your group project team, obviously. However, you may not discuss or share solutions with students in any other groups, nor should you be receiving any help from outside sources, including students not taking this course or online resources. If you find help online or use third-party code as part of your solution, you must cite it. Failure to do so will be considered academic dishonesty, and your team will receive a grade of 0 on this assignment (which pretty much means you'll all fail because this is worth 50% of your final grade!).
If you run into problems, please ask a member of the teaching staff for help before trying to find solutions online!
Your score will be out of 100 total points, broken down as follows:
Functionality (40 points)
Each of the ten functional requirements (the eight specified above, plus the two that your group came up with) is worth four points.
Non-functional Requirements (10 points)
Each of the five non-functional requirements (listed above) is worth two points.
Individual Responsibility (10 points)
In your final documentation, please specify which member of the team is responsible for (a) the back-end, (b) the middleware, and (c) the front-end. Please use these three categories -- do not make up your own! -- and only assign one team member per category (unless your group does not have three members, of course). Each part of the system will be assessed on its own and graded based on the quality of the code. Note that you may lose some points for a poorly-implemented solution (e.g. unnecessarily wasting memory, network bandwidth, battery power, etc.) even if the functionality appears to be correctly implemented from the user's point of view.
Presentation/Demo (10 points)
Your presentation should clearly describe: what new features you added; algorithms and data structures you used for processing and storing data; the structure of your communication protocols; the results of your analysis. The demo should show a fully-functional system running on actual hardware with all features implemented.
Analysis (15 points)
Each of the five analysis tools (listed above) is worth three points.
Documentation (15 points)
The technical documentation is worth 10 points; the user documentation is worth 5 points.
All deliverables will be submitted via Blackboard. You should submit a single zip/tar file that contains:
- all of your source code, which should be bundled into three separate zip/tar files: the Arduino code that runs on your device; the C code that runs on your middleware; and the Android application (you should submit the entire Eclipse project)
- all of your documentation and writeups, which should consist of three separate PDF files: the analysis; the technical documentation; and the user documentation; also submit the output files for each of the five analysis tools
- the PowerPoint (or whatever you use) for your in-class presentation
Updated: Mon, July 25, 12:22pm