Jump to content

Plenz

Members
  • Content Count

    175
  • Joined

  • Last visited

Community Reputation

0 Neutral
  1. 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?
  2. 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?
  3. 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.
  4. 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?
  5. 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?
  6. 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
  7. 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.
  8. 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.
  9. 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!
  10. 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
  11. 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?
  12. 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.
  13. 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?
  14. 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.
  15. 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.
×
×
  • Create New...