Hallo, ich bin Schüler und habe für den Physik Unterricht ein kleines Projekt umgesetzt. Wir behandeln das Thema Dynamik, aktuell den freien Fall mit Luftwiderstand. Um da die verschiedenen Einwirkungen von Masse, Fläche usw. zu zeigen, habe ich einen Ultraschallsensor (HC-SR04) mit dem Raspi 2 nach oben gerichtet und verschiedene Objekte darauf fallen gelassen. Im Anhang findet ihr meinen Python (dummerweise Python 2) Code und erste Messergebnisse. Kleine Anmerkung zum Programm: Gnuplot plottet direkt die csv. Datei als Zeit-Weg-Diagramm. Das funktioniert auch alles, allerdings sind die gemessenen Werte zu ungenau bzw. es werden zu wenig Messungen währen dem Fall gemacht. Jetzt zu der eig. Frage: 1. Gibt es einen besseren Sensor für diesen Anwendungszweck? 2. oder kann man evtl. das Programm noch tunen? Bitte entschuldigt, falls ich mich teils unklar ausgedrückt habe oder der Code nicht so gut ist. Ich bin noch am Lernen;) Bei Rückfragen daher bitte melden - ich freue mich über jeden Tipp!
JanTec schrieb: > HC-SR04 Kurz gesucht, das soll Modul soll auf maximal 50 Messungen pro Sekunde kommen. Wenn 2m Freifall 0,6 Sekunden dauern, könntest du in der Zeit 30 Datenpunkte gewinnen. Ob du realistisch auf 30 brauchbare Messungen kommst wäre auch noch zu klären. Aber selbst unter Idealbedingungen finde ich das etwas wenig?
> 1. Gibt es einen besseren Sensor für diesen Anwendungszweck?
Eine Lichschranke alle x cm fiele mir da ein. Zur Auswertung brauchts
dann allerdings etwas mehr Echtzeitfähigkeit fürchte ich.
JanTec schrieb: > und erste Messergebnisse. Ein simpler Screenshot im PNG-Format hätte es auch getan, dann könnte ich die Daten mit dem Handy auch ansehen... JanTec schrieb: > Jetzt zu der eig. Frage: > 1. Gibt es einen besseren Sensor für diesen Anwendungszweck? Wir lösen solche Probleme immer mit einer Hochgeschwindigkeitskamera. Die kann 2000 Bilder pro Sekunde machen. Ist aber nicht ganz billig. Aber die hier kann für kleines Geld schon mal 90 Bilder/s: http://www.netzmafia.de/skripten/hardware/RasPi/kamera/index.html Und die hat den Vorteil, dass sie das Timing von sich aus mitbringt, denn JanTec schrieb: > Raspi 2 ... Python Das mit der Echtzeitfähigkeit sehe ich hier auch recht spannend. Hast du mal gemessen, wie zuverlässig du da z.B. ein 100Hz-Signal einlesen kannst. Wieviel Jitter hat dein System?
so, bin jetzt auch registriert. Sorry wegen der Tabelle. Ich habe tatsächlich so eine Pi Cam. Ist eigentlich eine super Idee, die ich gar nicht auf dem Schirm hatte. Werde mir das mal genauer anschauen. Lothar M. schrieb: > Das mit der Echtzeitfähigkeit sehe ich hier auch recht spannend. Hast du > mal gemessen, wie zuverlässig du da z.B. ein 100Hz-Signal einlesen > kannst. Wieviel Jitter hat dein System? Weiß nicht genau ob ich das richtig verstehe. Ich bin da auf eine Messfrequenz von ca. 50Hz gekommen, ohne wirklich große Latenz.
...mögliche Alternative: Ein Foto mit langer Belichtungszeit. Die Beleuchtung erfolgt mit kurzen wiederholten Lichtblitzen (Stroboskop) und bildet das fallende Objekt mehrfach - in konstanten Zeitabständen auf einem Bild ab. Wahrscheinlich lässt sich das preiswerter realisieren als eine Hochgeschwindigkeitskamera.
Jan W. schrieb: > Weiß nicht genau ob ich das richtig verstehe. Ich bin da auf eine > Messfrequenz von ca. 50Hz gekommen, ohne wirklich große Latenz. Das Problem ist das: du hast einen Hardwaretimer, der tatsächlich mit 10ms Abstand einen Interrupt auslöst:
1 | timer 0 10ms 20ms 30ms 40ms .... |
2 | überlauf | | | | | |
Normalerweise wird diese Interruptanforderung auch recht zügig bearbeitet:
1 | timer 0 10ms 20ms 30ms 40ms .... |
2 | überlauf | | | | | |
3 | interruptbearb. # # # # # |
Bis dann das Betriebssystem kommt und noch "wichtigere Dinge" zu tun hat oder fertig machen muss (einfach mal im Hintergrund Dateien kopieren, Netzwerktraffic aufbauen oder zufällig den USB-Stick einstecken). Dann wird auf einmal dein Code mit 5ms Verzögerung bearbeitet. Weil der nächste Timerüberlauf wieder pünktlich kommt und der Interrupt wieder schnell bearbeitet wird, "stolpert" dein Timing:
1 | timer 0 10ms 20ms 30ms 40ms .... |
2 | überlauf | | | | | |
3 | interruptbearb. # # # # # |
Nun bist du aber bei deinem Messungen von gleichen 10ms Zeitabständen ausgegangen und hast aus den 10ms Zeitabständen und dem Abstandsdifferenzen die aktuelle Geschwindigkeit ausgerechnet. Klar ist das Objekt aber in den realen 15ms und 5ms weiter oder weniger weit gefallen und du bekommst dadurch Schwankungen in der Kennlinie. Probiere das einfach mal aus: toggle aus deinem Programm mit 100Hz einen EA-Pin. Schließe an diesen Pin ein digitales Oszilloskop an. Und jetzt zeige einen vollen Impulszyklus auf dem Oszilloskop an und stelle die Nachleuchtzeit auf "unendlich". Im Idealfall sollte das am nächsten Morgen so aussehen:
1 | Trigger |
2 | V |
3 | |
4 | .----------------. .-------------- |
5 | | | | |
6 | | | | |
7 | | | | |
8 | | | | |
9 | -------' '----------------' |
Wenn dabei dann einmal der oben beschriebene Fehler aufgetreten ist, sieht es z.B. so aus:
1 | Trigger |
2 | V |
3 | |
4 | .----------------. .-------.------ |
5 | | | | | |
6 | | | | | |
7 | | | | | |
8 | | | | | |
9 | -------' '---------'-------' |
Was du aber vermutlich sehen wirst, ist so etwas:
1 | Trigger |
2 | V |
3 | |
4 | .------------......... .........------------ |
5 | | ||||||||| ||||||||| |
6 | | ||||||||| ||||||||| |
7 | | ||||||||| ||||||||| |
8 | -------' '''''''''---------''''''''' |
Das zeugt dann davon, dass ständig solche "Ungenauigkeiten" aka. Jitter auftreten. Dann gilt es abzuschätzen, inwiefern das für die Erfassung und die zuverlässigkeit der Messwerte schlecht ist. Und im schlimmsten Fall passiert es, dass die Linien oben und/oder unten ganz durchgehen:
1 | Trigger |
2 | V |
3 | |
4 | .------------.........---------.........------------ |
5 | | ||||||||| ||||||||| |
6 | | ||||||||| ||||||||| |
7 | | ||||||||| ||||||||| |
8 | -------' '''''''''---------''''''''' |
Dann ist der Interrupt während eines kompletten Zimerzyklus nicht bearbeitet worden und ging "verloren". Das "Übersehen" von Interruptanforderungen kann in den allermeisten Fällen nicht toleriert werden. War jetzt viel Text, ist aber auch kein ganz einfaches Thema. Es bedeutet lediglich: du musst dein System und seine Grenzen kennen, vor du ihm über den Weg traust und den gemessenen Werten glaubst.
Man könnte natürlich auch einfach größere Messreihen machen. Jeder Gegenstand wird aus unterschiedlichen Höhen fallengelassen. Ab diesem Zeitpunkt läuft ein Timer, der gestoppt wird wenn der Gegenstand auf ein Blech oder Karton fällt. Als Sensor dient ein Mikro. Einzig sehr leichte Objekte, die keinen lauten Aufprall erzeugen müsste man "von Hand" stoppen.
Lothar M. schrieb: > War jetzt viel Text, ist aber auch kein ganz einfaches Thema Da erhebt sich die Frage, ob man die Messreihe selbst nicht einem einfachen System wie Arduino überlassen sollte, das von vornherein keine Probleme mit einem zuverlässigen Echtzeit-Ablauf hat. Georg
Um den Jahrtausendwechsel herum gab es an einzelnen Gymnasien die "VideoCom", eine einzeilige CCD-Kamera, mit der man recht bequem die gängigen Versuche in Mechanik unter die Lupe nehmen konnte: - https://www.ld-didactic.com/software/vc-exp-d.pdf Seitdem bietet der Hersteller wohl ein Nachfolgeprodukt an. Mich hat damals das Konzept zufriedengestellt: berührungslose Messung mit der nötigen Genauigkeit und Präzision. Mein Vorschlag wäre daher anstelle eines Sensors einfach ein Kamerabild – wie Lothar es oben bereits angeregt hat. Das VideoCom-System konnte 80 Messungen pro Sekunde aufnehmen – von max. zwei Markierungen auf dem zu beobachtenden Objekt, wenn ich mich richtig erinnere, mit retroflektierender Folie markiert. Eventuell bleibt dann noch die Frage der Verschlusszeit zu klären: kann obige Raspberry-Pi-Kamera bei 90 Bildern/Sekunde bewegte Objekte ausreichend scharf genug aufnehmen? Wobei man vermutlich in dem Fall – kontrastreiche Markierung vorausgesetzt – bei gleichförmigen Bewegungen auch den Start-/Endpunkt dieser Markierung nehmen kann.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.