Plenz

Darf ich mal kurz daran erinnern, dass du gerade das Rad zum zweiten Mal erfinden möchtest. Die Grundlagen existieren seit der Zeit der Akustikkoppler und wurden auch verwendet, um Daten auf Cassettenrecorder zu speichern. 1.) nicht morsen, sondern ganz einfach ASCII übertragen. 2.) nicht lang/kurz übertragen, sondern Serielle Datenübertragung 3.) Zur Sicherheit ein Paritätsbit mitschicken und von der Gegenseite quittieren lassen 4.) Zur Technik der Datenübertragung siehe XModem. Protokolle, die die Pakete vergrößern, je weniger Fehler gemeldet werden, werden dort auch erwähnt.

Ich halte ihn für überflüssig. Es gibt einfache Piezo Buzzer, die selbst einen Ton erzeugen und mit 3 Volt bei 5 mA laufen, z.B. Conrad Nr. 752223 oder 710009. Die kann man sicherlich direkt an ein IO4 anschließen.

Nö, das Singen entsteht einfach dadurch, dass der Motor mit einer hörbaren Frequenz gespeist wird. Er arbeitet praktisch nebenbei wie ein Lautsprecher, das ist alles. Klar, irgendwo gibt es auch Resonanzfrequenzen, vielleicht vibriert der Motor dann fühlbar und/oder das Singen wird lauter. Diese Frequenzen sollte man vermeiden, aber dadurch verschwindet das Singen nicht. Also keine Bange, einfach mal ausprobieren, ob der Motor so besser läuft.

Logisch. Ich hätte mich nie getraut, das auch nur auszuprobieren. 20mA sind ganz schön viel für so einen Schaltkreis. Auf einem der Fotos ist eine LED über einen 1 kOhm-Widerstand verbunden, der begrenzt den Strom auf max. 3 mA, und das tut er sicherlich nicht um die LED zu schonen! Ja, der IO4-Bricklet sollte wirklich erweitert werden. Und zwar auf 40 x 40 mm, und der zusätzliche Streifen von 10 mm sollte mit einem einfach Lötpunkte-Lochraster aufgefüllt werden. Und jeder der 4 Ein/Ausgänge sollte über einen 1-kOhm-Widerstand (SMD) mit einem Lötpunkt verbunden sein. Das behindert nicht die Funktion als Eingang, und Transistoren kann man bei Bedarf selbst hinzulöten.

Dein Schaltbild sieht im Prinzip schon mal gut aus, so würde ich das auch machen. Die Transistoren sind wirklich egal, wähle einfach die billigsten, die es gibt, und dann kontrolliere, ob sie die nötigen Stromstärke vertragen. Zu den Widerständen: 170 Ohm gibt es nicht, aber 180 Ohm gibt es. So genau muss man den maximalen Strom der LED auch nicht ausreizen, das bringt nichts. Wegen der Relais: die elektronischen Lastrelais (also Triac mit Optokoppler) würde ich wirklich nur zum Schalten von 230 Volt Wechselspannung benutzen, dafür sind sie hergestellt. Keine Ahnung, ob sie Spannungen von wenigen Volt überhaupt schalten. Und wenn, dann kannst du sie nicht mehr ausschalten, denn ein Triac hält seinen Schaltzustand selbst und wird nur dadurch ausgeschaltet, dass der geschaltete Strom selber auf Null geht, was bei Wechselspannung ja 50 mal pro Sekunde geschieht, bei Gleichspannung aber gar nicht!

Über einen billigen NPN-Transistor. Basis über einen 1 kOhm-Widerstand am IO anschließen, Emitter auf Minus, Collector an die LED-Reihe. Das andere Ende der LED-Reihe an die Plus 12 Volt. Die Spannung muss aber haargenau an die Bedürfnisse der LEDs angepasst sein, sonst gehen sie kaputt oder leuchten zu schwach.

Von dem SSR würde ich Abstand nehmen, da die technischen Daten nicht bekannt sind, zumindest nicht der Steuerstrom, den das Ding zieht, wenn es eingeschaltet sein soll. Achja, da gibt es noch ein PDF, hast du das angeschaut? SSR bedeutet "schmales Steckrelais", es hat eine Magnetspule! Abgesehen davon würde ich für solche einfachen Steuersachen immer ein IO-Bricklet benutzen. Am Ausgang ein 1 kOhm-Widerstand und ein billiger NPN-Transistor, und damit kannst du schon reichlich LEDs schalten.

