Das Wissensportal für IT-Professionals. Entdecke die Tiefe und Breite unseres IT-Contents in exklusiven Themenchannels und Magazinmarken.

SIGS DATACOM GmbH

Lindlaustraße 2c, 53842 Troisdorf

Tel: +49 (0)2241/2341-100

kundenservice@sigs-datacom.de

Der verlängerte Arm in die physische Welt

Testautomatisierung ist ein wesentlicher Teil der Softwareentwicklung. Das Testen von hardwareabhängiger Software kann allerdings schwer durch eine reine Softwarelösung automatisiert getestet werden. Die Zuhilfenahme eines Roboterarms soll physische Interaktionen mit benötigten Geräten im Test ermöglichen. Aus dieser Idee entstand ein akademisches Forschungsprojekt in Kooperation mit einem Unternehmen der IT-Branche, in welchem ein Roboterarm in ein bereits vorhandenes Testautomatisierungsframework integriert werden sollte.

  • 23.04.2021
  • Lesezeit: 9 Minuten
  • 67 Views

Das in der ersten Phase dafür erarbeitete Konzept wurde in einer zweiten Phase anhand eines Anwendungsfalles, der automatisierten Bedienung einer Kaffeemaschine, implementiert und auf Machbarkeit überprüft. Neben der Auswahl eines geeigneten Roboterarms wurden notwendige Hardware- sowie Softwarekonfigurationen, Objekterkennung und ein Vorgehensmodell entwickelt und zusammen in einem Testautomatisierungssystem umgesetzt. Dieser Erfahrungsbericht beschreibt die wesentlichen Phasen sowie Bausteine unserer Lösung.

Den geeigneten Roboter finden

Das automatisierte Testen von Hardware und hardwareabhängiger Software stellt Tester vor Herausforderungen. Seien es Tests von Automaten, Netzwerkgeräten oder Smartphone-Anwendungen. Bei der Verwendung der Geräte während des Tests fallen physikalische Daten verschiedener Sensoren an. Um diese Tests für die Automatisierung wiederholbar zu machen, müssen diese Sensoren durch idente physische Interaktion von außen beeinflusst werden.

Eine Lösung für dieses Problem ist ein Roboterarm. Dieser kann für eine spezifische Aufgabenstellung im Test angepasst werden, indem der Endeffektor (z. B. ein Greifer) getauscht wird. Die Vielfalt verfügbarer Endeffektoren macht den Roboterarm zu einem vielfältig einsetzbaren Testwerkzeug. Die Herausforderung besteht in der Integration des Arms in ein Testframework, der Ausgestaltung des Testprozesses sowie der Konfiguration des Roboterarms für das spezifische Testszenario.

Anhand einer für den Anwendungsfall definierten Kriterienliste wurde eine Marktrecherche durchgeführt. Als geeigneter Roboterarm wurde der Niryo One ausgewählt. Der Roboterarm ist Open Source und stellt verschiedenste Methoden zur Ansteuerung zur Verfügung. Ein weiterer Vorteil ist, dass der Niryo One von einem Raspberry Pi 3B angesteuert wird und dessen Software leicht erweitert werden kann.

Das Testautomatisierungssystem konzipieren

Das Testautomatisierungssystem soll die Möglichkeit bieten, dass Testfälle von einem Tester ohne Programmierkenntnisse erstellt werden können. Die Testfälle werden dazu in Gherkin-Notation beschrieben und in einem Testmanagementwerkzeug abgebildet (in unserem Fall XRay von Xpand IT). Das folgende Beispiel beschreibt ein Szenario, in dem eine saubere Tasse gefunden und unter die Kaffeemaschine gestellt wird:

Given die Tasse ”Tasse1” ist sauber und verfügbar

When Ich die Tasse ”Tasse1” auf die Plattform der Kaffeemaschine stelle

Then die Tasse ”Tasse1” ist auf die Plattform der Kaffeemaschine gestellt worden

Die aus dem Testentwurf resultierenden Feature-Dateien werden für die Testausführung über eine REST-Schnittstelle in ein Testautomatisierungsframework (TAF) geladen.

Jede Zeile mit Gherkin-Schlüsselwort (Given, When, Then, And) ist ein Schritt, der mithilfe der Cucumber-Bibliothek auf zugehörige Funktionen gemappt wird. In diesen Funktionen wird das Verhalten des Roboterarms für den jeweiligen Schritt implementiert.

