wireless healthcare system final report -...

21
1 Wireless Healthcare System Final Report Zhihui Qiu, Minghuan Zhao Tufts University Dec 2014

Upload: vanthuan

Post on 28-Jul-2018

215 views

Category:

Documents


0 download

TRANSCRIPT

1

Wireless Healthcare System

Final Report

Zhihui Qiu, Minghuan Zhao

Tufts University

Dec 2014

2

Contents

1. Instruction ............................................................................................ 3

2. Motion detection Algorithm ................................................................. 4

2.1 Classification Algorithm ............................................................... 4

2.2 Standing up and sitting down detection .................................. 7

3. Android application development ......................................................... 8

3.1. UI design ..................................................................................... 8

3.2. Application design ....................................................................... 9

4. Contiki ............................................................................................... 10

4.1 Introduction ................................................................................ 10

4.2 IEEE 802.15.4 standard .............................................................. 10

4.3 Cooja .......................................................................................... 11

4.4 Routing protocol for Low power and Lossy Networks ............... 12

4.4.1 Visualize RPL .................................................................... 12

4.4.2 RPL neighbor discovery .................................................... 14

4.5 Future Contiki ............................................................................. 17

4.6 Zolertia Z1 ................................................................................. 17

4.6.1 Introduction Z1 and its components ................................... 17

4.6.2 Zolertia Z1 Test ................................................................. 18

5. Conclusion ......................................................................................... 20

Reference: .............................................................................................. 20

3

1. Instruction

Recently wearable wireless device is becoming a hot topic. Our project is based on

designing a wearable wireless service for movement detection and body healthcare. In

the future, integrated chip embedded on pendant and bracelet would be perfect for

clients to keep. Whenever client is falling, an emergency call will be dialed

immediately. Meanwhile, based on Contiki Operating System, other applications like

monitor body temperature and blood pressure will all possible in the future. In this

project, we developed a prototype framework for body healthcare service.

In Figure 1, motes like Zolertia Z1, Moto cellphone and server are all played an

improtant role in this framework. Motes on the one hand collect client’s information

like position and temperature in the werable ends. After data processing on chip, final

result will be sent to border router. In this project, we detect client’s movement. A new

algorithm has been proposed. Separate behaviors can be detected by this algorithm.

Typical behavior like walking, running, walking, standing, sitting and falling are

designed as test behavior. After the data processing part in motes or cellphone, the

final result has been sent to server data base. The slight different is that motes will

sent border router first and border router will send request to server and transmit

information collected to data base. However cellphone just connect to server data base.

The existence of border router is to save power consumption. In this case mote could

just send information in a short range to border router instead of start an Internet

service. Usually motes consume AA battery and works for several months. Meanwhile,

wireless personal area network (WPAN) has limited transmit range usually 10 meters.

After that, both border router and Moto cellphones are connect to Internet service

store information to data base.

Figure 1. Project Framework

In 2014 CES, a lot of wearable device has been showed. What many observer and

4

consumers fell is lots of internets, logs of caution, and not much worth buying…yet.

Wearable device is not yet popular as cellphones. However, many companies are still

working on this are. Samsung has published its new smart watch Samsung Gear S in

market. Apple watch is also on its way. Other new brand like Misfit Flash and Pebble

Steel are trying to be part of producer in wearable device. What’s more, wearable

device is more than smart watch and necklace. Smart glove helps workers to test

temperate and recognize RFID. Smart healthcare helps pregnant woman to monitor

their baby. Even smart close and smart furniture are all possible area. Internet of

things, in a word, will make our life wonderful and more convenient.

2. Motion detection Algorithm

To detect the user’s motions we have to design algorithms to recognize different

pattern of user. Our motion detection algorithm combines with two different

algorithms. For the first algorithm we use classification in machine learning to

distinguish standing still, walking running and falling down based on the data

collected by accelerometer. Another algorithm is to detect standing up and sitting

down based on the gravity sensor.

2.1 Classification Algorithm

To detect standing still, walking, running and falling we find that those patterns

have different accelerometer values in 3 axis. In the following figure we collect the

value of accelerometer from walking, running, falling and followed by standing up

and sitting down. Then sample rate is 100 times per second. The following figure

indicates the changing value in about 65 seconds. You can easily find out that it is

different between each pattern.

5