Experimentiere mal ein bisschen mit dem Brick-Viewer und verschiedenen Impulsfrequenzen. Ich habe die Erfahrung gemacht, dass meine Motoren viel besser reagieren und sich auch sehr langsam drehen können, wenn ich die Impulsfrequenz auf 500 Hz senke. Klar, bei dieser Frequenz geben die Motoren ein hörbares Singen ab, aber das kann man in Kauf nehmen.

Am Wochenende habe ich ein komplett neues Gerät gebaut, diesmal mit Servos. Es funktioniert auch schon im Prinzip, aber die Umrechnung von Winkeln aus dem IMU-Brick in Impulse für die Servos (wie an anderer Stelle erwähnt, "missbrauche" ich dafür meine DC-Bricks) lässt noch zu wünschen übrig. Beim Experimentieren und Justieren stellte ich fest, dass der eine Servo sehr heiß geworden war - und anscheinend hat das Getriebe eine Macke abgekriegt. Also muss ich das Projekt erst mal auf Eis legen, bis ich einen neuen Servo habe. Hier ein aktuelles Bild:

Nur mal so nebenbei: wer eine Canon Powershot hat, kann solche und andere Dinge mit Hilfe des Canon Hacker Development Kit (CHDK) erledigen - ganz ohne irgend einen Hardware-Aufwand.

Hier mal zwei leider nicht ganz scharfe Detailfotos.

Für meine Frage nach einer achsialen Verbindung wäre das eine mögliche Antwort, aber eigentlich suchte ich etwas mit einer Riffelung, was auf das Zahlrad eines Servos passt. Das Thema ist aber inzwischen für mich "gestorben", weil ich mir Lösungen ausgedacht habe. Und zwar bewege ich nicht die Achse, sondern ganz direkt die Teile, die auf der Achse montiert sind. Konkret: Achsiale Verbindung: das Servokreuz wird einfach mit dem zu verdrehenden Teil direkt verschraubt. Parallele Verbindung: die Löcher im Servokreuz werden mit den mitgelieferten Schrauben versehen. Das zu verdrehende Teil bekommt Löcher und feststehende Schrauben M3 im selben Abstand wie die Schrauben im Servokreuz. Auf allen Schrauben sind Stellringe (Conrad Nr. 225401) gesteckt. Anstelle der Madenschrauben befinden sich Schubstangen ø3 mm (Conrad Nr. 225452). Die Schubstangen sind auf die passende Länge verkürzt und miteinander verlötet. Ich weiß nicht, wie lange ich im Conrad-Katalog vergeblich gesucht habe, und dann habe ich bestimmt noch eine Viertelstunde vor dem Regal gehockt und geschaut und gegrübelt, bis mir die Idee mit den Stellringen kam. Funktioniert jedenfalls einwandfrei.

In my opinion, a really good watchdog should only work from outside the system. A simple relay could do it if you connect its switch to one input pin of the IO16 bricklet. Switch the relay on/off and check from the input pin if it is really switched on/off. Repeat this after some seconds/minutes.

Mal eine allgemeine Modellbaufrage: Ich möchte die Drehbewegung eines Servos auf eine einfache Achse (z.B. ø8 mm Messingrohr) übertragen. Wie machen ich das am besten? Servos haben ein geriffeltes Rad, auf das kann man einen Hebelarm oder ein Rad stecken, und damit kann man Gestänge bewegen. Für Achsen gibt es z.B. Zahnräder, die man mit einer Madenschraube befestigen kann. Das alles passt nicht zusammen. Ich habe noch keine Hebelarme gesehen, die man auf eine Achse stecken kann, und ich habe auch noch keine Zahnräder gesehen, die man auf einen Servo stecken kann. Auch für eine direkte achsiale Verbindung zwischen Servo und Achse scheint es nichts zu geben. Welche gängigen Lösungen gibt es für dieses Problem? Am liebsten wären mir Teile, die ich morgen abend direkt bei Conrad oder einem Modellbauladen in Frankfurt mitnehmen kann.

Steht sowieso nicht in der Doku, aber du kannst es mit dem Brick Viewer ausprobieren: da kannst du einstellen, was du willst - ohne zu warten. Insbesondere wenn du eine niedrige Beschleunigung eingestellt hast, dann passiert ja auch nichts anderes als eine kontinuierliche Änderung der Geschwindigkeit.

