Group 6: Your Own Loving Teddy Bear

December 18, 2017November 20, 2018
by Raluca Semenescu

“Imagine entering your home and your Teddy Bear greeting you with a welcoming message or with lighting up eyes. Also, it will be great if the Teddy Bear is not so welcoming to other members in the house (just for fun!). For this, you are encouraged to use an RFID tag and reader with a choice of tags, one of them being your own, hence the Teddy realising it is you and delivering a friendly message! You need to use at least one other tag that is not yours and hence delivering unwelcoming messaged and red eyes! Remember, you do not need to use a real Teddy Bear but you can use other prototyping options.”

Meeting #1 – 21st of November 2017

On our first meeting, we carefully studied the project brief again and ensured everyone had completely understood it. We then moved on to brainstorming and defining the story behind our object: what is its purpose? What are its functionalities and how can we achieve them? Who is it aimed at? How can we make the design meaningful to users? etc. While asking ourselves these questions and seeking answers, we managed to establish a solid starting point for our project.

Object

The product we will be working on for the next 3 weeks is an interactive teddy bear which will aim to entertain the user through a variety of functionalities. Moreover, our teddy will be more than “fun”; it will engage with the user as much as possible, make an emotional impact and appeal to their senses, too.

Purpose

The main goal of the teddy bear is to relax users and provide comfort through its unique set of functionalities (i. e. in comparison to the classic teddy bear we all get attached to). We decided to focus mainly on children, as they are more likely to use teddy bears. In particular, the toy would act as a therapeutic device and help them overcome loneliness, autism or solve their behaviour issues (e. g. for more agitated and violent children). Secondary goals include offering users a fun, as well as useful experience.

Target users

As stated above, children are our main point of interest. However, the teddy bear will be designed to be suitable for many groups of people, including teenagers, young people and adults.

Market research & inspiration

Before brainstorming the functionalities of our object, we conducted a brief market research to understand what it already has to offer and analyzed a few existing electronic and interactive toys. Here are a few examples:

[Furby] https://en.wikipedia.org/wiki/Furby

https://www.toysrus.com/buy/interactive-stuffed-toys/georgie-interactive-12-inch-electronic-plush-puppy-540175-91837786

[Furreal Friends] http://www.very.co.uk/furreal-friends-furreal-chatty-charlie-the-barkinrsquo-beagle/1600188979.prd?crossSellType=item_page.recs_1

Possible functionalities & ways to achieve them

recognizing the owner (positive response to owner, negative response to other people?)

solutions: RFID reader and tags/ facial recognition/ finger print scanner;

heart simulation (visual and auditive – heartbeat)

solutions: red LEDs/ 8×8 matrix LEDs, speaker;

when owner squeezes the Teddy, the heartbeat becomes louder & quicker (as a sign of emotion)

solution: force sensing resistor;

when owner squeezes the Teddy, it vibrates (haptic response)

solution: force sensing resistor, haptic motor (for vibrations);

red eyes, growling sound as negative feedback (when other people interact with it)

solutions: red LEDs (for red eyes), audio amplifier, speaker and micro SD card (for growling sound effect), accelerometer/flex sensor (for motion detection);

ambient lights

solution: LEDs (colorful?), pushbutoon;

ability to talk

solution: IfThisThenThat (allows communication between Siri and Arduino)

ability to sing (as inspired by Furby)

solution: audio amplifier, Micro SD card, speaker;

Possible design

Ideally our final product will be an actual Teddy Bear. In order to connect the Arduino with the Teddy and implement the functionalities we would have to embed the components into the Teddy (for future reference – look into Lilypads and conductive thread). We should focus on making the circuit work before thinking about the final adjustments. However, if we do not have time to use a real Teddy Bear and deliver the circuit alone in the end, we will need to think about a good board layout design and interface which will facilitate usability and thus make our product more successful.

Possible uses

relaxation/soothing after a long day at school/work (for teenagers, adults) – quick, flexible (portable)
therapeutic and calming device for children (e. g. makes them stop crying)
night light for reading/other activities (for teenagers, adults) – flexible (can be placed anywhere), easy to use (the button)
night light for children (or people in general) who are scared of darkness – “The Night Defender”
entertainment – having a laugh with your friends (red eyes and growling) and speaking to it
educational (for children): the Teddy might teach them the alphabet through singing, provide simple quiz games through talking etc.

In order to have a better understanding of how the above mentioned components work and to make a list of components which should be further ordered, we agreed to split them between us and conduct an in-depth research on how they could be used for our project. Thus, this is what we had to individually look into until our next meeting:

Raluca // owner recognition: RFID reader and tags/ facial recognition/ finger print scanner & positive feedback: force sensing resistor

Mark // heartbeat vibrations: haptic motor & motion detection: accelerometer/ flex sensor

Xander // heartbeat (visual and auditive): red LEDs/ 8×8 matrix LEDs, speaker; negative feedback: red LEDs, audio amplifier & ambient lights: more LEDs, pushbutton

Finally, we delegated tasks which we will be responsible for throughout the entire development process to achieve maximum productivity:

Task list

Research – all, as described above
Coding – all, based on our research (mainly, but in general we will work as a group effectively and help each other)
Components ordering – all, based on our research
Ideas – all
Meeting notes – Xander
Pictures/videos – all
Meetings organization – Raluca
Project progress – Mark
Online portfolio – Raluca
Design concepts & interface – all
Prototyping – all
Circuit layout and diagrams – Mark, Xander
Testing – all
Shortcomings comments – Xander
Presentation – all
Sketches – Mark, Raluca
Maker manual – all

