Due Week 2
Build a microcontroller-based device that can give step-by-step directions. You’ll be given a serial protocol that the device should respond to. Your device should read this protocol and indicate to the user what to do. Assume that whatever device is sending the serial data will be determining the position; your device need only respond to the incoming serial data.
- f – forward
- b – turn around 180 degrees
- l – upcoming left (within 10 seconds)
- L – turn left now
- r – upcoming right (within 10 seconds)
- R – turn right now
- s – stop
- S – stop, you’ve reached your destination
In addition to taking serial input from the USB-serial connection, you need to expose the serial port for an external connector. Provide access to RX, TX< +5V and ground for four wires to plug into.
The total budget for external components (not including the microcontroller and serial cable) is $20.00 US. That’s the retail cost of the components (i.e. what you’d pay for them to build your prototype), not wholesale (i.e. what you could get them for in bulk).
Don’t just build the electronics. Come up with a simple physical form for a user to hold/touch/see/hear, and consider the layout of your components on that physical form.
Work individually on this. All students should build their own device.
One of the most popular (and accessible, from a programming standpoint) applications in the connected devices market is lighting control. In this assignment, you will build a lighting controller for a specific lighting scenario. You’ll be working with commercially available lighting fixtures and the control hubs that communicate with them. You get to choose the scenario, suggestions are below.
Consider not just the lamps (bulbs) and the controllers, but also the fixtures and the room you’re lighting. If you do your job right, we’re looking at the subject you’re lighting, not the light itself.
Work in pairs on this assignment.
For the first phase of the assignment, you’ll design a browser-based control interface that’s suited to the setting you’ve chosen. If a browser-based interface is not appropriate to the scenario in question, you should build a diagnostic interface that lets you test whether all the controls are working from a browser.
First define the parameters of control:
- how many light sources?
- on/off, or dimming?
- Color or white?
- Group control of lamps, individual, or both?
- Ability to create groups?
- Ability to add automated transitions, or not?
- Ability to set and recall fixed configurations, or not?
Then make sure your interface has an interface to modify all appropriate parameters and provide feedback on the current state of the fixtures.
For the second phase of the assignment, you’ll learn one of the APIs for the hub devices or individual fixtures we have available, and you’ll connect your interface to the hub or device.
For the third phase, you’ll build a physical controller to communicate with the system to control the lights. In some scenarios, the physical interface might be very simple, like the Hue Click. In others, it may be a more complex controller requiring multiple physical inputs. Your controller should also give some indication as to its state. At the very least, it should indicate whether or not it has a successful network connection.
A few possible scenarios:
Task lighting for a workbench. The user might want it bright for some work, dimmer at other times, and have the ability to focus on different areas of the bench. Immediate control is probably necessary to make things bright, and there might be reasons to control the lights with the feet rather than the hands, for example when manipulating a soldering iron.
Lighting for a home video studio. In addition to brightness and direction control, the user might want color correction to get the white balance correct.
Area lighting for an open plan studio. Different areas would require individual control, and users might want to control only their own area with an interface that makes it easy to know what area they are controlling.
Classroom lighting. You may want it bright all around for s discussion, area light only on the presenter when doing an on-screen presentation, and area light only on a demo when doing a live demo.
Take home one of the connected appliances we have in-house. (If you already have one at home you’d like to review, talk to me about it) You’ll be living with it for three weeks and reviewing the experience. Here is a partial list of what’s on the market. Please update and add to this spreadsheet as you review. Review the device and its role in your everyday life.
At the end of three weeks, you’ll bring the device back into class, packaged as you received it, and swap with someone else so that they can review it as well.
Review the existing blog posts, and if your product’s been reviewed, add your own confirmation or rebuttal posts. If it hasn’t been reviewed, write a blog post on the product, updating it each week as you continue to use it. Use the category “Product Reviews”.
First week: review the out-of-box experience for your assigned networked device.
- Are there directions included? How clear are they?
- How does it connect? To what does it connect?
- What additional hardware is assumed?
- Is there a software interface to the device? If so, on what platforms?
- What physical indications does the device give as to its status from power-up to full operation?
- Does the device operate without a network? What does it do?
- What assumptions does it make about the network or device to which it connects?
- How long did the whole setup take?
Second week: Keep track of how much you use your connected appliance.
- How frequently do you interact with it?
- In what ways have you adapted your behavior to it?
- In what ways have you been able to adapt it to fit your normal behavior?
- Which features do you use the most? Which ones do you use the least, or never use?
- What features would you add? What features would you cut?
Third week: Take final notes on the device you’ve been reviewing and summarize your experience of it in a full review, incorporating notes and links from your previous reports as needed. Next week you’ll swap them with someone else in the class.
Hub Platform Reviews
Right now, the connected device market is seeing a proliferation of hubs to connect different products. Each hub comes with its own strengths and weaknesses, and most come with their own API as well. It’s not clear which (if any) will become the clear leader. You’ll all be working with different hubs and APIs for your lighting project. Once the lighting project is over, we’ll have an in-class discussion comparing all the hubs. As a group, review your hub in the class blog and prepare to discuss it with the others comparatively.
Final Project: Connected Physical Device System Prototype
Make a working physical prototype of a connected appliance, including any software interfaces needed for it on other devices (browser interfaces, tabled interfaces, etc) Your appliance should include both physical sensors and actuators, and should perform a useful function in everyday life. You can repurpose any of your previous work as needed, but this prototype should be more fully realized than any of your other projects. It should give the class (and any invited guests, TBD) a full picture of how users would interact with this system, from connection to regular use. It should incorporate all the principles we have discussed in this class.
This is a group project, to be done in groups of 3-4. Assign responsibilities for each of your group members. Each week, you’ll be expected to report on your area of responsibility.
The project will be broken down into phases, as follows:
Explain the idea in broad terms, starting with what the purpose of the device is, and how the user interacts with it physically. Tell us who the intended user is, what her needs are, what her motivations to use the device or system are, what capabilities (knowledge or skills) you expect her to have. Tell us something about her life, her surroundings, her activities, her lifestyle.
Your classmates, and possibly invited guests (TBD), will critique the idea’s utility and feasibility.
Usage narrative description
Walk us through how the user uses the product. Explain the functions, the out-of-box experience, the connection process, and a regular use case. Explain it all in terms of what the user senses and does, and what the results are. Use storyboards, images and wireframes as appropriate to describe what the user sees and does.
System Diagram and Bill of Materials
Prepare a set of diagrams indicating what physical devices are used, what network transactions are involved, and what program or processes are running on each device. Label the devices, processes, communication media, and protocols used in the system, and explain step-by-step in technical terms how the system works. In the interaction narrative, you explained the system from the user’s perspective; in this presentation, you’re explaining it from the implementer’s perspective. Your diagrams and any accompanying text should explain as much as you know about what it will take to build this. Make sure to label clearly the elements whose functionality you’re not yet settled on as well.
In addition to the system diagram, prepare a bill of materials. This is a list of every piece of hardware needed to build and operate the system. At first, it may be broad, but by the time you are building, it should be itemized down to the component level. This is ideally done as a spreadsheet, with vendors and costs.
Software Alpha Build and Test Programs
It’s possible that you are still waiting for hardware to arrive at this stage, but you can and should be working on your software already. Since you’ve researched the hardware involved, and know the specs, you can design the communications protocols and write server-side code and UI code. You can test network transactions with simple test programs running on a laptop, tablet, or microcontroller, as appropriate. These test programs can stand in for any hardware you’re waiting for, allowing you to speed the development process. This will allow you to conduct user tests of your software user interfaces, to see how users understand your systems, and to modify as needed.
Hardware Test Programs
Once you have your hardware in hand, you should write simple test programs to test that you can properly receive data from all sensors, and properly control all actuators. Write a program for each different sensor or actuator type in isolation. Ideally, design your test programs so that you can send a simple command over a serial or socket connection as appropriate to test the functionality. This is also a good way to provide for some quick user tests of hardware.
System Integration and final user tests
Once you know you can control all of your components, you should combine them according to your current system plan (which may have undergone modifications as you worked; keep it up to date!). When you have all of the components working together, test it again with users to see if what you have built matches your users’ mental model of the system as you described it to them.
Final Presentation and Summary
It’s not over yet. Once you’ve demonstrated your project in class and had your fellow classmates and guests use it and comment on it, you should prepare a final report on your whole process. Explain what your initial assumptions were and how they changed, what you learned in the development process and the user tests, and what you believe the next steps would be from here if you were to continue with the project. Use media aids as needed, but do not demonstrate your system in this presentation.