Assistenzrobotik für die Gesundheitsassistenz - ein ... · Assistive Robotics for Health Assistance - a Contribution towards Evaluating the Practicability by Example of a Mobile

Assistenzrobotik für die Gesundheitsassistenz - ein Beitrag zur Evalu-ierung der Praxistauglichkeit am Beispiel eines mobilen Reha-Roboters1

Assistive Robotics for Health Assistance - a Contribution towardsEvaluating the Practicability by Example of a Mobile Rehab Robot

Horst-Michael Gross, Andrea Scheidig, Markus Eisenbach, Thanh Quang Trinh, Tim WengefeldTechnische Universität Ilmenau, Fachgebiet Neuroinformatik und Kognitive RobotikPF 100565, 98684 Ilmenau Email: [email protected]

KurzfassungDieser Beitrag stellt für das Gebiet der sozialen Assistenzrobotik für die Gesundheitsassistenz einen kompakten Leitfa-den für eine systematische Bestandsaufnahme implementierter Roboterservices und der zugrundeliegenden HRI- undNavigationsbasisleistungen im Rahmen von Funktions- und technischen Nutzertests zur Verfügung. Basierend auf die-sem Leitfaden werden anschließend zwei Fallbeispiele aus dem Bereich der robotischen Gesundheitsassistenz bezüg-lich ihrer Praxistauglichkeit für den Einsatz in realen Seniorenwohnungen und in einem klinischen Umfeld evaluiert.Dabei wird insbesondere das BMBF-Projekt ROREAS (Interaktiver RObotischer REha-Assistent für das Lauftrai-ning von Patienten nach Schlaganfällen) selbstkritisch analysiert, um die Stärken und Schwächen der entwickeltenAssistenzlösung bezüglich ihrer erreichten Praxistauglichkeit im klinischen Einsatzfeld aus technischer Sicht deutlichwerden zu lassen und damit eine ehrliche Bestandsaufnahme des Erreichten möglich zu machen.

AbstractFor the research field of socially assistive robotics for health assistance, this paper provides a compact guideline for asystematic evaluation of implemented services and underlying basic functionalities for HRI and navigation as part offunction tests and technical user trials. Based on this guideline, subsequently two case studies from the field of robotichealth assistance are evaluated with respect to their practical suitability for domestic and clinical application. In particu-lar, the project ROREAS (Robotic Rehabilitation Assistant for walking training of Stroke patients) is analyzed in detail,in order to demonstrate the strengths and weaknesses of the developed assistive solution regarding its practicability forthe clinical use from technical point of view to make an honest inventory of the achievements possible.

1 Motivation

In den letzten zehn Jahren gab es weltweit eine Fülle vonProjekten im Bereich der sozialen Assistenzrobotik fürAlltagsunterstützung und Gesundheitsassistenz. Dabei istes selbst für “Insider” häufig schwierig, ein aussagekräf-tiges und realistisches Gesamtbild über das Funktions-und Servicespektrum und die Praxistauglichkeit der ent-wickelten Robotersysteme samt ihrer Servicefunktionenzu erhalten, da in wissenschaftlichen Publikationen meistzwar Angaben zu den methodisch-technischen Teilleis-tungen zu finden sind, hingegen nur selten oder garnicht konkrete quantitative Ergebnisse von Funktions-und Nutzertests im realen Einsatzfeld mit echten Nut-zern präsentiert werden. Häufig werden in den Publika-tionen sogar nur ausgewählte Teilfunktionen ohne diedazu erforderlichen robotischen Basisleistungen präsen-tiert, wie z.B. Roboter als “Vorturner” für Bewegungs-übungen oder als “Medikamentenerinnerer”, aber ohnedie dazu notwendige, alltagstaugliche Navigation undMensch-Roboter Interaktion (HRI). Zudem wird in Nut-

zerstudien durch “Wizard of Oz”-Experimente häufig ei-ne Autonomie simuliert, die in dieser Form noch gar nichtexistiert, was in der Öffentlichkeit oft zu erheblichenFehleinschätzungen bezüglich der bereits erreichten Pra-xistauglichkeit führt. Gleichzeitig ist es auch auffallend,dass zwar häufig ein detailliertes technisches Benchmar-king von Teilfunktionen (z.B. zur Nutzerwahrnehmungoder zur Hindernisvermeidung) vorgenommen wird, ei-ne Evaluierung des Roboter-Gesamtsystems inklusive derangebotenen Services unter realen Einsatzbedingungenmeist aber noch die seltene Ausnahme ist. Dies führtvor allem bei Außenstehenden zu einer bedenklichen Si-tuation, die von deutlichen Zweifeln an der Robotik biszur völligen Überschätzung ihrer derzeitigen Möglich-keiten geprägt ist. Ursache dafür ist der nicht immer auf-richtige Umgang der Entwickler bezüglich der Autono-mie und der erreichten Robustheit und Praxistauglich-keit ihrer Lösung als Ganzes sowie der Systemstabilitätim Realeinsatz, oft gepaart mit fehlendem Benchmarkingund unzureichender Systemevaluierung in Funktionstestsmit realen Endnutzern.

1Gefördert im Projekt ROREAS durch das Programm “IKT 2020 - Forschung für Innovationen” des BMBF (Förderkennzeichen 16SV6133)

German AAL Conference (AAL), Frankfurt, Germany, pp. 58-67, VDE Verlag 2016

2 Evaluierung der Praxistauglich-keit von Assistenzrobotern

Ziel dieses Beitrages ist es, für zukünftige Publikationenim Bereich der sozialen Assistenzrobotik für den häusli-chen und klinischen Einsatz einen kompakten Leitfadenfür eine systematische und ehrliche Bestandaufnahmegetesteter Roboterservices und der zugrundeliegendenBasisleistungen zur Verfügung zu stellen. Dieser Leitfa-den erfragt möglichst präzise Angaben zur eigentlichenFunktionalität des Roboters und zur Durchführung derFunktions- und Nutzertests unter Realwelt-Bedingungen.Dabei lassen sich vier Themenkomplexe zur Bewertungder Praxistauglichkeit definieren:

Komplex S - Servicespektrum:

S1: Welche Serviceleistungen für die Nutzer sind be-reits verfügbar? Welche davon a) völlig autonomauf dem Roboter, b) nur mit geeigneter Peripherie(z.B. externe Sensoren, Kameras oder Mikrofone),c) nur über Fernsteuerung (remote control) durcheinen telepräsenten Operator?

S2: Welche Basisleistungen der Navigation und HRI ste-hen dem Roboter dafür in welcher Autonomiestufezur Verfügung?

S3: Wie sieht dafür die notwendige IT-Infrastruktur vorOrt aus? Welche Konsequenzen ergeben sich dar-aus für den späteren Praxiseinsatz?

Komplex R - Reifegrad:

R1: Wie ist der Reifegrad des getesteten Robotersystems- handelt es sich noch um ein Labormuster/einenDemonstrator, bereits einen Prototypen oder schonum ein am Markt verfügbares Produkt?

R2: Gab es bereits Funktionstests außerhalb des Labors(wann, wo, mit wem, wie oft, wie lange, unter wel-chen Bedingungen)?

R3: Gab es bereits Nutzertests mit den Endnutzern in derfinalen Einsatzumgebung (wann, wo, mit wem, wieoft, wie lange, unter welchen Bedingungen)?

R4: War dabei technisches oder sozialwissenschaftli-ches Begleitpersonal zugegen, und wo hielt es sichwährend der Tests auf?

R5: Über welchen Zeitraum war der Roboter für denNutzer verfügbar, wie war die Nutzungsquote?