Time chart

Meeting with Akram – 23rd of November 2017

Reflections

So far we are on the right track: the functionalities we have identified for the Teddy Bear match its purpose and target audience generally. However, we were advised to reconsider the group of people the Teddy aims at. Designing objects for children can be tricky as they are a more sensible audience. In our case, having the Teddy recognize its owner and react badly to other people might send the wrong message to a child and influence their education in a negative way (i. e. they might develop a strong sense of property and understand that their belongings should never be shared, which could finally lead to exclusion and solitary). At the same time, features like red eyes and growling sounds would undoubtedly scare them (both the owner child, as well as other children e. g. in kindergarten) and therefore make the Teddy an unsuccessful product.

With that said, we agreed to reconsider who we are designing the Teddy Bear for: we will leave children aside for now and focus on teenagers, young adults and mature people. More precisely, we estimate the age of our users to be somewhere between 14 – 50 years old. This allows us to keep our initial goals and design without worrying about any negative outcome – at 14 or above, people are old enough to interpret the negative feedback appropriately and regard them as fun and exciting.

Additionally, we were encouraged to have a realistic mindset while developing the object, understand which features are less and too ambitious and tackle them bearing the time limitation in mind.

Conclusion

Target audience updated: people between 14-50 years old.

Functionalities: Will focus on the less ambitious functionalities for the moment, but keep our options open in the future. The following will be looked into/implemented ONLY if time allows us to, as they are slightly more complex:

ability to talk

ability to sing (as inspired by Furby)

Meeting #2 – 27th of November 2017

We all completed our in-depth research into the allocated design portions (components). Now we understand the context better and are able to re-establish the functionalities we wish to implement, as well as justify our choice of components. Additionally, we know what needs to be ordered and can complete the form provided by the Electronics Lab.

Final functionalities

The Teddy Bear will be able to recognize its owner and react to them accordingly through positive feedback.
Positive feedback includes a beating heart simulation (visual, auditive).
Positive feedback also includes increasing the volume and speed of the heartbeat and providing haptic response when the Teddy Bear is squeezed.
The Teddy Bear can act as a night light (through ambient lights).
The Teddy Bear will react to strangers (other people than owner) through negative feedback.
Negative feedback includes red eyes and growling sound effect.

Ordering the required components as soon as possible was a crucial task, since we needed to consider the shipping time whilst trying to meet the project deadline. This is why we ordered them together during our meeting:

Choice of components

RFID reader and tags (white card and keychain): We chose the RFID reader to implement owner recognition because the level of complexity is kept to a minimum (in comparison to e. g. face recognition). As form of input, users are given a card to access the Teddy’s personal and emotional functionalities. Additionally, this RFID reader comes with two RFID tags, so we are given the flexibility to explore different ways of system activation/deactivation.

8×8 dot matrix: Allows us to create the outline of a pulsing heart (growing and shrinking) more accurately than a simple set of LEDs. It will therefore create a more striking experience for the user.

LEDs and pushbutton: enable us to catch the users’ attention and at the same time engage with them visually. In this context, the light emitted by the LEDs will assisst users in the darkness. The pushbutton is easy to incorporate in a Teddy Bear and easy to use: people will correlate the night light functionality with a lamp (familiarity) and will make correct use of the button.

Haptic controller & motor: We chose to implement vibrations because we wish to engage the user with our Teddy by addressing their sense of touch, as well. The vibrations will create a more realistic heartbeat effect and will give life to the Teddy Bear. They will impact the user emotionally, too: the steady rythm and subtle pulsing sound will soothe the user and induce calm.

Accelerometer: Allows accurate motion detection and facilitates the delivery of negative feedback. Can be easily implemented using the Adafruit LIS3DH library.

Micro SD card: Used to store our sound effects (heartbeat sound and growl).

Audio amplifier: We picked this component because it strengthens low-power and inaudible electronic audio signals to a level that is strong enough to power driving the speaker. It plays a vital role to us, as we want to appeal to users through the hearing sense, too.

Speaker: The speaker helps us play the heartbeat and growl sound effects from the SD card, with the help of the amplifier.

Force sensing resistor: We chose this component to identify if pressure is applied to the Teddy and activate other components as feedback (e. g. haptic effect).

We then moved on to creating a coding plan following the logic of our functionalities. Coding is divided between us based on our previous research areas (mentioned in the Meeting #1 section).

Pseudocode (coding logic)

There are four main components which trigger different parts and actions:

– the RFID reader & tags (positive feedback – heartbeat)

– the force sensing resistor (heartbeat becomes louder and quicker – haptic response begins)

– the accelerometer (negative feedback) and

– the pushbutton (ambient lights).

The RFID reader is our main sensor component because it creates a strong and special connection between the Teddy and its owner.

CASE 1 – OWNER => positive feedback

IF the owner’s RFID tag is READ then owner is RECOGNIZED and POSITIVE FEEDBACK TRIGGERED

8×8 dot matrix: heartbeat visual is ON; speaker: heartbeat sound is ON
IF owner squeezes Teddy => force sensing resistor captures CHANGES IN PRESSURE AND TRIGGERS

a) heartbeat visual QUICKER/SLOWER (on no press)

b) heartbeat audio LOUDER/QUIETER (on no press)

