Plenz

Vielen Dank für diesen Link, den werde ich mal weiterleiten.

Danke für die Antwort. Was ich nicht verstehe, ist die Sache mit der Genauigkeit. Wenn ich das Ding eine Stunde lang laufen lasse, muss sich ein Drehwinkel von 15° ergeben, während die Fehler, die ja positiv und negativ auftreten, sich eigentlich weitgehend kompensieren sollten, und letztendlich wäre es mir auch egal, ob dann 14° oder 16° herauskommen. Oder ist das zu einfach gedacht? (Ich habe leider auch nur die alte IMU Version 1.1)

Ich habe jetzt gelesen, dass man die Erdrotation mit einer IMU nur dann nachweisen kann, wenn die Bias-Fehler ausreichend gering sind. Bei den technischen Daten der Tinkerforge-IMUs steht nichts von Bias. Wären sie für einen Nachweis der Erdrotation geeignet oder nicht?

Der Anlass meiner Frage ist zugegebenermaßen etwas "skurril". Auf der Seite www.rolf-keppler.de wird behauptet, dass wir im Inneren einer Hohlwelt leben. Nun ist Herr Keppler auf die Idee gekommen, dass man mit einer IMU die Erdrotation nachweisen könnte. Wenn man nach Osten schaut und die IMU immer so hält, dass sie sich nicht bewegt, dann müsste man sie in Bezug auf den östlichen Horizont auf einer Vollkugel immer höher drehen und in einer Hohlkugel immer tiefer. Da ich ein Tinkerforge-IMU-Brick besitze, dachte ich, ich könnte beim Nachweis der Vollkugel behilflich sein. Aber ist ein IMU-Brick dafür überhaupt geeignet? Könnte es sein, dass ein IMU-Brick anhand der anderen Sensoren feststellt, wo Norden und wo das Zentrum der Erde ist, und dass es mit Hilfe dieser Daten die Erdrotation aus den IMU-Daten heraus rechnet?

Sehr interessant, offensichtlich wurde also Korrekturbedarf festgestellt, weil ich nicht der einzige mit diesem Problem war, stimmt's? Warum hatten die früheren Versionen keine Kalibriermöglichkeit? Wurde der Bedarf für das Kalibrieren unterschätzt, weil die ersten Chips zufällig nur tolerierbare Abweichungen hatten?

Mein AnalogIn misst deutlich zu wenig (getestet mit mehreren Digitalmultimetern): 7840 bei 8 Volt 9830 bei 10 Volt 11760 bei 12 Volt Lässt sich das irgendwie kalibrieren, oder kann ich nur nachträgliche Korrekturen einrechnen?

Danke für die Antwort. Nein, die UID war schon korrekt, das Programm lief ja bereits auf einem schnelleren Notebook unter Win10. Was mich wundert: dass dieser Fehler bei dem Befehl getVoltage() auftrat und nicht schon früher, denn vorher wird noch ein IO20 initialisiert. Seltsamerweise funktioniert es jetzt plötzlich auch auf dem langsamen Notebook ohne Änderung der Timeout-Zeit. Allerdings gab es falsche Messungen. Erst nach Verdoppeln einer Wartezeit wurden korrekte Werte gemessen. Zur Erklärung: ich will die Spannungen von Akkus messen, während ich sie entlade, um die Kapazität zu berechnen. Die Pluspole der Akkus werden nacheinander über CD4066 an den Messeingang gelegt, dann wird kurz gewartet (bisher 25 ms, jetzt 50 ms) und dann gemessen. Naja, nur für die Chronik, die Sache funktioniert jedenfalls jetzt.

Ich programmiere den Analog IN 2.0 unter VB. Weil ich mein Projekt längere Zeit laufen lassen möchte, ohne meine aktuelle Hardware zu belegen, habe ich dafür ein altes verstaubtes Notebook mit WinXP wieder ausgegraben. Leider ist es extrem langsam, und beim Auslesen der Spannung erscheint "TimeoutException wurde nicht behandelt". Kann ich das irgendwie mit SetResponseExpected() übergehen?

