fahrzeug mit vier motoren und vier encodern

[RoboHolIC]

Hallo Inka.

- habe die "summen" mit "=0" versehen - kein einfluss auf den ablauf

Hatte ich auch nicht wirklich erwartet, weil die Zählungen ansich ja ganz vernünftig aussahen.

- habe sämtliche printanweisungen entferrnt - geschockt - die räder 3 & 4 zuckten nur kurz . . . das unterschiedliche anlaufen und abbremsen . . . variiert um mehrere umdrehungen und wechselt von mal zu mal auch die reihenfolge der räder...

Uiii. da liegt aber noch was ganz im Argen. digitalRead(encoder_n) klingt sehr nach Bibliotheksfunkion. Hast du die Doku dazu studiert? Wechselwirkungen im Einsatz mit anderen Funktionen? Evtl. Überschneidungen bei den Controllerpins?
'Encoder' klingt für mich auch nach mehreren Spuren für die Richtungserkennung (Quadraturencoder) oder Absolutposition. Passen Sensor und Auswertungscode wirklich zusammen?

Ich habe mich ein wenig vertieft in deinen Code, habe die Idee dahinter aber noch nicht verstanden (vllt. auch deswegen, weil es mir schwer fällt, mich auf andere Programmiergewohnheiten einzustellen):
- Steckt da an irgend einer Stelle die Erkennung einer Flanke (dunker --> hell) drin? Zehnmal "hell" gemessen müssen ja keine zehn Zählpulse sein!
- Sperrzeit nach der Flankenerkennung oder Schmitt-Trigger-Eingang, damit nicht mechanische Vibrationen aus einem Übergang mehrere Pulse machen können.
- Warum werden die Motoren nicht bestmöglich zeitgleichgestartet? Und ?immer wieder? gestartet - auch wenn das vielleicht nicht schadet.

"motorfahrer" . . . kommunikation über IIc

Das sind klassisch zwei verschiedene Aufgaben auf einem Controller: Eine zeitkritische, nämlich die Encoderauswertung - und eine zeitUNkritische, nämlich die I2C-Kommunikation.
Wenn du die beiden pollend in einer gemeinsamen Schleife bearbeitest, mag das zu Anfang funktionieren. Kommt dann mehr und mehr Code hinzu, steigt die Zykluszeit evtl. so weit an (vgl. deine seriellen Ausgaben!), dass der Controller bei der gewählten Drehzahl nicht mehr alle Inputs der Radsensoren mitkriegt. Besser ist es, die Encoderauswertung in einen Interrupt zu packen - dort kann sie mit Vorrang (ggf. in festem Zeitraster) abgearbeitet werden. Die Kommunikation und der ganze Rest darf meist innerhalb gewisser Grenzen mal ein wenig früher oder später in der Schleife passieren, ohne dass gleich das System aus dem Tritt gerät.

Mut zum Interrupt - das ist meine Devise. Keines meiner Projekte arbeitet ohne.

Gruß
Christian.