Menü
Aktuelles
Von:
Filter

Odometrie bringt Mega zum Absturz?

@Patrick,
ich nutze nicht das Odometrie Modul aus dem Shop. Bei mir sind alte Gabellichtschranken aus einem ausgedienten Drucker verbaut. Es gab dazu hier irgendwo im Forum mal einen Artikel/Anleitung dazu.
Daher kann ich leider nichts zu den Potis vom Odometrie Modul sagen. Ich vermute man kann damit die Flanke einstellen.
Module Features:
the use of imported groove coupler sensor
the slot width 5mm.
the output state indicator lamp output high, output low lights.
with cover, high output; unobstructed, output low.
the comparator output signal clean waveform is good, driving ability, than 15mA.
Operating Voltage 3.3V-5V
the output format: Digital switching output (0 and 1)
a fixed bolt holes for easy installation
small plates PCB size: 3.2cm x 1.7cm
using a wide voltage LM393 comparator
Gruß Stephan
 
Hallo,

ich denke ich weiß wo das Problem liegt, ab Version 1.0a5 ist der Interrupt leer:
------
#ifdef __AVR__
ISR(PCINT2_vect, ISR_NOBLOCK){
#else
ISR(PCINT2_vect){
#endif
----

Hier fehlt der Code der ausgeführt werden soll wenn der Interrupt aufgerufen wird und vor allem die "}" am Ende:
------------------------
unsigned long timeMicros = micros();
boolean odometryLeftState = digitalRead(pinOdometryLeft);
boolean odometryLeftState2 = digitalRead(pinOdometryLeft2);
boolean odometryRightState = digitalRead(pinOdometryRight);
boolean odometryRightState2 = digitalRead(pinOdometryRight2);
boolean motorMowRpmState = digitalRead(pinMotorMowRpm);
robot.setOdometryState(timeMicros, odometryLeftState, odometryRightState, odometryLeftState2, odometryRightState2);
robot.setMotorMowRPMState(motorMowRpmState);
}
------------------------

Alex
 
Hallo Alex,

da bin ich mir nicht sicher. Hast du es erfolgreich getestet?
So wie ich das sehe, ist der auszuführende Code da und die Klammer ist auch gesetzt. Die #-Anweisungen sind Compiler Anweisungen. Der Compiler entscheidet hier je nach Plattform, wie die ISR definiert wird.


Code: 
#ifdef __AVR__
ISR(PCINT2_vect, ISR_NOBLOCK){
#else
ISR(PCINT2_vect){
#endif
  unsigned long timeMicros = micros();
  boolean odometryLeftState = digitalRead(pinOdometryLeft);
  boolean odometryLeftState2 = digitalRead(pinOdometryLeft2);
  boolean odometryRightState = digitalRead(pinOdometryRight);  
  boolean odometryRightState2 = digitalRead(pinOdometryRight2);  
  boolean motorMowRpmState = digitalRead(pinMotorMowRpm);
  robot.setOdometryState(timeMicros, odometryLeftState, odometryRightState, odometryLeftState2, odometryRightState2);   
  robot.setMotorMowRPMState(motorMowRpmState);  
}


So schaut es bei mir aus
 
Hallo Patrick,
es hat leider wieder nicht beständig funktioniert(egal ob mit oder ohne Compileranweisung), war wohl eher Zufall dass er in einer Regenpause eine halbe Stunde gelaufen ist.

Hab in die Interruptanweisung wo die Odometriesignale übergeben werden eine serielle Ausgabe eingefügt und bemerkt dass jeder einzelne Sichnalwechsel von 1 auf 0 oder umgekehrt unzählige interrupts auslöst!
Momentan teste ich mit den digitalen Eigängen für RC (11 u.12) die scheinbar bei Signalwechseln weniger Interrupts auslösen.
Hab mir allerdings ein anderes Problem eingefangen, nämlich dass er nach kurzer Fahrt vorwärts denkt er sei außerhalb der Schleife und wieder rein will! Das sollte aber mit der Änderung auf die digitalen Eingänge weniger zu tun haben.
Hatte allerdings keine Zeit mehr das näher zu untersuchen....
 
Hallo,

wirklich schade, dann ist unser Problem leider noch nicht gelöst.
Ich glaube du bist dem Problem aber ein gutes Stück näher gekommen. Der Flankenwechsel sollte ja nur einen Interrupt auslösen. Wenn du bei den echten digitalen Eingängen weniger Interrupts hast (immer noch mehr als einen?), vermute ich dass die Kombination analoger Eingang mit Comparator des Odometrie Moduls das Problem verursacht.
Stefan nutzt eine einfache Lichtschranke ohne Comparator und hat keine Probleme.

Ich schaue mal, ob ich zum Comparator was finde, ggf. müssen wir einfach an den Potis drehen um weniger Signale zu bekommen.

Aktuell rüste ich auf die neue 1.0a6 Version um, weil ich mir von der NewPing Bibliothek einiges erhoffe.
(Bisher lösen die US Sensoren unzuverlässig aus, meistens wenn es eh zu spät ist. Trigger hochsetzen hilft leider auch nicht. Außerdem fährt er mit US und Perimeter deutlich schlechter). Muss noch meine Codeanpassungen nachziehen.

Danach geht es weiter mit Odometrie.
 
Ich denke mittlerweile auch dass die Kombination Comperator und AnalogEingang als Trigger des Interrupt das
Problem verursacht.
Es war auch beim digitalen Pin mehr als ein Interrupt, allerdings sprechen wir hier von 1-4, beim analogen Pin als Trigger eher von 50 bis ??...

Ich muss mir das Signal am Pin nochmal mit dem Oszi ansehen bzw. prüfen ob es Unterschiede gibt ob der Comperator bei den Analogeingängen oder den DigitalPins angeschlossen Signale liefert(eher unwahrscheinlich aber wer weiß).
Wenn ich das Datenblatt des Mega richtig verstehe sollten eigentlich immer logische Signalwechsel den Trigger des Interrupt auslösen, zuletzt hatte ich allerdings bei den analogenEingängen das Gefühl als würden Wertänderungen reichen (wie gesagt ist es aber nur ein Gefühl).

Bin gespannt wie es dir mit den US und NewPing geht, habe es kurz getestet, hatte gleich einige Fehlauslöser und hab es da ich es nicht wirklich brauche wieder abgeschaltet.
 
Hi,
jetzt läuft dass Ding seit mehreren Stunden ohne Probleme :)
Problem dürfte eine kalte Lötstelle am RC-Glied gewesen sein.
Hab meiner externen Entstörschaltung jetzt zusätzlich einen 100µF Kondensator spendiert der auch die anderen analogen Signale nochmal etwas beruhigt hat!

Alex
 
Kannst du kurz den Schaltplanausschnitt posten, damit es ein bissel klarer wird, wie du dein Problem in den Griff bekommen hast?

Gruß,
Jem
 
Das wäre die Stelle die bei mir das Problem verursacht hat:
ODORC.jpg


Im Endeffekt muss das Signal sauber rein kommen (ohne rauschen) da sonst unzählige interrupts ausgelöst werden die dann die Steuerung überfordern!
Attachment: https://forum.ardumower.de/data/media/kunena/attachments/939/ODORC.jpg/
 
Zuletzt bearbeitet von einem Moderator:
Was hat du genau geändert? Bei der Odemetrie sind die Widerstande des RC Gliedes gebrückt und der Kondensator ist über eine Lötbrücke standardmäßig ohne Funktion. Damit ist das RC Glied ohne Funktion.
Um das zu nutzen müsste bei den Widerstandsnetzwerk eine Leiterbahn unterbrochen werden und bei den Kondensator eine Lötbrücke geschlossen werden.

Gruß
Uwe
 
Hi Uwe,
wie kurz erwähnt hab ich eine externe Schaltung für die Glättung der analogen Signale und auch Odometrie die eine kalte Lötstelle hatte.
Das Board aus dem Shop kenne ich bis auf den Schaltplan nicht so genau, denke aber dass es nicht schaden kann
das RC-Glied zu aktivieren oder evtl. zuerst mit einem externen RC-Glied zu testen.

Alex
 
Hallo,

schön dass es bei dir jetzt klappt.
Da ich nicht plane, eine Funkfernbedienung zu nutzen, werde ich die Odometrie mal über die Pins laufen lassen. Ich habe manuell mal getestet. Wenn ich den Sensor unterbreche, wird für die entsprechende Seite genau einmal gezählt. Bei mehrfach auslösendem Interrupt würde ich erwarten, dass mehrfach gezählt würde. Aufgefallen ist mir auch, dass immer nur bei fallender Flanke gezählt wird. Bei steigender Flanke wird offensichtlich kein Interrupt ausgelöst.
Dürfte meiner Ansicht nach aber nicht zu einem Problem führen.

Wenn der Bock unterwegs ist, kann ich am Handy auch schön sehen, dass für beide Seiten gezählt wird. Die Werte für links und rechts weichen auch nicht sonderlich voneinander ab, also scheinen die Interrupts korrekt zu laufen.
Ich werde auch mal Konsolenausgaben verwenden, um die Interrupts zu debuggen.

Ich habe da aber mal eine Frage an die Experten. So wie ich das bisher verstanden habe, wird der Interrupt nicht für einen einzelnen Pin, sondern für ganze Gruppen von Pins aktiviert. Damit wird der Interrupt ausgelöst, sobald einer der Pins sich ändert. Ich habe aber nicht herausfinden können, welche Pins denn zusammen zu den Odometrie Pins gehören (aus Sicht der Interrupt Gruppe). Meine Vermutung ist, dass andere Pins floaten und damit unzählige Interrupts auslösen.
Ich z.B. habe ja nur One-Wire Odometrie, keine MOW RPM und über die Charge Pins kommt ja im Mähbetrieb auch nichts.
Könnte das evtl. daran liegen`?
 
Hi bin unterwegs daher nur kurz.
Das RC-Glied (Tiefpass) für den ODO INT zu nutzen ist nicht besonders sinnvoll, da damit aus einer ordentlichen Flanke ein gebogenes etwas wird. Möchte man an dieser Stelle einen schönen Filter sollte danach ein Schmitt-Trigger sitzen. INT Eingänge lieben eindeutige Flanken.

Das mit der INT-Gruppe stimmt und stimmt auch wieder nicht. Da man ja in der jeweiligen Gruppe auch noch einstellen kann welche PCINT-Pins jetzt als solche fungieren dürfen und welche nicht.
Wird der jeweilige Guppen-INT-Vektor angesprungen schaut man in der INT-Routine einfach nach welcher von den vielen es jetzt war. Genaue Infos findet man im Datenblatt ab Seite 109.

Gruß

Jürgen
 
Nabend,
ich habe mir auch die Odometrie Scheiben von Stefan ausdrucken lassen und an die GMPD Motoren von Pollin montiert.
2100 Impulse pro Radumdrehung.
Azurit 1.0a5
Dual Drehzalsensor aus dem Shop.
Nichts an der Software geändert.
Bei mir stürtzt nichts ab.


Gruß Thomas
 
Ui, kannst du mir davon mal ein Foto machen? Das heisst, du hast den Motor aufgemacht, um an die Motorwelle zu kommen? Da scheue ich mich noch vor ...

Gruß,
Jem
 
Hallo,
ich habe einen Permanet-Magnet mit Sekundenkleber an die Odometrie-Scheibe geklebt,
den Motor habe ich hinten an der Motorwelle etwas aufgebohrt 6 mm
und die Odometrie-Scheibe mit dem Magneten an der Motorelle befestigt.

Gruß Thomas
 
Hallo zusammen.
Da ich schon eine ganze Weile so mitlesen und gerade mit beim meinem Aufbau beim Thema Odometrie angekommen bin, frage ich mich wie das ganze eigentlich genau funktioniert.
Mich interessiert vor allem warum so viele Ticks pro Umdrehung benutzt werden.
Warum werden auch meistens die Signale am Motor und nicht am Rad abgenommen.
Wie sieht das mit dem Umkehrspiel (Backlash) der Mechanik aus?
Wenn ich in meinen Beruf einen Gleichlauf Programmiere (SPS), dann versuche ich das nicht mit möglichst vielen Impulsen, sondern ich messe die Zeit zwischen zwei Impulsen und gleiche dementsprechend an. Somit kann man mit weniger Interrupts auch genau regeln.
Ist vielleicht eine Idee…….
 
Hat wohl damit zu tun, dass die Funktion, die vom Interrupt aufgerufen wird, möglichst kurz sein muss. Ich weiss jetzt nicht, wie lange es dauert, die micros()-Funktion aufzurufen und die Werte (Alter Wert und Neuer Wert, zw. ein Delta berechnen) zwischenzuspeichern, um sie dann außerhalb der Interruptfunktion auszuwerten, aber ein simples i++ in der Funktion geht garantiert schneller. Jeder Takt zählt, vor allem wenn man sowas aufwendiges wie die Perimeterauswertung noch mit drin hat.

Gruß,
Jem
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben