Anhalten an der Kante: Latenz und Bremsweg

Das Budget steht in Millimetern, nicht Millisekunden

Ein Roboter mit Abwärtssensor bekommt eine Information – weiß, jetzt – und eine feste Strecke, darin zu handeln. Ein Mini-Sumo-Ring gibt 25 mm Rand. Eine Tischkante gibt, was der vordere Montageversatz deines Sensors zufällig ist. So oder so ist es eine Strecke – und der Roboter gibt sie auf zwei sehr verschiedene Arten aus:

overshoot = v × t_latency  +  v² / (2a)

Der erste Term ist bezahlt, bevor Bremsen überhaupt beginnt. Der zweite ist, was der Boden verlangt, sobald es tut.

Beide verhalten sich völlig verschieden mit steigendem Tempo – und zu wissen, welchen man zahlt, ist der Unterschied zwischen Beheben an einem Nachmittag und Umschreiben deiner Regelschleife für nichts.

Wohin die Latenz wirklich geht

„Latenz“ ist nicht der Sensor. Es ist alles zwischen Photonenwechsel und Reifen, die Kraft in die andere Richtung erzeugen – und es wird fast immer von einem Term dominiert, den niemand maß:

Die Schleifenperiode ist vier Fünftel davon – und die einzige Zeile, die man gratis behebt.

Ein Sensor, den man mit 50 Hz liest, ist ein Sensor, den man 20 ms am Stück ignoriert. Die übliche Ursache ist kein langsamer Prozessor – sondern ein blockierender Aufruf. Ein pulseIn() an einem Ultraschallsensor sind bis 30 ms völlige Blindheit, und ein delay(20) für ein Servo ist dasselbe anders buchstabiert. Den Kantensensor jeden Durchlauf einer nicht blockierenden Schleife zu lesen kostet nichts und beseitigt den Großteil der Reaktionsstrecke.

Die letzte Zeile überrascht Leute. Motoren umzukehren kehrt die Räder nicht um, bis die Zahnräder ihr Spiel überquert haben – Getriebespiel ist also freie Fahrt im schlimmstmöglichen Moment: 4° Abtriebsspiel an 32-mm-Rad sind 1,1 mm Rollen, bevor Bremsmoment überhaupt eintrifft.

Bremsen ist ein Reibungsproblem, kein Motorproblem

Der zweite Term sieht aus, als hinge er davon ab, wie stark die Motoren sind. Tut er nicht.

Dieselben Motoren, die 25 N Schubkraft liefern, würden einen 500-g-Roboter mit 50 m/s² verzögern. Der Boden erlaubt µg – 11,8 m/s² auf Silikon, 6,9 m/s² auf Hartplastik. Der Antriebsstrang hat vierfache Autorität, die er nutzen dürfte – Anhalteweg setzt also vollständig die Reifen, und ein größerer Motor verkürzt ihn um exakt nichts.

Darum hat das untere Feld zwei Kurven statt einer. Bei 25 ms Latenz hebt Silikon statt Plastik das sichere Tempo von 0,79 auf 0,98 m/s – 24 % Gewinn aus einem Bauteil, das außerdem 72 % mehr Schub liefert.

Eine Ehrlichkeitskorrektur: µ per Schleppen eines stehenden Roboters gemessen ist der Haftkoeffizient – und eine harte Umkehr lässt die Räder gleiten, was auf den Gleitkoeffizienten setzt, typisch 10–20 % niedriger. Das errechnete Tempo als optimistische Schranke behandeln und mit etwa 80 % davon fahren.

Welcher Term dominiert, und was man daher behebt

Beide Terme gleichsetzen und der Übergang ist sauber:

v × t = v² / 2a   →   v = 2at

Bei 25 ms und µ 1,2 sind das 0,59 m/s.

• Darunter ist man latenzbegrenzt. Die Schleifenperiode zu halbieren kauft mehr als jeder Reifen. Hier lebt ein suchender Roboter – und das ist die gute Nachricht: Die Lösung ist eine Softwareänderung.
• Darüber ist man traktionsbegrenzt. Grip und Massenverteilung zählen mehr als Schleifenrate – und jenseits eines Punkts bleibt als einzige Antwort, langsamer zu werden.

Die meisten Roboter, die irgendwo herunterfallen, stecken im ersten Regime und werden abgestimmt, als wären sie im zweiten.

Sich mehr Millimeter verschaffen