c) vibrations are ON and become MORE OR LESS INTENSE according to the pressure value

3. IF 10 minutes HAVE PASSED, RFID tag value no longer recorded (to be further discussed for design decisions)

ELSE nothing happens

CASE 2 – NO OWNER => negative feedback

IF RFID tag is not READ/RECORDED then

IF Teddy is MOVED accelerometer captures CHANGES IN MOTION AND ACTIVATES

a) red LEDs are HIGH (red eyes)

b) growling sound effect is ON

ELSE nothing happens

ELSE stop red eyes and growling effect, THEN perform the positive feedback above

CASE 3 – ambient lights

[independent of OWNER/NO OWNER situations]

IF button IS PRESSED AND old value of button is LOW

turn ambient lights ON

ELSE turn ambient lights OFF

old value of button = current value of button

Main functions logic

Raluca: RFID reader & force sensing resistor

boolean ownerHere() {

return TRUE if RFID tag is read;

else return FALSE; }

int pressure() {

if force sensing resistor is applied pressure

return the value of the pressure applied; }

Mark: accelerometer, red LEDs for eyes & haptic motor

boolean isMoving() {

return TRUE if accelerometer has reasonable reading (if value is in a certain range);

return FALSE if accelerometer has very low values (if value is in another range); }

void angry(boolean isMoving) {

if Teddy is moved, red LEDs are HIGH;

otherwise, nothing happens; }

void heartbeat(int pressure) {

higher pressure => higher vibrations intensity;

lower pressure => lower vibrations intensity; }

Xander: 8×8 dot matrix, speaker, audio amplifier, micro SD card, LEDs & pushbutton

void heartbeat(int pressure) {

higher pressure => higher volume;

lower pressure => lower volume; }

void heartbeat(int pressure) {

LED array showcasing pulsing heart; }

void nightLight(int button) {

if button HIGH, show ambient light (LEDs HIGH);

if button pressed again, turn off ambient lights (LEDs LOW); }

void angry(boolean isMoving) {

if Teddy is moved, play growling sound;

otherwise, nothing happens; }

Meeting conclusion: While we wait for the components to arrive, we should start testing the logic of our plan by implementing mock-up functions with placeholder components.

In-class exercise: lo-fi prototyping (27th of November 2017)

Today’s in-class exercise required putting the ideas we gathered so far for our project into practice and create our first lo-fi prototype. We drew two storyboards according to the two responses given by the Teddy: positive feedback on owner recognition and negative feedback otherwise. Each frame illustrates the functionalities we previously discussed in a visual manner, facilitating further project development and improvement. Moreover, the exercise included sharing our work with another group and exchanging thoughts.

Storyboard 1 – positive feedback & ambient lights

Storyboard 2 – negative feedback

We found this exercise particularly useful because it enabled us to explore the design aspects of our project in more depth (we mainly focused on the electric circuit and components so far). In both cases, we depict example scenarios of how our Teddy Bear could be used in real life. This helps us identify possible user-interactivity methods, as well as ways in which our product manages to impact the user (how is it meaningful to users and how does it benefit them?). By discussing user-interactivity, we naturally ended up speaking about the design component of the Teddy and its interface. The feedback received from our partner group was also valuable, because they were able to relate more to our target audience and bring in a different perspective.

Here are a few notes we made based on our discussion around these topics:

– the Teddy could be used by anyone aged 14-50 for different reasons;

– one of them is relaxation: after a long and stressful day, the Teddy will make them forget about their worries through its warm and loving reaction;

– the subtle heartbeat and vibration rythms will induce calm and peacefulness and will make the toy more realistic;

– the ambient lights transform the teddy into a flexible and easy-to-use night light (e. g. a lamp is not portable, but our Teddy is);

– they can use it to read a book/complete a task which requires lighting, or simply as a visual aid in case they need to leave their bed during the night (e. g. if they live with other people, switching on the lights might bother the rest of the house);

– some people are afraid of darkness;

– having a Teddy which recognizes its owner can be fun and meaningful to the user;

– RFID card and keychain are portable and can be stored in reachable places (e. g. wallet, pocket);

– the red eyes and growls exposed to strangers make the toy more realistic and enhance the overall user experience.

Design thinking – where do we put the components and how do we hide the “technical” part from the user?

Design plays a crucial role when it comes to creating an object because it defines the object-user relationship which leads to a successful product. Our lo-fi prototype presents scenarios where we use a real Teddy Bear for our final interactive object. If we have the opportunity to do this in the future, we need to think about effective design decisions of integrating the circuit into the Teddy. We believe a good design will have no hidden or invisible affordances, will not confuse or irritate the user, impede them in any way, will have an intuitive and easy-to-use/learn interface and, most importantly, will offer them a unique, pleasant and problem-free experience. A good design will also follow Norman’s (Design of Everyday Things) core principles: usability, utility and experience. And this is what we wish to accomplish for our product, too.

With that said, here are some of our design ideas so far (considering our final delivery will use a real Teddy Bear toy):

red eyes: the red LEDs can serve as eyes which light up on negative feedback;
heartbeat: 8×8 dot matrix embedded into the chest;
force sensing resistor can be located inside the belly: users will squeeze the Teddy and it will naturally trigger the haptic response and make the heartbeat louder and quicker;
RFID reader can be embedded into the arm or the chest;
users can scan the white card/keychain to “log-in” (to be recognized) and the card value will be registered for 10 minutes;

