hurz

Ja genau, um das Ritzel und den Fokusring ein stinknormaler Zahnriemen aus der Bucht mit ca. 10-12mm Breite. Die Zähne sollten natürlich zum Ritzel passen, auf seiten der Kamera muss ich noch schauen ob ich da ebenfalls einen Zahnkranz am Objektiv montiere für optimalen Kraftschluss oder darauf verzichte. Das hängt hauptsächlich von der Spannung des Riemens und der Oberfläche des Fokusrings am Objektiv ab, ob da etwas verrutschen könnte. Aber wird sind weit vom Threadthema ab... leider bin ich gestern nicht mehr dazu gekommen den Code nochmal auszuprobieren, aber heute Abend dürfte es klappen. Wenn das so schonmal funktioniert, werde ich das ähnlich mit dem Setup für den FollowFocus probieren, also PowerSupply und Stepper durch 12V-Bleiakku gespeist, dazu ein Linear Poti und einen Schalter um dem Brick die Endlage des Fokus mitzuteilen und damit quasi das Poti bei jedem Objektiv auf den Fokusweg kalibrieren und den vollen Verfahrbereich für den Fokus nutzen zu können. Da stellt sich mir nun erneut die Frage welche Pins ich beim Linear Poti sowie beim I/O4-Bricklet setzen/auslesen muss um an die Werte zu kommen. zur not schaue ich mir da den Schaltplan an, aber wenn borg das spontan parat hat, wäre ich dankbar Beim I/O4 würde ich mal vermuten alle vier Pins mit PIO_Get bekommen zu können wenn ich sie als Input konfiguriert habe? Beim Linear Poti die Werte wohl auch mit dem ADC-Channel, aber muss ich noch Output-Pins setzen? Welche Genauigkeit hat das Poti, 12 oder gar 16bit? Diese Fragen führen wieder zu Nics berechtigtem Wunsch nach einer Art Übersicht/Architekturbeschreibung auf hardwarenaher Ebene... Man kann sich wohl alles aus Schaltplänen und Quellcode herauslesen, das ist aber schon immer mühsam und nicht für jeden leicht verständlich.

Der Antrieb wird parallel zur Kamera montiert, mit der Welle in gleicher Blickrichtung wie das Objektiv. Auch eine Montage unter der Kamera wäre denkbar, da ist man mit einem Zahnriemen ja flexibel. Fürs erste verwende ich diesen Makroschlitten: http://www.enjoyyourcamera.com/Makrozubehoer/Makro-Einstellschlitten/Stereo-Einstellschlitten-LP-02-Verstellweg-24cm::3734.html Auf einer Schraube meine DSLR, auf der anderen ein Gehäuse mit Motor, Stepdown-PowerSupply und Stepper Brick. Je nach Objektiv lassen sich dann Motorritzel und Fokusring passend zueinander ausrichten (sowohl seitlicher Abstand als auch nach vorne, Stichwort Parallelogramm). Ich werde die ganze Anordnung also nie aufs Bild bekommen... vielleicht kann man sich das noch nicht so gut visuell vorstellen, aber bald gibts dann mehr dazu.

Beim FollowFocus werde ich keine direkte Verbindung zum Objektiv herstellen, sondern über einen Zahnriemen. Je nach Objektivdurchmesser ergibt sich da schon eine recht große Übersetzung, da wird die kleinste Drehung von 1,8° beim Ritzel nur 0,x° am Objektiv ausmachen. Das ist auf jeden Fall genau genug. Beim Ruck muss ich mir was einfallen lassen. Bei längeren Schrittweiten kann man ja über Rampen fahren, ansonsten kommts am ehesten auf das verwendete Objektiv an. Da sind die üblichen Consumer-Objektive nicht sehr geeignet (kleiner Drehwinkel am Fokusring, schlecht gedämpft), aber es gibt ja (und ich habe) durchaus gut gedämpfte manuelle Objektive mit langem Fokusweg (von Samyang oder Voigtländer z.B.), damit dürfte das schon klappen. Aber mal sehen, ich werde berichten wie es läuft

