borg

bricklib/utility/init.c:24:24: fatal error: pio/pio_it.h: No such file or directory Mmmmmh, in Zeile 24 steht aber eigentlich #include "bricklib/drivers/pio/pio_it.h" und nicht #include "pio/pio_it.h" Ich denke er versucht einfach den Ordner "pio/" direkt im Hauptverzeichnis zu finden, er müsste aber in "briclib/drivers/pio" suchen. Welche IDE verwendest du denn? Kann man da irgendwas bzgl. Include-Pfaden einstellen? Edit: Im Zusammenhang mit dem anderen Thread vermute ich, dass du v1.x.y Branches mit v2 Branches mischt (also bricklib v1 und master v2 oder umgekehrt). Du musst bei beiden die v1.x.y Branches nehmen: https://github.com/Tinkerforge/master-brick/tree/v1.x.y https://github.com/Tinkerforge/bricklib/tree/v1.x.y Ich würde allerdings empfehlen auf v2 umzusteigen, v1 wird nicht mehr mit neuen Features erweitert werden!

Was du probieren könntest ist der Aufbau: PC -> WLAN -> PC -> USB -> Bricks Also sprich: Der Brick Daemon läuft auf einem PC wo der Brick direkt per USB angeschlossen ist und die Kommunikation läuft über Wi-Fi von einem anderen PC aus. Verhält es sich in dem Fall anders? Bzgl. eines Checks wegen der Geschwindigkeit steht zumindest nichts im Datenblatt des Moduls. Ich könnte dir aber eine Firmware machen in dem ich die "Transmit Rate" auf einen festen Wert setze.

Echt interessant, du scheinst da ja wirklich eine störungsreiche Umgebung zu haben . Ich gucke mal ob wir das nicht schaltbar in die Firmware eingebaut bekommen.

Ich denke die beste Lösung für so ein Projekt ist es, ein kleines Embedded Board (Raspberry PI, BeagleBoard o.ä.) mit auf die Seilkamera zu bringen und die eigentliche Regelung machen zu lassen. D.h. du schickst eine "High-Level Anweisung" per Wi-Fi an das Embedded Board (fahre 10m nach links mit 20km/h) und das Embedded Board macht die eigentliche Regelung. Eine Regelung über Wi-Fi wird nie Echtzeitanforderungen genügen, also nie eine definierte minimale Paketlaufzeit haben. Welche Verbindungsart theoretisch am stabilsten sein könnte kommt sicherlich auf das verwendete Equipment an. Wenn ein AP mit sehr hoher Sendeleistung verwendet wird, kann es denke ich durchaus sein dass eine Verbindung stabiler ist als direkt AdHoc.

http://download.tinkerforge.com/firmwares/

Also geplant ist sowas, das wird aber noch lange dauern. Ist relativ weit hinten in der Neue-Hardware-Liste. Im Moment tendieren wir aber dazu ein NFC-Bricklet zu machen, das scheint sich ja jetzt in Mobiltelefonen durchzusetzen usw. Vielleicht wäre NFC für ein Zugangssystem auch besser geeignet. Das ist auf Sicherheit ausgelegt und man könnte dann auch Zugang über Handys erlauben: http://www.fakir.it/aktuelles/detail/items/unterschied-rfid-und-nfc-eine-kurze-erklaerung.html

Unser Standardport ist 4223, nicht 4222 .

Do you have a screenshot of the behavior?

Da gibt es mehrere Möglichkeiten, ich würde es einfach mit einem großen Blob Lötzinn versuchen, den ich immer hin und her schwenke. Das kommt ein bisschen drauf an was du an der anderen Seite dranmachen willst. Wenn dein Taster auch einfach Pinne hat könntest du z.B. Jumper Kabel nehmen: http://nodna.de/Jumper-Kabel-F-F-gecrimpt-mit-Pingehaeuse-10-Stk Ansonsten gibt es auch passende Stecker dafür: http://webshop.schneider-consulting.it/25-Stueck-Pinheader-Buchsenstecker-Raster-254mm-zweireihig-6-polig (muss man aber selbst crimpen). Oder wenn du einfach nur ein Kabel anlöten willst, was du wieder an- und abstecken kannst, würde ich einfach eine 2x3 Buchsenleiste nehmen und dort Käbelchen anlöten: http://www.elmotex.de/steckverbinder/stiftleisten-und--buchsen/bl-2x3-g8-rm254.php (Sorry für die unterschiedlichen Shops, sind die ersten Google Treffer)

Die haben 3,5mm Abstand, füge ich hinzu. Das ist nicht mehr aktuell - oder? Ab Version 1.2 hat das LCD doch kleine Taster + Lötpunkte. Hö? Die Lötpunkte sind dafür da um eine Stiftleiste einzulöten: https://www.tinkerforge.com/de/shop/right-angle-pin-header-2x3.html Das soll die Doku an der Stelle beschreiben .

In gewisser Weise hängt es damit natürlich zusammen. Ein System welches nur dafür da wäre IO16 Werte über eine RS485 Verbindung auszulesen könnte sicherlich schneller sein. Ich müsste mal zwei Stack mit unserem Logic Analyzer verkabeln um herauszufinden wo genau wieviel Zeit verloren geht.

Das sollte nicht passieren. Welche Version hat die Master Brick Firmware?

An increase of 1mbar is equal to a decrease of ~10m. You can see that in both screenshots.

Again, we use the same algorithm. The link you posted is even in our documentation: http://www.tinkerforge.com/en/doc/Hardware/Bricks/IMU_Brick.html#how-it-works .

I don't know anything about Bluethooth, but i would expect that it has a lower latency then Wi-Fi. It is used in mice and such, which likely wouldn't work very well over Wi-Fi.

I would expect that it stabilizes a bit more if you run it for a longer time period. A change in air pressure of 0.12mbar is really not that much i am afraid. The altitude calculation is directly correlated to the air pressure. There is nothing we can do about that. If you want the altitude to be correct in the cm range, you will need to combine it with the IMU Brick data (with a Kalman filter).

Oh, but over Wi-Fi you will always have the added latency. I don't think there is anything you can do about that. If you connect the IMU to a PC over USB and then connect with to the IMU with another PC over Wi-Fi, you will get the same latency.

Yes, i agree. We had this discussion already quite often. It would be possible to generate something like this. It was once even planned during the protocol V1 to protocol V2 transition. But we decided to not invest time in this for the moment, since must of our users configure their Extensions in the Brick Viewer and don't need the API anyway. There is a huge list of TODOs and new products and so on, we have to pick our battles wisely .

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 .