Projekt Filmscanner mit Raspi & Pico

[Klaus14]

Ich möchte mich hier kurz vorstellen. Mein Name ist Klaus, ich wohne in Wien, werde in Kürze 64, bin jetzt endlich in Pension und habe nun die Zeit mich meinen Hobbies zu widmen. Auch ich möchte mir einen Filmscanner bauen und habe mit Jahreswechsel mit meinen Experimenten begonnen. Angespornt von Friedemanns "Challenge: Framescanner für < 350€ bauen" möchte ich auch einen kleinen Beitrag leisten und meine bisherigen Ergebnisse vorstellen.

 

Mein Projekt ist noch nicht so weit fortgeschritten wie das von Friedemann und ich habe mir auch nicht das Ziel gesetzt mit 350 Euronen das Auslangen zu finden, mir geht es eher um das Ausloten der Möglichkeiten mit den heutigen Mitteln, wobei mein Augenmerkt besonders auf die HQ Kamera, den Raspi 4/5 und dem kleinen Rechenzwerg Pico gerichtet ist.

 

Leider bin ich erst vor wenigen Tagen über das Projekt von Friedemann gestolpert und ich finde es fantastisch, was er da bereits geleistet hat und ich kann sehr viel daraus lernen. So werde ich wohl das Licht und das Objektiv übernehmen, denn damit kenne ich mich viel zu wenig aus und könnte es wohl kaum besser machen. Unsere Ansätze sind ja sehr ähnlich (ok so viele Möglichkeiten das Problem zu lösen gibt es ja wohl nicht) trotzdem möchte ich jetzt meine bisherigen Erfahrungen hier zeigen. Vielleich wird ja die eine oder andere Idee aufgegriffen.

 

 

Das ist eine Übersicht meines aktuellen Aufbaues. Der Projektor ist ein ganz einfacher Bauer Visalux, den habe ich geschenkt bekommen und er reicht für meine ersten Experimente vollkommen aus. Im Endausbau werde ich aber einen deutlich besseren Projektor nutzen, in meinem Keller steht eine größere Sammlung an diversen Geräten die ich in den letzten Jahren günstig erstanden habe.

 

Links ist ein Raspberry Pi 4 zu sehen auf ihm läuft die komplette Software geschrieben in Python und als GUI nutze ich derzeit PyQt5. In der ersten Version hat der Raspi auch die Steuerung des Motors und die Auswertung der Lichtschranke übernommen, dafür gab es die Library Pigpio, mit der man die IO-Ports sehr gut ansteuern konnte, doch wie das nun mal so ist wollte ich dann auf den Raspi 5 umsteigen, weil der doch deutlich mehr Power hat und auch kaum mehr kostet und ich musste mit Entsetzen feststellen, dass dort die IO-Ports intern ganz anders angesprochen werden und diese Library leider nicht funktioniert. Es musste also eine andere Lösung her ...

 

 

... und so kam ich eben auf den kleinen Rechnzwerg Pico, der ebenfalls von der Raspberry Foundation stammt. Da ich sehr experimentierfreudig bin wollte ich mir das Ding ohnehin schon genauer ansehen und das war nun die perfekte Anwendung dafür. Jetzt hat der Pico die Ansteuerung des Motors übernommen, wertet auch die Lichtschranke aus und kommuniziert mit dem Raspi via Serielle Schnittstelle UART. Was mich dabei echt fasziniert ist die Tatsache, dass der Code im Pico derzeit ebenfalls in Micro Python programmiert ist und das hätte ich nun wahrlich nicht erwartet, dass der kleine Zwerg das schafft.

 

Das war's erst mal, weitere Details folgen

Bearbeitet 2. März von Klaus14 (Änderungen anzeigen)

[AndreasH]

Hallo Klaus,

 

sehr spannend - ich freue mich schon auf weitere Folgen dieser  Serie im Forum.

Willkommen bei den Filmvorführern!

 

Viele Grüße,

Andreas

Bearbeitet 2. März von AndreasH (Änderungen anzeigen)

[Klaus14]

Nach dem ersten groben Überblick erst mal, speziell für dich Friedemann, ein wenig über den Pico

 

Bei dem Angebot das es heute an Micro-Controllern gibt, hat es mich doch sehr erstaunt, dass die Raspberry Foundation einen eigenen Controller auf den Markt gebracht hat. Die Sinnhaftigkeit hat sich mir zuerst nicht so ganz erschlossen, doch nach meinem ersten Test, hat mich doch die Neugierde gepackt und die wahre Stärke scheint, wie ja schon beim Raspbberry Pi, in der gewaltigen Coummunity zu liegen. Im Netz ist eine wahre Flut an Beschreibungen und Beispielen zu finden, wie kaum für einen anderen Controller (ok vom Arduino mal abgesehen aber der ist für heutige Verhältnisse doch schon etwas betagt).

 

https://www.raspberrypi.com/products/raspberry-pi-pico/

Den Zwerg gibt es in zwei Varianten, wobei ich im Moment den Kleineren ohne WiFi nutze Pico BerryBase und beim heutigen Wocheneinkauf habe ich für Brot mehr Geld ausgegeben als so ein kleiner Pico kostet, denn der ist ab ca. 4 Euro zu haben. Der Controller hat doch deutlich mehr Power wie ein übliches Arduino Board und man kann ihn auf mehrere Arten programmieren. Die einfachste Variante ist zweifelsohne Micro Python, ich nutze dafür am PC die Thonny IDE https://thonny.org/ einfacher geht es nicht und ich bin nach meinen ersten Experimenten doch erstaunt, wie weit man mit Micro Python kommt. Sogar auf Interrupts kann man direkt in Python reagieren. Bin jetzt sehr gespannt wann das Ende der Fahnenstange erreicht ist, denn irgendwann wird wohl doch der Speicher ausgehen. Natürlich kann man den Pico in der Zwischenzeit auch in der Arduino Umgebung in C/C++ programmieren. Entweder in der original Arduino IDE oder mit Visual Studio Code, aber mit dieser Methode ist man natürlich auf das beschränkt, was in dieser Arduino Umgebung zur Verfügung gestellt wird. Und dann gibt es noch die "Hard Core" Variante, die Nutzung des hauseigenen SDK der Raspberry Foundation. Ich gebe aber zu, das ist dann nichts mehr für Einsteiger, da braucht man dann schon etwas mehr Know How, kann dafür aber den Pico bis ins letzte Detail ausreizen und in der Zwischenzeit gibt es auch ein kleines Programmiergerät mit dem man sogar Debuggen kann.

 

https://www.berrybase.at/raspberry-pi-debug-probe

 

 

Es gibt beim Pico auch noch eine Version mit WLAN und Bluetooth https://www.berrybase.at/raspberry-pi-pico-w-rp2040-wlan-mikrocontroller-board wäre eine Überlegung wert um sich das Kabel zwischen Pico und Raspberry zu sparen ... werde ich vielleicht später mal testen.

 

Die technischen Daten sind ja für heutige Verhältnisse nichts Besonderes

• Dual-core Arm Cortex-M0+ processor, flexible clock running up to 133 MHz
• 264kB on-chip SRAM
• 2 × UART, 2 × SPI controllers, 2 × I2C controllers, 16 × PWM channels
• 1 × USB 1.1 controller and PHY, with host and device support
• 8 × Programmable I/O (PIO) state machines for custom peripheral support
• Operating temperature -40°C to +85°C
• Drag-and-drop programming using mass storage over USB
• Low-power sleep and dormant modes
• Temperature sensor
• Accelerated integer and floating-point libraries on-chip

da gibt es deutlich "flottere" Controller aus der Cortex Serie, aber dennoch haben sich die Raspberry Entwickler etwas ganz Besonderes einfallen lassen und haben dem Ding 8 × Programmable I/O (PIO) state machines for custom peripheral support verpasst und was man mit denen alles anstellen kann ist unglaublich. Das ist aber zugegeben nichts mehr für Einsteiger, das zu behirnen (mir ist es noch nicht so recht gelungen) bedarf schon "etwas mehr" Einarbeitungszeit, ist aber auch unter Micro Python möglich!

 

Endlos mehr Informationen gibt es auf der entsprechenden Raspberry Pi Seite

 

https://www.raspberrypi.com/documentation/microcontrollers/

 

 

 

 

[Friedemann Wachsmuth]

Ja, der Pico ist ne schöne Brücke zu den größeren Arms (STM32 und so). Ich kenne ihn schon recht gut, hab schon einiges mit dem gemacht, auch state machines per PIO. Sehr feine Sache. 
 

Ich finde aber keineswegs, dass der die 8-Bit AVRs einfach ersetzen sollte, nur weil er neuer ist. Ich bin bei EE ein Freund der Philosophie, das zu nehmen, was wirklich benötigt wird — überflüssiges bringt nur unliebsame Überraschungen. Der 328P (oder 168P) kommt beim Scannen mitnichten an irgendwelche Grenzen, reicht also vollkommen. (Im Grunde hätten die GPIO des Raspi allein wohl auch zum Steuern gereicht, mit ist der Raspi aber für sowas zu zickig, zu kompliziert, und Linux zu wenig RTOS.)

 

Viele Wege führen zum Ziel. 🙂

Bearbeitet 2. März von Friedemann Wachsmuth (Änderungen anzeigen)

[Klaus14]

Der Antrieb

Da ich aus der Welt der EUMIG Projektoren komme (meine Großmutter hat damals bei EUMIG gearbeitet und mir meine erste Kamera & Projektor geschenkt) und diese Geräte damals mit Wechselstrom-Synchronmotoren angetrieben wurden, ist es mir nicht in den Sinn gekommen, dass es auch andere Geräte gibt. Erst in den letzten Jahren, wo ich auch Bauer, Yelco, ELMO und diverse andere Projektoren genauer angeschaut habe, wurde mir klar, dass es ohnehin viele Modelle mit Gleichstrommotoren gibt, die deutlich leichter in der Geschwindigkeit geregelt werden können. Ich habe aber bei diversen Tests feststellen müssen, dass diese Motoren nur bis etwa 6 FPS brauchbar funktionieren, darunter klappt das bei den Wenigsten, was wohl an der Kennlinie dieser Motoren liegt und sie im untersten Drehzalbereich kaum Kraft haben. So war es auch bei meinem Bauer Visalux und ich habe gleich mal den Originalmotor durch einen NEMA17 Stepper ersetzt. Solche Stepper habe ich von diversen anderen Bastelprojekten daheim herumliegen.

 

Wie hier im Forum schon gefragt wurde, ober der Schlupf eines Riemenantriebes eine Rolle spielt (hängt davon ab wie der Antrieb realisiert ist) habe ich mich gleich dazu entschlossen auch einen Antrieb mit Zahnriemen einzubauen, wollte auf Nummer Sicher gehen und über Schlupf nicht nachdenken müssen,

was bei diesem Projektor wirklich sehr einfach zu bewerkstelligen war. Ich verwende eine 1:1 Übersetzung, also eine Umdrehung entspricht exakt einam Bild.

 

 

Ich verwende Zahnriemenscheiben wie sie auch für 3D Drucker verwendet werden, das ist also Zeugs das man heute sehr leicht kaufen kann

GT2 Zahnriemenscheiben und die notwendigen Zahnriemen gibt es fein abgestuft und fast verschiedenen Längen GT2 Zahnriemen 6mm

 

Bei meinen ersten Versuchen war es ein ganz normaler Stepper, für den man aber auch noch einen Controller braucht wie z.B. so etwas Stepper Treiber aber davon bin ich rasch wieder abgekommen. Es funktioniert zwar grundsätzlich wunderbar, weil man im unteren Drehzalbereich wirklich perfekt den Motor betreiben kann, aber (was ich bisher vergessen habe zu erwähnen) ich möchte versuchen auch eine Lösung zu finden, wo ich in Echtzeit scannen kann und das ging mit dem Stepper nicht, weil bei ca. 6 FPS das Ende der möglichen Drehzahl erreicht wurde. Ausserdem muss ich gestehen, dass mich bei meinen ersten Scan Tests dieses piepsende  Geräusch des Steppers echt genervt hat. Das "Gerattere" des Projektors ist ja schon unangenehm genug, aber im Zusammenhang mit so einem Stepper ist das unerträgtlich, also musste auch hier eine andere Lösung her und so habe ich testweise in einen EUMIG Mark 8 einen Stepper Servo Motor eingebaut wie im folgenden Bild zu sehen ist

 

 

und das funktioniert einfach grandios, auch wenn der iHSV57 mit seinen 100 Watt wohl "etwas" übertrieben ist, aber den hatte ich nun mal herumliegen. Auch hier wieder der entsprechende 1:1 Zahnriemanantrieb zu sehen, nur eben mit einem etwas längeren Zahnriemen. Dieser Motor ist fast nicht zu hören und kann von "Schneckentempo" also deutlich unter 1FPS bis ca. 3000 U/min betrieben werden was dann schon 50 FPS entsprechen würde.

 

Und die Ansteuerung dieser Motoren ist wirklich einfach. Man braucht 1 Pin für die Richtung und 1 Pin für die Impulse, die am Pico sehr leicht mit PWM erzeugt werden können. So stand mein Entschluß fest und ich habe nach so einem Motor aber in NEMA 17 gesucht (der iHSV57 ist doch etwas groß) und wurde letzte Woche fündig NEMA17 Servomotor und habe ihn sofort bestellt und seit gestern werkelt er in meinem Bauer Testprojektor, wie im obigen Bild zu sehen ist und das wird wohl künftig der Motor meiner Wahl sein, weil ich damit wohl ALLE meine künftigen Experimente durchführen kann.

 

Ich möchte aber schon erwähnen, dass dieser Aufwand mit dem Antrieb nicht wirklich notwendig ist und ich das jetzt nur deshalb mache, weil ich noch einige Experimente vorhabe und mich im Moment auf keine Kompromisse einlassen möchte 😉

 

[Klaus14]

vor 36 Minuten schrieb Friedemann Wachsmuth:

Ich finde aber keineswegs, dass der die 8-Bit AVRs einfach ersetzen sollte, nur weil er neuer ist. Ich bin bei EE ein Freund der Philosophie, das zu nehmen, was wirklich benötigt wird — überflüssiges bringt nur unliebsame Überraschungen. Der 328P (oder 168P) kommt beim Scannen mitnichten an irgendwelche Grenzen, reicht also vollkommen. (Im Grunde hätten die GPIO des Raspi allein wohl auch zum Steuern gereicht, mit ist der Raspi aber für sowas zu zickig, zu kompliziert, und Linux zu wenig RTOS.)

Friedmann ich gebe dir grundsätzlich recht bei EE keine unnötigen Risiken einzugehen, aber ich bin kein Profi-Entwickler, sondern mache das aus Spaß an der Sache und da ist es doch irgendwie klar, dass ich mir immer wieder was Neues ansehen möchte. Bei meiner ersten Version habe ich ALLES über die GPIOs des Raspi 4 erledigt und das hat grundsätzlich funktioniert. Der Ärger ist ja erst entstanden wie das mit dem Raspi 5 eben nicht mehr geklappt hat und da hatte ich eben endlich die Gelegenheit mir den PICO genauer anzusehen. Der 328/168P würde da vollkommen reichen und sich wohl immer noch die meiste Zeit eher fadisieren, aber mein "Drang" Neues zu erforschen hat mich einfach überwältigt. Vor allem wollte ich ausloten, wie weit ich auf dem PICO mit Micro Python komme und das ist ja auch ein erhebliches Neuland und damit Risiko ... aber es macht Spaß ... und darauf kommt es mir bei meinem Hobby ja an 😀

 

Viele Wege führen ans Ziel und ich zeige hier einfach mal meine Experimente der letzten Wochen ... was da letzt endlich daraus wird ... mal sehen 😉

 

Freue mich schon sehr auf deine weiteren Fortschritte

 

schönes Wochenende und LG aus Wien

[Friedemann Wachsmuth]

vor 1 Stunde schrieb Klaus14:

Bauer Visalux

Eigentlich ist er Visalux doch von Braun. Oder hast Du da ein seltenes Modell was ich noch nicht kenne? 🙂

 

Und Ja: der Spaß an der Sache, in unserem Fall Forscher- und Entdeckergeist, die sind das wichtigste!

[Helge]

Der Visacustic ist von Braun, der Visalux von Bauer

[Klaus14]

Es steht zumindest Bauer drauf, aber wenn ich die Technik mit meinem Bauer T502 vergleiche, bin ich nicht sicher, ob da auch ein echter Bauer drinnen ist 🫣

 

Ich kenne mich mit den ganzen Modellen zugegeben zu wenig aus, aber am Ende der Schmalfilmzeit wurden von den verschiedensten Firmen noch Projektoren auf den Markt geworfen, die sich doch sehr, sehr geglichen haben, nur wer hat die wirklich gebaut. Vielleicht gibt es hier ja einen Experten der das aufklären könnte.
 

 

[Klaus14]

Kamera & Objektiv

Als Kamera nutze ich natürlich die Raspberry HQ Kamera die ich vor dem Projektor auf einen 3-Achsen Lineartisch montiert habe. Das ist zwar zum Experimentieren recht nett, aber in der Praxis keine brauchbare Lösung, weil viel zu wackelig.

 

 

Als Objektiv verwende ich ein simples C-Mount Objektiv mit 35mm 1:1,7 vor das ich noch entsprechend viele Distanzhülsen geschraubt habe. Das habe ich rein experimentell ermittelt, ich kenne mich mit Objektiven viel zu wenig aus um dazu was Schlaues sagen zu können. Die ganze Konstruktion möchte ich aber durch ein Objektiv ersetzen, wie es Friedemann in seinem Projekt beschrieben hat, das scheint mir doch eine deutlich bessere Lösung zu sein.

[Klaus14]

Frame Sensor

fehlt eigentlich nur noch ein Sensor, der immer dann anspricht, wenn der Film nach dem Bildwechsel wieder zum Stillstand gekommen ist. Da habe ich wieder auf Technik aus dem 3D Druckerbereich zurückgegriffen und nutze Lichtschranken die als optische Endschalter verwendet werden.

 

Lichtschranke

 

 

Für die Montage (die ja sehr vom Projektor abhängt) habe ich mir mit Fusion 360 die entsprechenden Teile konstruiert und auf meinem 3D Drucker ausgedruckt. Mit etwas Übung klappt das echt gut und man findet wohl in jedem Projektor eine Stelle wo man das montieren kann. Diese Methode hat den Vorteil, dass man durch einfaches Drehen der Sensorscheibe, die den Lichtstrahl unterbricht, den richtigen Zeitpunkt perfekt justieren kann.

 

Die Auswertung des Signals übernimmt der PICO und sendet den Abspeicherbefehl an den Raspberry Pi der dann im gewünschen Format (RAW ist leider noch nicht dabei) abspeichert.

[Klaus14]

GUI am Raspberry

Und zu guter letzt noch die GUI am Raspberry die ich zu 100% in Python programmiert habe und das Framework PyQt5 nutze

 

 

Das ist aber noch in einem sehr frühen Entwicklungsstadium und da wird es wohl noch viele Änderungen geben. Ich gebe zu da nicht alles selbst implementiert zu haben, so Manches ist aus verschiedenen Projekten "zusammengeklaut" ... man muss ja das Rad nicht immer neu erfinden und in der Dokumentation der HQ Kamera gibt es ja ein wunderbares Beispiel, wo man sich was "abkupfern" kann. Also geklaut trifft die Sache nicht, habe Ausnahmslos auf Open Source Beispiele zurückgegriffen.

 

Aber da bin ich schon sehr auf die Lösung von Friedemann gespannt, denn meine GUI ist viel zu überladen. Aber im Moment dient sie mir eben auch dazu, die Möglichkeiten der HQ kamera auszuloten.

 

So das war's erst mal, damit habe ich in etwa gezeigt wie meine Experimente so aussehen. Wie der endgültige Scanner dann aussehen wird, kann ich noch nicht sagen, aber ich habe zumindest schon mal viel gelernt, seit ich mit diesem Projekt begonnen habe. Werde es weiter hier dokumentieren, wenn Interesse besteht.

[Henry08]

vor 12 Stunden schrieb Klaus14:

Es steht zumindest Bauer drauf, aber wenn ich die Technik mit meinem Bauer T502 vergleiche, bin ich nicht sicher, ob da auch ein echter Bauer drinnen ist

Ich hatte mal einen Bauer Visalux.

Dieser Projektor gehört zu den letzten, die Bauer herausgebracht hat. Der Bauer T430 als Stereo-Tonprojektor und der Visalux als Gerät ohne Tonteil. Beide erzeugt in Italien bei Silma. Man hat an diesen Projektoren gespart- der T430 hat keine Vorwickelzahnrolle und der Visalux weder eine Vorwickel- noch eine Nachwickelzahnrolle. Das ist ein großer Nachteil beim Projizieren. Für den Digitalisierungseinsatz aber ohne Bedeutung.

[Friedemann Wachsmuth]

vor 1 Stunde schrieb Henry08:

Für den Digitalisierungseinsatz aber ohne Bedeutung

Ich würde fast behaupten: Bei Einzelbildschaltung ist der Vorwicklet noch wichtiger als im kontinuierlichen Betrieb, weil die gebende Filmrolle nie in Schwung kommt sondern bei jedem Bild neu beschleunigt werden muss. Das ist auch einer der großen Fehler des Wolverine.