Zitierenmbed mag ich nicht weil es im netz läuft, nicht lokal.
MPU6050. Code gibts auf Github.
Mbed ist prinzipiell das gleiche wie Arduino IDE. Kein low-level Kram.In 1 Satz: ja, es geht auch sogar noch schneller, wenn man mbed verwendet.
Aber nicht einfacher, wenn man schnell Ergebnisse braucht, nicht alle libs selber schreiben will, und sich nicht mit low level-Compilerproblemen und make file herumschlagen will.
Doch, gibt es. Wenn du dynamisch auf einem wenige KB großen RAM speicher allokierst ohne vernünftige Speicherverwaltung, dann überschreibst du ganz schnell wichtige Bereiche wie Stack. Genau deshalb ist es auch deaktiviert.Dadurch sind diverse C++ Features (z.B. string, vector, usw.) künstlich deaktiviert. Technische Gründe dafür gibt es nicht, wenn man die Sketches außerhalb der IDE baut funktioniert es und die Programme sind teilweise kleiner und schneller als mit der Arduino IDE.
mfg
mbed mag ich nicht weil es im netz läuft, nicht lokal.
das leben ist hart, aber wir müssen da durch.
ich hab inzwischen Arduino Due + Display bestellt.Zitat von Wsk8
Bzgl. IMU bin uch noch unsicher - es gibt wohl welche, die direkt "Richtungskoordinaten" liefern (wie auch immer das fachlich rorrekt heißt, ich meine Werte für die Winkel pitch, roll, yaw) und solche, die nur Rohdaten liefern und bei denen man selbst rechnen muss. Einfacher und "schöner" / sicherer (?) würde ich natürlich Variante 1 finden. Viele scheinen auch neben Beschleunigung und Drehwinkel das Erdmagnetfeld mit einzuberechnen - nachdem ich bei dem Gerät zwei große Motoren mit Zündung und Lichtmaschinen in der Umgebung habe (einer ist ca. 80 cm weit weg), frage ich mich, ob das Einbeziehen des Erdmagnetfeldes in dem Fall Sinn macht.
Die CMPS11 schien eine der "Komplettlösungen" zu sein, allerdings unter Berücksichtigung des Magnetfeldes (wobei ich keine Ahnung habe, in wie fern evtl. Verbrennungsmotoren darauf Einfluss haben), die MPU6050 ist wohl eher die "rechne mal selber" Variante. Gibt es vielleicht noch Empfehlungen für "Komplettlösungen", evtl. sogar mit Barometer??
Sag ich ja. Nur halt eben effizienter gemacht.
Das stimmt nicht. Es ist ja auch nicht deaktiviert. Es sind einfach Dateien gelöscht. Der normale gcc-arm-none-eabi sowohl unter Linux als auch Windows hat diese Dinge und die funktionieren auch auf den 32 Bit Arduinos. Auch hat das offenbar nichts mit dynamischer Speicherverwaltung zu tun, es fehlen auch <array> oder <functional>.
Ich verwende normalerweise auf dem Notepad++ und platformio.org anstatt der Arduino IDE, damit ist das kein Problem.
Auch das stimmt nicht (mehr). Mbed 3 ist lokal.mbed mag ich nicht weil es im netz läuft, nicht lokal.
Mbed 2 kann mittlerweile als zip Datei exportieren und die Projekte lassen sich unter Linux (auch auf Raspi oder Beaglebone) einfach durch Aufruf von "make" übersetzen, die entstandene Datei muss man nur noch auf den mbed kopieren.
Es gibt aber auch 2 oder 3 Projekte, wie das genannte Platformio, die mbed, Arduino, Teensy, TI offline auf der Kommadozeile bauen können. Sie lassen sich auch in diverse IDEs einbinden.
http://docs.platformio.org/en/latest/ide.html
- - - Aktualisiert - - -
Da muss ich nochmal antworten, weil sich das so schön selbst widerspricht
Ja beide verwenden offline den gleichen Compiler.
Eben noch gleich, jetzt nicht. In mbed geht std::string und std::vector und in Arduino nicht, weil ?
Geändert von Mxt (23.01.2016 um 09:06 Uhr)
@all:
der TO hat doch jetzt den Arduino Due bestellt, dann bietet sich doch auch die Arduino-IDE an, gerade für Anfänger. Das war ja auch sein Entscheidungskriterium gegenüber anderen ARM (mbed) Boards. Wenn er mag, kann er später ja immer noch wechseln.
@FlyRider,
zum Thema IMU:
ok, an Magnet-Störfelder durch die Verbrennungsmotoren hatte ich als Alu- und Plastik-Nutzer nicht gedacht - stimmt aber!
Immerhin kannst du beim CMPS11 auch alle Einzel-Sensor-Raw-Werte ebenso einfach aus den Registern auslesen - allerdings nicht fusioniert.... damit geht sein größter Vorteil (onboard-cpu mit Kalman) natürlich "flöten".
Vom MPU6050 würde ich aber definitiv abraten, das ist ein unglaublich mistig zu handhabendes Monster, ich habe es mal damit probiert... ist zwar saubillig, aber jetzt liegt er ungenutzt in der Ecke. Die Libs dafür sind eine einzige Zumutung! (Vllt findest du aber hier jemanden, der dir das anfängertauglich erklären kann, ICH habe es aufgegeben...)
Was an der MPU 6050 ist denn nun wieder kompliziert?
Man schliesse das Ding an, besorge sich die Kalman-Filter-Bibliothek für Ardunino und lese die gewünschten Werte....
Das Einzige, was man u.U. tun muss, ist, die Achsen an die _wirkliche_ Einbaulage anpassen.
Noch unkompolizierter kann ich es mir nicht vorstellen- zumal das Beispielprogramm der genannten Bibliothek auch Rohwerte (wenn man mal selber versuchen möchte, so _richtig_ zu programmieren) und auch komplementärGefilterte Werte ausgibt.
Hier kann man sehr schön vergleichen...
Und das funktioniert auch, einwandfrei.
Besser kann es irgendeine alles-in-Wunderlösung auch nicht machen, die hätte allenfalls nen Geschwindigkeitsvorteil, wenn die Filtereien direkt im Sensorbord erledigt werden, mehr nich...aber selbst auf nem, mit nur 16MHz getakteten, Arduino reicht das allemal zum balancieren.
Kompass wirst du wirklich knicken können. Abstand zu Eisen mindestens 20cm, bei weniger muss das Ding sehr gründlich kalibriert werden, und die Fehler, die die Zündanlagen erzeugen, wirste niemals raus gerechnet bekommen, fürchte ich.
Grüssle, Sly
..dem Inschenör ist nix zu schwör..
Ich kann mir ja die MPU 6050 einfach mal ansehe, das Ding kostet ja wirklich nicht die Welt. Und mann kann ja relativ problemlos auch später noch eine andere IMU einbauen, wenn es die doch nicht bringen sollte. Bei Lösungen mit Magnetfeld habe ich eben bedenken, ob die noch problemlos funktionieren, wenn das Magentfeld gestört wird (ob man die Werte quasi ignorieren kann und nur auf Beschleunigung und Drehwinkel geht - aber dann bringt die "teure" Lösung hat eh nix).
Jetzt wart ich mal, ob noch jemand Efahrung mit alternativen IMUs hat, ansonsten probier ich einfach mal die MPU 6050 ...
gut zu wissen das mbed3 lokal ist
kompass ist echt kompliziert, nicht nur eisen, sondern auch motoren machen probleme.
das leben ist hart, aber wir müssen da durch.
den fehlerhaften Kompass-Anteil kannst du keinesfalls einfach ignorieren, wenn er in den IMU mit eingeht, aber durch Metallteile verfälscht wird. Dann wird auch dein heading total verfälscht sein. Daher brauchst du tatsächlich einen IMU OHNE Kompass-Anteil.
Gelöscht oder deaktiviert. Was ist da jetzt der Unterschied? Standardmäßig ist es nicht verwendbar, und auf das kommt es an.Das stimmt nicht. Es ist ja auch nicht deaktiviert. Es sind einfach Dateien gelöscht. Der normale gcc-arm-none-eabi sowohl unter Linux als auch Windows hat diese Dinge und die funktionieren auch auf den 32 Bit Arduinos. Auch hat das offenbar nichts mit dynamischer Speicherverwaltung zu tun, es fehlen auch <array> oder <functional>.
Und es geht hier hauptsächlich um die Container, hier wird sehr viel mit dyn. Speicher gemacht. Bei unseren kleinen Hobby-Projekten, wo keine 10% des Controllers genutzt werden, funktioniert das natürlich gut. Aber es gibt ja schließlich Leute, die jedes Byte ausnutzen und dabei zu 100% garantieren müssen, dass nichts abstürzt. Sonst wird es seeehr teuer.
Aber in den nächsten Jahren wird sich hier noch viel ändern.
mfg
Berechtigungen
Lesezeichen