Figure 2. Walking, Running, Falling Pattern

As soon as we know there are different values in a period when you are walking,

running falling and standing still. We can design an algorithm to distinguish those

patterns, but as we don’t know which position the phone is when the user is using the

phone. So we decide to have the absolutely value of 3 axis. One better way is to take

the magnitude sun of each vector. It can not only provide an absolute value, at the

same time it decrease the computation of classification. The following figure is the

magnitude of vector sum.

Figure 3. Magnitude of vactor sum

We can clearly find out that of 4 different patterns. So what our algorithm does is

try to recognize 4 different patterns. As we know that a significant falling last for 0.8

seconds. So our detection window is set to be 80 samples (remind: sample rate is 100

samples/second). Then we get the standard deviation, average value and max value of

80 sample points. It is showed in the following figure.

6

Figure 4. Std mean and max of samples

Then we try to find how those patterns can different from each other. The basic

concept we are using is classification. If we can find for each pattern those points

clustering at certain value. Then we can easily find a way to differentiate those

patterns. So the following figure is we put those value in 3D plot.

Figure 5. Clustering

7

And we can find that different pattern do clustering at some value. For example the

standing still point clustering at the location, which is very close to [0,0,0]. And

walking is a little away from [0,0,0]. For the lefts side of the figure we can tell those

points indicate running and the rest where max value is very high is falling.

So the idea comes out to be like this. We have 4 center points for each pattern.

When a new points come in. We have to decide which pattern it belongs to just to

calculate the distance between the new given value to the center points we have.

If we set 0 represent standing still, 1 for walking, 2 for running and 3 for falling.

The result of the data we collected above is like the following figure:

Figure 6. Result of test data

We can see in this test we start from standing still to walking to running and to

falling. And this is how our algorithm works for distinguish standing, walking,

running and falling.

2.2 Standing up and sitting down detection

For standing up and sitting down which is finished in 0.2 to 0.4 seconds. The last

algorithm is not that fast detect and some time can have a wrong detection. So we

develop a now algorithm to detect standing up and sitting down which is based the

gravity sensor. The reason we choice gravity sensor is that it is pretty stable because it

8

automatically subtracts the acceleration from the value in accelerometer.

To implement the algorithm we have the data from the accelerometer. In our

algorithm we have to know the position of the phone. And we can get the position of

phone by simply compare the value of each axis. If the max value is from x axis the

phone is horizontal, if it is y axis it is vertical. In the algorithm we detect the standing

up and sitting down based on the following 2 positions of the phone. We call the first

one position is vertical and the second one the horizontal. When the phone changes

from vertical to horizontal, we know it's a sitting down. And for horizontal to vertical

transaction is standing up. The biggest advantage of this algorithm is its detection

speed. Because we don’t need to collect 80 points to do the calculation then give the

results. This algorithm has less delay than the last one.

Figure 7. 2 position of phone

3. Android application development

In our Android application development we use Moto-G as our test device. The

application has following features: Motion detection, Voice announcements,

Adjustable Sensitivity and Auto Online Update. And the phone consists with UI

design and algorithm implementation

3.1. UI design

The following figure is the UI design of our phone. We display the raw data from

9

the accelerometer and gravity sensor on the screen because we are using those 2

sensors in our design, which can also help with our debug. Then we have a start and

stop button to start and stop the motion detection. In the following 2 rows we have

some button to adjust the sensitivity of our motion detection. We also have a small

server supported by this app. In the application server website we display the data

from those sensors and show the status of phone.

Figure 8. UI design and web layout

3.2. Application design

In our application we use Java programming language and Eclipse to implement the

Android phone application. We start from the Tolga’s shaker demo and then get the

help in the debug server. Based on those demos we begin to learn how to use those

sensors and how to set a server in an Android application.

In the application there are following modules there code are in the appendix:

The UI module mainly consists with what we can see in the soft ware. It helps

display the 2 row of text data. And several button module which can be used to

10

interact with the application.

The sensor module mainly consists how to get the data from 2 sensors and set the

resolution of sample rate. In the on sensor change function we can right code when

sensor changes value.

The main implementation of algorithm is in the on sensor change function. We set

an array of size 80 in the function when array is full; we begin to process the data in

the array. We can calculate the standard deviation, max value and average of the 80

samples. And classify the results to certain pattern based on our experience.

