Skip to content
Browse files

Merge branch 'master' of github.com:it2901g10/GROUP10-baf_sintef_arduino

  • Loading branch information...
2 parents 900718d + e54d631 commit d9ec567fc3ceeb0d6ec4905207d83ce99112c8ba @roffelsaurus roffelsaurus committed
Showing with 327 additions and 270 deletions.
  1. +14 −14 documentation/report/files/appendix/firstdraftarchi.tex
  2. +4 −4 documentation/report/files/appendix/meetingminutes/2001.tex
  3. +5 −5 documentation/report/files/appendix/meetingminutes/2301.tex
  4. +3 −2 documentation/report/files/appendix/weekreports/STATUSREPORTWEEK4.tex
  5. +2 −2 documentation/report/files/appendix/weekreports/STATUSREPORTWEEK5.tex
  6. +2 −2 documentation/report/files/appendix/weekreports/STATUSREPORTWEEK6.tex
  7. +1 −1 documentation/report/files/appendix/weekreports/STATUSREPORTWEEK7.tex
  8. +2 −2 documentation/report/files/appendix/weekreports/STATUSREPORTWEEK8.tex
  9. +2 −2 documentation/report/files/appendix/weekreports/STATUSREPORTWEEK9.tex
  10. +91 −77 documentation/report/files/architecture.tex
  11. +2 −0 documentation/report/files/bibliography.tex
  12. +30 −32 documentation/report/files/conclusion.tex
  13. +14 −14 documentation/report/files/intro.tex
  14. +9 −7 documentation/report/files/management.tex
  15. +9 −11 documentation/report/files/prestudies.tex
  16. +27 −28 documentation/report/files/requirements.tex
  17. +75 −56 documentation/report/files/sprints.tex
  18. +8 −8 documentation/report/files/systest.tex
  19. BIN documentation/report/img/app-fb.png
  20. BIN documentation/report/img/app-generic.png
  21. BIN documentation/report/img/app-jacket.png
  22. BIN documentation/report/img/app-led.png
  23. BIN documentation/report/img/app-temp.png
  24. BIN documentation/report/img/app-twitter.png
  25. BIN documentation/report/img/blingled-schematic.png
  26. BIN documentation/report/img/osnap-generic.png
  27. BIN documentation/report/img/sprints-gantt1.png
  28. BIN documentation/report/img/sprints-gantt2.png
  29. BIN documentation/report/img/sprints-gantt3.png
  30. BIN documentation/report/img/sprints-gantt4.png
  31. BIN documentation/report/img/sprints-gantt5.png
  32. BIN documentation/report/img/sprints-gantt6.png
  33. BIN documentation/report/img/sprints-gantt7.png
  34. BIN documentation/report/img/sprints-gantt8.png
  35. BIN documentation/report/img/sprints-gantt9.png
  36. +25 −1 documentation/report/report.tex
  37. +1 −1 documentation/report/title.tex
  38. +1 −1 documentation/report/winmake.bat
