Difference between revisions of "F12: Smart Bulb"
(→Team Information) |
|||
| Line 20: | Line 20: | ||
* Supervisory commands intended to show that other systems (including home automation) can be tied into this system. | * Supervisory commands intended to show that other systems (including home automation) can be tied into this system. | ||
| − | == Team | + | == Team Members & Responsibilities == |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
=== Roles & Responsibilities === | === Roles & Responsibilities === | ||
| − | * Phil Cyr | + | * '''Phil Cyr''' |
| − | * Stephanie Fung | + | ** Hardware architect, electronics, sensors, software |
| − | * Brandon Schlinker | + | * '''Stephanie Fung''' |
| + | ** Electronics, sensors, software, wiki-updater | ||
| + | * '''Brandon Schlinker''' | ||
| + | ** Embedded systems architect, software, network | ||
== Schedule == | == Schedule == | ||
Revision as of 03:05, 10 November 2012
Contents
SmartBulb: The Intelligent Lighting System
Problem Statement
Conventional lighting systems do not provide flexibility or automatically adapt to users’ needs. While there has been a push for smarter light bulbs, the equipment which has been released to the market incorporates no intelligence, and the functionality is superficial at best.
Our Solution
A lighting system which adapts to occupant needs and produces optimal light output. SmartBulb automatically recognizes ambient light and the presence of occupants, incorporates the diurnal cycle into its decisions, and enables supervisory devices to request changes to the system configuration.
Abstract
Conventional lighting systems, such as those used in commercial workplaces and residences, are antiquated, primarily because these systems provide minimal flexibility and do not automatically adapt to user’s needs. While there has been a push for “smarter lightbulbs”, the equipment which has been released to the market (such as color configurable LED bulbs) incorporates no intelligence, and the functionality is superficial at best. Being able to change your living room’s color to hot pink via your smartphone only allows a user to amuse him/herself. In comparison, we are interested in having the lighting system adapt to occupant needs automatically, recognizing ambient light and occupant presence, incorporating the diurnal cycle into its decisions, and enabling supervisory devices to request changes to the system’s current configuration.
For instance, each of the bulbs (nodes) within our intelligent lighting system is able to sample the current ambient light within the room without visible interruption to its own light output. We accomplish this by producing a light with a 120 Hz flicker, utilizing 60 Hz AC power as a ground-truth available to all bulbs. Since all bulbs are connected to the same 60 Hz AC power source, they all flicker at the same time. This allows us to sample the ambient light using our color sensors, without the light output from the bulb or the adjacent bulbs impacting our measurements. From our samplings, we can determine the intensity of light in the room, along with the color composition of the light. This information is shared amongst all bulbs within the same room via a shared intelligence network facilitated by the Digimesh protocol, which utilizes XBee radios. From this information, a consistent lighting color / temperature is created in the room, and light output can be limited when plenty of ambient light (such as sunlight) is available. When ambient light is limited, the system will utilize the current time-of-day and the diurnal cycle to determine optimal light output. By utilizing the diurnal cycle to make lighting decisions, we can ensure that occupant fatigue due to lighting is minimized, improving occupant comfort.
Objectives & Introduction
System will be able to detect and adapt to changing ambient light conditions
- If the room is dark and occupants are detected, the system should utilize the time-of-day combined with the diurnal cycle to output the preferred light temperature and brightness
- If the room has ambient light, the system should attempt to match the color of the ambient light and should lower its light output to meet the room’s desired number of lumens. * For instance, if a warm colored ambient light is visible to the system, it should produce a warm colored output. If a cool color light is visible to the system, it should produce a cool colored output. Extreme cases can also be demonstrated
- Lights should not need to turn on / off (from occupant perspective) during ambient light measurements
- System will be able to respond to supervisory commands via Digimesh network
- Web interface will be connected to Digimesh network via Raspberry Pi or via ConnectPort X2. User will be able to control the current output (intensity, color) of each bulb, and modify other configuration settings (amount time on when occupant detected, relative location to other bulbs, etc.)
- Supervisory commands intended to show that other systems (including home automation) can be tied into this system.
Team Members & Responsibilities
Roles & Responsibilities
- Phil Cyr
- Hardware architect, electronics, sensors, software
- Stephanie Fung
- Electronics, sensors, software, wiki-updater
- Brandon Schlinker
- Embedded systems architect, software, network
Schedule
| Week Number | Planned Items | Actual |
|---|---|---|
| 1 |
|
|
| 2 |
|
|
| 3 |
|
|
| 4 |
|
|
| 5 |
|
|
| 6 |
|
|
| 7 |
|
|
| Week Number | Scheduled Items | Items Completed |
Parts List & Cost
Give a simple list of the cost of your project broken down by components. Do not write long stories here.
| Part | Quantity | Cost |
|---|---|---|
| Fun Part #1 | 5000 cubits | |
| Fun Part #2 | 88 cubits | |
| Fun Part #2 | 789 cubits |
Design & Implementation
The design section can go over your hardware and software design. Organize this section using sub-sections that go over your design and implementation.
Hardware Design
Discuss your hardware design here. Show detailed schematics, and the interface here.
Hardware Interface
In this section, you can describe how your hardware communicates, such as which BUSes used. You can discuss your driver implementation here, such that the Software Design section is isolated to talk about high level workings rather than inner working of your project.
Software Design
Show your software design. For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level. Do not show the details of the code. For example, do not show exact code, but you may show psuedocode and fragments of code. Keep in mind that you are showing DESIGN of your software, not the inner workings of it.
Implementation
This section includes implementation, but again, not the details, just the high level. For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash. You can include sub-sections for each of your component implementation.
Testing & Technical Challenges
Describe the challenges of your project. What advise would you give yourself or someone else if your project can be started from scratch again? Make a smooth transition to testing section and described what it took to test your project.
Include sub-sections that list out a problem and solution, such as:
Wifi Connection Issues
Many wifi connection issues were encountered. To solve this problem, a dedicated task was created to re-connect to wifi if the connection was ever lost.
Conclusion
Conclude your project here. You can recap your testing and problems. You should address the "so what" part here to indicate what you ultimately learnt from this project. How has this project increased your knowledge?
Project Video
Upload a video of your project and post the link here.
Project Source Code
Send me your zipped source code and I will upload this to SourceForge and link it for you.
References
Acknowledgement
Any acknowledgement that you may wish to provide can be included here.
References Used
List any references used in project.
Appendix
You can list the references you used.