Another very important module is sensitive change module. As we do the training

from a very large number of data set. But the performance may vary from individuals.

So by implementing this module the user can adjust the sensitivity of each pattern to

improve the accuracy of detection.

4. Contiki

4.1 Introduction

Contiki is an open-source operating system especially designed for Internet of

things. Contiki is designed to run low-power microcontrollers. That makes this system

low-power consumption and could be used in time –long running devices like

industrial monitor and wireless router.

Contiki is implemented in C language and has been ported to a number of

microcontroller architectures, including the Texas Instruments MSP430 and Atmel

AVR. [1]In this report we choose MSP430. In [2], they have shown that dynamic

loading and unloading of programs and services is feasible in a resource constrained

system, while keeping the base system lightweight and compact. In the recently

research, Contiki security issue has been solved by supporting the mandatory AES128

Counter with CBC-MAC (CCM) mode. More futures will be talked in the last part of

this chapter.

4.2 IEEE 802.15.4 standard

Contiki is especially friendly for personal area network. That is all this project is

focusing on. In this case, Contiki is the perfect candidate. In 802.15.4, its goal is to

product standard that enabled by low-cost, low-power communications. The

frequency bands may include 868–868.6 MHz, 902–928 MHz, 2400–2483.5 MHz,

11

314–316 MHz, 430–434 MHz, and 779–787 MHz band in China and 950–956 MHz

in Japan [3]. However, due to the lamination of power consummation, the coverage

range is usually less than 10 meters. Meanwhile, the peak data for WPAN (wireless

personal network) is constrained by 250 kbps.

4.3 Cooja

Cooja is a simulation tool design especially for Contiki operating system. Recently

Instant Contiki chooses Cooja as build-in software. Instant Contiki just likes a system

image. Popular Virtual machine service provider like VMWare and Virtual box could

install this image in a really convenient way.

Figure 9. Desktop of Instant Contiki

In Figure 9, Cooja and Wireshark are installed as default choice. Cooja provides

almost all broads simulation for contiki. Actually we can consider Cooja as

professional simulation tool just designed for Contiki.

Figure 10. Cooja Simulation Interface

As we can see form Figure 10, network topology has been showed on the left. 11

motes are allocated. One of them labeled 1 is the border-router. When it runs, traffic

12

will be showed as arrowed line on network topology. Also radio environment also

supported. The coverage of one mote is easily observed. The one tool in the middle is

the output of all of simulated motes. Instead of printing in shell, Cooja just offer all

debug information for motes. In the real motes, one another simple way is to monitor

information by plugging a serial port line. Automatically, debug information will send

it back to computer terminal. Other tools can also be found in its tools menu.

Actually, simulation in Cooja really decreases the product cycle. It takes more time

to figure out a bug in burning program in real motes. However, simulation offers a

chance to test some of logical mistakes. Anyway, simulation is still in the basic level

of product cycle. Moe complex problem may appear in the real motes. For instance, in

our project accelerator sensor is not active in the simulation. The best way to test this

is to burning the program in the real motes.

4.4 Routing protocol for Low power and Lossy Networks

4.4.1 Visualize RPL

Contiki used a Routing protocol for Low power and Lossy Networks (RPL). In

Cooja, visualize this routing protocol is not easy. It is probably better to just access to

every motes including border router in web browser. Based on the topology in figure,

here is some result in Figure 11 and 12.

Figure 11. border router information in web browser

13

Figure 12. Motes information in web browser

As we can observe from Figure 11, in the column neighbors, 10 other motes’ IPs

(IPv6) address are listed. Routes column demonstrate the next hop to the destination.

However, in this case all motes are laid in the broader-router’s coverage. That means

router could access to any motes in one hop. The next hop to destination should be

them self. Consider the topology in Figure 13. Motes 6 is out of router’s coverage.

Figure 13. Motes out of the router’s coverage

14

Figure 14. Web browser information for motes out of router’s coverage

In Figure 14, the next hop to aaaa::212:7406:4:404 (mote 6) is

fe80::212:7404:4:404 (mote 4). That also means even though mote 6 is out of range to

router, we can still access to it by talking to mote 4. That simple request is based on

neighbor discovery in RPL.

4.4.2 RPL neighbor discovery

Two important concepts in RPL is Directed Acyclic Graph (DAG) – a directed

