Das mit der Frau kenne ich, wenn ich meiner Freundin von meinen Fortschritten erzähle, sieht sie mich genauso an wie ihr Hund, wenn ichs _dem_ erzähle. [-(

Und du hast recht, es macht wahnsinnig Spass, richtig spannend.
Ich habe inzwischen etwas probiert:

Gezieltes Bremsen (ein, zwei Odoklicks vor dem Ziel rückwärts) _kann_ funktionieren, aber zu ungenau, damit kriege ich das Ergebnis runter auf ca. einen Odoklick (ich weiss, blödes Wort aber die Variable in meinem Programm heisst nunmal so und ich glaube, irgendwann denkt man einfach in Variablen ), aber das reicht mir nicht.

Im Moment bin ich dabei, ein Stück vor dem Ziel (derzeit zehn Odoklicks, also rund 6cm) das Tempo zu drosseln, so dass bei Zählerstand Null auch die Motoren stehen: funktioniert nicht wirklich.
Obwohl ich in 50er Schritten runterregle (immer einen pro Klick, weil ich mit Halbgas "repräsentativ" arbeite, ergeben sich weiterhin die üblichen Ungenauigkeiten.
Ausserdem gefällt mir diese Lösung nicht: 6cm Bremsweg??
Es _muss_ deutlich kürzer gehen, sonst ist die Variante viel zu unflexibel.
Leider haben beide Varianten einen grossen Nachteil: sie sind im Grunde unkontrollierbar, man kann in Situationen kommen, in denen der Roboter zu früh oder zu spät steht. Es funktioniert mit voreingestellten Parametern so untergrundabhängig, dass ich bei letzter Methode z.B. auf Teppich das Ziel gar nicht erreichen kann, während der Roboter im Freien ( Räder in der Luft) noch immer zu weit "fährt".

Ich denke, da muss ein eigenes Bremsprogramm hinein, was obendrein die Drehzahl überwacht.
Nur habe ich ab und an jetzt schon den Verdacht, dass mitunter Odoklicks "übersehen" werden, weil einfach irgendwas nicht mehr nachkommt- ist das technisch denkbar?
Soweit ich es richtig verstanden habe, erzeugen doch die Odosensoren einen Interrupt, richtig?
Wenn das aber stimmt, dann _müssen_ die ja auch, falls zurzeit eine andere Interruptroutine läuft (nebenbei strapaziere ich in meinem Programm Timer0 ein bisschen), gespeichert und anschliessend richtig aufgerufen werden? Auch richtig?
Leider hab ich nicht genug Ahnung von der Sache, um beurteilen zu können, _Was_ man besser unterlassen sollte, um den Prozessor nicht nennenswert auszubremsen, ich weiss nur, dass Fliesskommaberechnungen richtig dauern können, darum würdest du wohl gerne ohne auskommen?
Es geht, wenn sie nicht in zeitkritischen Momenten erfolgen, und _das_ kann man umgehen, denke ich (bei hindernisfreier Fahrt kann der Prozessor das nebenbei mit erledigen).
Das Problem bei den gespeicherten (und zeitlich später ausgewerteten Odo-Interrupts ist klar: ehe der Prozessor reagieren kann, stimmt der Odowert im Extremfalle nicht mehr, muss also alles fix gehen.

Die Räder sind übrigens absolut nicht das Problem (wobei klar ist, dass dauerhaft bessere rauf müssen), es ist wie ich sagte:

Die Motoren rotieren nach dem Abschalten noch etwas weiter (normal, Masseträgheit) und dadurch wird übers Ziel hinaus gefahren.
Kannst du auch ohne Display testen:
schreib dir eine kleine Routine, die ein Lämpchen anschaltet, _wenn_ der Roboter zu weit "gefahren" ist und lass ihn einfach, wie ichs tu, leer laufen (anheben), dann kannst du Radschlupf ausschliessen.
Immerhin braucht der Motor durch die Getriebeuntersetzung, nur ein und ne viertle Umdrehung, und schon hast du einen Odoklick zu viel auf dem Tacho.