The general explanation:
What is happening right now?
Wir befinden uns auf dem Gelände des Deutschen Rettungsrobotik-Zentrums. Wir treffen uns im DRZ Konsortium, um eine Woche lang alle Robotersysteme von den Verbundpartnern zu integrieren. Das bedeutet, dass jeder Roboter dieselbe Sprache spricht und die Informationen in ein großes gemeinsames System gebracht wird. So soll jeder Benutzer sehen, welche Informationen die einzelnen Robotersysteme liefern.
And what does that look like in particular?
Jeder Verbundpartner hat eigenes Roboterequipment von der Drohne bis zum Bodenroboter in seinem Spezialgebiet und diese verschiedenen Systeme in ein gemeinsames System zu integrieren, das ist die Hauptaufgabe. Die andere Hauptaufgabe ist es, dass dann für die Anwender, also für die Feuerwehr bzw. die Sicherheitskräfte so zu visualisieren und darzustellen, dass die Zielgruppe im Einsatz damit umgehen können.
Interviews zum Integrationssprint 2021
Interview mit Jan Quenzel zum Demonstrator „D1“
Was testet ihr hier gerade?
Wir testen gerade unsere autonomen Assistenzsysteme. Dazu gehört die Entfernungsmessung umliegender Objekte mit einem LiDAR-Scanner, mit der wir unsere Position relativ zur Umgebung bestimmen können. Mit den daraus gewonnenen Daten können wir Karten von der Umgebung erstellen und mit der Drohne autonome Explorationen durchführen. Die autonome Exploration funktioniert wie bei einem Rasenmähroboter, nur im dreidimensionalen Raum. Bei der Drohne gibt es allerdings die Schwierigkeit, dass sie nicht einfach stehen bleiben kann, sondern die Position halten muss, um nicht abzustürzen.
Hat euch die Corona-Krise bei der Entwicklung irgendwie beeinflusst?
Ja, hat sie. Es war für uns wesentlich schwieriger im Team zu arbeiten. Unser Team besteht aus unterschiedlichen Leuten, die für spezielle Komponenten unseres Systems zuständig sind. Die Integration der verschiedenen Komponenten wurde um einiges erschwert.
Wir brauchen für Testflüge einen Sicherheitspiloten und die jeweiligen Experten für die verschiedenen Funktionen der Drohne.
Durch Simulationen konnten wir allerdings einige Sachen testen, sodass unser Rückstand geringer ausfällt.
Was ist das Besondere an eurer Arbeit in diesem Projekt?
Die Autonomie unserer Drohne ist besonders. Im Vergleich zu Konsumerdrohnen können wir auch in Gebäuden und ohne GPS fliegen. Dadurch kann unser System Inspektionen an Strukturen vornehmen. Zusätzlich kann unsere Drohne durch den 360°-Laserscanner auch nachts fliegen, da sie nicht auf Licht für die Kameras angewiesen ist.
Unsere Drohne kann sogar Gebiete autonom erkunden, von der sie keine Vorinformationen hat.
Interview mit Alexander Miller zum
Demonstrator „D4“
Was testet ihr hier gerade?
Wir arbeiten gerade gemeinsam mit dem @Fraunhofer.FKIE am Modularisierungskonzept. Es gibt mehrere Nutzlastmodule mit verschiedenen Sensoren und Aktoren und wir versuchen diese auf unseren Robotern interoparabel zu integrieren. Diese Module sollen sowohl auf dem D3 als auch auf dem D4 arbeiten können. Die Nutzlastmodule sind roboterunabhänging und haben Laserscanner und Kameras und ähnliches integriert, die während des Betriebs unter den Robotern einsatzspezifisch tauschbar sein sollen.
Hat euch die Corona-Krise bei der Entwicklung irgendwie beeinflusst?
Prinzipiell Ja! Da wir nicht unbedingt am Standort arbeiten konnten, mussten wir unsere Pläne ändern. Sachen, die wir sonst erst später erledigt hätten, mussten wir ins Homeofficebüro verlagern, um dort am Projektfortschritt weiterzuarbeiten. Wir haben umstrukturiert und Aufgaben, die vor Ort gemacht werden müssen weiter nach hinten geschoben.
Was ist das Besondere an eurer Arbeit in diesem Projekt?
Wir arbeiten am D4, der speziell für Industrieanlagen gedacht ist und präventiv arbeiten soll. Er fährt also autark Patrouille und sucht nach Entstehungsbränden oder anderen Gefahrensituationen. Das gibt es so noch nicht im Einsatz. Typischerweise haben Industriehallen Brandschutzanlagen wie Sprinklersysteme, die sektorweise Brände löschen. Unser System soll Brandherde frühzeitig erkennen, damit Brandschutzanlagen erst gar nicht auslösen müssen und der Schaden begrenzt wird. Der Roboter erstellt eine Umgebungskarte und könnte dynamisch Kurse abfahren, so dass man keine Festinstallationen benötigt und im Falle eines Brandes die Schäden klein hält.
Interview mit Kevin Daun zum Demonstrator „D2“
Was testet ihr hier gerade?
Wir testen gerade, wie ein Bodenroboter den Einsatzkräften bei einem Einsturzszenario helfen kann. Das umfasst bei uns das Fahren in engem, schwierigem Terrain und das Öffnen einer verschlossenen Tür. Es gibt ein Einsturzszenario, bei dem ein Teil verschüttet ist, der erst von einem anderen Roboter freigeräumt wird, damit wir Zugriff zum Szenario haben. Anschließend müssen wir durch enge Röhren, eine Treppe hoch und über unebenen Boden fahren. Am Ende befindet sich eine Tür, die wir öffnen müssen, um durch diese Tür hindurchzufahren und in dem Raum eine potenziell vermisste Person zu suchen.
Wir testen dabei die Hardware und die Software des Systems. Zum einen testen wir, ob wir das Szenario physisch bewältigen können. Also wo die Schwierigkeiten beim Fahren und die generellen Grenzen des Systems sind. Auf der anderen Seite testen wir auch die Software, Da es eine neue Umgebung ist, die wir in der Form noch nicht gesehen haben. Es gibt viel zu erproben, einzustellen und nachzujustieren.
Hat euch die Corona-Krise bei der Entwicklung irgendwie beeinflusst?
Die Coronakrise hat Entwicklungen in Präsenz verhindert. Alle Leute waren zuhause und haben remote gearbeitet. Das hat unsere Prozesse verändert. Im Team haben wir deutlich mehr Besprechungen digital durchgeführt, die Dokumentation hat sich verändert und auch in der Entwicklung sind wir auf simulationsbasierte Verfahren umgestiegen, um Kontakte und Infektionsrisiken in den Laboren möglichst gering zu halten. Wir haben ein Teil der Arbeiten zuerst in Simulationen entwickelt und anschließend auf dem Bodenroboter getestet. Die Erkenntnisse, die wir aus den Simulationen gewinnen konnten, haben uns dabei geholfen.
Was ist das Besondere an eurer Arbeit in diesem Projekt?
Uns geht es darum, den Operator – die Rettungskraft, die den Roboter steuert – zu unterstützen. Dafür möchten wir neue und besondere Methoden entwickeln, sodass Rettungskräfte im Einsatz effizienter arbeiten können und dass der Robotersteuerer den Einsatz der Rettungskräfte vor Ort sicherer machen kann.
Stand der Technik ist, dass aktuell eingesetzte Roboter komplett teleoperiert gesteuert werden. Das bedeutet, jemand steuert den Roboter manuell mit einem Gamepad, fast wie in einem Computerspiel. Das ist sehr schwierig und anstrengend und schränkt die Einsatzmöglichkeiten des Systems stark ein, wenn z.B. keine Funkverbindung möglich ist. Dort können wir einen deutlichen Mehrwert bringen und weiterhelfen.
Interview mit Stefan Rilling zur Lagebilddarstellung
Was testet ihr hier gerade?
Wir testen hier das Lagebildsystem, dass wir im IAIS entwickelt haben und die Prozessassistenz, die die Kollegen vom DFKI entwickelt haben und deren Zusammenspiel mit allen Robotern. Die Lagedarstellung dient dazu den Führungs- und Einsatzkräften im Einsatz die Lage zu visualisieren und die Daten, die von den Robotern gesammelt werden zu verarbeiten und darzustellen.
Die Prozessassistenz hilft den Führungskräften im Einsatz, sich im vordefinierten Einsatzablauf zurechtzufinden und die nächsten Schritte zu planen. Das dient der Unterstützung der Einsatzkräfte.
Beides sind unterschiedliche Softwaresysteme, die im Zentralen System vom A-DRZ – dem A-DRZ Backend – gekoppelt werden, sodass die Daten von allen unterschiedlichen Systemen im A-DRZ Verbund eingesehen und entsprechend aufbereitet werden können.
Hat euch die Corona-Krise bei der Entwicklung irgendwie beeinflusst?
Dadurch, dass wir viel Software entwickeln, sind wir in der glücklichen Position eher weniger durch fehlende Präsenz beeinflusst zu sein. Wir konnten viel im Homeoffice arbeiten und die nötigen Besprechungen untereinander gut über Telefonkonferenzen durchführen.
Die Integrationstests mit allen Beteiligten und den Robotern vor Ort haben jedoch gefehlt. So etwas kann man auch nicht durch Remotelösungen ersetzen.
Was ist das Besondere an eurer Arbeit in diesem Projekt?
Das besondere an unserer Arbeit ist, dass wir uns nicht um Teilprobleme kümmern, die ein einzelner Roboter erledigt, sondern wir integrieren alle entwickelten Systeme im Projekt zu einem Ganzen.
Egal ob nur eine Drohne, eine Drohne und ein Roboter oder drei Roboter eingesetzt werden, die gesammelten Daten fließen in dasselbe System. Das neue an unserem System ist, dass es nicht auf einen speziellen Roboter angepasst ist, sondern es für ganz unterschiedliche Roboter mit unterschiedlichen Fähigkeiten und Sensoren funktioniert.
Interview mit Stefan Soltau zum Thema Löschapplikation
Was testet ihr hier gerade?
Wir testen eine weiterentwickelte Version des Löschmoduls. Das Löschmodul kann Flammen detektieren, lokalisieren und anschließend autonom ablöschen. Da das Modul neu aufgebaut ist, wird es erst generell getestet und dann an den Demonstrator D4 angebunden. Wir haben das Modul in Bad Oldesloe entwickelt und passen es hier an den D4 an, damit die Verbindung über die Schnittstellen funktioniert und das Modul mit dem Roboter kommunizieren kann.
Hat euch die Corona-Krise bei der Entwicklung irgendwie beeinflusst?
Das Integrieren ist schwieriger geworden. Da wir größere Entwicklungsschritte örtlich getrennt voneinander erarbeiten und weniger Integrationssprints haben, ist es sehr viel Integrationsarbeit, wenn alle zusammentreffen. Ich hätte da lieber mehrere Treffen gehabt, um kleinschrittiger integrieren zu können.
Der Stand der Entwicklung ist jedoch trotzdem da, wo er sein sollte. Es ist gerade nur etwas aufwändiger und umständlicher gemeinsam zu arbeiten.
Was ist das Besondere an eurer Arbeit in diesem Projekt?
Ein wichtiger Punkt bei uns ist, dass wir Autonomie in die Löschrobotik bringen. Etablierte Löschrobotiksysteme werden ausschließlich manuell bedient, unser System kann ohne menschlichen Operator Brände detektieren, anfahren und löschen.
Interview mit Prof.-Dr. Hartmut Surmann zum Lagebildsystem
Was testet ihr hier gerade?
Wir testen gerade das Zusammenspiel unterschiedlicher Drohnen und wie wir die Bilder, die die Drohnen liefern ins Lagebildsystem einbinden können.
Dabei bereiten wir die Bilder mit komplexen Algorithmen auf, sodass der Einsatzleiter ein gutes Lagesystem und somit eine gute Entscheidungsgrundlage für weiteres Vorgehen erhält.
Die Drohnen fliegen in bestimmten Mustern über das Szenario und zeigen einen Livestream im Lagebildsystem an. Dabei nimmt jede Drohne mehrere Bilder auf, die zu einem größeren Bild zusammengesetzt werden.
Hat euch die Corona-Krise bei der Entwicklung irgendwie beeinflusst?
Da wir nicht mehr zusammen in den Laboren arbeiten konnten, hat es schon unsere Arbeit behindert. Wir haben versucht das aufzufangen, aber ganz kriegt man das nicht hin, da wir natürlich darauf angewiesen sind im Labor mit den Robotern zu arbeiten und im Team verschiedene Sachen zu testen.
Zeitlich sind wir jedoch nicht im Verzug, da wir mehr gearbeitet haben und andere Arbeiten vorgezogen haben, die wir sonst später gemacht hätten.
Was ist das Besondere an eurer Arbeit in diesem Projekt?
An unserer Arbeit ist besonders, dass wir direkt bei den Einsätzen dabei sind. Normalerweise entwickelt man in der Forschung irgendwelche Sachen und testet diese dann im Labor. Das ist bei uns auch der Fall, allerdings versuchen wir unsere Entwicklungen direkt in Einsätze zu bringen.
Wir waren zum Beispiel bei einem Großbrand in einer Berliner Industriehalle und konnten Bilder von Bereichen liefern, die überhaupt nicht zugänglich sind. So etwas gab es vorher noch nicht. Das sind halt Sachen, die weit über die Laborarbeit hinausgehen und das macht natürlich einen großen Reiz aus.
Interview mit Dr. Janis Tiemann zu interoperablen Kommunikationsschnittstellen
Was testet ihr hier gerade?
Wir testen eigentlich ganz viele unterschiedliche Sachen, aber im Fokus liegt aktuell die Integration der interoperablen Kommunikationsschnittstellen auf die zentralen Demonstratoren des Projektes.
Das sind im Prinzip kleine Boxen, die über unterschiedliche Kommunikationstechnologien eine Konnektivität für die Robotiksysteme herstellen können. Wir verbinden unterschiedliche Kommunikationstechnologien zu einem leistungsstarken Kommunikationslink. Was das konkret heißt, ist wenn ein Roboter aus der Abdeckung von einer lokalen Funktechnologie fährt, dass dann eine andere Technologie übernehmen kann und das ganze muss dann so gestalten sein, dass die Partner entsprechend ihre Systeme an das Gesamtsystem anbinden können. Das ist eine sehr herausfordernde Aufgabe, mit vielen spannenden kleinen Hürden. Gerade das macht die Neuartigkeit des Ganzen aus.
Hat euch die Corona-Krise bei der Entwicklung irgendwie beeinflusst?
Ja schon, wahrscheinlich hätten wir noch ein bisschen mehr integriert ohne den Coronaoverhead. Aber dadurch, dass wir auch vieles remote machen können, sind wir da inhaltlich nicht so stark von beeinflusst.
Was ist das Besondere an eurer Arbeit in diesem Projekt?
Der große Benefit ist, dass wir durch diese Sachen ein Gesamtsystem auf die Beine stellen. Alle Partner arbeiten zusammen und kommunizieren durch diese Kommunikationsschnittstellen. Wir bauen nicht viele Einzelsysteme auf, sondern können über diese Kommunikation ins zentrale Lagebildsystem anbinden und an die ganzen anderen Systeme auch. Es wächst alles zusammen.
Das macht das ganze herausfordernd, aber das ist auch das Tolle und Neuartige daran.
Interview mit Ralf Bruder zum Thema Vitalzeichen-Erkennung
Was testet ihr hier gerade?
Da wir uns als Uni Lübeck auf die Aufgabe konzentriert haben, den Faktor Mensch im Rettungsszenario genauer zu beleuchten, testen wir unser Lebenszeichenmodul. Das heißt, wir haben ein Modul entwickelt, dass Menschen findet und dann grundlegende medizinische Werte ermittelt.
Der Fortschritt im Vergleich zum letzten Integrationssprint ist, dass wir jetzt wirklich praktisch arbeiten. Im Labor einen Testaufbau unter perfekten Bedingungen zu machen, spiegelt einfach nicht den realen Einsatz auf einem Roboter wider. Dieser wackelt, fährt schnell und stößt auch mal an. Unsere Elektronik muss das abkönnen und wir müssen das viel größere Datenrauschen adaptieren.
Das ist gar nicht so einfach, da unser Demonstrator D3 ein Kettenfahrgestell hat und dadurch sehr starke Vibrationen verursacht. Die Stöße sind so stark, dass wir unsere Elektronik im Modulgehäuse noch mal durch eine Gummihalterung entkoppeln müssen.
Hat euch die Corona-Krise bei der Entwicklung irgendwie beeinflusst?
Bis jetzt waren wir hauptsächlich theoretisch unterwegs. Dafür mussten wir jetzt ordentlich an unserer Apparatur arbeiten und viel adaptieren, sind jetzt aber auf einem guten Weg. Der Integrationssprint ist wichtiger denn je.
Was ist das Besondere an eurer Arbeit in diesem Projekt?
Das besondere an unserer Arbeit ist der Faktor Mensch. Kein anderes Forschungsprojekt kümmert sich bisher richtig vollautonom darum. Wir haben unsere kleine Modulbox, die reiner Beifahrer auf einem Roboter ist. Wir wissen dabei nicht, was der Operator macht. Unser Modul findet selbständig Menschen in der Nähe und nimmt selbstständig medizinische Messdaten auf. Durch die Zusammenarbeit mit dem Fraunhofer DFKI kann unser Modul sogar kommunizieren und beispielsweise Meschen ansprechen und eine Anamnese durchzuführen. Die Reaktion einer Person bewertet das Modul auf der sogenannten Glasgow Koma Skala und meldet das Ergebnis ans Lagebildsystem.
Interview mit Thomas Barz zum Demonstrator „D3“
Was testet ihr hier gerade?
Wir testen hier gerade mit spannenden neuen Nutzlasten und Modulen aller Partner unser Modularisierungskonzept, das wir für das DRZ entwickelt haben.
Beim D3 haben wir das modulare Nutzlastkonzept mit einem Modulträger realisiert und die Partner können ihre entwickelten Module dort aufstecken und sofort einsetzen. Die Module werden automatisch über Transponder erkannt, mit Strom versorgt und softwaretechnisch ins Gesamtframework eingebunden.
Hat euch die Corona-Krise bei der Entwicklung irgendwie beeinflusst?
Ja, sicherlich. Die Coronakrise hat dazu geführt, dass wir sehr viel weniger Integrationssprint und sehr viel weniger persönliche Treffen durchführen konnten. Der große Vorteil war hierbei beim Modularisierungskonzept, dass die Partner unabhängig von diesen Sprints an ihren eigenen Modulen arbeiten konnten. Dadurch konnten wir einiges kompensieren, was Corona uns hier in diesem Punkt zugemutet hat.
Ich bin froh, dass die Partner viele Module gebaut haben, die Schnittstellen eingehalten haben und dass jetzt mit sehr wenig Aufwand alles in Betrieb genommen werden kann.
Was ist das Besondere an eurer Arbeit in diesem Projekt?
Der Benefit ergibt sich aus den zwei Punkten, die wir gerade schon besprochen haben. Ich denke, dass das Modularisierungskonzept, so wie wir das hier umsetzen, relativ einzigartig ist in der Forschungslandschaft. Dass wir jetzt auf Demonstratorlevel die Modularisierung durchführen können, ist meiner Meinung nach ein absolutes Novum, welches es sonst anderswo nicht gibt.
Interview mit Alexander Berrang zur Prozessassistenz
Was testet ihr hier gerade?
Wir integrieren gerade die Prozessassistenz in den RobLW, damit diese synchron mit dem Lagebildsystem läuft. Bei der Prozessassistenz wird der aktuelle Einsatz visualisiert, sodass die Einsatzleitung einen Überblick über verfügbare und im Einsatz befindliche Einheiten erhält. Anhand eines Prozessmodells des Instituts für Wirtschaftsinformatik wird gezeigt in welchem Abschnitt des festgelegten Einsatzprozesses man sich befindet. Das System wurde im Labor schon erprobt und wird jetzt in den RobLW übertragen.
Hat euch die Corona-Krise bei der Entwicklung irgendwie beeinflusst?
Nur insofern, dass wir beim letzten Integrationssprint nicht anwesend sein konnten und deshalb jetzt die Prozessassistenz in den RobLW integrieren müssen. Was die Softwareseite angeht sind wir nicht im Verzug, da wir uns im Vorhinein mit dem IAIS bezüglich des Lagesystems abstimmen konnten.
Was ist das Besondere an eurer Arbeit in diesem Projekt?
Die Prozessassistenz ist dafür da, dass die kognitive Last für die Einsatzleitung verringert werden soll. Es wird dargestellt wie der aktuelle Stand des Einsatzes ist und welche Schritte laut Feuerwehrdienstvorschrift als nächstes einzuleiten sind. Dabei dient die Prozessassistenz als Anleitung und optimiert den Einsatzprozess durch diverse unterstützende Funktionen.
Interview mit Christopher Zech zum Thema praxisbezogene Tests der Systeme
Was testet ihr hier gerade?
Wir testen die Zusammenarbeit von mehreren robotischen Systemen in einem Einsturzszenario.
Dabei schicken wir robotische Systeme in Bereiche, die ein zu hohes Risiko für Einsatzkräfte darstellen, um Such- und Rettungsarbeiten durchzuführen. Wie bei einem realen Einsatz koordinieren wir den Einsatz der Roboter. Das Problem ist, dass Einsatzkräfte teilweise nicht in einsturzgefährdete Bereiche gehen können. Roboter ermöglichen hier eine Überbrückung der Zeit, bis die gefährdeten Bereiche durch Fachpersonal statisch freigegeben sind und nach vermissten Personen gesucht werden kann.
Hat euch die Corona-Krise bei der Entwicklung irgendwie beeinflusst?
Bei diesem Forschungsprojekt gibt es technisch gesehen zwei Parts – einmal softwareseitig und hardwareseitig. Die Softwareseite konnte sehr gut während Corona bedient werden, aber die Hardwareseite hat auf Grund der fehlenden Präsenz etwas zurückstecken müssen. Das heißt vor Ort die Systeme aufeinander abzustimmen und diese auch im Gelände in einem physischen Szenario dann zu testen hat an der einen oder anderen Stelle gefehlt. Wir haben einige Softwareteile vorgezogen, um am Ende des Projektes nicht hinterherzuhinken.
Was ist das Besondere an eurer Arbeit in diesem Projekt?
Unsere Arbeit spezialisiert sich dadurch, dass wir versuchen, komplette Szenarien ohne Einsatzkräfte durchzuführen aber auch kooperative Einsätze mit Mensch und Maschine zu testen. Das heißt es handelt sich in den Szenarien um Gefahrenbereiche, in denen Einsatzkräfte gar nicht oder zeitlich begrenzt arbeiten können. Dabei stellen wir unser Knowhow aus real Einsätzen dem Projekt zur Verfügung, um die Roboter praxisnahe weiterzuentwickeln. Wir versuchen die Tätigkeiten von Einsatzkräften auf robotische Systeme umzumünzen, um das Risiko von Verletzungen im Einsatz für den Menschen zu reduzieren.
Die Interviews mit unseren Partnern aus 2020
What is happening right now?
We are currently integrating our autonomous flying robots with the network provided by TU Dortmund University. The robots have WiFi and the TU Dortmund University takes care that enough access points are provided, that the data rate is correct and that enough traffic can be transmitted. We are currently connecting our robots to this system.
What hurdles have you already overcome in the project?
The most difficult hurdle in the project is the complexity of the systems, because a robot has tens of sensors and subsystems and getting them all to work at the same time is the most difficult thing. We are on the right track and have already overcome some of the hurdles.
What facilitation do you provide for real-life use?
We are responsible for the autonomous assistance functions and ensure that the flying robots assist the emergency services autonomously. This means that they avoid obstacles or fly independently to certain points. This supports the emergency forces in order to avoid wrong decisions based on stressful situations.
What exactly does autonomous mean for you?
Autonomous means that the robot independently performs certain tasks that a firefighter no longer has to do. For example, independently flying away from the scene, taking photos of the danger situation, recognising important details in the danger area (e.g. danger signs). Based on this data, the robot assesses the danger and transmits it to the emergency worker or the control centre. Full autonomy is not aimed at for legal and safety reasons. But the more autonomous work the robot can do for the operator, the better. In our project, however, there will still be an operator who monitors what the robot decides.
What is happening right now?
We are preparing to test our robot in a replicated, real environment. The environment is fogged with smoke and we want to see how this smoke affects the sensor data. From this data, we want to draw conclusions as to whether the data can still be used in the smoke.
What hurdles have you already overcome in the project?
We have built a completely new demonstrator (D4). This is intended for indoor purposes, i.e. for industrial sites, industrial halls. There it is supposed to patrol and detect fires as early as possible in order to directly prevent a larger fire. The robot is configurable via a modular concept. Due to its high speed (118 km/h) and the very high carrying capacity of payloads (100 kg), it can be used individually.
What facilitation do you provide for real-life use?
We are already trying to act preventively, in that the robot can detect early on where fires could occur (e.g. areas in industrial plants that are difficult to access) and report them. With this help, emergency services quickly have an overview of the situation and can intervene at an early stage. The robot is also able to extinguish small fires directly and independently.
What is happening right now?
We are currently testing the radar module we developed, which enables the robot to localise and navigate in smoky environments. The radar module is based on a radar signal, which enables the robot to see through the smoke and recognise the geometry in the room. This enables it to detect and avoid obstacles in the room. The robot is in the test room and the sensors are set up. First smoke is generated with a fog machine and then a smoke cartridge is ignited. Then we test how well the sensors can work in the smoky room.
What hurdles have you already overcome in the project?
We now have an egocentric representation of our robot situation images. This means that the robot understands its environment. It knows where, for example, walls or a fire are in its environment and can make decisions based on this. For example, the exploration of the environment, a message to the operator where there are dangers or even the creation of a 3D model of the environment.
- Interposed question: How did the robot learn that? Did he go to school?
Yes, you could say that. The robot has learned to understand its environment in 3D. It has various sensors with which it perceives its environment. We have dealt with how to process the sensor data obtained and the robot understands, on the one hand, that there are walls and floors here, that I can drive here, that there is an obstacle there that I cannot overcome or that there is an obstacle here where I have to use my joints and arms to overcome it.
The assistance functions are constantly being further developed. This enables an ever higher level of autonomy. In this way, the robot's ability to learn is constantly progressing.
- Interim question: What does autonomy mean to you?
Autonomy means that we place the robot in an environment and then go to "Start exploration". Then the robot independently explores the environment without any further intervention. With us, there is still someone who controls the robot and also experiences a certain transparency of the assistance functions. But he no longer has to intervene directly.
What facilitation do you provide for real-life use?
We want to prevent rescue forces from having to expose themselves to increased risks in dangerous, unclear situations. For example, the situation when a hazardous substance escapes and the emergency forces do not know what kind of hazardous substance it is, what quantity, where exactly it escaped or a building that is in danger of collapsing and it is not known whether there is still an injured person in the rubble. Then our goal is to send the robot ahead and it creates a situation picture of the surroundings. This way, it is no longer necessary to bring the emergency worker into the dangerous situation.
What is happening right now?
Here you can see the situation display that we are developing as part of the project. The situation display shows a map on which the entire operational situation is visualised. The data of the robots, but also the positions of the emergency forces, an overview of operation commands, orders and executed actions are displayed here. In other words, an exact picture of what is happening on site. The data of the task forces are entered manually into the system by the group and platoon leaders. In the process, virtual cards are drawn onto the situation picture to depict the situation accordingly. The system thus combines all components of the operation. The added value is that different parties (task forces in the scene, operator in the robotics command vehicle, task forces further away, etc.) access the same situation display and are aware of changes and updates in a fraction of a second.
What hurdles have you already overcome in the project?
We have already overcome numerous hurdles. The biggest challenge was to store the different data centrally and make it available. Another major hurdle we have overcome is the integration of the software into a real operation. We map the complete command structures in a fire brigade operation in the software and in the situation picture.
What facilitation do you provide for real-life use?
We facilitate the presentation of the entire situation. What was previously done with paper and slips of paper is graphically processed in this system using state-of-the-art technology and several instances can access the same data. Updating via radio, mail or SMS is no longer necessary and thus valuable time is gained for the operation.
What is happening right now?
At Minimax, we specialise in detecting and fighting incipient fires and are currently trying to approach, detect and fight these fires with a robot. The place of operation is usually an industrial company. Unlike the fire brigade, which only arrives at the scene when a fire has broken out, we are already at the scene with the robot. The robot, which is small, fast and manoeuvrable and has good detection, can fight the incipient fire. It has little extinguishing agent on board - the amount is enough to bridge the period until the emergency services arrive. We are not concerned with different driving platforms and how they are directed, but with the extinguishing application. So which extinguishing agent is best suited for an incipient fire. The robot is supported by a fire alarm system or a person.
What hurdles have you already overcome in the project?
The biggest challenge was the initially unfamiliar cooperation with a university compared to a commercial enterprise. Certain processes run very differently in a university than they do here, but we quickly got used to that.
What facilitation do you provide for real-life use?
The relief is that one already has a mobile device at the scene that provides data or has already initiated the extinguishing process. In this way, the emergency services can already work with the data obtained and intervene in a targeted manner. A large fire can be avoided with the extinguishing robot.
What is happening right now?
We are currently flying a drone that takes pictures and creates panoramic images. This livestream from the drone is sent to a server via the mobile phone. There, a selection of video image data is made and sent to a so-called web ODM via an Intelligent Image Hub, which contains an AI in the background that can detect audios. There, a 3D point cloud is generated to support the emergency services on site. The emergency services can thus view all objects in the dimensioned point cloud and draw conclusions about their size and shape.
What hurdles have you already overcome in the project?
First of all, I learned how to fly a drone with four other colleagues from Prof. Surmann. But not only the simple flying, but also all the autonomous assistance functions and sensor data processing, as well as the various AI algorithms that you have to pay attention to when flying. Learning under pandemic conditions was a real challenge. Then, together with the association and Fraunhofer IAIS, we expanded the robotics guidance vehicle into a small mobile data centre that runs cloud and server services as well as the AI processes I just mentioned. This allows us to send live image data via the network to various systems, for example to the IAIS situational awareness system or to the 3D mapping module. We have made the system so robust that it could already be used in a fire drill.
What facilitation do you provide for real-life use?
When the emergency services are on the scene, the drone can already take panoramic images and point clouds without a firefighter having to go into a dangerous situation, for example. A drone can provide the localisation of people in a building and thus pass on targeted information to the emergency services.
What is happening right now?
Currently, we are putting our demonstrator "Xplorer" into operation. On this research system, four communication channels are bundled as part of the development of interoperable communication interfaces in order to generate an optimal connection for the emergency services. The following networks are bundled:
- Local network - which serves as our research network
- Public mobile network
- Private mobile network in the 5G campus network band - which we carry on our communications lab
- Proprietary system - which is to be seen from the context of the current systems in rescue robotics.
These many systems are necessary because each system has its individual advantages and disadvantages. For example, a proprietary system only supports a very low data rate and is only available locally. When the robot moves out of the system's reception range, alternative systems are needed to ensure a continuous connection of all robotic systems. Therefore, we have developed methods that enable a combination of these networks. The goal is to provide continuous connectivity in real-world applications so that the robot is always available and data can be transmitted.
In parallel, the integration of the central demonstrators with our communication modules is currently underway. At the end of the integration sprint, all systems will be able to communicate with the control centre in RobLW via our communication interfaces.
What hurdles have you already overcome in the project?
For the first time, we have created the possibility to bundle different networks transparently via interoperable communication interfaces. This did not exist before. This bundling is being done in practice here in Bad Oldesloe for the first time. In addition, we have connected the central demonstrators of the project for the first time via the interoperable communication modules.
What facilitation do you provide for real-life use?
In real operations, the network connection often fails as soon as the robot moves in a building or a system suddenly no longer has availability. As a result, a reconnaissance can no longer take place and the emergency services can no longer act. Continuous availability through our interoperable communication interfaces is therefore of enormous importance for the emergency services.
What is happening right now?
The University of Lübeck takes care of the human factor in the overall project. The goal of a firefighter is to save endangered people in addition to fighting fires. Robots in firefighting operations should also at least recognise people. There are already many ways to detect people. However, environmental influences such as smoke, fire or partial occlusion often prevent localisation. Therefore, three approaches are combined in our module: Image processing detects 50% of a face, plus a body outline and a heat source. If there is a combination of the features, it can be assumed that it is a human being. In addition, we take care of assessing the health of injured people. We teach the robots how to recognise human vital signs and determine the severity of injuries. These are primarily heartbeat, breathing and body temperature.
What hurdles have you already overcome in the project?
In the meantime, we have built up two modules. One represents the state of the art and research in rescue robotics. Many of the methods for person detection published in the literature have been integrated. The module is equipped with thermal imaging and normal camera, a microphone array that locates people by their calls, and 8 gas sensors that have been used in the literature to detect buried people by their smell. A radar module measures and localises large but also the smallest movements such as pulsation, i.e. the skin surface movement caused by blood flow during a heartbeat. Of course, a moving emergency worker detected by radar generates a signal 1000 times stronger. But we know the frequency at which a heart beats and the frequency at which a normal person breathes. We filter according to these frequencies in order to not only detect injured people, but also to say something about their state of health.
What facilitation do you provide for real-life use?
The focus of the University of Lübeck is clearly on medical technology. Other groups navigate their robots autonomously through a rescue scenario while carrying our vital signs module. The module automatically detects people in its vicinity and records various vital parameters. This provides information on whether people are still alive and who needs help first. In this way, emergency forces can plan their deployment in a targeted manner and help where help is needed most quickly.
What is happening right now?
We are working on a cross-platform modularisation concept. The goal is to break down the robot functions into smaller units, so-called modules. These modules can be used independently of each other in different robot systems. The robots themselves are equipped with a so-called module carrier. This carrier provides a standardised receptacle for the DRZ modules that have been developed, which can themselves have very different capabilities. The operator can choose which devices and sensors are to be carried and thus decide, for example, whether a thermal camera, an optical camera, a 3D laser scanner or something else is needed for the current mission. This makes a tailor-made mission possible.
What hurdles have you already overcome in the project?
There was no comparable preliminary work that could be adapted. So we first had to think about what the whole thing should look like - from the division of space to the shapes of the modules, interfaces and connectors. The system should be as flexible as possible without too many specifications.
What facilitation do you provide for real-life use?
The benefit for the operator is that he can operate with known systems. This means that if one selects the robot (large, small with manipulation, etc.) depending on the operational situation, the module known to it can be placed on this robot. So completely independent of the ground platform. With the standardising idea, we can ensure that there are not so many isolated solutions. We want to map a set of basic skills via the modules that the operator is familiar with.
What is happening right now?
The radio traffic is listened to and interpreted by our system. The information resulting from the interpretation is placed in the context of the mission and forwarded to our process assistance component. Here, this information is used to visualise the status of the mission and suggest possible next steps.
What hurdles have you already overcome in the project?
Integration! Das ist in einem Projekt mit so vielen verschiedenen Partnern immer einer der größten Herausforderungen. Außerdem entwickeln wir Sprachmodelle für eine „real-live“ Domäne, für die es keine bzw. kaum Daten gibt. Aus Sicht der Prozessassistenz-Komponente ist dies auch der erste uns bekannte Versuch Methoden und Techniken des Geschäftsprozessmanagements in Einsätze der Feuerwehr zu integrieren. Wir glauben, dass uns dies gut gelungen ist.
What facilitation do you provide for real-life use?
We are developing two components to facilitate the deployment. With the first component for voice recognition and processing, data does not have to be entered; instead, components of the data are automatically extracted from the radio communication and entered into the DRZ system. The second component processes this data from a process-oriented perspective and visualises relevant information on the current status of the mission for the task forces. This reduces the cognitive load of the task forces, especially the leaders. The current status of a mission as well as possible future steps are then visible. In addition, the central collection and processing of data enables a better follow-up of the mission. For example, a functionality for the automatic creation of mission reports is currently being developed.
What is happening right now?
We test the developed systems in a practical application scenario where the cooperation of the different robotic systems is also tested.
What hurdles have you already overcome in the project?
Due to the individual environmental conditions, the application differs considerably from standardised industrial applications. In order to develop practical solutions for the challenging tasks at operation sites, we support the project partners in the implementation of user-related requirements and specifications, among other things by developing comparable test scenarios.
What facilitation do you provide for real-life use?
The integration of the various technical systems is a major challenge and must be tested in practical exercises. Among other things, the Dortmund Fire Brigade tests the interaction of the systems developed by the project partners in realistic scenarios. For this purpose, mission-related processes are practised under practical conditions.
English 
German