borg

Depending on the sensor we are using 100KHz or 400KHz (we generally use the max speed of the sensor). You mean for SPI? It is 8MHz. 64MHz

x-IMU does use Madgwick’s AHRS and IMU algorithms, which we use too! So they either 1. made the video with a very well calibrated and tweaked IMU, 2. have a better parameterization of the algorithm or 3, just use much more expensive sensors. I would bet that it is a combination of 1. and 3. I probably could make a very similar video if i tweaked one IMU long enough. When say that "its way more faster", what do you mean? Do you mean the 3D rendering lags behind? And about the accuracy: Have you tried to recalibrate the magnetometers in your environment?

@Jan: Du würdest bessere Performance aus dem Raspberry PI bekommen wenn du das offizielle "Raspbian" verwenden würdest: http://www.raspberrypi.org/downloads Da funktioniert dann auch unsere brickd.deb. Unser .deb ist für arm Architekturen mit einer Floating Point Einheit (FPU). Du verwendest ein Linux für arm ohne FPU, der RPI hat aber eine FPU. Das ist der Unterschied zwischen armhf und armel

Das ist nicht möglich, die Step-Down Power Supply ist ja rein analog, da ist nichts drauf was das schalten könnte.

Naja das kann schon hin kommen. Du musst halt gucken was alles passiert. Deine Daten gehen von deinem Programm per TCP/IP an den Brick Daemon, der schickt es über USB an den Eingangsbuffer von Master1, der schiebt es in den RS485 Ausgangsbuffer, von da geht es in den Eingangsbuffer von Master2, der gibt es an das Bricklet weiter. Dort wird dann per I2C der Port abgefragt und das ganze geht den weg wieder zurück. An allen Buffern kann ein Delay von 1ms auftreten, dazu kommt dann noch die Zeit die das eigentliche ausführen benötigt und schon kommst du auf 8ms. Beide Ports gleichzeitig abfragen ist technisch natürlich möglich, ob das noch auf das IO16 EEPROM passt weiß ich aber nicht. Ich schreibe es mir mal auf die TODO Liste mir das anzugucken. Ich werd auch mal ein paar Tests bzgl der Roundtrip Time machen, dann können wir das entsprechend dokumentieren. Das wird aber nichts in den nächsten paar Tagen.

So the h1_val throws an exception if you comment it in, but it doesnt if you comment out te tX_val lines? That doesn't make sense . Can you make a minimal Program (including the initialization and so) that causes the exception?

Der eigentliche Bootloader ist read only und sobald du den Erase Knopf drückst während du USB rein steckst kommst du auf jeden Fall in den Bootloader. Sollte also nichts passieren können .

Alle klar, gucke ich mir an. Komme aber wahrscheinlich erst am Montag dazu.

Mh, also wer sich daran schonmal versuchen will bevor wir dazu gekommen sind: https://github.com/Tinkerforge/brickv/blob/master/src/brickv/samba.py Was gemacht werden müsste: * Alles was mit Qt zu tun hat rausschmeißen * Aus flash(self, firmware, imu_calibration, lock_imu_calibration_pages, progress) alles entfernen was mit "progress" zu tun hat (ist GUI kram). * Flash aufrufen mit firmware=geladene Firmware, imu_calibration=None und lock_imu_calibration_pages=None

Vielleicht wird es auch ein SD Card Bricklet, ich habe da so eine ganz bestimmte "auto-logging Funktionsweise" im Kopf. Dafür wäre die SD Karte ein Interface, genauso wie USB, WIFI oder RS485. Das ist aber noch nicht zuende gedacht, liegt ja auch noch in ferner Zukunft. Erstmal brauchen wir überhaupt On Device Programming .

Zum Glueck nicht wirklich. Dann bliebe ja noch die manuelle Wiederbelebung per USB, oder? Jo, über USB kannst du immer flashen. Naja in Theorie geht sowas sicherlich. Es würde sich vermutlich anbieten die SD Card Extension die wir fürs On-Device-Logging machen wollen dafür zu nehmen. Aber du musst halt überlegen wie viel Aufwand das ist und welchen nutzen es hat. Ich denke es haben ca. 5% unserer Kunden eine WIFI Extension, wenn wir großzügig sind und sagen, dass 20% davon nochmal Geld ausgeben würden für ein "Zwischenspeicher-Bricklet" mit dem man dann über WIFI flashen kann. Dazu kommt der ganz schön große Aufwand das umzusetzen. Es ist halt schwierig das zu rechtfertigen, wenn noch so viele TODOs offen sind die fast alle TF Nutzer betreffen . Das ist mit dem Microcontroller den wir verwenden nicht möglich.

Ah, dann hab ich das falsch verstanden. Ich denke mit 64MHz sam3s den wir auf dem Master verwenden schon an der oberen Leistungsgrenze von Microcontrollern. Bist du sicher, dass du mehr Leistung brauchst?

Zum einen bin ich mir nicht sicher ob der komplette WIFI Code + der ganze Code den ich zum flashen brauche überhaupt in den RAM passt. Zum anderen wäre das extremst anfällig. In diesem Modus müsste ich auf jedenfall alle globalen Variablen und Buffer usw im RAM überschreiben, d.h. es gibt kein zurück aus dem Modus! Ein Verbindungsabbruch o.ä. würde sofortig zu einem gebricktem Brick führen . Eine Firmware über Funk updaten kann man eigentlich nur ohne Risiko machen wenn man die komplette Firmware einmal irgendwo zwischenspeichern kann. Ansonsten macht das mehr Probleme als es löst.