Hier ein kleines Programm, das Pitch, Roll und Yaw graphisch darstellt, natürlich mit den neuen Formeln, die die Winkel unabhängig voneinander machen. Man kann wählen, welche Seite des IMU-Bricks "vorn" ist. #!/usr/bin/env python # -*- coding: utf-8 -*- # # IMU demo by Plenz 12.06.2012 - public domain from Tkinter import * from tinkerforge.ip_connection import IPConnection from tinkerforge.brick_imu import IMU import math import time import threading class TF: HOST = "localhost" PORT = 4223 UID_IMU = "9yEBJGvcxtQ" # IMU Brick def __init__(self): self.base_x = 0.0 self.base_y = 0.0 self.base_z = 0.0 self.base_w = 0.0 self.imu = IMU(self.UID_IMU) # Create device object self.ipcon = IPConnection(self.HOST, self.PORT) # Create IPconnection to brickd self.ipcon.add_device(self.imu) # Add device to IP connection self.imu.set_convergence_speed(30) # Wait for IMU to settle print 'Set IMU to base position and wait for 10 seconds' print 'Base position will be 0 for all angles' time.sleep(10) self.set_base_coordinates() self.imu.set_quaternion_period(200) def quaternion_cb(self, x, y, z, w): # Use conjugate of quaternion to rotate coordinates according to base system x, y, z, w = self.make_relative_coordinates(-x, -y, -z, w) pi = math.atan2(2.0*(y*z - w*x), 1.0 - 2.0*(x*x + y*y)) ro = math.atan2(2.0*(x*z + w*y), 1.0 - 2.0*(x*x + y*y)) ya = math.atan2(2.0*(x*y + w*z), 1.0 - 2.0*(x*x + z*z)) di = app.dir.get() if di == 0: pi = -pi if di == 1: pi, ro = -ro, -pi if di == 2: ro = -ro if di == 3: pi, ro = ro, pi self.pi = pi self.ro = ro self.ya = ya def set_base_coordinates(self): q = self.imu.get_quaternion() self.base_x = q.x self.base_y = q.y self.base_z = q.z self.base_w = q.w def make_relative_coordinates(self, x, y, z, w): # Multiply base quaternion with current quaternion return ( w * self.base_x + x * self.base_w + y * self.base_z - z * self.base_y, w * self.base_y - x * self.base_z + y * self.base_w + z * self.base_x, w * self.base_z + x * self.base_y - y * self.base_x + z * self.base_w, w * self.base_w - x * self.base_x - y * self.base_y - z * self.base_z ) class App: def __init__(self, master): root.geometry("200x300+30+30") frame = Frame(master) frame.place(x=1, y=1, width=199, height=299) self.button = Button(frame, text="Reset", command=tf.set_base_coordinates) self.button.place(x=5, y=5, width=90, height=25) self.button = Button(frame, text="QUIT", command=self.ende) self.button.place(x=102, y=5, width=90, height=25) self.message_pit = Label(frame, width=10, text="pitch") self.message_pit.place(x=13, y=35, width=50, height=20) self.message_rol = Label(frame, width=10, text="roll") self.message_rol.place(x=73, y=35, width=50, height=20) self.message_yaw = Label(frame, width=10, text="yaw") self.message_yaw.place(x=133, y=35, width=50, height=20) self.rpy_canvas = Canvas(frame, width=190, height=64, relief=SUNKEN, borderwidth=1) self.rpy_canvas.place(x=3, y=55, width=190, height=70) self.message_dir = Label(frame, width=10, text="Direction:") self.message_dir.place(x=75, y=130, width=50, height=20) self.imu_canvas = Canvas(frame, width=100, height=100, relief=SUNKEN, borderwidth=1) self.imu_canvas.place(x=50, y=170, width=100, height=100) self.imu_canvas.create_rectangle(0, 0, 100, 100, fill="#333333") self.imu_canvas.create_rectangle(0, 30, 15, 70, fill="#EEEEEE") self.imu_canvas.create_rectangle(85, 30, 100, 70, fill="#EEEEEE") self.imu_canvas.create_rectangle(40, 75, 60, 100, fill="#CCCCFF") self.imu_canvas.create_oval(20, 5, 44, 29, fill="#FFFFFF") self.imu_canvas.create_oval(27, 12, 37, 22, fill="#333333") self.imu_canvas.create_rectangle(54, 7, 62, 27, outline="#FFFFFF", width=2) self.imu_canvas.create_rectangle(54, 19, 74, 27, outline="#FFFFFF", width=2) self.dir = IntVar() self.dir1 = Radiobutton(frame, text="", variable=self.dir, value="0") self.dir1.place(x=90, y=150) self.dir2 = Radiobutton(frame, text="", variable=self.dir, value="1") self.dir2.place(x=155, y=210) self.dir3 = Radiobutton(frame, text="", variable=self.dir, value="2") self.dir3.place(x=90, y=275) self.dir4 = Radiobutton(frame, text="", variable=self.dir, value="3") self.dir4.place(x=25, y=210) self.dir1.select() def circ(self, nu, wi): rax = 10 ray = 9 ofx = 25 + rax ofy = 25 + ray ax = rax + nu * 60 ex = ax + 50 dr = math.pi * 30 /180 self.rpy_canvas.create_oval(ax, ray, ex, ray + 50, fill="yellow") ax = math.cos(wi) * -25 + nu * 60 + ofx ay = math.sin(wi) * 25 + ofy ex = math.cos(wi) * 25 + nu * 60 + ofx ey = math.sin(wi) * -25 + ofy if nu == 0: self.rpy_canvas.create_line(ax, ay, ex, ey, fill="red", width=4) bx = math.cos(wi + dr) * -15 + ofx by = math.sin(wi + dr) * 15 + ofy cx = math.cos(wi - dr) * -15 + ofx cy = math.sin(wi - dr) * 15 + ofy points = [ax, ay, bx, by, cx, cy] self.rpy_canvas.create_polygon(points, outline="red", fill="red") if nu == 1: cx = nu * 60 + ofx cy = ofy self.rpy_canvas.create_line(ax, ay, cx, cy, fill="red", width=4) self.rpy_canvas.create_line(cx, cy, ex, ey, fill="green", width=4) if nu == 2: self.rpy_canvas.create_line(ax, ay, ex, ey, fill="black", width=4) ax = math.sin(-wi) * -25 + nu * 60 + ofx ay = math.cos(-wi) * 25 + ofy ex = math.sin(-wi) * 25 + nu * 60 + ofx ey = math.cos(-wi) * -25 + ofy self.rpy_canvas.create_line(ax, ay, ex, ey, fill="red", width=4) bx = math.sin(-wi + dr) * -15 + ofx + nu * 60 by = math.cos(-wi + dr) * 15 + ofy cx = math.sin(-wi - dr) * -15 + ofx + nu * 60 cy = math.cos(-wi - dr) * 15 + ofy points = [ax, ay, bx, by, cx, cy] self.rpy_canvas.create_polygon(points, outline="red", fill="red") def ShowAngle(self): self.rpy_canvas.create_rectangle(0, 0, 190, 70, fill="#DDDDDD") pi = int(-tf.pi * 180 / math.pi + .5) ro = int(-tf.ro * 180 / math.pi + .5) ya = int(tf.ya * 180 / math.pi + .5) self.message_pit.config(text = "pitch " + str(pi) + "°") self.message_rol.config(text = "roll " + str(ro) + "°") self.message_yaw.config(text = "yaw " + str(ya) + "°") ya = tf.ya if ya < math.pi: ya = ya + math.pi else: ya = ya - math.pi ya = -ya self.circ(0, tf.pi) self.circ(1, tf.ro) self.circ(2, ya) if tf.term == 0: # nicht mehr ausführen nach QUIT timer1 = threading.Timer(0.25, self.ShowAngle) timer1.start() else: tf.term = 2 # länger warten nach QUIT def ende(self): print " === waiting for callbacks..." tf.imu.set_quaternion_period(0) tf.term = 2 while tf.term > 1: tf.term = 1 time.sleep(0.5) tf.ipcon.destroy() print "IP destroyed." root.destroy() if __name__ == "__main__": tf = TF() root = Tk() app = App(root) root.title(" IMU Viewer by Plenz") root.resizable(0,0) # Register quaternion callback tf.imu.register_callback(tf.imu.CALLBACK_QUATERNION, tf.quaternion_cb) tf.term = 0 timer1 = threading.Timer(0.25, app.ShowAngle) timer1.start() root.mainloop()

