raphael_vogel

Coole Sache. Aber wieso als Bricklet? Der Sinn von diesem Gerät ist doch gerade dass es "Standalone" betrieben werden kann. Da will ich doch kein Master Brick zusätzlich an der Wand haben ? Oder hab ich dich falsch verstanden? Was ich mir vorstellen könnte ist ein Bluetooth Bricklet (BLE), das dann mehrere solcher Teile zentral steuern kann.

Hi mit 433MHz und dazu noch ohne Rückkanal (Unidirektional) würde ich nix steuern. Was kabelgebundene Steuerung angeht kannst du mehrer RS485 Extensions mit jeweils einem Master Brick verwenden. Das wird allerdings vermutlich zu teuer, und auch wichtig zu wissen: Die RS485 Extensions können nicht sternförmig verlegt werden (eine RS485 + Master von dem sternförmig weitere RS485 Extensions versorgt werden). Könntest das auch mit WLAN steuern. Dazu brauchst du einen Master + WLAN Extension, aber das ist auch zu teuer, wenn du das 10 mal brauchst! Fazit: Aktuell ist das ehr schwierig mit TF zu realisieren. TF arbeitet aber anscheinend an einer Wifi Bridge, die eventuell preislich interessanter sein könnte. Gruß Raphael

Um ein wirklich stromsparendes System zu bekommen müsstest du ja nicht nur den Master Brick sondern auch die Wifi Verbindung schlafen legen. Das geht aktuell nicht. Das TF Protokoll unterstützt das nicht. Siehe http://www.tinkerunity.org/forum/index.php/topic,3323.0.html In diesem Thread hab ich auch meine eher "radikale" Lösung vorgeschlagen NodeMCU oder Micropython auf dem Wifi Chip (ESP8266) direkt auszuführen. Das bricht aber das TF Konzept mit den multiplen Language Bindings.

Schau dir mal das IO16 Bricklet an. Dort gibt es fast 5V (4,x wegen Schutzdiode) und 20 mA am Ausgang.

Aktuell geht das nicht. Was du willst ist sowas wie ein Deep Sleep Modus. Das Problem ist hier nicht unbedingt die Hardware (MCU) sondern das TF Protokoll ist derzeit darauf ausgelegt eine dauerhafte Verbindung zu den Bricklets zu haben. So zumindest mein Verständnis. Eventuell tut sich da was mit der kommenden Wifi Bridge. Such mal danach im Forum für mehr Infos.

Schönes Design. Beim alten Design find ich die visuelle Darstellung der bevorstehenden Schaltvorgänge besser als beim neuen Design. Aber natürlich sieht beim neuen Design nicht mehr alles zu gequetscht aus. Eine Kombination aus beidem fänd ich das Beste ;-)

Du kannst auch einen Web Server laufen lassen und dem RED ein WLAN Stick spendieren. Dann kannst du auch per File Upload aus dem Browser was hochladen.

Hi nochmals Was ich im Github bei TF gesehen habe wollt ihr ja den ESP8266 benutzen. Der Chip wirbelt ja gerade so einiges durcheinander bezüglich Preis (der WLAN Chip alleine weniger als 2€ !!), Funktionalität und Größe. Ich würde sogar sagen das er "revolutionär" ist. Weiterhin habe ich folgendes Board bei Adafruit gefunden: http://www.adafruit.com/product/2471 und auch das nodeMCU Open Source Projekt: http://nodemcu.com/index_en.html Nach etwas einlesen ist mit folgendes aufgefallen: 1) Man kann den Chip direkt mit einer High Level Programmiersprache programmieren (hier LUA). LUA kannte ich vorher nicht, aber die API sieht sehr sehr einfach aus. Beispiele: http://nodemcu.com/index_en.html#fr_5475f7667976d8501100000f 2) Man kann den LUA Code "direkt" per USB auf den Chip laden (mit FTDI Kabel). Es ist nichts weiter nötig. Was das alles mit TF zu tun hat? 1) Was bei nodeMCU fehlt ist die high level Anbindung von Sensoren. Wenn man mit nodeMCU Sensoren anbinden will muss man da oft auf auf Protokollebene usw. Hier könnte TF Mehrwert bieten. 2) Ich würde mir eine solches Board wünschen wie von Adafruit jedoch mit Brickletanschluss und einer high level Sensor API. Die User Programme würde man dann direkt auf den Chip laden. Damit würde man halt die multiplen Languages Bindings nicht mehr unterstützen können, aber als ich die Einfachheit von LUA gesehen habe wär das für die Software Leute hier glaube ich kein Problem ! Ich würde dafür auch 20-30 € bezahlen, wenn die Bricklets angeschlossen werden könnten und es eine high level LUA API für die TF Bricklets gäbe. Mein Vorschlag wäre also das nodeMCU Projekt zu forken und dann die LUA API erweitern dass damit Bricklets angeschlossen werden können.

Hat funktioniert..... Danke $ sudo dpkg -i brickd_linux_latest_armhf.deb (Reading database ... 70063 files and directories currently installed.) Preparing to replace brickd 2.2.1 (using brickd_linux_latest_armhf.deb) ... [ ok ] Stopping Brick Daemon: brickd. Unpacking replacement brickd ... Setting up brickd (2.2.2) ... [ ok ] Starting Brick Daemon: brickd. Processing triggers for man-db ...