Die Leinwand selbst ist nicht motorisiert, wiegt ja alles in Allem so an die 40kg. Dafür bräuchte ich schon große Kaliber (Garagentormotor oder sowas) oder einen entsprechenden Seilzug. Dann hätte ich aber die Decke abhängen müssen um das unsichtbar unterzubringen. Aber da reden wir dann über ca. 20Nm, nicht mehr Ncm. Die Leinwand wird von Magneten an der Decke gehalten und bei Bedarf manuell runtergeklappt. Nur die schwarze Maskierung vom oberen Bildrand ist motorisiert (IKEA Tupplur Rollo). Selbst dafür habe ich schon eine kleine Übersetzung gebraucht, fahre den Motor aber auch im Achtelschrittbetrieb, da hat er nicht soviel Dampf läuft da aber angenehm ruhig.

Ich verwende wie schon bei der Leinwand recht klein bauende Schrittmotoren mit 1,8° Schrittwinkel und um die 4-5 Ncm Drehmoment. Nema17-Moteren z.B. Ich hab noch ein paar gebrauchte aus der Bucht hier herumliegen. Für einen FollowFocus würde sich ein Servo zwar besser eignen, weil ich dann wirklich einen bestimmten Winkel=Fokusentfernung geregelt anfahren kann, aber über den Schrittmotor und eine Übersetzung dürfte das schon ausreichend genau klappen. Ich hab einfach noch einen Stepper Brick übrig, das bietet sich also an. Das High-Level-Konzept hat halt immer den Nachteil, dass ich neben dem PowerSupply und dem Stepper Brick eben noch zumindest eine Art Rechner mit USB-Verbindung bzw. sogar noch einen MasterBrick und WLAN-Extension unterbringen müsste. Das braucht natürlich mehr Platz, der Programmieraufwand ist ggf. größer, die Latenzzeiten steigen, etc. aber flexibler ist man dann natürlich schon und kann komplexere Dinge realisieren. Für einen Roboter, eine Wetterstation oder eine CNC-Fräse würde ich jetzt nicht unbedingt low-level programmieren, aber für eine simple vor/zurück-Steuerung eines einzelnen Motors finde ich es recht sinnlos einen kleinen Rechner irgendwie verbauen zu müssen und den Dämon drauf laufen zu lassen oder den Stapel um Master und WLAN aufstocken zu müssen. Von den zusätzlichen Kosten ganz abgesehen. Auch wenn die Low-Level-API oder eine genauere Beschreibung noch auf sich warten lassen, muss ich aber sagen dass ich wirklich beeindruckt bin was so wenige Leute auf die Beine gestellt haben, v.a. wenn man sich mal die Menge an Code im Repository anschaut, den schnellen Support im Forum, die mitlerweile echt große Vielfalt an Bausteinen etc. Weiter so!

