Digital Health: Exploring Use and Integration of Wearables

By Sam Stuart

Digital Health: Exploring Use and Integration of Wearables is the first book to show how and why engineering theory is used to solve real-world clinical applications, considering the knowledge and lessons gathered during many international projects. This book provides a pragmatic A to Z guide on the design, deployment and use of wearable technologies for laboratory and remote patient assessment, aligning the shared interests of diverse professions to meet with a common goal of translating engineering theory to modern clinical practice. It offers multidisciplinary experiences to guide engineers where no clinically advice and expertise may be available.

Entering the domain of wearables in healthcare is notoriously difficult as projects and ideas often fail to deliver due to the lack of clinical understanding, i.e., what do healthcare professionals and patients really need? This book provides engineers and computer scientists with the clinical guidance to ensure their novel work successfully translates to inform real-world clinical diagnosis, treatment and management.

• Presents the first guide for wearable technologies in a multidisciplinary and translational manner
• Helps engineers design real-world applications to help them better understand theory and drive pragmatic clinical solutions
• Combines the expertise of engineers and clinicians in one go-to guide, accessible to all

• Language: English
• Publisher: Academic Press
• Release date: Jul 6, 2021
• ISBN: 9780128189153

Book preview

Chapter 1

Kits for wearable sensor systems: exploring software and hardware system design, building guides, and opportunities for clinical rehabilitation

Ross Allan Clark¹*, Shamala Thilarajah²**, Gavin Williams³,⁴†, Michelle Kahn⁴††, Sophie Heywood⁵‡, Hong Han Tan²§, Emma Jodie Hough¹§§ and Yonghao Pua²¶,    ¹University of the Sunshine Coast, Sippy Downs, Australia,    ²Singapore General Hospital, Singapore,    ³University of Melbourne, Melbourne, Australia,    ⁴Epworth Hospital, Melbourne, Australia,    ⁵St Vincent’s Hospital, Melbourne, Australia

Abstract

Creating wearable sensor systems is a daunting prospect to healthcare professionals and novice developers: where to start and what to use? This chapter provides a pragmatic guide to low-cost software, hardware, and developer kits for those interested in exploring wearables in clinical populations. Firstly, the build, repurpose or outsource decision process is described. Secondly, key hardware and software design decisions are described to simplify the choice. This encompasses wireless/wired communication methods, data recording and graphical user interface design, choosing and efficiently using a 3D printer, and selecting the right sensors. Two detailed system design examples are then provided: (1) a wireless surface electromyography device; and (2) a global positioning system and accelerometer activity monitoring system. Finally, a brief summary of hardware and software systems available for people new to the field, including graphical and human readable programming languages, 3D modeling software and learn-to-program support, is given.

Keywords

Arduino; microcontroller; sensors; electromyography; load cell; muscle activation; accelerometer; gyroscope; inertial monitoring unit; wearable sensor

1.1 Introduction

There is only so much information we can gain from testing people in a research laboratory. Often what we really want to know is what the person is doing in the real world, and for this we need to send our data collection systems out with them. Thankfully creating research-grade devices has never been easier or cheaper, with software and hardware development kits now widely available. This ranges from building analysis programs to interface with existing software and hardware ecosystems, through to creating your own devices and software using microcontroller and sensor kits. The aim of this chapter is to provide a pragmatic guide to designing and building devices and software for collecting research-quality data in the field.

1.2 Buy or build?

Short answer—Buy if you can

Long answer—Ask yourself the questions in Fig. 1.1.

Figure 1.1 A decision tree for use when deciding on whether to buy, outsource or build your own system.

To further explain some of the key aspects of the decision tree:

1.2.1 Does a current system exist?

This is easy—if something already exists that does what you want to do, you need to ask yourself why you would bother reinventing the wheel. It is easy to forget that time is money, so make sure that if you are going to replicate the system it will be financially viable to do so. You also need to consider the intellectual property (IP) aspects—if you are replicating something that already exists you may be infringing on their copyright, patent, etc. If it is a one-off that will only be used by you, this is unlikely to be an issue.

1.2.2 Who owns the intellectual property?

If nothing is out there to do what you want, essentially you must invent it. This may have IP ramifications, particularly if you are in a situation where your employer owns the IP you generate. It is always a good idea to speak to your commercialization department (if you have one) about this before you go too far, as once your IP is disclosed in public it can never be taken back. It is easy to make the mistake of thinking you want to make it open-source or freely available for the greater good. This is often a great option; however, it is important to remember that if you intend to make a clinical device, it is going to have to be registered as one. This costs money to do, and if a company doesn’t have exclusive access to the technology via a patent or other licencing, they are much less likely to pursue doing it. Remember, by making something freely available you may actually be making it less available to the people who need to use it.

