Errechneter Wert ist falsch. Programmfehler? Kann mal jemand drüberschauen?

Sollte ich dann besser die bestehende Logik einfach mit volatile und nointerrupt erweitern oder sollte ich die Zeitmessung zusätzlich in den Interrupt packen?

hi,

vielleicht komplett falsch, aber mir scheints einfach (wenn auch nichtr so elegant):

warum läßt Du nicht einen kleinen ATirgendwas abwechseln messen und die werte an den arduino schicken? würde doch einige der probleme lösen...

gruß stefan

Grundsätzlich gute Idee, die Geschwindigkeit z.B. mit einem zweiten IC zu messen. Da ich die Steuerung aber bereits im Einsatz habe und ungern nochmal umlöten möchte, ist das keine praktikable Lösung für mich.
Davon abgesehen wäre es mit Kanonen auf Spatzen geschossen. Ich bin nicht auf eine absolut exakte Geschwindigkeit angewiesen, es wäre aber schön, wenn sie dennoch stimmen würde (daher hier ja meine Suche nach einer programmatischen Lösung).

Wenn GPS Module nicht so scheiß teuer wären, würde ich eines verbauen und einfach damit die Geschwindigkeit errechnen. Dann hätte ich auch nicht mehr die Probleme mit dem Schlupf (der macht sich nämlich tatsächlich bemerkbar und ich weiß nicht, wie ich den rausrechnen sollte).

hi,

Davon abgesehen wäre es mit Kanonen auf Spatzen geschossen.

naja, wenn die kanone nur 80 Cent kostet...
aber das argument mit umlöten versteh' ich schon.

eine frage zu GPS: laut wikipedia hat GPS eine genauigkeit von 5-8 metern. wird da die ungenauigkeit durch kurven nicht größer als die durch den schlupf ?

gruß stefan

GPS hat im Stillstand eine schlechte Genauigkeit, das ist korrekt. In Bewegung lässt sich die Position aber sehr genau berechnen (etwa 50cm genau).

Du hast aber Recht, in Kurven kann man per GPS keine gescheite Geschwindigkeit errechnen, das geht nur auf der Geraden.
Aber schaust du in der Kurve auf den Tacho? Besonders beim Motorrad? Eigentlich nicht :wink:

Ich würde die Lösung mit GPS dann sowieso nur für eine zusätzliche Anzeige nutzen. Die Geschwindigkeit des Hinterrads muss ich trotzdem weiterhin korrekt berechnen (also incl. Schlupf), da die Geschwindigkeit bzw. die gefahrene Strecke dazu benutzt wird, um die Kette zu ölen. Und die Kette hat nunmal mehr Strecke zurückgelegt, als das Moped (wegen Schlupf).

warum läßt Du nicht einen kleinen ATirgendwas abwechseln messen und die werte an den arduino schicken? würde doch einige der probleme lösen...

Welche ? Ist es denn so , dass der Arduino zu viel zu tun hat, um alle 100 ms die die Geschwindigkeit der letzten 5 Zehntelsekunden zu mitteln ?
Den Schlupf (oder Messprobleme oder einen Programmierfehler ?) kann man doch nicht durch einen zweiten Controller beheben ?
Die letzte der 3 Fehler-Möglichkeiten wird dadurch eher erweitert.

Wenn der Schlupf so groß ist, wie groß ist denn dann die Abnahme des Rad-Durchmessers während einer Fahrt ? :wink:

Wer sagt denn übrigens, dass alle theoretischen Impulse, und nur die, einen Interrupt auslösen. 100% störungsfreie Messtechnik und "hurra, es geht, Impulse kommen" sind leider zwei verschiedene Sachen.
Evtl. mal die Interruptroutine nach Ausreissern fahnden lassen ? Die Zeit zwischen 2 Impulsen sollte sich nur langsam ändern, einzelne Lücken oder Störpulse sollten zumindest erkennbar sein

hi, michael,

und genau darum geht's bei einem zweiten atirgendwas: der kann in ruhe messen, weil andere aufgaben hat er nicht. danach kann er in ruhe korrekturen von wegen schlupf usw. vornehmen, weil andere aufgaben hat er nicht. und wenn er nach 0,1 sek fertig ist, kann er in ruhe die daten zum arduino senden, weil andere aufgaben hat er nicht. eben nicht elegant, aber effizient. der arduino kann ohne durch interrupts unterbrochen zu werden, sein programm ausführen, weil das ist seine aufgabe.
es ist halt ein anderer ansatz...

