Plenz

Hast du gesehen? Die liefern nicht an private Kunden! Mehrere Analog-Bricks in Reihe schalten kannst du nur dann, wenn sie alle völlig unabhängig voneinander ihre eigene Stromversorgung haben. Du darfst sie also nicht zusammenstecken, und sie dürfen auch nicht per USB an dem selben Computer angeschlossen sein. Du könntest aber einen Analog-Brick nehmen, an den Ausgang kommt eine Zener-Diode für 7 Volt und daran die Basis eines Leistungstransistors. An dessen Emitter kommen mindestens 14 Volt, dann kannst du am Collector eine Spannung zwischen 7 und 12 Volt einstellen.

Ich mache nun meine ersten Gehversuche mit Python. Es geht um einen Getriebemotor, dessen Achse sich maximal um +/- 120 Grad verdrehen darf. Die eigentliche Steuerung kommt später, aber für den Fall, dass sie versagt, habe ich schon mal einen Schalter eingebaut, der in beiden Endstellungen betätigt wird. Er hängt an Pin0 eines IO4-Bricklets und dieses an einen DC-Brick, der den Motor steuert. Zum Testen habe ich ein Programm geschrieben, das beim Betätigen des Schalters die Drehrichtung umkehrt: HOST = "localhost" PORT = 4223 UID_DCo = "9oXWJFxoHoS" # DC Brick oben UID_IO4 = "7Qo" # IO-4 Bricklet from tinkerforge.ip_connection import IPConnection from tinkerforge.brick_dc import DC from tinkerforge.bricklet_io4 import IO4 dco = None io4 = None velo = 0 # Callback function for interrupts def cb_interrupt(interrupt_mask, value_mask): vm = value_mask & 1 if vm < 1: velo = dco.get_velocity() dco.full_brake() dco.set_velocity(velo * -1) if __name__ == "__main__": ipcon = IPConnection(HOST, PORT) # Create IP connection to brick io4 = IO4(UID_IO4) # Create device object ipcon.add_device(io4) # Add device to IP connection io4.set_debounce_period(500) io4.set_configuration(3, 'i', True) # Eingang Pin 0 und 1 mit Pull-Up io4.set_interrupt(3) # Eingang Pin 0 und 1 = Interrupt io4.register_callback(io4.CALLBACK_INTERRUPT, cb_interrupt) dco = DC(UID_DCo) # Create dc brick device object ipcon.add_device(dco) # Add device to IP connection dco.enable() dco.set_acceleration(0xFFFF) # acceleration (FFFF = full) velo = 10000 # Velocity: -32767/32767 dco.set_velocity(velo) raw_input('Press Enter to exit\n') # Use input() in Python 3 dco.disable() ipcon.destroy() Das funktioniert auch so weit ganz gut, der Motor dreht sich brav zwischen den Anschlägen hin und her. Wenn ich jetzt aber die Geschwindigkeit erhöhe, tun sich merkwürdige Dinge auf dem Bildschirm: Exception in thread Thread-2: Traceback (most recent call last): File "C:\Programme\Python\lib\threading.py", line 551, in __bootstrap_inner self.run() File "C:\Programme\Python\lib\threading.py", line 504, in run self.__target(*self.__args, **self.__kwargs) File "build/bdist.linux-x86_64/egg/tinkerforge/ip_connection.py", line 212, in callback_loop device.callbacks[function_id](*self.data_to_return(data[4:], form)) File "C:\Programme\Python\CamStab.py", line 22, in cb_interrupt io4.set_configuration(8, 'o', True) # Ausgang Pin 3 File "build/bdist.linux-x86_64/egg/tinkerforge/ip_connection.py", line 76, in func return f(self, *args, **kwargs) File "build/bdist.linux-x86_64/egg/tinkerforge/bricklet_io4.py", line 87, in set_configuration self.ipcon.write(self, IO4.FUNCTION_SET_CONFIGURATION, (pin_mask, direction, value), 'B c ?', '') File "build/bdist.linux-x86_64/egg/tinkerforge/ip_connection.py", line 279, in write self.destroy() File "build/bdist.linux-x86_64/egg/tinkerforge/ip_connection.py", line 222, in destroy self.join_thread() File "build/bdist.linux-x86_64/egg/tinkerforge/ip_connection.py", line 245, in join_thread self.thread_callback.join() File "C:\Programme\Python\lib\threading.py", line 654, in join raise RuntimeError("cannot join current thread") RuntimeError: cannot join current thread Was soll ich nun damit anfangen?

Meine Befürchtung ist aber: je höher die Frequenz, desto höher sind Verluste in den Halbleitern (die Zeit, die auf einem Level verbracht wird, wird immer kürzer, während immer mehr Zeit zum Umschalten benötigt wird) plus Verluste im Motor (Wirbelströme etc.). Deshalb zögere ich, Frequenzen im kHz-Bereich zu verwenden. Kann aber auch sein, dass diese Befürchtungen erst im 10-er oder 100-er kHz-Bereich zum Tragen kommen... ich weiß es wirklich nicht und lasse mich gern belehren.

