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
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
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.
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.
Milestone #1: Proposal (Feb 10)
One member of your project group should send an email to the instructor indicating:
Milestone #2: Back-End Prototype (Mar
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.
Your final deliverables should consist of the following:
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!
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.
Return all hardware
If you run into problems, please ask a member of the teaching staff for help before trying to find solutions online!
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.
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.
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.
You should submit a single PDF that sufficiently addresses all of the topics described above.
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.
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