Das halte ich auch für eine gute Idee. An den grundlegenden Programmierkenntnisse mangelt es den Tinkerforge-Kunden ja nicht, sie müssen so oder so programmieren. Die zusätzlichen Kenntnisse für die Verwendung der Bricks und Bricklets low-level sind ja auch nicht schrecklich kompliziert wenn man eben wüsste was man alles beachten muss, also welche Pins wofür da sind, wo Daten liegen die wie ausgelesen werden können, etc. Den Hinweis mit der Pin-Konfiguration probiere ich gleich heute Abend aus! Ich dachte eben dass ein PIO_Set den Pin bereits durch das HIGH-Setzen als Output-Pin benutzt (Inputs kann ich ja schlecht manipulieren), aber das ist eben eine Kleinigkeit die mich schon von alleine viel weiterbringt, wenn sie irgendwo stehen würde. Das würde euch ja auch etwas den mühsamen Support im Forum sparen. Ich kann versuchen da etwas im Wiki zu schreiben wenn alles klappt. Zur Frage "was die Kunden wollen" hier als Beispiel meine ersten zwei kleinen Projekte mit Tinkerforge und wofür ich diese Umstände mit der low-levlel-Steuerung des Stepper Bricks mache: 1) Ich habe eine Heimkinoleinwand mit motorisierter Maskierung gebaut: http://mulb.org/node/1084. Im ersten Schritt soll die Maskierung über den Joystick und Schrittmotor steuerbar sein (rauf/runter). Im zweiten Schritt will ich das Ambient Light Bricklet, das in der Unterkante der Maskierung eingebaut ist, dazu verwenden, selbstständig den Rand des beleuchteten Bildes zu erkennen und den Schrittmotor im Runterfahren passend anzuhalten. Ein dritter Schritt wäre der Leinwand über die WLAN-Extension bereits zu sagen, welches Format das Bild haben wird und den Schrittmotor so anzusteuern (werde ich aber vermutl. nicht realisieren). Hier sieht man schon dass es keinen Sinn macht eine dauerhafte USB-Verbindung zu haben, es sei denn ich Verwende einen ebenfalls eingebauten RaspberryPi, das erscheint mir für die sehr einfache Aufgabe aber Overkill. 2) Mein nächstes Projekt das jetzt parallel startet wird ein Filmkran mit motorisiertem Follow-Focus für das Filmen mit einer DSLR. Dazu werde ich ebenfalls einen Stepper (mit einem Motor über Zahnriemen oder Zahnkranz am Objektiv) sowie ein Linear Poti Bricklet und wieder low-level Programmierung um mobil zu sein und mit der Kamera den Fokus sehr genau ziehen zu können ohne eine mechanische Verbindung zur Kamera zu haben. Auch hier wäre im nächsten Schritt dann eine Ansteuerung des Fokus über ein Tablet oder Handy möglich, was dann aber wohl doch ein High-Level-Konzept benötigt (wegen der Verbindung zur Andrroid- oder iOS-Software). Sollte meine low-level-Versuche mit Erfolg gekrönt sein, kann ich natürlich gerne über die Projekte hier im Forum und über die Realisierung im Wiki berichten.

Ok, danke für den Hinweis. Das ist so explizit nirgends beschrieben, oder? Jetzt hängt ein Step-Down Power Supply unter dem Stepper Brick und er läuft auch ohne USB-Verbindung. Nur das Auslesen der ADC-Daten will noch nicht richtig funktionieren. Komme da einfach nicht weiter. Habs auch probiert mit: adc_channel_get_data_unfiltered(BRICKLET_A_ADC_CHANNEL) Ich vermute, ich mache grundsätzlich etwas falsch, nur was? Genrell mache ich folgendes (siehe Source-Code weiter oben): Schritt 1: PIN3 setzen für X-Achse (PIO_Set) Schritt 2: ADC auslesen und dann PIN3 und PIN4 rücksetzen (PIO_Clear) Schritt 3: PIN4 setzen für Y-Achse (PIO_Set) Schritt 4: ADC auslesen und dann PIN3 und PIN4 rücksetzen (PIO_Clear) Schritt 5: Schrittzähler zurücksetzen Gelesen wird der Wert ja aus folgendem Register des SAM3: RoReg ADC_CDR[16]; /**< \brief (Adc Offset: 0x50) Channel Data Register */ Entweder werden keine Werte dort periodisch hineingeschrieben oder ich mache etwas anderes falsch? Wenn jemand noch Ideen hat, wäre für jeden Hinweis dankbar... Wofür ist der PIN1 gut? Laut Schaltplan wird dort drauf die aktive Spur des Joystick geschrieben. Muss ich den auch irgendwie auslesen damit ich die ADC-Werte bekomme?

