fahrzeug mit vier motoren und vier encodern

[inka]

Hi RoboHolIC,

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?

also: als encoder wird das teil vom hersteller/lieferanten bezeichnet, hat die anschlüsse Vcc / GND und OUT und ist eher eine lichtschranke mit einer lochscheibe, die 20x pro umdrehung hell und dunkel unterscheidet. Es ist noch eine rote LED und irgendein IC auf der platine, dessen funktion nicht klar ist. Die bibliothek für die motoren ist die von Adafruit, studiert habe ich sie nicht, die befehle aus einem beispiel so übernommen...

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)

ich habe hier meinen code (den teil mit dem ersten motor) kommentiert, mir ist durchaus bewusst, dass bei einer 20er teilung und der relativ langsamen drehung des motors mehrere dutzend positive wie negative signale (null oder 1) beim arduino-pin ankommen bevor ein echter wechsel in der hardware passiert, habe also versucht nur das jeweils erste signal zu cashen (zaehler_1) und die abfrage damit zu steuern...

void(loop)
{
  wert_1=digitalRead(encoder_1); //wert des encoders einlesen und speichern, 0 oder 1, hell oder dunkel
  
  if (summe_1 <= 19 && zaehler_1 == 0) // wenn summe <= "19" UND keine "0-impulse" gezählt
 
  {
    motor_1.setSpeed(150); //geschwindigkeit auf 150 stellen (0 bis 250 möglich)
    motor_1.run(FORWARD); // forwärts fahren
    zaehler_1 = 1; //, zähler der "0-impulse" auf "1" stellen
  }

  else if (summe_1 <= 19 && zaehler_1 == 1) // wenn summe < als 19 UND der zähler der "0-impulse" = "1"
  {
    zaehler_1 = 0; // zähler der "0-impulse" wieder auf "0" stellen
    summe_1 = (summe_1 + wert_1); // summe um "1" (den wert des encoders) erhöhen
    motor_1.setSpeed(0); // geschwindigkeit auf "0" stellen
    motor_1.run(RELEASE); // motor freigeben (kein antrieb, kein bremsen)
  }
}

vielleicht wird das jetzt klarer, welcher gedanke dahintersteckt, habe aber bereits zweifel angekündigt, ob der ansatz so ok ist - bei einem motor funktioniert es ja halbwegs...

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

siehe oben...

- Warum werden die Motoren nicht bestmöglich zeitgleichgestartet? Und ?immer wieder? gestartet - auch wenn das vielleicht nicht schadet.

Du meinst bei allen motoren im setup die geschwindigkeit festlegen und auch dort nacheinader starten? Oder teilen: geschwindigkeit im setup, start alle kurz hintereinander im loop? Ich hatte angst, dass die dann schon zu weit/zu lange drehen bis die abfrage nach dem signal kommt, ist aber wohl unbegründet...Muss ich probieren...

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.

ich möchte erstmal den zeitkritischen teil bearbeiten, das mit dem IIc ist noch weit, weit weg

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

Du hast gut reden. Aber auch recht...

[RoboHolIC]

Hallo inka.

Ich sehe da keine Flankenerkennung. Die IF-Anweisungen enthalten keinerlei Abhängigkeit vom Encodersignal. Stattdessen wird zaehler_1 im ersten IF auf 1 erhöht, erfüllt damit die Teil-Bedingung zaehler_1 ==1 im zweiten IF, wo dieselbe Variable sofort wieder auf Null gesetzt und der eigentliche Counter summe_1 erhöht wird.
Das bedeutet doch, dass in den ersten 19 Durchläufen die Bedingungen immer erfüllt sind und der rein zufällige Zustand des Encoders zu summe addiert wird. Das ist vielleicht ganz lustig, zählt aber keine Flanken, obwohl die Summe früher oder später 19 überschreitet. Das passiert nämlich selbst dann, wenn das Rad im Encoderzustand 1 (oder eben "H") blockiert.

Flanken erkennt man z.B., indem man pro Durchlauf den Input der vorherigen Runde mit dem aktuellen vergleicht, ggf. den Zähler erhöht (oder ein Flag setzt) und anschließend den aktuellen Input als "neuen alten" Vergleichswert für die nächste Runde speichert.

Warum in aller Welt die ständige Umschaltung zwischen Antrieb und Leerlauf? Das Teil soll doch fahren und nicht parken.

Und wo fährt wohl ein Rollstuhlfahrer hin, wenn er aus der Ruhe zunächst nur mit der Linken antreibt, mit der Rechten aber erst noch ein wenig UARTelefoniert, bevor er dann doch auch diese zum Vortrieb verwendet? Sicher übertrieben skizziert, könnte aber zur Erhellung beitragen.


Gruß
Christian.