graph with no cycles exists. And Destination Oriented DAG (DODAG) – a DAG

rooted at a single destination. This is because all the nodes want to connect with the

single border router to get the access to the Internet. So it should be rooted at a single

destination, at the same time it don’t want to waste power so the router protocol

should avoid the cycle in the routing. The Figure 15 shows the difference between the

DAG and DODAG.

15

Figure 15. Topology of DAG and DODAG

So In the simple nodes and border router based network DODAG is the ideal

topology. To develop a DODAG network we should define a node’s relative position

within a DODAG with the respect to the DODAG root. For neighbor discovery in the

6LoWPAN RPL defines a new ICMPv6 message with three possible types: DAG

information Object (DIO): carried information that allows a node to discover an RPL

Instance, learn its configuration parameters and select DODAG parents. DAG

Information Solicitation (DIS): solicit a DODAG Information Object from RPL node

Destination Advertisement Object (DAO) – used to propagate destination information

upwards along the DODAG. And for neighbor discovery there are following methods

for the each node to process and decide which node to be its parents:

1. Nodes periodically send link-local multicast DIO messages.

2. Stability or detection of routing inconsistencies influences the rate of DIO

messages.

3. Nodes listen for DIOs and use their information to join a new DODAG, or to

maintain an existing DODAG.

4. Nodes may use a DIS message to solicit a DIO.

5. Based on information in the DIOs the node chooses parents that minimize path cost

to the DODAG root.

The result: Upward routes towards the DODAG root. Figure 16 should how each

nodes use the metrics to decide which node to be its parents.

16

Figure 16. DODAG example

One thing should be mention is that each node only know its parents and have no

idea with its child. And the metric are decided by the Link properties (Reliability,

Latency) and Node properties (Powered on not).Now we have the DODAG, then the

network can begin to process DAO, which issued for Nodes inform parents of their

presence and reachability to descendants by sending a DAO message, Node capable

of maintaining routing state → aggregate routes and Node incapable of maintaining

routing state → attach a next-hop address to the reverse route stack contained within

the DAO message. Figure 17 shows an example of how DAO works.

Figure 17. DAO working principle

1. H sends a DAO message to F indication the availability of H, F adds the next-hop

and forwards the message to I.

2. G sends a DAO message to F indication the availability of G, F adds the next-hop

and forwards the message to I.

3. F sends a DAO message to I indication the availability of F.

4. I aggregates the routes and sends a DAO advertising (F-I).

This is all about RPL in the 6LoWPAN and the neighbor discovery is included in the

17

content of RPL.

4.5 Future Contiki

Contiki is still a new operating system comparing to Windows, Android and Linux.

Since Contiki 2.7 is published, many people are looking for possible improvements.

When it comes to application of an idea, better API always make it efficient.

However, put the examples in the Instant Contiki aside, other files did not offer

friendly enough APIs. For examples, the http shake hand protocols have to be finished

by ourselves. Considering it is a young OS, it is tolerable to develop our own

protocols. One of the wonderful things about Contiki is its examples. However, so

many old version of example could be cleaned up. Or it may mislead the reader. Even

though this example will totally work in this version, it may change in the next

version. Bug and patches need to be found and fixed.

There may even more thing to do right now. Internet of things is not popular as

Internet itself. This new-born OS for internet of things need bigger reputation that

makes it better.

4.6 Zolertia Z1

4.6.1 Introduction Z1 and its components

Z1 by Zolertia is a low-power wireless sensor network (WSN) module that serves

as a general purpose development platform for WSN developments, researchers,

enthusiasts and hobbyists.[4] Also Z1 is the board we choose to apply our project. It is

widely used in area like personal healthcare monitoring, environmental monitoring

and emergency detectors.

18

Figure 18. Components of Z1

Figure 18 is from Zolertia’s datasheet. The main components include

MSP430f2617, CC2420, ADXL345, M25P16 and TMP102. MSP430 is one type of

microcontroller from TI. CC2420 a single-chip 2.4 GHz IEEE 802.15.4 compliant RF

transceiver designed for low power and low voltage wireless applications. ADL345

and TMP102 are embedded sensors. ADL345 is 3-Axis digital accelerometer.

TMP102 stands for low-power digital temperature sensor. Our movement detection