Das TAF läuft auf einem externen PC und sendet Befehle an den Raspberry Pi 3B-Mikrocomputer innerhalb des Roboterarms. Abbildung 1 zeigt die gesamte Architektur des Systems inklusive der Aufteilung auf alle physische Geräte, interne Softwareprogramme und deren Zusammenhang.

Abb. 1: Testsystem

Hardware-Konfiguration des Roboterarms

Um kontrolliertes Testen zu gewährleisten, muss der Roboterarm samt Umgebung konfiguriert werden. Der Roboterarm muss so auf einer Plattform platziert werden, dass ein Transport ohne Zerlegungen möglich ist. Die Plattform soll die Möglichkeit bieten, lose Kabel zu organisieren und Modifikationen leicht umzusetzen. Um diesen Ansprüchen gerecht zu werden, wurde eine lackierte Holzplatte als Basis gewählt, welche über seitlich montierte Kabelkanäle verfügt.

Der Roboterarm braucht eine Kamera für das Erkennen von Objekten und einen Abstandssensor, um mit Objekten interagieren zu können. Die Spitze der Erweiterung muss mit Silikon umhüllt werden, um den Grip während des Drückens auf einen Gegenstand zu erhöhen. Für die Erweiterung wurde 3-D-Druck verwendet, der Flexibilität im Designprozess bietet. Die Erweiterung wurde an der Spitze des Roboterarms platziert und mittels Schrauben an bereits vorhandenen Löchern befestigt.

Software-Konfiguration des Roboterarms

Das System wurde so konzipiert, dass auf der untersten Schicht das Robot Operating System (ROS) verwendet wird, um Befehle entgegenzunehmen und diese auszuführen. Für ROS-unerfahrene Nutzer wurde eine Python-basierte REST-Schnittstelle entwickelt, die erhaltene Befehle in ROS-Nachrichten umwandelt. Darüber hinaus wurde der Versand von Daten des Abstandssensors sowie während des Tests aufgenommener Bilder im System vorgesehen. Die Bilder werden von einer Raspberry Pi 2-Kamera gemacht, welche direkt über den vorhandenen Anschluss an den Raspberry Pi 3B angesteckt wurde. Zusätzliche Berechnung, wie die Bilderkennung, wurden vom Raspberry Pi 3B durchgeführt.

Objekte erkennen

Es gibt verschiedene Möglichkeiten für die Objekterkennung, einschließlich Deep Learning, Farb- und Merkmalserkennung. Deep-Learning-Algorithmen bieten die Möglichkeit, das System für die Erkennung bestimmter Objekte zu trainieren. Allerdings muss hierfür die Menge der bereitgestellten Daten relativ groß sein und es braucht auch sehr viel Zeit, um ein System dieser Art zu trainieren. Aufgrund der verfügbaren Zeit wurde beschlossen, den Deep-Learning-Ansatz vorerst nicht zu verfolgen.

Für die Objekterkennung in der 3-D-Umgebung wurde die Methode der Farberkennung ausgewählt, da diese einfach zu verwenden und zuverlässig ist. Farbige Aufkleber wurden auf Tassen und auf anderen wichtigen Objekten innerhalb der Testumgebung aufgeklebt. Der Farberkennungsalgorithmus wurde mittels Open Computer Vision (Open-CV)-Bibliothek bereitgestellt. Um eine Farbe zu definieren, wurde diese mit einer oberen und unteren Grenze im HSV-Farbraum festgelegt, um die Farbe unter verschiedenen Lichtbedingungen erfassen zu können.

Für die Erkennung der Symbole auf dem Bedienfeld der Kaffeemaschine wurde der Merkmalserkennungsalgorithmus der Open-CV-Bibliothek ausgewählt. Die zu berücksichtigenden Bedienelemente („Einschalten“, „Kein Wasser“ und das Symbol „Bohnenmenge“) hatten dieselbe Farbe, sodass keine Farbunterscheidung möglich war. Durch die Merkmalserkennung konnten eindeutige Merkmale (z. B. markante Formen eines Objekts) gespeichert und auf einem anderen Bild gefunden werden.

Den Roboterarm bewegen

