Fallstudie: Vom CE-Berater zum Engineering Lead bei einem Healthcare-Robotik-Startup
Fallstudie: Vom CE-Berater zum Engineering Lead bei einem Healthcare-Robotik-Startup
Wie das Loesen von Hardware-Limitierungen in Software einen Nachtpatrouillen-Roboter vom Prototyp zur CE-Prueffaehigkeit brachte
10 Min. Lesezeit | Fallstudie
Die Herausforderung
Bearcover baut einen 90 cm grossen autonomen Roboter, der nachts durch Pflegeheime und Kliniken patrouilliert und durch geschlossene Tueren hindurch nach Patienten schaut, mit UWB-Radar. Ein Produkt, das sofort neugierig macht: ein Roboter, der menschliche Bewegung durch Waende erkennt, ohne Kameras, ohne jemanden zu wecken.
Als ich anfing, war der Auftrag klar umrissen. Das Unternehmen brauchte einen CE-Compliance-Berater. Sie hatten einen funktionierenden Prototyp, echte Einsaetze in Pflegeeinrichtungen und ein Produkt, das ein reales Problem loeste. Was fehlte, war jemand, der sie durch den Sicherheitszertifizierungsprozess fuehrt, damit sie skalieren koennen.
So kam es nicht.
Innerhalb der ersten Wochen wurde klar, dass CE-Compliance kein Dokumentationsproblem ist. Du kannst keine Sicherheitsdokumente fuer ein System schreiben, das architektonisch nicht fuer einen sicheren Betrieb bereit ist. Der Roboter funktionierte, aber die Luecke zwischen "funktioniert in der Demo" und "zertifiziert fuer unbeaufsichtigten Betrieb in klinischer Umgebung" war groesser als erwartet.
Die State Machine, die Patrouille, Scannen und Docking steuerte, war monolithisch. Das Sichtfeld der Sensoren war begrenzt, was zu Kollisionen und Lokalisierungsverlusten fuehrte. Die Raeder rutschten auf glatten Pflegeheimboeden, verfaelschten die Odometrie und brachten den Roboter dazu, seine Position zu verlieren. Es gab keinen systematischen Ansatz fuer Sicherheit, der einer CE-Pruefung standhalten wuerde.
Also trat ich dem Team bei. Nicht als Berater, der von aussen Dokumente schreibt, sondern als Engineering Lead, der das technische Fundament von innen heraus neu aufbaut.
Was wir vorfanden
Das Erste, was ich tat, war eine Kartierung der tatsaechlichen Fehlermodi. Nicht die theoretischen, die man in einer Risikoanalyse auflistet, sondern die, die im Feld passierten.
Die State Machine war ein einziges Skript. Patrouillenlogik, Scan-Verhalten, Docking-Sequenzen und Fehlerbehandlung lebten alle in einer monolithischen Datei. Wenn waehrend einer Patrouille etwas schiefging, musste man sich durch Hunderte Zeilen verschachtelter Zustandsuebergaenge lesen, um die Ursache zu finden. Einzelne Verhaltensweisen isoliert zu testen war unmoeglich. Neue Features hinzuzufuegen bedeutete, ueberall Regressionen zu riskieren.
Das begrenzte Sensorfeld erzeugte tote Winkel. Der Roboter hatte eine eingeschraenkte Sensorabdeckung, und mehr Sensoren kamen nicht in Frage. Budget war knapp, das mechanische Design stand fest, und der Zeitplan liess keine Hardware-Aenderungen zu. Aber das begrenzte Sichtfeld verursachte reale Probleme: Der Roboter kollidierte mit Hindernissen, die er nicht sehen konnte, oder verlor die Lokalisierung, wenn er nicht genuegend Features mit der Karte abgleichen konnte.
Die Lokalisierung war auf glatten Boeden unzuverlaessig. Pflegeheime haben lange Korridore mit glatten, oft polierten Boeden. Die Ubiquity-Motors/MCB-Raeder rutschten oder drehten manchmal durch, besonders in Kurven. Jedes Rutschereignis verfaelschte die Rad-Odometrie, und der Roboter driftete nach und nach von seiner angenommenen Position ab, bis er im Grunde verloren war.
Es gab keine Lokalisierungs-Gesundheitsueberwachung. Der Roboter hatte keine Moeglichkeit zu wissen, dass er verloren war, bis er gegen etwas stiess oder seine Docking-Station nicht fand. Keine Pfadabweichungspruefung, keine Lokalisierungsqualitaetsmetrik, kein automatisches Wiederherstellungsverhalten.
Das war kein schlechtes Engineering. Es war ein Startup, das mit begrenzten Ressourcen etwas wirklich Beeindruckendes gebaut hatte und nun an die Grenzen dessen stiess, was die urspruengliche Architektur tragen konnte. Der Weg zur CE fuehrte nicht ueber mehr Dokumente. Er fuehrte ueber mehr Engineering.
Der Ansatz
Das Thema jeder Entscheidung bei Bearcover war dasselbe: Hardware-Limitierungen in Software loesen, weil Hardware-Aenderungen keine Option sind.
State-Machine-Refactoring
Ich entwarf und implementierte eine saubere State-Machine-Architektur als eigenes ROS-Paket. Das monolithische Patrouillen-Skript wurde zu separaten Controllern fuer Patrouille, Scannen und Docking, mit sauberen Zustandsuebergaengen und eigenen ROS-Messages fuer die Betriebssteuerung. Jedes Verhalten konnte unabhaengig getestet werden. Fehlerbehandlung wurde explizit statt in verschachtelten Bedingungen vergraben.
Das war nicht nur eine Frage der Code-Qualitaet. Ein CE-Pruefer muss das Verhalten deines Systems in jedem Zustand verstehen koennen, einschliesslich der Fehlerzustaende. Ein monolithisches Skript macht das nahezu unmoeglich. Eine gut strukturierte State Machine macht es pruefbar.
UWB-Radar-Wahrnehmungspipeline
Die Kernfaehigkeit des Bearcover-Roboters ist die Erkennung menschlicher Bewegung durch geschlossene Tueren mittels X4M06/SLMX4 UWB-Radarsensoren. Dafuer gibt es keine fertige Loesung. Ich baute die Wahrnehmungspipeline von Grund auf: DSP-basierte Signalverarbeitung zur Extraktion aussagekraeftiger Merkmale aus den Radar-Ruecksignalen, einen Bewegungsklassifikator zur Unterscheidung menschlicher Praesenz von Rauschen und ein Publishing-System, das die Radar-Streams ins ROS-Oekosystem integrierte.
Das ist die Art von Arbeit, fuer die es kein Tutorial gibt. Du liest Datenblaetter, schreibst Signalverarbeitungscode und iterierst an Klassifikationsschwellenwerten, waehrend du in echten Pflegeeinrichtungen testest.
RGB-LiDAR-Docking
Autonomes Docking klingt einfach, bis du es versuchst. Der Roboter muss zuverlaessig zu seiner Ladestation zurueckkehren, sich praezise ausrichten und verbinden. Ich baute ein Docking-System mit RGB-Kamera- und LiDAR-Sensorfusion: Die Kamera erkennt visuelle Marker an der Ladestation, der LiDAR liefert praezise Entfernungs- und Poseschaetzung, und die Fusion beider gibt dem Roboter zuverlaessige Ausrichtung auch bei wechselnden Lichtverhaeltnissen.
IMU-Rad-Odometrie-Fusion
Das Radschlupf-Problem konnte mechanisch nicht geloest werden. Stattdessen integrierte ich einen IMU mit der Rad-Odometrie der Ubiquity-Motors/MCB-Basis. Wenn die Raeder rutschen oder durchdrehen, liefert der IMU ein unabhaengiges Rotations- und Beschleunigungssignal, das die verfaelschten Raddaten erkennen und kompensieren kann. Die fusionierte Odometrie war auf den glatten Boeden, die chronische Probleme verursacht hatten, deutlich zuverlaessiger.
Lokalisierungsueberwachung und Wiederherstellung
Anstatt nur die Lokalisierung zu verbessern, baute ich eine Ueberwachungsschicht darueber. Pfadabweichungspruefungen vergleichen die angenommene Trajektorie des Roboters mit dem, was physikalisch plausibel ist. Lokalisierungsqualitaetsmetriken tracken, wie gut die Sensordaten des Roboters mit seiner Karte uebereinstimmen. Ein Roboter-verloren-Erkennungssystem loest automatische Wiederherstellungsverhalten aus, bevor der Roboter in eine gefaehrliche Situation geraet.
Diese Monitoring-Infrastruktur fuettert auch ein Echtzeit-Betriebsdashboard, das ich gebaut habe, und gibt Operatoren Einblick in den Lokalisierungszustand, Patrouillenfortschritt und Systemstatus jedes Roboters.
Semantisches Mapping und Sperrzonen
Pflegeeinrichtungen haben Bereiche, die ein Roboter nie betreten sollte: Medikamentenraeume, Personalbereiche, bestimmte Patientenzimmer. Ich baute ein Sperrzonen-System mit polygonbasierten Regionen und einem interaktiven visuellen Waypoint-Editor zum Erstellen und Bearbeiten von Patrouillenrouten. Ein "Wo bin ich"-Service liefert Echtzeit-Standortinformationen, und die Sperrzonen verhindern das Betreten eingeschraenkter Bereiche unabhaengig davon, was der Navigationsplaner vorschlaegt.
Multi-Sensor-Integration
Die volle Sensorausstattung umfasst eine RealSense D435 Tiefenkamera, RPLiDAR A2M12, UWB-Radarsensoren, einen IMU und die Ubiquity-Motors/MCB-Basis, alles ueber ROS integriert. Diese Sensoren zuverlaessig zusammenarbeiten zu lassen, mit korrekter Kalibrierung und Zeitsynchronisation, ist die Art unglamouroeses Engineering, die alles andere erst ermoeglicht.
Ergebnisse und Wirkung
Der kumulative Effekt dieser Aenderungen war erheblich. Kollisionsereignisse und Lokalisierungsverluste gingen deutlich zurueck. Ich werde keine konkreten Zahlen erfinden, aber die Verbesserung war gross genug, dass Operatoren sie sofort bemerkten.
Noch wichtiger fuer das Business: Die Architektur war jetzt CE-pruefbar. Die State Machine hatte explizites, dokumentiertes Verhalten in jedem Zustand. Sicherheitskritische Funktionen hatten Monitoring und Fallback-Verhalten. Das Sperrzonen-System bot eine verifizierbare raeumliche Sicherheitsschicht. Ich erstellte die CE-fokussierte technische Dokumentation, Risikoanalyse und die architektonischen Nachweise, die der Zertifizierungsprozess erfordert.
Das Betriebsdashboard gab dem Team Echtzeit-Transparenz ueber eingesetzte Roboter und verwandelte eine "hoffentlich funktioniert's heute Nacht"-Situation in einen ueberwachten, messbaren Betrieb.
Was als "wir brauchen einen CE-Berater" begann, wurde zu "wir haben ein CE-faehiges technisches Fundament." Der Roboter ging von einem vielversprechenden Prototyp zu einem System, das glaubwuerdig fuer den unbeaufsichtigten Einsatz in klinischen Umgebungen bewertet werden konnte.
Die zentrale Erkenntnis fuer Gruender
Wenn es ein Muster gibt, das ich bei Robotik-Startups immer wieder sehe, dann dieses: Gruender nehmen an, die Luecke zwischen Prototyp und Produktion bestehe hauptsaechlich aus Dokumentation, Zertifizierungspapierkram und vielleicht ein paar Tests. In Wirklichkeit ist es fast immer eine Engineering-Luecke. Dein Prototyp funktioniert, weil ein erfahrener Ingenieur zuschaut und eingreift, wenn etwas schiefgeht. Produktion bedeutet, dass der Roboter jeden Fehlermodus selbst bewaeltigen muss, und deine Architektur muss das unterstuetzen.
Das andere Muster: Wenn Ressourcen knapp sind, ist dein Instinkt, Hardware-Probleme mit mehr Hardware zu loesen. Mehr Sensoren fuer bessere Abdeckung, bessere Raeder gegen Schlupf, zusaetzliche Rechenleistung fuer schnellere Verarbeitung. Manchmal ist das richtig. Aber oft ist der schnellere und guenstigere Weg, Hardware-Limitierungen in Software zu loesen. IMU-Fusion statt besserer Raeder. Lokalisierungs-Monitoring statt mehr LiDAR-Einheiten. Sperrzonen statt zusaetzlicher Bumper-Sensoren.
Das ist die Art von Arbeit, die ein Fractional CTO fuer Robotik-Startups leistet: nicht nur von aussen beraten, sondern erkennen, wo die echten Engineering-Luecken sind, und sie schliessen. Wenn du an dem Punkt bist, wo dein Prototyp funktioniert, aber die Produktion unerreichbar weit weg scheint, kann eine Robotik-Machbarkeitsstudie diese Luecke konkret abbilden. Und wenn du dich auf Investorengespraeche ueber deine technische Reife vorbereitest, stellt eine Vorbereitung auf Technical Due Diligence sicher, dass du von den Fragen, die wirklich zaehlen, nicht kalt erwischt wirst.
Die Prototyp-zu-Produktion-Luecke ist real. Aber sie ist kein Mysterium. Sie ist reine Ingenieursarbeit.