Meines Wissens sind Bilder nicht zu knacken, auf denen Hunde und Katzen zu sehen sind. Computer können nicht Hunde und Katzen voneinander unterscheiden. Die Software müsste eine gewisse Anzahl Bilder vorrätig haben, in denen mehrere Hunde verschiedener Rassen und mehrere Katzen zu sehen sind. Die Frage "wie viele Katzen siehst du?" kann nur ein Mensch beantworten.

Yepp, einen Nachmittag geproggt, und die Erkennung ist fertig. Es gibt etwa zwei Durchgänge "Einlesen - Analysieren" pro Sekunde. Das ist zwar nicht gerade viel, aber dafür besteht der ganze Hardwareaufwand nur aus Draht, zwei 3,5mm-Stecker, zwei Widerständen und einem Kondensator.

Ich hab's gerade getestet: man kann ohne weiteres einen digitalen Servo auch mit einem DC-Brick steuern! Dazu muss man die PWM-Frequenz auf 50 Hz setzen, eine hohe Beschleunigung ist ratsam. Je nach dem, an welchem der beiden Motoranschlüsse man die Steuerimpulse für den Servo abzapft, muss man eine positive oder negative Geschwindigkeit einstellen. Mein kleiner Test-Servo dreht sich bei einer eingestellten Geschwindigkeit von 1100 auf -90° und bei 4100 auf +90°. Das bedeutet, man kann den Servo theoretisch in 0,06°-Schritten einstellen. Genauer braucht man es wohl kaum. Damit kann ein DC-Brick durchaus einen Servo-Brick ersetzen, falls man nur einen Servo betreiben möchte.