Den Schlupf (oder Messprobleme oder einen Programmierfehler ?) kann man doch nicht durch einen zweiten Controller beheben ?

doch, genau das kann man:
den schlupf kann man wegrechnen, weil man die zeit dazu hat.
messprobleme werden minimiert, weil der kleine at nur auf daten wartet und sonst nichts zu tun hat.
programmierfehler werden ohne interrupts viel einfachen eingrenzbar.

aber stimmt schon, kostet ja auch viel geld, und wie gesagt, die eleganz...

gruß stefan

Also mit Messfehlern wegen Störungen hatte ich bisher nicht zu kämpfen, da scheint das Tachosignal ganz ordentlich zu sein. Oder es liegt daran, wie gemessen wird (interner Pullup und über Diode an das Tachosignal - somit triggert der Massedurchgang).

Ich habe jetzt mal volatile auf dem Zähler mit reingenommen und noInterrupts für das Auslesen der Messzeit und der gezählten Ticks eingebaut. Weiter werden die Ticks nicht mehr auf 0 gesetzt sondern der zuvor ausgelesene Wert wird abgezogen.

Testen kann ich die Lösung leider erst in ein paar Tagen. Gestern abend wars schon zu spät und heute bin ich dann bis Sonntag unterwegs.
Mal schnell ausprobieren ist leider nicht, da ich den Sitz runternehmen und die hintere Seitenverkleidung abnehmen muss. Das dauert ein wenig.

@Stefan:

messprobleme werden minimiert, weil der kleine at nur auf daten wartet und sonst nichts zu tun hat.
programmierfehler werden ohne interrupts viel einfachen eingrenzbar.

und wenn er nach 0,1 sek fertig ist, kann er in ruhe die daten zum arduino senden, weil andere aufgaben hat er nicht

Versteh ich nicht ganz: Während er 100 msec lang rechnet und dann in Ruhe Daten zum Arduino sendet, müssen die Pulse doch per Interrupt verarbeitet werden, oder ?

Ob der kleine "ATirgendwas" in Ruhe Daten zum Arduino sendet, oder, wenn er sonst nichts mehr zu tun hat, ein Display aktualisiert, ist doch kein wesentlicher Unterschied ?

Interruptgesteuertes Pulse erfassen ist in jedem Fall erforderlich, ansonsten kann alles "in Ruhe" gemacht werden. Ob die Anzeige "ruckelt", hat TelosNox noch nicht gestört. Welche anderen Echtzeit-Anforderungen siehst du ?

"Daten senden" ist in der Regel langwierig. Das bischen Zählen und rumrechnen kann man locker in den Interrupts erledigen. Ja, Interrupts sind einen Tick schwieriger zu programmieren. Aber Systeme mit 2 unabhängigen Prozessoren die aus welchen Gründen nicht mehr miteinander reden wollen sind auch nicht wirklich leichter in den Griff zu bekommen.

Ich würde für sowas auf keinen Fall einen zweiten Prozessor spendieren. Da lohnt es sich mehr sich richtig in Interrupts einzuarbeiten. So schwierig ist das ja nun auch nicht.

hi,

Versteh ich nicht ganz: Während er 100 msec lang rechnet und dann in Ruhe Daten zum Arduino sendet, müssen die Pulse doch per Interrupt verarbeitet werden, oder ?

ich meinte eigentlich, daß er das abwechselnd macht, also:
daten sammeln
berechnen
senden
damit wäre er ja beim pulse sammeln ungestört

"Daten senden" ist in der Regel langwierig

das habe ich nicht bedacht. ich hab meine arduinos noch nicht miteinander "reden" lassen. habe ich mir wohl einfacher vorgestellt.

gruß stefan

Sauberer IO ist fast immer schwieriger als der ganze Rest. Und zwar nicht nur beim Arduino sondern ganz allgemein. Und verteilte Programme sind immer schwieriger als normale. Ob die Verteilung durch Threads, Interrupts oder durch verschiedene CPUs erfolgt ist eigentlich egal. Nur kommt im Fall von getrennten CPUs das IO Problem dazu. Deshalb lieber Interrupts. Wie gesagt, dass ist nicht Arduino spezifisch sondern so gut wie immer so.

Ich hab jetzt den neuen Code ausprobiert und immer noch das gleiche Ergebnis (bei 100km/h Tacho habe ich ca. 84km/h auf dem Arduino).
Ich weiß, dass der Tacho bei 100km/h ca. 7km/h vor geht (laut Navi). Demnach MUSS der errechnete Wert zu wenig sein.

