Servus Zusammen, ich hab mich beim Titel ein bischen schwer getan - sorry der klingt irgendwie creepy =) Also folgendes "Problem": Ich besitze eine Nikon D5000. Ich mache recht gern Zeitraffer-Aufnahmen. Nachdem ich aber die Aufnahmen in verschiedenen Blenden / Belichtungen machen möchte - dies aber über längere Zeiträume - brauche ich soetwas wie einen Zeitauslöser. Sowas gibt's auch - leider ohne die Möglichkeit Blende & Belichtungszeit bei jedem Foto zu variieren. Prinzipiell lassen sich die Kameras auch alle "per USB" steuern. Hierzu gibt's von Nikon eine spez. Software namens Camera Control Pro. Desweiteren gibt es ein SDK von Nikon mit dem das ganze auch möglich ist. Ich wollte also einen ATMEGA engagieren und ihm beibringen die entsprechenden Kommandos an die Kamera zu senden. Leider rückt Nikon das "Protokoll" natürlich nicht raus. Es gibt auch keinerlei Informationen über diese wie auch immer geartete Protokoll. D.h. zumindest keine entsprechend detaillierten. Darum sehe ich folgende Möglichekeiten (oder auch nicht) - Irgendwie das SDK (für C++ / Win & Mac) auf den MEGA8 bekommen. Leider fehlt mir da die Erfahrung und ich möchte bezweifeln, dass sowas gelingt. Von Nikon gibt's halt Treiber aber was hilfts... - Die Verbindung "mitcapturen" und dann irgendwie die Datenflut zu analysieren. Große Zweifel ... - Die verschiedenen Kombinationen aus Blende + Belichtung immer per Software (im Endeffekt via SDK) loszuschicken, den "Verkehr" dann mitschneiden und dann wieder per MEGA8 loszuschicken. Das das wohl nicht so einfach sein wird wie ich mir das vorstelle ist mir übrigens auch klar. Leider gefallen mir die letzten beiden Möglichkeiten absolut nicht. Das ist irgendwie die DIRTY-Methode ;) Mir fällt leider absolut nichts besseres ein. Fällt vielleicht jemandem von euch was ein? Vielleicht auch nur ein Kommentar zur Machbarkeit... Dankeschön ...
>- Die verschiedenen Kombinationen aus Blende + Belichtung immer per >Software (im Endeffekt via SDK) loszuschicken, den "Verkehr" dann >mitschneiden und dann wieder per MEGA8 loszuschicken. Das das wohl nicht Vergiss den MEGA8.
@Holger Full Ack.... halte ich für nicht machbar, v.a. kein USB-Host-Interface Besorg dir irgendwas worauf das SDK läuft, notfalls einen alten Rechner oder wenn vom SDK unterstützt irgendwas worauf Linux läuft und USB-Host Interface hat (OpenWRT-Router oder die Motorola Box die es bei Pollin für 5€ gab) Gruß Roland
>Ja notfalls nehm ich auch nen FPGA + MEGA128.
Und da USB Host reinprügeln?
Wie wärs mit nem kleinen Netbook?
Roland Praml schrieb: > @Holger Full Ack.... halte ich für nicht machbar, v.a. kein > USB-Host-Interface > > Besorg dir irgendwas worauf das SDK läuft, notfalls einen alten Rechner > oder wenn vom SDK unterstützt irgendwas worauf Linux läuft und USB-Host > Interface hat (OpenWRT-Router oder die Motorola Box die es bei Pollin > für 5€ gab) > > Gruß > Roland Hmm ich hab noch nen PDA mit Windows Mobile. Vielleich könnte man das dadrauf zum laufen bringen. Gibt's sowas wie ein Bluetooth <> USB Inteface. Also so á la: Bluetooth Infterface mit PDA verbinden - "dann Bluetooth-Schnittstellen haben" ?
Ein Mega8 ginge vielleicht, wenn du die entsprechenden Tastenbefehle sendest, dies würde aber bedeuten, dass du den direkt an die Taster anlöten musst (oder vielleicht intern irgendwo i2C o.ä. abgreifen musst) was bei einer hochwertigen Kamera auch nicht empfehlenswert ist.
Roland Praml schrieb: > Ein Mega8 ginge vielleicht, wenn du die entsprechenden Tastenbefehle > sendest, dies würde aber bedeuten, dass du den direkt an die Taster > anlöten musst (oder vielleicht intern irgendwo i2C o.ä. abgreifen musst) > was bei einer hochwertigen Kamera auch nicht empfehlenswert ist. So DIRTY wollt ich's dann doch nicht machen... ;)
Lehrmann Michael schrieb: > Ja notfalls nehm ich auch nen FPGA + MEGA128. Sinnvoller wäre wohl ein AT90USB647 oder sowas in dem Stil, der kann wenigstens USB OTG, ohne dass man da irgendwas zusammenfummeln muss. Das spannendere ist natürlich das Reverse-engineeren des Protokolls. Da hilft vermutlich nur USB mitsniffen, Belichtungsreihen machen und hoffen, dass die auf dem USB nicht verschlüsselt kommunizieren. Wenn man dann die Kamera z.b. kontrolliert via z.B. libusb auslösen kann, dann kann man sich Gedanken über eine µC-Plattform machen. Bevor Du Dich allerdings da wirklich reinkniest: Guck Dir mal an, ob Du die Kamera mit gphoto auslösen kannst ( http://www.gphoto.org/ ). Da ist die D90 als unterstütztes Modell (im PTP-Modus) gelistet. Ob das tatsächlich auch das Einstellen von Parametern erlaubt, weiß ich nicht. Aber einen Versuch ist es wert: Zumindest das Auslösen von Fotos sollte gehen, sogar (laut manpage) folgende Nikon-Spezialität:
1 | --capture-tethered |
2 | Lets gphoto2 wait for notifications from the camera that an object |
3 | was added. This is useful for tethered capture, where pressing the |
4 | shutter on the camera immediately transfer the image to the machine |
5 | for processing. |
6 | |
7 | Together with the --hook-script to immediately postprocess or |
8 | display the images this can help a studio workflow. |
9 | |
10 | This option requires support in the driver and by the camera, |
11 | currently only Nikon DSC are known to work. |
Viele Grüße, Simon
Simon Budig schrieb: > Das spannendere ist natürlich das Reverse-engineeren des Protokolls. Da > hilft vermutlich nur USB mitsniffen, Belichtungsreihen machen und > hoffen, dass die auf dem USB nicht verschlüsselt kommunizieren. Okay - Logic Analyzer ? Simon Budig schrieb: > Bevor Du Dich allerdings da wirklich reinkniest: Guck Dir mal an, ob Du > die Kamera mit gphoto auslösen kannst ( http://www.gphoto.org/ ). Da ist > die D90 als unterstütztes Modell (im PTP-Modus) gelistet. Ob das > tatsächlich auch das Einstellen von Parametern erlaubt, weiß ich nicht. Nein soweit ich das verstanden habe werden die Photos einfach sofort zum PC übertragen. Der Source Code ist außerdem von ungeahntem Ausmaß.
Lehrmann Michael schrieb: > Simon Budig schrieb: >> Das spannendere ist natürlich das Reverse-engineeren des Protokolls. Da >> hilft vermutlich nur USB mitsniffen, Belichtungsreihen machen und >> hoffen, dass die auf dem USB nicht verschlüsselt kommunizieren. > > Okay - Logic Analyzer ? Nö, usbsnoop oder sowas - es gibt diverse USB-Sniff-Software, was im Moment en-vogue ist, weiß ich nicht. > Nein soweit ich das verstanden habe werden die Photos einfach sofort zum > PC übertragen. > > Der Source Code ist außerdem von ungeahntem Ausmaß. Hm. Zumindest in http://gphoto.svn.sourceforge.net/viewvc/gphoto/trunk/libgphoto2/camlibs/ptp2/cameras/nikon-d90.txt?revision=12265&view=markup stehen viele interessante Dinge drin :) Leider für meine D40 erheblich weniger Dinge... Viele Grüße, Simon
Ok, folgendes funktioniert hier mit meiner D40 und dem gphoto aus dem aktuellen Ubuntu:
1 | $ gphoto2 --set-config shutterspeed=1.0000s \ |
2 | --set-config f-number=f/7.1 --capture-image-and-download |
Damit das funktioniert muss die Kamera am Modus-Rad in den manuellen Modus gedreht werden, ansonsten verweigert die Kamera die Einstellung von Shutterspeed und/oder F-Nummer. Das --capture-image-and-download sorgt dafür, dass das Bild nicht auf die Speicherkarte geschrieben wird. Eine Liste der möglichen Parameter findet man mittels --list-config. Achtung: Die Zeiten/F-Stops müssen genau so geschrieben werden wie sie bei "--get-config shutterspeed" auftauchen. Alternativ kann man die Index-Zahlen verwenden.
Cool das wusste ich garnicht =) vielen Dank Dann muss ich nur noch ein Linux auf einen µC bringen xD Spaß. Für meine D5000 gibt's 2500 Zeilen Dokumentation. Leider fehlt mir noch das wissen wie ich nun das ganze auf den Weg schicke =)
Lehrmann Michael schrieb: > Für meine D5000 gibt's 2500 Zeilen Dokumentation. Leider fehlt mir noch > das wissen wie ich nun das ganze auf den Weg schicke =) Ach, D5000. Wie komme ich denn auf D90? Egal, sollte prinzipiell ähnlich gehen. > Dann muss ich nur noch ein Linux auf einen µC bringen xD Spaß. Naja, das entscheidende ist doch letztlich, dass gphoto eine Free-Software im Sinne der FSF ist, d.h. insbesonders, dass lesbarer Source vorhanden ist. Jetzt muss man "nur noch" lesen, wie PTP auf dem USB-Level funktioniert, dann muss man rauskriegen wie man die Funktionen der libusb auf den USB-Controller mappt und dann hat man schon 90% der Funktionalität. Natürlich brauchen die restlichen 10% dann 90% der Zeit... :-) Viele Grüße, Simon
Oje ich glaub ich muss mich mal mit USB Beschäftigen. Erfahrung = 0. Nur UART<>USB Bridge soweit man das Erfahrung nennen kann.
Servus nochmal, so mir reichts - ich glaub auf einen Microcontroller bekomme ich den Spaß nie und nimmer drauf. Jetzt werd ich mich mal in eine andere Richtung wenden: Heute hab ich zufällig das hier gesehen. Beitrag "20Euro Embedded System mit ARM, 128MB ram und 256MB Flash" Da fiel mir auf, dass man da wohl Gentoo (Linux) draufbringen kann. Ich hab zwar weder Plan von Linux noch von dieser "Box" aber ich muss es wohl irgendwie schaffen ein Programm für Gentoo zu schreiben, dass mir auf der Box gphoto2 in der Kommando-line-operation ausführt. Simon Budig schrieb: > $ gphoto2 --set-config shutterspeed=1.0000s \ > --set-config f-number=f/7.1 --capture-image-and-download Als Interface dachte ich an einen MEGA8 und dann eine UART<>virtueller COM Port. Gibt's sowas auch unter Gentoo ? Muss mich glaub endlich mal mit Linux beschäftigen xD Im Endeffekt also: LCD+Taster <> MEGA8 <> Belichtungsablauf <> UART <> USB <> virt. COM <> mein Programm auf "Box" <> gPhoto2 <> USB <> Kamera Puuh
Lehrmann Michael schrieb: > Simon Budig schrieb: >> $ gphoto2 --set-config shutterspeed=1.0000s \ >> --set-config f-number=f/7.1 --capture-image-and-download > > Als Interface dachte ich an einen MEGA8 und dann eine UART<>virtueller > COM Port. Gibt's sowas auch unter Gentoo ? > > Muss mich glaub endlich mal mit Linux beschäftigen xD > > Im Endeffekt also: LCD+Taster <> MEGA8 <> Belichtungsablauf <> UART <> > USB <> virt. COM <> mein Programm auf "Box" <> gPhoto2 <> USB <> Kamera Ähwas? :) LCD+Taster <> at90usb162 <> USB CDC (virt. COM) <> dein Programm auf "Box" <> gphoto2 <> USB <> Kamera (Ja, ich bin da etwas vorbelastet: http://shop.kernelconcepts.de/product_info.php?cPath=1_27&products_id=102 ) Oder aber du nimmst direkt einen Linux-tauglichen embedded-Rechner, der ein Display+Tastatur selber ansteuert: dein Programm auf "Box" <> gphoto2 <> USB <> Kamera. Ist natürlich etwas teurer als der 20 EUR Hackspaß, potentiell aber erheblich interessanter. Sowas zum Beispiel: http://shop.strato.de/epages/61238048.sf/de_DE/?ObjectPath=/Shops/61238048/Products/5041 Fotos direkt von der Kamera runterladen, direkt auf dem Bildschirm darstellen und dann per WLAN irgendwohin hochladen... Nurmalsoalsidee... Simon
Hm, habe gerade nochmal überlegt. Ich glaube Du hast zuviel Respekt vor dem USB. Glaub mir, dass die Einarbeitung in Embedded-Linux schon auf offiziellen Eval-Boards nicht unbedingt ein Zuckerschlecken ist, erst recht nicht auf solchen Hack'n'Repurpose-Boards. Es macht ohne Frage Spaß und bringt einen deutlich voran, aber "nur" für Dein Ziel, eine Kamera automatisch gesteuert auszulösen scheint es mir deutlich Overkill zu sein. Besorg Dir ein http://www.watterott.com/de/Atmel-AT90USBkey und wühl Dich durch USB, die LUFA-Library und die gphoto-sourcen. Viele Grüße, Simon
Ich weiß, dass ich einem uralten Thread wieder aus der Versenkung ziehe, aber ich wollte mal nachfragen, ob sich hier etwas getan hat?! Gibt nämlich mittlerweile das ein oder andere, z.B. das hier: https://www.timelapseplus.com/ Ist aber ein bisschen teuer, wie ich finde. Die SW ist sogar open, sodass man praktisch nur die Hardware nachbauen müsste. Sollte machbar sein, oder? Jemand Interesse?
Bitte 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.