Requirements

In order to reach the objectives, the assignment is to build a smart interactive automatic toilet freshener, using your Interaction technology kit and an automatic toilet freshener (the missing piece), and to evaluate and report its performance.

First things first

  • Attending one of the soldering workshops and soldering a Stickuino kit is a requirement for passing the Interaction technology course. It’s an integral part of this assignment. (Unless you’ve been a participant in this course last year. If this concerns you, please contact the lecturer of the embedded systems and sensors assignment to discuss this if you haven’t done so already.
  • We require you to work on this assignment in pairs, as embedded systems will probably be new to you and there’s a lot of work to be done in a limited amount of time. Find a fellow student. Divide and conquer. Although 2 is still the ideal size for a group working on these assignments, we decided to also allow groups of 3 in some cases. This should be the exception, however, and this requires permission an does imply extra work. See the Standard Operating Procedures page in Blackboard for more details, as well as the consequences of a team of 3.
  • Information on registering your team is available on the Standard Operating Procedures page in Blackboard. You need to use an MS Forms form to register, which is available from that page.

User requirements and context of use

You are required to start at the beginning, i.e. by determining who will use your device and what their particular needs are. In order to get there, the following is required:

  • Prepare and plan your user research. Pick one of the needs gathering methods presented in the lecture. The plan, explanation and planning sheet are available as “Assignment Zero”. The TAs will give you feedback on your planning.
  • Perform your needs gathering. Analyse the data gathered.
  • Include a context of use and requirements specification in your report. Check with the slides to see what these should contain.
  • Your report must show how the design of your toilet freshener stems from user needs which you uncovered.

Note that this part of the assignment is also supported by the “plenary tutorial on assignment 0 and 1” that is in the Blackboard schedule.

Hardware-technical requirements

From a hardware-technical point of view, the requirements are as follows:

  • You need to actually build your system and install it in a real toilet. If you are working together with one fellow student, installing the system once will suffice. If you are working in a team of three, you need to build and install at least two copies of your system, in different households. These two copies need to run the same code.
  • The system may use the components from only a single kit. You may not combine the kits of team members to increase the number of sensors or actuators. The fact that you all acquired a kit does help, however, as it enables you to work on the assignment independently at home.
  • The system should use almost all of the sensors and actuators from one Interaction technology kit. That means that the following MUST be used: a distance sensor, a motion sensor, a light sensor, a temperature sensor, a magnetic contact sensor, 3 push buttons, an LCD display, at least 2 leds (an RGB led counts for 3 if all colors are used) and a mosfet (in combination with the automatic toilet freshener). These are all required. As these sensors and actuators need some supportive components as well, this means that you’ll probably be left with just a few unused resistors, jumper wires and maybe some leds. Feel free to include the LED There Be Light soldering practice board in your setup, for example as an ‘always on’ light show, but it won’t count towards the number of leds (you’ll need to include at least 2 additional leds in that case).
  • You may not use any additional electronic components, besides the contents of the Interaction technology kit and the automatic toilet freshener. You are, however, allowed to use some additional wire, duct tape, screws, card board and other hardware needed for mounting / installing your system.

Functional requirements

From a functional point of view, the system should:

  • Be able to distinguish between a ‘number one’ and a ‘number two’ use of the toilet (which in Dutch would be called a small message versus a big message).
  • Be able to distinguish between the cleaning of the toilet and other uses.
  • Spray once after a ‘number one’ use of the toilet, after a configurable delay.
  • Spray twice after a ‘number two’ use of the toilet, after a configurable delay.
  • Not spray after the cleaning of the toilet.
  • Spray once after pressing a manual override button, after a configurable delay. The manual override button should be a dedicated push button (single purpose).
  • Not spray at other times (i.e. during use, between uses).
  • Keep track of at least the following states: ‘not in use’, ‘in use – type of use unknown’, ‘in use – number 1 use’, ‘in use – number 2 use’, ‘in use – cleaning’, ‘triggered – spray-shot imminent’ and ‘operator menu active’.
  • Indicate its current state using the leds.
  • Display the number of remaining spray-shots on the LCD display during normal operation. (A full can is supposed to contain 2400 spray-shots.)
  • Display the ambient temperature on the LCD display during normal operation. This value should be refreshed regularly (at least once every 2 seconds).
  • Offer a menu system using the LCD display and two push buttons to configure the spraying delay and to reset the number of remaining spray-shots.
  • Suspend all other functionality whenever the menu system is active (status is ‘operator menu active’). Upon exit of the menu system, the system should return to the ‘not in use’ status.

Software-technical requirements

From a software-technical point of view, the requirements are as follows:

  • Your sketch should use external interrupts for at least two of the inputs.
  • Your sketch should be non-blocking and responsive. Don’t use (excessive) delays in your code that may cause you to miss button presses or other inputs.
  • You should handle all time and scheduling related functionality in your sketch by yourself. Using libraries for timers and scheduling is not allowed, unless indicated otherwise.
  • You should handle input debouncing in your sketch by yourself. Using libraries for debouncing is not allowed.
  • Your sketch should be safe with regards to a roll-over of the millis() value.
  • The number of remaining spray-shots should be non-volatile.
  • Your code should be correctly indented, commented, split into functions, etc. like we require in our regular programming courses.

Evaluation requirements

Once your toilet freshener prototype is ready, it is time to evaluate it. In this assignment your task is to:

  • Conduct expert heuristic evaluation using Nielsen’s usability heuristics.
  • Use a minimum of three experts. We suggest recruiting “experts” from other groups. You may use the Teaming Up channel in MS Teams to contact other groups.
  • Report the experts’ remarks in your report
  • Write on how what improvements you plan for your prototype based on the feedback. It is not acceptable to conclude that your system has no usability issues.

Note that this part of the assignment is also supported by the “plenary tutorial on assignment 0 and 1” that is in the Blackboard schedule.

What we didn’t tell you

grumpyrefresherAlthough the specifications might seem to be clear, there are a lot of things implicit to them and left for you to think about and decide upon, such as:

  • Which sensor will you use for which real world variable? Some examples: you could use the magnetic contact sensor in a straightforward way as a door sensor. But you could also use the distance sensor for that. That would leave the magnetic contact sensor free to use as a flush sensor. Or to monitor the use of toilet paper. Or to sense the position of the toilet seat, if at all relevant. Or you could maybe use one of the push buttons as a flush sensor, but that leaves you with just two push buttons for the menu system and the manual override. However, the distance sensor might sense the position of the toilet seat as well. And maybe you don’t even need to sense the position of the toilet seat, the use of toilet paper and/or toilet flushes. Well, you’ll get the idea: there are some serious choices to make!
  • How do you interpret sensor readings? What makes you decide that your system is in a certain state? How do you recover from errors in judging user behaviour? (i.e. deciding on the wrong state, such as ‘in use’ when that turns out not to be the case). And how will you handle errors in sensor readings?
  • What are sensible bounds to enforce, both in sensor readings as well as in the values of the configuration options?
  • If you’ve got 3 push buttons and one of these is used as a dedicated manual override button, that leaves you with a maximum of 2 push buttons for the menu system. How do you make a sensible menu system with only 2 buttons for navigation and selection?
  • Will the menu system time out after an idle period? And will you implement a delay after exiting the menu system to offer the operator some time to leave the toilet before resuming normal operation?
  • Which leds will you use for which states? Can you think of colors and/or blinking patterns that convey their meaning instantly, even if the user is new to the system?

These are the kind of things that generally make the difference between a fairly OK system and a great system. And these are the kind of things that make your automatic toilet freshener into a really smart interactive automatic toilet freshener, featuring a pleasant UX. The course is called Interaction technology, after all…

A few tips

  • We advise you to make sure that each team member builds her or his own copy of the same system (hardware wise). In that way you can easily write, test, debug, share and integrate code that is certain to behave in the same way on all copies of the system. It also allows for distributing tasks (e.g. implement a certain functionality or test and debug someone else’s code).
  • First try to get the sensors and actuators each working independently. Note that there are many libraries out there and that the use of libraries in general (with some exceptions, see above) is allowed. Complexity is mainly introduced by combining sensors and actuators (with possibly conflicting libraries) as well as timer and scheduling related functionality.
  • Get the LCD to work for you: it’s great for debug messages during development. Also use the serial interface for this!
  • You may create and test most of your system on the breadboard / workbench and install it later on. You can replace the automatic toilet freshener by a led for the time being. However, the proof of the pudding is in the eating.
  • You’ll notice that the system has two distinct modes of operation: a normal operation mode and an operator menu mode. Functionality is mostly disjoint between these modes. Use this to structure your code.
  • A lot of the functionality is timer related (x should happen n milliseconds after y) and depends on the current state. Think event loops and finite-state machines here. The passing of a certain amount of time may be considered to be an event as well. Draw a state diagram to help you keep track of what happens in your code; you need to hand one in anyway.
  • Getting your system to work in two different toilets using the same code (requirement for teams of 3 students) will be more challenging than getting it to work in just one toilet (requirement for teams of 2 students). Both environments will be different (light levels, room size, temperature, etc.). Getting it to work under varying condition while running the same code may mean that you need to make certain aspects of your system configurable through the menu system.

Stretch goals

The functionality specified above is the bare minimum. There’s a lot of additional functionality that we can think of for such a system. As we value motivation and enthusiasm, here are some stretch goals, from a functional point of view. These should not be too difficult to achieve. Implementing one or more of these features as a team of 2 students might help us round your grade up. For teams of 3 students these are definitely must haves.

  • Extend the system with a heartbeat indicator: a led that blinks once in a while (at least one change every 2 seconds) to indicate that the system is operational. This will help you diagnose a frozen system.
  • Have the system display its current state on the LCD display during normal operation. This will come in handy for debugging as well.
  • Extend the menu system with the option to set the number of times the system will spray after a ‘number 1’ and a ‘number 2’ use.

And then some

But it doesn’t have to stop here. Feel free to continue adding other functionality that you can think of. Again, for teams of 3 students we will be more expectant. Here are some suggestions:

  • Display the elapsed time since the user started to use the toilet.
  • Use the leds to warn if the spray is running out. (Add a ‘low on spray’ state?)
  • Distinguish between male and female use. (But how? And especially: why?)
  • Display the time of day and add an option to the menu system to set it. (But note: timekeeping is not accurate without additonal dedicated hardware).
  • Display the distance sensed by the distance sensor. (But why?)
  • Display the current light level. (But why?)
  • Keep a log of uses of the toilet.
  • And show the log on the web… (But we’ll move to internet connected devices in the second assignment!)
  • Implement gesture control of your system using the distance sensor… (But we’ll move to gesture based interaction in the second assignment!)
  • …

What will you build? Note: the bare minimum will be fine to get a reasonably good grade, so don’t feel obliged. However, we don’t want to limit your imagination either and we do value creativity.

Bonus for Makers: Lili’s Proto Lab

A bonus will be awarded to anyone who creates a really neat physical device.

For this, you may make use of the facilities in Lili’s Proto Lab, our own makerspace! Lili’s Proto Lab offers digital fabrication tools such as 3D printers, a laser cutter, a CNC, a vacuum former, etc. Feel free to discuss the options with the lecturer of the embedded systems and sensors assignment, preferably before you start on your design.

We also have support available in Lili’s Proto Lab to help you get started: ask for Pieter Kooijman, the lab manager. Feel free to walk-in after 13:00 on any working day. Before 13:00 you are still very welcome, but on appointment basis (send an email to lpl@uu.nl to avoid disappointment in that case).

We value enthusiasm and creativity. But beware: it will only be a bonus. Don’t spend all of your time on just the housing! And note: this is fully optional.

Questions? Problems? Don’t know where to start?

As always, feel free to ask questions! Make use of practical assistance whenever needed. Also, check out the deliverables for this assignment, so that you know what’s expected from you. And finally, we do offer some links to additional resources.

Closing thoughts

We understand that these requirements may be daunting at first, but remember that your smart interactive device does not have to be perfect to get a reasonable grade, and a lot of the things mentioned above (stretch goals, bonus for Makers) are optional (depending on team size).

Furthermore, be careful what you spend your time on. Again, a nice housing is certainly cool, but building it might turn out to be a real time sink. Make sure you get your code and prototype running before you start working on any extras! And don’t forget about the evaluation part!