Posts by Lefty

    War leider erkrankt, konnte mich daher nicht weiter mit der Hardware beschäftigen.

    Jetzt ist aber wieder alles gut.

    Leider ergab mein Test mit stabilem Funktionsgenerator-Rechteckimpulse eine Auslese Ungenauigkeit von 1 mS mit Ausreißern bis in den 100mS Bereich. Auchim minimalem System, also NUR 1 Event erfassen, in der Callback NUR time.time() lesen und printen. Keine Rechnungen, kein Schnickschnack. Ich vermute dieses Problem nicht in der Hardware des Raspy sondern mehr in Python ( in Kombination mit dem Betriebssystem). Ob ich das mit Arduino nochmal probiere weiß ich noch nicht...mal sehen.

    Alternativ lese ich mich gerade in opencv ein, um zu sehen ob eine Lösung per Objektverfolgung/Erkennung umsetzbar ist.

    Diesen THread werde ich daher schliessen.

    hyle   someone

    Langzeitbelichtung mit analoger Kamera (Polaroid um sofort das Bild zu bekommen) funktioniert, habe ich früher schon mal so gemacht; ist aber nicht der Hit.

    Programm in C mit Modul opencv auf Windows10 scheint mir sinnvoller (moderner)

    Lefty

    Stimmt, die Geometrie macht mir da auch etwas Sorgen 20 Meter lang 1 Meter breit ist verdammt nicht günstig. Ich kann die Kamera maximal in einer Höhe von 4 Meter anbringen, aber nur am Anfang der Bahn. Mit Handy oder normaler Digicam bekommt man schon ein nettes Video. Meine Casio FX100 Digicam macht bei einer Framerate von 210 FpS noch ganz passable Videos, bei 420 FpS reicht das normale Licht nicht aus; mit 1000 Watt Scheinwerfer geht es, aber das ist natürlich nix. 210 reicht grundsätzlich.

    Mit der DigiCam wäre es natürlich Quatsch das ganze auf einem Raspi zu versuchen, da ist ein schneller PC wohl die bessere Alternative.

    Meine Unkenntnis in Software- Programmierung - hier speziell Videobearbeitung _ sind der eigentliche Knackpunkt.

    Danke, Linusg, habe ich auch gelesen.

    Das Projekt kennst du schon aus dem Thread " Alle GPIO gleichzeitig lesen", wo du mir schon geholfen hast.



    ob CV oder was Anderes kann ich noch gar nichts zu sagen, das Ganze ist für mich erschreckendes Neuland, aber spannend.

    Nein Gnom !

    Da bin ich noch nicht weitergekommen. War von Sonntag bis heute bettlägerig (Magen-Darm)

    Vielleicht bin ich heute noch fit genug um den Test mit Funktionsgenerator zu machen.

    Wenn ich da Reproduzierbarkeiten von 10 yS bekomme, mache ich weiter.

    Die momentane Version mit Laser hat schon einiges meiner Resourcen aufgebraucht; bevor ich also neu anfange will ich erst grundsätzliche Meinungen einholen. Ganz trivial scheint mir das nämlich nicht zu sein.

    Mit Kamera wäre der mechanische Aufwand allerdings noch um ein vielfaches geringer, und die Zusätzlichen Informationen wie Rotation und Achsenwinkel (Rotationsachse und Axis-Tilt) wären das ( NON PLUS ULTRA)



    Lefty

    Bevor ich eine Kamera kaufe, scheint mir sinnvoll erst mal hier eure Meinung einzuholen, ob das angestrebte Projekt überhaupt lösbar ist.

    Projekt Beschreibung:

    Erfassung eines Objekt mit einer Geschwindigkeit zwischen 16 und 36 Km/h auf einer Strecke von ca. 20 Meter. dauert c. 2 Sekunden

    Genau gesagt geht es darum den Weg eines Bowlingball auf der Bahn grafisch darzustellen, wie in dieser Skizze

    Die Angaben an der Seite sind in Fuß (ca. 18 Meter bis Pin 1), Breite der Bahn ca. 1 Meter

    20 Meter in 2 Sekunden wären also alle 10mS ein Bild um eine Genauigkeit von 10cm zu erhalten. Als Video demnach eine Frame-Rate von 100 FpS.

    Die Auflösung braucht nicht besonders zu sein, Es geht nur um die Positionserkennung seitlich auf der Bahn alle 10cm.

    Also leere Bahn erfassen, Starten der Aufnahme bei Erkennung des Objekt (Ball) [alternativ könnte der Start auch per Lichtschranke auf GPIO ausgelöst werden).

    Alle 10 Milli- Sekunden ein Bild aufnehmen oder Video mit 100 FpS starten bis Ball in den Pins. (Ende der Aufnahme ebenfalls über Objekt Erkennung oder GPIO.

    Ersetzen des Objekt (Ball) durch einen Punkt und in der Grafik visualisieren. Punkte als Kurve verbinden.

    Ausgabe der Laufzeit zwischen definierten Bereichen z.B. Laufzeit 15 bis 30 Fuß, 30 bis 45 Fuß, 45 bis 60 Fuß.

    Abspeichern der Grafik

    fals das funktioniert knnt noch hinzukommen:

    Erkennung der Ballumdrehungszahl (z.B. durch 2 Aufkleber auf dem Ball und deren Auszählung


    Möglicherweise hat a schon mal Jemand ein ähnliches Projekt gesehen; könnte mir vorstellen Flugbahn visualisieren bei Darts, Bogenschiessen, Fußball usw.)


    Zur Zeit versuche ich das ganze per Hardware mit Laserlichtschranken zu lösen, die Eventerkennung auf den GPIO ist dafür aber bisher zu ungenau.


    Freue mich über jede Meinung dazu.


    Lefty

    Also erst mal grundsätzlich die Frage: schafft die Kamera+Raspy das ?

    Verstehe (halbwegs) bin kein Programmierer! daher der primitive Code.

    Danke, das kriege ich hin.


    Primär:

    Die Ungenauigkeit im Projekt scheinen auch mit den fotodioden zu tun haben; zumindest sind die Flanken per Oszi nicht sauber. Habe daher TYP: BPW43 bestellt, die nach Datenblatt 4ns schaffen sollen.


    Als zweites werde ich demnächst mal meinen Funktionsgenerator nehmen und ein Rechteck auf das GPIO legen.

    Danach weiß ich sicher die kleinste mögliche Reaktionszeit, die noch reproduzierbar ist.

    Den Versuch mit Motor habe ich gestern leider nicht mehr geschafft; schlafen muss auch sein.

    Bilder vom Versuchsaufbau

    Die Scheibe ist so Justiert das die Laser Aussen für 23cm unterbrochen werden: Ist also wie ein echter Ball.

    Das Loch in der Mitte ist lediglich als Unwucht-Ausgleich!

    ok, das sieht mir schon ganz gut aus. Danke

    [[1, [11, 21, 31]]]

    [[2, [12, 22, 32]]]

    [[3, [13, 23, 33]]]

    [[4, [14, 24, 34]]]

    [[5, [15, 25, 35]]]

    [[6, [16, 26, 36]]]

    [[7, [17, 27, 37]]]

    [[8, [18, 28, 38]]]

    [[9, [19, 29, 39]]]

    [[10, [20, 30, 40]]]

    [[11, [21, 31, 41]]]

    [[12, [22, 32, 42]]]

    [[13, [23, 33, 43]]]

    [[14, [24, 34, 44]]]

    [[15, [25, 35, 45]]]

    [[16, [26, 36, 46]]]

    [[17, [27, 37, 47]]]

    [[18, [28, 38, 48]]]

    [[19, [29, 39, 49]]]

    [[20, [30, 40, 50]]]

    Code
    1. daten_pro_durchgang = (durchgang, event1, event2, event3)

    Soweit war mir das schon klar, aber bei 20 Durchgängen erwarte ich 20x Daten für eventn1, event2, event3
    So wird aber nur jeweils der letzte Zyclus in "daten_pro_durchgang" abgelegt, die vorigen werden überschrieben. richtig?

    Ich muß aber NACH! der Datenerfassung auf alle event_daten zugreifen können, um diese auszuwerten.

    Das sehe ich so nicht.

    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
    1. while running:
    2. time.sleep(1)
    3. if not queue.empty():
    4. interrupt_time, pin = queue.get()
    5. if pin == 21:
    6. event1_time = interrupt_time
    7. elif pin == 20:
    8. event2_time = interrupt_time
    9. elif pin == 16:
    10. 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

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

    Hier der komplette momentane Code

    Lefty

    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:

    Quote

    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.

    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

    Quote

    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

    Quote


    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
    1. GPIO.add_event_detect(21, GPIO.RISING, callback = event1, bouncetime = 400)
    2. GPIO.add_event_detect(20, GPIO.RISING, callback = event2, bouncetime = 400)
    3. 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

    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.

    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

    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

    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

    Werde die erste Idee erst mal versuchen. Da dem Laser die Strecke ziemlich egal ist kann ich die Strecke an beiden Seiten der Bahn ca. 20cm überstehen lassen und den Abstand der Laser auf 5cm erhöhen. Dadurch wären die Events zeitlich weiter auseinander, was für den RASPi vielleicht reicht.

    Wenn ich einen Arduino Uno benutze hat dieser ja schon USB; dann brauch ich wahrscheinlich den RASPi garnicht und brauche ja nur die 2 Time pro Station dem PC senden und dort weiter verarbeiten.

    Alleine schon wegen der entfallenen Justage der Stationen auf der Bahn und dem baulichem Aufwand beim Herstellen/Einsetzen der Kontakte habe ich mich momentan in deine Laser-Idee verliebt.

    Aber auch deine zweite Idee mit den Widerständen ist mir vorstellbar zumal hier nur 1EIN analoger Eingang benötigt würde.

    Bleibt mir also als Version im Hinterkopf, falls Laser nicht funktioniert.

    Lefty

    Gnom

    2 mal denken ist immer gut. Dein 2ter Lösungsvorschlag mit 3 Laser auf 3 Fotozellen (pro Station) im Abstand von 1cm; Das Ganze als "Modul, so das keine Justage etc nötig ist, wäre praktikabel.

    Der Kostenaufwand ist sicher deutlich geringer, und auch die Fehleranfälligkeit (Kontakte) geht gegen 0.

    Also wäre dann im RASPi zu tun:
    Stationen = (Anzahl der Stationen)

    Schleife 1 bis Stationen

    3 GPIO als Event erkennen , nur die TIME 1>3 (für Geschwindigkeitsrechnung) und 1>2 (für Positionsrechnung) erfassen und im RAM speichern; 300 yS Zeit !! Du meinst der RASPi ist schnell genug dazu?

    Zusammenfassen der Daten (n Stationen x 2 TIME), Speichern in Datenbank aud USB-Stick, grafische Darstellung usw. kann danach erfolgen, das ist nicht zeitproblematisch.


    Auf Grund der deutlich geringeren Kosten und des geringeren Hardware-Aufwand werde ich die erste Idee in den Hinterkopf verschieben (nicht böse sein meigrafd) und eine Station zum Test bauen.

    Danke an Alle

    Lefty