With the development of low cost wireless chips and microcontrollers, the prevalence of internet connected devices is ever increasing. This provides a great deal of potential as we can start to exercise more nuanced control of previously standard tasks (e.g. lighting). This new level of control allows for new interesting interaction models and the ability to better control how our environment works for us. The key to this future of intelligent ubiquitous computing is the user experience; not only in a user’s control the systems around them, but also the user’s experience of installing, maintaining and upgrading these systems. However, current “smart” devices force extra complexity onto the user instead of enabling these interaction models in an unimpeded way in order to access the functionality for the sake of simpler to develop and produce products . This defeats the purpose of building these devices, because their differentiating functionality from their ”dumb” brethren goes unused; the typical user has no interest navigating layers of apps, hubs, and cloud services, to use the device’s full potential. As a rebuttal to the current industry approach to ubiquitous computing, we present a lighting platform called Twilight that seeks to demonstrate the potential of intelligent and easy to use smart devices. Twilight allows users to enjoy the benefits of a lighting system that thinks for them, optimizing the environment for productivity and comfort while requiring no active management from the end user. Twilight achieves these goals by applying ideas from the field of swarm robotics and developing a lighting system that is self-organizing and reconfigurable
This work was funded by the University of Illinois Urbana-Champaign Association for Computing Machinery Chapter We would like to acknowledge our gratitude to our Advisor Prof. Can Bayram and our Teaching Assistant Rebecca Chen for their time and advice as we conducted this work.
The environment people live and work in has a deep impact on many things including mood, psychological health and productivity. Simple changes like having the correct color temperature at different times of the day or or having the environment handle simple background tasks to reduce cognitive load may help people live happier and healthier lives. However, the main blockers to wide-spread deployment of these intelligent environments include their cost and rigidity. Twilight aims to rectify some of these problems.
Typically there are a couple issues that can cause systems to be rigid and hard to use. Dependence on user interface flows that are not intuitive or do not leverage the user’s habits, means that whatever baked in smart functionality doesn’t get used. When these systems are not fully utilized as designed, they often fall back to a default functionality that is not better than a standard “dumb” equivalent 3 which calls into question why someone would invest in a more advanced system.
Moreover these systems are rigid, typically requiring a centralized external reliance like a hub or cloud service in order to coordinate actions throughout the system. The hub is not a great solution as it introduces a bottleneck for the scalability of the system as each hub as a limited number of nodes it can support 4 and a maximum range at which lights can connect to the hub. This means a user must build around hubs, buying multiple hubs, placing them in the foreground in order to support the system.
Even with a hub, most systems also require use of a cloud service in order to get the full set of features. This means that in order to use your expensive smart bulbs you always need to have an internet connection, also if the company running the cloud service ever goes out of business your home’s lighting system stops working.
A potential solution to the rigidity problem of traditional systems is to use ideas from biology, namely the idea of collective behavior and self organization. By developing a federated system to govern the control of the entire of lighting system, we remove the central controller bottleneck. Such an architecture also introduces flexibility into the system, as nodes can now enter and leave the system without the system collapsing and the system can partition itself and continue to operate. Farrow et. al. present a platform built upon this core idea and show that intelligent collective behavior can be displayed without a central controller. Their work shows a smart wall system where each brick communicates with other bricks to develop a distributed touch screen and to leverage the heterogeneous hardware of the bricks to allow the entire system to utilize special components of particular blocks.
These are all useful properties of a potential lighting system to have. Because there is no reliance on a central controller the system scales from 1 to many nodes better than the current deployed solutions. The self organizing behavior means that as long as a node is connected to the system it can inherit the properties of the system, hence removal of any one node does not collapse the system. The system can be partitioned easily so nodes in one room need not be connected to nodes in another room. The system also can act like a normal device on a network through the use of a border router, so control of the system is direct within the network without the use of a cloud system.
Almost all existing smart lighting solutions require a companion app on a user’s phone to configure their “smart” functionality. This is an unexpected and unnatural user interaction model for most people.
Twilight from a user’s perspective will immediately begin executing intelligent functionality out of the box. Twilight will not require any significant external control for its operations, will make programming the system easy for application developers, and will most importantly not be required by the end user.
Installation of many existing lighting solutions is a long, nonintuitive process of pairing with a hub or connecting to a WiFi network.
Installation and maintenance of Twilight will be trivial to the point where a student can put a fixture up with no help. As a result, Twilight should be compatible with standard ceiling tiles and be robust to individual Twilight blocks failing.
Twilight blocks will run off standard AC wall power and will daisy chain power to one another to reduce cabling.
Twilight is sponsored [email protected], an organization that exists to help students explore the world of computing, mainly through experimentation and project building. This is one of many platforms [email protected] is bringing up to provide the members opportunities to work with complex technologies in a tangible way. Therefore Twilight must be a system that lets students easily express their creativity on this platform.
As entailed in Section 1, the use of a self organizing architecture alleviates many of the issues current intelligent lighting systems have today. From the outside Twilight looks like a collection of wooden boxes in a grid formation with cables connecting them together, see Figure 2. Each block is connected to its neighbors via a serial connection (orange) for communication and power (black) for distributing the 120V AC input. The power connections pass through each block with each block converting down to 5V DC to power the Raspberry Pi and the LEDs. While other configurations of the system will be supported, this will be the canonical topology as it most closely matches the space the system is designed to be deployed in. This simple layout is easy to install due to the block’s compatibility with standard ceiling tiles. Each block is magnetically mounted and makes very simple interconnections to adjacent nodes. This simple exterior hides the intelligent behavior detailed below.
When the system is powered on for the first time, it will perform a localization protocol where each block creates a map of the system. This is done by the device with the lowest MAC address propagating it’s location as the origin, this block will be referred to as the border router of the system. Neighboring blocks receive this location message, use it to assign their own location, and further propagate this information to their neighbors, signing the message with its MAC address and the number of times the message has been propagated. The block will take assignment from the message with the lowest hops, if there happens to be a tie, the assigner with the lower MAC address will be believed. If a block has been assigned and a new message comes in with fewer hops than the assignment message that previously assigned the block and the locations differ, then the block will take the new message. If a block has been assigned and sees a location assignment message that has more hops than the assignment message that assigned its location, the block will ignore the message and not propagate it, so eventually the messages will all die out finalizing the network topology.
Once the topology of system is established, nodes will begin waiting for a command from the border router to begin executing. On subsequent power cycles, the system will first begin by trying to recover the topology it discovered previously by confirming its neighbors are the same neighbors it remembers. If not, it will trigger attempt to begin the localization and consensus protocols for the system again. If a threshold is passed, 33% of the network, then the entire system will re-localize. If the threshold is not passed then the unlocalized block will ask its neighbors to tell it its location. In the case of inconsistent locations, the block will defer to the location closest to the origin location of the network.
Now that the system is organized, it can start to do useful work. User control of the system is done through the border router. From the user’s perspective, control of the system can be anything from a simple on-off to any number of more complex interfaces that connect to the border router. It is the developers job to translate the high level setting into operations the network can carry out. For the example of a color temperature regulator to match the time of day, the code is as simple as a each block running a mapping from date/time to RGB value. However for more complex examples like displaying a pattern or music syncing, the developer can draw on the internal localization and consensus of the system in order to create collective behavior. Loss of network connection does not hamper the functionality of the system, as it will continue to attempt to run the last command from the user.
It may be case where a user wants to take down the system and move it, add a new block, or remove a broken block; the self organizing property of Twilight makes it robust to these possibilities. If a block is removed, the system will continue onwards since there is no dependency between blocks in the system. If the block removed is the sole intersection of two partitions of the network the system will begin to run as two separate systems. If the block removed is the sole border router in the system or there is no border router in the system, then the system will execute the leader election protocol, looking for the block with the lowest MAC address and having it become the border router. This is determined using periodic polling of the current border router and a timeout. If a block is added or the network is rearranged, the system will go though the localization steps described in 2.1.2 and resume operation as normal.
Specific Requirements and Verification tests to demonstrate these properties can be seen in Table 7.
Block Hardware Architecture
The backbone of each block is a Raspberry Pi Zero responsible managing the high level software execution of the block and reacting to the messages from other blocks. Though the self organizing functionality of the project can be accomplished on a microcontroller, we choose to include the Pi because it provides a comfortable environment for student developers (which is crucial as this is a learning platform).
We designed custom daughter board for the Raspberry Pi which features an ATMega2560 connected to the Raspberry Pi via I2C. This daughter board manages communication on the Twilight network and as an LED driver to control the RGB LED strip within each block. Each block also includes a AC to DC power supply for the Raspberry Pi, daughter board, and LEDs to run off of standard AC power.
The choice of an ATMega2560 was due to its four hardware backed serial ports and its compatibility with common development tools and libraries. We decided to use an RGB strip because it allows for dynamic animations and smart effects than a purely warm LED strip.
A high level functional block diagram of a Twilight block and how it may connect to other blocks is shown in Figure 12. Schematics, board layout, and a bill of materials can be seen in Figure 6, Figure 7 and Figure 8, and Figure 6, respectively.
The overall block functional architecture did not change over the course of the project, however individual sub-components implementations were revisited multiple times. These changes are detailed below along side the final implementations of the components.
For a proof of concept we constructed a system of three blocks. Each block is a magnetically suspended wooden box with the same dimensions as a standard ceiling tile, a square with external width 24.5” and internal width 23”. The internal sides are covered with with aluminum tape, improving the internal light reflection. A strip of 140 LEDs is wrapped along the these inside edges. The bottom face of the frame is covered by a canvas diffuser mounted to the inside of the frame. A Raspberry Pi with the custom daughter board is mounted to the inside of the block. Two NEMA 5-15 outlets, one male and one female, are inlaid into the two opposing sides provide power to the LEDs, Raspberry Pi and control board and propagate power to further blocks. Lastly, holes are drilled in all four sides to allow serial cables to pass through for serial communication between blocks. Renders of these boxes can be seen in Figure 10 and Figure 11.
We had initially planned on using RJ45 connections between blocks, backed by Ethernet to facilitate communication. However this implementation made construction significantly more difficult and introduced the technical complexity of creating and housing the corresponding required networking switch. This informed our decision to use simple serial lines between blocks.
The LED Driver is responsible for taking display frames, a description of the color of each LED in a block from the Raspberry Pi and displaying them.
Figure 14 and Table 2 together specify the shape and duration of the various LED control signals. The controller software meets these timing by setting an output PWM pin high and performing an appropriate number of NOPs (No-operations) then setting the PWM pin low and and again waiting an appropriate number of NOPs. Explicit requirements and verification tests to confirm functionality of the LED driver can be seen in Table 9
This component was initially designed to work via TTL logic. The design consisted of a ping-pong buffers, one to store the next display frame from the Raspberry Pi and one to shift values out to be displayed by a signal generator. When a new frame was ready and had been loaded into the first buffer, a ready signal would be raised to trigger the second buffer to load all of its values from the first buffer in parallel. These shifts would occur every 1.25ns and be fed into a signal generator.
This generator would take an input and generate the corresponding wave via a hardware FSM and a 16Mhz crystal designed to meet the LED control signal requirements. However, this was not achievable a single semester and the design was revised. We now do this process entirely in software on the ATMega2560.
Each Twilight block uses a MeanWell IRM-20-5 integrated switching power supply that provides 4A at 5v. Explicit requirements and verification tests to confirm functionality of the power supply can be seen in Table 8.
Initially the power design called for a custom two stage solid state transformer. 120V AC wall power would first be rectified to 120V DC via a full bridge rectifier consisting of four diodes and smoothed by a capacitor. This power signal would then be stepped out to 5V DC via a Buck-Transformer and used to power all the other components in the block.
This approach had issues regarding weight and size and was scrapped for a switching power supply design. However, designing a switching power supply would have been significantly more complex than a standard transformer based one and would push the amount of work for this project out of the scope of this class. We therefore opted into using an integrated component.
This decision allowed us to focus on the other components as well as reduced risk of injury as working with AC power is dangerous and using an integrated system mitigates that risk.
Additionally, using an integrated power supply allowed us to use a small and light package achieving the power supply component’s weight and size requirements, which were potentially infeasible by a custom designed power supply.
The I2C to UART subsystem manages the inter-block communication. This is used to transfer new programs and configurations from the Raspberry Pi and to transmit relevant data for the execution of the current program between blocks. Raspberry Pi Zero comes with a single dedicated UART handler exposed on GPIO. However each block may have to support up to 4 connections at a minimum of 9600 baud. We therefore use I2C and the control board as a way to multiplex a single connection to a PI to the four serial connections it needs to support. The design is based off of an ATMega2560, which has 4 hardware UART implements are protocol translating each incoming/outgoing UART connection into a I2C slave. The various messages sent over this interface are detailed in 2.3.2
Our first implementation of the Inter-block communication consisted of an Ethernet con- nection between blocks running a custom communication protocol to allow for long buffered message streams with error detection.
The initiating block (referred to as the initiator) would start in the idle state. After deciding to send a message to a node, it would send a request to start a connection (termed: “Ready to Listen”) and wait for a “Ready to Listen Confirmed Message” from the receiver. Once getting the confirmed message, the initiator would begin transmitting the message, sending packets followed by their hashes to confirm integrity. Once the data packets were all sent the initiator would signal the transmission is complete via an “END” message and return to the idle state. The initiator’s transitions can be seen in Figure 4.
The receiver would also start in an idle state, but it would wait for a “Ready to Listen?” message. It would then respond with confirm to start a connection or would ignore the “Ready to Listen” 8 . After sending a confirmation message, it would wait for data, verifying packets as they came in. Once the initiator sent the “END” message, the receiver would return to the idle state. The receiver’s transitions can be seen in Figure 3.
This design was ultimately scrapped as due to the many edge cases that were not fully handled. We decided to use the ATMega2560’s built in serial communication due to its robustness and build error detection on top of it.
Each block contains a Mean Well IRM-20-5 power supply with a total power budget of 4A @ 5V (20W). While the power supply can exceed the rated maximum (up to 25W) for short periods, we impose a hard limit 20W of power draw even in the worst conditions. This restriction provides a comfortable safety factor of, at worst, 1.25.
Table 1 contains the values for typical and maximum power draw for each component in a block’s electrical system. The values for the “Raspberry Pi - Zero” and “ATMega2560” come from each component’s respective datasheet. The values for the ”Supporting Components” come from a reference design for an ATMega based daughter board. The values for the “LED Strip” were found empirically from 4 prototype blocks and represent the maximum value observed for both the typical and maximum power draw. The “Estimated Losses” come from possible DC losses through the system and represent a worst case scenario. As seen in Table 1, in the worst conditions where ever component is drawing the maximum possible power a block will never reach the limit of 20W. The maximum draw of 16.47W ensures a safety factor of 1.52 above the industry standard safety factor of 1.25.
The wood frame of each block creates additional thermal constraints to the power system. The calculated max power draw, 16.47W, is non-trivial and presents safety concerns regard- ing potential autoignition of the frame. In this section we explore the worst case scenario: the electrical system is 0% efficient, all energy is lost as heat into the wood frame, heat is only dissipated into the air external to the system.
Given this scenario we must ensure the wood equilibrium temperature falls below its autoignition temperature. Table 3 details the various physical thermal properties of the system used to determine the wood equilibrium temperature.
This system can be modeled as heat transfer through conduction (1) where the power transfered is equal to the power injected.
As seen in equation (4) the wood equilibrium temperature in the absolute worse case scenario is far below wood’s autoignition temperature. Realistically, the system will have an efficiency around 80% and additionally a large percentage of the heat will be dissipated through the diffuser. Given these calculations there is no concern that a block’s frame will auto-ignite.
Block Software Architecture
The software of the Twilight system is centered around a single block. This goes back to the swarm robotics roots of the system design. Each block runs the exact same code (except for the border router which will run an extra layer, though all nodes in the system will have the ability to run that code as will if needed). The complex mulit-node behavior of the system is an emergent outcome of the execution of each block’s software. Because of this there is no overarching network code or different versions for different roles. Each node’s software is centered around the host runtime on the Raspberry Pi. This code is responsible for all actions in the node (LED control, message exchange, etc.) The host runtime interfaces with the controller firmware flashed on the control board and if the border router and whatever local area network (LAN) the border router is configured to interface with if the node is the system border router. The controller firmware executes commands from the host runtime in the box and delivers and receives messages on behalf of the block. Finally the border router code will connect a node both to the twilight network and LAN and ultimately whatever user interface the end user chooses.
The host runtime has a couple major subcomponents. There is the node state manager, which maintains the state of the system, containing information about ID (MAC address), location, current executing command, and LED color. These values are modified by defined system protocols like the localization protocol (as described in Section 2.1.1) or by the developer though the Device API. There is also the message exchange which periodically poles the control board for new messages from the Twilight network and sends messages to be sent to the twilight network and commands from the host runtime to the control board after serializing time into strings for easier transfer over I2C, the format of which is described below. Behavior of the node based on incoming messages and other stimuli is decided at the application layer which is defined by the developer. Border router implementations are an example of application layer software for a node.
The controller receives commands from the host via I2C in the form of serialized strings.
The prefix of the string determines its type. For instance
LED: means that the string is
a command to turn the box a specific color. After the string is reconstructed from I2C it is
parsed and sorted. It then follows the following control paths
- LED Command
Messages coming in from the host controller starting with
LED:specifically are sent to the LED driver to be displayed.The LED driver converts this string into a RGB tuple (after some format verification) and sets the LEDs to that color.
LED:250,0,0sent to the controller from the host over I2C will turn the box color to red.
Messages starting with
COM:coming from the host are treated as outgoing messages. The firmware will take the message and multicast it as is to its sur- rounding nodes. If the firmware receives a message from the twilight network starting with
COM:, it will store it in a mailbox for the next time that the host poles for incoming messages.
COM:HELLO WORLDsent to the controller from the host over I2C will will send a message
COM:HELLO WORLDto all neighboring nodes. Each node will receive the message and log which direction the message came from by appending an enum to the end of the string (e.g. a message coming from the south has 3 appended to the end). The next time that one of those nodes polls for new messages it will see in the return set of messages
COM:HELLO WORLD;3. From there the application layer of host runtime can decide what to do based on this message.
Messages coming in starting with
LOCcoming from the host are treated as outgoing messages from the controller’s perspective. The firmware will take the message and multicast it as is to its surrounding nodes. If the firmware receives a message from the twilight network starting with
LOC, it will store it in a mailbox for the next time that the host poles for incoming messages appending with direction it came from to the end of the string. When receiving nodes poll their controllers and the message is transfered into the bus, the system protocol layer will see the
LOCmessage and begin the localization protocol.
LOC:0,0;[BLOCK1_MAC_ADDR];0;3sent to the controller from the border router host over I2C will send a message
LOC:0,0;[BLOCK1_MAC_ADDR];3to all neighboring nodes. If the firmware receives a message from the twilight network starting with it will store it in the mailbox for the next time that the host poles for incoming messages after appending the direction from which it came (e.g. 3 for south, hence
LOC:0,0;[BLOCK1_MAC_ADDR];3;3). When the protocol layer sees the
LOCmessage in the inbox, it will parse out the string into the following information:
(0,0) - Location of the block sending the message BLOCK1_MAC_ADDR - ID of the block sending the message 3 - Time to Live (TTL) of the message 3 - Direction the message came from (SOUTH)
From this message, the host code will modify its state to set its location to (0,1) ((0,0) is one hop south of this block) and then send the message
LOC:0,1;[BLOCK2_MAC_ADDR];2to the firmware to be sent out to the network.
Application Layer Code
A developer can write custom responses to stimuli in the network using the device API, this is refereed to as the Application Layer. This is where the developer can start to create intelligent behavior for the system.
Border Router Software
Border Router software is a subset of application layer code, with the main caveat of making a connection to the outside network. Typically this is done by a web server running a REST API which converts HTTP requests into command strings for the controller. An external control application can then use the REST API to control the system in a similar manner to other application layer code.
External control applications are where the end user can begin to configure and control their system to their liking if so desired, as the system will operate without external control. These applications can take the form of an iOS app (see Figure 17) or a website or another hardware device. All that is required is to be able to make an HTTP request. How all of these components interconnect to establish the full Twilight system is described in Figure 13.
Development and Verification
In the course of developing a first working version of Twilight we iterated through various implementations of the Twilight hardware. We started with off the self hardware, in order to make iteration time much faster. Figure 9 shows an initial system model we used when developing core software. It shows two nodes connected via serial to each other, each roughly following the high level component structure of the final design of a block, albeit with less LEDs to drive to make suppling power more manageable. Here we learned that our initial protocol design for inter-block communication (Figure 4 and Figure 3) was overly complicated and common libraries abstract much of the error correction out for us.
We then moved on to our first attempted bring up of our control board. Here we learned some key lessons if we were to revise our design. Our board looked to be compliant with the Raspberry Pi Zero Hat Standard. The working space of the Hat is very small and as such we chose small components. This made the board very difficult to manufacture. Some choices of packages made this even more difficult. However, we still managed to build three booting boards.
The use of a custom board required the development of a custom toolchain to flash the MCUs on board, especially since potentially there are 10s of boards to flash. Here the initial prototype was helpful again as we used it to prototype a toolchain that uses the Raspberry Pi GPIO to flash the MCU, opening the possibility of remote/programmatic updates of not just host software but the firmware.
With our 3 booting boards we did run into an issue when we tried to run our prototype firmware on our custom boards. We were unable to control the LEDs. This is a key re- quirement of the project, and without it the system would be meaningless. It took using an oscilloscope to measure the frequency at which the control signal was being sent to the LED strip to realize that the MCU was running at a fraction of the expected clock frequency. After some research we found that out of the box the ATMega2560 uses an internal 8MHz clock divided to 1MHz. This speed is far too slow to control the LEDs. The datasheet of the ATMega showed that in order to use the external 16MHz oscillator we placed on the board, we needed to set the internal control fuses correctly, and if done incorrectly the chip would brick. After finding the particular value of the LOW FUSE BITS to set, we saw our clock running at 16MHz and we were able to control the LEDs.
Once we resolved that issue, it was a matter of completing the final boxes, of which we only had minor mostly cosmetic modifications to add and develop the full fledged firmware and software. Development of the firmware was more significant task of the two as we needed to handle multiple protocols doing orthogonal tasks. We started with the I2C driver for the Raspberry Pi and the manager for the control board. Development of this component took a lot of trial and error, using different libraries, configurations and strategies for data transfer. Due to details in the hardware implementation of the MCU’s I2C discovered in this process we had to limit any sort of message between the Pi and the MCU to 32 bytes. Serial was much harder to bring up as it required developing on two headless nodes. Instead we began by connecting one of our boards to an Arduino and printing out the message sent by our board. Once we could do that we tried to do the opposite, using the LED strip to display if the expected message arrived. Finally we tried connecting 2 then 3 of our boards together.
We now needed to merge these three components of the firmware together. Here we hit some of the limitations of the MCU. Since it is single threaded and we are trying to handle concurrent processes, we started to create buffers that the system could use so that not too much of the time is used on any given task. In our small LED strip prototyping platform, this works fine but as we attempted to scale up to 140 LEDs per board we hit the singular major failure of this project. We were not able to control a full set of 140 LEDs while also trying to receive messages from the twilight network and the Pi. The system would begin to deadlock as the LED library we use disables interrupts as it is updating the LEDs. Our best guess is that is may be happening in a context that prevents further interrupts. A change of library might be able to alleviate this issue, however we chose to address other requirements instead of this particular one.
The requirements of this work and its subcomponents are shown in Tables 7-10. We were able to successfully address all of our major system requirements. The system on startup can localize itself and begin execution of the standard program. This is shown by a test utility we write. We can then send a command to one node and have all nodes in the three node system react correctly. And we can remove a node, add it back and have it function correctly. We can also split the 3 nodes into 2 partitions and have them both work independently. We are able to control our LEDs and hence are able to correctly generate 1s, 0s and Reset signals for the strip. Since our power supply is an integrated unit, we were able to verify that it can convert 120VAC to 5VDC at 4A at our weight and size requirements. Finally other than a limitation of the simplification of our serial communication which limits the ability to guarantee all messages are delivered, we can transmit data without data loss, at 9600 baud and can localize successfully.
Each Twilight block contains every component listed in Table 4. While there is no set requirement for the per unit cost, keeping these costs down was an important consideration when choosing parts. When discussing various possible criterion and requirements keeping the per unit cost below $50 was mentioned, however never finalized. Regardless, as seen in the table, each block costs $35.44 in materials below this threshold. It is important to note that labor and maintenance costs are explicitly not included here as Twilight will be a student managed and maintained project.
By the end of the project we were able to create, demo, and install a successful realization of a three node system. We were able to achieve all the high level goals defined at the beginning of the project; Twilight is partition tolerant, self organizing and reconfigurable. Moreover, setup is plug and play and extremely easy for any student to do. Additionally, the API for potential student developers consists of simple string based commands. While we were able to achieve all the high level goals we set out to, Twilight has ample room for improvement. We have identified many places we can make the system even more intelligent and robust. In the future we would like to: resolve the LED driver instability, increase communication speed to allow for fast message propagation throughout the network, block more boxes and build out the device firmware into a fully fledged “TwilightOS”.
The biggest safety issue in Twilight is working with and distributing wall power. Since every block in the system will be working off wall AC power, verification of the power supply is crucial. This safety risk in addition to technical concerns led us to scrap designing the power supply ourselves and instead use an integrated off the shelf component.
Additionally there are concerns around issues like epilepsy when dealing with fast anima- tions. We addressed by limiting the frequency of the LEDs in our LED Driver firmware and introduced a reviewing system so no firmware that circumvents this can deployed on the system.
Moreover, while this platform is designed to be used to improve peoples’ environments, through the use of color temperature modulation, one could the system to decrease peoples’ quality of life. For instance, many people have complained about short wave heavy white LEDs used in streetlights preventing people from sleeping. Our software reviewing process also involves testing potential programs to ensure they do not decrease a viewer’s quality of life.
There are potential environmental concerns that may arise when sourcing LEDs as some have been found to contain lead, arsenic and other dangerous substances. We took proper care in sourcing RoHS compliant components throughout the project.
 AVR040: EMC Design Considerations, Atmel. Retrieved October 18, 2017. Available at: http://www.atmel.com/images/Atmel-1619-EMC-Design-Considerations ApplicationNote AVR040.pdf
 AVR042: AVR Hardware Design Considerations, Atmel. Retrieved October 18, 2017. Available at: http://www.atmel.com/Images/Atmel-2521-AVR-Hardware-Design-Considerations ApplicationNote AVR042.pdf
 C. Rowland, ”What’s different about user experience design for the Internet of Things?”, O’Reilly Media, 2017. [Online]. Available: https://www.oreilly.com/learning/whats-different-about-user-experience-design-for-the-internet-of-things. [Accessed: 03- Oct-2017]
 W. van Bommel and G. van den Beld, ”Lighting for work: a review of visual and biological effects”, Lighting Research & Technology, vol. 36, no. 4, pp. 255-266, 2004.
 I. Knez, ”Effects of indoor lighting on mood and cognition”, Journal of Environmental Psychology, vol. 15, no. 1, pp. 39-51, 1995.
 N. Farrow, N. Sivagnanadasan and N. Correll, ”Gesture based distributed user interaction system for a reconfigurable self-organizing smart wall”, Proceedings of the 8th International Conference on Tangible, Embedded and Embodied Interaction - TEI ’14, 2013.
 H. Ishii, H. Kanagawa, Y. Shimamura, K. Uchiyama, K. Miyagi, F. Obayashi and H. Shimoda, ”Intellectual productivity under task ambient lighting”, Lighting Research and Technology, 2016.
 R. Küller, S. Ballal, T. Laike, B. Mikellides and G. Tonello, ”The impact of light and colour on psychological mood: a cross-cultural study of indoor work environments”, Ergonomics, vol. 49, no. 14, pp. 1496-1507, 2006.
 J. Kim, J. Ko and M. Cho, ”A Study of Integrated Evaluation of System Lighting and User Centered Guideline Development - Focused on the Lighting Design Method for Office Space -”, Korean Institute of Interior Design Journal, vol. 23, no. 6, pp. 78-86, 2014.
 D. Park, Y. Lee, M. Yun, S. Song, I. Rhiu, S. Kwon and Y. An, ”User centered gesture development for smart lighting”, HCI Korea 2016, 2016.
 F. Tan, ”User-in-the-loop smart lighting control system”, Masters, Delft University of Technology, 2016.
 D. Burmeister, A. Schrader and B. Altakrouri, ”Reflective Interaction Capabilities by Use of Ambient Manuals for an Ambient Light-Control”, HCI International 2016 – Posters’ Extended Abstracts, pp. 409-415, 2016.
 A. Lucero, J. Mason, A. Wiethoff, B. Meerbeek, H. Pihlajaniemi and D. Aliakseyeu, ”Rethinking our interactions with light”, interactions, vol. 23, no. 6, pp. 54-59, 2016.
 National Electrical Code. Quincy, MA: National Fire Protection Association, 2007.
 ”Serial Baud Rates, Bit Timing and Error Tolerance”, 2017. [Online]. Available: http://www.picaxe.com/docs/baudratetolerance.pdf. [Accessed: 20- Oct- 2017].