Not necessarily convenient: it limits the users with time and does not give them the choice to enjoy the positive feedback as much as they want. Might be better to come up with a design, so that the card is constantly read by the RFID reader without any effort required from the user (e. g. embed the RFID reader into the chest and create a pocket outside to fit the card – this way users can decide when they wish to start and stop the owner recognition functionalities).

accelerometer, audio amplifier, speaker and SD card can be sewn into the back using the Arduino Lilypad and conductive thread (users do not have any direct contact with these components);
ambient lights: (white? blue?) LEDs attached at the back of the head (because users are more exposed to the front side of the Teddy and LEDs might disturb their vision);
the pushbutton: inside the hand, which could have a “Squeeze me” label on it (making the functionality obviously visible).

Mock-up functions & testing (3rd of December 2017)

Testing (hypothetically): RFID reader, accelerometer, force sensing resistor (analog inputs) & ambient lights

We chose the potentiometer as placeholder (analog sensor). The logic behind the analog input testing is to define two ranges, read in the input value, check the range it belongs to and perform an action according to the range (e. g. display TRUE or FALSE). For example, in the following case, if the potentiometer input value is between 0 and 512, the Serial Monitor will display the value TRUE. Otherwise, the Serial Monitor will display the value FALSE.

int sensorPin = A0; // select the input pin for the potentiometer 
int sensorValue = 0; // variable to store the value coming from the sensor
int under=0; //checks if sensorValue variable is over or under 512

void setup() {
 //set up the Serial Monitor
 Serial.begin(9600);
}

void loop() {
 //check the range of the sensorValue and display true/false accordingly
 checkRange();
 printToSerial();
}

void checkRange () {
//read in the analog input from the potentiometer
sensorValue = analogRead(sensorPin);

 if((sensorValue >= 0) && (sensorValue <= 512)) //checks if it's under 512
 { 
 under=1; //it is under 512
 }
 else {
 under=0;
 }
}

void printToSerial() {
 //if it is under 512
 if (under==1){
 Serial.println("True"); //print TRUE to the Serial Monitor
 } else {
 Serial.println("False"); //print FALSE to the Serial Monitor
 }
}

After testing this basic principle, we wanted to see a more high-fidelity representation of what we aim to achieve in the end (when we receive the components). Thus, we added an LED to the circuit providing visual feedback while the potentiometer knob is twisted.

int sensorPin = A0; // select the input pin for the potentiometer 
int sensorValue = 0; // variable to store the value coming from the sensor
int ledPin = 13; // LED pin number
int under=0; //checks if sensorValue variable is over or under 512

void setup() {
 // declare the ledPin as an OUTPUT and set up the Serial Monitor
 Serial.begin(9600);
 pinMode(ledPin, OUTPUT);
}

void loop() {
 //check the range of the sensorValue and display true/false accordingly
 checkRange();
 ledEvent();
}

void checkRange () {
//read in the analog input from the potentiometer
sensorValue = analogRead(sensorPin);

if((sensorValue >= 0) && (sensorValue <= 512)) //if it's under 512
 { 
 under=1; //it is under 512
 }
 else {
 under=0;
 }
}

void ledEvent() {
 //if it is under 512
 if (under==1){
 Serial.println("True"); //print TRUE to the Serial Monitor
 digitalWrite(ledPin, HIGH); //turn on LED
 } else {
 Serial.println("False"); //print FALSE to the Serial Monitor
 digitalWrite(ledPin, LOW); //turn off LED
 }
}

Although we’re not using boolean functions here (according to the main functions from the coding plan), we use an int variable under which toggles between 0 and 1 and acts almost like a boolean (where 0=FALSE and 1=TRUE). The result above is similar to the result we expect to obtain using the RFID reader, accelerometer and force sensing resistor. If the input value is within a range of values, then something happens (e. g. red eyes, louder heartbeat etc.) – otherwise, nothing happens.

Note: This example can also demonstrate the red eyes feedback (except we would need 2 LEDs for 2 eyes and programming tweaks to make the 2 LEDs switch on/off at the same time).

Design modification for ambient lights: We took the interface into consideration and imagined a real use-case scenario. What if people would like to adjust the brightness of the ambient lights (e. g. some people might want a lower brightness when sleeping; others might want a stronger brightness for reading)? In this case, a potentiometer would be more useful than a pushbutton, which does not allow any variation in brightness. Therefore, we will use a potentiometer to control the ambient lights.

Components have arrived! Time for testing (8th of December 2017)

(table with components that need to be tested)

Meeting #3 – 8th of December 2017

In order to reduce the number of shortcomings, we decided to test each part individually, then assemble them one by one and build and test lo-fi prototypes as we advanced.

Today we will test the following components:

force sensing resistor
RFID reader + tags (white card and keychain)
accelerometer
haptic controller & motor

For each component, we tested the range checking principle that we demonstrated last week using a potentiometer (respectively an LED).

Force sensing resistor

Notes: We assembled the circuit and tested whether the analog input was received or not using the Serial Monitor. In order to identify the correct checking range for this component, we tested different pressures and observed the values obtained. The results were the following:

light press: values between 400-500;
medium press: values between 200-400;
hard press: values between 0-200;
=> NO PRESS: values between 500 –

Therefore, our two ranges are [0, 500] and [500, 1024], where [0, 500] means pressure applied (=> something should happen) and [500, 1024] means no pressure (=> nothing happens). We tested these ranges by using the Serial Monitor and printing TRUE if the resistor is pressed and FALSE otherwise.

