Test Engineer — Dexterous Humanoid Hand (Mensch)

Deine Mission & Herausforderungen

Wir bauen geschickte humanoide Hand‑Plattformen – mehrgradige, seilgetriebene Systeme mit integrierter taktiler Sensorik, Echtzeit‑Motorregelung und KI‑basierter Wahrnehmung auf Edge‑Compute. Der Stack reicht von kundenspezifischen PCBs über Bare‑Metal‑Firmware und ROS‑2‑Middleware bis zu gelernten Inferenzmodellen – alles vereint in einem physischen System, das draußen in der Realität zuverlässig funktionieren muss.

Wir suchen eine:n Test Engineer, der/die die Validierung über den gesamten Stack verantwortet. Kein QA‑Job, der erst am Ende des Entwicklungszyklus auftaucht – sondern jemand, der die Test‑Infrastruktur von Grund auf aufbaut, definiert, was auf jeder Ebene „funktioniert“ heißt, und das Team während der gesamten Entwicklung ehrlich hält.

Das Programm ist frühphasig. Es gibt kein bestehendes Test‑Framework, das du übernehmen könntest. Du entwirfst es.

• Du konzipierst und führst Integrationstests für den Hand‑Control‑Stack durch: Motor‑Treiberboards, Embedded‑Compute‑Module, Sensor‑Interfaces und das Kommunikations‑Backbone (DDS über TSN‑Ethernet und SPI).
• Du baust Hardware‑in‑the‑Loop (HIL)‑Testaufbauten, um Firmware‑Verhalten an realer Aktuator‑ und Sensor‑Hardware zu validieren – brushed DC‑ und BLDC‑Motor‑Kanäle, Absolute‑Encoder, taktile Sensorarrays, IMUs.
• Du definierst und automatisierst Bring‑up‑Testsequenzen für neue PCB‑Revisionen: Power‑On‑Checks, Bus‑Enumeration, Driver‑Smoke‑Tests und kanalweise Funktionsvalidierung.
• Du verantwortest das Integrationstest‑Protokoll für die Unterarm‑zu‑Körper‑Ellbogen‑Schnittstelle: DDS‑Topic‑Korrektheit, Latenzmessung, Link‑Loss‑Verhalten und Übergang in sichere Zustände unter Fault‑Injection.
• Du testest die geschlossene Regelkette Ende‑zu‑Ende: Sensor‑Input → Embedded‑Inference → Motorbefehl → physische Reaktion, mit instrumentiertem Ground‑Truth auf jeder Stufe.
• Du instrumentierst und misst System‑Timing: Regelkreis‑Jitter, DDS‑Publish‑Latenz pro Topic, NPU‑Inference‑Latenz sowie End‑to‑End‑Perception‑to‑Action‑Latenz gegen definierte SLAs.
• Du validierst mechanisch‑elektrische Schnittstellen: Steckverbinder‑Durchgang über den Bewegungsbereich, Kabelbaum‑Belastungstests, Signalintegrität bei Biegezyklen.

• Du baust und pflegst die Software‑Testsuite für: ROS‑2‑Nodes und DDS‑Topic‑Pipelines, Motion‑Primitive‑State‑Machines, Grasp‑Sequencer‑Logik und Safety‑Watchdog‑Verhalten.
• Du entwirfst Unit‑ und Integrationstests für die Embedded‑Inference‑Pipeline: ONNX‑Output‑Korrektheit vs. CPU‑Referenz, Ring‑Buffer‑Verhalten, Multi‑Task‑DDS‑Publishing unter Dauerlast.
• Du implementierst Regressionstests für den Control‑Stack: Stabilität der Positionsregelung, Durchsetzung von Kraftlimits, Timing der korrigierenden Nachzieh‑Reaktionen und Arbitration zwischen parallelen Control‑Modi.
• Du definierst und fährst Fault‑Injection‑Tests in Software: Link‑Loss simulieren, Sensor‑Dropouts, Classifier‑Confidence unter Schwelle, aufeinanderfolgende hochkritische Slip‑Events – und prüfst, dass das System in jedem Fall korrekt in den Safe State wechselt.
• Du baust simulationsbasierte Tests, wenn keine physischen Rigs verfügbar sind: URDF‑basierte Bewegungsvalidierung, Prüfung kinematischer Limits und Trajektorien‑Machbarkeit vor dem Hardware‑Einsatz.
• Du hältst die CI‑Pipeline‑Integration am Laufen: automatisierte Testläufe bei jedem Firmware‑ und Software‑Commit, mit klaren Pass/Fail‑Gates und Fehler‑Triage.
• Du verantwortest das Benchmark‑Testprotokoll für externe Hand‑Plattformen und definierst reproduzierbare, instrumentierte Testverfahren.