1.2.3 Do you have the skills/desire to make it yourself?

Building a wearable sensor system is akin to almost anything in life—the Pareto Principle applies and 20% of the effort will achieve 80% of the outcome. The problem is that if you are going to ask people who aren’t your employees/students to use your device, then it needs to be polished. Getting a system up and collecting data is often very easy, but making it look sexy, be bug-free and have a user-friendly interface can take a very long time. It is relatively easy to program a system to collect and record data using examples from the internet, and this is the most exciting part of the build. The grind comes with the error checking, debugging, and verification to turn the rough program into something that is user-friendly, accessible and most importantly, provides accurate, reliable and valid data. If you don’t have the coding experience to do this, you need to ask yourself if this is a challenge you want to take, or whether you are better off outsourcing it.

1.3 Repurposing or innovating with existing technology

This cannot be emphasized strongly enough—if you don’t have to create new hardware, do not do it. Let a company spend the money in research and development, tooling, manufacturing, marketing, and selling a device. It is becoming more commonplace now for devices and software to include an access point interface (API) or software development kit (SDK) from which you can manipulate the data. For more details on these methods refer to Chapter 11, Healing and Monitoring of Chronic Wounds: Advances in Wearable Technologies. This is a great example of a shortcut when creating a data collection system, as often the hardware and software from the company does the hard work for you and you can simply leverage off their examples to make it do what you want. An excellent example of this is the Microsoft Kinect SDK, which performs machine learning on data acquired from video and depth camera images to identify joint landmarks in three-dimensional space. These data are easily accessible, along with kinematic information, via the SDK allowing you to create your own software to leverage this information. Specific to wearable sensors, many devices including those of FitBit include software with an API. Whilst in earlier years this was almost solely useful for data analysis, with the proliferation of smartwatches these API’s can also be used to control the way that the user interacts with the device. This is a potential game-changer with respect to wearable sensor design, as the devices can be programmed to collect additional data and provide user feedback, whether it could be directly from the sensors or via implementing questionnaires with touchscreen responses.

1.4 System design

So you’ve made the decision to design a new system—what now? By far the most important and time-consuming aspect is the planning stage. Planning out every aspect is essential prior to attempting the build, as otherwise there’s a very good chance you will run into a roadblock that may be insurmountable. Hopefully you have found an example that is very similar to your intended system which can be tweaked to suit your purpose. However, quite often it will be similar but not identical and therefore you will need to change major aspects of it. Before diving head first into building a system you need to think about the following aspects.

1.5 Patient and public involvement: collaborating with your end-users and patients

Many interesting technologies have not been translatable to clinical practice and are often abandoned after the exciting this system shows great promise! findings of early research. It is essential that you talk to as many trusted potential end-users as you possibly can before going too far down the development path. This limits wasted time and resources, and also helps you to iterate through prototypes and improve your system as early as possible. Take care not to rely on false confidence from just getting feedback from the that’s exciting crowd. Including individuals in your project who are skeptical of technology and its place in clinical practice can often result in some disheartening feedback, but it can also provide you with the knowledge of what you must achieve to make the system’s widespread use viable. Early and frequent feedback assists you to understand important aspects of the clinician or end-users technical capability, successful use, comfort, and cultural concerns as well as considering the type of education and support that is needed for testing out of the lab. Here are some examples of feedback I have received on systems that I have created:

• I cannot open the computer. This was feedback I received over the phone for a system which was designed to run when the computer operating system booted. It took a couple of minutes to realize that the feedback wasn’t about the software but the laptop itself—which had a latch on the monitor you had to slide to open and access the keyboard.

• You cannot use a star on that device, it will make people angry. This was for a wearable device which I put a star on as a pretty way of showing which side was facing upwards. The country it was being used in had a dislike of communism and the red star brought up strong emotions.

• Oh no. This was feedback received from a home-visit therapist when she first saw a rehabilitation device we had spent weeks creating. We thought we had come up with something that could be used in the patients’ own home; we were sorely mistaken.

Just because the system is exciting to you doesn’t mean it is to others. When you are discussing the potential for the system with the end-users some key points to discuss are:

