Test Engineer - Dexterous Humanoid Hand (Mensch)

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

• Hardware-Software-Integrationstests

• 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.

• Software-Tests

• 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.

• Test-Infrastruktur

• 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., + 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.

• 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.

• Strongly Preferred

• 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.