Smart Room controller implemented with Microsoft's Gadgeteer
Developed by Ofir Levi and Etay Livne, in a course by Professor Sivan Toledo
Winter semester 2013-2014
Introduction
The following is a documentation of the namesake project for the course "Embedded Systems", held at Tel Aviv university by professor Sivan Toledo in the fall of 2013. The problem we decided to tackle was the ever increasing demand of humanity for automation and control over the immediate environment - namely, their houses. We defined a collection of tasks we found useful and decided to create an embedded system solution that allows easy control over all of them.
Goals
- To create a "smart room" computerization device utilizing a touch screen for easy and intuitive user interface, and which could also be accessed remotely by an internet website for certain tasks.
- To integrate the concept of "profiles" into the device - a profile is a list of conditions and instructions that allow the smart room controller to manage itself with increased automation. Switching between profiles is done manually.
The system is designed and built with the Microsoft .Net Gadgeteer open source toolkit. As could be seen in the diagram below, the project's hardware includes a mainboard which contains an embedded processor and extended by several modules that are plugged into it.
Following is a comprehensive list of all modules and hardware pieces used in the project:
Finally, a flow chart of the system from the user's perspective:
Note that only the different windows are presented in the flow charts, not their features. So, for example, from main window the user can activate or deactivate several modules (lamp, fan, camera) - but there do not appear here as they do not open a new page.
Possible future developments
While the project currently supplies what we feel are some of the most important essentials of a house managing system, there are many ways to improve upon it and enlarge it's scope.
One such way is simply to add more extensions - allow the chip to control more hardware in the house. Washing machines, ovens, maybe even an alarm system.
Another way is too increase the range of actions possible through the internet - eventually, every feature that could be manipulated through the touchscreen could be also made available through the internet.
A third possibility is to make the profiles more sophisticated, by allowing more than one active profile at a time, creating and maintaining logs of activities and/or setting orders of priorities between profiles based on outside input (for example we can give the profile that wants to activate the fan priority once room temperature reaches some critical level).
Last but perhaps not least, the user interface itself could be improved to be more intuitive and aesthetic.
What we learned
Additional resources -
- FEZ Spider motherboard
- GHIElectronics USBClientDP
- GHIElectronics sdCard
- GHIElectronics Display T35
- GHIElectronics EthernetJ11D
- GHIElectronics camera
Challenges and solutions
- When booting the system up, a failed access to the internet for time synchronization will block the program if no server is available.
- We re-wrote the startup function to utilize two threads, such that the main program could continue to run even if access to the internet is unavailable.
- The embedded computer's memory space proved to be too small for our application's needs
- We added an external memory card. Due to our low performance requirements, the increase in time required to access memory was not an issue.
- Similarly, our memory heap proved to be smaller than we initially accounted for, and we found that an average run of the program would over-fill the heap.
- We managed our memory allocations more economically. Specifically, before the change we were using the DateTime structure, but we needed to use multiple instances and their shared memory demands became cumbersome. We dispensed of DateTime and replaced it with our own struct that only had the functions and data we needed.
Full operation flow
The user interface we created, which allows a human user to access and change aspects of the control chip's operation by touching a screen, is event-driven by nature. As such, a traditional chart of operation flow is not the best tool to describe the system's performance. Rather, we included a detailed description of the functionality of each of the features of the chip, and a diagram detailing the flow of the program from the user's point of view.
- startup - initial variables are set according to configurations read from xml files stored in the sd card. an idle-timer is created, and the main window is launched
- main window - from here the user is able to navigate to each of the board's functionalities by pressing the appropriate icon on the touch screen. Note that the lamp, fan and camera icons do not lead to specialized windows, only activate the corresponding relay. List of icons -
- Lamp
- fan
- camera
- internet
- settings
- profile
- Setting window - Here the user can manage many of the parameters of the system-
- idle screen timeout time/enabling
- default profile
- profile check time (time between checking if a profile switch is needed)
- Internet setting - this page accessible from the main window and is static to the user. The IP address is determined upon activation (during the startup stage) and displayed here. Additionally, the user may view a sample of the clock that the system is using as a reference for it's profiles.
- /camera - one of the main features of the control chip is a constant stream of images taken from the camera extension and sent to an established webpage that can be found at XXX/camera, where XXX is the IP address of the current run. This allows for real time surveillance while not at home.
- Profile list window - accessible through the main window, the profile list is exactly what the name suggests - a list of all active profiles in the device. The list is scrollable through the "up" and "down" arrows, and each profile is also selectable. All profiles are saved to an XML file on the sd card to avoid eating up all the memory of the core processing unit.
- profile editor - accessible through the Profile List window, each profile has it's own editor, which includes:
- profile name (by touching the name area a user will get a keyboard screen that allows to type in letter and numbers as expected from a keyboard).
- Rules (by clicking on the adjacent arrow, the user can access the rule editor set of windows)
- scrollable descriptor area that includes all existing rules of the profile.
- Rules Editor - Each profile has a unique editor, and each such editor has a unique rules editor. Divided into two pages for screen space considerations, among them the Rule Editor pages allow
- to set light, fan and system rules
- to control the times at which the profile is active. The controller switches between profiles automatically. Time is managed by a new struct defined for this project that is compatible with the small heap space available for us, and is updated by a connection to the internet.
- Idle Screen - From any window in the system, after a certain amount of time has passed without anyone touching the screen, the system will enter an idle mode (where the display is replaced with a blank black screen) to conserve energy. This is implemented with a global idle-timer.
Finally, a flow chart of the system from the user's perspective:
Possible future developments
While the project currently supplies what we feel are some of the most important essentials of a house managing system, there are many ways to improve upon it and enlarge it's scope.
One such way is simply to add more extensions - allow the chip to control more hardware in the house. Washing machines, ovens, maybe even an alarm system.
Another way is too increase the range of actions possible through the internet - eventually, every feature that could be manipulated through the touchscreen could be also made available through the internet.
A third possibility is to make the profiles more sophisticated, by allowing more than one active profile at a time, creating and maintaining logs of activities and/or setting orders of priorities between profiles based on outside input (for example we can give the profile that wants to activate the fan priority once room temperature reaches some critical level).
Last but perhaps not least, the user interface itself could be improved to be more intuitive and aesthetic.
What we learned
While the work on the final project approximates the development of an actual product, it is still the work of students in a university and is thus first and foremost about learning and experiencing. During work on the project we learned several lessons regarding the subject matter of the course - embedded systems.
First, we experienced the process of designing a product- attempting to anticipate the needs of our potential clients, and use the available ingredients to create what we believe is the optimal provider of these needs.
During work on the system itself we learned the basics of event based programming in C# - while in earlier parts of the course we used event based C for other boards such as contiki, .Net Gadgeteer is higher level and requires familiarity with it's own libraries.
Further, we encountered some of the difficulties of writing code for an embedded system - namely, memory constraints. While writing to a PC, we would never even consider how inefficient certain actions we take are, since we know the computer could easily handle our oversight. However, with the small space that an embedded system can afford, a more economical and precise utilization of memory is required.
In addition, we chose to have some level of integration between our system and the internet (a webpage where the camera constantly streams pictures), which is a high level implementation using TCP. and events.
Lastly, we encountered the problem of a blocking line in the code, which forced us to use two threads during the startup procedure.
First, we experienced the process of designing a product- attempting to anticipate the needs of our potential clients, and use the available ingredients to create what we believe is the optimal provider of these needs.
During work on the system itself we learned the basics of event based programming in C# - while in earlier parts of the course we used event based C for other boards such as contiki, .Net Gadgeteer is higher level and requires familiarity with it's own libraries.
Further, we encountered some of the difficulties of writing code for an embedded system - namely, memory constraints. While writing to a PC, we would never even consider how inefficient certain actions we take are, since we know the computer could easily handle our oversight. However, with the small space that an embedded system can afford, a more economical and precise utilization of memory is required.
In addition, we chose to have some level of integration between our system and the internet (a webpage where the camera constantly streams pictures), which is a high level implementation using TCP. and events.
Lastly, we encountered the problem of a blocking line in the code, which forced us to use two threads during the startup procedure.
Additional resources -
- Link to the code - https://drive.google.com/folderview?id=0B4xxdjqUWYKUTkNfMzYwX0dxYmM&usp=sharing
- .NET gadgeteer documentation - http://www.netmf.com/Gadgeteer/gadgeteercore-documentation