Das sollte mein nächstes Projekt werden, aber ich habe es gerade begraben. Ich erwähne es hier, weil meine Erfahrungen vielleicht anderweitig Nutzen bringen können. Die Aufgabe ist, die Signale einer IR-Fernbedienung zu entschlüsseln. In meinem speziellen Fall geht es um eine preiswertes Funk-Übertragungssystem, das Fernbedienungssignale in ein Nebenzimmer übertragen kann. Der Empfänger hat einen Ausgang, dem ich das Signal entnehmen kann. Das heißt, ich brauche mich nicht mit einem IR-Empfänger und Elektronik herumzuschlagen. Ich hatte so etwas schon mal gemacht, und zwar mit einem älteren Notebook, das noch eine parallele Druckerschnittstelle hatte. Mit einem C-Programm lässt sich diese Schnittstelle schnell genug abfragen, um sämtliche Impulse einlesen und analysieren zu können. Nun aber gibt es nur noch USB. Und das IO4-Bricklett. Aber das erwies sich in meinen Versuchen als zu langsam (was auch an dem preiswerten Notebook liegen könnte). Ein Signal (es geht um eine Panasonic-Fernbedienung) ist 60 ms lang und wird von einer 70 ms langen Pause gefolgt. Es beginnt mit einem 3 ms langen Impuls und einer anschließenden Kette von Impulsen, die 0,5 ms lang sind und von einer 0,5 ms langen Pause gefolgt werden. Die Kodierung der verschiedenen Tasten entsteht durch das Weglassen von Impulsen, das heißt, die jeweilige Pause ist dort 1,5 ms lang. Jeder Impuls besteht aber seinerseits noch mal aus einer Reihe von kurzen Impulsen, die 20 us lang sind mit einer Pause von 10 us. Diese Pausen habe ich beseitigt, indem ich die Impulse mit einem Monoflop (1/2 CD 4528 mit 3,3 nF und 22 kOhm) verlängert habe. Ich habe dann ein kleines Python-Programm geschrieben, das Callbacks vom IO4-Brickletts annimmt. Dabei werden nur die Callbacks verarbeitet, bei denen der Eingang auf 1 liegt. Die Routine misst die Zeit, die zwischen zwei Callbacks vergeht. Es zeigte sich, dass die Callbacks sehr unregelmäßig verarbeitet werden. Mal wird eine Zeit gemessen, anschließend kommen mehrere Callbacks direkt hintereinander, also praktisch in Nullzeit. Ich habe dann ein weiteres Monoflop benutzt, um die 0,5 ms langen Impulse auf 1,5 ms zu verlängern. Dadurch werden die normalen Pausen von 0,5 ms überbrückt, und nur die mich interessierenden Pausen bleiben übrig. Das bedeutet erheblich weniger Callbacks. Aber auch die Zeit zwischen diesen ließ sich nicht zuverlässig messen. Zumindest unter Python auf meinem Notebook liefern die Funktionen time.time() und time.clock() nur Vielfache von etwa 15 ms, das heißt, ich kann nicht unterscheiden, ob zwischen zwei Callbacks 5 ms oder 10 ms vergehen. Und auch längere Zeiten sind nicht zuverlässig zu ermitteln, weil das Betriebssystem die aufgelaufenen Callbacks offensichtlich nach eigenem Ermessen abarbeitet, wenn es gerade Zeit und Lust dazu hat. Eine zuverlässige Entschlüsselung von Fernbedienungssignalen ist vermutlich nur durch ein Programm direkt im Brick zu bewerkstelligen. Inzwischen ist mir jedoch eine ganz andere Lösung eingefallen: ich schicke das Signal einfach in die Mikrofonbuchse des Notebooks, mache kurze Aufnahmen von 200 bis 300 ms und analysiere diese.