Ich habe mir gestern den Analog IN 2.0 gekauft und mit einer Mignonzelle ausprobiert. Zwei Digitalvoltmeter zeigen 1483 bzw. 1490 mV an, der Analog In misst jedoch 1410 mV. Diese Abweichung halte ich für inakzeptabel. In der Doku steht etwas von Kalibrieren, aber wenn ich das richtig verstehe, müsste ich dafür ein weiteres Bricklet kaufen, was natürlich nicht in Frage kommt, weil ich dieses in absehrbarer Zeit einfach nicht benötige. Gibt es keine andere Methode der Kalibrierung? Kann man vielleicht irgendwie irgendwelche Kalibrierungswerte manuell eingeben? Oder bleibt mir nichts anderes übrig, als ein paar Vergleichsmessungen zu machen und den gemessenen Wert per Software auf den korrekten Wert umzurechnen?

Nach einer Fußoperation muss ich Spritzen gegen Thrombose bekommen. Da ich nicht in der Lage bin, mir selbst Spritzen zu geben, habe ich eine Maschine gebaut, die das erledigt. So schaffe ich das: Knopf drücken, wegschauen, abwarten, über mich ergehen lassen, fertig. Womit steuere ich das Ding? Der Motor muss langsam vorwärts und schnell rückwärts drehen, außerdem müssen der Startknopf und zwei Mikroschalter abgefragt werden. Natürlich zu minimalen Kosten. Meine Wahl fiel auf den OLIMEXINO-85, er ist eigenständig, direkt zu programmieren, preiswert, klein und hat genau so viele Ein- und Ausgänge, wie ich brauchte. Hier ein kurzes

So, liebe Leute... hiermit erkläre ich dieses Projekt für beendet. Die Ergebnisse waren unbefriedigend, und das bei einem zu großen Aufwand, denn es gehört ja immer noch ein Notebook dazu, das die Bricks und Bricklets steuert. Inzwischen stellte ich fest, dass ich dabei war, das Rad zum zweiten Mal zu erfinden. In der Quadrokopter-Szene gibt es längst fertige und hochentwickelte Controller für eben diese Aufgabe. Es gibt sogar Controller mit zwei IMUs, und die Steuerbausteine für Brushlessmotoren sind auch gleich dabei. Das Notebook braucht man nur noch einmalig zum Einrichten und Kalibrieren. Auf dieser Seite habe ich eine (englische) Beschreibung und ein Demo-Video.

Interessante Artikel - scheitert nur leider an meinen Mathe-Kenntnissen. Allein wenn ich die Formel-Ungetüme bei der Beschreibung des IMU-Bricks sehe, kommt mir das kalte Grausen. Und obendrein ist es auch ziemlich demotivierend für mich zu sehen, dass andere Leute genau das selbe machen wie ich und davon auch noch mehr verstehen als ich. Siehe im Link von Novae das Bild mit der Bezeichnung "Sideslip", genau das ist mein Anliegen.

So, inzwischen funktioniert die Sache. Leider nicht so, wie ich mir das gewünscht hätte. Der IMU-Kompass zittert reichlich, aber am unzuverlässigsten scheint das GPS-Bricklet zu sein. Dem Richtungswinkel kann man wohl nur bei hohem Geschwindigkeiten trauen, wenn die tatsächliche Fortbewegung ganz erheblich deutlicher ist als die Abweichung. Übrigens: die paar Euro für eine Stützbatterie für das GPS-Bricklet sind eine sehr empfehlenswerte Investition, damit fixt das Ding in Sekundenschnelle!

Heute kam endlich das heiß ersehnte GPS-Bricklet. Eigentlich war es schon für Samstag angekündigt, aber Die Hoffnungslos Lahmen hatten es aus unerklärlichen Gründen nicht geschafft. Also habe ich am Wochenende mein Programm erst mal mit Fantasiewerten geschrieben und getestet. Und nun, wo ich es endlich real testen könnte, regnet es in Strömen

Ich möchte mir einen Kompass bauen... und gerade ist mein Blick auf die dicke Drosselspule im USB-Kabel gefallen, und da dachte ich, wie es sich wohl mit solchen Gegenständen aus Eisen/Stahl verhält: die Drosselspule, die Schrauben, die USB-Buchse - beeinflussen die nicht alle den Magnetsensor des IMU-Bricks?