• Value and meaning. Does the technology provide information that is currently not obtainable through standard clinical tests? Does it value-add? Can clinicians/end-users action the results and explain them to the patients they are seeing? If clinicians do not see added value they are much less likely to adopt it, particularly if they can’t explain what it means or how to fix bad scores to their patients. Good luck explaining sample entropy scores to a clinician, let alone someone who has had a severe stroke.

• Ease and speed of use. What is needed for the technology to have a clear, easy to use interface? A big screen? Certain colors? A layout consistent with other tools they use? Does the technology shorten clinical assessment?

• Data extraction. Can the data be quickly downloaded in a format that is easy to read in clinic? This is important as clinicians are more likely to adopt technology that can (1) directly and (2) immediately be used to improve patient outcomes. Your JSON based web API sounds great to you, but many hospitals have poor/no/blocked internet access, so a web-based analysis and reporting method is prone to problems.

• Size. For a wearable sensor this is particularly important. For example, if it’s on the ankle make sure it doesn’t look like a police monitoring device! If you want someone to wear it all day it needs to be as minimally cumbersome as possible.

• Maintenance. How do we clean/reuse it? Ensuring that the equipment has parts that can be cleaned using hospital grade disinfectant wipes is often very important. If this isn’t the case, it needs to be reskinned every use and the consumable budget could blow out.

Once you’ve had these discussions it is time to think about the hardware. The following table (Table 1.1) provides some questions to ask yourself when designing the hardware for the system:

Table 1.1

Once you’ve answered these questions you will have a good idea about what the system requires. Now you can plan out every specific detail of the project prior to commencing the build. Determining what is required from the software is a good place to start, as that will dictate the hardware you require. Knowing that your device needs to collect A at B sampling rate while displaying C wirelessly will help you to narrow your hardware search. For example, I might need to collect data wirelessly from an inertial monitoring unit (IMU) and display the roll pitch and yaw angles on an Apple iOS phone in close to real-time as part of a prototype design to see if the system might be worth pursuing for a project. This narrows down my hardware search to requiring a system with:

1. Bluetooth low energy (recent Apple hardware does not support Bluetooth Classic);

2. An IMU, preferably one that performs processing on-chip to reduce complex coding;

3. A microcontroller, preferably one that is known to work with the preferred IMU;

4. A small battery to power the system;

5. Preferably a battery charging circuit to allow recharging without taking the battery out;

6. An enclosure that is functional but not necessarily professional.

1.5.1 Hardware

For this system I could use the well-established Bosch BNO 055 IMU, which has on-board sensor fusion for obtaining Euler or Quaternion (preferred because it removes gimbal lock) angles with minimal drift. This could interface directly with a Sparkfun Artemis Nano, which is a relatively powerful microcontroller board that includes both a battery charging circuit and Bluetooth low energy (LE). This could be combined with a small lithium polymer battery and a basic enclosure to create the hardware for the system. Overall this system would be very simple to create.

1.5.2 Software—the hard way

This is the more complex part. The hardware needs to be connected to the iOS device via a Bluetooth LE connection. These data transmitted by the hardware then need to be collected and visualized on the iPhone screen in a format that is intuitive to the end-user. The microcontroller programming aspect is straightforward, with a plethora of examples available online for sending sensor data over Bluetooth LE. Programming the iPhone however is much more difficult. For a simple interface it may be worth programming it in a graphical programming language such as Thunkable, which has example programs showing how to create iOS apps relatively easily that interface with Bluetooth LE.

1.5.3 Software—the easy way

For a first proof of concept prototype avoiding phone programming may be the best solution for rapid deployment and testing. This can be achieved in many ways; however, a viable solution is to have the hardware interface with a computer that is running the programming language and associated graphical user interface of choice [e.g., Python, Laboratory Virtual Instrumentation Engineering Workbench (LabVIEW)]. This user interface can then be sent over the local WiFi network or internet to the iPhone using something as simple as Google Remote Desktop and depending on your connection speeds the lag is typically imperceptible. This can reduce the programming requirements dramatically and speed up customisation. If the system is found to be worth pursuing and converting into a more professional device, that is when the next step of device specific programming can be explored. While this may seem like it is using two stones to kill one bird, perfecting the software in one programming language you are familiar with allows rapid deployment before porting to the more complex system, which can save significant amounts of time in the prototyping stage.