Shortcomings: We did not assemble the circuit properly in the beginning. The Serial Monitor was continuously displaying the value “1023”.

Reference: https://learn.adafruit.com/force-sensitive-resistor-fsr/using-an-fsr

RFID reader + tags (white card and keychain)

Notes: We first tested the cards individually to check if the reader captures input, as well as to discover the unique codes for the white RFID tag and the keychain. We achieved this by using the RFID master library and analyzing online RFID reader implementation examples. This was successful, so we moved on to adding an LED to the board and writing appropriate code to switch it on when the white card is read and switch it off when the keychain is read. This is a good start for us, because switching an LED on/off can be easily replaced with other functionalities. The main concept works and this is what matters most for now.

Shortcomings: No shortcomings – worked from first upload!

Additional notes: RFID reader needs soldering. We have also made a design modification which we believe will benefit the user more.

If we decide to use a real Teddy Bear in the end: As mentioned before, we can embed the RFID reader into the chest and create a pocket outside to fit the card and give users the liberty to choose their own usability time. Alternatively, we can attach a string to the card and turn it into a necklace which can be easily added or removed.

(sketch)

If we present the product as a circuit: We can use both the white card and the keychain to “log-in” and “log-out” of the system. White card would provide access and keychain would stop functionalities (apart from the ambient lights, which are independent).

In both cases we show that we take our audience and their experience into consideration, as well (and not focus on the circuit design and layout alone).

Reference: https://www.youtube.com/watch?v=KQiVLEhzzV0

Accelerometer

Shortcomings: We tested the accelerometer using using Adafruit’s LIS3DH library and implementation guide.Test was unsuccessful because The accelerometer needs soldering. Accelerometer could not detect any change in motion (although there was). This is what we were returned on testing:

Notes: We will solder it, then retake the test.

Haptic controller and motor

Shortcomings: Could not be tested at all because it required soldering first (same situation as accelerometer).

Notes: We will solder it, then retake the test.

Meeting conclusion: Some parts require soldering. We also need to get a bigger breadboard from the Electronics Lab as we will start expanding the circuit soon.

Meeting #4: More testing + second lo-fi prototype (11th of December 2017)

All components that required soldering have been soldered together (using the Electronic’s Lab equipment). Some tests proved unsuccessful before (accelerometer and haptic controller & motor), so we tested them again. In addition, we tested the audio aspect of the circuit: the Micro SD card with shield, speaker and amplifier.

Accelerometer

Notes: Once again, the test was unsuccessful (see shortcomings). Once we sorted out the issue, the Serial Monitor finally started displaying the analog values. These would change according to the movement of the breadboard with the accelerometer. Similarly to the force sensing resistor, in order to check whether the Teddy has been moved or not, we need to define ranges and a variable of type boolean (or int, switching between 0 and 1). This should be further investigated as it is a more complex case: the accelerometer has the X, Y, Z coordinates changing, so the number of ranges will be higher.

Shortcomings: Accelerometer did not work at first (could not start at all, like previously tested). The issue proved to be a pin which was not soldered properly.

Reference: https://cdn-learn.adafruit.com/downloads/pdf/adafruit-lis3dh-triple-axis-accelerometer-breakout.pdf

Haptic controller and motor

Notes: We tested the haptic controller and motor using the Adafruit DRV2605 library and implementation guide. Test was a success: the motor vibrates according to our input value (the digital value we assign through code). The Serial Monitor was used to double-check whether the correct value is output. We also played around with different values to have a better understanding of the component behaviour.

Shortcomings: No shortcomings – worked from first upload!

Additional notes: DESIGN CHANGE – We thought that having a haptic response and a hearbeat visual and audio working simultaneously would create a more realistic heartbeat representation. This is why we made the following design modification:

IF the RFID tag is read

user receives positive feedback: haptic response, heartbeat audio and visual

IF the force sensing resistor is pressed

– heartbeat beats quicker/slower and heartbeat sound gets louder/quieter (unchanged)

– vibrations intensify (when force sensing resistor is not pressed, the vibrations will be very subtle)

Reference: https://learn.adafruit.com/adafruit-drv2605-haptic-controller-breakout/wiring-and-test

Micro SD Card, audio amplifier & speaker

Notes: The first component we tested in this context was the speaker. We have used such a component before in the lab, so we were able to test it without issues. We uploaded a soundtrack (for test only) on the micro SD card, assembled the SD card Shield, the SD card (inside it, as presented above) and the audio amplifier and checked whether the soundtrack was played by the speaker. We did this using the Arduino SD library and following this online example: https://circuitdigest.com/microcontroller-projects/arduino-audio-music-player

The result was positive.

We uploaded a heartbeat and a growling sound effects to the SD card, and once again conducted testing. The growling effect worked perfectly; the heartbeat sound worked, too, although the quality of the speaker and the low frequencies determined a very low quality display of sound. As we want to deliver quality only, we decided to exclude the heartbeat sound from our plan. Nevertheless, the haptic motor was making a subtle pumping noise while vibrating, which creates the auditive impression of a real heartbeat alone, so we thought that a heartbeat sound effect would overwhelm the user.

Additional notes: The two pushbuttons do not have a specific role in our circuit: they are used to shuffle through the SD card and play the corresponding soundtrack, but it does not require this feature.

Reference: https://circuitdigest.com/microcontroller-projects/arduino-audio-music-player