Komplex F - Funktionstests von Basisleistungen: Hierwerden die szenariospezifisch notwendigen Einzelleis-tungen, die Basisleistungen der Navigation und derMensch-Roboter-Interaktion (HRI), funktionell getestetund möglichst auch quantitativ bewertet. Leistungsver-gleiche der Einzelleistungen (Benchmarks) unter Labor-bedingungen und in realer Einsatzumgebung sind anzu-streben, um die Besonderheiten und Schwierigkeiten derEinsatzumgebung zu beurteilen.

F1: Welche Navigationsleistungen wurden getestet undunter welchen konkreten Testbedingungen?

F2: Sind dabei Navigationsprobleme aufgetreten undwie wurden sie quantitativ erfasst, z.B. als An-zahl der Verklemmungen, Kollisionen, Beinahe-Kollisionen, Fehllokalisationen, Verletzungen desPersonal Space, etc. ?

F3: Welche HRI-Leistungen wurden getestet und unterwelchen konkreten Testbedingungen?

F4: Sind dabei HRI-Fehlfunktionen (z.B. der Personen-detektion, des Personentrackings, der Nutzerwie-dererkennung, etc.) aufgetreten?

F5: Welche Erfolgsraten der Basisleistungen wur-den dabei als quantitative Gütemaße ermit-telt (z.B. Zielerreichung, Lokalisierungsgenauig-keit, Nutzerdetektion, Nutzersuche, Nutzerwieder-erkennung, etc.)?

F6: Gab es notwendige manuelle Eingriffe vor und wäh-rend der Tests (z.B. Markierung von No-Go Areas,Präparierung von Hindernissen, Not-Stopps, Ab-laufänderungen, etc.)?

F7: Wurde eine quantitative Bewertung der Komplexitätder Testumgebung vorgenommen?

Komplex N - Nutzertests auf Applikationsebene: Hierinteressieren der Grad der Autonomie und die Praxistaug-lichkeit der Anwendung im Zusammenspiel der einzel-nen Basisleistungen. Wir haben dazu drei Fehlermaße fürdie Qualitätsbeschreibung der Tests auf Applikationsebe-ne definiert:

N1: Unkritische Fehler: Fehler, die autonom durch dieApplikation selbst behandelt werden können, ggf.auch unter Beteiligung des Endnutzers (z.B. An-fahren eines Ruhepunktes bei einem Kontaktver-lust zum Nutzer oder selbständiges Beenden einesBumper-Stopps bei Wissen über Dauer und Lagedes auslösenden Ereignisses)

N2: Kritische Fehler: Fehler, die nur durch das Eingrei-fen eines Operators behebbar sind (z.B die Korrek-tur einer fälschlichen Personenhypothese)

N3: Sehr kritische Fehler: Fehler, welche nicht durchden Eingriff eines Operators behebbar sind, wiez.B. Sensorausfälle

Die Einstufung der Fehler muss immer im Kontext derszenariotypischen Anforderungen erfolgen.Ein wichtige Voraussetzung für Funktions- und Nutzer-tests unter Realwelt- und Praxisbedingungen ist zudemeine objektive Bewertung der Komplexität der Einsatz-umgebung bezüglich ihrer Größe, der zeitlich variablenPräsenz von Personen, der vorherrschenden Lichtverhält-nisse, der Möblierung und der damit verbundenen “Be-engtheit” mit Konsequenzen für die Navigation sowie In-teraktion im verfügbaren Freiraum (↗ F7). Allerdingswerden dazu in vielen Publikationen bislang höchstenssubjektive, qualitative Einschätzungen, wie z.B. “sehr


eng, kaum Freiraum”, “kaum Tageslicht”, “stark bevöl-kert”, jedoch keine objektiven, quantitativen Kennzahlenverwendet. Ein erster Ansatz zur Objektivierung der Testsund zur quantitativen Bewertung der Komplexität der Te-stumgebungen wurde für das häusliche Einsatzfeld be-reits in [1, 2] präsentiert, mit dem Ziel zukünftig auchvergleichende Benchmarks in verschiedenen Einsatzum-gebungen möglich zu machen.Im nachfolgenden Beitrag wird es nach den entsprechen-den Erläuterungen jeweils direkte Verweise auf diesenFragenkatalog geben, wie zum Beispiel (↗ S1).

3 Eigene Fallbeispiele

3.1 Gesundheitsassistenz SERROGA

Abbildung 1: Gesundheitsassistent “Max” in Interaktionmit einer Seniorin in deren privater Wohnung im Rahmendes SERROGA-Projektes.

Basierend auf diesem Leitfaden wurden bereits dieim Rahmen der Forschergruppe SERROGA (SERvice-RObotik für die GesundheitsAssistenz) [3] entwickel-te robotergestützte Gesundheitsassistenz bezüglich ihrerPraxistauglichkeit für den Einsatz in realen Seniorenwoh-nungen evaluiert. Die im Rahmen von SERROGA entwi-ckelte Herangehensweise an die Durchführung von tech-nischen Nutzertests in Seniorenwohnungen wurde erst-mals in [4] und in erweiterter Form in [1] vorgestellt.In Vorbereitung der mehrtägigen Nutzertests mit dem ent-wickelten Demonstrator (↗ R1) erfolgten zunächst in ei-ner wohnungsähnlichen Laborumgebung und darauf auf-bauend in Mitarbeiterwohnungen Funktionstests zu dennotwendigen robotischen Basisleistungen (↗ R2). Dabeiwurden solche Verhaltensweisen wie die autonome Ziel-anfahrt, das automatische Andocken an die Ladestation,das Dem-Nutzer-Folgen und das Suchen des Nutzers be-wertet (↗ F1, F3). Neben dem Nachweis der grundsätz-lichen Funktionsfähigkeit wurden auch objektive Bewer-tungsmaße für die Güte dieser Basisleistungen bestimmt(↗ F5).Bei den Funktionstests in verschiedenen Wohnumgebun-gen war zunächst zu klären, wie realistisch dort vorhan-dene Bedingungen sind, und ob die erreichten Ergebnis-se auch auf andere Wohnungen übertragbar sind. Daherwurden zunächst die räumlichen Eigenschaften der Woh-nungen anhand von navigationsrelevanten Kenngrößen

gegenübergestellt (↗ F7). Diese Kenngrößen ließen sichunmittelbar aus den vorher gelernten Navigationskartenermitteln. Exemplarisch seien hier nochmals einige der in[4] vorgestellten Kenngrößen genannt: a) Grundfläche A:gesamte von Wänden eingeschlossene Fläche der durchden Roboter befahrbaren Räume; b) Freifläche F: Grund-fläche A ohne Möbel; c) befahrbare Fläche B: durchden Roboter kollisionsfrei erreichbare Positionen auf derFreifläche, d) Flächenabdeckung B/A: Verhältnis von be-fahrbarer Fläche zur Grundfläche als Maß, wie zugestellteine Umgebung ist; e) Formfaktor Z: Verhältnis des Um-fangs der befahrbaren Fläche B zur Wurzel dieser Flä-che als Maß für die Konvexität bzw. Zerklüftetheit; f)Wandabstand W: mittlerer Abstand zum nächsten Hin-dernis über der gesamten befahrbaren Fläche; g) Durch-fahrtbreite D: mittlerer Abstand von der Mitte des be-fahrbaren Raumes oder einer Durchfahrt zum nächstenHindernis. Für die nutzerzentrierten Navigationsverhal-ten Folgen und Suchen war auch die Beleuchtungssituati-on der Wohnung zu berücksichtigen, da die Nutzerwahr-nehmung u.a. bildbasiert über Detektionen im frontalenFischaugenkamerabild der SERROGA-Roboter erfolgt.In den Tests wurden daher auch erstmals die wohnungs-spezifischen Beleuchtungsbedingungen erfasst, um derenEinfluss auf die Erkennungsleistungen des Roboters zuobjektivieren und vergleichbar zu machen.Nachdem mit den durchgeführten Funktionstests nach-gewiesen wurde, dass sich die SERROGA-Roboter sta-bil autonom in Wohnungen auch im Zusammenspiel mitPersonen bewegen konnten, fanden im Zeitraum Februarbis April 2015 mit den beiden in SERROGA entwickeltenmobilen Assistenzrobotern Max und Tweety abschließen-de Mehrtagesnutzertests mit vier Senioren der AWO Ser-vicewohnanlage “Am Krämpferufer” und mit fünf Senio-ren der ARTIS Servicewohnanlage Erfurt im Alter von 68bis 92 Jahren in deren eigenen Wohnungen statt (↗ R3).Mit einer Gesamttestzeit von 220 Stunden ohne Anwe-senheit von Fremdpersonen in den Wohnungen gilt diesals einer der bislang längsten Praxistests von autonomenmobilen Assistenzrobotern bei Senioren in deren priva-ten Wohnungen (↗ R4, R5) (Stand 4/2015). Diese Nut-zertests bestätigen, dass die in SERROGA entwickeltenAssistenzroboter trotz sehr unterschiedlicher Einsatzbe-dingungen über einen mehrtägigen Zeitraum stabil funk-tionieren und durch die Senioren gut zu bedienen waren.Es zeigt sich aber auch, dass die Länge der Tests von einbis drei Tagen noch nicht ausreichte, um eine gewisseAlltagsnormalität zu erreichen. Nutzungsintensität, Nut-zungsmuster und die Bewertung des Nutzungserlebnissesmussten daher im Kontext eines außer-alltäglichen Erleb-nisses interpretiert werden und ließen nur Tendenzen füreine reale Alltagsnutzung erkennen. Detaillierte Ergeb-nisse der Funktions- der Nutzertests sind [1, 4] zu ent-nehmen.

3.2 Rehabilitationsassistent ROREAS

Basierend auf dieser Herangehensweise soll nachfolgendeines unserer Robotikprojekte aus dem Gebiet der kli-


nischen sozialen Assistenzrobotik, das ROREAS-Projekt[5, 2, 6, 7]), so aufgearbeitet werden, dass die Stärken undSchwächen der entwickelten Assistenzlösung bezüglichihrer erreichten Praxistauglichkeit im klinischen Einsatz-feld aus technischer Sicht deutlich werden. Dabei kom-men auch wiederum Gütemaße zur Bewertung des ge-zeigten Navigations- und Interaktionsverhaltens der Ro-boter zum Einsatz.In [2] wurde das seit Mitte 2013 laufende BMBF-ProjektROREAS (Interaktiver RObotischer REha-Assistent fürdas Lauf- und Orientierungstraining von Patienten nachSchlaganfällen) vorgestellt. Dessen Zielstellung ist dieEntwicklung eines robotischen Reha-Assistenten für einEigentraining von Patienten zur Durchführung einesLauf- und später auch Orientierungstrainings in der klini-schen Schlaganfallnachsorge. Von Projektbeginn an wur-de die Technikentwicklung durch die Einbindung derTechniknutzer - in diesem Fall Schlaganfallpatienten -begleitet. Unter Berücksichtigung medizinischer, techni-scher und sozialwissenschaftlicher Aspekte wurden fürden robotischen Reha-Assistenten unterschiedliche Sze-narien definiert, von denen bislang der Laufcoach zumLauftraining praktisch realisiert und in Funktions- undNutzertests bewertet wurde. Der Laufcoach wurde da-bei durch solche Reha-Patienten genutzt, die bereits dieErlaubnis erhalten hatten, mithilfe eines Laufhilfsmittelsselbständig zu gehen. Insbesondere sollte er ängstliche,antriebsgestörte oder selbstunsichere Patienten unterstüt-zen, sich zunächst auf dem Gang und dann in einem im-mer größer werden Umfeld in der Klinik sicher zu be-wegen (↗ S1). Details zum Ablauf einer typischen Trai-ningseinheit mit dem Laufcoach wurden bereits in [2]vorgestellt, in Kurzform findet sich dies auch noch ein-mal im folgenden Abschnitt.

Abbildung 2: Robotischer Reha-Assistent in der Funk-tion eines Laufcoach-Demonstrators (↗ R1) basierendauf einem SCITOS G3 Roboter der Firma MetraLabsGmbH Ilmenau während eines Gangtrainings in der m&i-Fachklinik Bad Liebenstein (Deutschland).

4 Wie praxistauglich ist ROREAS?

4.1 Dreistufige Teststrategie

Im Rahmen des ROREAS-Projektes wurde für den entwi-ckelten Demonstrator (↗ R1) eine dreistufige Teststrate-

gie angewandt, mit der die nötigen Funktions- und Nut-zertests in der Einsatzumgebung der Reha-Klinik unterrealen Alltagsbedingungen konzipiert und durchgeführtwurden. Aus Sicherheitsgründen erfolgte in Stufe 1 nochkeine Interaktion des Laufcoachs mit realen Patienten vorOrt, stattdessen wurden sie zur Untersuchung aller not-wendigen Basisverhalten und Skills (siehe Abb. 3) ersetztdurch eingewiesene Mitarbeiter unseres Robotik Labs.Darauf aufbauend wurde in Stufe 2 der Laufcoach mitsogenannten Patienten-Doubles, Projektfremde oder kli-nische Mitarbeiter, die das Laufverhalten von Schlagan-fallpatienten imitierten, getestet (↗ R2, R3). Erst nach-dem dies erfolgreich war und sich ROREAS als stabilund genügend zuverlässig erwiesen hatte, wurden in Stufe3 Nutzertests mit freiwilligen Schlaganfall-Patienten be-gonnen.Im Rahmen dieses Beitrages soll anhand der erreich-ten methodisch-technischen Ergebnisse der Nutzertestsdie Frage diskutiert werden, ob der Reha-Assistent Lauf-coach aus technischer Sicht im klinischen Einsatzfeld be-reits autonom agieren kann. Möglich wird dies durch dasstabile Funktionieren wesentlicher funktionaler Elemen-te des Trainingsablaufs, unabhängig von der Komplexitätdes Trainingsprogramms. Ein typischer Trainingsablaufmit dem Laufcoach umfasst folgende Teilabschnitte (↗S2):

TA1: Fahrt des Roboters zum Patientenzimmer auf einegeeignete Warteposition und Warten auf die Kon-taktaufnahme durch den Patienten

TA2: Kontaktaufnahme des Patienten mit dem Roboterdurch Hinsetzen auf die Startposition (ein Stuhl vordem Zimmer)

TA3: Heranfahren des Roboters an den Patienten zur Ini-tiierung der Interaktion

TA4: Dialog zwischen Roboter und Patient und Aus-wahl des Trainingsprogramms, Lernen des aktuel-len Nutzermodells nach Aufstehen vom Stuhl

TA5: Begleiten des Patienten (Folgen) bis zur erneutenKontaktaufnahme durch den Patienten durch Hin-setzen (an Ruhepunkten oder am Ziel)

TA6: Interaktion mit dem Patienten an den Ruhepunktenund am Ziel getriggert durch Sitzenderkennung

TA7: Auswertung der Trainingsergebnisse und Ab-schlussdialog vor dem Zimmer des Patienten

Zur Umsetzung dieses Trainingsablauf werden zahlreicherobust funktionierende Basisleistungen benötigt, in der fi-nalen Ausbaustufe müssen alle völlig autonom funktio-nieren. Die wichtigsten von ihnen wurden im Rahmender Funktions- und Nutzertests zwecks kontinuierlicherOptimierung immer wieder technisch evaluiert, um einezunehmend größere Autonomie zu erreichen. Hierzu zäh-len (siehe Abb. 3, orange hinterlegt):