This highlights a key aspect of prototype design—taking shortcuts is not only a good thing but essential to optimize efficiency as long as they do not negatively impact the quality of the data you are collecting. Shortcuts that speed up the process and allow you to fail fast, fail early, and fail cheaply are a great idea, particularly if you are not confident that the system will eventually be scaled to a large volume. For example, it can take weeks if not months to build the instructions and video examples into a smartphone app in a polished way. The same can be achieved in an hour using drag and drop web design software such as Weebly or Wix, with a simple button that hyperlinks to open the webpage you’ve created built into the app. As an example, here’s a link to the MIT App Inventor code for an Android phone app created to assess spasticity in people with acquired brain injury:

www.tiny.cc/spasticity

If this app were to be monetised or scaled to millions of users, the combination of MIT App Inventor as the coding language and webpage-based instructions may not have been optimal. However, after we performed our preliminary validation [1] and establishing that it was worth pursuing clinically [2] with rough code, we were able to create and distribute the finished app in around one day of work. Given the niche target market for this sort of App we deemed this method to be optimal.

The following section provides some key aspects of hardware, software, and enclosure design.

1.6 Key aspects of hardware design

1.6.1 Choosing a computer/microcontroller system

This comes down to personal preference, if you are used to using a Mac and are experienced with BeagleBone Black then this is a logical starting point. The key issue is making sure that you know the answer to all of the questions in Table 1.1, and any others you can think of. This will allow you to make an informed decision about which device you should build your system around. If you are new to the area, the Arduino platform is an excellent one to begin with. It has extensive online support and an extremely wide range of compatible microcontroller and sensor systems.

1.6.2 Which sensor should I choose?

For many of the common assessments there are a plethora of different sensors and models to choose from. For example, IMUs have many different variants including 3, 6, 9, and 10 degree of freedom chips, on-board versus software sensor fusion, analog versus digital output, etc. This is where finding similar examples of systems that have successfully achieved what you want to do is useful, as you can use them to guide your decisions. It is also important to balance practicality and precision when making the decision. For example, pressure sensitive fabric such as Velostat is not as precise or accurate as a load cell for measuring forces. However, in some situations its low weight, ultralow profile and ability to be shaped easily to match the surface of interest may make it a superior choice to a load cell. For example, if the goal was to measure how much force was applied to a key while being placed in a lock it may be a good option [3].

1.6.3 Think about getting the data

Does the end user need to give the device back to you so that you can download the data? Or is it going to send the data via the internet? What if they don’t have access to the internet, or are restricted on the sites they can use or data they can transfer? These are all very important aspects of the system design. For example, consider a home-based system that the person takes with them for a month. If you only collect the data at the end of the month you risk complete data loss if the device goes missing or is damaged. Alternatively, if it updates daily/weekly you can overcome this issue. If, however you do go with an Internet of Things (IoT) approach what happens if they have no internet connection for a period of time? Methods such as sending all data that has been stored whenever a network connection is available can overcome this, however consider the file sizes.

1.6.4 Which wireless method should I choose?

This is a key question to ask, and ranges from the simplicity of traditional Bluetooth through to IoT. Some of the most common methods are:

1. Bluetooth Classic: Also known just as Bluetooth, this is arguably the simplest method of sending data wirelessly from a wearable device to a Windows or Android system. Using a Bluetooth breakout module, all you need to do is connect the RX (receiver) and TX (transmitter) pins to the opposite pins (i.e., connect RX on an Arduino to TX on the Bluetooth module) on the microcontroller of your choice and it is ready for action. The system is then paired with the device you want to send data to, and from then on it is treated as a standard serial communications port. This simplistic explanation brushes over many important points, such as setting the Serial Baud rate to the speed you want, however it shows just how easy it can be to replace your tethered cable with a wireless connection. In addition to being simple it is also one of the cheapest options, with JDY 31 breakout boards available for under USD$3 each. Note though: Bluetooth Classic is not supported on recent iOS devices.

2. Bluetooth low energy (LE): Bluetooth LE shares the same name but otherwise is very different to implement. Whereas Bluetooth can be treated as a simple serial communication port, Bluetooth LE requires a server/client partnership. Its major advantages are that it is very low power, which is important for wearable devices where charging is an issue, and it is compatible with iOS. Bluetooth LE cannot send data as rapidly as Bluetooth Classic, so keep this in mind.

3. Radio frequency: One of the go-to methods for wireless communication with a wearable sensor, radio frequency transceivers cover a broad spectrum of use cases. The nRF24L01+ is an extremely low-cost device, with breakout boards for this chip often available for