Nochmal zum USB-Problem: Kann ich den Brick überhaupt ohne zusätzliche 5V-Versorgung (über Stack oder USB) betreiben? Holt er sich aus der externen Versorgung für den Motor (bei mir 24V) die 5V-Versorgung für seinen Chip etc. oder muss ich ihm zwingend noch 5V auf den Stack-Pins bzw. per miniUSB füttern? Ich will den Brick ja eigentlich völlig alleine ohne Stack oder per USB angeschlossenem Gerät betreiben... Da er in der Firmware ohne USB-Verbindung als "stack participant" eingestellt wird, weiß ich nur nicht wie ich ihn dazu bewege, sich selbst zu versorgen und als quasi-Master zu agieren. Zum Auslesen der Analogwerte: Soweit ich das aus dem Schaltplan des Joystick bricklets sehe, schalten ja die Pins 3 und 4 die y- bzw. x-Spur des Joysticks auf den Pin 1. Muss ich diesen Pin auch gesondert per PIO_Get auslesen oder macht das "adc_channel_get_data(...)" bereits? Welchen "channel" muss ich der Funktion denn übergeben? Ich habs mit beiden probiert,e rhalte aber bei beiden keine vernüftigen Werte... - BRICKLET_A_ADC_CHANNEL (84) - BRICKLET_A_ADDRESS (12) Das Initialisieren des Channels mittels "adc_channel_enable(BRICKLET_A_ADDRESS)" sollte ja quasi schon die Verbindung zum Pin 1 herstellen um dessen Wert als 12bit-Digitalwert in den Speicher (BRICKLET_A_ADC_CHANNEL?) schreiben zu können. Irgendwo ist da noch der Wurm drin. Da es aber über den BrickV problemlos funktioniert, liegt das Problem sehr wahrscheinlich an meinem Code... Muss ich vielleicht doch das bricklet initialisieren damit ich Daten im ADC-Channel bekomme? Ich hoffe ich bekomme das noch irgendwie hin, sonst müsste ich zur Not doch auf einen Master-Brick ausweichen. Aber würde dieser von der externen Spannung am Stepper versorgt werden oder müsste ich auch noch über USB oder ein PowerSupply Brick zusätzlich einspeisen?

Vieln Dank für die Hinweise! Habe es so umgesetzt wie vorgeschlagen und meinen Code im Tick-Task der stepper.c integriert. Es funktioniert das Auslesen des Buttons über PIO_Get und cih kann Pins high und low setzen über PIO_Set und PIO_Clear, aber ich bekomme aber keine vernünftigen Werte aus dem ADC channel. Die sollten ja zwischen 0 und 4095 sein? Angelehnt an die Funktion "position_from_analog_value_x(...)" in der joystick.c sieht meine Funktion jetzt z.B. so aus (aber ohne die zusätzliche Addition beim temp-Wert haute auch nicht hin... mir ist nicht so ganz klar wozu die gut ist): temp = (int32_t)adc_channel_get_data(BRICKLET_A_ADC_CHANNEL) + (MAX_ADC_VALUE / MAX_JOYSTICK_POSITION)/2; joystick_position_y = MAX_JOYSTICK_POSITION/2 - SCALE(temp, 0, MAX_ADC_VALUE, 0, MAX_JOYSTICK_POSITION); Den Motor würde ich dann so ansteuern: if(joystick_position_y > MAX_JOYSTICK_POSITION/3) { stepper_direction = STEPPER_DIRECTION_FORWARD; stepper_make_step(); } if(joystick_position_y < -MAX_JOYSTICK_POSITION/3) { stepper_direction = STEPPER_DIRECTION_BACKWARD; stepper_make_step(); } Der Motor bewegt sich auch, aber immer nur "backward" egal in welcher Position der Joystick steht. Das spräche aber für zu große eingelesene Werte... Vielleicht fällt dir ja mein fehler auf? Im Anhang wäre auch meine komplette, modifizierte stepper.c soweit... Neben deinem Vorschlag hab ichs eben auch mit der ADC-Channel-Adresse statt der Bricklet-Adresse probiert, das erschien mir richtiger oder nicht? adc_channel_enable(BRICKLET_A_ADC_CHANNEL) adc_channel_get_data(BRICKLET_A_ADC_CHANNEL) Mein größtes Problem ist aber noch das Folgende: Der Tick-Task läuft scheinbar nur bei bestehender USB-Verbindung durch. Wenn ich den Stepper-Brick nur über externe Stromversorgung ohne USB betreibe, rührt sich nichts mehr. Er wird ja scheinbar ohne USB als "stack participant" eingestellt... Muss ich den Brick für den autarken Betrieb dann als Master setzen? Das Definieren von BRICK_CAN_BE_MASTER als 1 bringt mir aber an anderen Stellen Probleme... EDIT: Datentypen hatten noch nicht gepasst, habe die stepper.c nochmal aktualisiert. adc_channel_get_data() gibt uint16 zurück, für die Position (+-) rechne ich in int32 um... EDIT2: Nochmal mit durchgängig uint16 probiert und Rohdaten. Ich lese wohl grundsätzlich FFFF also 65535 ein, weiß aber nicht woran das liegen könnte. Schreibt das Bricklet keine Daten in den ADC channel? config.h stepper.c