• Zielanfahrten


Touch

Display

Display &

Speaker

2D/3D Perception

and Mapping Reactive Navigation

Metric Path Planning with

User-centered aspects

Topological Path Planning

across multiple levels

Visual Person

Detection

Laser-based

Person Detection

Self-Localization &

Floor Estimation Person Tracking

Person

Re-Identification

Deadlock

Recognition

Search for Waiting

Position

Speech

Synthesis

Elevator Filling

Analysis

Person Motion

Prediction

Eye contact

with Person

Guide

User

Follow User

(with Goal)

Approach

User Drive to Goal

Wait Aside &

Give Way

Contact

Person

GUI State Machine

Odometry Laser

scanners Cameras

2D / RGB-D

GUI

Head with

Eyes Differential Drive

Skill

Layer

Hardware

Layer

Behavior

Layer

Control

Layer

Sensors Actuators

Application

Layer

Walking

Training

Orientation

Training

Elevator

Training

Exploration

Training

User / Environment

Behavior State Machine

Upper-Body

Orientation Estim.

Training Database

Sitting down

Detection

Abbildung 3: Übersicht über die benötigten Basisleistungen des Demonstrators “Laufcoach” (aus [5, 2, 6]). In derApplication Layer grau hinterlegt sind weitere mögliche Demonstratoren, die bislang aber noch nicht realisiert wur-den. Der Laufcoach wird durch zwei State Machines (Control Layer) und kombinierte Basisverhalten (Behavior Layer)umgesetzt, die dazu eine Vielzahl von robust funktionierenden Erkennungs-, Navigations- und Interaktionsleistungenbenötigen (Skill Layer) (↗ S2). Sowohl die Behaviors als auch die Skills werden nachfolgend als Basisleistungenbezeichnet, die in Funktions- und technischen Nutzertests auf ihre Praxistauglichkeit bewertet werden müssen.

• Erkennung des Hinsetzens des Patienten

• Heranfahren an den Patienten zwecks Erreichbar-keit des Touch-Displays

• Personentracking und Personenwiedererkennung

• Begleiten des Patienten durch Hinterherfahren oh-ne Unterschreiten eines minimalen und Über-schreiten eines maximalen Begleitabstandes

• höfliche Navigation gegenüber Passanten ohneVerletzung ihres Personal Space

Zur Korrektur noch fehlerhafter Entscheidungen der Ba-sisleistungen und damit zur möglichst unterbrechungs-freien Durchführung der Nutzertests wurde im Rah-men von ROREAS ein tabletbasiertes Korrekturinterface(Control Tablet) entwickelt, dass einem Testbeobachtermanuelle Eingriffsmöglichkeiten bietet. Das über WLANangebundene Control Tablet erlaubt ihm, mit ausreichendAbstand zum Roboter (>5 m) die Tests zu begleiten (↗R4), so dass er das Verhalten des Roboters nicht be-einflusst und trotzdem auf Ereignisse und beobachtbareProbleme reagieren kann. Dadurch konnte noch vor Ab-schluss der Algorithmenentwicklung und der Funktions-tests und damit deutlich frühzeitiger als sonst üblich mitNutzertests in der realen Umgebung begonnen werden,was für den engen zeitlichen Projektablauf wichtig war.Außerdem erhielten die Entwickler durch die mittels desControl Tablets protokollierten Eingriffe des Beobachtersein sehr spezifisches und objektives Feedback, in wel-cher Situation die Basisleistungen noch Probleme haben.

Gleichzeitig stand so ein weiteres Gütemaß für das au-tonome Agieren des Reha-Assistenten zur Verfügung, indem die Anzahl notwendiger Ferneingriffe pro Wegstre-cke erfasst wurde (↗ F6). Für die spätere Auswertungwurden in allen Tests auf dem Roboter zudem Logdatenmitgeschnitten. Diese speicherten den inneren Zustanddes Roboters und ausgewählte Sensordaten, um ein Fehl-verhalten im Nachgang nachvollziehen und interpretierenzu können.

4.2 Stufe 1: Funktionstests mit Projektmit-arbeitern

Bevor der Laufcoach in Nutzertests mit Patienten evalu-iert werden konnte, mussten zunächst alle grundlegendeBasisverhalten in der klinischen Einsatzumgebung getes-tet und bewertet werden. Erste umfangreiche Funktions-tests erfolgten mit ROREAS in der m&i Fachklinik inBad Liebenstein im Februar 2015 über 4 Tage, wobei ca.15.000 m Fahrtstrecke zurückgelegt wurden. Die Funk-tionstests wurden in verschiedenen Etagen der Klinikund zu unterschiedlichen Tageszeiten durchgeführt, umdie Basisverhalten unter möglichst vielfältigen Klinik-bedingungen zu bewerten, wie z.B. räumliche Charakte-ristik, Beleuchtungsverhältnisse oder Personendichte aufden Gängen. Ein detaillierter Überblick über die wäh-rend der Funktionstests getesteten Basisverhalten autono-me Zielanfahrt, Lotsen und Folgen einer Person im Kon-text der Nutzung der Skills 2D-Umgebungserfassung,3D-Umgebungserfassung, Personal Space, Engstellenbe-handlung, Rechtsfahren und Personenwiedererkennung


(↗ F1, F3) und die ermittelten Erfolgsraten (↗ F5) wur-de bereits in [2] gegeben und soll daher hier nicht wie-derholt werden. Manuelle Eingriffe per Control Tablet er-folgten bei diesen Tests nur bei der Wiedererkennung undbei Not-Stopps vor möglichen Kollisionen (↗ F6). ImUnterschied zur SERROGA (siehe Abschnitt 3.1) konn-te wegen der Weitläufigkeit und der Erscheinungsviel-falt der Klinik bislang allerdings noch keine quantitativeBewertung der Komplexität der Einsatzumgebung vorge-nommen werden (↗ F7).

4.3 Stufe 2: Nutzertests mit Patienten-Doubles

Nach erfolgreichem Abschluss der Funktionstests mitProjektmitarbeitern wurde der Laufcoach erstmals imMai 2015 und später erneut vor jedem Nutzertest im Rah-men von simulierten Nutzertests mit Patienten-Doublesgetestet (↗ R2, R3). Diese Tests unter Einbeziehung vonKlinikmitarbeitern und Projektfremden, die das Laufver-halten der Patienten imitierten und dabei auch Laufhilfs-mittel benutzten, waren sozusagen die Generalprobe fürdie noch ausstehenden Nutzertests. Getestet wurden da-bei neben der Stabilität der benötigten HRI- & Naviga-tionsbasisleistungen (↗ F1, F3) vor allem die eigentli-che Trainingsapplikation und die Schlüssigkeit und Ver-ständlichkeit des Trainingsablauf sowie die Notwendig-keit manueller Eingriffe durch den Beobachter mittelsdes Control Tablets (↗ F6). Im Fokus dieser Tests stan-den damit erstmals der Grad der Autonomie und die Pra-xistauglichkeit der Anwendung im Zusammenspiel dereinzelnen Basisleistungen mit Blick auf die Qualitätsbe-schreibung der Tests auf Applikationsebene. Wie bei denFunktionstests war außerdem ein externer Versuchsbeob-achter (Observer) anwesend (↗ R4), der mit ausreichendAbstand zum Roboter die Tests begleitete und die nochaufgetretenen technischen Probleme dokumentierte. Ei-ne detaillierte quantitative Erfassung der Erfolgsraten derBasisleistungen (↗ F5) und der ermittelten Fehler aufApplikationsebene (↗ N1-N3) erfolgte aus Beherrsch-barkeitsgründen auf dieser Stufe jedoch nicht sondernwar Gegenstand der folgenden Nutzertests.