4. WiFi: This method is typically what we think of when we hear the term IoT. WiFi can allow the wearable to connect to the internet and send/receive data remotely, but it can also connect to local networks and send data within this network only. The former method is particularly suited to collecting data from research participants in their homes, as it can all be sent to a central location controlled by the supervisory team. This may not be feasible in clinical settings though due to data privacy, which is where the local network is a much better and more controlled environment for safely transmitting and receiving data. For example, WiFi could be used to connect different assessment systems located in a clinical center to a central database for analysis and electronic medical records integration without needing to connect to the internet.

5. Cellular: Leveraging off the broad reach of phone networks, you can create wireless systems that send data via the cellular network itself, for example, text messaging results or automated phone calls, or use the mobile internet connection to transfer data. This is a great option when you want to receive data at regular intervals and don’t want to be limited by range. It is costly though, as each device will need its own sim card and network plan.

1.6.5 Make it forwards compatible

At the time of writing, one of the most popular IMUs (MPU9250) has been discontinued by the manufacturer but is still being sold in large quantities as distributors have massive amounts of them. It is a great chip, however integrating it into a device now might make it impossible to replicate in a year’s time. Always check to see what the expected lifecycle of data critical aspects of the device is before using them. For example, to swap out this IMU with another would likely require reprogramming the software, modifying the existing hardware enclosure, and validating the new chip with the existing one, amongst other potential issues. This is a very important point and one not to be overlooked.

1.7 Key aspects of software design

1.7.1 Plan how you want it to be used

If it is an early prototype or research, then function is the only thing that matters. Focus on data quality, effective visualization and spotting bugs or sources of error as they occur. For these programs it is often a case of the-more-the-merrier with data, particularly if you can use Boolean (True/False) operations to color code your data as right or wrong for easier identification of errors in real-time. If you intend on using the system in the real-world then focus on making the user interface as uncluttered, responsive and simple to use as possible. It is essential that you work with the proposed end-user(s) to determine what they want from the system. If it is a system that you hope will receive widespread use, make it in a way that gets buy-in from the intended end-user. Simple things can make a huge difference as to whether the system gets put in a box in a cupboard or gets used everyday, such as:

1. Personalizing the software to the setting. If it is with a hospital, consider including the hospital or specific departments logo (check copyright issues first) as a background image or button decal.

2. Using indicators and visualizations that the end-user wants. In research we often use advanced theoretical techniques to analyze data, however if a clinician can’t explain it to the patient or action it in their work, quite often, they have no interest in it. Ask the end-user what they want to know from the device, and how they want it displayed.

3. Automating as much as possible. Simply setting the software to boot up automatically when the device is turned on, and including a power off button in the software that shuts the entire system down, can make a big difference to the ease-of-use and integration of the device into everyday usage.

1.7.2 Which data format should I use?

There are numerous data formats, including:

1. Human readable. This covers the data you are used to seeing, with values being represented by arabic numerals or text. This is optimal for the visualization of the data; however, this typically requires much higher memory capacity to store than other methods. Human readable data can take many forms, and it can be important to choose wisely if memory capacity and transfer speeds are important. For a great description refer to https://learn.sparkfun.com/tutorials/data-types-in-arduino/all

2. Binary. This form is not directly interpretable; however, it is often an order of magnitude smaller in terms of memory footprint. This makes it particularly well suited for use on microcontrollers with limited memory and bandwidth capacity, as this smaller footprint makes it easier and faster to store. For most devices it is a good idea to save and transfer data in binary format, then convert it into human readable format for the analysis and visualization.

1.7.3 Think about how you want the data to be saved

Never allow spelling mistakes or typographical errors in file names or folder locations when you are testing. This can be done by minimizing or completely removing text box inputs, which can often be replaced by dropdown boxes. For example, let’s say you are doing a project with a wearable sensor where you want to perform a series of double leg squats eyes open, double leg squats eyes closed, single leg squats eyes open and single leg squats eyes closed tests performed for three trials each. You have many options to achieve this, including:

1. Having the participant/researcher type in all 12 variants of the trial names, of which at least one is likely to have a spelling mistake;

2. Provide a dropdown box from which the user can choose their trial. This negates all chances of spelling mistakes or typographical errors;

3. Use a method such as voice activation to tell the system which trial is being performed. This sounds sexy but can cause errors in data labeling in situations with high noise, strong accents, etc.

