Jump to content

Barometer, Altimeter, Auflösung und Preis


borg
 Share

Recommended Posts

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:

 

MPL115A1:

 

Was meint ihr? Wir würden Momentan Aufgrund von endlicher Zeit und endlichen finanziellen Mitteln nur eine der beiden Varianten machen können!

Link to comment
Share on other sites

  • Replies 60
  • Created
  • Last Reply

Top Posters In This Topic

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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ß :).

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

@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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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...

 

Link to comment
Share on other sites

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 :)

Link to comment
Share on other sites

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.....

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 ^^

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share


×
×
  • Create New...