Ich hänge meine Frage hier mal dran, weil das Thema so allgemein formuliert ist Ich habe nun einen Gleichstrom-Getriebemotor an den DC-Brick angeschlossen, alles funktioniert prima, nur eine Frage: welche PWM-Frequenz soll ich wählen? Lieber hoch oder lieber niedrig oder kann ich irgendwie ein Optimum ermitteln?

Nach meiner Einschätzung fängst du die Sache völlig falsch an. Ich würde zuallererst mal an das Schneidwerk denken. Wie groß ist das? Wie schwer ist das? Welche Stromversorgung braucht es? Wie groß und wie schwer ist die Stromversorgung? Und wenn du das alles weißt, DANN kannst du anfangen, über das Fahrwerk nachzudenken.

Ich fürchte, das wäre zu umständlich. Die Motoren beeinflussen zumindest den Kompass meines Smartphones schon bei einer Entfernung von 20 cm. Ich hoffe, ich kriege es hin, nur die Kreiselfunktionen des IMU auszuwerten und die Magnetfeldfunktionen zu ignorieren.

Schau doch einfach mal, was es bereits alles auf dem Markt gibt, z.B. die "Homematic". Und dann schau mal, was deren Besitzer alles basteln und programmieren: http://www.fhz-forum.de/

Vielen Dank, wenn man weiß, dass sie "Phoenix" heißen, findet man sie leicht. Leider sind sie so exotisch, dass auch Conrad nur auf Bestellung liefert.

Bestellen heißt: Versandkosten plus Wartezeit. Conrad heißt (für mich): 20 min Fahrradfahren plus sofort haben.

Bei der Beschreibung des DC-Bricks vermisse ich Angaben, wie die Stecker (grün bzw. schwarz) heißen. Die Bauform ist mir unbekannt, und ich habe sie auch nicht bei Conrad gefunden. Am liebsten wäre mir eine Conrad-Bestellnummer.

DHL ist super. Die geben das Paket beim Nachbarn ab oder auch beim nächsten Kiosk. Jedenfalls muss ich nicht bis 18 Uhr die Post erreicht haben und da in einer langen Schlange stehen, der Kiosk ist bis spät in die Nacht und feiertags geöffnet.

Noch eine Idee: ein allgemeiner Steuerungs-Brick. Weil ich im Endeffekt weder ein Notebook noch einen externen Controller anschließen, geschweige denn irgendwelche Firmware verstehen und manipulieren möchte. Also ein Teil, auf dem man per USB ein Programm abspeichern kann, das z.B. Befehle enthält wie "wenn das Temperatur-Bricklet weniger als 15 Grad feststellt, schalte Ausgang 1 des IO4-Bricklets auf 1, anderenfalls auf 0." Dann zieht man das USB-Kabel ab, drückt auf den Start-Knopf, und das Paket läuft allein.

Idee Nr. 1: Richtungsanzeiger auf dem Boot. Problem: je nach Wetter ist ein Bildschirm mühsam oder gar nicht ablesbar. Selbst schon erlebt: GPS-Gerät in Plastiktüte verpackt, alles wegen angetrockneter Salzwasserspritzer praktisch undurchsichtig, aber wegen stressigem Wetter absolut keine Zeit, das Ding sauber zu machen... und als ich endlich Zeit hatte, war ich schon einen Kilometer in die falsche Richtung gesegelt und musste zurück. Also: ein Zeiger auf einem Motor zeigt immer in die Richtung, wo der nächste Zielpunkt ist. Selbst bei grellem Sonnenlicht gut zu erkennen. 2. Idee: eine Uhr (Uhrzeit kommt ebenfalls via GPS), die immer weiß, wo sie ist, und die dementsprechend die korrekte Zeitzone benutzt.

Korrekt erkannt, das Ding regelt sich selbst. Ebenso korrekt ist die Sache mit der Abweichung. Ich gehe davon aus, dass die interne Stabilisierung der Kamera diesen Rest ausgleicht.

Mein Beitrag von gestern scheint weg zu sein, also noch mal: Ich fände einen IR-Empfänger nützlich. Er müsste natürlich lernfähig sein, sodass man ihn für eine beliebige preiswerte Universal-Fernbedienung einrichten kann.

Aus Schlumpfhausen, bitte sehr Aus Offenbach. Und nach Norddeutschland zu fahren kann wirklich preiswert sein, wenn man die Bahntickets ein paar Wochen vorher im Internet bucht.