Have you played around with the convergence speed?

That depends on the speed of the board. If it has a really fast CPU this would probably be true, but it would also be very expensive .

Aver USB you can't reach 760µs for this, unfortunately. The polling frequency is 1khz, which means 1 message per ms.

Also wir sollen einen Arduino Due Klon machen? Ich glaube das passt nicht so in unser Konzept. Es geht ja bei uns gerade dadrum nicht löten zu müssen.

Flashen über Commandline ist definitiv sinnvoll, sollten wir auf Dauer anbieten. Zum Thema flashen über WIFI siehe hier: http://www.tinkerunity.org/forum/index.php/topic,1440.0.html

Das wird ja über unser normales Nachrichtensystem gehen, also auch über WLAN/Ethernet. Nicht über USB, sondern über WLAN. Vergessen habe ich noch das Anbieten von Web-Services. In Theorie kann man sich mit der WIFI Extension auf einen ftp Server verbinden oder einen Webservice anbieten. Das wäre aber etwas was es in erster Instanz von uns direkt als API nicht geben wird. Wer sich damit beschäftigen möchte kann das aber natürlich, ist ja alles Open Source und die Datenblätter liegen mit im git: https://github.com/Tinkerforge/wifi-extension/raw/master/datasheets/GS1011M_Adapter_Guide.pdf Also in erster Instanz (unabhängig von der Sprache) wird man per On Device die API haben die man extern auch hat und eine Möglichkeit Daten mit dem PC auszutauschen. Wenn es da die ersten Projekte gibt kann man anfangen zu gucken inwiefern es Sinn macht die API um On-Device-spezifische Funktionen zu erweitern. Eine einfache Möglichkeit einen kleinen Webservice anzubieten wäre da durchaus im Rahmen des möglichen.

Sockets/rpc/ftp/openvpn über USB? Oder wie stellt ihr euch das vor? Wir werden sicherlich eine Möglichkeit schaffen um Daten zwischen PC und On Device Programm auszutauschen, das ist z.B. für eine CNC Fräse notwendig (was ja durchaus oft angesprochen wird hier im Forum).

No worries, we just splitted the On Device Programming thread, since it degraded to a discussion about a "Linux Brick" (that can handle real Java/Python with standard library etc). I agree that a Super Master is no viable anymore when there are Linux boards for 35€ available.

Ich Kommentiere das Gezanke einfach mal nicht . Also ich ziehe folgenden Schluss aus den Anforderungen die ich bisher gesehen habe: Es handelt sich bei dem gewünschten "Super-Master Brick" in der Tat um ein Linux Brick. @Equinox: Das bedeutet unter anderem automatisch, dass wir ein Image über die SD Karte einspielen, wie bei allen kleinen Linux Boards üblich. Jetzt ist unser Linux Brick aber natürlich kein gewöhnliches Linux Board, wir wollen ja Sensoren auslesen, regeln und steuern. D.h. wir brauchen kein HDMI, Sound und diesen ganzen Schnickschnack (würde eh nicht auf 4x4cm passen). Bleibt eigentlich nur noch die Frage nach der Leistung. Das Linux Board von der Elektor läuft mit 180MHz, ist also eine echte Krücke ! Das wäre das absolute Minimum was man überhaupt noch mit Linux betreiben könnte. Damit würde sich z.B. mit hoher Wahrscheinlichkeit kein Quadcopter steuern lassen. Direkt per On Device mit C auf den Bricks ginge das aber sehr wahrscheinlich schon. Ist natürlich dann eine lustige Situation. Wenn wir jetzt mit der Leistung hoch gehen, in Richtung RPI oder darüber, dann gehen wir mit dem Verkaufspreis allerdings leider auch schnell weit über die 100€ hinaus. Die Frage die ich mich stelle: Gibt es da irgendwo ein passendes Maß an Leistung wo das Preis-/Leistungsverhältnis Sinn macht? Und macht das auch in 1,5 Jahren noch Sinn?

Unter einem Mini-Betriebssystem verstehen wir hier Windows/Mac OS/Linux/Solaris/Unix, richtig? Wenn nicht, was meinst du damit und was ist eine vollständige Java VM? Ich glaube nämlich nicht das es eine vollständige Java VM gibt (inklusive Standardbibliothek) die außerhalb dieser Betriebssysteme läuft. Warum ist steckbarer RAM wichtig?

Ich hab diesen Thread mal aus dem anderen herausgetrennt. Wir werden ein On Device Programming Interface für die existierenden Bricks anbieten. Da brauchen wir nicht drüber diskutieren. So ein Linux Brick oder Super-Master Brick ist natürlich auch eine Diskussion Wert. Anstatt darüber zu diskutieren ob es sinnvoller ist als ein On Device Programming Interface lasst uns darüber diskutieren wie so ein Super-Master Brick aussehen könnte. Also: Was sollte ein Super-Master Brick können? Was unterscheidet es von einem Raspberry PI? Und was darf es kosten?

Ich hab den Thread mal getrennt, die Diskussion über den "Super-Master Brick" gibts hier: http://www.tinkerunity.org/forum/index.php/topic,1479.0.html Wir werden ein On Device Programming Interface für die existierenden Bricks anbieten. Da brauchen wir nicht drüber diskutieren. Hier geht es jetzt darum wie so ein Interface aussehen könnte. Wie ein Linux Brick oder Super-Master Brick aussehen könnte und ob es sinnvoll ist, ist natürlich auch eine interessante Diskussion, die hab ich jetzt mal ausgelagert.