Matching SmartHouse Technology to Needs of the Disabled and

Elderly

Genevieve Davies, Nirmalie Wiratunga, Bruce Taylor and Susan Craw

THEROBERT GORDON

UNIVERSITYABERDEEN

School of ComputingScott Sutherland School

Overview

• SmartHouse Technology

• Case Representation

• Iterative Retrieval

• Evaluation

SmartHouse Technology

Humidity sensorLight

IRPressure Mat

Remote ControlWall SwitchThermostat

SwitchWater Level

Windows OpenWindow Sensor

Access RampBasinBath

BlindsClock Display

TimerCommunity Alarm

CookerCurtains

DishwasherExtractor Fan

Fridge FreezerLight

Medication DispenserMicrowave

OvenPC

Entry PhoneRadiator

SinkTelephone

StereoTV

Washing MachineWC

SmartHouse Textual Cases

... Ms M is an indoor wheelchair user with cerebral palsy. She is a tenant in her own ground-floor flat, and whilst living moderately independently, did have support from care workers to assist her in getting dressed and bathed... She required an intercom that was both hands free and with video so that she could operate it from her wheel chair ... also electrically operated locks were fitted on her external door ...

wheel-chair-indoor

wheel-chair-outdoor

house-type care-staff able-into-bath

Yes unknown ground- floor-flat

Yes with-help

Electrically-operated-locks-external-door

Intercom-front-door

Yes Video-hands-free

Case Representation

ChallengingBehaviour (11)

Mobility (13)

Dexterity (6)

General (3)

Personal (6)

Home (6)

Preferences (4)

PreviousCare (2)

CareStaff (1)

CognitiveAbilities (12)

Pro

blem

spa

ce:

pers

on d

escr

iptio

n MovementRelated (5)

CookerRelated (6)

WaterRelated (5)

HearingAids (3)

RemoteAlarm (1)

Controllers (2)

Phone (3)

Security(2)

VisualAids (3)

PowerWindows (1)

Bathroom (2)

Doors (8)

Taps (2)

FieldBusArchitecture (1)FieldBusArchitecture (1)

Sol

utio

n sp

ace:

Sm

artH

ouse

Dev

ices

Retrieval With a DT Index

Casebase

Relevant Cases

Most SimilarCases

Case Base

C4.5 Decision Tree Index

k-Nearest Neighbour Similarity Matching

pro

gre

ss o

f re

trie

val

Vote

Tcl adaptation rules

witch $idx { 0 {ProcBathroomAdapt()} 1 {ProcControllerAdapt()} 2 {ProcCookerDetectorAdapt()} 3 {ProcDoorAdapt()}

Tcl iterative retrieval

for {set i 0} {$i < $Counter} {incr i} { ProcMultipleConcepts() $i ProcRetrieveCases() $i ProcRetrieveAttributes() $i ProcWeightedAttributes() $i ProcAskUser() $i}...

Set concept

Retrieval Example

• Insufficient cases for one shot retrieval• Deal with each device separately

PoweredWindows: 15 casesN (15 cases, 100%)

OpenDoorInside = Able InfoGain: 0.1711

PoweredWindows: 2 casesY (1 case, 50%), N (1 ex, 50%)

OpenDoorInside = Unable InfoGain: 0.1711

PoweredWindows: 6 casesN (6 ex, 100%)

OpenDoorInside = AbleWithDifficulty InfoGain: 0.1711

Cases:23

PoweredWindows:Y (1 case), N (22 cases)

Y (1 case, 50%), N (1 case, 50%)

Task Decomposition

MovementRelated (5)

CookerRelated (6)

WaterRelated (5)

HearingAids (3)

RemoteAlarm (1)

Controllers (2)

Phone (3)

Security(2)

VisualAids (3)

PowerWindows (1)

Bathroom (2)

Doors (8)

Taps (2)

FieldBusArchitecture (1)FieldBusArchitecture (1)

Sol

utio

n sp

ace:

Sm

artH

ouse

Dev

ices

1

2

3

44

Generalised Concept

CookerRelated Devices

CaseX: Value CaseY: Value

auto-cooker-shut-off {gas, heat, timer} N

detectors-over-cooker {gas, heat, smoke} unknown

alarm-for-carers N N

cooker-isolation-alarm N N

fire-alarm Y N

gas-alarm Y N

F Needed Not-Needed

• Summarise each device group / sub-task• Create index tree for each sub-task

Iterative Retrieval

P = probe caseCB = case basedevice-groups = 14

FOREACH sub-task {1 TO device-groups}

concept <= generalised-concept (sub-task)tree <= build-tree (concept, CB)neighbours <= traverse (tree, P)k-sim-cases <= kNN (neighbours, P, sim-metric)sub-solution <= majority-solution (k-sim-cases)

END FOREACH

Evaluation

• Leave-one-out testing– 23 cases (11 + 12 provided by domain expert)– real case used separately as probe to system– 22 cases in case base

• User Testing– cases created by expert– A and B fewer device requirements– C more challenging

• Retrieval Strategies– Single, one-shot – Multiple, iterative

Quality of System SolutionDoors Device Group 

Solution Categories

System Expert TP TN FP FN

alarm-when-open No No 0 1 0 0

contacts-on-external-doors Yes No 0 0 1 0

contacts-on-bedroom-door No No 0 1 0 0

contacts-on-bathroom-door No No 0 1 0 0

contacts-on-kitchen-door No No 0 1 0 0

intercom-to-front-door Audio Video-HF 0 0 1 0

powered-external-doors Yes Yes 1 0 0 0

electric-locks-external-doors No Yes 0 0 0 1

• Overlap Sim = (TP+TN)/(TP+TN+FP+FN)• Recall (R)=TP/ (TP+FN)• Precision (P)= TP / (TP+FP)• Fmeasure (F)= 2PR/(P+R)

Leave-One-Out Testing

• Multiple – improvement in 8 of the 14 device groups– overall solution quality Sim 0.91% F 0.64%

• Interesting alternatives suggested– flood detectors vs. push-to-operate– pendant activated community alarm vs. pager

• Overly expensive suggestions– environment and lighting controllers– person with some mobility problems

User Testing

• Patient A and B– 2 out of 3 devices suggested for A– failure with controllers due to sparse case base– all 5 devices identified for B– decreased solution quality with increased neighbourhood– but Single achieves similar results

• Patient C more challenging– 7 of the 9 devices identified by Multiple, compared to 2– Multiple reused solutions from 9 different cases – R drops from 0.64 to 0.18 with Single

Conclusions

• Task decomposition is easy when there are fewer interactions between sub-tasks.

• Standard DT-based iterative retrieval strategy– focus on a sub-task at a time– addition of generalised concept

• Best use of case base with multiple indices

• Iterative retrieval provided better quality solutions compared to one-shot retrieval– empirical evaluation– subjective evaluation

• Use of multiple cases to solve different parts of a problem case was well received