–    Extreme Sports Jacket   –

Project description and aim

It is often inconvenient and unsafe to use smart devices when doing more extreme forms of sport such as skiing, ski diving or rock climbing. In these situations sometimes all the user can afford is a quick glance to check their speed or altitude. This can be the difference between win and loose or life and death. By designing a wearable LCD implemented into the forearm of a jacket, we aim to display data in a clear, easy to read manner not only for the user but for others to compare against. The jackets size allows us near unlimited freedom in terms of adding sensors and without the confines of a small smartwatch screen, we are able to allow the user to see data at a glance.

Our prototype jacket includes a 2.8″ LCD screen on the forearm and a GPS module attached at the chest between the inner and outer layers of the jacket. It displays GPS data in real time, including:

– Time and Date
– Latitude and Longitude
– Speed
– Altitude

 

Project Brief

Loads of different companies provide a variety of fitness trackers and other gear for people to find out more information about their bodies and habits (the “quantified self”). Most of these devices allow us to collect data and visualise it using spreadsheets and graphs. This project will aim to build a wearable with a difference; its primary focus will be to display the users’ health data on a wearable (t-shirt, bag, wristband) for all to see.

 

Time management & planning

To complete the task successfully within the allotted timeframe it was imperative that we worked to a time plan. We began by outlying the major tasks we needed to complete the project and gave them individual deadlines to remain on-track. we have chosen to visualise this in a Gantt chart.

Most tasks required input from the group as a whole, whilst others were assigned to a single member of the group depending on their knowledge and expertise. Subsequent meetings would allow the group to discuss and provide opinions and advice.

A complete list of tasks performed include:

• Meeting to outline product aim and brainstorm – All members helping to form the initial ideas and give us a starting point to know what to research.
• Outlying possible sensors and components – All members need to focus on what ideas are possible and what sensors are needed to meet the functionality requirements of the product.
• Researching market trends – Can be performed individually to understand design choices and limitations of previous products as well as trends in the market to understand what users want and need.
• Researching components – Can be done individually to find out what components can be used within the jacket.
• Buying components – researching the best and most reliable sources of components and logging expenses.
• Prototyping and testing the code with Arduino components
• Prototyping physical product
• Updating Blog
• Logging process with pictures
• Forming the Maker Manual
• Constructing the final product
• Performing final tests and adjustments
• Final product photos
• Writing presentation

 

 

–  Design Blog  –

This blog should be updated throughout the duration of the project. It should describe and explain all design decisions, steps and methods applied to reach the final solution. You need to discuss the interactive design principles applied and also the choices made in user interface and hardware components used. Ensure you cover both your successes and your failures. This blog should include pictures and videos of major milestone/prototypes.

Brainstorming Session – 19th Nov 2018

In our very first group meeting, we started jotting down ideas. We did a market research to see the current technologies on wearables, and started to look out for a possible gap we could fill with our product.

 

Health data options:

• Heart rate
• Walking distance
• Location
• Speed
• Altitude
• Happiness rating
• Reaction to music genre
• Body temperature
• Outside temperature
• Humidity

Initial designs – 20th Nov

From our brainstorming session, we devised some possible devices which we then evaluated against the brief therefore discarding the ideas that were unrealistic or did not meet the brief requirements.

Headphones:

We discussed an idea that involved headphones with a screen on the side to display a face that reacted to various data inputs such as walking distance, and the type of music the user was listening too. we eventually dropped the idea since the user would not be able to see the data themselves and with the equipment available to us the headphones may become too heavy on one side.

Muscle tension wearable:

Another idea we had was a full body suit that has elastic bands that wrapped around the major muscle groups such as the biceps and thighs. the bands would have a resistive material that changed resistance when elongated. this change in resistance would be picked up on the Arduino board and visualised on a LCD screen to display how much the user uses different parts of the body throughout the day. We eventually dropped this idea since it might be too intrusive to use regularly and would require a memory chip to store the data over time.

Location Heatmap device:

We discussed an idea that used GPS data to visualise the frequency of visits to locations on a map, this would encourage users to visit more locations and visualise their routines. we would have a face on the LCD screen as well that got happier the more you explored an area.  We did not choose this idea since it would be more accurate and effective to have on your phone instead and did not fit the brief entirely.

Finalising idea – 21st Nov

After some more research, we found out that one of the newest technologies on wearables was this smart jacket made by Google and Levi’s. However, this is designed for everyday use. Our idea was to design a smart jacket for extreme sports.

Final choice:

We decided on a wearable real-time display on the sleeve of a jacket. This would allow the user to see information about their location, speed and altitude through the use of GPS module. since wearables are already in market, such as the Apple iWatch. We decided to focus our target market on more extreme sports where you were not able to see a smartwatch since it is under your jacket and too small to see whlist on the go. Implementing an LCD into the jacket meant that we could increase the screen size and make it easier for users to see information.

 

Initial Display Testing – 22nd Nov

After collecting the 1.8″ display from the Electronics Lab, we set it up.
We started by wiring it to a small breadboard. However, the display gave us problems: it kept disconnecting.
We then tried to plug it into a bigger breadboard: same problem.
Eventually, we opted to order a 2.8″ TFT/LCD shield instead (bigger, more appropriate for our purposes).

 

 

 

 

 

 

 

 

LCD UI initial design – 27th Nov

Worked on a first draft of the data visualisation for our LCD display.
The screen is 2.8” and supposedly our users will be wearing gloves, hence why we tried to make the buttons as big as possible and the UI very minimal; at a glance, the users should be able to get all the information they need.

We will have a main menu with two icons/buttons. One will redirect to a screen with GPS information, the other one to a screen with user info, such as steps take, speed, temperature.

There will be a “Home” button on both screens, to go back to the main selection.

The first screen (running man) will include some or all this information:

• Steps taken
• Heart rate
• Current speed
• Outside temperature

Users will be able to change the units of measure (e.g. from C to F) by clicking on the specific icon or measurement.

 

The second screen (placeholder icon) will include this information:

• Current time (UTC)
• Current date (UTC)
• Position – Lat and Long.

Note the switch to a bigger “Home” button.

And further development of those:

These included multiple screens with the possibility to choose between different sports.

Testing LCD – 30th Nov

Collected the LCD from the electronics lab and started experimenting with it, trying to familiarise with the TFT library. In the process we tried different sketches to test the functionalities we needed:

• Created one sketch to print strings on the screen.
• Another one to upload .bmp images; this led to the realisation that we cannot use icons in our UI.
• Another sketch to test touchscreen functionalities and the possibility to create buttons.

 

Developing LCD Code – 1st Dec

We spent the entire day developing the code for the LCD. After the initial setup and various tests, we started developing the UI previously designed. However, changes had to be made.

The first change was made after realising that we cannot use icons. We will just be using text instead. Moreover, we will not have 4 information (e.g. date, time, latitude and longitude) all in one screen. We will display one information at a time, but bigger for better readability.

To navigate through the various information, we developed a code that enables gestures (swipe left and right) to change between screens.
The initial division between different two main categories is still in place, but it might be changed later on.

What is missing now is taking the output of the sensors, modifying/mapping it as necessary and then print it on the right screen via the existing code.

As the shield covers all the pins, we will need some extra wiring to be able to read in values from the GPS sensor, the temperature sensor and any other module we will attach.

Developing GPS Code – 4th Dec

Collected the GPS module and spent a couple of hours setting it up, exploring the library and getting everything up and running. It was not easy to understand how the GPS module works, and why it was not transmitting any data. Problem at the end was both satellite fixation, pin and baud.

 

GPS & LCD Code integration – 5^th Dec

Spent the whole day trying to integrate the GPS data with the LCD. There were many blocking problems, mostly due to the refresh method we were using for the LCD.
Dropped the gesture code in favour of:
Clicking on the left side of the screen will go left, clicking on the right will go right. This is way more precise than the swipe.
To temporarily fix the refresh problem (it takes 2-3 seconds to refresh, and when refreshing, you can’t change screens) we are now refreshing the data manually by clicking in the middle of the screen.

GPS & LCD wiring and general testing– 7^th Dec

Spent an afternoon in the electronics lab. We wired everything and tested out the code. Of course, modifications had to be made. The main one, in the loop() which now wait for the serial to be available and some more assertions on GPS signal correctly encoded and available.

We also tested it outside.

Shortcomings found during this session: the GPS receiver is not too strong, hence we need to be next to a window to fetch GPS data. Later in the afternoon, we finally overcame the problem of screen refresh rate (with a decent solution for a prototype, with room for improvement for an eventual finished product)

 

Video of this prototype: https://drive.google.com/file/d/1ONF3uuXvZcS4lCIuBhp2g0jB9ejr5-LD

LCD data visualisation code development– 9^th Dec