Tja... das ist einfach meine Erfahrung mit einem Forum, das ich betreibe. Kann aber auch daran liegen, dass ich eine uralte Software benutze, auf die gängige Bots nicht eingerichtet sind. Wenn ich den Russen von heute morgen sehe - der hat ja sogar ein Profil mit Bild eingerichtet. Gegen einen Bot, der so etwas leistet, hilft vermutlich wirklich nur ein Captcha.

Für meine Kamera-Stabilisierung habe ich 1 Master, 2 DC, 1 IMU und 1 IO4, die versorge ich allesamt über das USB-Kabel. Einen Power-Brick habe ich nicht. Die beiden DC bekommen jeweils 12 Volt direkt angeschlossen. Dafür benutze ich ein ausrangiertes Computer-Netzteil. Direkt an der Spannungsbuchse eines der DC-Bricks habe ich noch einen 2200uF-Elko angebracht, und eventuelle Lastspitzen abzufedern.

Das geht auch anders: jeder Besucher bekommt auf der Übersichtsseite ein Cookie verpasst (Gültigkeitsdauer für eine Sitzung), und nur wer das Cookie hat, darf schreiben. Mir ist jedenfalls bislang noch kein Bot untergekommen, der Cookies verarbeiten konnte.

Nun, wo der IMU-Brick dank der dafür notwendigen Formeln endlich die richtigen Verdrehungswinkel hergibt, ging es an die Praxis. Ich musste feststellen, dass die Getriebemotoren ziemlich träge sind. Dies besserte sich ganz erheblich, nachdem ich die Impulsfreuqenz des DC-Bricks schrittweise von 15.000 Hz auf 500 Hz gesenkt hatte. Klar, man hört jetzt ein ständiges Singen, aber dafür haben die Motoren jetzt richtig Power. Noch tiefer zu gehen hat allerdings wenig Nutzen, bei 200 Hz traten spürbare Vibrationen auf. Und trotzdem ist das alles immer noch viel zu langsam. Und wenn ich die Geschwindigkeit der Motoren erhöhe (also dass sie noch schneller und entschiedener auf Verdrehungen reagieren), dann fangen sie an, sich aufzuschaukeln. Und wenn ich dann bei Conrad sehe, dass es Servos gibt, die eine 45°-Drehung in 1/10 Sekunde schaffen (die kosten aber auch entsprechend), dann denke ich, ich sollte das alles noch mal völlig umstricken.

Ich darf dich korrigieren: das "ziemlich" kannst du streichen. Mit anderen Worten: JAAAA!!! ES FUNKTIONIERT!!! Ich habe keine Ahnung, wo der Fehler steckt(e), jedenfalls lag es an Zeile, in der das Programm auf den Tastendruck wartet. Wenn ich diese Zeile und ipcon.destroy() lösche, dann funktioniert das Programm. In meinem Programm benutze ich eine grafische Oberfläche mit QUIT-Button, der ipcon.destroy() auslöst, sowie eine Schleife root.mainloop(). Ich muss noch ergänzen: das Programm funktioniert so, wie ich will, das heißt, pitch und roll sind unabhängig von yaw. Umgekehrt wird jedoch yaw von pitch und roll beeinflusst. Das juckt mich zwar nicht, aber wer einen Kompass haben möchte, der dürfte immer noch ein Problem haben. Ich habe auch keine Ahnung, warum meine Excel-Tabellen ein anderes Ergebnis brachten, ich hatte alle Formeln und Funktionsweisen genau übernommen. Naja, Schwamm drüber. Und herzlichen Dank für deine Mühe! Wenn du schon einen halben Tag daran gebrütet hast, dann hätte ich das niemals im Leben auf die Reihe gekriegt...