4.4 Stufe 3: Nutzertests mit PatientenAufbauend auf den Tests mit Patienten-Doubles wurdenim weiteren Projektverlauf im Zeitraum von Juni 2015 bisMärz 2016 fünf Kampagnen von Nutzertest durchgeführt(↗ R3). Während die Nutzertests im Juni und Septem-ber 2015 noch kürzere und fest vorgegebene Laufwegemit einer Trainingsdauer von ca. 20 Minuten umfassten,wurde der Laufcoach für die Nutzertests im November2015 und im Januar 2016 so erweitert, dass auch beliebi-ge, durch den Nutzer frei wählbare Laufstrecken möglichwaren und eine Trainingseinheit, je nach Fitness des Pati-enten, bis zu einer Stunde dauern konnte (↗ R5). In allenNutzertests hatte der Testbeobachter die Möglichkeit, perFerneingriff noch fehlende Basisleistungen (z.B. Sitzen-derkennung) zu emulieren oder noch fehlerhafte Erken-

nungsleistungen zu korrigieren. Ziel war es, von Nutzer-test zu Nutzertest die Anzahl der Korrektureingriffe zureduzieren und die Autonomie des Systems zu erhöhen.Daher wird in den nachfolgend beschriebenen Nutzer-tests der Fokus der Auswertung auf die jeweils noch feh-lende Autonomie, d.h. auf die noch notwendigen Fern-eingriffe, gelegt, um eine ehrliche Problemdiskussion zuermöglichen. In allen Nutzertests kamen als freiwilligeTester nur solche Schlaganfallpatienten zum Einsatz, dievon ihrem behandelnden Arzt bereits die Freigabe erhal-ten hatten, in Eigenverantwortung ein Lauftraining als Ei-gentraining zu betreiben. Auf die Details der Einweisungder Patienten am Tage der Nutzertests und die Durchfüh-rung von Probedurchläufen (Instruktionsgänge) soll hierallerdings nicht weiter eingegangen werden.

4.4.1 Nutzertest Nr. 1 im Juni 2015

In diesem ersten Nutzertest mit freiwilligen Patienten wa-ren bereits alle Teilabschnitte des Trainingsablaufs (sie-he Abschnitt 4.1) zu absolvieren, allerdings mit unter-schiedlicher Autonomie und Unterstützung durch Fer-neingriffe (↗ S1, F6). Dabei ergab sich folgender Stand:

Teilabschnitt Erreichte AutonomieTA1: Fahrt zum Zimmer 100% autonomTA2: Sitzenderkennung 100% per FerneingriffTA3: Heranfahren an Patienten 100 % autonomTA4: Dialog und Auswahl nur 1 TrainingsstreckeTA5: Begleiten des Patienten teilautonom, tw. mit

FerneingriffenTA6: Interakt. an Ruhepunkten 100% per FerneingriffTA7: Auswertung/Verabschied. 100% autonom

Außerdem wurden die Testbedingungen bewusst nochvereinfacht und in die ruhigen Nebenzeiten (nach-mittags und abends) gelegt, um die Störungen durchunbeteiligte Passanten zu minimieren. Die Trainings-applikation war noch stark eingeschränkt, und dieTrainingsstrecken waren kurz. Wichtige Angaben zuden Ergebnissen dieses technischen Nutzertests sindder nachfolgenden Tabelle zu entnehmen (↗ R5):

Kriterien AngabenZeitraum: 6/2015, 2 TageAnzahl Patienten: 5Anzahl Durchläufe: 11 (Gesamt)Verwend. Gehhilfsmittel: RollatorenGefahrene Gesamtstrecke: 873 mTrainingszeit: 62 minMittlere Dauer pro Pat.: 5 min 30 sAnzahl Passanten: 78Eingriffe per Contr. Tablet: 19

Navigationsprobleme (↗ F2): Während dieses Tests be-rührte der Roboter 3 mal Hindernisse und musste durcheinen manuellen Eingriff aus dieser Situation befreit wer-den (↗ N3). Gründe für diese Form der Kollision warenDrehbewegungen des Roboters in der Nähe von Wän-den und Berührungen der dort verankerten Handläufe, dievon den Laserscanner oder den 3D-Kameras des Robo-ters aufgrund ihrer Befestigungshöhe nicht erfasst wer-


den konnten. Diese Probleme waren in den vorangegan-genen Funktionstests nicht aufgetreten und kamen daherüberraschend. 2 mal fuhr der Roboter sehr nah an Per-sonen heran (< 15 cm) und verletzte damit ihren Perso-nal Space. Gründe dafür waren plötzlich aus Zimmernheraustretende Personen und eng überholende Passanten.19 mal musste der Beobachter per Ferneingriff reagie-ren (↗ F6), um unsichere oder fehlerhafte Hypothesendes Wiedererkennungsmoduls bei Abrissen des Perso-nentrackings zu bestätigen bzw. zu korrigieren (↗ N2).Nur in zwei Fällen waren es falsche Hypothesen, alle an-deren waren zu unsicher und erforderten lediglich Bestä-tigung. Hier wurde deutlich, dass die kleidungsbasierteWiedererkennung von Patienten gegenüber den Tests mitMitarbeitern und Patienten-Doubles eine höhere Schwie-rigkeit aufwies.Die Ursachenforschung für die beobachteten Fehler er-gab weiterhin, dass bestimmte Fehler im Ablauf der Ap-plikation noch nicht korrigiert werden konnten (↗ N3),die Erfassungsbereiche der bislang verwendeten Panora-makamera auf dem Kopf zu gering waren, so dass alsZwischenlösung für die nächsten Nutzertests eine zusätz-liche Frontkamera am Display montiert werden sollte,und dass das Heranfahren an Patienten noch suboptimalwar, da die Abstände für eine gute Bedienbarkeit desTouch-Displays zu groß waren.Zwischenfazit: Es wurde in diesem Test sehr deutlich,dass das Trainingsszenario unbedingt erweitert werdenmuss im Sinne längerer Trainingsstrecken und dem Be-reitstellen von Auswahlmöglichkeiten, da der Ablauf fürdie Patienten zu wenig herausfordernd war. Außerdemsollten weitere Korrekturmöglichkeiten in der Ablauf-steuerung hinzugefügt werden, um auftretende Fehlergleich während des Tests per Ferneingriff auch korrigie-ren zu können. Zudem sollten sensorisch noch nicht er-fassbare kritische Bereiche, wie z.B. Handläufe in denGängen der Klinik, in der Navigationskarte als NoGo-Gebiete eingezeichnet werden (↗ F6).

4.4.2 Nutzertest Nr. 2 im September 2015

Im Nachgang von Nutzertest 1 wurde eine zusätzlicheKamera zur Erkennung von sitzenden Personen am Ro-boter installiert, außerdem wurde der Algorithmus fürdas Heranfahren an sitzende Personen verbessert (neuerzweistufiger Ansatz: erst Heranfahren an eine Positionmit optimalem Abstand, dann Anpassung der Orientie-rung des Roboters). Damit konnte im August 2015 noch-mals ein Nutzertest mit Patienten-Doubles durchgeführtwerden, ehe es im September 2015 zum zweiten Nutzer-test mit freiwilligen Patienten kam (↗ R2, R3). Im Un-terschied zum Nutzertest 1 wurde hier ein anspruchsvol-leres Setting gewählt - das Training erfolgte auch wäh-rend der Stoßzeiten, zudem konnten die Patienten länge-re Trainingsrouten wählen. Immer noch vorhandene Ein-schränkungen dieses Tests waren aber (↗ S1): keine voll-ständige Autonomie (die Sitzenderkennung war zwar ak-tiviert zur Funktionsprüfung, aber noch nicht in die Ap-plikation integriert und musste daher noch manuell per

Ferneingriff getriggert werden), die Trainingsapplikationhatte nur eingeschränkte Wahlmöglichkeiten (der Patientkonnte wahlweise nur die linke oder rechte Teilstreckebis zum Ende des Ganges wählen). Bezüglich der er-reichten Autonomie ergab sich damit folgender Stand:

Teilabschnitt Erreichte AutonomieTA1: Fahrt zum Zimmer 100% autonomTA2: Sitzenderkennung autonom im Test. noch

nicht integriert100% per Ferneingriff

TA3: Heranfahren an Patienten 100% autonomTA4: Dialog und Auswahl 2 TrainingsstreckenTA5: Begleiten des Patienten teilautonom, tw. mit

FerneingriffenTA6: Interakt. an Ruhepunkten siehe TA2TA7: Auswertung/Verabschied. 100% autonom

Die Angaben zur Testdurchführung sind wiederumder nachfolgenden Tabelle zu entnehmen (↗ R5):

Kriterien AngabenZeitraum: 9/2015, 2 TageAnzahl Patienten: 7Anzahl Durchläufe: 21 (Gesamt)Verwend. Gehhilfsmittel: 3 x Rollatoren

2 x Gehstöcke1 x 4-Punkt-Gehstock1 x ohne

Gefahrene Gesamtstrecke: 2109 mTrainingszeit: 142 minMittlere Dauer pro Pat.: 6 min 45 sAnzahl Passanten: 353

16,8 pro Durchlauf16,7 pro 100 m2,5 pro Minute

Eingriffe per Contr. Tablet: 56

Navigationsprobleme (↗ F2): Während dieses Tests be-rührte der Roboter nur 1 mal ein Hindernis (ein herausstehendes Rad eines Transportwagens) und musste durcheinen manuellen Eingriff aus dieser Situationen befreitwerden (↗ N3). Grund dafür war ein Ausfall des 3D-Sensors, so dass das Rad nicht wahrgenommen wurde.Einmal fuhr der Roboter zu nah an eine in einem Roll-stuhl sitzende Person heran, weil die Personendetektiondiese Person übersehen hatte (↗ F4).56 mal musste der Beobachter per Ferneingriff reagieren,um unsichere oder fehlerhafte Hypothesen des Wiederer-kennungsmoduls bei Abrissen des Personentrackings zubestätigen bzw. zu korrigieren (↗ N2). In neun Fällenwaren es wiederum falsche Hypothesen, alle anderen Fäl-le waren wieder zu unsicher und erforderten lediglich Be-stätigung. Wesentliche Ursachen hierfür waren die größe-ren Distanzen zwischen Roboter und Patient und stärkerwechselnde Beleuchtungsbedingungen auf den längerenLaufstrecken dieser Testreihe. Bezogen auf die Anzahlder Passanten lag die Erkennungsleistung aber in der glei-chen Größenordnung wie die während der Stufe 1, denFunktionstests mit Mitarbeitern.Zwischenfazit: Insgesamt waren immer noch recht vieleKorrektureingriffe nötig (↗ N2) und der Abstand zwi-schen Roboter und Patient war teilweise noch zu groß.


Während dieses zweiten Tests wurde zudem deutlich,dass das Trainingsszenario noch stärker erweitert wer-den muss durch längere Trainingsstrecken und mehr Aus-wahlmöglichkeiten. Außerdem waren weitere Verbesse-rungen an den Basisleistungen erforderlich, so z.B. beider Wiedererkennung des aktuellen Nutzers, weshalb zu-sätzlich Sensorik zur Wiedererkennung eingesetzt wer-den sollte (auf Sonar basierende Peilung des Patienten).

4.4.3 Nutzertest Nr. 3 im November 2015

Bei diesem Test im November 2015 lag der Schwerpunktauf dem erzielbaren Begleitabstand zwischen Patient undRoboter sowie auf noch immer vorhandenen Navigati-onsproblemen beim Trainingsablauf mit Patienten (↗F2). Außerdem wurden während dieses Tests die neuenKomponenten zur Sitzenderkennung und zur peilungsba-sierten Wiedererkennung auf ihre Funktionalität getestet,aber noch nicht in die Applikation integriert (↗ F3). Be-züglich der Autonomie ergab sich jetzt folgender Stand:

Teilabschnitt Erreichte AutonomieTA1: Fahrt zum Zimmer 100% autonomTA2: Sitzenderkennung autonom im Test. noch

nicht integriert100% per Ferneingriff

TA3: Heranfahren an Patienten 100% autonomTA4: Dialog und Auswahl längere Trainingsstre-

ckenTA5: Begleiten des Patienten teilautonom, tw. mit

FerneingriffenTA6: Interakt. an Ruhepunkten siehe TA2TA7: Auswertung/Verabschied. 100% autonom

Angaben zur Testdurchführung sind wiederum tabella-risch aufgelistet (↗ R5):

Kriterien AngabenZeitraum: 11/2015, 2 TageAnzahl Patienten: 4Anzahl Durchläufe: 15 (Gesamt)

4x Instruktionsgang11x Eigentraining

Verwend. Gehhilfsmittel: RollatorenGefahrene Gesamtstrecke: 2714,2 mTrainingszeit: 3h 21 minMittlere Dauer pro Pat.: 50,2 minAnzahl Passanten: 311

20,7 pro Durchlauf11,4 pro 100 m1,54 pro Minute

Begleitabstand: Der Abstand zwischen dem Laufcoachund den Patienten lag während des Trainings mit den Pa-tienten bei durchschnittlich 2,6 m (minimal: 1 m, ma-ximal 8 m) (↗ F5). Der wesentliche Grund für den zuhohen Maximalabstand ist folgender: Nachdem der Pa-tient sich am Ruhepunkt hinsetzt oder sich am Anfangeinloggt, wartet der Roboter bis der Patient vorbei läuftund eine festgelegte Mindestdistanz zum Roboter erreichtist, bevor er dem Patienten folgt. Dieses Verhalten istnötig, damit der Roboter den Patienten beim Passierennicht auf seinem Weg behindert. Wenn der Patient aber

in dieser Phase des Vorbeilaufens kurzzeitig nicht beob-achtbar ist (z.B. durch eine fehlerhafte Personendetektionoder Probleme der Wiedererkennung durch vorbeilaufen-de Passanten), können große Abstände entstehen, bis derRoboter das Vorbeilaufen auch erkannt hat und sich inBewegung setzt, um dem Patienten zu folgen.Probleme: 7 mal fuhr der Roboter sehr nah an Personenheran (< 15 cm) (↗ F4). Gründe dafür waren wieder-um plötzlich aus Zimmern heraustretende Personen undPassanten, die den Roboter sehr dicht überholten.Zwischenfazit: Abgesehen von den noch in die Appli-kation zu integrierenden Funktionalitäten (Sitzenderken-nung, peilungsbasierte Wiedererkennung) erwies sich derLaufcoach schon relativ robust unter den spezifischenKlinikbedingungen. Die Trainingsservices konnten durchdie Patienten genutzt werden, für die nächsten Tests soll-te den Patienten eine vollständige Wahlfreiheit ihrer Trai-ningsstrecke auf der gesamten Ebene überlassen werden.Allerdings erwies sich der Begleitabstand zwischen Pati-ent und Roboter beim Training als noch zu variabel, wasdie Patienten verunsicherte.

4.4.4 Nutzertest Nr. 4 im Januar 2016

