Drehzahl Messung

[robonooby]

hat keiner ne Idee wieso das Softwareseitig nicht funktionieren will?

[RoboHolIC]

Ich habe keine Löschung der Interruptflags gesehen. Geschieht die bei Bascom evtl. ohne ausdrücklichen Befehl ? Falls nein, wird der Controller wohl nach dem ersten Zählimpuls je Kanal (L/R) keine weiteren Zähl-Interrupts ausführen.

[Besserwessi]

Die Signale sehen nicht so schlecht aus. Das sollte der AVR noch als Signal erkennen können. Der gelbe Kanal hat wohl ein etwas schwächeres Signal. Das könnt z.B. an der Ausrichtung der LED liegen.

Beim Programm ist noch ein Fehler drin: es muss durch die Zahl der Timerüberläufe dividiert werden, und mit 61,... multipliziert - nicht anders herum. Anhängig davon wie oft die Routine aufgerufen wird muss man noch aufpassen das man keine Überläufe bekommt, oder bei sehr schnellem Aufruf den Fall 0/0 bekommt. Gegen das Problem mit zu häufigem Aufruf könnte es etwas helfen, wenn man das Zurücksetzen der Zähler nur macht wenn die Zeit größer als etwa 0,5 s war. Je nach Anwendung wäre zu überlegen eine andere Einheit als Umdrehungen pro Sekunde zu nutzen. Das gibt für die Räder nämlich wohl eher kleine Zahlen und damit ggf. Rundungsprobleme. Ggf. könnte man die beiden Faktoren 8 und 61,... auch noch gleich zusammenfassen: also nicht erst / 8 und dann mal 61,... sondern gleich nur mit 7,6.... multiplizieren.

[robonooby]

Ich habe keine Löschung der Interruptflags gesehen. Geschieht die bei Bascom evtl. ohne ausdrücklichen Befehl ? Falls nein, wird der Controller wohl nach dem ersten Zählimpuls je Kanal (L/R) keine weiteren Zähl-Interrupts ausführen.

Wie meinst du die Interruptflags löschen? Wie geht das?^^

Die Signale sehen nicht so schlecht aus. Das sollte der AVR noch als Signal erkennen können. Der gelbe Kanal hat wohl ein etwas schwächeres Signal. Das könnt z.B. an der Ausrichtung der LED liegen.

Beim Programm ist noch ein Fehler drin: es muss durch die Zahl der Timerüberläufe dividiert werden, und mit 61,... multipliziert - nicht anders herum. Anhängig davon wie oft die Routine aufgerufen wird muss man noch aufpassen das man keine Überläufe bekommt, oder bei sehr schnellem Aufruf den Fall 0/0 bekommt. Gegen das Problem mit zu häufigem Aufruf könnte es etwas helfen, wenn man das Zurücksetzen der Zähler nur macht wenn die Zeit größer als etwa 0,5 s war. Je nach Anwendung wäre zu überlegen eine andere Einheit als Umdrehungen pro Sekunde zu nutzen. Das gibt für die Räder nämlich wohl eher kleine Zahlen und damit ggf. Rundungsprobleme. Ggf. könnte man die beiden Faktoren 8 und 61,... auch noch gleich zusammenfassen: also nicht erst / 8 und dann mal 61,... sondern gleich nur mit 7,6.... multiplizieren.

also danke für den Tip. Das hab ich irgendwie mit der Berechnungseingabe vertauscht. Hab die Berechnung mal geändert. Überläufe dürften eigentlich keine entstehen da das Rad relativ Langsam sich dreht. vielleicht 25-max 100 Umdrehungen / minute. Der Bot soll ja nicht schnell fahren^^ Aber ich kann wenn er irgendwelche Werte schonmal raus bringt das mal einbauen. Ich werde jetzt erstmal die Berechnung prüfen.

Wäre aber noch schön wenn mir jemand sagen könnte ob man dieses Interruptflag löschen muss?

[RoboHolIC]

Wie meinst du die Interruptflags löschen? Wie geht das?

Bei Prozessoren zwingt ein gesetztes Interrupt Request Flag den Controller in die Interruptbearbeitung, sofern diese freigeschaltet ist. Diese Flags sind statisch und "speichernd", damit auch die Priorisierung (Rangfolge) zwischen verschiedenen Interruptquellen funktioniert, d.h. damit der Prozessor keinen rangniedrigeren Interrupt Request vergisst.

Wenn man in der Serviceroutine die Löschung des IRQ-Flags unterlässt, wird derselbe IRQ immer und immer wieder ausgeführt und der Prozessor kommt nicht mehr zur Bearbeitung des Hauptprogramms.

Nun weiss ich aber nicht wie Bascom das handhabt; dazu müsste sich ein Kenner äußern.

[robonooby]

Ah okay. ja scheinbar braucht man das nicht zu tun. War wirklich nur nen Berechnungsfehler wie Besserwessi geschrieben hat, dadurch kam dann nen 0,0... Wert raus und er hat nichts angezeigt.
Also vom Prinzip her funktioniert es jetzt. Raddrehzahl Rechts (Blaue Kurve oben im Oszi Bild) zeigt er jetzt ca 18 Umdrehungen pro Sekunde an.  
Danke hierfür schonmal für eure Hilfe.

Was nicht richtig geht ist Drezahl Links (Gelbe Kurve oben im Oszi Bild). Hier erkennt er scheinbar doch nicht die kleinen Pieks. Sind scheinbar doch zu schmal. Es kommt hier immer Null raus. Wenn mans mal 5 Minuten laufen lässt auch ab und an mal 1 oder 2 aber mehr nicht. Also muss ich hier noch was machen.
Weis vielleicht jemand woran das liegen könnte? Ist wirklich der Sensor nicht richtig justiert? Hab das Fahrgestell so gekauft mit allem drum und dran.

[RoboHolIC]

Hallo robonooby.

Im oberen zeitgerafften Bild sieht man ja auch deutlich, dass der Scheitelwert des gelben Signals starken Schwankungen unterworfen ist, während der blaue Kanal immer voll in die Sättigung geht. Da solltest du wirklich vorrangig rangehen.

Bring es optisch und elektrisch in Ordnung, also Lichtschranke und ggf. Fächerscheibe justieren, kontrollieren. Fächerscheibe OK oder evtl. zu kontrastschwach???

Einen Schmitt-Trigger würde ich zuletzt einbauen. Wenn nach dem nächsten Stoß der vielleicht jetzt "auf Kante" gerade noch funktionierende Lichtschrankenkanal gar nicht mehr funktioniert, hilft dir nämlich auch kein Schmitt-Trigger mehr.


Gruß
RoboHolIC

[robonooby]

Okay. also muss ich wohl oder übel doch den Bot nochmal komplett zerlegen^^
Schade, wird wieder viel Arbeit xD

Werd das dann mal die nächste Woche angehen und Bericht erstatten ^^