Danke für die schnelle Antwort! Ok, soweit ich dich und den Code verstehe passiert folgendes: main ruft brick_init() auf, dieses wiederum bricklet_init(). Während dem Bricklet-Input wird über die Funktion "i2c_eeprom_master_read_plugin" der Code (plugin) des bricklets ausgelesen und über "bricklet_write_asc_to_flash" in den Speicher geschrieben. D.h. am Speicherort von ba (bricklet api), bs (settings) und bc (context) finde ich jeweils die Daten. Aber sind dem Brick jetzt die Funktionen is_pressed(...), position_from_analog_value_x(...) bzw. _y(...) bekannt und können aufgerufen werden? Die Return-Werte dieser Funktionen scheinen ja jeweils in den BrickContext geschrieben zu werden, aber wie kann ich diesen auf dem Stepper-Brick auslesen? Oder ist es dieser context der über das Auslesen des Plugins eingelesen wurde? Das Drücken des Joystick wird ja scheinbar von selbst durch den tick-task upgedated, die Analogwerte muss ich mir ja bei Bedarf holen vermute ich? Nur ist mir noch nicht ganz klar wie ... Hättest du noch ein paar Tipps für mich oder gar ein kurzes Code-Schnipsel zum Auslesen von einem Analogwert z.B.? Von da an dürfte ich durch experimentieren mein simples Programm hoffentlich hinbekommen ... Tut mir Leid wegen der vielen Fragen und ich weiß low-level-Programmierung ist nicht wirklich für Tinkerforge-Anfänger wie mich gedacht, aber für mein Projekt würde ich gerne vom Master bzw. einem brickd unabhängig sein und die eigentliche Aufgabe ist ja sehr einfach, mir fehlt es nur ein bisschen an den low-level-Grundlagen.

Hallo zusammen, bin gerade dabei ein einfaches Projekt umzusetzen, in dem ein Stepper Brick von einem Joystick rudimentär bedient werden soll, ohne angeschlossenen Master Brick und ohne USB-Verbindung (da der Brick schwer erreichbar sein wird). Mir ist es bisher recht problemlos gelungen die original Firmware mit einigen geänderten Standardwerten neu zu kompilieren und im brickv zu testen. Im nächsten Schritt wollte ich die main.c um erste Aktionen wie stepper_enable() usw. erweitern um den angeschlossenen Motor direkt autark steuern zu können. Beim Stöbern im Code suche ich aber bisher vergeblich nach den Funktionen um die Bricklet-Daten auszulesen. Ich finde nur bricklet_read_plugin() usw. die wohl eher fürs Flashen/Verifizieren gedacht sind? Aber womit bekomme ich z.B. die Positionsdaten eines Joystick-Bricklets? Ich hatte mir das so vorgestellt: Nach der Initialisierung überprüft der Stepper-Brick endlos die einkommenden Daten vom Joystick-Bricklet. Wird der Joystick geklickt, möchte ich stepper_enable() aufrufen, beim Loslassen stepper_disable(). Mit der Richtung des Joystick (oben/unten) will ich schrittweise (je nach Zykluszeit?) fahren, solange der Joystick weit genug (>x) ausgelenkt ist. Hättet ihr ein paar Tipps wie ich diese low-level Funktionen realisieren kann oder wo ich die benötigten Funktionen zum Auslesen des Bricklet finde? Ach ja, noch eine kleine Frage: Dient der in der main.c aufgerufenen Task lediglich einer Art Watchdogfunktion oder hat er noch eine tiefere Bedeutung? Entschuldigt die etwas "dummen" Fragen aber meine C-intensive Zeit ist schon eine Weile her =) Vielen Dank!