Bei diesem Test bildeten die bisherigen, aber auch eineganze Reihe neuer Fragestellungen den Fokus der Pra-xistauglichkeitsuntersuchungen: Begleitabstand Patient-Roboter beim Training, Qualität der Nutzerwiedererken-nung nach Installation einer neuen hochauflösenden Pa-noramakamera (bestehend aus 6 Kameras) mit großemvertikalen Öffnungswinkel für die Sitzenderkennung,Rolle der peilungsbasierten Wiedererkennung, Einflussder Nutzung von Gehhilfsmitteln auf die ansichtsbasierteWiedererkennung, Erkennung sitzender und aufstehenderPersonen sowie das Anfahren sitzender Personen.Von besonderer Bedeutung war bei diesem Test die Fra-gestellung, wie sich das Gesamtverhalten des Laufcoachsverändert, wenn die Korrekturen durch den Beobach-ter per Ferneingriff gegenüber einer vorsichtigen, frühenKorrektur nur noch in wirklich kritischen Ausnahmefäl-len erfolgt (späte Korrektur), in allen anderen Fällen aberdie Autonomie aller Basisleistungen des Roboters gefragtist (↗ F6). In den bisherigen Nutzertests wurde die frü-he Korrektur angewandt. Mit Hinblick auf den finalenNutzertest im März 2016, bei denen der Laufcoach mög-lichst autonom agieren soll, war diese Untersuchung be-sonders wichtig. Folgender Status wurde damit erreicht:

Teilabschnitt Erreichte AutonomieTA1: Fahrt zum Zimmer 100% autonomTA2: Sitzenderkennung 66% autonom

34% per FerneingriffTA3: Heranfahren an Patienten 100% autonomTA4: Dialog und Auswahl freie AuswahlTA5: Begleiten des Patienten teilautonom, tw. mit

FerneingriffenTA6: Interakt. an Ruhepunkten 80% autonom

20% per FerneingriffTA7: Auswertung/Verabschied. 100% autonom

Angaben zur Testdurchführung sind wiederum tabella-


risch aufgelistet (↗ R5):

Kriterien AngabenZeitraum: 1/2016, 2 TageAnzahl Patienten: 3Anzahl Durchläufe: 6 (Gesamt)

2 pro Patient, je1x mit früher Korrektur1x mit später Korrektur

Verwend. Gehhilfsmittel: 2x Gehstock, 1x Vier-punktstock

Gefahrene Gesamtstrecke: 1.966 mTrainingszeit: 1h 54 minMittlere Dauer pro Pat.: 38 minAnzahl Passanten: 235

39,2 pro Durchlauf12 pro 100 m2 pro Minute

Eingriffe per Contr. Tablet: 36 (27 früh, 9 spät)

Begleitabstand: Der Abstand zwischen dem Laufcoachund den Patienten lag während des Trainings mit demlangsam laufenden Patienten bei durchschnittlich 1,2 m(minimal: 0,94 m, maximal 3,0 m) und mit den beidenschnell laufenden Patienten bei durchschnittlich 2,0 m imBereich von 1,1 bis 4,4 m.Nutzerwiedererkennung: Im Vergleich zu den vorange-gangenen Nutzertests war das Personenaufkommen beidiesem Test sehr hoch mit 39,2 Passanten pro Durchlaufbzw. 12 pro 100 m bzw. 2,0 pro Minute. Es zeigte sich,dass die peilungsbasierte Wiedererkennung vorrangig fürdie die Wiedererkennung verantwortlich war, währenddie kleidungsbasierte Wiedererkennung immer dann ent-schied, wenn keine Peilung möglich war (durch Verde-ckungen, Reflexionen, etc.). Im Falle der frühen Korrek-tureingriffe (am ersten Tag) waren in 13 Situationen Ein-griffe nötig (↗ N2). In 9 der 13 Fälle wurden Perso-nen nicht wiedererkannt (sowohl peilungsbasiert als auchkleidungsbasiert), es lag aber auch keine Verwechslungvor. Gründe dafür waren fehlende Detektionen, zeitwei-se vollständige Verdeckungen der Patienten nach Abbie-gung um eine Ecke, Nichterkennung nach Hinsetzen. Ineinem Fall kam es zu einer Verwechslung mit einer na-he vorbeigehenden Person, in den restlichen 3 Fällen warbei der Auswertung kein ersichtlicher Grund für den frü-hen und damit vorschnellen Eingriff des Testbeobachterserkennbar. Außerdem kam es durch die peilungsbasierteWiedererkennung auch zu kurzzeitigen Verwechslungenmit nahestehenden Personen, die jedoch den Ablauf nichtnegativ beeinflussten.Im Vergleich dazu waren bei den späten Korrekturein-griffen (am zweiten Tag) in 9 Situationen Korrekturennotwendig (↗ N2). In den 9 Fällen wurde die Personnicht wiedererkannt (peilungs- und kleidungsbasiert), eslag aber auch keine Verwechslung vor. Auch hier warendie wesentlichen Gründe für die Nichtwiedererkennungdas Hinsetzen, zeitweise vollständige Verdeckungen nachAbbiegung um eine Ecke und fehlende Detektionen vomPersonendetektor. In einem Fall hatte der Roboter zwi-schenzeitlich fälschlicherweise den Durchlauf beendet.Navigationsprobleme: 16 mal fuhr der Roboter zu nah an

Personen heran (< 15 cm), ohne sie zu berühren (↗ F2).Gründe dafür waren ausbleibende Detektionen (meist beiRollstuhlfahrern oder teilweisen Verdeckungen durch an-dere Gegenstände), plötzlich auftauchendes Personal ausZimmern und Passanten, die den Roboter sehr dicht über-holten.Erkennung Hinsetzen & Aufstehen: Eine robuste autono-me Sitzenderkennung ist für den Trainingsbeginn (Initi-alsituation) und für ungeplante Pausen während des Trai-nings erforderlich. Von den 6 Initialsituationen (3 an je-dem Tag) wurden 4 korrekt erkannt (davon 2x leicht ver-zögert mit 10 und 26 s Verzögerung), zwei wurden nichterkannt wegen fehlender Personendetektion und musstenper Ferneingriff getriggert werden (↗ N2). Bei der Sit-zenderkennung während der Pausen waren 24 Erkennun-gen notwendig, davon wurden 20 erkannt (8x sofort, 8xverzögert > 5 sec, 4x deutlich verzögert), 4 mussten perFerneingriff getriggert werden. Grund für die deutlichenVerzögerungen sind die bewusst späten Eingriffe des Be-obachters am zweiten Tag (↗ N2), dadurch kam es vor,dass Personen nicht wiedererkannt wurden, während siesich hinsetzten. Gründe dafür sind zeitweise ausbleiben-de Personendetektionen durch atypische Ansichten beimHinsetzen. In drei Fällen wurden sitzende Personen alsstehend erkannt, dann wieder als sitzend durch Fehler beider Wiedererkennung. Das Aufstehen wurde in 20 von28 Fällen korrekt erkannt, davon 4x länger als 5 Sekun-den verzögert. Gründe für die beobachteten Fehler sindwiederum fehlerhafte Wiedererkennung oder ausbleiben-de Personendetektionen, in einem Fall beendete der Ro-boter zwischenzeitlich fälschlicherweise den Durchlauf.Heranfahren an Sitzende: 28 mal musste an die Patien-ten herangefahren werden, 2 mal wurde durch den Robo-ter abgebrochen, da der Patient nicht mehr erreichbar war(nicht mehr sichtbar wegen fehlender Wiedererkennung).In 26 der erreichten Anfahrpositionen konnten die Patien-ten das Display gut bedienen. Der Winkel zum Patientenwar in 25 von 26 Fällen kleiner als 45o, was Vorausset-zung für eine gute Bedienbarkeit des Touch-Displays ist.Der Abstand war in 15 von 26 Fällen kleiner als 30 cm,so dass das Display ohne bzw. mit wenig Vorbeugen gutbedienbar war. Bei Abständen größer als 30 cm musstensich die Patienten allerdings weit vorbeugen.