Ich könnte mir vorstellen, dass der Radumfang vielleicht etwas zu klein ist. Ich habe 195cm eingestellt (gemessen), manch andere haben 198cm. Das wären aber auch nur 1,5% Differenz, das würde sich gar nicht auswirken (1km/h mehr).

Ich wollte das aber lediglich berichten. Aktuell belasse ich es einfach dabei, da ich keine Lust habe immer wieder die Verkleidung auf zu machen, damit ich neu programmieren kann.

Wieso Verkleidung aufmachen? Leg doch einen Programmieranschluss nach außen.

heute bekommt wirklich schon alles einen USB-anschluß...

Ich hab ein Gehäuse, in das der Arduino gerade so reinpasst. Da geht kein Stecker mehr in den USB Port.
Wenn ich ein größeres Gehäuse nehme, dann passt es nachher eventuell nicht mehr rein.

Eine Lösung wäre ein USB Kabel direkt dran zu löten. Aber das will ich nicht machen, dann kann ich den Arduino nicht im Bedarf einfach wieder austauschen (bisher ist alles über ein selbstgebautes Shield gelöst).

Davon abgesehen wüsste ich ja sowieso nicht, was ich noch ausprobieren sollte.

hi,

Davon abgesehen wüsste ich ja sowieso nicht, was ich noch ausprobieren sollte.

was mir dazu einfällt: montiere einen camcorder so, daß er den tacho aufnimmt, und beschleunige auf einer geraden strecke mal rauf. gleichzeitig protokolliere die pulse, die der µC erhält (die reinen pulse, nichts berechnen lassen). mit zb. media player classic (gratis) kannst Du zu jeder position des filmes springen. mach dir in excel eine wertetabelle sek : km/h : pulse. laß Dir beides zusammen in einer grafik anzeigen. so eine optische hilfe kann einen weiterbringen, um zusammenhänge zu verstehen.

ich weiß, etwas aufwendig, aber wenn man nicht weiter weiß...

gruß stefan

Kamera wäre vorhanden und auf entsprechende Software hätte ich auch Zugriff.

Allerdings wäre es wieder zu viel Aufwand dafür, dass ich die Geschwindigkeit lediglich anzeige und keinen genauen Wert brauche. Die Geschwindigkeit dient mir ja lediglich um:

  1. zu erkennen, ob das Tachosignal funktioniert
  2. die Geschwindigkeitsprogression des Kettenölers zu berücksichtigen (höhere Geschwindigkeit = mehr abgeschleudertes Öl = früher nachölen)

Dafür reichen mir ungenaue Werte und im Zweifel wird halt mal 10m zu spät geölt, weil die errechnete Geschwindigkeit langsamer war. Bei einem Raster von 100m für die Einstellung sind diese 10m dann auch egal.
Ihr wisst, was ich meine. Die ganze Ölerei ist ja sowieso alles nur pi mal Daumen.

Was mich antreibt ist rein nur der Ehrgeiz herauszufinden, ob ich in meinem Code scheiße gebaut hab (ich bin Softwarentwickler, da sollte ich fähig sein einen funktionierenden Code zu basteln), oder ob das Tachosignal doof ist oder sonst irgendwas in der Art.

Ich war auch schon am überlegen, ob ich mir nicht testweise als Debug mal die Ticks pro Sekunde anzeigen lasse. Das würde zumindest zeigen, ob die Ticks linear mit dem Tacho laufen oder ob vielleicht da bereits ein Fehler ist. Dann kann man darauf schließen, dass die Berechnung stimmt bzw. falsch ist.

Was es mir halt so richtig schwer macht ist die Ableserei. Das Display hängt direkt am Lenker. Ich muss also immer vom Tacho wegschauen. So super 100% konstant Gas geben kann kaum jemand. Also schwankt es immer ein wenig. Den Wert am Display für genau 50km/h Tacho abzulesen ist also nicht gerade einfach.

hi,

genau das meinte ich ja mit camcorder. dann brauchst Du garnicht hinzusehen. und wie gleichmäßig gas Du gibst ist auch egal (ein weiterer nebeneffekt ist die dankbarkeit des typen, den Du nicht überfahren hast). Du hast dann immer zwei parallele vergleichswerte. ich wußte nicht, daß ohnehin beide displays nahe aneinander sind. machts ja noch leichter.

Ich war auch schon am überlegen, ob ich mir nicht testweise als Debug mal die Ticks pro Sekunde anzeigen lasse.

genau, das und den tachowert auf einem bild.

gruß stefan