CIS 542 - Spring 2012

Group Project Overview


In this project, you will work with up to three 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 a remote sensor, and to send control information to a remote display.

Project Options

All projects will consist of an Android application (the "mobile" component) that is connected over the Internet to a program running on some sort of microcontroller (the "embedded" component) that is attached to at least one sensor and at least one type of display.

Because all students have different backgrounds, levels of interest, experience, and goals, your group may choose from one of the following four options (listed in approximate order of difficulty):

1. Simple Arduino
This is the same project that was done in the Summer 2011 offering of this course; you can find a description of the expected functionality here. In that project, a program written in a Java-like programming language ran on an Arduino microcontroller to read data from a temperature sensor, and passed it via a serial connection to a C program (running on a desktop computer or laptop). The C program communicated over the Internet to the Android app. The Android app could then send messages back to the C program, which passed them via the serial connection on to the Arduino, which could then modify a 7-segment display (which is the type of display typically used on a digital clock) or a lightbulb. Serial communication and network communication (using socket programming) will be covered in class, so pretty much everything you need to know for the project will be taught to you at one point or another.

Instead of a temperature sensor or simple display, you may want to investigate some of the other Arduino peripherals -- they call them "shields" -- that are listed here.


2. Wireless Arduino
It is possible for two Arduino boards to communicate wirelessly using the Zigbee protocol. In this project, the Android app is connected to a C program over the Internet; the C program is connected to one Arduino using a serial connection; and that Arduino communicates wirelessly with another Arduino, which runs a program to control something like a small robot. Thus, the Android app acts as a remote control for the robot (or whatever else is being controlled by the remote/wireless Arduino).

This project includes all the same programming challenges as option #1, but also involves the wireless Arduino programming, as well as a little bit of electrical engineering, in terms of sending analog signals to the device that is being controlled by the remote Arduino; however, this should not be much of a problem for most students.


3. Freescale Tower
One of the challenges that students faced when implementing the Arduino project last summer is that the Arduino is not multi-threaded, so it was a bit complicated to write one program which would switch back and forth between getting sensor data and sending it to the C program, and at the same waiting for (asynchronous) incoming control messages. This could be avoided by using a more robust board like the Freescale Tower, which allows you to write C code, where each "program" that you write is really just a thread in a multithreaded app. Like the Arduino, there are some simple peripherals that you could use, and you would avoid the necessity of having a separate C program to communicate with the Android; the Freescale Tower programs could do that and also deal with the peripherals.

The tradeoff between Arduino and Freescale Tower is that if you go the Arduino route: (a) you need to write the Arduino program in their Java-like language; (b) you need to solve the issue of the Arduino program being single-threaded, but wanting to essentially do something multi-threaded; (c) you need to implement serial communication between the Arduino and a C program. If you go the Freescale Tower route: (a) all your code would be in C; (b) you don't have to solve the multi-threading problem, or have any serial communication; (c) but, the code to interact with the peripherals is a bit more complex and the programming environment is not quite as user-friendly. We would recommend using Arduino to groups who are not particularly strong in C, and recommend Tower to those who are.


4. BeagleBoard/PandaBoard
If you are a bit more adventurous, you may want to try a more powerful microcontroller board like the BeagleBoard or PandaBoard . These let you run full-blown operating systems like Linux, so that you could write "regular" C programs. These boards have USB, RS-232 (serial), and ethernet connections, as well as Bluetooth and HDMI output (seriously!), so you can certainly do quite a lot with them. These would be appropriate for groups who may have access to more powerful peripherals and I/O devices, e.g. you could presumably get something like a Microsoft Kinect, webcam, medical device, etc. to talk to one of these boards, and have the board talk to Android over the Internet. However, you would somewhat be on your own in terms of learning how to use those peripherals (and in procuring them), but if you're up for a challenge, and have contacts in the mLab or PRECISE lab or elsewhere, this may be a good choice for you.


Note that these four options are not necessarily set in stone: if you have an idea for a project that involves mobile and embedded components, please discuss these with the instruction staff and we will see what we can do to make it work.


It is important that you make steady, continuous progress towards your final system. Over the course of the semester there will be four "milestones" that your group should meet, as described below.


Milestone #1: Proposal (Feb 10)
One member of your project group should send an email to the instructor indicating:

Once your proposal has been approved, the instruction staff will work with you to get the necessary hardware.


Milestone #2: Back-End Prototype (Mar 15 22)
During today's lab session, your group will have a 10-minute meeting with 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 back-end ("embedded") functionality completed. That is, you should have a program running on your microcontroller board (Arduino, Tower, etc.) that can read from the sensor and write data to the display. Additionally, you should be able to demonstrate that it is possible for another application to communicate with your microcontroller over the Internet.

During this meeting, be prepared to discuss issues such as:


Milestone #3: Front-End Prototype (Apr 5)
By this point, you should have completed a simple Android app that is able to get information from the embedded component over the Internet. Your group will have a 10-minute meeting with members of the instruction staff in which you will demo the prototype of your Android app (either running on the emulator or on a physical device if you have one). The prototype should, at the very least, allow the Android user to see readings from the sensor.

During this meeting, you will be asked about:


Milestone #4: Final Presentation (Apr 26)
You should plan on doing your final demo during the course "project fair" on Thursday, April 26 from 4:30-6pm in Moore 204. At least one member of your group should be there to do a demo for your TA.


All deliverables are (tentatively) due by Friday, May 4, 12:00 noon 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:

Source code
Submit all source code, configuration files, etc. 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 code: 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.

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.


Technical documentation
This document should explain how your system "works". This should include:


User documentation
This document explains how someone would use your Android application. Do not assume that it is "intuitive"!


Return all hardware
You must return any equipment before you can receive a grade for this assignment.

Academic Honesty

You should be working with the other three members of your group project team, obviously. However, you should 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.

If you run into problems, please ask a member of the teaching staff for help before trying to find solutions online!


Grading for the project will be as follows:

Functionality (50%)
Each functional requirement that you have identified along with your TA is equally weighted. You may not change the functional requirements without the approval of your TA. Once you have submitted the project and done your final demo, the TA will determine the extent to which each functional requirement has been met; if the TA is not satisfied, then you have the option of continuing to improve your project and arranging subsequent demos up until the due date (May 4).

If there is a disagreement between you and the TAs as to whether a requirement has been satisfied, please notify the instructor.

Usability (5%)
You do not have to make your Android app particularly flashy or cool, but it should at least be sensible and usable for the average somewhat-intelligent human being. As with the functional requirements, the TA will determine what is satisfactory in terms of usability. Don't worry about this too much, though, you'll only lose points here if there are big problems.

Analysis (15%)
You are expected to perform the analysis described above, using all five tools (Helgrind, Memcheck, massif, gprof, and gcov). If you are somehow not using threads, you do not have to use Helgrind, of course.

If you do not have any C code in your system, or if the C code is running on a platform that does not support the analysis tools, please discuss this with the instructor.

Documentation (15%)
You should submit a single PDF that sufficiently addresses all of the topics described above.

Blog (5%)
Your documentation should include the URL of your project blog, in which you document your progress as you develop your system.

Peer Assessment (10%)
Each member of the group should (separately) submit a short writeup in which you rate yourself and the other group members in terms of their contribution to the project and the effort they put in.

To do this, you have 12 points that you can distribute amongst the members of your group, including yourself. For instance, let's say I'm working with Barry, George, and Bill. I feel that I did about the same as Barry, but George did practically nothing and Bill did quite a bit. So maybe I give myself and Barry 3 points each, 5 points to Bill, and just 1 point to George, for a total of 12.

The point total that you accumulate from yourself and your peers will be considered when determining how many points you get for this part of the grade.


Please create a single PDF containing the names of your group members, the documentation (technical doc and user guide), and the analysis. Then combine the Eclipse project containing all Android source code, configuration, data, etc. into a single tar and/or zip file. Also put all your server-side C code (if applicable) into a separate tar/zip file, and lastly include all your Arduino code into a third file. Submit the PDF and all three zip/tar files via Blackboard; only one member of your group needs to submit this.

Each member of the group should submit the peer assessment as described above. Do this in Blackboard either as a text file or in the comments section.

Updated: Mon, Apr 30, 10:49pm