borg Geschrieben August 13, 2012 at 13:59 Geschrieben August 13, 2012 at 13:59 Hallo zusammen, wir können uns bezüglich des Sensors für das zukünftige Barometer/Altimeter Bricklet nicht einig werden. Wir haben folgende zwei Sensoren in der Endauswahl: MS5611-01BA: Auflösung: 0,01mbar (bei Verwendung als Altimeter 10cm)Wird von Quadrocopter Projekte zur Höhenbestimmung genommen (http://code.google.com/p/arducopter/) allerdings in Verwendung mit Kalmanfilter und Beschleunigungssensor-WertenDatenblatt: http://www.meas-spec.com/downloads/ms5611-01ba01.pdfVerkaufspreis: 21,99€ MPL115A1: Auflösung: 0,1mbar (bei Verwendung als Altimeter 100cm)Sehr wahrscheinlich nicht als Altimeter für Flugdrohnen verwendbarDatenblatt: http://www.freescale.com/files/sensors/doc/data_sheet/MPL115A1.pdfVerkaufspreis: 9,99€ Was meint ihr? Wir würden Momentan Aufgrund von endlicher Zeit und endlichen finanziellen Mitteln nur eine der beiden Varianten machen können! Zitieren
jan Geschrieben August 13, 2012 at 14:28 Geschrieben August 13, 2012 at 14:28 Ich würde den mit 10cm bevorzugen. Vielleicht wäre eine Umfrage nicht schlecht, dann müsste man die Threads am Ende nicht zählen. Zitieren
kuli Geschrieben August 13, 2012 at 14:43 Geschrieben August 13, 2012 at 14:43 bin auch für die genauere version! .. sonst muss ich einen externen verwenden edit: möchte mich auch an einem quadcopter versuchen Zitieren
luxor Geschrieben August 13, 2012 at 14:57 Geschrieben August 13, 2012 at 14:57 Wäre auch für den MS5611-01BA. Ist der Verkaufspreis, euer Verkaufspreis oder der Verkaufspreis vom Sensor? Zitieren
batti Geschrieben August 13, 2012 at 15:19 Geschrieben August 13, 2012 at 15:19 Dies wäre unserer VK Preis. Wir haben uns gegen einen Poll entschieden, weil wir gerne auch eure Gründe dazu hören wollt. Zitieren
arminiusdc Geschrieben August 13, 2012 at 17:04 Geschrieben August 13, 2012 at 17:04 Also ich würde auch lieber den MS5611-01BA nehmen kostet zwar doppelt hat aber den besseren Range und die bessere Auflösung. Zitieren
macdiverone Geschrieben August 13, 2012 at 17:06 Geschrieben August 13, 2012 at 17:06 Also ich würde auch lieber den MS5611-01BA nehmen kostet zwar doppelt hat aber den besseren Range und die bessere Auflösung. +1, keine Frage Zitieren
McStep Geschrieben August 13, 2012 at 17:26 Geschrieben August 13, 2012 at 17:26 Die Frage für mich stellt sich anders: In welcher Form ist der MS5611-01BA angebunden? Wie kann der User am Ende davon profitieren? Im Prinzip ist eine höhere Auflösung ja ganz nett, aber ich würde das Ding auch gerne im Unterricht einsetzen. Da würden mich andere Aspekte ebenfalls interessieren: Kalmanfilter, alternative Verwendung I²C oder SPI .... . Für mich klingt der jedenfalls im Ansatz interessanter. McStep Zitieren
Malik Geschrieben August 13, 2012 at 18:33 Geschrieben August 13, 2012 at 18:33 Also ich meine, so einen Sensor braucht man mehr für Messungen in Erdnähe - so bis 10 m Höhe - als z.B. von einem höher fliegenden Segelflugzeug aus. Die Modellbauer haben da ihre eigene (Sensor-)Welt. Deswegen ist der genauere Sensor (10 cm) sinnvoller. Ein günstiger, aber grober messender Sensor würde wahrscheinlich einige Leute zum Kauf reizen, die dann aber enttäuscht sind weil er nicht das leistet was sie messen wollen. Zitieren
AuronX Geschrieben August 13, 2012 at 18:38 Geschrieben August 13, 2012 at 18:38 Da ich denke, dass er von vielen Nutzern eben auch als Altimeter für Quadrokopter u.ä. eingesetzt werden soll (bzw. als solcher mal gewünscht wurde) wäre ich auch definitiv für den hoch-aufgelösten. Der andere scheint nur für die Wetterstationen u.ä. interessant zu sein. Zitieren
Wumpus Geschrieben August 13, 2012 at 19:00 Geschrieben August 13, 2012 at 19:00 Aus meiner Sicht wären der Stromverbrauch und die Response-Time noch interessante Parameter. Aber diese liegen offnebar für beide Modelle recht nah bei einander. Die Response-Time wäre wichtig, wenn man mit dem Sensor einen Druckschalter realisieren wollte. Insgesamt sind die Tinkerforge-Produkte zwar preiswert (und eigentlich würde ich sagen, dass es auf einen Euro mehr oder weniger nicht angekommt), allerdings summieren sich die Kosten für ein Projekt ganz schön. Daher tendiere ich zur preisgünstigeren Variante. Zitieren
ArcaneDraconum Geschrieben August 14, 2012 at 04:41 Geschrieben August 14, 2012 at 04:41 Auch mir würde der günstigere Sensor für meine Belange voll und ganz ausreichen. Der Preisunterschied ist ja schon beträchtlich. Da ich durchaus 2-3 Module haben möchte.... ein teures, oder 2 günstige... Zitieren
jan Geschrieben August 14, 2012 at 04:43 Geschrieben August 14, 2012 at 04:43 Unabhängig vom Preis, hoffe ich (bitte ich euch) das Modul im selben Formfaktor wie das Temp- und Humiditybricklet (15x25) herauszubringen. Dann kann man alle schön zusammenschrauben :-) Zitieren
borg Geschrieben August 14, 2012 at 09:54 Autor Geschrieben August 14, 2012 at 09:54 Unabhängig vom Preis, hoffe ich (bitte ich euch) das Modul im selben Formfaktor wie das Temp- und Humiditybricklet (15x25) herauszubringen. Dann kann man alle schön zusammenschrauben :-) Jop, das wird passen! Ich bin überrascht, dass doch so viele die mehr als doppelt so teure Variante vorziehen. Deutet ja im Moment alles stark darauf hin als sollten wir den MS5611-01BA benutzen. Ich denke wir werden mal einen kleinen Mockup aus IMU und MS5611-01BA bauen, wo aus Beschleunigungssensor-Werten und den Daten vom MS5611-01BA die höhe bestimmt wird. Das sollte dann natürlich auch gut funktionieren, sonst ist am Ende die Enttäuschung groß . Zitieren
jan Geschrieben August 14, 2012 at 10:26 Geschrieben August 14, 2012 at 10:26 Kann man das nicht so implementieren, dass wenn an Port A der IMU ein BarometerBricklet hängt, dass die IMU diese Daten automatisch mit auswertet? Zitieren
borg Geschrieben August 14, 2012 at 11:29 Autor Geschrieben August 14, 2012 at 11:29 Kann man das nicht so implementieren, dass wenn an Port A der IMU ein BarometerBricklet hängt, dass die IMU diese Daten automatisch mit auswertet? Ja, sowas kann man auf Dauer machen, etwas ähnliches ist auch für DC/Stepper Brick und Inkrementalgeber Bricklets geplant. Zitieren
AuronX Geschrieben August 14, 2012 at 16:42 Geschrieben August 14, 2012 at 16:42 @borg: Ich denke alle die die hohe auflösung wollen kommen aus der Ecke "Quadrokopter". Eine Frage die ich für mcih noch nicht klären konnte ist, ob TF überhaupt geeignet ist Quadrokopter zu steuern. Also mit eigener Firmware natürlich, aber mit Bordmitteln wird das eng. Da ist dann schon die Frage, ob der Wunsch nach der höheren Auflösung nicht eher auf "Träumen" beruht. Der einzig andere Anwendungsfall für ein Altimeter der mir einfällt wäre das HUD fürs Flugzeug, da wird Metergenauigkeit wohl reichen ^^ Will sagen: ich bin mir inzwischen uneins... Haltet ihr (TF) den Einsatz eurer Hardware für quadrokopter für realistisch? Zitieren
lightman17 Geschrieben August 14, 2012 at 17:25 Geschrieben August 14, 2012 at 17:25 Hallo Welche Genauigkeit braucht man denn für den Einsatz als Barometer in einer Wetterstation? lightman Zitieren
The_Real_Black Geschrieben August 14, 2012 at 19:20 Geschrieben August 14, 2012 at 19:20 Wie genau ist der geneuere der Sensoren? Wenn ich ein Fenster aufreiße oder eine Tür schlägt dieser dann an oder liegt dies unterhalb der Messgenauigkeit? Als Tür öffnungssensor\Alarmanlage wäre das sicher nett. Für meinen Roboter welcher am Boden fährt werde ich vermutlich sowas nicht brauchen, aber wenn dann würde ich schon genauere Messwerte haben wollen... 10 cm wären für Höhenangaben schon eine sehr genaue Angelegenheit... +1 für den besseren. Zitieren
ArcaneDraconum Geschrieben August 15, 2012 at 05:08 Geschrieben August 15, 2012 at 05:08 Also wenn ich das Datenblatt vom "besseren" Modul richtig deute, kann man auch Temperaturwerte abfragen. Wenn das in der Firmware vom Bricklet auch freigeschaltet ist - so könnte man sich ja bei einer Wetterstation das TemperatureBricklet sparen - dann ist man preislich wieder ganz gut im Rennen. Übrigens wird mit Genauigkeit 1,5mbar angegeben. Das wäre auch für eine Barometeranwendung sehr gut. Das kleinere Modul hat ja einen Fehler von 1kPa = 10hPa = 10mBar. Das ist ja nicht so dolle. Übrigens das Modul, welches thunderbird (und ich in Kopie auch) einsetzen hat einen Fehler von 1,5% = ca. 15mBar. Also wäre hier schon eine Verbesserung zu erzielen. Zitieren
batti Geschrieben August 15, 2012 at 07:42 Geschrieben August 15, 2012 at 07:42 Das mit dem Quadrokopter können wir auch nicht mit Sicherheit beantworten. Das weiß man wohl erst wenn man es probiert hat. Falls jemand an eine Anwendung des Raspberry Pi's denkt, dann wird das mit dem jetzigen Brickd nicht möglich sein. Python ist einfach sehr langsam auf dem Raspberry Pi (Brickd ist in Python geschrieben). Wir denken aber über eine Implementierung in C nach, so dass auch auf dem Raspberry Pi 1000 Nachrichten/sek möglich sind. Problematisch könnte dann noch Reaktionszeit sein, da die Nutzung von USB natürlich Latenz mitbringt. Keine Ahnung wie schnell man bei so einem Quadrokopter reagieren muss und was alles durch eine vernünftige Regelung rauszuholen ist. Grundsätzlich halte ich das ganze aber für möglich und wer weiß, vll. gehen wir das auch mal an... Zitieren
Faab Geschrieben August 15, 2012 at 08:03 Geschrieben August 15, 2012 at 08:03 Das mit dem Quadrokopter können wir auch nicht mit Sicherheit beantworten. Das weiß man wohl erst wenn man es probiert hat. Falls jemand an eine Anwendung des Raspberry Pi's denkt, dann wird das mit dem jetzigen Brickd nicht möglich sein. Python ist einfach sehr langsam auf dem Raspberry Pi (Brickd ist in Python geschrieben). Wir denken aber über eine Implementierung in C nach, so dass auch auf dem Raspberry Pi 1000 Nachrichten/sek möglich sind. Problematisch könnte dann noch Reaktionszeit sein, da die Nutzung von USB natürlich Latenz mitbringt. Keine Ahnung wie schnell man bei so einem Quadrokopter reagieren muss und was alles durch eine vernünftige Regelung rauszuholen ist. Grundsätzlich halte ich das ganze aber für möglich und wer weiß, vll. gehen wir das auch mal an... OT: +1 für die C-Implementierung des brickd... habe es gestern an meinem pi auch wieder bemerkt - ein bisschen ist der Geschwindigkeitsunterschied im Vergleich zum PC zu spüren. Ich denke das wird dann bei einem Quadrokopter viel herausreissen.. Und da ja jetzt viele das Pi benutzen, wäre es ja schon lohnenswert, oder? Könnte ja man mal mit auf die timeline nehmen Zitieren
ArcaneDraconum Geschrieben August 15, 2012 at 08:04 Geschrieben August 15, 2012 at 08:04 Noch ne Anmerkung zur Reaktionszeit: Die von Euch genannte Genauigkeit von 0,01 mBar wird nur bei massivem Oversampling erreicht, dann ist aber die Reaktionszeit von dem Chip 8ms. Da sind dann eh keine 1000 Nachrichten pro Sekunde mehr drin. Ich würde sagen im Idealfall 250. 1ms erreicht man nur bei 0,06mBar Genauigkeit.... für ne Barometeranwendung sind 8ms natürlich nix, aber für ne Flugsteuerung..... Zitieren
batti Geschrieben August 15, 2012 at 08:40 Geschrieben August 15, 2012 at 08:40 Und da ja jetzt viele das Pi benutzen, wäre es ja schon lohnenswert, oder? Könnte ja man mal mit auf die timeline nehmen Natürlich ist das lohnenswert. Allerdings ist es schon einiger Aufwand und wir wollen eigentlich nicht zwei Brickd's parallel haben. D.h. wir würden dann Brickd komplett auf C für alle Platformen umstellen damit wir nicht zwei Systeme parallel warten müssen. Ein C Programm für verschiedene Plattformen (32bit/64bit, Linux/Mac OS X/Windows etc.) anzubieten ist aber leider einiger Aufwand. Dies war auch einer der Gründe warum wir Brickd in Python geschrieben haben. für ne Barometeranwendung sind 8ms natürlich nix, aber für ne Flugsteuerung..... Ich denke das die 8ms kein Problem darstellen. So oder so muss ja eine Regelung dahinter die auch die Beschleunigungswerte des Quadrokopters mit einbezieht. Zitieren
AuronX Geschrieben August 15, 2012 at 18:27 Geschrieben August 15, 2012 at 18:27 für verschiedene Plattformen (32bit/64bit, Linux/Mac OS X/Windows etc.) Und damit nennst du ja nichtmal die Probleme durch ARM und Co ^^ Ich bin auch mittelmäßig skeptisch was den Gain durch die neue Implementierung angeht. Immerhin ist TCP (darauf basiert ja der brickd) schon von sich aus eher fett (selbst wenn es nur übers loopback-interface geht). Auf jeden Fall solltet ihr da vorher ausloten was ihr erwartet und mit nem kleinen Prototyp testen ob das jemals erreicht werden kann. Alternative: Ich habe mir sagen lassen, dass PyPy schneller sein soll als Python (ist aber source-kompatibel). Aber das ist mehr so hören sagen (keine Erfahrungen meinerseits), wäre aber villt eine interessante Richtung in die man die Nase mal halten könnte ^^ Zitieren
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.