Option 2 is a great one and can be expanded to include dropdown boxes for participant codes if it is a research study, or barcode scanners for patient ID in hospital/clinical settings. It is a good idea to always try and minimize button clicks, but never at the expense of data quality. User testing in the field will quickly help you understand potential issues with data collection and labeling.

1.7.4 Plan for new analyses of old data

New analytical methods are being created all the time, and there’s a good chance you will want to go back and reanalyze previously collected data at some point. Steps to achieve this include:

1. Logging raw data: If you don’t have the raw data, you often cannot perform a new analysis. This can be problematic if you are collecting at high sampling rates and storing the data on the device itself, however, keep this in mind when you choose how much memory for storage the microcontroller has access to.

2. Automating the saving protocol: This relates to the prior point about thinking how the data will be saved. If it is automated it makes it much easier to batch process later on. A great structure for saving data is to have a folder for each individual, then a subfolder for each assessment session that uses the data in reverse order (i.e., 20190128 for the 28th of January 2019—this makes it easier to sort). This reverse order data is then included in the file name along with the time the file is saved and the input to identify the participant code and trial type. For example:

P004_Outdoor Walking Trial 1_20190128_1645.bin

Would be Outdoor Talking Trial 1 collected for Participant 4 at 4:45p.m. on the 28th of January 2019. The underscores allow you to programmatically separate the file name into its individual components during batch processing. Simply searching for the different strings (i.e., text) between the underscores (which serve as separators) allows for full identification.

3. Saving all user input: This is often overlooked but can change reanalysis from a daunting task into a simple one. If there is any button clicking, data trimming or option selections involved in the data analysis, record this in the file. That way if you ever need to reanalyze the data you can automate this process instead of having to redo the manual input.

1.8 Creating an enclosure for your device

Enclosures for your device achieve a number of important functions. They can improve data quality and reliability, user comfort, fixation of the device to the person, increase safety and isolation of the power source, as well as create a more professional finish. However, many factors often need to be considered. Take for example the creation of a wearable EMG device; making it as low profile and lightweight as possible is essential to minimize movement artefact and prolong electrode adhesion to the skin.

Although looks are not the most important part of a system, never underestimate the importance of first impressions. Having a device that appears to be made by a major technology company will improve the end-users confidence in its use. At the time of writing, by far the dominant method for creating the exoskeleton of a prototype wearable sensor device is 3D printing. There are a range of different 3D printing methods, with the most common one being fused deposition modeling.

1.8.1 Choosing a 3D printer

A simple rule to live by, always get the best 3D printer you can afford. At the time of writing (2020), 3D printing has come a long way since the early 2010’s but is still a painstaking task that is fraught with failed prints and wasted plastic. Before purchasing a system do a thorough assessment of:

1. Safety issues: Many of the lower cost printers have known safety issues related to suspect wiring, thermal runway heating issues and questionable power supplies. It is important to remember that these machines are electrical devices producing heat often in excess of 200°C sometimes for days at a time. It is strongly recommended that printing is only done in a controlled environment with fire safety equipment ready. Printing should also be supervised; however, this can be difficult given larger prints with high details can take multiple days of continuous operation to complete.

2. Print quality: Early 3D printers could replicate simple geometry and not much more. Now with higher movement resolution, dual extruders, improved filament technology and multipoint bed calibration, the outcomes are far superior. However, each 3D printer will have its own quirks so it’s best to find a review of it before purchasing.

3. Failure rate: Many of the very cheap 3D printers can produce outstanding quality prints…when they don’t fail! Print failures are common, and can be caused by excessive warping, poor model design, not providing sufficient support structures for overhangs, and issues with the printer itself. If you buy a reliable printer and you have failures at least you can remove one of these possible reasons.

4. What materials it can print: Excluding the more advanced materials such as biological filaments (e.g., polycaprolactone), the most commonly encountered ones fall into the categories of standard, flexible, composite, and support. The most popular standard filaments are polylactic acid (PLA) and acrylonitrile butadiene styrene (ABS), with each one having its pros and cons. PLA is cheap, easy to use, the fumes are relatively safe, and it is strong and stiff. The downsides are that it has a much lower melting point, which can result in it warping and dropping if left in a hot car or direct sunlight for too long. ABS by contrast is better suited to end-use, because while it is more prone to warping and releases more potentially hazardous fumes during printing it is less susceptible to breaking and has a much higher heat tolerance. However, there are numerous filaments that provide many of these advantages without the drawbacks, such as Colorfabb Ngen or Ultimaker Tough PLA.