Das Budget steht nicht fest. Es ist Randbreite plus Strecke, die der Sensor vor den Rädern montiert ist – und dieser zweite Term ist eine freie Entwurfsgröße:

budget = border + sensor lead

Ein Sensor 40 mm vor der Antriebsachse verwandelt 25 mm Rand in 65 mm Anhalteraum – der Unterschied zwischen 0,60 m/s und 0,98 m/s. Andersherum lösen, wenn man ein Zieltempo hat:

budget = v·t + v²/(2a)

Praktische Grenzen, wie weit nach vorne man gehen kann:

• Er muss den Rand sehen, nicht den Ring dahinter. Zu weit vorne montiert schaut er an der Linie vorbei, während der Roboter noch sicher ist – was Tempo ohne Grund kostet.
• Tief montieren und abschirmen. Ein IR-Reflexionssensor bei 3 mm liest die Oberfläche; bei 15 mm liest er Oberfläche plus Raumlicht. Dasselbe Schwellen- und Kalibrierproblem, das ein Linienfolger hat – mit weit schlimmerer Fehlermode.
• Einen an jede Vorderecke setzen. Ein einzelner Zentralsensor sagt: Die Kante ist irgendwo voraus. Zwei sagen, wohin man sich von ihr wegdreht – ohne Extralatenz.
• Das Heck nicht vergessen. Ein rückwärts geschobener Roboter quert den Rand falschherum – und die Vordersensoren sehen ihn nie.

Erst rückwärts, dann drehen

Bei festem Budget zählt Reihenfolge mehr als Abstimmung.

Voll rückwärts, sofort. Nicht ausrollen – ein ausrollender Roboter verzögert nur mit Rollwiderstand, einem kleinen Bruchteil von µg, und der Überschuss verdreifacht sich grob. Auch nicht sanft bremsen: Das ist der eine Moment, wo ein Bewegungsprofil der falsche Instinkt ist – denn die Zwangsbedingung ist Strecke statt Weichheit.

Dann drehen, sobald man steht. Noch fahrend zu drehen verwandelt dein Geradenproblem in einen Bogen, der eine Roboterecke weiter hinausträgt als seine Mitte. Erst stoppen, dann neu orientieren – und bedenken, dass eine Drehung auf der Stelle die Reifen die ganze Zeit seitwärts walken lässt.

Die Erkennung einrasten. Eine einzelne weiße Messung reicht. Auf zwei Folgemessungen zur Bestätigung zu warten verdoppelt deine Worst-Case-Reaktionsstrecke – und das Fehlpositiv, wovor es schützt, ist weit billiger als der Sturz.

Die eigene Latenz messen

Die Zahl in der Tabelle ist eine Startschätzung. Deine ist in etwa fünfzehn Minuten messbar.

Von innen. micros() aufzeichnen, wenn der Sensor die Schwelle kreuzt, und erneut an der Zeile, die das umgekehrte PWM schreibt. Das erfasst die Softwarehälfte – die Hälfte, die man beheben kann. Den schlechtesten Wert über hundert Erkennungen ausgeben, nicht den Mittelwert – der Worst Case entscheidet, ob der Roboter fällt.

Von außen. Mit Handy bei 240 fps filmen. Bilder zwischen Sensorüberquert-Linie und sichtbar umkehrenden Rädern zählen; jedes Bild sind 4,2 ms. Das fängt die elektrische und mechanische Verzögerung, die Software nicht sieht – und ist die einzige Art, das Ganze zu bestätigen.

Ende zu Ende. Bei bekanntem Tempo auf eine geklebte Linie zufahren und messen, wie weit dahinter der Roboter stoppt. Den errechneten Bremsweg v²/2a abziehen – was bleibt, ist v × t: Gesamtlatenz, mit Lineal gemessen.

Letzteres dauert fünf Minuten und lohnt sich vor jedem Abstimmen überhaupt – denn es sagt, welchen der zwei Terme man wirklich zahlt.

Wenn es schiefgeht

Dieselbe Rechnung deckt Tischkantenroboter, treppenmeidenden Sauger und Hindernisstopp ab – nur das Budget ändert sich. Der Hindernisvermeidungssimulator legt exakt diese Anhalteweggeometrie mit vorwärtsschauendem statt abwärtsschauendem Sensor offen – und das Mini-Sumo-Projekt ist der Ort, wo sie gegen einen Gegner arbeiten muss, der dich scheitern sehen will.