Ja, das wird wohl so sein mit der Kompassfunktion. Ich zweifelte daran, weil ich mir nicht vorstellen konnte, dass dieses Ding von Garmin immer wieder justiert und kalibriert werden muss. Aber inzwischen ist mir eingefallen, dass auf einem Schiff selbstverständlich ein Kreiselkompass existiert, dessen Ausrichtung wahrscheinlich auf das Navigationsgerät übertragen wird. Mit dem IMU-Brick und dessen magnetischen Kompass hat man dann wohl doch die zu erwartenden Probleme mit Ausrichtung, Missweisungen etc.

Auf einem Segelschiff habe ich ein Gerät von Garmin gesehen, das zeigt auf einem Bildschirm die tatsächliche Bewegungsrichtung an, das heißt, man sieht, wie stark das Schiff infolge von seitlichem Wind abtreibt. Wie kann ich so etwas mit TF-Bausteinen realisieren? Das GPS-Bricklet gibt ja nur die Bewegungsrichtung relativ zur Nordrichtung an. Zusätzlich müsste es nun auch noch wissen, in welche Richtung es selbst ausgerichtet ist. Gibt es außer der Kompaßfunktion des IMU-Bricks noch andere Möglichkeiten?

Viel zu kompliziert. Ich denke gar nicht an eine Dekodierung, wo am Ende rauskommt, welche Funktion bei welchem Gerät gesteuert werden sollte. Mir würde es völlig genügen, wenn ich eine Kette von Impulslängen bekäme. Der Empfänger müsste nur in der Lage sein, den Start einer Impulskette zu erkennen und anschließend die Längen zu messen: 10000µs high (Startimpuls), 600µs low, 1200µs high, 600µs low... und mein eigenes Auswertprogramm muss dann schauen, was es mit all den Zahlen anfängt.

Wir haben hier eine kleine Anleitung: http://www.tinkerforge.com/de/doc/Embedded/Raspberry_Pi.html Ich sehe, da war ich auf einem völlig falschen Dampfer. Ich hatte die Vorstellung, der RPi könnte Bricks direkt über die IO-Ports ansteuern. Was hier beschrieben wird, zeigt ja nur, wie man am anderen Ende des USB-Kabels einen RPi anschließt anstelle eines Notebooks. Ich habe keine Vorstellung, wie lange es dauert, bis ein Signal von einem Bricklet durch eine lange Kette von Subroutinen gelaufen, in ein serielles Signal verwandelt, durchs Kabel geschickt, beim angeschlossenen Computer zwischen den Treibern herumgereicht ist und schließlich einen Interrupt ausgelöst hat, was dieser Computer noch alles für wichtiger hält, bevor er diesen Interrupt abarbeitet und wann das Signal endlich von meiner Steuersoftware verarbeitet wird. Aber wenn ich sehe, wann eine Handbewegung vor einer Webcam auf dem Bildschirm zu sehen ist oder wann ich einen Ton höre, wenn ein Microfon an eine USB-Soundbox angeschlossen ist, dann liegt die Verzögerung im dreistelligen Millisekundenbereich. Dieser langen Weg wäre bei einer OnDevice-Lösung stark verkürzt, und ich hatte bei einer Steuerung durch einen RPi die Vorstellung für eine ähnlich straffe Signalverarbeitung.

Ich würde gern einen Brickstapel per IR-Fernbedienung steuern können (ganz besonders im Hinblick auf zukünftige Standalone-Lösungen). Das gewünschte Empfänger-Bricklet müsste billige Universalfernbedienungen unterstützen und bräuchte eigentlich weiter nichts zu können, als ein ankommendes IR-Signal zu dekodieren und die dabei jeweils erkannte Folge von "Nullen" und "Einsen" z.B. als Zeichenkette zum Auslesen zur Verfügung zu stellen. Es bleibt dann dem Anwender überlassen, die verschiedenen Zeichenketten auseinanderzuhalten und darauf zu reagieren.

