Jump to content

borg

Administrators
  • Gesamte Inhalte

    3.546
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    50

Posts erstellt von borg

  1. Die Bindings generieren wir mit einem Pythin Skript. Die ganzen Generatoren findest du im generators git: https://github.com/Tinkerforge/generators

     

    Der Generator für die Bindings sieht so aus: https://github.com/Tinkerforge/generators/blob/master/csharp/generate_csharp_bindings.py

    Der Generator für die Dokumentation sieht so aus: https://github.com/Tinkerforge/generators/blob/master/csharp/generate_csharp_doc.py

     

    Die sind beide für C#, nur so als Beispiel.

     

    D.h. wenn du eine Unterstützung für Delphi hinzufügen wolltest, müsstest du mindestens den Generator für die Bindings für Delphi schreiben.

     

    Gucks dir mal an, wenn du da Lust zu hast würde ich nochmal genau aufschreiben wie du da am Besten vorgehst und was genau zu tun ist etc.

  2. Die Board-to-Board Verbinder sind leider keine Standardteile, da haben wir nichts gefunden was gepasst hätte (Pinanzahl und Höhe etc). Wie oben schon geschrieben werden wir aber welche bei uns in den Shop stellen sobald die nächste Bestückung fertig ist. Wenn benötigt können wir auch ganze Reels verkaufen.

  3. Hab das Gerät hier und jetzt mal kurz getestet. Ich kriege das Olidata ding auf Anhieb nicht zum laufen (so rein gar nicht, auch nicht mit anderen Geräten, weder unter Linux noch unter Windows).

     

    Hab gerade keine Zeit mich damit Stunden zu beschäftigen, ich gucke es mir nächstes Wochenende noch mal an.

  4. 1. I'm guessing that none of your modules have a suitable processor or memory to replicate the functions of a Beagleboard or Raspberry Pi?

     

    2. If that's correct are there plans to do something hardware based to make this possible?  Timescales?

    That is right. I wouldn't preclude that we ever make a "Linux Brick", but that won't happen any time soon.

     

    3. If I am wrong in question 1 then could low level programming of your modules in the remove the need for the likes of a Beagleboard or Raspberry Pi controller and is there adequate memory and processor speed to do this?

    All Bricks have a processor speed of 64Mhz and the master has 256kb flash, that is definitely enough to program a robot. However, there is currently no documentation from us to do this. You will need to read the datasheets of the ICs we use etc. If you never did embedded C programming, this might be quite a challange (but its fun! If you want to learn embedded stuff, do it).

     

    4. If the only realistic option is only the likes of a Beagleboard or Raspberry Pi then I am currently at a loss on how to link them together.  Would the simplest thing be to link the usb lead from these boards to the controller brick and treat it like a pc controlling the board?  Are there other ways that would operate better?

    A Beagleboard or Raspberry Pi on your robot that has Bricks/Bricklets connected over USB seems to be the easiest solution currently. Of course that will also give you lots of processing power.

     

    An adapter between an embedded Linux board and Bricks, that allows to directly control Bricks/Bricklets without USB is planned, but the software effort necessary to implement this is not trivial. The complete stack communication of the Master Brick needs to be implemented in the Linux kernel for this.

     

  5. Den Akkuladezustand kannst du denke ich am besten anhand der Spannung feststellen (die fällt ab wenn der Akku leer wird). Die Spannung die am schwarzen Stecker auf dem Stepper Brick eingespeist wird kannst du mit get_external_input_voltage abfragen (oder get_stack_input_voltage, falls du durch einen Stack einspeist).

     

    Du kannst auch mit set_minimum_voltage eine minimale Spannung für dein Akku hinterlegen und bekommst dann ein UnderVoltage Signal, sobald die Spannung zu weit abfällt.

  6. Da die Frage danach schon öfter gekommen ist, denke ich wir werden alle Bauteile die keine Standardbauteile sind auch bei uns in den Shop stellen.

     

    Das wird allerdings erst nach der neuen Produktion passieren, wenn wir die übriggebliebenen Bauteile wieder haben. Wir haben im Moment keine nicht verlöteten Board-to-Board Stecker hier :-).

  7. Puh, das haben wir wie gesagt noch nie getestet. Ich kann da im Moment nichts zu sagen.

     

    Ich nehme an du hast sowas hier gekauft:

    http://www.amazon.de/Olidata-Wireless-USB-Set/dp/B002BX3LRI/ref=sr_1_1?ie=UTF8&qid=1326324313&sr=8-1 ?

     

    Ich bestell das mal und probier es mal selber aus. Da WUSB noch vergleichsweise neu ist könnte ich mir vorstellen das sie die USB Geräteklasse die wir verwenden noch nicht komplett unterstützten (Im Gegensatz zu Eingabegeräten, Massenspeicher etc).

  8. 1) Dokumentation in der Lib könnte man passend mit generieren. Ich schreibs mal auf die TODO-Liste, werde ich aber nicht in nächster Zeit zu kommen.

     

    2) Mit der enumerate Funktion von der IPConnection: http://www.tinkerforge.com/doc/Software/IPConnection_CSharp.html#example

     

    3) Die Reset Leitungen sind im Stack miteinander verbunden. D.h. wenn du den Reste Knopf bei einem beliebigen Brick betätigst werden alle Bricks im Stack neugestartet. Reset per Software auslösen geht im Moment nicht.

     

    4) Die Chibi Extension wird bis zu 255 Slaves unterstützten (d.h. ein Master+Stack+Chibi am PC und 255 Master+Stack+Chibi autonom, über Chibi vom PC gesteuert).

     

    PS: Ich arbeite gerade am Code der Chibi Extension, das sieht schon ganz gut aus! Sind nur noch ein paar Kleinigkeiten zu fixen.

  9. Ganz unterschiedlich.

     

    Bricklets haben Plugins auf dem EEPROM die vom Brick ausgelesen und ausgeführt werden. D.h. da können die Interrupts ganz normal vom Prozessor ausgelesen werden.

     

    Bricks die in einem Stack auf einem Master Brick sitzen kommunizieren über SPI mit dem Master, d.h. der Prozessor vom Stack Teilnehmer bekommt einen Interrupt und speichert den solange bis er vom Master Brick per SPI angesprochen wird.

     

    Bei Kommunikation über Extensions gibt es wiederum "echte" Interrupts (Da die Latenz über Funkkommunikation sowieso schon so hoch ist, ist das dort notwendig).

     

    Oben drüber sitzt dann nochmal das USB Protokoll. Bei USB wird leider immer vom PC gepollt, eine USB Datenübertragung kann nie von einem USB Device gestartet werden.

  10. Die Stecker sind von Anytek. Die auf der Platine sind aus der OQ Reihe und die zum reinstecken aus der KD Reihe. Beide 3.5mm pitch.

     

    OQ: http://www.anytek.com.tw/EN/search_product.aspx?cateid=&codename=oq&exflag1=3.5&exflag5=&page=1

    KD: http://www.anytek.com.tw/EN/search_product.aspx?cateid=&codename=kd&exflag1=3.5&exflag5=&page=1

     

    Den auf der Platine gibt es Vertikal. Du wolltest aber vermutlich eher den zum reinstecken im 90° Winkel haben oder? Das gibt es, wenn ich das richtig sehe, leider nicht.

  11. Ich denke wichtig ist eine gute Struktur im Wiki. Wer eine gute Idee hat etwas hinzuzufügen aber keinen passenden Platz dafür findet lässt es vermutlich lieber sein.

     

    Zur Sprache: Ich finde es wichtig das man vergleichsweise einfach vom deutschen zum englischen Teil des Wiki und wieder zurück kommt. Oft wird ja doch die eine oder andere Information in einer Sprache fehlen und es wäre schade wenn man dann nicht einfach an die englischen Inhalte kommt die man evtl. auch versteht.

     

    Ich werde am Mittwoch mal ein bisschen Struktur ins Wiki bringen und erste Inhalte schaffen. Die ist dann natürlich nicht für immer fest und wir können jederzeit wieder umräumen.

     

     

  12. Jeder Funktionsaufruf ist ein Befehl. D.h. eine Rampe mit Beschleunigung x, Endgeschwindigkeit y, Debeschleunigung z und 2500 Schritten sind drei Befehle (SetMaxVelocity, SetSpeedRamping und SetSteps).

     

    Das sind allerdings alles Setter, da ist die Latenz nicht so schlimm weil keine Nachricht zurück kommt.

     

    Angenommen du würdest DriveForward aufrufen, dann immer GetRemainingSteps und anhand der noch zu fahrenden Schritten die Geschwindigkeit verändern. Das geht sicher gut wenn man es direkt per USB anschließt, allerdings würde die Latenz über eine Funkverbindung Probleme machen (da der Schrittmotor einfach schon wieder viele Schritte gemacht hat bis der Getter antwortet und der neue Setter raus ist).

  13. Ist von uns noch ungetestet, sollte allerdings funktionieren. Es gilt das gleiche wie später auch für die Wireless Extensions: Die Latenzen der Nachrichten steigen stark, dadurch steigt die Roundtriptime von einer Nachricht (vom Programm zum Brick Daemon zum Brick und zurück vom Brick zum Brick Daemon zum Programm) von 1ms auf sowas wie 10ms oder höher.

     

    Das kann Regelungen die mit einer hohen Frequenz erfolgen müssen evtl. unmöglich.

  14. Das Breakout Bricklet kannst du nutzen um an die Pinne von einem Bricklet zu kommen, wenn du z.B. Arduino verwenden möchtest.

     

    Du kannst es auch nutzen wenn du es am Brick anschließt wenn du direkt C auf dem Brick programmieren möchtest. Vom PC aus kann man damit nichts machen. Es ist auch kein EEPROM drauf, d.h. es kann vom PC aus gar nicht erkannt werden.

  15. Hab das gerade getestet und hab in der Tat das gleiche Problem. Es sollte bis auf etwa 100mA runter gehen. Ich gucke mir das an.

     

    Edit: Das ließ sich schnell finden. Für unter 500mA müssen wir einen extra Widerstand schalten, das ist schlicht und ergreifend nicht implementiert. Ich werde das heute Abend schnell fixen. Du musst dann eine neue Firmware auf dein Stepper Brick flashen. Ich sag nachher nochmal Bescheid wenn ich die neue Firmware hochgeladen hab.

×
×
  • Neu erstellen...