Stoppen aan een rand: latentie en remafstand

Het budget is in millimeters, niet in milliseconden

Een robot met een naar beneden gerichte sensor krijgt één gegeven — wit, nu — en een vaste afstand om daarop te reageren. Een mini-sumoring geeft 25 mm randlijn. Een tafelrand geeft wat de voorwaartse montage-offset van je sensor toevallig is. Het is in beide gevallen een afstand, en de robot besteedt hem op twee heel verschillende manieren:

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

De eerste term koop je en betaal je voordat er ook maar wordt geremd. De tweede is wat de vloer rekent zodra dat gebeurt.

Ze gedragen zich volstrekt anders naarmate de snelheid stijgt, en weten welke van de twee je betaalt is het verschil tussen dit in een middag verhelpen en je regellus voor niets herschrijven.

Waar de latentie werkelijk heen gaat

“Latentie” is niet de sensor. Het is alles tussen het veranderen van de fotonen en de banden die kracht de andere kant op uitoefenen, en het wordt vrijwel altijd overheerst door een term die niemand heeft gemeten:

De lusperiode is vier vijfde daarvan, en dat is de enige regel die je gratis kunt verhelpen.

Een sensor die je op 50 Hz uitleest, is een sensor die je 20 ms tegelijk negeert. De gebruikelijke oorzaak is geen trage processor maar een blokkerende aanroep. Eén pulseIn() op een ultrasone sensor is tot 30 ms volledige blindheid, en een delay(20) voor een servo is hetzelfde met andere woorden. De randsensor elke doorgang van een niet-blokkerende lus uitlezen kost niets en haalt het meeste van de reactieafstand weg.

De laatste rij is de verrassing voor mensen. Motoren omkeren keert de wielen pas om nadat de koppels hun speling hebben overbrugd, dus de rondgang in de overbrenging is vrije slag op het slechtst mogelijke moment: 4° uitgaand spel op een wiel van 32 mm is 1.1 mm uitglijden voordat er enig remkoppel aankomt.

Remmen is een wrijvingsvraag, geen motorvraag

De tweede term lijkt af te hangen van hoe sterk de motoren zijn. Dat doet hij niet.

Dezelfde motoren die 25 N duwkracht kunnen leveren, zouden een robot van 500 g met 50 m/s² afremmen. De vloer staat µg toe — 11.8 m/s² op siliconen, 6.9 m/s² op hard plastic. De aandrijflijn heeft vier keer zoveel gezag als hij mag gebruiken, dus de stopafstand wordt volledig door de banden bepaald, en een grotere motor verkort hem met exact niets.

Daarom heeft het onderste paneel twee krommen in plaats van één. Bij 25 ms latentie verhoogt de overstap van plastic naar siliconen de veilige snelheid van 0.79 naar 0.98 m/s — een winst van 24% uit een onderdeel dat je ook 72% meer duwkracht geeft.

Eén eerlijke correctie: µ gemeten door een stilstaand staande robot te slepen is de statische coëfficiënt, en een harde omkering laat de wielen slippen, waarmee je op de kinetische komt — doorgaans 10–20% lager. Behandel de berekende snelheid als een optimistische grens en rij op ongeveer 80% daarvan.

Welke term overheerst, en dus wat je moet aanpakken

Stel de twee termen gelijk en het kruispunt is helder:

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

Bij 25 ms en µ 1.2 is dat 0.59 m/s.

• Daaronder ben je latentiegebonden. De lusperiode halveren levert meer op dan enige band. Dit is waar een zoekende robot leeft, en het is het goede nieuws: de oplossing is een softwarewijziging.
• Daarboven ben je tractiegebonden. Grip en massaverdeling belangrijker dan de frequentie van de lus, en voorbij een bepaald punt is het enige resterende antwoord om langzamer te rijden.

De meeste robots die van dingen vallen zitten in het eerste regime en worden afgesteld alsof ze in het tweede zaten.

Geef jezelf meer millimeters

Het budget is niet vast. Het is de breedte van de randlijn plus de afstand waarop de sensor voor de wielen is gemonteerd, en die tweede term is een vrije ontwerpvariabele:

