The system runs on an Arduino, since this makes prototyping really easy. Arduino is a platform specifically developed for rapid prototyping and offers both hardware and software solutions. Hence the choice to use this platform. For this specific system I am using an Arduino Uno (the most common version) that can be programmed via USB from the PC. In this section I will dwell on composition of the prototypes, and in specific on the software upgrades per iteration. In combination with pseudo-code I will explain what each iteration does and what observations have arisen from the user-tests conducted with the corresponding iteration. Furthermore I will shortly state the hardware qualifications of the iteration. A more elaborate description of the hardware, however, can be found in this section [The Hardware].

The first prototype version will not be discussed here since it does not include the Arduino and has no software. To read more about it, see section: First prototype. The second prototype is the first version to include the Arduino, there are two main reasons it has so many subversions (2.0, 2.1, 2.2 and 2.3). The first reason is because the user tests have been planned close to each other leaving little time to improve the prototype on anything else but the inner workings (software). The second reason is I wanted to experiment with different user interactions to come to the desired one. Hence this version has so many different tries.

For the design choices and specifications of both prototype 2.0 as well as prototype 1.0, please read their sections accordingly. In this section I assume you know about them.

Prototype 2.0

As stated before, the second prototype is the first iteration to use the Arduino (the first iteration was purely mechanical) and the code is kept fairly basic for two reasons. The first reason being the fact that this version has yet to prove itself. I don’t want to lose to much time coding it and then find out it was a waste of time since the concept doesn’t work (similarly to the first iteration). The second reason is that with each user test comes new information that helps improve the code. The user’s feedback helps to see clearly see what improvements are necessary.

For this first version of the code I want to include two main ideas. I want the LEDs in the system to fade in-and-out and I want the intensity of the LEDs to be relative to the amount of pressure received by the sensors.

Fading

For the fading I’ve written the following code when translated to pseudo-code:

FOR each increment of LED intensity
   WRITE analog value of intensity to LED
   WAIT 30ms
FOR each reduction of LED intensity
   WRITE analog value of intensity to LED
   WAIT 30ms

Scoring

The sensors inside the system return a value between 0 and 1023, this value is categorized in five different categories as proposed by Adafruit:

• No pressure (<10)
• Light touch (10 – 200)
• Light squeeze (200 – 500)
• Medium squeeze (500 – 800)
• Big squeeze (>800)

These categories determine both the intensity of the LEDs and the duration of the fading. Furthermore they also increase a score kept for each vertebrate. This score determines the state of the vertebrate. If a massage is applied on the vertebrate it wil glow (fade) red, when the score limit is reached it will turn green and the treatment is at an end. This limit is chosen randomly and does not represent reality in any way. In a real situation there is no end to the treatment except for the time-limit of the practitioner’s session. The inclusion of this limit is incorporated so that the testers do not keep on massaging endlessly.

Prototype 2.1

In the previous version the user had to be told at what point the hernia was located. For this version we want the system to take control of this indication. The main point of the system is to convey the experience of a real patient, in that case the practitioner will almost never be told upfront where the hernia is located. Whereas in the previous version all vertebrates glow red when touched and turn green when they are OK, in this version only the vertebrate with the hernia will show this behavior. The other vertebrates wil stay ‘silent’.

Prototype 2.2

Since the testers were afraid to touch the hernia located spot in the previous version of the prototype, I changed back to the situation where all vertebrates show feedback to the user’s input. In this version all LEDs glow red (assuming this means the wrong spot), and the disc where the hernia is located glows green.

Prototype 2.3

Since the user tests for the previous version indicated that the user associates the green color with everything alright and red with needs more work, I decided to swap the colors around. Now all vertebrates glow green except for the location with the hernia. Since there are five vertebrates in the system only five LEDs need the option to fade with this current prototype version. Four of them need to be able to glow the green LED and the verterate simulating the location of the hernia needs to be able to glow red. The functionality to simulate a hernia at a random location in one of the five vertebra’s is not incorporated yet. Partly because there is too few pins to support the LED fading effect (see PWM pins: fading LEDs) and partly because I want the test results to be based on the same user experience.

Prototype 3.0

Trying LEDFader library. Mostly hardware additions

Prototype 3.1

Attaching servo’s as actuators to outputs. The servo’s block pin 9 and 10. Now one of the vertebrates does not work.

Taking in multiple inputs at once. [write pseudo code]