Unterschätz bitte nicht die HomeMatic. Da steckt eine Menge Knowhow drin, damit die Zentrale mehrere Wandthermostate und diese wiederum mehrere Heizkörperventile steuern kann, ohne sich gegenseitig zu stören und ohne von außen gestört zu werden. Ich möchte allein schon bezweifeln, dass du es jemals herausfindest, mit welchen Signalen du so ein Ventil abfragen und ansteuern kannst. Kauf dir lieber ein komplettes System. Ich weiß, das ist eine Menge Geld (ich hab schließlich selbst eine), aber du bekommst eine ausgereifte Lösung mit Möglichkeiten, an die du wahrscheinlich heute noch gar nicht denkst. Und das sage ich, obwohl ich selbst auch gern mal was selbst bastele, weil's Spaß macht und Geld spart.

Ich warte schon lange sehnsüchtig auf eine Standalone-Lösung, aber was in dieser Umfrage vorgestellt wird, ist für mich mit Kanonen auf Spatzen geschossen. Ich habe schon so komplizierte Sachen wie die Auswertung eines GPS-Empfängers und Ausgabe der Ergebnisse auf einer LCD-Anzeige und Simulation eines Funkuhr-Zeitsignals auf einer simplen C-Control realisiert - alles ohne Linux, HDMI, Ethernet etc. Und für meine TF-Sachen brauche ich auch nicht mehr: Messwerte von Brick(let)s auslesen, verarbeiten, andere Brick(let)s ansteuern. Und diese Aufgabe würde ich gern von meinem Notebook in den Brickstapel verlagern, damit alles kompakter ist, weniger Strom braucht und vor allem damit der Mess- und Steuervorgang viel öfter pro Sekunde wiederholt werden kann, als es USB erlaubt. Optimalerweise hätte ich gern eine Software, mit der ich solche Aufgaben lösen kann, ohne dass ich mich lange in die Firmware der Einzelteile einarbeiten muss. Das resultierende Programm wird in einen Brick geschrieben, und fertig - so wie bei der C-Control. Als nächstes würde ich den RPi ins Auge fassen, eben wegen des günstigen Preises. Ich habe hier erwähnt gesehen, dass man damit Brick(let)s ansteuern könnte - ist das irgendwo genauer dokumentiert? Als letztes käme dann die Variante mit 99 Euro in Frage, aber eigentlich würde mir auch diese schon echt weh tun, da müsste ich mich fragen, was rechtfertigt diesen Preis? Doppelte Geschwindigkeit gegenüber dem RPi? Das wäre für mich kein Argument. Die Vergleichsbasis ist für mich USB: z.B. beim IO-16 maximal 400 Abfragen pro Sekunde und ganz besonders all die Verzögerungen, bis so eine Abfrage vom Notebook registriert, ausgewertet und beantwortet wurde. Wie schnell würde das mit einem RPi gehen, und wäre das nicht bereits so unglaublich schnell, dass eine doppelte Geschwindigkeit keine spürbare Verbesserung mehr wäre?

Sorry, die Anfrage war wohl ein Schnellschuss. Alle beschriebenen Phänomene lassen sich einfach durch Reduzierung des Wertes "Convergence Speed" auf 10 deutlich verbessern.

Nach längerer Abstinenz habe ich mal wieder mein Projekt "Kamerastabilisierung" angepackt, über das ich im Mai unter "Projektvorstellungen" berichtet hatte. Was ich bisher erreicht hatte, befriedigt mich noch nicht wirklich. Um die Sache zu vereinfachen, habe ich das Gerät stark verkleinert und vereinfacht, und zwar nicht für meine Videocamera, sondern für meine kleine Powershot, die macht nämlich auch recht gute Videos. An sich funktioniert der Stabilisator wie gehabt, aber drei Dinge finde ich verbesserungswürdig: 1.) Das Ding vibriert ständig, weil der IMU-Brick auch bei völliger Ruhe minimale Bewegungsänderungen ausgibt 2.) Bei abrupten Bewegungen gibt der IMU-Brick immer noch ein kurzes Nachschwingen aus 3.) Schnelles Drehen um die Z-Achse (yaw) erzeugt immer ein zusätzliches kurzes Schwingen um die übrigen Achsen (typisch Kreisel) Hat schon mal jemand versucht, diese Kreiseleffekte zu neutralisieren?

Win7 auf dem PC (wegen diverser Multimedia-Killerapplikationen) WinXP auf dem Notebook (läuft gut, warum dann noch 'ne Lizenz kaufen?) Debian auf dem gemieteten Server