batti

Danke für den Hinweis AuronX, werde ich den Jungs gleich mal vorschlagen. Bzgl. TCP/IP, das stellt kein Problem dar. Haben es auf dem Raspberry Pi getestet. Eine reine C Implementierung schafft ohne Ende Nachrichten (>10.000/Sek). Das Stellt kein Flaschenhals dar. Testet man dies allerdings mit Python, so ist man schon wieder in der Nähe von 1.000/Sek. Und da kommt beim Brickd natürlich noch der USB Kram und das Messagehandling dazu.

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. Ich denke das die 8ms kein Problem darstellen. So oder so muss ja eine Regelung dahinter die auch die Beschleunigungswerte des Quadrokopters mit einbezieht.

That the LCD dimm slightly when switching the DR is normal. The reason is, that the DR draws a significant current when switched on, so the voltage drop across the protection diode on the bricks is higher. This leads to a lower voltage on the 5V line and a slightly darker LCD backlight. Regarding the LCD Problem. Please write us an email, there seems to be something wrong with it.

I understand the need for a mounting plate, but I don't know how this plate should look currently. I think it should have a 5mm grid with 3mm drills. What dimensions should this plate have? Should there be some other kind of Mounting holes? Please make some suggestions. If possible a DXF file or something else would be nice. Thanks

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

Ok... That was not the answer I was expecting , but it's nice that you enjoy the tinkering...

Dies wäre unserer VK Preis. Wir haben uns gegen einen Poll entschieden, weil wir gerne auch eure Gründe dazu hören wollt.

Any update here Xenna? We are currently discussing possible improvements...

Hallo Holy, hat der upload geklappt? Können wir dich irgendwie unterstützen (auf server hochladen, dokumentation etc)? Grüße, Bastian

Hallo zusammen, wir können euren "Zorn" natürlich verstehen. Wie wir schon zu genüge geschrieben haben waren wir mit Chibi so nicht zufrieden und versuchen lieber möglichst schnell eine bessere Alternative anzubieten. Es gibt natürlich Gründe warum wir nicht einfach noch nen paar Chibis machen. So müssen die Bauteile wieder neu beschafft werden und der Bestücker muss wieder loslegen. Normale Kunden bestellen Ihre Waren 4 Wochen im vorraus beim Bestücker. Dieser "normale" Weg würde also durchaus lange dauern. Einfach auf nen Knopf zu drücken und schwupps ist alles da ist also nicht möglich (leider). Anstatt unsere Energie darein zu stecken, setzen wir momentan alles daran die WIFI Extension fertig zu bekommen. Unser Bestücker wird auch alles versuchen sie schneller zu produzieren. Nun ist das aber so, dass es nicht "das WIFI Modul" gibt. Wir haben uns Anfangs auf das WiFly eingeschossen da es weit verbreitet und recht günstig ist. Nach nen paar Tests und nen Prototypen haben wir aber festgestellt, dass es Probleme mit manchen FritzBoxen gibt. Der Hersteller verkauft mehr oder weniger an Firmenkunden wo dies nicht so wichtig zu sein scheint. Für uns war dies natürlich ein k.o. Kriterium. Also haben wir uns andere (teurere) Module schicken lassen und diese getestet. Wir scheinen jetzt zwei Kandidaten zu haben. Typischerweise werden diese Module per serieller Schnittstelle betrieben. In unserem System wäre eine SPI Schnittstelle aber deutlich sinnvoller, da der Prozessor geschont werden könnte und auch ein höherer Durchsatz möglich wäre. Die Module unterstützen SPI laut Datenblatt, wenn man aber mal nachfragt stellt man fest, dass diese sich noch in der Entwicklung befindet... Kurzum: Wir haben hier jetzt Module die wir auch per SPI ansteuern können. Etwas müssen wir dies noch testen, dann gibt es noch einen "Vorserien Prototypen" und dann werden die Leiterplatten bestellt. Sorry das dies so lange dauert. Grüße, Bastian

Xenna, have you solved these strange EMI problems?

Ich könnte mir vorstellen das es vll. irgendwo einen Verstärker existieren könnte. Alternativ sind vll. bessere Antennen eine Option (Richtfunk?)

Hallo Olaf, der Varistor sollte genügen. Wir haben gerade auch einen größeren Satz an Varistoren, RC Gliedern etc. bestellt. Wir werden diese Testen und euch dann hoffentlich Lösungen präsentieren können. Mit Bezugsquellen etc. Vielleicht bieten wir den Kram dann auch in unserem Shop an. Ich melde mich wenn ich mehr weiß. Grüße, Bastian

Hallo Nic, können dir nur recht geben. Steht auf unserer TODO Liste.

Die verwendeten Komponenten sind von Servocity. Siehe auch hier: http://de.blog.tinkerforge.com/2012/5/31/1126

Sorry für die späte Antwort. Momentan kann man nur eine IO-4 oder IO-16 für nen Stop Signal nutzen. Sofern keiner über das Kabel stolpert oder die Software sich aufhängt sollte dies vernünftig funktionieren. Eine Möglichkeit, dass der Stepper direkt einen Schalter überwacht gibt es momentan nicht. Hierfür müsste die Firmware des Steppers angepasst werden.

@glaf: Probiere mal die hier beschriebenen Maßnahmen: http://www.tinkerforge.com/doc/Hardware/Bricklets/Dual_Relay.html#inductive-load-switching @Loetkolben: Alle Leitungen werden beim Dual Relay benutzt. In der Luft hängen tut keine. Die Flächen des LCD Bricklets sind wirkliche Masseflächen. @Wumpus: Tritt das Problem bei dir auch nur auf wenn du Lasten schaltest? Die hier beschriebenen Maßnahmen schon probiert? http://www.tinkerforge.com/doc/Hardware/Bricklets/Dual_Relay.html#inductive-load-switching

Danke für den Hinweis! Sollte jetzt gefixt sein.

Du hast recht. Ist gefixt. Danke für den Hinweis!

Hast du die Callbacks denn aus der Schleife rausgenommen? Die solltest du wirklich nur einmal registrieren.

Hi, Ne kurze Skizze: Bau dir doch nen Wrapper Klasse mit der du beide Relais einzeln schalten kannst. Dann brauchst du nur eine Methode, die sich nur den alten Zustand merken müsste und dann setState aufruft etc.

Hi! Zum Thema Schrittmotoren kann ich dir folgenden Artikel empfehlen: http://www.rn-wissen.de/index.php/Schrittmotoren Das Stepper Brick regelt die Spannung nicht herunter, dies ist aber auch nicht notwendig. Schrittmotoren sollte man immer mit einer höheren Spannung betreiben, wichtig ist den Strom einzuhalten (siehe Artikel). Du solltest den Motor ohne Probleme benutzen können. Solltest nur keinen höheren Strom einstellen wie die Angegebenen 1.6A. Grüße

Möglich ist das sicher, ich kann den Aufwand dafür momentan auch nicht einschätzen. Wichtig war uns erstmal zu zeigen, dass es überhaupt mit dem Raspberry Pi funktioniert. Wenn wir mal wieder etwas mehr Zeit zur verfügung haben können wir uns das ja mal ansehen.

Es gibt jetzt eine eigene Seite für die Nutzung des Raspberry Pi's: http://www.tinkerforge.com/doc/Embedded/Raspberry_Pi.html

Thanks for the description Xenna, We have added a small description to our documentation: http://www.tinkerforge.com/doc/Embedded/Raspberry_Pi.html If anyone has similar descriptions for other boards please let us know.