Es war schon vorher auf dem aktuellen Stand. Geht trotzdem nicht. Brickd mit Version 2.2.1 funktioniert. Hab das jetzt mal installiert damit ich weiter testen kann.

Hab sudo apt-get install libc6 gemacht. Ist auf dem aktuellen Stand.

Hi Wollte heute auf meinem Raspi 2 (Wheezy) den brickd installieren und bekomme folgende Fehlermeldung: [....] Starting Brick Daemon: brickd/usr/bin/brickd: /lib/arm-linux-gnueabihf/libc.so.6: version `GLIBC_2.17' not found (required by /usr/bin/brickd) apt-get update && apt-get upgrade habe ich gemacht.

Das ist das Hauptproblem denke ich. Ist das nur wegen der Callbacks? Warum könnte man nicht das Nugget komplett in den Standby Modus schicken und nur bei Bedarf aufwecken ?

Vielleicht hilft das RS232 Bricklet in Verbindung mit sowas? http://www.instructables.com/id/RS-232-Infrared-Receiver-in-a-Serial-Connector-LI/ und hier, das könnte ja auch auf dem RED laufen? http://www.lirc.org/

Über 100 € http://www.tinkerunity.org/forum/index.php/topic,3054.msg19111.html#msg19111

Hi Könnte man die Methode IO16.get_edge_count(pin, reset_counter) erweitern, dass man 2 Flankenzähler auf einmal abfragen kann? Momentan muss ich den Befehl zweimal, für jeden Zähler nacheinander abfragen. Hintergrund: Ich habe zwei Antriebsmotoren die über Hallsensoren die Anzahl der Umdrehungen messen. Für Odometrie Zwecke will ich, bei beiden Motoren die Umdrehungszahl kontinuierlich überwachen. Wenn ich jetzt get_edge_count() zuerst für den einen Motor und danach für den anderen Motor aufrufe hat der zweite Motor immer einen höheren Flankenzähler. Ich möchte aber zum Zeitpunkt x genau beide Flankenzähler des IO16 mit einem Befehl auslesen. Wäre das möglich noch einzubauen ?

Ich würde eher ein RC Glied empfehlen. 100nF und 47nF Keramikkondensatoren haben sich bewährt. http://www.roboternetz.de/community/threads/332-Wie-entstört-Ihr-Motoren Eventuell bei hartnäckigen Störungen die Zuleitungen noch um einen Ferritring wickeln wie beschrieben.

Sieht schick aus, Gratulation! Ich hätte gleich noch einen oder zwei weitere Arbeitsplätze eingeplant

In the german forum TF gave an update. On 9th of July they sent the bricklets to the company which places the electronic parts on the circuit board. After the bricklets are coming back TF needs to finalize documentation and make fotos etc. So my guess/hope will be mid/end of next week?

Servo Kabel richtig herum eingesteckt? Externe Stromversorgung vorhanden? Eventuell ziehen die Servos zu viel Steom? Poste doch mal dein Code

Im NPM gibt es dazu ein(ige) Module, z.B. https://www.npmjs.com/package/webworker-threads

Du kannst das direkt mit JavaScript machen: Schau mal hier (Temperatur auslesen): http://www.tinkerforge.com/en/doc/Software/Bricklets/Temperature_Bricklet_JavaScript.html#simple-html oder hier (Relais schalten): http://www.tinkerforge.com/en/doc/Software/Bricklets/DualRelay_Bricklet_JavaScript.html#simple-html Weitere Möglichkeit wenn du Web UI's bauen willst: Installiere einen Web Server und benutze ein Binding deiner Wahl (PHP, Python, Java.....). In der Methode in der du den Request verarbeitest kannst du dann eine IPConnection aufmachen, den Sensor Wert lesen und zum Schluss das HTML/JavaScript/CSS an den Browser zurücksenden (Response). Die letzte Möglichkeit ist ein natives UI (kein Web) zu verwenden. Das hängt dann mehr von der Programmiersprache ab, wie du das machen willst. Java -> SWT, Swing, Java FX, QT Python -> TkInter, QT...... ....

Eine andere Möglichkeit ist die Positionsbestimmung mittels Trilateration. Es werden die Abstände zu 3 feststehenden Landmarken ermittelt. Dies kann mit einem Laserscanner gemacht werden. Ich werde das mit dem neuen Laser Range Finder Bricklet das bald kommt mal ausprobieren ! Schönes Video mit Erklärung wie das gemacht wird:

Wie Nic erwähnt hat ist das mit Odometrie relativ einfach zu machen, wenn die Räder keinen Schlupf haben, was in Innenräumen besser ist als Außen. Aber mit der Zeit wirst du auch mit Odometrie immer größere Fehler bekommen, und nach einger Zeit weisst du nicht mehr wo du genau bist. Generell ist die Positionsbestimmung (Localization) bei Robotern nicht einfach zu lösen. Oft werden multiple Sensordaten fusioniert, um Fehler auszugleichen (Kalman Filter -> https://en.wikipedia.org/wiki/Kalman_filter).

Hi TF Der DC Brick hat die Methode get_current_consumption(). Leider gibt es dafür keine Callback Funktion, die z.B. gerufen wird, wenn der Motor eine bestimmte Menge an Strom zieht. War dies nicht möglich? Könnt ihr die API hier noch erweitern? Hintergrund: Wenn bei einem Roboter ein Rad blockiert, steigt der Strom und dann will ich den Motor schnell abschalten können.