algorithm is based on ADL345, which is an accelerometer. More details about

ADL345 should be mentioned. The ADXL345 is a small, thin, low power, 3-axis

accelerometer with high resolution (13-bit) measurement at up to ±16 g. Digital

output data is formatted as 16-bit twos complement and is accessible through either a

SPI (3- or 4-wire) or I2C digital interface.

4.6.2 Zolertia Z1 Test

In our project we choose Zolertia Z1 as our test board. Figure 19 shows the picture

of Z1.

19

Figure 19. Zolertia board

Figure 20. Test result

According to Figure 20, information is printed to computer terminal. In this project,

whenever this board is reset, it will print its basic information like its MAC, node id

and channel check rate. In our project, I set up an array to hold collected data from

accelerometer. This array size is 80. Every 0.02 clock size it will send a set of <x,y,z>

to this array. Then these 80 points array is forced to movement detection check.

According to the closest detection point, movement like standing, walking, running

and falling will be detected. However, due to the accuracy of detection, detection time

interval is quite small. Falling, on the other hand, need to pay more attention on.

Whenever falling happens, it will stop for a few seconds to check whether it is a real

20

falling or not. That is also convenient for a server to get this falling information.

5. Conclusion

Movement detection project offers whole service from hardware data collection to

software data processing, form data wireless transmission to data storage in data base.

Testing from Z1 motes shows a quite accurate result. Standing is really sensitive.

Running and walking is distinguishable. Falling is the easiest way to catch. Because

of that, some inevitable erroneous judgments may appear. When the false falling

happens, it is a better way to confirm from user that is a true falling. Android could

solve that problem by setting up a reset bottom for the conformation.

Testing from Moto cellphone could offer more complex algorithm. However,

limited by size of ROM in embedded system (Z1 motes), more complex computing

could move to server and send back to motes. This solution based on pretty good

Internet Service environment. Or the communication delay will make terrible user

experience.

Reference:

[1] CST Group at FU Berlin. Scatterweb Embedded Sensor Board. Web page. Visited

2003-10-21. http://www.scatterweb.com/]

[2]Dunkels, Adam, Bjorn Gronvall, and Thiemo Voigt. "Contiki-a lightweight and

flexible operating system for tiny networked sensors." Local Computer Networks,

2004. 29th Annual IEEE International Conference on. IEEE, 2004.

[3] IEEE Standards Association. IEEE Standard for Local and metropolitan area

networks Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs),

Amendment 4: Alternative Physical Layer Extension to Support Medical Body Area

Network (MBAN) Services Operating in the 2360 to 2400 MHz Band. Technical

Report IEEE Std 802.15. 4j, 2013.

[4] "Z1 Datasheet," Zolertia, 2010. Available from

http://zolertia.com/sites/default/files/Zolertia-Z1-Datasheet.pdf

[5] P. Kannus, H. Sievä nen, M. Palvanen, T. Jä rvinen, and J.Parkkari,

"Prevention of falls and consequent injuries in elderly people," The Lancet, vol. 366,

no. 9500, pp. 1885-1893, 2005. (Pubitemid 41690118)

[6] C. Rougier, J. Meunier, A. St-Arnaud, J. Rousseau, "Robust video surveillance for

fall detection based on human shape deformation," IEEE Transactions on Circuits and

Systems for Video Technology, vol.21, no.5, pp.611-622, 2011.

21

[7] Maarit Kangas , Antti Konttila, Per Lindgren, Ilkka Winblad, Timo Ja ̈msa ̈ ,

Comparison of low-complexity fall detection algorithms for body attached

accelerometers

[8] Android Developer menu, http://developer.android.com/index.html

[9]P. Thubert. RPL: IPv6 Routing Protocol for Low power and Lossy Networks.IETF,

Internet-Draft draft-ietf-roll-rpl-05, December 2009.

[10] [RFC6775] “Neighbor Discovery Optimization for IPv6 over

Low-PowerWireless Personal Area Networks (6LoWPANs)”, Z. Shelby, S.

Chakrabarti, E.Nordmark, C. Bormann, November 2012

[11] [RFC4919]“IPv6 over Low-Power Wireless Personal Area

Networks(6LoWPANs): Overview, Assumptions, Problem Statement, and Goals”, N.

Kushalnagar, G. Montenegro, C. Schumacher