Shortcomings: Everything worked from first upload! Only problem is the heartbeat sound effect mentioned above.

Second lo-fi prototype

After testing and playing around with all components we were unfamiliar with (i. e. not LEDs, potentiometers, pushbuttons etc.), we decided to start working on the actual circuit. The first combination we tested is the RFID reader + accelerometer + force sensing resistor + haptic controller & motor. Naturally, we added the usual LED for visual feedback.

The test logic is the following:

IF RFID reader receives input from the tag (we choose the white card)

haptic motor starts to vibrate

IF resistor is pressed

vibrations intensify

IF accelerometer detects any change in motion

LED is HIGH (for now, a placeholder for the red eyes)

Firstly, we re-tested each component individually (but in the same circuit environment) to check their reaction within a more complex circuit. The force sensing resistor and the haptic controller & motor presented no issues (tested using both the Serial Monitor and the LED for instant visual feedback). The accelerometer worked, too (tested using the LED), although we have not discovered the ranges covering the change in motion yet. The RFID reader test failed and the cause is still unknown (to be investigated).

We agreed to focus on the successful components (force resistor, haptic controller and motor and LED) for now and combine their code to check whether they work together.

What we are testing:

IF resistor is pressed

vibrations intensify and LED is HIGH

ELSE LED is LOW and vibrations stabilize (become subtle)

Result: Success! (watch the video below)

Additional notes: DESIGN CHANGE – after several haptic controller and motor tests, we observed that the change in intensity (when force resistor is pressed) is not that obvious and the difference between intensities feels low. This is why we chose to experiment with speed instead, which proved to provide users with more consistent feedback (as demonstrated in the video, too). In order to do this, we call the delay() function after the haptic function when the force resistor is not pressed. For now this is good enough for testing, because it delivers the wanted result, but delay() can be problematic later. It stops the entire programme and thus affects the other components of the circuit (e. g. speaker playing sounds), so in the future we will try to implement a time interval instead.

Components that have yet to be tested:

8×8 dot matrix pulsing heartbeat (positive feedback)

ambient lights with potentiometer

Need further investigations:

RFID reader problems
accelerometer ranges
replacement for delay function

Other issues + reflections

As we started assembling the circuit and adding more components to the board, we identified an issue which we did not consider while we were planning the project goals and functionalities: we might not have enough digital pins to use all required components and to fully complete the project.

For our possible solution, we thought that instead of using the dot matrix for the heartbeat, the eyes and the ambient lights, we might be able to use one red (pulsing) LED for the heartbeat (but still set up the dot matrix heartbeat separately to demonstrate that we can implement it), one LED for the ambient lights (as a prototype example of the actual functionality) and remove the eyes completely (but demonstrate them separately for reference and keep the growling sound for negative feedback).

Reflections 1: Doubts about the negative feedback aspect

For a while now we started having second thoughts on the negative aspect feedback. As established at the beginning of the project, the red eyes and growling sounds would scare children and would communicate them the wrong message about human interaction and relationships. This means that we stopped considering the children part of our target audience. However, we think that the accessibility aspect of the product is as important as the functionality itself. Having the Teddy Bear react badly to strangers might be fun, but since it limits the target audience as discussed, should we still consider it a useful functionality? A successful product should be designed as universally as possible. The object is also a therapeutic and relaxing toy, which would benefit children most, we believe. Even the ambient lights, which are in fact an extra functionality and propose a secondary goal (more practical), can be useful for children (making the Teddy Bear a Night Defender who guides them through darkness or simply catching children’s attention and help them develop their visual capabilities – because LEDs are shiny and pretty!).

With that said, we concluded that the best design choice for our project would be to eliminate the negative feedback case and add a different functionality instead, which would make more sense for users: have the teddy say a warm greeting when the card/s is/are tapped on the RFID reader. This would be achieved using the speaker, SD card and audio amplifier. The accelerometer was the component triggering the negative feedback which we agreed to exclude, so the accelerometer will not be used anymore from now on. The red eyes and the growling sound are dismissed, too.

Here is our new design plan:

-RFID reader and tags for owner recognition;

-white card triggers warm and loving behaviour;

-after white card is read, Teddy greets owner (emotional response);

-behaviour includes a heartbeat representation through an LED, and subtle haptic effect;

-if the force resistor is pressed, the LED blinks faster and the haptic motor vibrates quicker; otherwise remain unchanged;

-if owner decides to stop using the Teddy, it will greet them again (emotional response);

-users can control the brightness of the lights (represented by one LED) using the potentiometer.

With this new plan, we welcome children back into our target audience.

Meeting #5 – 13th of December 2017

RFID reader and tags

Our main priority now was to make the RFID reader function again. On closer look, we realized that the reader’s red light (indicating “on”) was only partly on and had a very low brightness, meaning it was not properly connected to the board. The problem proved to be the soldering (we did not test the RFID reader again after soldering it). After soldering it again carefully, we re-assembled it to the circuit. The red light turned on properly now and the reader was ready for an individual test.

We tested the RFID reader by tapping the two RFID tags and checking for any received input (the two unique codes for the tags) using the Serial Monitor. The test was successful. We then improved this code by adding the if/else statements to verify the tags read and assign them different feedback:

if the white card is read -> do something
if the keychain is read -> stop everything (log-out)

To simplify our work and minimize the number of shortcomings, we tested this first using the Serial Monitor:

Then we combined everything together by replacing the “do stuff” and “don’t do stuff” text with the appropriate code at the appropriate location (haptic controller and motor, force resistor and red LED). Once again, the result was positive, with no shortcomings.

After achieving this improvement, we adjusted the code to make it more efficient. As previously discussed, we found a different way of slowing down the heartbeat vibrations when the force resistor recorded no pressure. Instead of using the delay() function, which mainly affects the entire program, we implemented a set of if/else statements to simulate a delay in vibrations. This helped us further improve the quality of the code and of the circuit overall (our replacement for delay() does not affect e. g. the red LED).

Ambient lights

Notes: The ambient lights (represented by one LED) were probably the easiest component that required testing. This is mainly because we have worked with LEDs and potentiometers in the lab before, which allowed us to leave it towards the end of the project.

Shortcomings: The LED was not iterating through brightnesses in the beginning, because we did not use the for loop properly.

Lastly, we added the speaker, SD card and audio amplifier to the circuit to make the Teddy greet the user on log-in and log-out. Although these components worked when tested separately (you can find the video above), they did not work when integrated in the circuit. We searched both our code and circuit for issues and made some modifications, but nothing seemed to work. The real problem, however, proved to be the libraries used for the RFID reader and the speaker. The libraries include predefined pins and some of them were used by both of them (e. g. both the RFID reader and the speaker used pin 9 as imposed by their library). We tried looking through the documents and change them, however this was a challenging task which we could not figure out in the end.

This is why we decided to make another design modification, and remove the speaker, SD card and audio amplifier from the circuit, alongside the greeting functionality.

Interface

Reflections: Interface

Now that we are approaching the end of the project, the idea of embedding the final circuit into an actual Teddy seems very unlikely. We will present a lo-fi prototype of our circuit, so we need to think about the circuit interface and how users would interact with it (despite it not being the final Teddy). Even if it is just a circuit (which makes fulfilling the experience design principle difficult), we still need to find ways to deliver an intuitive, easy-to-use and appealing interface which effectively hints the responsive design of the product.

Ideas: We can assemble related components (e. g. the ambient light and the potentiometer) next to each other, so users can naturally map them as a packaged functionality. We can also use labels to indicate usability of components (using adesive paper?). For example, we can have a small arrow on the potentiometer, showing the direction which turns the LED on, a small heart on the heartbeat LED and a “Squeeze me” text which indicated squeezing (feedback will be visible afterwards). Moreover, we can have a sample Teddy Bear toy at the presentation to enhance it and make it more visually striking and meaningful.

For the RFID white card and keychain (we are not using a Teddy Bear, so we will use the two RFID tags for triggering and stopping activities): they are light, portable and can be carried in pockets, wallets, bags etc. which is a pro. However, there is he risk that some people might confuse the Teddy card/s with their house keys. For example, Mark’s house key is a white, very similar to the RFID white card. This can not only cause confusion, but also frustration and an unpleasant experience. Also, we (as designers) know which card provides access and which stops the Teddy Bear features, but would our users know unless we shows them?

Idea: We can label the tags, too: keychain can have a “log-out” minimal Teddy Bear icon with an arrow indicating “down” (“log-out”) and the white card can have a “log-in” version of the same icon, with an arrow indicating “up”.

Ambient lights colour choice: We chose the colour blue for the ambient lights because blue is a calming and relaxing colour itself which does not tire the eyes.

!TO-DO LIST!

buy a Teddy Bear for presentation;
adesive paper for labels.

Presentation day

Before finalizing our project and proceed with our presentation, we were required to make a few final tweaks.

First of all, we thought that once we have removed the audio from our circuit, not having enough digital pins was not a problem anymore. This allowed us to implement a more accurate heartbeat with the 8×8 dot matrix and get rid of the red LED (used as a representative). Thus, we assembled and tested the dot matrix by drawing a pumping (shrinking and growing) heart using the lights.

Shortcomings: There were no shortcomings – worked from the first upload!

Now we have reached the final stage of our circuit. We added the ambient light with potentiometer and the 8×8 dot matrix and conducted further tests. We also adjusted the dot matrix code to make the heart pulse faster when the force resistor is pressed. The process ran smoothly with no shortcomings and enabled us to finish the circuitry part of the project. Here is some content demonstrating our final working prototype:

In terms of interface and presentation, we labeled the two RFID tags, as well as other less intuitive components to offer users clues about the functionalities of the product. We also bought a Teddy Bear toy to make our presentation more visual.

Finally, this is our final object, as shown in the presentation, too:

Makers Manual

Getting Started

These instructions will get you a copy of the project up and running on your local machine for development and testing purposes. See deployment for notes on how to deploy the project on a live system.

Prerequisites

For this Arduino project you will need to instal the following libraries:

Adafruit DRV2605
RFID-Master

To install these libraries copy and paste the folders into the following folders Arduino/libraries/
then re-start the Arduino editor.

Installing

For your development environment you will need an Arduino code editor, we suggest the official Arduino IDE from www.arduino.cc/en/Main/Software.

Deployment

Please follow and build the included diagram using the below components. Once this is completed you will need to download the repository and install all the required libraries included in the Prerequisites section above. Open the masterTed-master file and upload to your Arduino.

The included code is fully commented to help you change and add functionality.

Please note that the 8×8 matrix from our project used two shift registers but the above diagram displays the 8×8 matrix with an interface that includes theses components.

Enjoy your time with masterTed.