Ich würde generell eine einfach und schnell zu lernende Sprache bevorzugen. Eine solche ist BASIC. Da brauche ich nicht zu wissen, was Klassen und Methoden sind. BASIC ist universell und überall: - in der C-Control von Conrad - im CHDK-Tool für Canon-Kameras - in der Homematic Haussteuerung (objektorientiertes BASIC) PRINT "Hello World!" ist eine einzige Zeile. Keine Bibliotheken zu laden, keine Module zu definieren. Einfacher geht's nicht.

Nein, der Grund ist, dass die Haftreibung immer größer ist als die Gleitreibung. Außer man benutzt Kugellager.

Mit dem DC kannst du einen Motor langsam und schnell vorwärts und rückwärts laufen lassen. Der IMU liefert einen Winkel, und dieser Winkel ergibt direkt die Geschwindigkeit, mit der der Motor den IMU verdrehen soll. Sobald der IMU waagerecht gedreht ist, wird der Motor ruhig gestellt. Voraussetzung ist wie gesagt, dass der Motor die Kamera UND den IMU bewegt, sodass der IMU ständig über den "Erfolg" der Drehung informiert ist.

Da ich bereits zwei Getriebemotoren für 12 Volt von Conrad besitze, ist es ziemlich uninteressant für mich, noch mal zwei kräftige Servos zu kaufen. Zumal Servos mit geringerer Spannung laufen und somit für die gleiche Leistung einen höheren Strom ziehen. Ich vermute, die Lösung für Motoren ist einfacher, weil die Aufgabe nur lautet "bewege den Motor, falls nötig" und der Nullpunkt ergibt sich von selbst. Bei einem Servor muss man vermutlich die Steuerung noch eichen: der Drehwinkel wird durch die Länge eines Impulses geregelt, aber es ist (falls ich mich nicht irre) außer der Nullstellung nicht genormt, welche Impulslänge welchem Drehwinkel entspricht. Die Steuerung muss in der Tat sehr schnell sein (die Idee, eine Webcam zu benutzen, den Horizont per Software zu finden und dementsprechend das Ganze auszurichten, habe ich deshalb nicht lange verfolgt), und es wäre schon klasse, wenn man das direkt in den Bricks programmieren könnte.

Nur theoretisch. M.W. funktioniert Steadycam allein durch Massenträgheit, und dazu gehört, dass die Kamera 100%ig austariert ist, d.h. der Schwerpunkt muss genau im Drehpunkt des Kardangelenks sitzen. Ungenauigkeiten plus Reibung führen dazu, dass die Kamera sich doch verdreht. Für eine halbe Minute Kamerafahrt mag das egal sein, aber wenn man die Kamera auf dem Segelboot montieren und 10 Minuten laufen lassen möchte, dann ist das wohl kaum eine praktikable Lösung. Ich beschäftige mich mit diesem Thema seit drei Jahren (und habe ehrlich gesagt wenig Lust, alle Für und Wider zu diskutieren, die für mich schon seit langem abgehakt sind) und ich bin überzeugt, dass die Gyro-Lösung die beste ist. Die einzige Frage ist die Realisierung: A - IMU bei der Kamera mit DC-Bricks und einfache Motoren (die ich bereits besitze), die die IMU waagerecht drehen B - IMU unten im Boot registriert nur die Winkel und gibt sie über Servo-Bricks an Servos weiter, die genau die selben Winkel einstellen und somit die Kamera waagerecht drehen

Die Mechanik ist schon seit zwei Jahren fertig. Damals hatte ich versucht, mit Hilfe von Fotozellen den Horizont anzupeilen. Zu hell = Himmel = runter drehen, zu dunkel = Wasser = hoch drehen. War aber nicht praxistauglich, weil: je höher über dem Horizont, desto dunkeler wird der Himmel, je tiefer unter dem Horizont, desto heller wird das Wasser, das ist kontraproduktiv. Ich muss eigentlich nur die alte Steuerelektronik entfernen, die Bricks anschließen und fertig.

Ich denke, eine gewisse Verzögerung ist tolerierbar, weil die Kamera ja das Bild auch noch sebst stabilisiert. Und das Abbremsen kommt von allein, die Drehzahl der Motoren soll von der Größe des Winkels abhängen.

Nee, vergiss es, alles schon selbst ausprobiert. Jede Bewegung des Bootes bringt das Pendel zum Ausschlagen.

Offenbar habe ich hier das gefunden, was ich benötige, um eine Videokamera in einem schaukelnden Segelboot immer waagerecht auszurichten: ein IMU Brick, der die Bewegungen registriert, und zwei DC Bricks, die die Motoren der Mechanik entsprechend ansteuern. Allerdings wird mir schlecht, wenn ich die Formeln unter "What is this sourcery" anschaue. Ich hoffe, ich komme bei diesem Projekt ohne allzu viel Mathematik aus. Dazu müsste ich die Bricks mit auf die bewegliche Plattform montieren, auf der die Kamera befestigt ist, und die Motoren müssten sich einfach nur so lange drehen, bis alle Winkel auf Null stehen. Sehe ich das alles so richtig?