Alle GPIO gleichzeitig lesen

  • War gerade auf Toilette, und da hat man ja oft die besten Ideen.

    Ich komme sogar mit 2 Lichtschranken aus!

    1 Laser parallel und 1 Laser diagonal.

    Der Ball hat 23cm Durchmesser. Abstand der Lichtschranken z.B.6cm Abstand Foto 2cm

    Ich kann also erfassen

    Laser 1 parallel rising : starttime lesen Foto auf GPIO 1_Event

    Laser 2 rising : time lesen ( für Position ) Foto auf GPIO2_Event

    Laser1 parallel falling : time lesen ( für Geschwindigkeit + für Position )

    Das könnte für RASPi dann auch klappen trotz OS Aufgaben

  • Das stimmt. Ich hatte auch erst die Idee mit zwei Strahlen... hab aber gar nicht dran gedacht, dass man mit dem Durchmesser der Bälle arbeiten kann... Die Geschwindigkeit ändert sich ja wahrscheinlich im Verlauf des Wurfs nicht so wesentlich. Und für verschiedene Bälle könnte man ja auch die Durchmesser einrechnen.

    So kommst du mit einem Arduino auch hin und brauchst auch noch weniger Lichtschranken. (Gibts hier eigentlich kein Daumen-hoch-Smiley? ;)

    Um die Abweichungen gering zu halten, sollten die beiden Laserstrahlen sich in der Mitte kreuzen.

    Der Raspi wird das trotzdem nicht schaffen - er hat eben oft Verzögerungen von einigen Millisekunden, wenn er einen Systeminterrupt abarbeitet. Das ist wie beim PC - wenn der auf der Festplatte rumrödelt, geht auch oft länger nichts weiter... Mit einem µC bist du da sicher.

    Und wenn du dann noch ein WLAN-Shield für den Arduino einbaust, kannst du die Daten an PC/Notebook schicken und in Echtzeit anzeigen...

    Die Verkabelung würde mich noch stören. Immerhin Strom für 20 Stationen und insgesamt 40 Kabel zu den GPIOs... Naja, wenn der Controller in der Mitte steht, sind es 20 Kabel + strom in jede Richtung mit max. 3,5 Meter... das geht vielleicht noch. Ein Mikrocontroller in jeder Station und ein Bus für die Datenübertragung wäre überschaubarer - besonders, wenn es dann doch noch mehr Stationen werden.

    Übrigens: Wenn man die Idee mit einer Lichtschranke statt zwei zu Ende denkt, dann könnte man die Differenz der beiden Lichtschranken einmal bei der steigenden und einmal bei der fallenden Flanke messen. Dann würden Lichtschranken im Abstand von zwei Balldurchmessern genügen, um zwei Messwerte zu erfassen - also 7 / 0,46 = 15,2 also würden dann 15 Laserstationen und 30 Lichtschranken genügen, um 30 Messwerte zu bekommen.

    Vielleicht kann man es noch weiter treiben und es genügen jeweils abwechselnd gerade und gewinkelte Laser alle 46 cm.

    - Der erste (gerade) Laser dient zur Bestimmung der Geschwindigkeit. (Hier evtl. einen zusätzlichen Laser für die Position.)

    - Der zweite ist schräg. Es wird wiederum die Geschwindigkeit ermittelt (evtl. aus beiden Messwerten einen Durchschnitt bilden). Aus der Geschwindigkeit und der Winkelung des Lasers kann die Position bestimmt werden. Und zwar zweimal - bei fallender und steigender Flanke.

    - Der dritte Laser ist wieder gerade. Wieder Bestimmung der (Durchschnitts)geschwindigkeit und der Position...

    usw.

    Also aus den Positionen A/B, C/D und E/F kann man jeweils die Geschwindigkeit ermitteln.

    Als Mittelwert lassen sich die Geschwindigkeiten g1und g2 näherungsweise berechnen.

    Und aus der Zeit damit die Position. Ich bin mir nur nicht sicher, wie weit sich Fehler hier aufsummieren.

    Dann kommst du mit 15 Lasern aus. Allerdings ist die Justage deutlich schwieriger. Und ob das genau genug ist, kann ich auch schwer abschätzen.

    Mit nem cleveren Spiegelsystem kommst du vielleicht sogar mit einem weniger Lasern aus... die dürfen dann aber nicht so stark streuen.

    Das alles steht und fällt mit der Genauigkeit der Geschwindigkeitsbestimmung. Wenn der Laserwinkel bei 30 cm Abstand 6 cm Ausmacht, sind das 20%. Diese 20% Weg- und Zeitversatz entsprechen dem Meter Bahnbreite. Wenn die Geschwindigkeit um 2% ungenau gemessen wird, entspricht das schon 10 cm der Bahnposition. Der Balldurchmesser entspricht 1/30 der Messstrecke. Würde sich die Geschwindigkeit des Balls auf dieser Strecke um 30% verändern, wären das 1% auf einen Balldurchmesser (der hier als Messbasis für die Geschwindigkeit dient). Ich nehme nicht an, dass sich die Bälle so massiv verlangsamen. Wenn es 15% auf den 7 Metern wären, läge der Messfehler bei 0,5%. Wenn man dann noch mit Durchschnitten rechnet, kann man den Fehler vielleicht weiter reduzieren und käme in einen Genauigkeitsbereich unter 2,5 cm.

    Das ist ne richtig spannende Aufgabe. Ich komm dann mal zum Kegeln (äh, Bowlen ;) und schau mir das an, wenn es fertig ist.

    Oh, man kann hier unliebsame Nutzer blockieren. Wie praktisch!

  • Das sollte ja auch heißen:

    Das ist ne richtig spannende Aufgabe. Ich komm dann mal zum Kegeln (äh, Bowlen ;- ) und schau mir das an, wenn es fertig ist.

    Aber das freche System ersetzt einfach mein ASCII-Smiley ;) (Gut, hier darf es... aber jetzt nicht! ;- )

    Oh, man kann hier unliebsame Nutzer blockieren. Wie praktisch!

  • Die Geschwindigkeit des Balls ändert sich wie folgt:

    von 0 bis 40 Fuß "ist die Bahn geölt, und der Ball rutscht und rotiert; Die Geschwindigkeit bleibt dabei annähernd gleich bei ca. 22 km/h. Nach 40 Fuß kommt der Ball in die "Gripzone" hier ist kein Rutsch mehr, nur Rotation, die aber durch den Grip zur Bahn eine höhere Geschwindigkeit bis 30km/h zur Folge hat. Aber: Innerhalb von 10 cm kann man Änderungen der Geschwindigkeit vernachlässigen, letztlich bekommt man ja eine Momentaufnahme an jeder Station, so das man auch die verschiedenen Geschwindigkeiten hinterher noch auswerten kann.

    Der Balldurchmesser ist genormt! max Abweichung D+0.2mm; das kann man getrost als konstant ansehen.

    Kabel sehe ich nicht als Problem Vss+, Gnd, Foto1, Foto2 also 4Adern Steuerleitung und nur 2 GPIO Eingänge.

    Alle Stationen über Widerstand parallel an eine Leitung. Der yPC braucht ja nur die Anzahl der Stationen wissen und immer nur jeweils die 3 Time speichern.

    Die Version mit 2 Laser auf 2 Fototransistoren pro Station gefällt mir am besten, weil hier die höchste Flexibilität herrscht.

    Einzig als Problem könnte hier tatsächlich die Auslesungsungenauigkeit in Time sein. letztendlich geht es in dieser Version um ySekunden. Das muß ich probieren.

    Spätestens Montag weiß ich mehr! und werde dann berichten.

    PS

    Noch nie war ein Forum so informativ und motivierend; und ich war schon in vielen Foren ( Nebenbei : ICH BIN 62! )

    Lefty

  • Erster Probeaufbau mit 2 Laser und erster Code dazu

    import RPi.GPIO as GPIO

    import time

    #GPIO Ports

    #parallel_start = 21 Pin 40

    #diagonal = 20 Pin 38

    #parallel_end = 16 Pin 36

    #Variabeln

    event1_time = 0

    event2_time = 0

    event3_time = 0

    Position = 0

    Geschwindigkeit = 0

    Ball_D = 2.3 #Nur hier im Test ein kleines Objekt 2.3cm Ball hat später 23cm

    #GPIO initialisierung

    GPIO.setmode(GPIO.BCM)

    GPIO.setup(21, GPIO.IN) # Pin 40

    GPIO.setup(20, GPIO.IN) # Pin 38

    GPIO.setup(16, GPIO.IN) # Pin 36

    # internen Pullup-Widerstand aktivieren.

    GPIO.setup(21, GPIO.IN, pull_up_down = GPIO.PUD_UP)

    GPIO.setup(20, GPIO.IN, pull_up_down = GPIO.PUD_UP)

    GPIO.setup(16, GPIO.IN, pull_up_down = GPIO.PUD_UP)

    # Callback für GPIO 21 event1

    def event1(channel):

    global event1_time

    event1_time = time.time()

    #print ("event1_time: ", event1_time)

    # Callback für GPIO 20 event2

    def event2(channel):

    global event2_time

    event2_time = time.time()

    #print ("event2_time: ", event2_time)

    # Callback für GPIO 16 event3

    def event3(channel):

    global event3_time

    global dif1_2

    global dif1_3

    event3_time = time.time()

    #print ("event3_time: ", event3_time)

    dif1_3 = event3_time - event1_time

    dif1_2 = event2_time - event1_time

    #print (" Dif 1_2 Position: ", dif1_2)

    #print (" Dif 1_3 für Tempo: ", dif1_3)

    Geschwindigkeit = Ball_D / dif1_3 * 0.36 #Ball incm

    Position = dif1_2 / dif1_3 * 1500 # Breite der Bahn

    print ("Geschwindigkeit: ", Geschwindigkeit)

    print ("Position: ", Position)

    # Interrupts aktivieren

    GPIO.add_event_detect(21, GPIO.RISING, callback = event1, bouncetime = 200)

    GPIO.add_event_detect(20, GPIO.RISING, callback = event2, bouncetime = 200)

    GPIO.add_event_detect(16, GPIO.FALLING, callback = event3, bouncetime = 200)


    try:

    while True:

    time.sleep(0.1)


    except KeyboardInterrupt:

    GPIO.cleanup()

    Funktioniert im Prinzip.

    Ob die Daten "vertrauenswürdig" / reproduzierbar sind kann ich noch nicht sagen, mein Versuchsaufbau ist dafür nicht stabil genug. Das werde ich dann am Wochenende optimieren. Wennn ich mir die Eventdaten von time ansehe, geht es jedenfalls um die 3te Stelle hinter dem Komma.

    Erste Results (von Hand simuliert, also nicht wirklich aussagefähig

    tempo: 46.189949219944936

    Position: 1117.6154122388177

    tempo: 48.163120930509926

    Position: 1099.7972449162146

    tempo: 46.021379017895

    Position: 1120.346689212111


    Lefty

    • Offizieller Beitrag

    Hallo Lefty,

    nur zwei kleine Anmerkungen...

    - Wenn Du im Editor oben auf </> klickst, dort dann Deinen Code einfügst und im besten Fall noch Python auswählst, dann ist dieser auch lesbar und die Einrückungen sollten stimmen. ;) Bitte editiere einfach Deinen Beitrag.

    - Und normale Variablen werden klein geschrieben, sonst fällt bei PEP die 8 um: ∞ :stumm:

    Ansonsten bin ich gespannt, was bei den Messungen heraus kommt.

  • Du brauchst nicht für jeden Pin eine Callback - die werden wenn dann eh nur nacheinander verarbeitet, es gibt also kein Vorteil durch mehrere Callbacks.

    "global" sollte man vermeiden. In der 3.Callback wäre das aktuell sowieso überflüssig.

    Die Variable-Namen irgendwie abzukürzen oder abzuhacken bringt nur Nachteile mit sich... Was erhoffst du dir dadurch?

    Orientiere dich an meinem Code, pack das in eine Queue mit dem jeweils ausgelösten Pin des Interrupts. In der while des Scripts fragst du die dann ab und verarbeitest die Messungen - das was du zZt in der 3.Callback stehen hast.

    ...normalerweise vermischt man auch nicht Deutsch mit Englisch, sondern benennt alle Variablen einheitlich in Englisch.

  • meigrafd

    Habe heute den ganzen Tag erst mit der Hardware, dann mit Software und Test verbraten und deine Post gerade erst gesehen. Danke

    Das Ergebnis ist allerdings eine Katastrophe und meine Matte hat Fehler,(lang ist es her) da muss ich nochmal nachdenken.

    Ich habe von PYTHON gar keine Ahnung : Mir ist klar dass ich Fehler, Unsauberkeiten, und auch Blödsinn code; sOWAS DAUERT HALT, YOU KNOW. iCH VERSUCHE MEIN bESTES.

    Jetzt bin ich erst mal deprimiert. Schranke Hardware aufgebaut mit 1875 mm Länge Abstand Laser 0 (Übereinander) Abstand Fotodioden 40mm.

    230mm Papier als Objekt genommen und dann durchgezogen.

    Einmal am Ende , direkt vor den Fotodioden (Hätte Position 1875 ergeben müssen),

    event1_time: 1519949935.7819922

    event2_time: 1519949935.8184428

    event3_time: 1519949935.914508

    tempo: 5.704975466524652

    Position: 2707.6812280951112

    dif1_2: 0.03645062446594238

    dif1_2_max rechnerisch 0.02524112519763765

    event1_time: 1519949938.065645

    event2_time: 1519949938.0899777

    event3_time: 1519949938.1678782

    tempo: 7.394860094636856

    Position: 2342.9344917291864

    dif1_2: 0.024332761764526367

    dif1_2_max rechnerisch 0.019472985040573848

    event1_time: 1519949940.5558481

    event2_time: 1519949940.5858757

    event3_time: 1519949940.671084

    tempo: 6.560460931778025

    Position: 2565.0401042550284

    dif1_2: 0.03002762794494629

    dif1_2_max rechnerisch 0.02194967724028088

    dann direkt vor den Laser hätte Position 0 ergeben müssen.

    event1_time: 1519951050.0492575

    event2_time: 1519951050.0551667

    event3_time: 1519951050.1002302

    tempo: 14.831468575036833

    Position: 1141.174226478636

    dif1_2: 0.0059092044830322266

    dif1_2_max rechnerisch 0.009709085736955916

    event1_time: 1519951052.3248727

    event2_time: 1519951052.3295388

    event3_time: 1519951052.3904083

    tempo: 11.53572455943771

    Position: 700.8688690536824

    dif1_2: 0.00466609001159668

    dif1_2_max rechnerisch 0.012482961018880209

    event1_time: 1519951054.3353531

    event2_time: 1519951054.3391092

    event3_time: 1519951054.4030309

    tempo: 11.170586392635832

    Position: 546.3182244126526

    dif1_2: 0.0037560462951660156

    dif1_2_max rechnerisch 0.012890997387114026

    event1_time: 1519951056.2042964

    event2_time: 1519951056.2077346

    event3_time: 1519951056.2592235

    tempo: 13.763695026933645

    Position: 616.1824054501022

    dif1_2: 0.003438234329223633

    dif1_2_max rechnerisch 0.010462306794666108


    Erst mal Schade, und überlegen woran es liegt.

    Zu schlechte Programmierung und dadurch zu ungenaue time.time() , oder grundsätzlich nix für RASPi ? Wir werden sehen.

    Werde mich aber trotzdem auch mit deinem Code beschäftigen !!! Die Mühe soll nicht umsonst sein. Danke.

  • Hallo Zusammen,

    würde sich als erster Test nicht soetwas wie im angehängten Bild anbieten.

    Mit GPIO26 schaltet man zu fest definierten Zeiten, simuliert also die Kugel.

    GPIO22 erfasst die Signaländerungen und löst die Interrupts aus. Anschließend überprüft man die Abweichungen von Soll zu Ist und kann sich so schon mal Gedanken machen ob man mit dieser Abweichung überhaupt leben kann oder ab die Messergebnis schon zu sehr verfälscht sind.

  • Du fragst drei GPIOs ab? Aber du doch nur zwei Laser? Müsste die fallende Flanke nicht am gleichen GPIO gemessen werden wie die erste steigende?

    Für den Aufbau wäre es besser, wenn die beiden Laserstrahlen in der gleichen Höhe sind und sich in der Mitte der Bahn kreuzen. Der Aufbau sollte so schmal wie möglich sein, wegen der Streuung der Laser. Da musst du mal checken, wie du die Elemente an der Bahn so nah wie möglich positionieren kannst.

    Ich weiß nicht, wie lange es dauert, vier globale Variablen zu initialisieren - aber wenn du so extrem kurze Zeiten misst, solltest du in der Callback-Funktion zuerst die Zeit messen und dann andere Dinge machen.

    Außerdem ist es nicht sinnvoll, in der 3. Callbackfunktion alle Berechnungen zu machen - die gehören ins Hauptprogramm.

    Meigrafds Queues sind hier empfehlenswert. In der Callbackfunktion wird nur die Zeit ermittelt und über die Queue ans Hauptprogramm gegeben. Dort kannst du dann alles Ereignisse in Ruhe auswerten.

    Grundsätzlich gehen die Zeiten doch schon in die richtige Richtung.

    Kannst du erstmal testen, wie genau der Pi die Messung macht? Dazu müsstest du ein sehr genaues Schaltsignal für die Laser haben und sie mit definierten Zeiten ein und aus schalten. Wer weiß, was da noch alles reinspielt. Trägheit der Photodioden, Kapazität des Signalweges oder so. Oder schlicht die Trägheit des Pi, wenn gerade mal eine Systemfunktion die interrupts gesperrt hat...

    Deshalb hab ich schon früher empfohlen, die Zeiterfassung mit einem Mikrocontroller zu machen. Ich glaube einfach nicht, dass der Pi das genau genug hin bekommt.

    Wenn du, wie Hoffei anregt, Testsignale generieren willst, wäre auch dafür wegen der Genauigkeit ein Mikrocontroller nicht schlecht. Ein Arduino Uno ist ja preiswert zu bekommen...

    Vielleicht kannst du auch ein Testobjekt mit halbwegs gleicher Geschwindigkeit durchsausen lassen. Ich denke da an ein Brett an möglichst langen Schnüren an der Decke aufgehängt. Wenn du es aus der immer gleichen Höhe loslässt, bekommt es wie ein Pendel immer die gleiche Geschwindigkeit. Die Bewegungen "per Hand" sind sicher nicht so richtig gleichförmig.

    Oh, man kann hier unliebsame Nutzer blockieren. Wie praktisch!

    Einmal editiert, zuletzt von Gnom (9. März 2018 um 23:12)

  • Hier ist ein interessanter Vergleich der Reaktionsgeschwindigkeit des Pi mit der eines Arduino. Die Ausreißer dürften bei deiner Aufgabe immer mal zu unsinnigen Ergebnissen führen. Und interessant ist auch, dass eine schlanke, Schleife schneller ist als die Interruptsteuerung. Bei hohen Ballgeschwindigkeiten (12,5 m/s) entspricht 1 mm Wegstrecke 80 µs. Da machen 80-270 µs Verzug die ganze Messung kaputt.

    Also, bei aller Eleganz der Interruptroutinen... versuchs mal testweise mit einer Schleife. Du kennst ja die Reihenfolge der Ereignisse (zumindest wenn sich die Laser nicht kreuzen) und kannst die Schleifen so anordnen, dass sie immer nur mit maximaler Geschwindigkeit auf das nächste relevante Ereignis warten.

    Um ein breiteres Wertespektrum zu bekommen, könntest du die Laser stärker anwinkeln. Doppelter Abstand heißt halber Messfehler. 80 mm (statt 40) entspricht 6400 µs = 6,4 ms (bei 12,5 m/s). Eine Fehlmessung von 16 µs entspricht dann 0,25% - bezogen auf die Breite von 1875 mm also ungefähr 5 mm.

    Oh, man kann hier unliebsame Nutzer blockieren. Wie praktisch!

  • Naja, der Programmablauf kann auch auf einem µC schlecht sein. Mehrere Interrupt Callbacks wirken sich negativ auf die Reaktionsgeschwindigkeit aus. Deshalb sollte er zumindest mal den Code aus Beitrag#28 ausprobiert haben um einen Vergleich zu sehen.

  • Zitat

    Wenn du, wie Hoffei anregt, Testsignale generieren willst, wäre auch dafür wegen der Genauigkeit ein Mikrocontroller nicht schlecht. Ein Arduino Uno ist ja preiswert zu bekommen...

    Vielleicht kannst du auch ein Testobjekt mit halbwegs gleicher Geschwindigkeit durchsausen lassen. Ich denke da an ein Brett an möglichst langen Schnüren an der Decke aufgehängt. Wenn du es aus der immer gleichen Höhe loslässt, bekommt es wie ein Pendel immer die gleiche Geschwindigkeit. Die Bewegungen "per Hand" sind sicher nicht so richtig gleichförm

    Habe heute erst mal ein stabileres Model aus Holz gebaut, weil der Justageaufwand genervt hat. Zum ermitteln der Reproduzierbarkeit denke ich einfacher. Ich werde einen regelbaren Motor nehmen mit 32cm geschlitzter Scheibe.

    So bekomme ich dann simuliert die gleichen Events wie sie später auftreten werden, und kann die Genauigkeit reproduzueren (Für Geschwindigkeit genauso wie Position). Noch habe ich nicht aufgegeben.

    Das mein Code nicht dem entspricht was ihr so machen würdet, ist mir bewußt; Meine Erfahrungen tendieren gegen null, und selbst das was ich bisher gecodet habe, verstehe ich nicht wirklich. TSCHULDIGUNG

    Zitat


    Du fragst drei GPIOs ab? Aber du doch nur zwei Laser? Müsste die fallende Flanke nicht am gleichen GPIO gemessen werden wie die erste steigende?

    Aber 3 events 2x rising 1x falling; Erst habe ich nur 2 GPIOs benutzt,

    Code
    GPIO.add_event_detect(21, GPIO.RISING, callback = event1, bouncetime = 400)
    GPIO.add_event_detect(20, GPIO.RISING, callback = event2, bouncetime = 400)  
    GPIO.add_event_detect(21, GPIO.FALLING, callback = event3, bouncetime = 400)

    Das war nicht gut, es wurden Events doppelt detectet.

    Nur eine callback habe ich noch garnicht kapiert. Ich muß doch unterscheiden können ????

    Und nebenbei, Das mit einer Schleife zu machen überfordert mich; vor allem weil letztlich die Values ja noch irgendwie in ein Array oder so abgelegt werden müssen. Bisher beschränke ich mich ja nur zum Test noch auf print("Event",Value)

    Softwaremäßig werde ich morgen erstmal den Code von Beitrag #28 probieren

    und Hardwaremäßig den Signalgeber bauen.

    Einen Aufbau mit Lasern die in der Mitte kreuzen behalte ich im Hinterkopf ! Könnte Sinn machen weil die Randbereiche deutlich wichtiger sind als die Mitte.

    Lefty

  • Weils mir keine Ruhe gelassen hat, habe ich das mal mit dem Code aus #28 von meigrafd 1:1 übernommen und getestet.

    Funktioniert auf Anhieb! Lediglich die Angaben für Position sind noch Quatsch; aber das ist ein rechnerischer Fehler denke ich (muß ich noch 2mal denken).

    folgend erste Resultate:

    je 3 Kugeln in etwa gleich schnell gerollt an der hintersten Position, dann 3x in der Mitte, dann 3x vorne.

    Geschwindigkeit: 34.48110685818807

    Position: -292.0520949401612

    Geschwindigkeit: 30.846687603834308

    Position: -295.3180266789009

    Geschwindigkeit: 28.807930615424567

    Position: -303.98304336535966

    Geschwindigkeit: 31.406978369709382

    Position: -201.54705908165042

    Geschwindigkeit: 13270.256076555024 #dicker Ausreisser

    Position: -2573594.210526316 #dicker Ausreisser

    Geschwindigkeit: 32.54135622055744

    Position: -205.00623317043983

    Geschwindigkeit: 34.10868196247531

    Position: -206.9345354762838

    Geschwindigkeit: 33.097153222173496

    Position: -99.84513399742835

    Geschwindigkeit: 32.658178001963506

    Position: -107.70851210705965

    Geschwindigkeit: 33.901470264224635

    Position: -98.44857222745962

    Quit

  • Eine Funktion pro GPIO reicht doch - mit Erkennung für beide Flanken. Die gibt dann halt zwei Zeiten zurück - eine für falling eine für rising Edge. Den Rest machst du ja im Hauptprogramm. Insgesamt hast du ja vier Ereignisse - zwei für jeden GPIO. Damit kannst du die Geschwindigkeit zweimal berechnen und Ausreißer aussortieren oder Durchschnitt bilden, wenn die Abweichung gering ist. Ebenso kannst du die Position zweimal bestimmen, einmal aus der Differenz der steigenden und einmal aus der Differenz der fallenden Flanken. Durch Mittelwerte kannst du vielleicht Messstreuungen vermindern.

    Nicht nur die Ausreißer sprechen nach wie vor mehr für einen Mikrocontroller - der ist hier einfach berechenbarer. Und wenns dann noch genauer werden muss, kann vielleicht jemand helfen, der sich in hardwarenaher Programmierung mit C oder sogar mit Assembler auskennt.

    Wie sieht eigentlich deine Schaltung genau aus? Welche Photodioden oder Phototransistoren benutzt du? Welche Widerstände? Vielleicht liegt da noch Verbesserungspotenzial.

    Oh, man kann hier unliebsame Nutzer blockieren. Wie praktisch!

  • Momentan benutze ich die 3.3Volt vom Raspi für die Dioden, Widerstand 10 KOhm Den Diodentyp kann ich leider nicht sagen (die lagen in meiner Wühlkiste) möglich das hier zusätzliche Probleme bei der Ansprechzeit dazu kommen.

    Habe in der Library gestöbert und folgendes gefunden:

    Zitat

    time.clock()

    On Unix, return the current processor time as a floating point number expressed in seconds. The precision, and in fact the very definition of the meaning of “processor time”, depends on that of the C function of the same name.

    On Windows, this function returns wall-clock seconds elapsed since the first call to this function, as a floating point number, based on the Win32 function QueryPerformanceCounter(). The resolution is typically better than one microsecond.

    Also habe ich im code

    #q.put( (time.time(), pin) )

    q.put( (time.clock(), pin) )

    geändert.

    Resultat 5x bei kurzer Distanz

    Geschwindigkeit in Km/h: 9904.306220095654

    Position: 100.11441647598132

    event1_time : 0.416908

    event2_time : 0.417183

    event3_time : 0.417744

    dif3_1 : 0.0008360000000000034

    dif2_1 : 0.0002750000000000252

    Geschwindigkeit in Km/h: 11728.045325779294

    Position: 149.1563000369353

    event1_time : 0.423567

    event2_time : 0.423913

    event3_time : 0.424273

    dif3_1 : 0.0007059999999999844

    dif2_1 : 0.00034599999999995745

    Geschwindigkeit in Km/h: 19078.341013822886

    Position: 139.55119214585125

    event1_time : 0.430206

    event2_time : 0.430405

    event3_time : 0.43064

    dif3_1 : 0.00043400000000004546

    dif2_1 : 0.00019900000000000473

    Geschwindigkeit in Km/h: 21395.348837207854

    Position: 137.6249859566096

    event1_time : 0.436917

    event2_time : 0.437092

    event3_time : 0.437304

    dif3_1 : 0.0003870000000000262

    dif2_1 : 0.00017499999999998073

    Geschwindigkeit in Km/h: 17922.07792207938

    Position: 150.19762845851417

    event1_time : 0.443039

    event2_time : 0.443267

    event3_time : 0.443501

    dif3_1 : 0.00046199999999996244

    dif2_1 : 0.00022800000000000598

    Resultat 5x bei langer Distanz

    Geschwindigkeit in Km/h: 12432.432432432435

    Position: 135.26570048307488

    event1_time : 0.449421

    event2_time : 0.449717

    event3_time : 0.450087

    dif3_1 : 0.0006659999999999999

    dif2_1 : 0.00029599999999996296

    Geschwindigkeit in Km/h: 12877.138413685752

    Position: 153.35722496452152

    event1_time : 0.455937

    event2_time : 0.456261

    event3_time : 0.45658

    dif3_1 : 0.0006430000000000047

    dif2_1 : 0.0003240000000000465

    Geschwindigkeit in Km/h: 15534.709193245613

    Position: 174.72877069909262

    event1_time : 0.462367

    event2_time : 0.462673

    event3_time : 0.4629

    dif3_1 : 0.0005330000000000057

    dif2_1 : 0.00030600000000002847

    Geschwindigkeit in Km/h: 12248.52071005899

    Position: 127.86210445073425

    event1_time : 0.463786

    event2_time : 0.46407

    event3_time : 0.464462

    dif3_1 : 0.0006760000000000099

    dif2_1 : 0.00028400000000000647

    Geschwindigkeit in Km/h: 13529.41176470585

    Position: 143.22250639386675

    event1_time : 0.470377

    event2_time : 0.470665

    event3_time : 0.470989

    dif3_1 : 0.0006120000000000014

    dif2_1 : 0.00028800000000001047

    Jetzt brauche ich erst mal wieder etwas Zeit um Hardware zu basteln ( Motor mit regelbaren Umdrehungen auf Scheibe mit 23cm Segment zur Simulation.

  • Warum der Wert für Geschwindigkeit jetzt so hoch ist ??? Das Problem sehe ich noch nicht.

    Hier der komplette momentane Code

    Lefty

  • Hoffentlich nerve ich nicht, aber jetzt mal ne blöde Frage (da werden noch mehr folgen denke ich )

    Bisher habe ich ja 3 Variabeln, die per print angezeigt werden.

    Code
    while running:
            time.sleep(1)
            if not queue.empty():
                interrupt_time, pin = queue.get()
                if pin == 21:
                    event1_time = interrupt_time
                elif pin == 20:
                    event2_time = interrupt_time
                elif pin == 16:
                    event3_time = interrupt_time

    Je nach Anzahl der Stationen entstehen diese 1 bis n mal hintereinander und sollen anschließend weiter verarbeitet werden.

    Also muss ich die Values sammeln. Ich erinnere mich schwach: Da war doch was mit ARRAYS; FINDE ICH IN python ABER KEINE SYNTAX für.gefunden habe ich : Code : daten_pro_durchgang = (durchgang, event1, event2, event3) bekomme also 4 Values hintereinander. Aber wie kriege ich die folgenden darunter um hinterher Alle Durchgänge auswerten zu können?? Das verstehe ich leider noch garnicht.

    Lefty

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!