Posts by Herr Kaiser

    Danke für deine Einschätzung, Jörg. Klingt nach ner Menge nötiger Rechenpower und auch nach viel Vorbereitungsaufwand. Mein Gedanke war, die jeweils letzte eindeutige Tonfolge einer Seite irgendwie einzuspeichern und den Raspberry darauf lauschen zu lassen, wann sie gespielt wird. Dann wäre auch zwischenzeitliches Falschspielen kein Problem - sofern es nicht am Seitenende erfolgt. Inzwischen bin ich aber selber etwas skeptisch geworden, denn die Tonfolge kann ja rasant sein und ein Klang gleichzeitg aus mehrern Tönen bestehen. Es gibt für diese Art der Mustererfassung und -analyse vermutlich noch keine fertigen Libraries, nehme ich an, oder kennt jemand da etwas? Soetwas vollständig selbst zu erstellen ist für einen Mann meiner Voraussetzungen vermutlich dann doch noch etwas größenwahnsinnig. ;-)


    Hab überlegt, ob die manuelle Weiterschaltung vielleicht doch der ökonomischere Weg ist. Aber dann vielleicht eine Variante, für die man weder Hände noch Füße benötigt, weil man die beim Klaverspielen ja anderweitig gut gebrauchen kann. Vielleicht eine Gestenerkennung per Kamera? Kopfnicken oder so? Hättet Ihr noch Ideen? Je simpler desto besser wäre es natürlich. Hier kriegt man ja oft Anregungen, auf die man selber nicht kommt. :-)

    Hallo Forum,

    meine Liebste spielt Klavier. Gerade beim Einüben neuer Stücke stört das Umblättern des Notenbuchs den Spielfluss, so dass die Umstellung vom Printbuch auf PDF-Noten per Bildschirm oder Tablet naheliegt. Bluetooth-Fußschalter zum "Umblättern" gibt es. Die sind zwar unangemessen teuer, aber glücklicherweise gibt es auch eine geniale DIY-Lösung:

    https://www.youtube.com/watch?v=mHP332XDJlg

    Das wäre schon einmal eine Verbesserung. Aber als Raspberryianer überlegt man bei sowas natürlich immer, ob es noch besser geht. Wäre es nicht super, wenn ein Raspberry automatisch anhand der gespielten Töne erkennt, wann es Zeit zum Umblättern ist, und ein entsprechendes Signal generiert? Wäre eine derartige akustische Mustererkennung per Raspberry denk- und machbar? Was meint Ihr?

    Ach so.

    Sind die Karts optisch von außen zu unterscheiden? Dann könnte man an der Ziellinie eine "Überwachungs"-Kamera anbringen, die per Bilderkennung feststellen, zählen und melden kann, wann ein Wagen durchs Bild fährt. Schwierigkeit dabei: Die Kamera muss so angebracht sein, dass auch nebeneinanderfahrende Karts gesehen werden. Also von schräg oder am besten direkt senkrecht von oben aufnehmen. Und die Karts müssten dann in der Ansicht optisch deutlich unterscheidbar sein. Der Raspberry kann erwiesenermaßen feststellen, ob eine Katze durchs Bild läuft. Ob das auch mit mehreren Objekten in Kartgeschwindigkeit funktioniert: keine Ahnung. Also erstmal nur so theoretisch als zu überlegende Möglichkeit genannt.

    Wenn es kein Bastelprojekt und keine Armaturenanzeige sein muss, würde ich einfach eine Sportuhr mit GPS-Funktion nehmen. Die ist vermutlich robuster und weniger störanfällig als eine Umsetzung mit Raspberry. Außerdem muss die Rundenzahl nicht durch LED-Leuchtmuster dekodiert werden, sondern wird direkt angezeigt inkl. zurückgelegter Distanz und Geschwindigkeit.

    Hm, dass mit der genauen Rundenerfassung erscheint mir im Moment gar nicht so trivial zu sein. Ich nehme an, es sind mehrere Karts unterwegs und es fahren u. U. mehrere zeitnah über die Rundenlinie? Ist das in einer Halle oder open Air?



    Edit: oh, du schriebst ja oben, dass es unter freiem Himmel ist. Meine Gedanken gingen in Richtung GPS, hab aber keine Erfahrung, ob der Raspberry das zuverlässig packt.

    Hallo Linuxer,

    eine "offizielle" Anleitung kenne ich nicht, hab das so zusammengebastelt, wie mir das in den Sinn gekommen ist. Grundlage sind folgende Passepartoutkartons:

    https://www.ebay.de/itm/10-Stu…626a75:g:tasAAOSwgkRVTG87

    Von denen klebe ich für jede Wand zwei aufeinander, dabei den inneren an jeder Seite 1,5mm kürzer, so dass eine stufige Kante entsteht. Die Wände werden zuerst mit etwas Alleskleber an den Kanten verbunden. Anschließend verstärke ich die Kanten mit Nassklebeband (Papier, dass man wie eine Briefmarke anfeuchtet, gibt es auf Rollen - glaube ich - im Künstlerbedarf). Das lässt sich leicht verarbeiten und gibt nach dem Trocknen gute Stabilität. Hinterher kommt gewöhnliche d-c-fix-Klebefolie in gewünschter Farbe darüber. Damit erreicht man für ein Pappgehäuse eigentlich eine recht erstaunliche Stabilität. Die Front mit Beschriftungen drucke ich einfach aus und laminiere sie und klebe sie dann auf die Vorderseite auf.

    Unten klebe ich kleine Gummifüße auf. Das sieht besser aus, wenn das Gehäuse nicht flach auf der Oberfläche aufliegt, gibt einen gewissen Rutschschutz und schont das Gehäuse. Wenn ich Gehäuse mit einer Art "Verschlussklappe" baue, bringe ich selbstklebende Neodym-Scheibenmagnete an (die dünnsten, die man finden kann), damit die Klappe selbständig "zuschnappt.".
    Wichtigstes Werkzeug: eine Hebelschneidemaschine. Ohne die wird man beim Pappgehäusebaus nicht glücklich. Außerdem hilfreich: Skalpell, ggf. Kreisschneider und Dremel für entsprechende Aussparungen/Löcher.


    Hallo Alex,

    danke für dein Interesse. Aktuell habe ich keine Version, die ich weitergeben könnte. Da ich inzwischen aber mehrfach per PN danach gefragt wurde, steht es auf meiner To-Do-Liste, meinen Code zu veröffentlichen. Wenn die aktuelle Zeitnot nicht wäre. Irgendwann demnächst werde ich entweder hier ein Image posten oder einen Link auf das (noch zu erstellenden) GitHub-Projekt. Kann noch nicht abschätzen wann, aber ich werde mich darum kümmern.

    Möchte mich mal an die Umsetzung der obigen Anleitung begeben. Da es aber ja doch ein bisschen Arbeit ist vorweg noch einmal eine Frage: Wenn ich zwei Zeros verbinde und einen der beiden wie beschrieben als virtuellen Datenträger konfiguriere, können dann beide Zeros auf diesen (bzw. auf das Filesystem innerhalb der genannten Image-Datei) gleichberechtigt schreibend und lesend zugreifen? Hat das schon mal jemand probiert?

    Super! Kannte ich noch nicht. Wie verwendet man die? Ich vermute, man steckt sie einfach zwischen Stecker- und Buchsenleiste und hat die beiden verbleibenden Lochreien für Lötkontakte zur Verfügung?


    Edit: Ups, man sieht auf den Bildern ja genau die Verwendung. Frage beantwortet! ::)

    Hallo Forum,

    ich möchte gern am Raspberry Zero, auf dessen Stiftleiste ein Display angeflanscht ist, die vom Display noch nicht verwendeten GPIO-Pins nutzen. Ich denke, dafür braucht man eine Stiftleiste, die von beiden Seiten - der Raspberry-Oberseite und -Unterseite - zugänglich ist. In meinem Fall wäre eine abgewinkelte Leiste recht praktisch. Meine Frage: An einer Seite müssen die Pins ja mit dem Zero verlötet werden und ich frage mich, ob dann Stecker an dieser Seite überhaupt noch ausreichend halten. Ich stelle mir die Verbindung dann etwas wackelig vor. Hat jemand von euch schon einmal einen zweiseitigen Zugriff auf die Pins ausprobiert und kann von Erfahrungen berichten? Oder von anderen Ideen, wie man an die Pins kommt, wenn ein Display aufgesteckt ist? Vielen Dank schonmal!

    Hey linusg,

    du hast in allem recht! :thumbup::thumbup::thumbup:

    Ein dilettantischer Syntaxfehler. Hatte es zunächst bei Verwendung der konkreten Werte richtig gemacht und nicht bemerkt, dass ich anschließend das "=" verschluckt habe. Danke, dass Ihr euch alle Gedanken gemacht habt. Und Tschuldigung für meine Dämlichkeit. :blush:

    Hallo Experten,

    habt Ihr eine Idee, was hier schief läuft:



    Der Code steigt mit der camera.zoom(...)-Anweisung und der Meldung 'tuple' object is not callable aus. Wenn ich statt der eingefügten Variablen konkrete Zahlen als Argumente in die Klammer setze:  camera.zoom(0.25, 0.25, 0.5, 0.5) funktioniert es. :conf:


    Die picamera-API sagt zur zoom-Anweisung:


    "Retrieves or sets the zoom applied to the camera’s input.

    When queried, the zoom property returns a (x, y, w, h) tuple of floating point values ranging from 0.0 to 1.0, indicating the proportion of the image to include in the output (this is also known as the “Region of Interest” or ROI). The default value is (0.0, 0.0, 1.0, 1.0)which indicates that everything should be included. The property can be set while recordings or previews are in progress."

    Hallo Forum,

    ich teste gerade die Raspberry Kamera Version 2.1. Dafür verwende ich die Python-Schnittstelle picamera. Ich nehme keine Veränderung der Default-Einstellungen vor und stelle fest, dass der automatische Weißabgleich bei Anzeige des Preview-Bildes (camera.start_preview()) überzeugende Ergebnisse liefert, die mit den Grundeinstellungen geschossenen Bilder (camera.capture('image1.jpg') unter identischen Lichtverhältnissen aber völlig grünstichig sind. Ich kriege durch keine Weißabgleichs-Einstellung das Ergebnis des Preview-Bildes hin. Wenn ich einfach den Konsolenbefehl raspistill -o image1.jpg anwende, sind die Farben wieder stimmig. Hat jemand von euch diese Erfahrung auch schon gemacht? Haben wir hier einen picamera-Bug oder sitzt das eigentliche Problem gerade wieder einmal an der Tastatur ;)

    Hey, ich wusste, dass ich mit meiner Behauptung hier nicht durchkomme (;

    Ganz herzlichen Dank für eure Mühe! :thumbup:

    Das Problem ist, dass ich einen Drucktaster mit Einbaugewinde benötige. Damit fallen die Wipp-, Kipp- und Printmontage-Exemplare weg (aber das konntet Ihr ja nicht wissen).

    Die günstigste passendere Variante, die ich bisher gefunden habe, sieht so aus:

    https://www.reichelt.de/?ARTIC…3QbQAHEAQYBSABEgIFZvD_BwE

    Bei einer Einzelbestellung sind nur solche Versandkosten zu schmerzhaft. Aber vielleicht finde ich ja noch günstigere Modelle oder Versandbedingungen. Eure Beispiele zeigen ja, dass solche Taster nicht per se teuer sein müssen ...

    Huch, diese 2x-EIN-Dinger sind ja gar nicht mal so preiswert. Bei denen, die ich gefunden habe und die von der Bauart passen würden, zahlt man inklusive Versand mehr als für zwei Zeros. :conf:

    Hab stattdessen jetzt ein kleines 2-Kanal-Relais für 2,40 € aufgetan und werde es mal damit versuchen (in der Hoffnung, dass der zusätzliche Stromverbrauch zu verschmerzen ist).