Jump to content

raphael_vogel

Members
  • Gesamte Inhalte

    328
  • Benutzer seit

  • Letzter Besuch

Posts erstellt von raphael_vogel

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

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

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

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

     

     

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

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

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

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

    ....

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

     

     

×
×
  • Neu erstellen...