budget = border + sensor lead

Een sensor 40 mm vóór de aandrijfas maakt van 25 mm randlijn 65 mm stopruimte, en dat is het verschil tussen 0.60 m/s en 0.98 m/s. Los het andersom op als je een doelsnelheid hebt:

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

Praktische grenzen aan hoe ver vooruit je kunt gaan:

• Hij moet de randlijn zien, niet de ring erbuiten. Te ver naar voren gemonteerd kijkt hij voorbij de lijn terwijl de robot nog veilig is, en dat kost je snelheid zonder reden.
• Monteer laag en scherm hem af. Een IR-reflectiesensor op 3 mm leest het oppervlak; op 15 mm leest hij het oppervlak plus de kamerverlichting. Dit is hetzelfde drempel- en kalibratieprobleem dat een lijnvolger heeft, met een veel slechtere storingsvorm.
• Zet er één bij elke voorhoek. Eén centrale sensor vertelt je dat de ergens vooruit ligt. Twee vertellen je welke kant op om ervan weg te draaien, zonder extra latentie.
• Vergeet de achterkant niet. Een robot die naar achteren wordt geduwd steekt de randlijn over voorbij in de verkeerde richting, en de sensoren voorin zullen het nooit zien.

Eerst terug, dan draaien

Bij een vast budget is de volgorde van handelen belangrijker dan het afstellen.

Volledig terug, onmiddellijk. Niet uitglijden — een uitglijdende robot remt alleen op rolweerstand, een kleine fractie van µg, en de overschrijding verdrievoudigt ruwweg. Ook niet zacht remmen: dit is het ene moment waarop een bewegingsprofiel het verkeerde instinct is, want de beperking is afstand en niet gladheid.

Dan draaien, zodra je stilstaat. Draaien terwijl je nog vooruit beweegt maakt van je rechte-lijnprobleem een boog die een hoek van de robot verder naar buiten brengt dan zijn middelpunt. Stop eerst en richt je daarna opnieuw op — en onthoud dat een draai op de plaats de banden de hele tijd zijwaarts schuurt.

Registreer de detectie. Eén wit monster is genoeg. Wachten op twee opeenvolgende metingen om het te bevestigen verdubbelt je reactieafstand in het slechtste geval, en de fout-positief die je daarmee voorkomt is veel goedkoper dan het vallen.

Je eigen latentie meten

Het getal in de tabel is een beginschatting. De jouwe is in ongeveer vijftien minuten te meten.

Van binnenuit. Leg micros() vast wanneer de sensor de drempel passeert en nogmaals op de regel die de omgekeerde PWM schrijft. Dat vangt de softwarehelft, en dat is de helft die je kunt verhelpen. Print de slechtste waarde over honderd detecties, niet het gemiddelde — het slechtste geval bepaalt of de robot van de rand valt.

Van buitenaf. Film het met 240 fps op een telefoon. Tel de frames tussen het passeren van de sensor langs de lijn en het zichtbaar omkeren van de wielen; elk frame is 4.2 ms. Dit vangt de elektrische en mechanische vertraging die software niet kan zien, en het is de enige manier om het totaal te bevestigen.

Van begin tot eind. Rijdt op een bekende snelheid naar een afgeplakte lijn en meet hoe ver voorbij die lijn hij stopt. Trek de berekende remafstand v²/2a daarvan af en wat overblijft is v × t — de totale latentie, gemeten met een liniaal.

Die laatste kost vijf minuten en is de moeite waard vóór alle afstemming, want hij vertelt je welke van de twee termen je werkelijk betaalt.

Als het misgaat

Dezelfde rekensom geldt voor een robot aan een tafelrand, een stofzuiger die trappen vermijdt en een obstakelstop — alleen het budget verandert. De obstakelvermijdingssimulator legt precies deze stopafstandgeometrie bloot met een vooruitkijkende sensor in plaats van een naar beneden gerichte, en het mini-sumo-project is de plek waar het moet werken tegen een tegenstander die je bewust wilt laten falen.