• Du wählst passende Test‑Tools aus und setzt sie ein: Logic‑Analyser, Oszilloskope, Kraft/Drehmoment‑Sensoren, Motion‑Capture oder kamerabasierter Ground‑Truth, Datenlogger.
• Du baust eine strukturierte Test‑Resultat‑Datenbank: Jeder Testlauf wird mit Software‑Version, Hardware‑Revision, Konfiguration und Ergebnis geloggt – nachverfolgbar und abfragbar.
• Du schreibst Testspezifikationen, die andere Ingenieur:innen unabhängig ausführen und deine Ergebnisse reproduzieren können.
• Du definierst Abnahmekriterien für jedes Subsystem, bevor die Integration beginnt – nicht danach.

• Abschluss in Elektrotechnik, Mechatronik, Informatik oder einem verwandten Fach.
• Hands‑on‑Erfahrung im Testen von Embedded‑Systemen: Bring‑up, Bus‑Protokolle (SPI, I²C, UART, CAN), Signalintegritäts‑Messungen und Firmware‑Debugging auf echter Hardware.
• Erfahrung mit automatisierten Software‑Tests in Python oder C++ – Unit‑Tests, Integrationstests, Regression‑Suites.
• Fähigkeit, Firmware und Software zu lesen und zu verstehen, um zu erkennen, was getestet werden muss und wo die Edge Cases liegen – ohne den gesamten Produktivcode selbst schreiben zu müssen.
• Erfahrung mit Messtechnik: Oszilloskope, Logic‑Analyser, Stromzangen – du richtest den Messplatz souverän ein und erfasst, was tatsächlich passiert.
• Strukturiertes Denken über Fehlermodi: Aus einer Systembeschreibung kannst du mögliche Fehler systematisch ableiten und Tests entwerfen, die sie aufdecken.

• Erfahrung mit ROS 2, DDS‑Middleware oder Echtzeit‑Kommunikationssystemen.
• Erfahrung mit Hardware‑in‑the‑Loop (HIL) oder dem Design physischer Testaufbauten.
• Vertrautheit mit Motorregelungssystemen – brushed DC oder BLDC – und typischen Fehlermodi von Positionsregelung, Strombegrenzung und Encoder‑Feedback‑Loops.
• Erfahrung beim Aufbau oder Mitwirken an CI/CD‑Pipelines für Embedded‑ oder Robotik‑Software.
• Kenntnisse in Kraft/Drehmoment‑Messung und taktilen Sensorsystemen.
• Erfahrung im Testen gelernter bzw. probabilistischer Systeme: Validierung von Output‑Verteilungen, Testen von Confidence‑Schwellen und Definition akzeptablen Verhaltens bei Out‑of‑Distribution‑Inputs.
• Background oder Berührungspunkte mit Functional‑Safety‑Tests – den Unterschied zwischen Korrektheit und Sicherheit zu testen zu verstehen, ist ein großer Pluspunkt.

Die meisten Test‑Rollen in der Robotik sind entweder rein Software oder rein Hardware. Diese hier spannt beides zusammen und verlangt echte Fluency an der Schnittstelle – die interessanten Fehler entstehen fast immer zwischen PCB‑Revision, Firmware‑Änderung und gleichzeitiger DDS‑Schema‑Anpassung.

Außerdem testest du ein System, dessen Perception‑Layer ein gelerntes Modell auf einer NPU ist. Zu definieren, was „korrekt“ für einen taktilen Slip‑Klassifikator bedeutet, der einen sicherheitsrelevanten Motorbefehl speist, ist kein gelöstes Problem. Du musst sorgfältig überlegen, wie probabilistische Outputs in einem deterministischen Control‑Kontext validiert werden und wie Testabdeckung für ein System aussieht, das graceful statt clean scheitert.

Auch der Benchmark‑Framework für externe Hand‑Plattformen liegt bei dir. Diese Arbeit hat direkten strategischen Wert – die Ergebnisse entscheiden, welche externen Plattformen wir integrieren und wie gut unsere eigenen im Vergleich abschneiden. Das ist sichtbare Arbeit mit echtem Programmeinfluss, kein Back‑Office‑Job.