View
28 documentation/report/files/appendix/firstdraftarchi.tex
@@ -1,4 +1,4 @@
-The client asks for a java framework that works on either Android or desktop, to support the connection between a Arduino board and social services.
+The client asks for a Java framework that works on either Android or desktop, to support the connection between a Arduino board and social services.
If a programmer wants to use the framework to connect a social service to the Arduino board, he would like to work with data in either end and forward it.
@@ -15,16 +15,16 @@
This illustrates a split in the middle where the developer wants to treat the data himself. Since there is no direct connection between a social service and the Arduino board from our framework, it makes sense to split the framework into two parts.
\begin{itemize}
- \item\textbf{Framework part one:} Retrieving and uploading data between social service and java.
- \item\textbf{Framework part two:} Grab and push data between the Arduino board and java.
+ \item\textbf{Framework part one:} Retrieving and uploading data between social service and Java.
+ \item\textbf{Framework part two:} Grab and push data between the Arduino board and Java.
\end{itemize}
Both frameworks would need to support Android and development. This is an advantage for us who is going to create the framework, and for those who are going to use it.
The disadvantage is that it will be no direct connection from the Arduino board to a social service.
-I.e, the board can not connect directly through the Internet to Facebook. It needs a middleman, either a Android phone or a laptop.
+I.e, the board can not connect directly through the Internet to Facebook. It needs a middleman, either an Android phone or a laptop.
-After some tests, we have figured out that it makes no difference if the Arduino board is connected through a Bluetooth device or trough an USB cable. If it's an USB cable, the board shows up as a COM port. If the board is paired with the computer/mobile using the operating system/Android, it also shows up as a COM port. So the program searches the COM ports and connects to the board anyhow. (It's may not work on all bluetooth chipsets)
+After some tests, we have figured out that it makes no difference if the Arduino board is connected through a Bluetooth device or trough an USB cable. If it's an USB cable, the board shows up as a COM port. If the board is paired with the computer/mobile using the operating system/Android, it also shows up as a COM port. So the program searches the COM ports and connects to the board anyhow. (It may not work on all bluetooth chipsets)
The board needs a firmware that is precompiled on a computer.
@@ -41,7 +41,7 @@
\section{Example run framework part 1}
-How the developer connects to board on Android/PC after pairing the Arduino with system.
+How the developer connects to the board on Android/PC after pairing the Arduino with the system.
\javacode
\begin{lstlisting}
@@ -100,27 +100,27 @@ \section{Adding a listener to shield}
In ArduinoConnection we have listenForData(); method, that has its own thread listening on it.
Steps:
-listenForData() recives a ArduinoPacked data from Arduino board.
+listenForData() recives an ArduinoPacket data from the Arduino board.
Thread looks in board.shields to find the same board as packet.getName().
It dumps the package into the shield.newArrivalPackage(dataPackage);
-It is then up to the shield class to extract the data from package, and fire off an ArduinoEvent to the listeners.
+It is then up to the shield class to extract the data from this package, and fire off an ArduinoEvent to the listeners.
\section{Constant data stream solutions}
-Some shields, like the accelerometer is sensitive and will always send data to the program. On a mobile phone who constantly needs to work on these packages this will be straining on the battery.
+Some shields, like the accelerometer is sensitive, and will always send data to the program. On a mobile phone who constantly needs to work on these packages this will be straining on the battery.
-The constantStream threshold value is a signal to the ArduinoBoard to indicate how often in will update.
+The constantStream threshold value is a signal to the ArduinoBoard to indicate how often it will update.
Threshold = 0.0f; means all data will be streamed
-Threshold = 1.0f; means no data will be send from shield to the program. You can only retrieve data by specifically asking for it.
+Threshold = 1.0f; means no data will be sent from the shield to the program. You can only retrieve data by specifically asking for it.
-A mid value is dependent on the Shields connected, if the accelerometer has upper values in x,y,z directions from $<-1000, 1000>$, a threshold of $0.8f$ indicates we need extreme sudden change of $\Delta(0.8*2000)$ in one of the x,y,z axis to send a notification from the Arduino board.
+A mid value is dependent on the Shields connected to the Arduino, if the accelerometer has upper values in x,y,z directions from $<-1000, 1000>$, a threshold of $0.8f$ indicates we need an extreme sudden change of $\Delta(0.8*2000)$ in one of the x,y,z axis to send a notification from the Arduino board.
-Example, extremely sudden change (In one cycle?) from -700 to +800 in x direction.
+Example, an extremely sudden change (In one cycle?) from -700 to +800 in x direction.
It's not yet clear if we can implement this function into the firmware.
@@ -132,7 +132,7 @@ \section{Example run framework part 2}
//Facebook.com
SocialService service = new FacebookService(FacebookSevice.getAppAuth("appName"));
-//The initateLogin will call up a browser window and request user to log in
+//The initateLogin will call up a browser window and request the user to log in
//(automatically handle the calls depending if its called from Android or PC)
service.initateLogin();
View
8 documentation/report/files/appendix/meetingminutes/2001.tex
@@ -38,7 +38,7 @@ \subsection{To do to next meeting}
Emanuele:
\begin{itemize}
-\item Find available Facebook APIs, document on Open Social, Apache Shindig..
+\item Find available Facebook APIs, documents on Open Social, Apache Shindig..
\end{itemize}
Asbjorn:
@@ -48,14 +48,14 @@ \subsection{To do to next meeting}
Anders and Bjørnar:
\begin{itemize}
-\item Connect arduino to java
+\item Connect Arduino to Java
\end{itemize}
Johan:
\begin{itemize}
\item OpenSocial, Java $\rightarrow$ Arduino
-\item Send two mail
+\item Send two mails:
\item To SINTEF
\item To reception to book room Friday 4th floor at 14:15 every week
\end{itemize}
@@ -63,6 +63,6 @@ \subsection{To do to next meeting}
\subsection{Next meeting}
Monday 23/01 GreenHouse
-Discuss brainstorm/possiblities
+Discuss brainstorm/possibilities
Get a meeting room at Friday at 14, to meet with the client
View
10 documentation/report/files/appendix/meetingminutes/2301.tex
@@ -5,7 +5,7 @@ \subsection{Agenda}
We will probably use the Java Facebook API library restFB.
Shared some ideas. Discussed a little bit on the development process to use.
Will probably adopt Scrum as development process, given the iterative nature of our work schedule and of the meetings with customer.
-Realized a proof of concept consisting in a led turned on by Arduino if there is any unread notification on Facebook.
+Realized a proof of concept consisting of a LED turned on by the Arduino, if there is any unread notifications on Facebook.
{\bf Henrik: } \newline
\begin{itemize}
@@ -25,7 +25,7 @@ \subsection{Agenda}
Results
\begin{itemize}
-\item Git and mailinglist up
+\item Git and mailing-list up
\end{itemize}
{\bf Emanuele: } \newline
@@ -35,7 +35,7 @@ \subsection{Agenda}
Results
\begin{itemize}
-\item Read the Facebook developers pages (Facebook Graph API, Access tokens..)
+\item Read the Facebook developers pages (Facebook Graph API, access tokens..)
and Open Social documentation.
\item It turned out Facebook does not implement the Open Social standard. restFB, a simple, flexible, actively developed and permissively licensed (MIT) Java Facebook API was found and used to code a small program that checks for unread notifications.
\end{itemize}
@@ -54,7 +54,7 @@ \subsection{Agenda}
{\bf Anders and Bjørnar: } \newline
\begin{itemize}
-\item Connect Arduino to java
+\item Connect Arduino to Java
\end{itemize}
Results
@@ -79,7 +79,7 @@ \subsection{Agenda}
\subsection{Next meeting}
{\bf Henrik: } \newline
-Create idea presentations for Client.
+Create idea presentations.
{\bf Jonas and Johan: } \newline
Collaboration tools
View
5 documentation/report/files/appendix/weekreports/STATUSREPORTWEEK4.tex
@@ -1,11 +1,12 @@
First weeks status report where major directional decisions will be explained.
\subsection{Progress summary}
-The starting weeks work was mainly focused on identifying the specifics of our task and for every group member to start individual research into possibilities in Arduino, Facebook APIs, other social network APIs and then reporting it back to the group at our meetings. Together we tried to find good concepts for the Tangible User Interface(TUI) product that we was going to make. We had a meeting with the customer on the friday where we discussed our concepts. In this meeting the customer voiced wishes for the project to go in a more general direction than focusing on specific tangible end products. We was going to make a framework where creating products with an Arduino chip was lessened in complexity both for the developer and the end user.
+The starting weeks work was mainly focused on identifying the specifics of our task. Each group member started individual research into possibilities of Arduino, Facbook APIs and other social network APIs, findings were reported back to group at the meetings.
+Together we tried to come up with good concepts for the Tangible User Interface(TUI) product that we was going to make. We had a meeting with the customer on the friday where we discussed our concepts. In this meeting the customer voiced wishes for the project to go in a more general direction than focusing on specific tangible end products. We were going to make a framework where creating products with an Arduino chip was lessened in complexity both for the developer and the end user.
We also got Arduino products(Bluetooth module etc) from Simone Mora from IDI.
\subsection{Open / closed problems}
-The direction the project should pursue in regards to the TUI and platform choice became clear on the meeting with the customer.
+The direction the project should pursue in regards to the TUI and platform choice became clear in the meeting with the customer.
How well the Arduino chip could handle wireless connections(Bluetooth, WiFi or Zigby) is an open problem.
\subsection{Planned work for next period}
View
4 documentation/report/files/appendix/weekreports/STATUSREPORTWEEK5.tex
@@ -1,10 +1,10 @@
A report of a very productive week with some breakthroughs and setbacks.
\subsection{Progress summary}
-We started by working on the tasks set forth. We got the Bluetooth module(SHIELD) to work much faster than we planned for so we set the bar higher and started working on a general protocol to be used for communication between Arduino and computers regardless of technology (USB,BT,WiFi etc). We also had people work on getting a working Facebook application fetch data from Facebook (last post on Facebook wall). Getting a bluetooth connection between Android and Arduino was also a challenging task that we got working by the end of the week. Our results this week was presented to the customer on the friday as we had agreed on. Our progress relative to our plan is very good, we are actually ahead of schedule.
+We started by working on the tasks set forth. We got the Bluetooth module(SHIELD) to work much faster than we had planned for. Therefore we set the bar higher and started working on a general protocol to be used for communication between Arduino and computers regardless of technology (USB,BT,WiFi etc). We also had people working on getting a working Facebook application fetch data from Facebook (last post on Facebook wall). Getting a bluetooth connection between Android and Arduino was also a challenging task that we got working by the end of the week. Our results this week was presented to the customer on the friday as we had agreed on. Our progress relative to our plan is very good, we are actually ahead of schedule.
We also started working on the preliminary report that is due in WEEK 6. We chose to write this in LaTeX language as this is the most powerful way to customise the style of our report.
-In the meeting with the customer we had to revise our plan regarding to the Android framework. The way social networks/applications connect to our framework should be with intents(an Android standard) and the framework should be highly flexible in regards to which applications can work on it. This lead us to reject some of the code we had made for Facebook fetching, Android Bluetooth talking amongst other things.
+In the meeting with the customer we had to revise our plan regarding to the Android framework. The way social networks/applications connect to our framework should be with intents(an Android standard) and that the framework should be highly flexible in regards to which applications it can work on. This lead us to reject some of the code we had made for Facebook fetching, Android Bluetooth talking amongst other things.
We also established working process management tools in GitHub and ScrumDo (www.scrumdo.com).
View
4 documentation/report/files/appendix/weekreports/STATUSREPORTWEEK6.tex
@@ -1,11 +1,11 @@
\subsection{Progress summary}
-This week we needed to do a lot of replanning because of the changes from last week. We also did work relating to how to break down tasks to a scrum environment. Further work also needed to be done relating to the arduino protocol, bluetooth implementation for android. We also had people researching and developing the android social media integration part of the project and progress was done in this area.
+This week we needed to do a lot of re-planning because of the changes from last week. We also did work relating to how to break down tasks to a scrum environment. Further work also needed to be done relating to the Arduino protocol, and to the Bluetooth implementation for Android. We also had people researching and developing the Android social media integration part of the project and progress was done in this area.
\subsection{Open / closed problems}
Closed: The main goal and requirements of the project was defined and is documented in reports.
Open:
-Protocol, bluetooth, social media all need refinement to fit in the scope of the project as it stands.
+Protocol, Bluetooth, social media all need refinement to fit in the scope of the project as it stands.
\subsection{Planned work for next period}
View
2 documentation/report/files/appendix/weekreports/STATUSREPORTWEEK7.tex
@@ -1,5 +1,5 @@
\subsection{Progress summary}
-This week we had discussions on which process we should use. Xtreme Programming, spiral and others were considered but we concluded that a modified version of scrum like we previously decided on was feasible. This would also be the most reasonable choice to promote continuity with past work. Other than this we had a slow week with not much progress in regards to programming, rather we focused on process and planning work.
+This week we had discussions on which development process we should use. Xtreme Programming, spiral and others were considered but we concluded that a modified version of scrum like we previously decided on was feasible. This would also be the most reasonable choice to promote continuity with past work. Other than this we had a slow week with not much progress in regards to programming, rather we focused on process and planning work.
\subsection{Open / closed problems}
Closed: Final decision on using scrum as development/process system.
View
4 documentation/report/files/appendix/weekreports/STATUSREPORTWEEK8.tex
@@ -1,8 +1,8 @@
\subsection{Progress summary}
-Further refinement of the communication library. We had some initial planning of several prototypes that would supplement the main T-Shirt idea. One of them was a LED light Mood indicator fetched from Myspace. We also had more planning and research programming going into the social library, but much work remains to be done on this part.
+Further refinement of the communication library. We had some initial planning of several prototypes that would supplement the main T-Shirt idea (T-shirt was replaced by a jacket later in the project). One of them was a LED light Mood indicator fetched from Myspace. We also had more planning and research programming going into the social library, but much work remains to be done on this part.
Open:
-ComLib(bluetooth arduino-android comm)
+ComLib(Bluetooth Arduino-Android comm)
Social Library
Prototypes
View
4 documentation/report/files/appendix/weekreports/STATUSREPORTWEEK9.tex
@@ -1,7 +1,7 @@
\subsection{Progress summary}
-This week much planning and design discussions was had on the social library. Progress was done
+This week much planning and design discussions were made regards to the social library. Progress was done
and now the work of implementing some of this is to be undertaken. The communication library
-between arduino and android bluetooth is finished pending further development. The mid-term report is
+between Arduino and Android Bluetooth is finished pending further development. The mid-term report is
due next week, so we started working on that as well.
Open:
View
168 documentation/report/files/architecture.tex
@@ -7,8 +7,8 @@ \section{System overview}
The system consists of:
\begin{description}
\item[Libraries:] Social library, Communication library
- \item[Applications:] T-shirt application, other applications
- \item[(U.I.) Prototypes:] T-shirt prototype, other prototypes
+ \item[Applications:] Jacket application, other applications
+ \item[(U.I.) Prototypes:] Jacket prototype, other prototypes
\end{description}
The figure \ref{fig:design-toplevel} illustrates the overall system architecture.
@@ -24,15 +24,15 @@ \section{System design}
\label{sec:system-design}
As the requirements for the product were not set early on by the customer, a lot of effort
was put into producing working prototypes to show during the meetings in order to receive
-as much feedback as possible and identify the ideas the customer had in mind; these would provide
+as much feedback as possible and identify the ideas the customer had in mind. This would provide information on
what was needed to proceed with system design. At some point, after roughly one month,
we understood that we were going in the wrong direction, and that our design wouldn't satisfy
the requirements the customer had mentioned. The design of some parts of the system had to be revised.
\subsection{First design}
-Our first system design was based on the scenario where the user would download the T-shirt
+Our first system design was based on the scenario where the user would download the Jacket
and the social applications, browse for some content from within the social application
-and actively send it to the tangible user interface (the T-shirt) by pressing a 'share' button.
+and actively send it to the tangible user interface (the jacket) by pressing a 'share' button.
This scenario is illustrated in figure \ref{fig:design-usecase1}.
\begin{figure}[h!]
@@ -42,7 +42,7 @@ \subsection{First design}
\end{figure}
Please note that in this scenario the user is required to actively send data from
-the social application (which acts as a Facebook client) to the T-shirt application,
+the social application (which acts as a Facebook client) to the jacket application,
which is merely capable of receiving. Also, both are implemented as Android applications.
The figure \ref{fig:design-resp} illustrates the communication between the applications.
@@ -56,8 +56,8 @@ \subsection{First design}
\subsection{Second design}
It turned out that the user was not supposed to browse for social content and actively send it
-to the T-shirt application. Instead, after downloading the software, he would just setup a set of rules
-specifying the behavior of the T-shirt. This scenario is illustrated in figure \ref{fig:design-usecase2}
+to the jacket application. Instead, after downloading the software, he would just setup a set of rules
+specifying the behavior of the Jacket. This scenario is illustrated in figure \ref{fig:design-usecase2}
\begin{figure}[h!]
\centering \includegraphics[scale=0.35]{img/design-usecase2}
@@ -65,12 +65,12 @@ \subsection{Second design}
\label{fig:design-usecase2}
\end{figure}
-This new scenario made clear that the T-shirt and social applications had to be re-designed so:
+This new scenario made clear that the jacket and social applications had to be re-designed to support new requirements.
\begin{description}
- \item [T-shirt application:] A user interface, implemented as an Android application,
- that the user would to setup the rules for the T-shirt. The application needed also a
+ \item [Jacket application:] A user interface, implemented as an Android application,
+ that the user would configure to setup the rules for the jacket. The application also needed a
background component (such as an Android service or Thread) that would 'ask' the required information
to the social service.
@@ -91,12 +91,12 @@ \subsection{Second design}
\label{fig:design-reqresp}
\end{figure}
-The T-shirt service is now 'asking' the social service for a specific content.
+The Jakcet service is now 'asking' the social application for a specific content.
This happens in the background, without user interaction.
\subsubsection{Sequence diagram}
-This sequence diagram shown in figure \ref{fig:design-sequence} shows a sample communication between the social and T-shirt applications.
-The T-shirt application requests the list of friends from Facebook whose age is the same as 'Anna'.
+This sequence diagram shown in figure \ref{fig:design-sequence} shows a sample communication between a social app and the jacket application.
+The jacket application requests the list of friends from Facebook whose age is the same as 'Anna'.
\begin{figure}[h!]
\centering \includegraphics[width=1.0\textwidth]{img/design-sequence.png}
@@ -111,7 +111,7 @@ \subsection{The Social library}
The Social library is the link between the Android applications that control the
behavior of TUI prototypes and social networks. It provides abstractions for
many common concepts found in different social networks like Facebook, Twitter
-and OpenSocial allowing third-party developers to use these concepts seamlessly
+and OpenSocial. This allows third-party developers to use these models seamlessly
between different social networks and extend them to possibly support others.
It also defines and implements a set of classes to allow Android applications
and services to exchange such data models. This mechanism is based on Android's
@@ -120,7 +120,7 @@ \subsection{The Social library}
of the library.
\begin{figure}[h!]
- \centering \includegraphics[scale=0.8]{img/architecture-socialclasses.png}
+ \centering \includegraphics[scale=0.7]{img/architecture-socialclasses.png}
\caption{Social library core classes}
\label{fig:social-classes}
\end{figure}
@@ -136,10 +136,10 @@ \subsection{The Communication library}
This library consists of a Java library (implemented on Android) and an Arduino firmware (figure \ref{fig:comlib-diagram}),
both implementing the ComLib protocol. The Java library provides a set of classes that simplify the connection to Arduino
devices that run the Communication library Arduino firmware. The library also implements a mechanism to request a list of
-services the remote device supports and any software download links associated with the remote device. A service might
-be a sensor, a lamp, display screen while download links are represented as an URI link. All this meta information is stored
-on in the firmware on the remote device as raw text using the JSON format. This meta-data can also be stored an retrieved
-in a QR code or anything else that can store plain text.
+services (components) the remote device supports and any software download links associated with the remote device. A service might
+be a sensor, a lamp, display screen, etc, while download links are represented as an URL link. All this meta information is stored
+on in the firmware on the remote device as raw text using the JSON format. This meta-data can also be stored and retrieved
+in a QR code or other plain text formats.
\begin{figure}[h!]
\centering \includegraphics[scale=0.4]{img/comlib-diagram.png}
@@ -187,13 +187,13 @@ \subsubsection{Arduino firmware implementation}
The user of this library can register local methods to be called with RPC when the corresponding instruction is called.
The instructions follow strict rules on how they are constructed (see Table~\ref{tbl:instr_struct} for sizes of the different parts).
Each instruction has to start with a "start-byte" which is always 0xFF (255 decimal). The next part is the size, which tells the number of bytes to come for this instruction (including the size byte itself). The rest is defined from which instruction is sent, but it is important to
-remember that the content cannot be empty, and has to at least contain 1 byte. This byte however, is not necessarily read or used.
+remember that the content cannot be empty, and has to at least contain one byte. This byte however, is not necessarily read or used.
The following figure \ref{fig:arduino_states} illustrates the Arduino state machine:
-\begin{figure}[h!]
+\begin{figure}[H]
\centering
- \includegraphics[width=\textwidth, keepaspectratio]{img/arduino_state-machine.pdf}
+ \includegraphics[scale=0.5]{img/arduino_state-machine.pdf}
\caption{The Arduino state-machine}
\label{fig:arduino_states}
\end{figure}
@@ -217,7 +217,7 @@ \section{Applications}
\subsection{oSNAP Generic Application} \label{section:app-generic}
\begin{wrapfigure}{l}{20mm}
- \centering \includegraphics[scale=1]{img/app-generic}
+ \centering \includegraphics[scale=0.25]{img/app-generic}
\end{wrapfigure}
This application allows the user to scan a QR code and connect via Bluetooth to a remote device (Arduino).
It will then retrieve additional metadata from the remote device and use it to present a list of all the
@@ -225,21 +225,33 @@ \subsection{oSNAP Generic Application} \label{section:app-generic}
and also download the prototype specific application from a link to the oSNAP market.
The idea is that the user can use this application to scan various oSNAP products and retrieve
additional information or software for that specific product. This application was initially used to test
-the T.U.I. prototypes that was later converted to a 'real' application by client's request.
+the TUI prototypes that was later converted to a 'real' application by client's request. The startup screen
+is display in figure \ref{fig:osnap-generic}.
+
+\begin{figure}[h!]
+ \centering \includegraphics[scale=0.4]{img/osnap-generic}
+ \caption{Screenshot of the Generic oSNAP Application}
+ \label{fig:osnap-generic}
+\end{figure}
\subsection{oSNAP Jacket Application} \label{section:app-jacket}
\begin{wrapfigure}{l}{20mm}
- \centering \includegraphics[scale=1]{img/app-jacket}
+ \centering \includegraphics[scale=0.25]{img/app-jacket}
\end{wrapfigure}
This application was developed to use and test the full functionality of both the ComLib and Social library in combination with the
-Jacket Prototype. It connects to the Jacket via Bluetooth and uses any Social service installed and running on the
-Android system. It will retrieve any status updates from these services and can via rules set up by the user output something
-on the Jacket. One example could be a rule to play a sound effect through the Jacket speaker whenever something happens
-on a twitter feed.
+Jacket Prototype (shown in figure \ref{fig:jacketapp-overview}). It connects to the Jacket via Bluetooth and uses any Social network services installed and running on the
+Android system. It will retrieve any status updates from these services and can via rules relay the user output to the Jacket.
+One example could be a rule to play a sound effect through the Jacket speaker whenever something happens on a twitter feed.
+
+\begin{figure}[H]
+ \centering \includegraphics[scale=0.35]{img/jacketapp-overview}
+ \caption{Screenshot of the main screen in the oSNAP Jacket Application}
+ \label{fig:jacketapp-overview}
+\end{figure}
As discussed in chapter \ref{sec:system-design} the T-shirt application design had to be reviewed after roughly one month.
-\begin{figure}[h!]
+\begin{figure}[H]
\centering \includegraphics[scale=0.35]{img/design-tshirtappusecase2}
\caption{Use case for the T-shirt application}
\label{fig:design-tshirtappusecase2}
@@ -247,18 +259,18 @@ \subsection{oSNAP Jacket Application} \label{section:app-jacket}
For completeness we present the previous application use case in figure \ref{fig:design-tshirtappusecase1}
-\begin{figure}[h!]
+\begin{figure}[H]
\centering \includegraphics[scale=0.35]{img/design-tshirtappusecase1}
\caption{Initial use case for the T-shirt application}
\label{fig:design-tshirtappusecase1}
\end{figure}
-\subsection{Facebook application} \label{section:service-fb}
+\subsection{oSNAP Facebook application} \label{section:service-fb}
\begin{wrapfigure}{l}{20mm}
- \centering \includegraphics[scale=1]{img/app-fb}
+ \centering \includegraphics[scale=0.25]{img/app-fb}
\end{wrapfigure}
The Facebook application is an Android application that that replies
-T.U.I. prototype applications' requests by providing a Social library's 'Social service'
+TUI prototype applications' requests by providing a Social library's 'Social service'
Facebook-specific implementation.
As discussed in chapter \ref{sec:system-design} the Facebook application design had to be reviewed after roughly one month.
@@ -277,9 +289,9 @@ \subsection{Facebook application} \label{section:service-fb}
\label{fig:design-socialappusecase1}
\end{figure}
-\subsection{oSNAP Temperature Measure Application}
+\subsection{oSNAP Temperature Application}
\begin{wrapfigure}{l}{20mm}
- \centering \includegraphics[scale=1]{img/app-temp}
+ \centering \includegraphics[scale=0.25]{img/app-temp}
\end{wrapfigure}
This application allows the user to connect to an Arduino thermometer device wirelessly through Bluetooth (read more about the
temperature prototype in section \ref{section:prototype-temp}). This is done by scanning a QR code to retrieve the mac address
@@ -287,7 +299,7 @@ \subsection{oSNAP Temperature Measure Application}
upload temperature updates to Facebook through the ComLib. This application is a proof-of-concept that the libraries work independently
and are not hard-coded for one application. It also shows that the ComLib supports two-way communication.
In the planning stage of this prototype, a paper prototype (see figure~\ref{fig:prototype2-paper}) was showed to the
-customer. Due to some problems with getting the initial design to work properly, the GUI was revised (see
+customer. Due to some problems to get the initial design to work properly, the GUI was revised (see
figure~\ref{fig:prototype2-gui}) to make it more user friendly and visually appealing.
\begin{figure}[H]
@@ -304,11 +316,11 @@ \subsection{oSNAP Temperature Measure Application}
\label{fig:prototype2-gui}
\end{figure}
-\subsection{BlingLED Application}
+\subsection{oSNAP BlingLED Application}
\begin{wrapfigure}{l}{20mm}
- \centering \includegraphics[scale=1]{img/app-led}
+ \centering \includegraphics[scale=0.25]{img/app-led}
\end{wrapfigure}
-This application uses ComLib to connect ot the third prototype, the LED Matrix (see section \ref{section:prototype-led}). It allows the user to control the color of each LED in the matrix wirelessly through Bluetooth. This is yet another showcase for how the ComLib can be integrated into any application. Figure \ref{fig:design-ledmatrix} shows the Android application used to control the prototype.
+This application uses ComLib to connect to the third prototype, the LED Matrix (see section \ref{section:prototype-led}). It allows the user to control the color of each LED in the matrix wirelessly through Bluetooth. This is yet another showcase for how the ComLib can be integrated into any application. Figure \ref{fig:design-ledmatrix} shows the Android application used to control the prototype.
\begin{figure}[h!]
\begin{center}
@@ -318,20 +330,19 @@ \subsection{BlingLED Application}
\label{fig:design-ledmatrix}
\end{figure}
-\subsection{Twitter application}
+\subsection{oSNAP Twitter application}
\begin{wrapfigure}{l}{20mm}
- \centering \includegraphics[scale=1]{img/app-twitter}
+ \centering \includegraphics[scale=0.25]{img/app-twitter}
\end{wrapfigure}
Similar to the Facebook application (see section \ref{section:service-fb}),
except that it is a Twitter specific implementation that is able to read NTNU's public Twitter page.
\section{Prototypes}
\label{sec:prototypes}
-Three different prototypes will be produced for the project. Their purpose is to serve as proof of concept and
-to show that the libraries and can effectively simplify the prototyping of Arduino-based T.U.I.
+Three different prototypes will be produced for the project. Their purpose is to show that the libraries can effectively simplify the prototyping of Arduino-based TUI.
One of the prototypes, the oSNAP Jacket (formerly the T-Shirt), is significantly bigger and more complex than the other two.
The oSNAP Jacket is the main prototype of the project; the purpose of the other two
-is just to show that the libraries can be use for other applications and in different contexts.
+is just to show that the libraries can be use for other applications and in different contexts - to showcase the generic nature of our libraries.
\subsection{Prototype 1: The oSNAP Jacket}
This is our main prototype and will showcase a lot features.
@@ -359,7 +370,7 @@ \subsection{Prototype 1: The oSNAP Jacket}
\end{figure}
The application of this prototype will feature several displays and indicators which will receive social data through an Android phone.
-The shirt features different tangible interfaces (see figure \ref{fig:design-TShirt}):
+The jacket features different tangible interfaces (see figure \ref{fig:design-TShirt}):
\begin{itemize}
\item LEDs
@@ -376,17 +387,17 @@ \subsection{Prototype 1: The oSNAP Jacket}
\label{fig:design-TShirt}
\end{figure}
-Any of these can be mapped to a fair deal of concepts found in social network.
+Any of these can be mapped to a fair deal of concepts found in social networks.
So a "Poke" from Facebook could become a vibration on the Jacket. When someone "Likes" your post a small sound effect
could be played, a LED blinking on status updates from Twitter, etc. The Jacket is connected to the social networks
-through a wireless connection to an Android mobile. Specifically, the mobile Android is connected to the Internet
-and carried in the pocket of the person using the Jacket and is connected wirelessly with the Arduino Fio through Bluetooth.
+through wireless connection with an Android mobile. Specifically, the Android mobile is connected to the Internet
+and carried in the pocket of the person using the Jacket. The jacket is connected wirelessly with the Arduino Fio through Bluetooth.
\subsection{Prototype 2: Temperature Sensor for Android} \label{section:prototype-temp}
This prototype will primarily showcase the communication from Arduino to Android using our libraries.
Figure \ref{fig:design-temperature} shows a visual representation of the entire Temperature Sensor
-prototype with an Android device connected wirelessy through bluetooth to the Arduino board. The
+prototype with an Android device connected wirelessly through bluetooth to the Arduino board. The
Arduino unit can read the ambient temperature and be able to send this info to an Android application,
either on demand or at a set interval that can be chosen through settings in the application. Figure \ref{fig:design-temperature-schematic} describes how the hardware in this prototype is connected and which parts are required to build it.
@@ -405,16 +416,24 @@ \subsection{Prototype 2: Temperature Sensor for Android} \label{section:prototyp
\end{figure}
\subsection{Prototype 3: LED Matrix} \label{section:prototype-led}
-This prototype was first planned to be LED lights (Figure \ref{fig:design-ledmatrix}) showing what mood you had on MySpace.
-Red LED lights would be angry, green would be happy and so on. We discovered that MySpace had removed this feature from their pages, even if it was still supported by the API. It would be a fools errand to pursue something you could not test properly
+This prototype was first planned to be LED lights showing what mood you had on MySpace.
+Red LED lights would be angry, green would be happy and so on. We discovered that MySpace had removed this feature from their pages, even though it is still supported by the API. It would be a fools errand to pursue something you could not test properly
in a real world situation, so we changed the concept of this prototype. It ended up to be a prototype with LEDs governed by Android.
You select colors of the 3x3 LEDS in a graphical interface in an Android app. Then you send this information over Bluetooth
-to the Arduino who shows the selected colors on a necklace.
-The purpose of this prototype is to show how easy it is to implement the Communication Library in an Android application and most of the time can be spent on actual development of your own idea rather than understanding specifics of the library. The second purpose is to show the extensibility of using Shift Registers to control multitudes of components. This prototype is using four shift registers to control nine LEDs but it could theoretically be several thousand with more shift registers and chained Arduino boards. An external open-source library was used to control the shift registers. \cite{link:shiftpwm}
+to the Arduino which displays the selected colors on a necklace.
+The purpose of this prototype is to show how easy it is to implement the Communication Library in an Android application and how most of the time can be spent on actual development rather than understanding the specifics of the library. The second purpose is to show the extensibility of using Shift Registers to control a multitude of components. This prototype is using four shift registers to control nine LEDs but it could theoretically be several thousand with more shift registers and chained Arduino boards. An external open-source library was used to control the shift registers\cite{link:shiftpwm}. Figure \ref{fig:design-blingled-schematic} describes how the hardware in this prototype is connected and which parts are required to build it.
+
+\begin{figure}[h!]
+ \centering
+ \includegraphics[scale=1.0]{img/blingled-schematic}
+ \caption{Schematic for hardware setup in the BlingLED prototype}
+ \label{fig:design-blingled-schematic}
+\end{figure}
+
\section{Package Structure}
The source code of the whole system can be organized in smaller sections.
-Here we describes some of the packages we have divided the system code into.
+Here we describe some of the packages we have divided the system code into.
The system was coded in Arduino C and Java. Java was used to code Android libraries and applications.
Arduino C code is executed on the Arduino board. The Java code is again divided into packages.
Below is a brief description of the most important ones.
@@ -422,43 +441,38 @@ \section{Package Structure}
\subsection{Java code}
\begin{itemize}
\item \textbf{no.ntnu.osnap.com}\newline
- Communication Library contains every class to establish a connection with a remote device using a general
+ The Communication Library contains every class to establish connection with a remote device using a generalized
protocol interface. The actual details of the communication such as Bluetooth, cable, WiFi, stream-based or
sockets are hidden away from the user. This is to provide a simple and generic interface to all supported
communication methods. The user can easily add new communication types by extending an abstract class.
- The ComLib additionally defines a standard of storing and retrieving meta-data of services and download URI
+ The ComLib additionally defines a standard of storing and retrieving meta-data of services and download URL
links from the remote device using JSON.
\item \textbf{no.ntnu.osnap.com.testing}\newline
Test units and sample programs for the ComLib. These are simple test applications that are run on
- the Android to test if the ComLib is communication correctly using the specified
+ the Android to test if the ComLib is working correctly using the specified
protocol.
\item \textbf{no.ntnu.osnap.social}\newline
- Social library main classes.
+ Social library main classes. These can send requests for data from social networks. The listener package (see below)
+ handles the responses from these requests.
\item \textbf{no.ntnu.osnap.social.models}\newline
- Social library data models.
+ Social library data models. These are common models representing data from social networks such as message, person,
+ notification or group.
\item \textbf{no.ntnu.osnap.social.listeners}\newline
- Social library listeners.
- \item \textbf{no.ntnu.osnap.tshirt}\newline
- T-shirt application classes.
- \item \textbf{no.ntnu.osnap.temp}\newline
- Temperature application classes.
- \item \textbf{no.ntnu.osnap.led}\newline
- Led application classes.
- \item \textbf{no.ntnu.osnap.mockups} \newline \label{section:mockup}
- Stubs and 'driver' applications used for testing purposes.
- Example applications for third-party developers.
- \item \textbf{no.ntnu.osnap.app} \newline
+ Social library listeners. Includes listeners for any response on requests for social networks.
+ \item \textbf{no.ntnu.osnap.mockups}\newline\label{section:mockup}
+ Sample and 'driver' applications used for testing purposes.
+ Also includes example applications for third-party developers.
+ \item \textbf{no.ntnu.osnap.app}\newline
This package contains Android applications (called Activities in the Android terminology) for the three prototypes
- we have implemented. Activity resources (graphics, sounds and activity manifest) is also included in this package.
+ we have implemented. Activity resources (graphics, sounds and activity manifest) are also included in this package.
\end{itemize}
\subsection{Arduino C code}
-All the Arduino code is in one class, and there is therefore no package structure to speak of.
-The class consists of a header file and a source file. This is then to be included in Arduino projects
-that want to use our protocol for communication.
+All the Arduino code is in one class called \emph{ComputerSerial}, and there is therefore no package structure to speak of.
+The class consists of a header file and a source file. These two files can be included in any Arduino projects that want to use our protocol for communication.
\section{oSNAP Market}
-As we approached the final sprint, it became apparent that we needed a way to simplify the end user experience. See \ref{section:app-generic} for an example of real life usage. The oSNAP Market is a simple market made for the purpose of prototyping oSNAP compatible apps' distribution and interaction. It follows a simple MVC scheme, where each part can easily be changed.
+As we approached the final sprint, it became apparent that we needed a way to simplify the end user experience. The oSNAP Market is a simple market made for the purpose of prototyping oSNAP compatible apps' distribution and interaction. See \ref{section:app-generic} for an example of real life usage of the \emph{oSNAP Market}. It follows a simple MVC scheme, where each part can easily be changed.
The market does not currently rely on any server side scripting. For the purpose of internal testing, the market (see figure \ref{fig:market-screen}) is currently being hosted at \newline http://folk.ntnu.no/svarvaa/utils/pro2www.
View
2 documentation/report/files/bibliography.tex
@@ -8,6 +8,8 @@
\bibitem{link:facebook-dev} Facebook Developer Pages {\em http://developers.facebook.com/}
\bibitem{link:arduino} Official Arduino Website {\em http://www.arduino.cc/}
\bibitem{link:git} GIT Fast Version Control System {\em http://git-scm.com/}
+\bibitem{link:github} GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. {\em http://github.com/}
+\bibitem{link:github-osnap} oSNAP's GitHub repository. {\em https://github.com/it2901g10/GROUP10-baf\_sintef\_arduino/}
\bibitem{link:opensocial} OpenSocial 2.0.1 {\em http://opensocial-resources.googlecode.com/svn/spec/2.0.1/}
\bibitem{link:xp} Extreme Programming {\em http://www.extremeprogramming.org}
\bibitem{link:wiki} Wikipedia {\em http://www.wikipedia.org/}
View
62 documentation/report/files/conclusion.tex
@@ -1,54 +1,40 @@
-\section{Conclusion}
-The final scope of the project was much bigger than we originally planned or envisioned. This large scope
-was mainly caused because of all the different prototypes we had to implement. Originally we had planned
-to implement one prototype with accompanying application, but ended up creating two developer libraries
-along with 3 prototypes and 6 different Android applications in addition to a webpage for distribution of oSNAP
-compatible software. While challenging this was also a lot of fun. We had a lot of freedom in developing
-these products in the way we liked.
-
-The weekly meetings with the customer proved to be very valuable and
-a good way for the customer to keep track of progress. We showed the fruits of the work from the earlier
-week to the customer and he could steer us in the direction he desired and comment on the results.
-
-
\section{Mistakes and new Experiences}
A big part of projects like this is reflecting back and see which mistakes were made throughout
the project lifetime. We can then learn why these mistakes happened and develop strategies to
prevent them from happening in future projects. This section describes the various pitfalls and
-mistakes that were made throughout the project and what we learned from these.
+mistakes that were made throughout the project and what we have learned from these.
\subsection{Establishing project requirements}
A lot of time was lost by prematurely starting the design and planning phase before the
requirements were properly understood and established. This was also caused by the shifting
requirements that the customer had every meeting. We should have properly established a list of
requirements and agreed with the customer that these were the final requirements. In addition we
-should have not started major planning, setting up resource management before the requirements
+should have not started major planning, like setting up resource management before the requirements
were properly set after a few meetings with the customer.
\subsection{Hardware problems}
There were various issues with the hardware for our prototypes. A big one was the large delay
-from when we initially ordered the hardware and until we received them. The two months it took
-for the hardware to arrive meant that in that period we could not do any integration and testing.
+from when we initially ordered the hardware and until we received them. It took just over two months for
+some of the necessary hardware to arrive, resulting in a delay in our integration and testing process.
This was a major setback to our plans and this time was mostly spent writing documentation, planning
-and testing the libraries for bugs. In addition the hardware we received was either wrong or not
-optimal for our specifications. This was caused by miscommunication within the project group. In
-addition we had not ordered backup or spare parts, so when for example the LCD screen broke,
-we had to find other workarounds to solve this issue. In hindsight we should have made sure that
-the list of hardware orders was correct and ordered additional spare parts in case something broke
-or malfunctioned.
+and testing the libraries for bugs. Due to miscommunication within the project group some of the
+hardware we received was either wrong or not quite optimal for our specifications. In addition we had
+not ordered backup or spare parts, so when for example the LCD screen broke, we had to find other
+workarounds to solve this issue. In hindsight we should have made sure that the list of hardware orders
+were correct and ordered additional spare parts in case something broke or malfunctioned.
\subsection{Group meetings}
-A chronic problem inside the group was late attendance to meetings. For various reasons members of
-the group would meet hours later than the agreed or planned time. This was somewhat mitigated to having
+A chronic problem inside the group was late attendance to internal team meetings. For various reasons members of
+the group would meet hours later than the agreed or planned time. This was somewhat mitigated by having
the meetings later in the day and working into the late hours of the night.
\subsection{Limiting project scope}
-Another problem caused by an early design choice was the level of portability. Initially we coded our libraries to support as wide range of platforms as possible (PC, Android, iOS, etc.). This caused various generalizations and concepts that worked not very well with Android. One prevalent example was callbacks and threads inside the Android system. While our library was based on multi-threading and callbacks through an observer pattern, this does not work on Android Java the same way one would expect on a PC. Since every prototype and testing software we coded was based on the Android platform this caused major problems and we had to spend a lot of time rewriting and redesigning libraries. So our choice of portability caused many problems considering the customer explicitly stated that we only needed to support Android. While portability is usually a good thing, the product quality should not suffer if it is not a high priority requirement.
+A problem caused by an early design choice was the level of portability. Initially we coded our libraries to support as a wide range of platforms as possible (PC, Android, iOS, etc.). This caused various generalizations and concepts that didn't work to well with the Android platform. One prevalent example was callbacks and threads inside the Android system. While our library was based on multi-threading and callbacks through an observer pattern, this does not work on Android Java the same way one would expect on a PC. Since every prototype and testing software we coded was based on the Android platform this caused major problems and we had to spend a lot of time rewriting and redesigning libraries. So our choice of portability caused many problems considering the customer explicitly stated that we only needed to support Android. While portability is usually a good thing, the product quality should not suffer if it is not a high priority requirement.
\section{Further Work}
This section describes ideas, code and features we did not have time or resources to
finish at the project deadline. The section can also describe various interesting concepts
-that we visualized that we might have explored given more time.
+that we visualized, which we could have explored given more time.
\subsection{Supporting more communication technologies in ComLib}
Currently the ComLib only supports Bluetooth connections. Further work would be
@@ -60,20 +46,32 @@ \subsection{Supporting more communication technologies in ComLib}
\subsection{Supporting additional Social networks}
The SocialLib currently supports Twitter and Facebook. Support for additional social
-networks like Google Plus, LinkedIn or MySpace was planned as future work. Also the
-SocialLib has been implemented to accommodate this process as simple as possible
+networks like Google Plus, LinkedIn or MySpace was planned as future work. The
+SocialLib has also been implemented to accommodate this process as simple as possible
for the developer.
\subsection{Multi-Platform}
-The Bluetooth part of the ComLib has been implemented using Android SDK. This means
+The Bluetooth part of the ComLib has been implemented using Android SDK. This means that
the Bluetooth part of the library will only run on an Android platform. The ComLib protocol
itself however, has been designed to support any type of platform. This means the ComLib
could be expanded to support other types of platform such as Bluetooth on iOS. This
-should preferably be implemented as a common interface, so the developer only has to use
-Bluetooth and the ComLib itself figures out if to use the Android version or the iOS version of
+should preferably be implemented as a common interface, so that the developer only has to use
+Bluetooth, and the ComLib itself figures out if it is to use the Android version or the iOS version of
the Bluetooth Protocol.
\subsection{Security}
Currently the ComLib offers no level of security. Anyone with the mac address can connect
and have access to the full functionality of each prototype device. A future possibility could
be to define a security standard in the ComLib protocol like authentication with a password.
+
+\section{Conclusion}
+The final scope of the project was much bigger than we originally planned and envisioned. This large scope
+was mainly caused because of all the different prototypes we had to implement. Originally we had planned
+to implement one prototype with accompanying application, but ended up creating two developer libraries
+along with 3 prototypes and 6 different Android applications in addition to a webpage for distribution of oSNAP
+compatible software. While challenging this was also a lot of fun, since we had a lot of freedom in developing
+these products in the way we liked.
+
+The weekly meetings with the customer proved to be very valuable and
+a good way for the customer to keep track of progress. We showed the fruits of our work from the earlier
+week to the customer, and he could steer us in the direction he desired and comment on the results.
View
28 documentation/report/files/intro.tex
@@ -20,13 +20,13 @@ \section{Problem description}
\section{The context}
In the past few years, social networks have become more and more popular, continuously increasing their user-base.
The project task was to design and develop an open source Android\cite{link:android} framework for allowing quick
-and flexible development of wireless Tangible User Interfaces (T.U.I.) for social networks using Arduino.
+and flexible development of wireless Tangible User Interfaces (TUI) for social networks using Arduino.
The product has served both as a proof-of-concept and as a starting point for future software projects.
\section{The customer}
Our customer was SINTEF, represented by Mr. Babak A. Farshchian.
-SINTEF is the largest independent research organization in Scandinavia \cite{link:sintef}.
+SINTEF is the largest independent research organization in Scandinavia\cite{link:sintef}.
It is an independent, non-commercial organization with their head office in Trondheim.
They have approximately 2100 employees, mainly in Trondheim and Oslo.
@@ -47,7 +47,7 @@ \subsection{Team members}
\item{\johan}\newline
Third year student at NTNU. Experience with the programming languages Java, C, C++ and
-Basic. Worked with AVR microcontrollers in other projects and courses.
+Basic. Worked with AVR micro-controllers in other projects and courses.
\item{\asbjorn}\newline
Second year student on bachelor in computer science at NTNU. Has previously had one year of
@@ -59,12 +59,12 @@ \subsection{Team members}
Experience with Java, C and C++ programming, basic electronic notions.
\item{\jonas}\newline
-Third year student at NTNU. Experience with Java, Python, Lua, PHP, and web standards such as HTML,
-CSS and JavaScript. Previously worked with media and sound engineering.
+Third year student at NTNU. Experience with Java, Python, Lua, PHP, and web standards such as HTML,
+CSS and Javascript. Previously worked with media production and sound engineering.
\item{\bjornar}\newline
Third year Informatics student at NTNU. Experience with programming in Java, C and C++.
-Previously worked with electronics and have basic knowledge about AVR microcontrollers through
+Previously worked with electronics and have basic knowledge about AVR micro-controllers through
own projects.
\end{itemize}
@@ -75,19 +75,21 @@ \section{Definitions}
\begin{description}
\item[Android:]
- An operating system based on Linux primarily for mobile devices made by Google.
+ An operating system based on Linux primarily for mobile devices. It features a software stack, and applications are written in the Java language. Android is made by Google and the Open Handset Alliance.
\item[Android-Arduino applications:]
With this term we refer to Android applications used to control the behavior of Arduino-based tangible user interfaces.
\item[Apache:]
A software foundation focused on open source and community driven software.
\item[Arduino:]
Arduino is a tool for making computers that can sense and control more of the physical world than your
- desktop computer. It's an open-source physical computing platform based on a simple microcontroller board, and a development
+ desktop computer. It's an open-source physical computing platform based on a simple micro-controller board, and a development
environment for writing software for the board.
\item[Facebook:]
Facebook is the biggest social network. It is also the network our libraries primarily focus on.
-\item[IPC]:
- See RMI.
+\item[IPC:]
+ Remote Method Invocation in Java (RMI) or Remote Procedure Call in C (RPC) are two implementations of inter-process communication (IPC).
+ This allows two different computer programs (possibly on two entierly different systems or platforms) to execute code in their respective
+ address space.
\item[JSON:]
Acronym for Javascript object notation. It is a lightweight data interchange format,
used in most social networks.
@@ -106,11 +108,9 @@ \section{Definitions}
\item[REST:]
A software architecture for distributed systems. Software that complies with REST constrains is called RESTful.
\item[RPC:]
- See RMI.
+ See IPC.
\item[RMI:]
- Remote Method Invocation in Java (RMI) or Remote Procedure Call in C (RPC) are two implementations of inter-process communication.
- This allows two different computer programs (possibly on two entierly different systems or platforms) to execute code in their respective
- address space.
+ See IPC.
\item[Shield:]
An Arduino chip (or module) one puts on top of the main board to extends the arduino's feature set.
\item[Shindig:]
View
16 documentation/report/files/management.tex
@@ -1,5 +1,5 @@
\section{The choice of development process}
-The choice of a development process is crucial for every project~\cite{book:software-engineering}
+The choice of a development process is crucial for every project\cite{book:software-engineering}
and many factors such as project size and scope, team members skills and time resources have to
be taken into consideration in order to make a good choice. The choice of the development process
will affect planning and many other aspects of the teamwork. The following section describes
@@ -17,7 +17,7 @@ \subsection{Waterfall}
is vital before implementation is started.
\begin{figure}[h!]
\centering \includegraphics[scale=0.30]{img/designmodel-waterwall}
-\caption{The Waterfall model~\cite{link:wiki-waterfall}}
+\caption{The Waterfall model\cite{link:wiki-waterfall}}
\label{fig:designmodel-waterfall}
\end{figure}
@@ -31,7 +31,7 @@ \subsection{Scrum}
frequent meetings it promotes verbal communication in the group.
\begin{figure}[h!]
\centering \includegraphics[scale=0.4]{img/designmodel-scrum}
-\caption{The Scrum process~\cite{link:wiki-scrum}}
+\caption{The Scrum process\cite{link:wiki-scrum}}
\label{fig:designmodel-scrum}
\end{figure}
@@ -47,7 +47,7 @@ \subsection{Extreme Programming (XP)}
where the customer is not entirely sure what he or she wants.
\begin{figure}[h!]
\centering \includegraphics[scale=0.75]{img/designmodel-xp}
-\caption{Extreme Programming~\cite{link:xp}\cite{link:wiki-xp}}
+\caption{Extreme Programming\cite{link:xp}\cite{link:wiki-xp}}
\label{fig:designmodel-xp}
\end{figure}
@@ -83,7 +83,7 @@ \subsection{Conclusions}
of the prototype each time. Moreover everyone in the team had some experience with Scrum from previous projects.
After a few weeks of development however, we began to wonder if the Scrum model did not fit perfectly to our project.
-This was due to the fact that especially on the 'social' part this project was much like a software research project
+This was due to the fact that especially on the "social" part this project was much like a software research project
so the specifications and the requirements for the product were not clearly set early on, but instead unfolded little
by little during our meetings with the customer thanks to his feedback on our prototypes and documentation.
This led to some of the code and documentation that we had produced to be scrapped during later iterations,
@@ -129,7 +129,7 @@ \section{Project roles}
Every week friday at 14:15 we would meet with the customer. After a progress update we would show the results
of the work we had done earlier that week. The customer would then give us guidelines and requests for what
he would like to have finished for the next sprint. The duration of the meetings with the customer varied anything
- from 15 minutes to two hours, depending on the amount of topics that need to be discussed.
+ from 15 minutes to two hours, depending on the amount of topics that needed to be discussed.
\end{itemize}
\section{Project management tools}
@@ -143,7 +143,7 @@ \section{Project management tools}
and eventually to "Done" areas.
\begin{figure}[h!]
-\centering \includegraphics{img/mgmt-scrumdo} \caption{A screen capture of the Scrum Board in ScrumDo \cite{link:scrumdo}}
+\centering \includegraphics{img/mgmt-scrumdo} \caption{A screen capture of the Scrum Board in ScrumDo\cite{link:scrumdo}}
\label{fig:mgmt-scrumdo}
\end{figure}
@@ -162,6 +162,8 @@ \subsection{Software and hardware development tools}
several team members had experience with GIT through other projects which was a significant factor for
this choice.
+ We chose to use the widely used GitHub\cite{link:github}\cite{link:github-osnap} for our VCS needs. Since we're developing libraries for third parties to make use of, it's easier for other developers to make use of oSNAP through forking on GitHub. This is also where our developer's documentation resides.
+
We used Skype\cite{link:skype} for instant message communication.
\item \textbf{Libraries and external software:} \newline
View
20 documentation/report/files/prestudies.tex
@@ -6,14 +6,14 @@
\section{Existing solutions}
We did some research on the Internet about similar and related products. It is important to underline that our task was
-not just to create another prototype, but instead a set of libraries that would ease future development of new protoypes
+not just to create another prototype, but a set of libraries that would ease future development of new protoypes
connecting Arduino to social networks. These existing products were relevant in order to confirm that tangible user interfaces
for social networks using Arduino were a reality. They also provided some ideas to take into consideration.
\newpage
\subsection{LikeLight}
-This product found on the internet is a Facebook like indicator that glows when some content the
+This product found on the internet\cite{link:likelight} is a Facebook like indicator that glows when some content the
user posted on Facebook is liked by someone. It was realized with an Arduino board inside a giant Lego hand.
(Figure \ref{fig:prestudies-likehand})
@@ -28,9 +28,8 @@ \subsection{LikeLight}
\section{Our own ideas}
\subsection{YepMailbox}
-The YepMailbox (Figure \ref{fig:prestudies-YepMailbox}) was another concept of a tangible Arduino-powered prototype
-that would interact with the user Facebook wall. The mail flag would rise powered by a small servo motor and a printer
-would print out the new message.
+The YepMailbox (Figure \ref{fig:prestudies-YepMailbox}) was another concept that we thought of. A tangible Arduino-powered prototype
+that would interact with the user Facebook wall. When a new message arrives, a flag powered by a small servo would rise, and the message print out.
\begin{figure}[h!]
\centering \includegraphics[scale=0.4]{img/prestudies-YepMailbox}
@@ -41,9 +40,9 @@ \subsection{YepMailbox}
\newpage
\subsection{Facebook Wall}
-The "Facebook Wall" (Figure \ref{fig:prestudies-facebookwall}) is a wall with two holes in it for people to put their faces in.
-The prototype would then make a picture and replace the wall with some image and add bodies to the two faces. The image
-would then be automatically uploaded and posted on Facebook.
+The "Facebook Wall" (Figure \ref{fig:prestudies-facebookwall}) is another concept we came up with. It is a wall with two holes in it for people to put their faces in.
+The prototype would then take a picture and replace the wall with some a image and add bodies and background scene to the two faces. After user confirmation, the image
+would then be uploaded and posted on their Facebook.
\begin{figure}[h!]
\centering \includegraphics[scale=0.22]{img/prestudies-facebookwall}
@@ -55,7 +54,7 @@ \subsection{Facebook Wall}
\subsection{T-Shirt}
The T-Shirt (Figure \ref{fig:prestudies-tshirt}) features electronic circuits powered by an Arduino Lilypad board.
-The Lilypad is an Arduino board designed especially to be wore. It is connected wirelessly to the Internet through
+The Lilypad is an micro chip designed specifically to be worn. It is connected wirelessly to the Internet through
an Android phone, and downloads status updates from a social network such as Facebook.
The content fetched is then displayed through one of the electronic devices: LEDs, LCD screen,
sound module or a vibration module.
@@ -73,8 +72,7 @@ \section{Conclusion}
We presented our various ideas and concepts to the customer and let him decide on what he would
like the group to work on. The client liked the t-shirt idea, and he decided that it would be the main prototype for this project.
After some iterations the t-shirt got swapped out with a jacket due to practical reasons for implementing the hardware.
-The prototypes work as proof-of-concept that our developer libraries function as they should and work as the same time as an
-example on how the libraries can be used. In our example we show how you can connect social networks (Twitter, Facebook, etc.) to
+The prototypes work as proof-of-concept that our developer libraries function as they should, and also provides examples for third party developers of how the libraries can be used. In our example we show you how you can connect social networks (Twitter, Facebook, etc.) to
tangible Arduino interfaces (LED, buzzer, sound, buttons, etc.). The customer requested one or two additional smaller prototypes in
addition to the oSNAP Jacket to prove that our libraries can be successfully used to develop different prototypes. Each of the prototypes are
described in more detail in section \ref{sec:prototypes}.
View
55 documentation/report/files/requirements.tex
@@ -10,17 +10,17 @@ \section{Functional requirements}
\hline
\bf{Requirement} & \bf{Priority} \\
\hline
- F1: SocialLib & Very High \\
- F2: ComLib & Very High \\
- F7: T-Shirt Prototype & High \\
- F3: oSNAP application & Medium \\
- F4: T-Shirt application & Medium \\
- F5: Facebook application & Medium \\
- F6: Twitter application & Medium \\
- F8: Temperature application & Low \\
- F9: Temperature Prototype & Low \\
- F10: LED matrix application & Low \\
- F11: LED matrix Prototype & Low \\
+ F1: SocialLib & Very High \\
+ F2: ComLib & Very High \\
+ F7: Jacket Prototype & High \\
+ F3: oSNAP Generic Application & Medium \\
+ F4: oSNAP Jacket Applications & Medium \\
+ F5: oSNAP Facebook Application & Medium \\
+ F6: oSNAP Twitter Application & Medium \\
+ F8: oSNAP Temperature Application & Low \\
+ F9: Temperature Prototype & Low \\
+ F10: oSNAP LED matrix Application & Low \\
+ F11: LED matrix Prototype & Low \\
\hline
\end{tabular}
\end{table}
@@ -48,27 +48,27 @@ \subsection{F2: Communication library}
\newpage
-\subsection{F3: oSNAP application}
+\subsection{F3: oSNAP Generic Application}
\begin{description}
\item[Libraries:] The application shall use the Communication library
to communicate with TUI prototypes.
\end{description}
-\subsection{F4: T-Shirt application}
+\subsection{F4: oSNAP Jacket Application}
\begin{description}
\item[On and Off:] The user shall be able to turn the application On
and Off. When the application is not running, no social data will be
- forwarded to the T-Shirt prototype.
+ forwarded to the Jacket prototype F7.
\item[Libraries:] The application shall use the Communication library to
- communicate with the T-Shirt prototype and the Social library to
+ communicate with the Jacket prototype and the Social library to
receive and send data from/to social services.
\item[Rules:] The application shall let the user setup a set of rules
- to control the behavior of the T-Shirt. Rules can be created and deleted.
+ to control the behavior of the Jacket. Rules can be created and deleted.
\item[User interaction:] The application shall continue to work
when the mobile itself is idle.
\end{description}
-\subsection{F5: Facebook application}
+\subsection{F5: oSNAP Facebook Application}
\begin{description}
\item[Login (Authentication):] The application shall handle the
authentication with Facebook.
@@ -82,19 +82,19 @@ \subsection{F5: Facebook application}
should be required.
\end{description}
-\subsection{F6: Twitter application}
+\subsection{F6: oSNAP Twitter Application}
\begin{description}
\item[Libraries:] The application shall use the Social library to
communicate with TUI prototype applications.
\end{description}
-\subsection{F7: T-Shirt prototype}
+\subsection{F7: Jacket prototype}
\begin{description}
- \item[Features:] The prototype shall map some social content to various
+ \item[Features:] The prototype shall map data from jacket app F4 to various
embedded electronic devices.
\item[Libraries:] The prototype shall use both the Social and Communication
libraries.
- \item[User input:] Once the rules for the T-Shirt are set, no further user
+ \item[User input:] Once the data for the Jacket are set, no further user
input shall be required.
\end{description}
@@ -114,19 +114,18 @@ \subsection{F9: LED matrix prototype}
\item[Libraries:] The prototype shall use the Communication library.
\end{description}
-\subsection{F10: Temperature application}
+\subsection{F10: oSNAP Temperature Application}
\begin{description}
\item[Mac address:] The user should be able to scan the mac address from a QR code, and/or enter it manually.
\item[Share temperature:] The user should have full control over when and to which social media the temperature data is shared.
- \item[Time interval:] The user should be able to set automated updating of the temperature.
- \item[Dependecies:] Facebook service application.
+ \item[Time interval:] The user should be able to set automated updating of the temperature from prototype F8.
\item[Libraries:] The application shall use the Social and Communication libraries.
\end{description}
-\subsection{F11: BlingLED application}
+\subsection{F11: oSNAP BlingLED Application}
\begin{description}
- \item[Connection:] You must be able to establish a wireless connection from the Android to the prototype (F9) through Bluetooth.
- \item[Lights:] When the appropriate light levels are adjusted on the Android, the prototype (F9) should adjust the LED matrix accordingly.
+ \item[Connection:] You must be able to establish a wireless connection from the Android to the prototype F9 through Bluetooth.
+ \item[Lights:] When the appropriate light levels are adjusted on the Android, the prototype should adjust the LED matrix accordingly.
\item[Libraries:] The application shall use the Communication library.
\end{description}
@@ -148,7 +147,7 @@ \subsection{Libraries}
shall be developed in independent, thus reusable modules so that adding new
functionality will be fairly easy for new developers.
\item[Target platform:] The library shall be compatible with the Android
- system starting from version 2.2. This will place restrictions on the
+ system starting from version 2.2 in order to support more cell phones. This will place restrictions on the
existing software and on the programming languages that will be adopted.
\item[Documentation:] The library shall be documented using Javadoc.
Since the product is going to be further developed by other people and is
View
131 documentation/report/files/sprints.tex
@@ -2,7 +2,7 @@
This chapter describes the work done in each sprint. A sprint is one iteration
of the Scrum process (see section \ref{section:scrum} for more information about
Scrum). The duration of each sprint was two weeks. Every sprint was assigned
-various tasks from the project backlog. Task IDs were assigned to task as they
+various tasks from the project backlog. Task IDs were assigned to tasks as they
were created. Each task was given a specific point value and assigned to one or
more team members. The point value is an estimation of the amount of work
(measured in man-hours) that is required to complete the task. The point value
@@ -10,8 +10,8 @@
time than planned and was not finished by the end of the sprint, it was assigned
a 'prolonged' status and moved to the next sprint.
-For table layout reasons we used some name abbreviations for the names
-of the members assigned to the task.
+For table layout reasons, we used some name abbreviations instead of the full names
+when listing which members are assigned to each task.
\begin{table}[ht!]
\begin{tabular}{ | c | l | }
@@ -42,16 +42,16 @@
\section{Sprint 1}
-Duration: 20/01 to 02/02
+Duration: 20/01 to 02/02\newline
Points total: 89
-The first sprint was dedicated to planning meetings and working hours
-and studying about interested technologies. While some team members had some
+The first sprint was dedicated to planning meetings, working hours
+and studying about relevant technologies. While some team members had some
experience with Arduino, none of us had any experience with Android application
development and social networks. Each member chose his own role in the project,
based on his own area of interest. The team did a lot of brainstorming in
-order to identify possible product ideas to show the customer and produced a
-small proof-of-concept application to show during the first meeting with the
+order to identify possible product ideas which we showed to the customer. We also produced a
+small proof-of-concept application which we demonstrated during the first meeting with the
customer, which was arranged for the beginning of the second week.
\begin{table}[ht!]
@@ -63,15 +63,15 @@ \section{Sprint 1}
7 & Brainstorm ideas about the product & 18 & Everyone & done \\
\hline
- 8 & Search for similar products & 14 & Everyone & done \\
+ 8 & Research existing solutions & 14 & Everyone & done \\
\hline
9 & Proof-of-concept application & 12 & AN,B,E,JH & done \\
\hline
-11 & Read on OpenSocial & 10 & E,H,JN & done \\
+12 & Read on OpenSocial & 10 & E,H,JN & done \\
\hline
-13 & Read Facebook developers' pages & 10 & E & done\\
+11 & Read Facebook developers' pages & 10 & E & done\\
\hline
-12 & Read on Arduino & 8 & AN,AS,B,JH & done \\
+13 & Read on Arduino & 8 & AN,AS,B,JH & done \\
\hline
10 & Choose a development process & 6 & Everyone & done \\
\hline
@@ -103,17 +103,17 @@ \section{Sprint 1}
\section{Sprint 2}
-Duration: 03/02 to 16/02
+Duration: 03/02 to 16/02\newline
Points total: 96
The second iteration was focused on producing more prototypes of the product to
-show the customer in order to receive the necessary feedback to identify
-the product requirements and to begin designing the different parts of the
+show the customer. We did this to receive the necessary feedback for identifying
+the product requirements. Additionally we began designing the different parts of the
system, as well as acquiring the necessary knowledge and confidence with the
-involved technologies. The team also worked on the preliminary version of the
+involved technologies. The team also worked on a preliminary version of the
report. The customer suggested that in order to show the re-usability
capabilities of the code, two more prototypes, considerably simpler than the
-T-shirt prototype, could be produced for the project.
+Jacket prototype, could be produced for the project.
\begin{table}[ht!]
\begin{tabular}{ | r | l | c | c | r | }
@@ -154,16 +154,16 @@ \section{Sprint 2}
\section{Sprint 3}
-Duration: 17/02 to 01/03
+Duration: 17/02 to 01/03\newline
Points total: 108
This sprint was focused on proceeding with the design using the customer
feedback on the prototypes presented so far. An initial version of the
Communication library was also designed and coded. Design of the Social library
also began; various IPC solutions available in an Android system were taken into
-consideration. During this sprint the system overall design started to take
-shape, and the various parts of the system became more definite. The team
-delivered a list of hardware needed to build the various T.U.I. prototypes.
+consideration. During this sprint the overall system design started to take
+shape, and the various parts of the system became more defined. The team
+delivered a list of hardware needed to build the various TUI prototypes.
The customer was happy with the team work so far and provided very valuable
feedback.
@@ -202,7 +202,7 @@ \section{Sprint 3}
\section{Sprint 4}
-Duration: 02/03 to 15/03
+Duration: 02/03 to 15/03\newline
Points total: 112
This sprint was mainly aimed to the delivery of the mid-term report as well
@@ -247,18 +247,18 @@ \section{Sprint 4}
\section{Sprint 5}
-Duration: 16/03 to 29/03
+Duration: 16/03 to 29/03\newline
Points total: 128
During this sprint the team produced yet another prototype for the customer
and proceeded with the design and coding of the Social library. Coding of the
Communication library also continued, and an initial version was deployed by the
-end of the sprint. The team also did some brainstorming and identified the other
-two prototypes that were to be presented together with the T-shirt. Some
+end of the sprint. The team also did some brainstorming and developed concepts for the other
+two prototypes that were to be presented along with the Jacket. Some
proof-of-concept applications for these prototypes were also made. This sprint
was a bit more intensive than the previous ones to cope with the fact that the
next sprint would have coincided with Easter vacation. The team still had not
-received the hardware needed in order to begin building the T-shirt prototype.
+received the hardware needed in order to begin building the prototypes.
\begin{table}[ht!]
\begin{tabular}{ | r | l | c |c | r | }
@@ -299,7 +299,7 @@ \section{Sprint 5}
\section{Sprint 6}
-Duration: 30/03 to 12/04
+Duration: 30/03 to 12/04\newline
Points total: 50
As this sprint coincided with Easter vacation, little was planned for this
@@ -336,24 +336,24 @@ \section{Sprint 6}
\section{Sprint 7}
-Duration: 13/04 to 26/04
+Duration: 13/04 to 26/04\newline
Points total: 130
-Back from Easter vacation! Roughly one week after the group was back from
+Back from Easter vacation! Roughly one week after the group had returned from
Easter vacation, the necessary hardware components needed for the product had
-arrived. Also the customer kindly provided a jacket that was to be
+finally arrived. Also the customer kindly provided a jacket that was to be
used for the final product. The various hardware devices were hooked up with the
Lilypad board and then tested individually, using a mockup application.
-During this sprint the final product changed sightly from a T-shirt to a jacket.
+During this sprint the final product changed slightly from a T-shirt to a jacket.
The Lilypad board probably wasn't the best choice for a jacket product, in fact,
since the Arduino board could be hidden in a pocket, the team could have used
a smaller Arduino board, maybe with power connector and built-in battery
charger circuitry.
-The Social library was finished, tested and an initial version deployed.
-The Comm. lib started being thoroughly tested along with the prototypes.
-Coding for the T-shirt application began. The Facebook and Twitter applications
+The Social library was finished, tested and an initial version was deployed.
+The Communication library started being thoroughly tested along with the prototypes.
+Coding for the Jacket application began. The Facebook and Twitter applications
started being converted from simple mockups to complete applications.
The team also worked on the delivery of the last supervised report.
@@ -387,33 +387,39 @@ \section{Sprint 7}
\end{tabular}
\end{table}
+\begin{figure}[h!]
+\centering \includegraphics[scale=0.8]{img/sprints-gantt7.png}
+\caption{Gantt diagram for the seventh sprint}
+\label{fig:sprints-gantt7}
+\end{figure}
+
\newpage
\section{Sprint 8}
-Duration: 27/04 to 10/05
+Duration: 27/04 to 10/05\newline
Points total: 168
-As the deadline for the project began closing near, the sprints started to be
+As the deadline for the project came closer, the sprints started to be
more intensive. During this sprint the team had some problems with the hardware
-which slowed down the development of the prototype. The LCD screen that the team
+which slowed down the development of the prototypes. The LCD screen that the team
was using stopped working probably due to wrong wiring. The team received a
spare one that was in the Lab a few days before the end of the sprint. As the
-T-shirt T.U.I. changed into a jacket, the Lilypad board lost its main advantage
+T-shirt TUI changed into a jacket, the Lilypad board lost its main advantage
of being a sewable piece of hardware and the team started looking for alternative
Arduino boards, possibly with a battery socket and built-in recharge circuitry
which were missing in the Lilypad. Finally, a board with such features
-(Arduino FIO) was chosen to substitute the Lilypad. A lot of testing involving
-the Comm. lib was performed while building and testing the T-shirt prototype.
-Testing was also performed for the other prototypes: Temperature and LED matrix.
-The coding of the T-shirt and Facebook applications continued.
-The T-shirt application couldn't be completed in time and was moved to the next
+(Arduino Fio) was chosen to substitute the Lilypad (see figures \ref{fig:design-arduinofio} and \ref{fig:design-arduinolilypad}).
+
+A lot of testing involving the communication library was performed while building and testing the Jacket prototype.
+Testing was also performed for the other prototypes: Temperature and BlingLED.
+The coding of the Jacket and Facebook applications continued.
+The Jacket application couldn't be completed in time and was moved to the next
sprint. During one of the meetings, the customer liked an application that we
-were using for testing the prototype functionality during the meeting's
-demonstration and suggested the team to improve it and incorporate it in the
-final product. This was rather unexpected as that application was only intended
-for testing purposes. However the team added the client's request to their goals
-for the next and final sprint.
+were using for testing the prototype functionality. The customer suggested the team to
+improve it and incorporate it in the final product (the oSNAP Generic Application). This was rather
+unexpected as that application was only intended for testing purposes. However the team
+added the client's request to their goals for the next and final sprint.
\begin{table}[ht!]
\begin{tabular}{ | r | l | c | c | r | }
@@ -452,22 +458,27 @@ \section{Sprint 8}
\end{tabular}
\end{table}
-\newpage
+\begin{figure}[h!]
+\centering \includegraphics[scale=0.8]{img/sprints-gantt8.png}
+\caption{Gantt diagram for the eight sprint}
+\label{fig:sprints-gantt8}
+\end{figure}
+\clearpage
\section{Final sprint}
-Duration 11/05 to 25/05
+Duration 11/05 to 25/05\newline
Points total: 172
The final sprint, as in most software processes, was very intensive and aimed
to find as many errors as possible in the product.
-The team continued in building the T-shirt T.U.I. prototype and testing
-the oSNAP and T-shirt applications, and the system as a whole.
+The team continued in building the Jacket TUI prototype and testing
+the oSNAP and Jacket applications, and the system as a whole.
The LCD screen that the team was provided wasn't designed to work with the
voltage the Arduino FIO board was operating at: there were problems adjusting
the contrast. After considering various solutions to the problem, the team
-opted to leave it like that since even if the contrast was off the text on the
+opted to leave it like that since even if the contrast was poor, the text on the
display could still be read. During the first week the team held a presentation
of the product at a SINTEF office near the university. The presentation went
smoothly and the client seemed satisfied with the product. Since most of the
@@ -475,7 +486,7 @@ \section{Final sprint}
week was focused mostly on documentation work.
-\begin{table}[ht!]
+\begin{table}[h!]
\begin{tabular}{ | r | l | c | c | r | }
\hline
@@ -510,9 +521,17 @@ \section{Final sprint}
\end{tabular}
\end{table}
-\newpage
-
\begin{figure}[h!]
+\centering \includegraphics[scale=0.8]{img/sprints-gantt9.png}
+\caption{Gantt diagram for the last sprint}
+\label{fig:sprints-gantt9}
+\end{figure}
+
+\clearpage
+\section{Story points breakdown}
+Below is a visual breakdown (figure \ref{fig:sprints-points}) of time spent on which parts of the project.
+
+\begin{figure}[H]
\centering \includegraphics[scale=0.8]{img/pie_chart.pdf}
\caption{Story points breakdown}
\label{fig:sprints-points}
View
16 documentation/report/files/systest.tex
@@ -1,9 +1,9 @@
Testing is an integral part of every development process.
In iterative software development processes, testing is usually planned in the
-early stages of each iteration and planned as soon as the iteration itself is
+early stages of each iteration and executed as soon as the iteration itself is
complete. As the system evolves so does the testing; it should be more
-comprehensive and cover not only modules but also the system itself as a whole.
+comprehensive and cover not only modules, but also the system itself as a whole.
\section{Testing approach}
Testing can be performed in a top-down or bottom-up fashion.
@@ -26,7 +26,7 @@ \section{Testing approach}
functionalities of the libraries. Stubs (or dummy modules) were also coded
to supply functionalities not yet fully implemented.
-Some of these 'driver' programs were included in the source coded repository.
+Some of these 'driver' programs were included in the source code repository.
These mockup programs were organized into a own package (see section \ref{section:mockup}).
\section{Customer feedback}
@@ -37,13 +37,13 @@ \section{Customer feedback}
iteration goals and plan the next iteration. Feedback from the customer
allowed us to understand the most common use case scenarios and from those
obtain a set of requirements used to design the system and plan test cases.
-Customer's feedback and proved to be very valuable for the project.
+Feedback from the customer proved to be very valuable for the project.
\section{Testing strategy}
\subsection{Unit testing}
Unit testing involves testing small portions of code or of the system itself
-(modules). Where possible, functions have been tested indipendetly. In order to
+(modules). Where possible, functions have been tested indepentently. In order to
test non indipendent system modules, such as the libraries, mockup (driver)
applications were coded.
@@ -65,14 +65,14 @@ \subsection{User interface testing}
involved in their design and coding.
\section{Functional requirement testing}
-Since the project a combination of proof-of-concept and research project,
+Since the project is a combination of proof-of-concept and research project,
tests are planned in order to test the functionality of the various parts of the
system against their own requirements and not for particular scenarios or more
specific use cases.
Tests were performed in order: the hardware and libraries were tested first
(the Android applications depended on both) and then integrated into more
-complete tests involving all the parts of the T.U.I. prototype: Android
+complete tests involving all the parts of the TUI prototype: Android
applications, libraries and the Arduino hardware.
@@ -276,7 +276,7 @@ \section{Functional requirement testing}
\hline Test ID: & [F1] Social lib. / [F2] Comm. lib. / [F4] T-shirt app. /
[F5] Facebook App / [F7] T-shirt TUI prototype \\
\hline Purpose: & Test T-shirt prototype functionality \\
-\hline Precondition: & The two applications are installed and the T-shirt T.U.I.
+\hline Precondition: & The two applications are installed and the T-shirt TUI.
is on and paired with cell phone \\
\hline
Steps:
View
BIN documentation/report/img/app-fb.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN documentation/report/img/app-generic.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN documentation/report/img/app-jacket.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN documentation/report/img/app-led.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN documentation/report/img/app-temp.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN documentation/report/img/app-twitter.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN documentation/report/img/blingled-schematic.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN documentation/report/img/osnap-generic.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN documentation/report/img/sprints-gantt1.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN documentation/report/img/sprints-gantt2.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN documentation/report/img/sprints-gantt3.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN documentation/report/img/sprints-gantt4.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN documentation/report/img/sprints-gantt5.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN documentation/report/img/sprints-gantt6.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN documentation/report/img/sprints-gantt7.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN documentation/report/img/sprints-gantt8.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN documentation/report/img/sprints-gantt9.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
26 documentation/report/report.tex
@@ -135,7 +135,31 @@
% - Should include a description of the problem, the solution and the main results.
% - Typically the last thing you write
\begin{abstract}
-This is our abstract. Last thing we will write.
+
+Social networks, such as Facebook and Twitter, are becoming increasingly popular
+and are used by millions of people throughout the world to share interests,
+opinions and information. Following the advent and spreading of modern
+smart phones, social networks are becoming accesible everywhere. The aim of this
+work is to demonstrate, and if possible, simplify the feasibility of tangible user
+interfaces for social networks.
+
+Three tangible user interface prototypes of different complexity were developed using an open source electronic prototyping
+platform called Arduino. A set of Java applications and libraries, targeting
+Google's Android mobile operative system, were also developed to control the
+behavior of these prototypes and implement their connectivity to social networks
+using the internet connection available on mobile phones. The most complex
+prototype, consisting of a jacket which embedded different hardware devices,
+demonstrated that tangible user interfaces for social networks are indeed
+feasible and could have applications in various scenarios such as aiding in
+disaster management. The other prototypes demonstrated that the libraries
+developed can be used to simplify tangible user interfaces prototyping.
+
+%oSNAP is the result of a research project we took part of on behalf of SINTEF. Our task was to investigate how
+%Arduino can wirelessly interact with social networks through an Android smart phone.
+
+%We have developed several solutions that includes a communication library, social library to exchange social concepts and data.
+%In addition we produced several prototypes using Arduino along with applications to demonstrate their functionality.
+
\end{abstract}
\cleardoublepage
View
2 documentation/report/title.tex
@@ -4,7 +4,7 @@
\textsc{\Large IT2901 - Informatics Project II}\\[0.5cm]
\HRule \\[0.6cm]
{ \huge \bfseries \project}\\[0.4cm]
- open Social Network Arduino Platform
+ Open Social Network Arduino Platform
\HRule \\[1.5cm]
\begin{center} \large
\anders \\
View
2 documentation/report/winmake.bat
@@ -1,5 +1,5 @@
@ECHO off
-del report.pdf
+If exist report.pdf del report.pdf
make
del report.pdf
make

0 comments on commit d9ec567

Please sign in to comment.
Something went wrong with that request. Please try again.