Tried to implement an additional screen to the ones we already have (Time, Date, Lat & Long, Speed, Altitude). The idea was to track the speed and display it. It was quite tough to test, as we couldn’t run around with it, and the speed the GPS was sending while sitting in one place fluctuated from 0.01 to 0.5 km/h. We still managed to jot down a simple visualisation. However, we will unsure whether or not we’ll include this in the final prototype.
In the picture, you can see the first version and the one with refined mapping.

Video of this prototype:https://drive.google.com/file/d/1GfUUk3aAmTIu9HRRN5HJVIQ_1P_GIcdn

Modifying the jacket – 10th Dec

Once we were certain the LCD screen code was up to a standard we were happy with and testing had been conducted, we were then able to implement it into the jacket itself. This process is explained in more detail in the maker manual section.

Testing final product – 11th Dec

We tested the final product outside to see if the components were working fine after putting them in the jacket. We conducted speed tests while walking, jogging and being stationary and altitude tests by walking upstairs. upon testing, we found that the GPS module would sometimes short circuit when moving in the jacket so this required us to go back and solder the wires again making sure they were insulated and were not touching one another.

– Makers’ Manual –

Final Product:

Marketing Video: https://drive.google.com/file/d/1pLTSsWBs3APco3oYMGRor_Oriw7lKweH

Our extreme sports jacket takes data such as speed altitude and location and displays in clearly on a large screen for the user to see whilst performing extreme sports.

 

Components:

• Arduino Uno board
• LCD screen
• GPS module
• 9V battery
• 0.5m wires X2 for battery
• 0.5m wires X3 for GPS
• PTFE 2 layer laminate material for waterproofing LCD
• Battery sleeve
• Donor jacket/item of clothing
• Wrist elastic
• Strong non-corrosive glue

Build-section:

• Assemble Arduino board
• Attach LCD shield to the Arduino board with the pins in correct locations
• Cut the 5 wires to length long enough to reach chest pocket from forearm
• Solder one end of three wires to each of the GPS outputs: power, ground and output.

• Solder GPS output to relevant pin, power to 5v pin and ground to ground pin.
• Cut the battery wires and solder the remaining 2 wires in order to extend the length of the wires connecting the battery to the arduino board
• Cut out the shape of the waterproofing LCD seal and fold over the inside edges and sew to make a neat edge.

• Remove the stitching of the inner sleeve in order to get in between the two layers of the jacket. This is where all the electronics will run through so they do not interfere with your arm when putting on and removing the jacket
• Cut out a square slightly smaller than the LCD on the preferred location on the sleeve. This should be at a location that can easily be seen when looking at your forearm (the top side).
• Repeat the process of folding the edges and sewing each edge. This will be the part the user can see so the sewing must be neat.
• Carefully glue the inside of the waterproofing seal to the edges of the LCD screen.
• Insert the LCD screen between the two layers of the jacket and feed the GPS module and battery pack up the sleeve and into the chest

• Cut band to the correct circumference and glue the ends (the length should be tested and should allow your forearm with long sleeved clothing to pass through whilst remaining tight enough to keep the device in position)
• Sew band to the inner sleeve of the jacket

• Glue band to back of the board
• Sew up the inner sleeve
• Glue waterproofing layer to the outer layer making sure the position of the LCD screen matches the cut-out on the jacket.
• Unstitch the sewing of the inner chest pocket to allow the battery to fit through.
• Glue the GPS module to the inner side of the jacket to fix the module in place. 
• Cut out the battery sleeve with the PTFE material and repeat the process of folding the edges and sewing to create a neat edge

• Sew the battery sleeve to the inside of the pocket
• Insert the battery
• The device can now be tested and used

Circuit schematics

 

Code section

We are using five libraries

• Elegoo GFX, TFT LCD, Touchscreen,  for the LCD screen [source]
• TinyGPS++, for the GPS module [source]
• SoftwareSerial, to enable serial communication between arduino and the GPS module  [source]

We then define some constants and then initialise the touchscreen object

 

We then define the LCD pins. These are fixed values as we are using a shield.

As you can see, the only pin left is A5; we will use this to communicate with the GPS.

We then configure the GPS

We are setting a TXPin even though we are not really using it; we are only receiving data from the GPS and not sending any to it.

Lastly, we define others constants we will use

Now, we need some variables

Ofx is used as an offset and textSize. We are using number as char, but we could perhaps switch to letters for a more meaningful representation (e.g. ‘s’ for speed screen, ‘a’ for altitude etc)

 

And for the GPS

“Raw GPS data” means those variables will be assigned by reading data straight from the GPS. The other ones will be manipulated before displaying them.

 

Our last declaration is the TFT object:

Elegoo_TFTLCD tft(LCD_CS, LCD_CD, LCD_WR, LCD_RD, LCD_RESET);

 

Our setup function looks like this

Firstly, we initialised both serial communications. We then reset the LCD, rotate the view and draw the logo. We then initialise the two variables which will allow us to update the data every second. We will see what drawUI(char) does later.

 

And here’s the loop function

While the serial is available, if the GPS is sending data (ss.read()) which is correctly encoded (gps.encode()) and one second has passed, then updateGPS(). This function, as we will see later, replaces values with new GPS data, only if the latter is valid.

Also, if we are not in the logo screen, printData() will run. This function updates just the portion of the screen which contains the data. Updating just a small part of the screen (the bare minimum in this case) makes the transition looks smooth. If we were to update all the pixel, the transition would be sloppy (and this can be observed when switching between screens).

Last part of the loop creates two button(). These are fixed rectangles that act differently based on the last parameter, the char. We will see this function later.

 

 

Following,  the code for our drawUI function:

As we can see, each case will draw a different screen. We need to set the pinMode to output otherwise we won’t be sending any meaningful data to the LCD. We then fill the screen with MAIN colour. Lastly, we print caption and value.

 

 

Our button function:

We are using TSPoint object from the Touchscreen library. This point has three dimensions: x and y, corresponding to the coordinates of the LCD, and z, which indicates the pressure.

We create a point, and if the pressure of this point is inside the boundaries define at the beginning, we map the values. If the mapped values are inside a rectangle we defined (i.e. we created a button), depending on which value we assigned to the button, it will perform an action. If the action is go right (char ‘r’), we will draw the curScreen + 1. However, if we hit the last screen, we will go back to zero. Likewise for going left action. This way you can cycle between the screens.

 

Our next declared function is updateGPS():

As stated above, this function will update the values we use and display only if these are valid.

Our last function and perhaps the most important:

This function runs every second (if we are not in the logo screen). It writes new values on top of the old ones. Since it draws just a little amount of pixels, the effect is really smooth.

[Full source code is available at https://github.com/AlbertQM/extremesportsjacket]

Testing and shortcomings

Testing was conducted intensively throughout the entire development process.

Each component was tested individually, starting from a simple sketch, and gradually implementing new methods, which were again, tested individually.

The first component we received was the LCD screen. We installed the libraries needed and built the circuit.

Despite our efforts, we couldn’t get it to work – it looked like an hardware fault as it kept disconnecting. We returned it and ordered a shield instead.

Once we received the new 2.8” TFT/LCD screen, we began testing its functionalities. (No circuitry building needed as the LCD was a shield).

This is when we realised that using a shield left us with just one pin. We looked into purchasing a bigger board but that was not feasible within our deadline.

We then agreed to use a GPS module, which with only one pin for communication would give us various levels of data.

We started off simple by simply printing strings on the screen using its library.

We then tried printing images on the screen.This process took 3-5 seconds, as the display is drawing pixel by pixel. After some research, we found out that we needed to store images in memory to be able to display them instantly. However, Arduino UNO doesn’t have that amount of memory to work with (let alone after filling it with 5 libraries). It was at this point that we realised that we needed to change our UI.

Lastly, we tested the actual touchscreen capabilities of our screen. We wrote a function that enabled us to draw a “button” (a square with round corners), and register whether or not the user was clicking inside its boundaries.

Before dropping the idea of using icons instead of captions, we tried drawing them as vectors rather than uploading a .bmp version. However, all the functions we had available (drawRect, fillRect, line and so forth) had no option to change the stroke weight, just the colour. We created a clock icon, but as the lines were 1px thick, it looked inadequate for our purposes.

We eventually decided to drop the icons and use our only resource left: strings. This is our first and biggest shortcoming: we couldn’t implement the UI we designed.

To increase the complexity of our code and enhance the user experience, we decided to develop gestures to control the LCD. Swiping left/right would cycle through all the data which we were going to display.
This process was coding intensive and left us with some functions that later helped us develop our final sketch.

After some manual testing on this one, we found various shortcomings that would have greatly affected users experience negatively: swiping between screens was not consistent. Moreover, it would take a couple of seconds to draw the new information on the screen.

To make everything more consistent, we decided to not use the gestures. These were replaced by a simple click on the left half of the screen to go back and forth.

Another shortcoming for the UI is not having signifiers: users won’t know they have to click on either half of the screen to swipe; although this is very intuitive so we thought it would have not been a problem.

Thanks for reading!

(Not quite everything worked on the first try..)