5. Dual versus single extruder: Once you have used a dual extruding machine it is difficult to return to the constraints of a single extruder. While dual extrusion allows you to do things like printing with two different colors on the same model easily, the most important advantage it provides is the ability to print support structures in easy to remove material. For example, you can print complex designs in PLA supported by polyvinyl alcohol (PVA), which is essentially glue. When the print is finished you simply place the part in water and the glue dissolves. In contrast, trying to do this using a single extruder results in having to mechanically remove the support material because it is made of the same plastic as the part itself. This is not a big deal for many devices, but if yours includes internal cavities this can make it highly problematic.

6. How long it takes to setup and calibrate: This is often what you pay for—rock solid calibration that is automatically performed. Systems such as the Ultimaker S5 perform automated, multipoint mapping of the bed surface which can overcome warping of the printer’s glass print surface. By contrast, cheaper printers often require manual calibration of the corners of the print bed, which is more time consuming and prone to causing model deformations if there is any nonlinearity in the print bed surface.

In summary, at this stage there are very inexpensive (for example, the Creality Ender 5 at plug-and-play systems such as those from Ultimaker. The initial financial savings may not be worth it if you are repeatedly having issues with prototype delays due to failed prints and the costs of wasted filament.

1.8.2 3D printing tips

Unfortunately, 3D printing is not always successful, however, the following tips will hopefully assist you in creating good quality parts.

Print using supports and build plate adhesion: One of the primary causes of print failures is poor supporting structures. Fused deposition modeling works by stacking thin layers on top of each other to create a 3D structure. This goes wrong when you try and stack filament onto an area where there is nothing underneath it, called an overhang. At best this will make the print look deformed, typically though this will cause a failure. As shown in Figure 1.2, support material is used as a base on which the overhanging part is supported.

Figure 1.2 An example print setup in top left: no build plate adhesion or support. Bottom left: A brim surrounding the model to help keep it in place (note the additional thin black layer around the outside of the model), and a support structure (white) to stop the overhanging structure from falling over. Top right: The 3D model. Bottom right: What the print looks like halfway through, with the support structure created in a grid-pattern. For optimal adhesion with PLA material I use a couple of small drops of saltwater spread over the surface of the heated (50°C) glass bed using a tissue. I choose this method as it has strong adhesion when heated, but once the bed is cooled the print is often easy to remove.

Adhesion of the part to the build plate, or bed, is one of the most important components of getting a good quality print. The part can lose adhesion entirely, which will result in a failed print, or lift in sections which will cause excessive warping that will transfer up through the part. Depending on your printer it is good practice to print with at least a brim (shown in Fig. 1.2), which helps to keep the print firmly anchored to the print bed. Other alternatives include a full raft.

Print in well-ventilated, well-controlled environments: Make sure to check whether the filament you are using has potential health hazards. Even if it doesn’t it is best to print only in well-ventilated settings. Safety is always the first priority.

Always use the easiest possible material that will do the job: There is no point printing in nylon if you don’t need to, it’s much harder to make it look good and more likely to fail than PLA.

Don’t use corners if possible: Right angle corners are prone to lifting off the build plate even when reliable filament (e.g., PLA) and good adhesion (e.g., glue stick, brim) is used. This causes warping of the print, at best making it ugly but often ruining it completely. Rounding the corners even slightly will significantly reduce the chances of warping, particularly on models that have a long edge, for example, the tripod stands shown in Fig. 1.3.

Figure 1.3 An example of using rounded corners on a 3D printed tripod stand. The long edge of the tripod would have likely resulted in warping or lifting of the print from the heated bed, potentially resulting in a failed print. Conversely, because of the small box size for the LIDAR, sharp edges were deemed reasonable and no warping was observed when printing with Colorfabb Ngen. The sensors and hardware used are described in detail at the website http://rehabtools.org/LIDAR.html [4].

Position the model in the slicer software to minimize support material and maximize bed contact: Having a relatively large surface area contact between the printer bed and the 3D model you are printing greatly increases the chances of a successful print. Doing something as simple as printing the model upside down or on a 45 degree angle can dramatically improve print quality.

Enclosures make a big difference: An enclosure serves many benefits, including protecting the printer from being damaged. Importantly, it also improves print quality and bed adhesion by keeping the ambient temperature elevated. This reduces the risks of warping when using filament such as ABS. When you purchase a 3D printer either buy or make an enclosure to put it in unless it is in a temperature-controlled space. Even then an enclosure is still a very good idea.

Take care of your filament: Don’t leave it lying around, if possible, put it back in a sealable container with silica to ensure that moisture doesn’t ruin it. This is particularly important for filaments such as PVA, which absorbs moisture and can become jammed in the printer and often fails if it has absorbed too much.

Now that we’ve covered some of the important aspects of software, hardware and enclosure design, here are two examples of the process used to create custom wearable sensors and some key issues that arose during the build.

1.9 Example 1: building a low-cost electromyography system

EMG can be a useful tool for assessing and training muscle activation. For example, EMG can assess muscle activation that may be indicative of poor knee function after anterior cruciate ligament surgery [5,6], measure involuntary muscle activation in people with acquired brain injury [7], and quantify early onset fatigue during manual tasks [8]. EMG is worthwhile as a clinical tool, however, it remains relatively unknown because of the numerous barriers to its widespread use including cost and ease-of-use [9]. The same question kept being asked whenever we used EMG in studies—is it possible to use this in the real world? We therefore set out to explore its use in clinical and home-based settings.

1.10 Following the decision tree

1.10.1 Does a current system exist?

There are numerous commercial EMG systems, however, typically they have quite a few barriers to implementation. Cost is problematic—most systems are multichannel and are often multiple thousands of $USD per channel. Interfacing is also often tricky—we require a system that could interface directly with a computer, tablet or smartphone as soon as you turn it on and without requiring any external interface connection. For some studies we also wanted it to synchronize with other sensors through software and/or hardware. For these reasons we decided that a custom system would be a good option.

1.10.2 Commercialize? Is there intellectual property worth protecting by me/my organization?

Given there was nothing novel about the system there was no need to discuss commercialization or IP protection for this specific device.

1.10.3 Do you have the skills/desire to build it yourself?

Anyone with a technical interest who has ever used EMG will likely have built their own system using an operational amplifier such as the AD620 or INA106. Therefore we felt it was worth pursuing building a custom system ourselves.

1.10.4 Has anyone built something very similar in the past and provided a how-to guide?

Not only were there how-to guides, there were also EMG kits for sale that would do exactly what we wanted.

1.10.4.1 Hardware design

Based on the project requirements we used a Myoware muscle sensor, which prior to implementing in this system we validated against a commercial system [10]. For one study consisting of underwater assessment, wireless data transfer was not an option, and therefore the person was tethered to a National Instruments data acquisition device. However, for the majority of studies we planned on using EMG in, we wanted an untethered system with wireless data transfer to a host computer. Therefore we have used variants of standard Bluetooth (JDY 31 SPP, HC05, RN-41) and also radio frequency transmission (NRF24L01+). Either method is simple to build, however, programming is much more difficult for the radio frequency transmission device. Therefore it is only used in specific instances such as situations where very high data transmission rates are required, or when long distance communication is essential by pairing it with external antennas. An example of wiring diagram for a Bluetooth EMG system is provided in Fig. 1.4, with the enclosure model and end result shown in Fig. 1.5.

Figure 1.4 A wireless electromyography system consisting of a Sparkfun Artemis Nano, Myoware muscle sensor, lithium polymer (LiPo) battery and JDY 31 SPP Bluetooth module. Note that the Artemis microcontroller includes built-in Bluetooth low energy, however for this system standard Bluetooth was required. Also note that the Artemis Nano charges at 500 mA, a LiPo battery equal to or higher than this capacity is required. The Artemis Nano is a good option because of its charging circuit with lights to indicate completion, and 14-bit analog to digital conversion ability. However, for prior studies we have used different microcontrollers including Tinycircuits Tinyduinos and Qduino Minis with 10-bit ADC and Teensy 3.2 with 13-bit ADC. The choice depends heavily on application, with more bits requiring a higher serial port transfer speed. Using the Artemis at 14-bit ADC resolution sending binary data through the Bluetooth module at 115200 bit/second should provide ample sampling frequency for most applications. The total cost of this system at the time of writing was

Figure 1.5 The 3D model for the electromyography device, and the final assembled version. The top images show the model, which was designed using Tinkercad. The bottom image shows the assembled device, note (1) the switch mounted on the Artemis printed circuit board (PCB that protrudes through the top section; and (2) that the small flat section shown in the top models was printed in transparent polylactic acid (PLA) to allow the charging and power lights to be