Built With

* 1 x Arduino Uno
* 1 x LED
* 1 x DRV2605L Haptic Controller
* 1 x Vibration Motor
* 1 x RFID-RC522 RFID Reader
* 1 x Force sensing resistor
* 1 8×8 hRed Dotmatrix
* 2 x 74HC595 Shift registers
* 1 x Large breadboard

Code

//include the following libraries
 #include <SPI.h>
 #include <MFRC522.h>
 #include <Servo.h>
 #include <Wire.h>
 #include "Adafruit_DRV2605.h"

// Define RFID reader pins
 #define SS_PIN 10
 #define RST_PIN 9

Adafruit_DRV2605 drv;
 MFRC522 mfrc522(SS_PIN, RST_PIN); // Create MFRC522 instance.

//Initalise all other variables
 int sensorPin = A0; // Force sensor
 int sensorValue = 0; // Value of force
 bool logStatus = false; // Login RFID status
 unsigned long previousMillis = 0; //Timer revious time
 long interval = 1000; //Set interval default

//Ambient Light variables
 int potentPin = A1; // select the input pin for the potentiometer
 int ambientPin = 3; // select the pin for the LED
 int lightLevel = 0; // intial light level

//Heart light variable
 int data = 6;
 int clock = 5;
 int latch = 4;

int bigHeart[] = {B01100110, B10011001, B10000001, B10000001, B10000001, B01000010, B00100100, B00011000}; //Bit regitstry for big heart display
 int littleHeart[] = {B00000000, B00100100, B01011010, B01000010, B01000010, B00100100, B00011000, B00000000}; // Same for small heart
 int nothing[] = {0,0,0,0,0,0,0,0}; // Empty state

void ambient();
 void show(int[]);

void setup()
 {
 Serial.begin(9600); // Initiate a serial communication
 SPI.begin(); // Initiate SPI bus
 mfrc522.PCD_Init(); // Initiate MFRC522
 Serial.println("Put your card to the reader...");
 Serial.println();
 pinMode(ambientPin, OUTPUT);
 pinMode(data, OUTPUT);
 pinMode(clock, OUTPUT);
 pinMode(latch, OUTPUT);

drv.begin();

drv.selectLibrary(1);

// I2C trigger by sending 'go' command
 // default, internal trigger when sending GO command
 drv.setMode(DRV2605_MODE_INTTRIG);
 show(nothing);
 }

uint8_t effect = 46;

void loop()
 {
 // Look for new cards
 if ( ! mfrc522.PICC_IsNewCardPresent())
 {
 // If logged it do this
 if(logStatus == true){

//turn off ambient light
 analogWrite(ambientPin, 0);
 //Read the force value
 sensorValue = analogRead(sensorPin);
 // get current elapsed time
 unsigned long currentMillis = millis();
 //if the force is between 0 and 512 then interval = 500, else interval = 250;
 if((sensorValue >= 0) && (sensorValue <= 512)) //if it's under 512
 {
 interval = 500;
 }
 else {
 interval = 250;
 }
 //if the current time minus the previous time is more that the interval set
 if (currentMillis - previousMillis >= interval){
 //update previous mill
 previousMillis = currentMillis;

// set the effect to play
 drv.setWaveform(0, effect); // play effect
 drv.setWaveform(1, 0); // end waveform

// play the effect!
 drv.go();
 //Scan through matrix and draw heart (small)
 for( int k = 0; k < interval; k++){
 show(littleHeart);
 }
 drv.go();
 //Scan through matrix and draw heart (large)
 for( int k = 0; k < interval; k++){
 show(bigHeart);
 }
 show(nothing);
 }
 } else {
 // if not logged in allow ambient light control
 ambient();
 }
 return;
 }
 // Select one of the cards
 if ( ! mfrc522.PICC_ReadCardSerial())
 {
 return;
 }
 //Show UID on serial monitor
 String content= "";
 byte letter;
 for (byte i = 0; i < mfrc522.uid.size; i++)
 {
 content.concat(String(mfrc522.uid.uidByte[i] < 0x10 ? " 0" : " "));
 content.concat(String(mfrc522.uid.uidByte[i], HEX));
 }
 content.toUpperCase();
 if (content.substring(1) == "E2 BC 84 59") //change here the UID of the card/cards that you want to give access
 {
 Serial.println("Log In");
 logStatus = true;
 }

else {
 Serial.println("Log out");
 logStatus = false;
 }
 Serial.println("Ambient Light");
 }

void ambient() {
 //Read the lightlevel
 int lightLevel = analogRead(potentPin);
 //adjust the value 0 to 900 to span 0 to 255
 lightLevel = map(lightLevel, 0, 900, 0, 255);
 //make sure the value is betwween 0 and 255
 lightLevel = constrain(lightLevel, 0, 255);
 //write the value
 analogWrite(ambientPin, lightLevel);
 }

void show(int red []){
 for (int i=0;i<8;i++){
 digitalWrite(latch, LOW);
 shiftOut(data, clock, MSBFIRST, ~(1<<i));
 shiftOut(data, clock, LSBFIRST, red[i]);
 digitalWrite(latch, HIGH);
 }
 }

Authors

* Mark Brown – github.com/mmmarkyb
* Raluca Semenescu
* Alexander Moran

License

This project is licensed under the MIT License – see the [LICENSE.md](LICENSE.md) file for details

Group 7: Track Your Action

Group 2: Enviro Loving Umbrella