Nach der Erkennung eines Objekts versucht der Roboterarm das Objekt schrittweise zu erreichen. Ein typisches Ziel wäre das vertikale Zentrieren eines Objekts anhand aufgenommener Fotos. Nach jedem Schritt überprüft der Roboterarm, ob er seine Zielposition erreicht hat, und falls nicht, wie der nächste Schritt auszusehen hat. Mit dieser schrittweisen Annäherung zentriert der Roboterarm alle Achsen, sodass der Endeffektor perfekt auf das Zielobjekt ausgerichtet ist. Das Zentrieren eines Objekts geschieht rein basierend auf Bilderkennung. Nach dem Ausrichten aller Achsen verwendet der Roboterarm den Abstandssensor, um sich dem Objekt anzunähern. Dies geschieht ebenfalls in mehreren Schritten, um etwaige Messfehler besser korrigieren zu können.

Vorgehensmodell für die Implementierung

Die während des Forschungsprojekts angefallenen Aufgaben wurden in einem Vorschlag für ein Vorgehensmodell für die Integration eines Roboterarms in ein TAF zusammengefasst. Das Modell sieht die Rollen HardwareingenieurIn, TestautomatisiererIn und TestmanagerIn vor.

Ein signifikanter Aufwand fällt in der Anfangsphase bei der Einrichtung der Umgebung samt Vorbereitung des Roboterarms, wie in Abbildung 2 dargestellt, an.

Abb. 2: Einrichtung der Umgebung

Für jedes neue Gerät werden die in Abbildung 3 dargestellten Schritte ausgeführt.

Abb. 3: Neues Gerät integrieren

Abbildung 4 fasst die Aufgaben der Erstellung eines neuen Testfalls zusammen

Abb. 4: Neuen Testfall erstellen

Fazit

Im Rahmen dieses Forschungsprojekts wurde ein vorhandenes, auf Gherkin-Notation basierendes TAF so erweitert, dass Interaktionen mit physischen Geräten als Testschritte abgebildet werden können. Damit ist es Testern möglich, Integrationstests für Hardware und Hardware-nahe Software in ihrem gewohnten Werkzeugset zu automatisieren und so den bestehenden Leistungsumfang zu erhöhen.

Es wurde dazu ein universell einsetzbares Testautomatisierungssystem implementiert, das für die verschiedensten Testszenarien eingesetzt werden kann. Die Aufrüstbarkeit und Modularität des beschriebenen Systems ermöglicht die Interaktion der verschiedensten physischen Testobjekte innerhalb des Arbeitsbereichs des Roboterarms. Die Modularität erlaubt, dass einzelne Bestandteile, wie beispielsweise die Objekterkennung, leicht durch andere Techniken ersetzt werden können.

Praxistauglichkeit

Die Praxistauglichkeit wurde am Anwendungsfall der automatisierten Bedienung einer Kaffeemaschine überprüft. Folgender Testfall wurde zugrunde gelegt:

Given Kaffeemaschine ist bereit

And Tasse „Tasse1“ ist sauber und verfügbar

When Ich einen „kleinen“ Kaffee mit Stärke „2“ auswähle

Then die Kaffeemaschine bereitet einen „kleinen“ Kaffee mit Stärke „2“ in der Tasse „Tasse1“ zu

Der Testfall wurde wie oben beschrieben im Testframework umgesetzt (4 Schritte, 62 Funktionen, 11 Klassen, 600 Lines of Codes zuzüglich 300 Lines of Code am Roboter) und anschließend mehrfach durchgeführt. Ein Video eines erfolgreichen Testlaufs kann unter https://www.youtube.com/watch?v=s7qlxi_ TZoA abgerufen werden.
Ein Problem entstand bei der Merkmalserkennung des Symbols der Bohnenmenge. Die Merkmale, die benutzt wurden, um unterschiedliche Mengen von Bohnen zu unterscheiden, waren zu ähnlich, was zu einer Fehlerrate von 60 Prozent bei diesem Schritt geführt hat. Die restlichen Schritte wurden erfolgreich und zuverlässig bei jeder Wiederholung durchgeführt.

Für das Projekt wurden insgesamt 700 Arbeitsstunden aufgewendet.

Ausblick

Für das Problem der mangelhaften Symbolerkennung „Bohnenmenge“ soll in einem zukünftigen Forschungsprojekt ein Deep-Learning-Ansatz implementiert werden. Auch die Verwendung eines hochwertigeren und genaueren Abstandssensors in Kombination mit der Speicherung bereits gefundener Koordinaten soll weiter erforscht werden. In Projekten des Kooperationspartners wird das implementierte Testautomatisierungssystem für den Integrationstest mit Automaten, Netzwerkgeräten sowie mobilen Anwendungen eingesetzt und weiterentwickelt

. . .


Artikel teilen