5 Fazit und AusblickNach vier zeitintensiven Nutzertests konnte ein Stand er-reicht werden, in dem alle Komponenten integriert wa-ren und autonom liefen und die meisten Basisleistun-gen auch vollständig ohne Korrekturen per Ferneingrifffunktionieren. Einige wenige, aber wichtige Basisleistun-gen, wie die Sitzenderkennung oder die Patientenwieder-erkennung, erforderten während des Trainings gelegent-lich aber noch immer Korrektureingriffe, wenn in be-stimmten Situationen Erkennungen falsch waren oder so-gar ausblieben. Hier hat auch die peilungsbasierte Wie-dererkennung mittels des vom Patienten zu tragendemSonar-Gerätes keine hundertprozentige Robustheit er-bracht, weil sich durch Eigenverdeckungen und akusti-


sche Einflüsse häufig Fehlpeilungen oder Ausfälle erga-ben, die dann per Ferneingriff korrigiert werden muss-ten. Bei der kleidungsbasierten Wiedererkennung wurdentechnische Unzulänglichkeiten der verbauten Panorama-kamera deutlich, deren unzureichende Farbtreue bei star-ken Änderungen der Beleuchtungsbedingungen gelegent-lich zu Problemen der Wiedererkennung während desLaufens führte, die dann ebenfalls per Ferneingriff korri-giert werden mussten. Konkrete Prozentangaben sind hiernicht möglich, da die Anzahl der korrekten Wiedererken-nungen nicht mitprotokolliert wurden.Bei der kamerabasierten Sitzenderkennung traten in 20%der Fälle Defizite auf, die sich sowohl mit den techni-schen Unzulänglichkeiten der Panoramakamera als auchmit der teilweise unzureichenden Erkennung von sitzen-den Personen auf Basis des Größenunterschiedes zwi-schen Stehen und Sitzen erklären lassen. Für einen voll-ständig autonomen praktischen Einsatz reicht diese Er-kennungsrate aber noch nicht aus. Abhilfe wird hier ver-mutlich nur eine echte ansichtsbasierte Erkennung vonSitzposen in 2D oder 3D erbringen. Angesichts der extre-men Vielfalt von möglichen Sitzhaltungen und Ansichts-störungen durch Gehhilfsmittel, Bekleidung und mitge-führten Utensilien stellt dies aber ein sehr anspruchs-volles, neues Erkennungsproblem dar, das bis zum Ab-schluss des Projektes nicht mehr in Angriff genommenwerden kann.Angesichts dieser erkannten Probleme ist für NutzertestNr. 5 im März 2016 keine hundertprozentige Fehlerfrei-heit und damit keine vollständige Autonomie mehr rea-lisierbar. Statt aber auf eine hundertprozentige Fehler-freiheit aller Basisleistungen zu setzen (↗ N1), sollte inder verbleibenden Zeit und in Folgeprojekten nach intel-ligenten Strategien zur autonomen Behandlung von aus-bleibenden Erkennungen (z.B. bei der Wiedererkennungoder der Sitzenderkennung), von neu auftretenden, un-erwarteten Situationen oder von Fehlern im Ablauf desTrainingszyklus gesucht werden. Beispielhaft könnte beieinem Kontaktverlust zum Patienten wegen fehlerhafterWiedererkennung eine Notfallstrategie vereinbart wer-den, nach der der Patient am nächsten Ruhepunkt aufden Roboter wartet, so dass dieser dort und auf dem Wegdorthin gezielt nach ihm suchen kann. Mit Hinblick aufdie angestrebte vollständige Autonomie als Vorausset-zung für eine echte Praxistauglichkeit, muss ehrlich ein-geschätzt werden, dass in ROREAS bis zum Projektendeim März 2016 eine technische Fehlerfreiheit und damiteine wirkliche Praxistauglichkeit nicht erreicht werdenkann.Durch die Möglichkeit der Ferneingriffe ergibt sich fürsozialwissenschaftliche Untersuchungen der Nutzertestsaber zumindest ein vollwertig nutzbarer Trainingsassis-tent. Eine Zielstellung der Nutzertests war aber nebender Bewertung der Praxistauglichkeit aus technischerSicht auch die sozialwissenschaftliche Bewertung desGesamtszenarios Laufcoach hinsichtlich des Trainings-ablaufs und der Art der Vermittlung von Informationenzwischen Patient und Roboter. Darüber hinaus bestandeine weitere Zielstellung in der Bewertung einzelnerKomponenten der robotischen Basisleistungen aus so-

zialwissenschaftlicher Sicht. Betrachtete Fragestellungenumfassten z.B. die Situation des Wartens vor dem Patien-tenzimmer hinsichtlich der Störung bzw. Beeinflussungunbeteiligter Patienten oder des Personals, aber auch dieErreichbarkeit des Roboters durch den Patienten zumStart des Trainingsprogramms. Beim Begleiten des Pati-enten wurde die Entfernung des Roboters zum Patientendurch diesen bezüglich Zufriedenheit und Sicherheit be-wertet. Es soll an dieser Stelle aber ausdrücklich betontwerden, dass diese sozialwissenschaftliche Bewertungder Nutzertests nicht Gegenstand dieses Beitrages war,ausgewählte Ergebnisse dazu werden in [8] vorgestellt.

Danksagung: Die Autoren möchten allen Projektpart-nern des ROREAS-Verbundes ganz herzlich für die ver-trauensvolle und inspirierende Kooperation danken - derMetraLabs GmbH Ilmenau, der “m&i Fachklinik” BadLiebenstein, dem SIBIS Institut für Sozialforschung Ber-lin und der Krankenkasse Barmer GEK.

Literatur[1] Gross, H.-M., Mueller, S., Schroeter, Ch. et al.

(2015). Robot companion for domestic health assi-stance: Implementation, test and case study undereveryday conditions in private apartments. In Proc.Int. Conf. on Intelligent Robots and Systems (IROS),pp. 5992–5999

[2] Scheidig, A., Einhorn, E., Weinrich, Ch. et al.(2015). Robotischer Reha-Assistent zum Lauftrai-ning von Patienten nach Schlaganfall: Erste Ergeb-nisse zum Laufcoach. In Proc. 8th German AALConference (AAL), pp. 436-445

[3] Projektwebseite: www.serroga.de

[4] Scheidig, A., Debes, K., Müller et al. (2015). SER-ROGA: Funktions- und Nutzertests Herangehens-weise und Ergebnisse. In Proc. 8th German AALConference (AAL), pp. 34-43

[5] Gross, H.-M., Debes, K., Einhorn, E. et al. (2014).Mobile robotic rehabilitation assistant for walkingand orientation training of stroke patients: A reporton work in progress. In Proc. IEEE Int. Conf. onSystems, Man, and Cybernetics (SMC), pp. 1880–1887

[6] Gross, H.-M., Scheidig, A., Debes, K. et al. (2016).ROREAS - Robot coach for walking and orientationtraining in clinical post-stroke rehabilitation: Proto-type implementation and evaluation in field trials. toappear: Autonomous Robots (AR)

[7] Projektwebseite: www.roreas.org

[8] Meyer, S., Fricke, Ch. (2016). PatientenzentrierteRoboterentwicklung - Schlüssel zur Nutzerakzep-tanz? Akzeptanzuntersuchungen mit 80 Patienten inder neurologischen Rehabilitation. In Proc. 9th Ger-man AAL Conference (AAL)


Documents

Assistenzrobotik für die Gesundheitsassistenz - ein ... · Assistive Robotics for Health Assistance - a Contribution towards Evaluating the Practicability by Example of a Mobile