Python mit TXT

[Techniker]

Hallo!

Ich habe die Community-Firmware installiert und möchte nun ein Python Programm schreiben.
Was ist dabei beim TXT zu beachten ( was muss da unabhängig vom Programm an sich rein)?
Und wie werden die Eingänge/Ausgänge bezeichnet?

[Torsten]

Hallo!

Ich habe die Community-Firmware installiert und möchte nun ein Python Programm schreiben.
Was ist dabei beim TXT zu beachten ( was muss da unabhängig vom Programm an sich rein)?
Und wie werden die Eingänge/Ausgänge bezeichnet?

Hallo,

beachten musst Du eigentlich nichts, Du musst nur die ftrobopy-Bibliothek am Anfang Deines Programmes importieren.
Die Ein- und Ausgänge haben Nummern:

für das motor-Objekt: 1 - 4 (entsprechend den Ausgängen M1 - M4 auf dem TXT)
für das output-Objekt: 1- 8 (entsprechend den Ausgängen O1 - O8)
für die input-Objekte: 1 - 8 (entsprechend den Eingängen I1 - I8)

ich weiss ja nicht genau, was für ein Programm Du schreiben möchtest, aber zum Testen und Ausprobieren könntest Du Dich per ssh auf dem TXT einloggen und eine interaktive Python-Session starten:

Code: Alles auswählen

ssh ftc@192.168.7.2
python

(nicht vergessen, das ssh-Kommando am TXT-Touch-Display zu bestätigen !)

Ein erstes kleines Programm zur Ansteuerung eines Motors am Ausgang M1 und zum Einlesen eines Tasters am Eingang I1 könnte dann so aussehen:

Du gibst die Befehle der Reihe nach interaktiv ein und sie werden jeweils sofort ausgeführt. Du kannst das kleine Programm natürlich auch auf Deinem PC eintippen und dann per scp-Befehl oder mit WinSCP auf den TXT kopieren

Code: Alles auswählen

scp myprogram.py ftc@192.168.7.2:myprogram.py

und Dich per ssh auf dem TXT einloggen und starten

Code: Alles auswählen

ssh ftc@192.168.7.2 
python myprogram.py 

Falls Du Dein Programm per ftc-GUI starten möchtest, findest Du weitere Anleitungen im Wiki auf der ftc-Seite (https://github.com/ftCommunity/ftcommun ... -first-app)

Code: Alles auswählen

import time
import ftrobopy

txt    = ftrobopy.ftrobopy('127.0.0.1', 65000)  # Verbindung über TCP herstellen
motor  = txt.motor(1)                           # Motor-Objekt erzeugen (Motor an M1 angeschlossen)
taster = txt.input(1)                           # Taster-Objekt erzeugen (Taster an I1 angeschlossen)

motor.setSpeed(200)                             # Geschwindigkeit des Motors auf 200 einstellen (max 512)
while taster.state() == 0:                      # Solange warten bis Taster gedrückt ist (Tasteranschlüsse 1 und 3 verwenden)
  time.sleep(0.01)                              # 10 ms warten (schneller sendet der TXT das Ergebnis nicht)
motor.setSpeed(0)                               # Geschwindigkeit des Motors auf 0 setzen

txt.stopOnline()                                # die TCP-Verbindung beenden
time.sleep(0.1)                                 # kurz warten, damit alle Prozesse die Chance haben, sich ordentlich zu beenden

weitere Beispiele findest Du auf den github-Seiten von ftrobopy: (https://github.com/ftrobopy/ftrobopy/tr ... r/examples).
Eine komplette Anleitung von ftrobopy mit allen Ein- und Ausgangsobjekten findest Du hier: (https://github.com/ftrobopy/ftrobopy/bl ... manual.pdf)

Torsten

[MasterOfGizmo]

Cool. Sowas wäre mit ein paar Screenshots sicher auch eine Wiki-Seite wert. Sich remote einloggen und dann interaktiv unter Python den TXT steuern hat durchaus Charme.

[Torsten]

Cool. Sowas wäre mit ein paar Screenshots sicher auch eine Wiki-Seite wert.

Ich schaue mal, ob sich da was machen läßt

Sich remote einloggen und dann interaktiv unter Python den TXT steuern hat durchaus Charme.

Noch praktischer ist das Ganze mit einem ipython-notebook, dass man dann interaktiv per Web-Browser bedienen kann. Ich hatte das ja im September auf der ftConvention bereits vorgeführt. Die Installation von ipython-notebook ist leider nicht ganz trivial, weil einiges cross-compiliert werden muss. Ich habe das bisher nur für die original fischertechnik Firmware gebaut. Ich schaue mal, ob ich das auch unter der community-Firmware ans Laufen bekomme.

Gruss
Torsten

[MasterOfGizmo]

Hi Torsten!

Sowas fände ich persönlich ziemlich cool. IPython und Snap!/Scratch sind m.E. wenn sie denn wirklich benutzbar integriert sind, Dinge, die wir direkt mit ausliefern sollten.

Wenn das im unbenutzten Zustand (also wenn man dann das iPython nicht nutzt) kein RAM und keine CPU braucht und auch den Bootprozess nicht bemerkenswert verlängert, dann würde ist sagen, dass wir das direkt in die Firmware einpflegen. Im buildroot-System gibt es sogar ein ipython, aber ich habe mir das nie genau angeschaut.

Und wenn IPython Hintergrundlast erzeugt, die man vermeiden will, wenn man's nicht nutzt, dann würde ich gerne eine Methode vorsehen, den Dienst per App zu aktivieren und de-aktivieren. Aber so global, dass ein einmal aktiviertes IPython auch beim nächsten Boot gleich gestartet wird bzw. andersrum beim De-aktivieren.

Ist nur meine persönliche Meinung, aber IPython, Snap!/Scratch und Co, also alle Arten von kompletter Online-Bedienbarkeit, sind m.E: echte Killer-Features, weil das den TXT komplett vom Handy/Tablet/wasauchimmer programmierbar macht und diese recht altmodische und aussterbendeAbhängigkeit vom PC auflöst.

Gibt's ein Video von Deiner IPython-Demo?

Edit: IPython lässt sich in der Builtroot-Umgebung aktivieren. Aber von ipython-notebook finde ich da nichts. Außerdem habe ich mir iPython-Notebook mal auf den PC getan. Ist in der Tat lustig. Da sollte man dann aber ein paar TXT-spezifische Notebooks gleich vorinstallieren, denke ich.

[richard.kunze]

Hallo zusammen,

ich geb mal auch meinen Senf dazu...

Sowas fände ich persönlich ziemlich cool. IPython und Snap!/Scratch sind m.E. wenn sie denn wirklich benutzbar integriert sind, Dinge, die wir direkt mit ausliefern sollten.

Das war - zumindest für mich - von Anfang an der Plan. Zumindest irgendeine Art IDE, die im Browser läuft und direkt vom TXT ausgeliefert wird. Und wenn es irgendwie geht auch so, dass der Browser auch auf einem Tablet (idealerweise sogar auf einem Smartphone) laufen darf und man trotzdem halbwegs vernünftig damit programmieren kann.

Und ich denke, mit IPython (für die Akademiker ) und irgendwas Scratch-ähnlichem (für die Leute mit Wischoberfläche und dafür ohne Tastatur) sind wir da ganz gut dabei. Wobei das "Scratch-ähnliche" so wie ich das aktuell plane aber wohl eher etwas auf Basis von https://developers.google.com/blockly/ werden würde statt eine Weiterentwicklung ft-robo-snap (im wesentlichen deshalb, weil man mit Blockly leichter Code erzeugen kann der direkt auf dem TXT läuft statt im Browser als mit Snap!).

Wenn das im unbenutzten Zustand (also wenn man dann das iPython nicht nutzt) kein RAM und keine CPU braucht und auch den Bootprozess nicht bemerkenswert verlängert, dann würde ist sagen, dass wir das direkt in die Firmware einpflegen.

Sehe ich genauso. Und allzuviele Resourcen (außer Platz auf der SD-Karte, und davon haben wir reichlich) sollte es auch nicht verbrauchen. Das meiste davon sind aus Sicht des Servers (d.h. des TXT-) einfach nur statische Daten, die bei Bedarf über das Webinterface ausgeliefert werden. Das schafft der TXT auch nebenbei.

Im buildroot-System gibt es sogar ein ipython, aber ich habe mir das nie genau angeschaut.

Das lohnt sich auch nicht. Das Ding in Buildroot ist IPython 2.0.4, und aktuell ist 5.0. Da macht es vermutlich mehr Sinn, wenn Torsten seinen IPython-Build für die Originalfirmware an die Community-Firmware anpasst.

[Torsten]

Wenn das im unbenutzten Zustand (also wenn man dann das iPython nicht nutzt) kein RAM und keine CPU braucht und auch den Bootprozess nicht bemerkenswert verlängert, dann würde ist sagen, dass wir das direkt in die Firmware einpflegen.

Sehe ich genauso. Und allzuviele Resourcen (außer Platz auf der SD-Karte, und davon haben wir reichlich) sollte es auch nicht verbrauchen. Das meiste davon sind aus Sicht des Servers (d.h. des TXT-) einfach nur statische Daten, die bei Bedarf über das Webinterface ausgeliefert werden. Das schafft der TXT auch nebenbei.

Ich habe mir das eben mal angeschaut: CPU-Zeit wird fast keine verbraucht. Allerdings ist der RAM-Bedarf nicht zu vernachlässigen. Ein auf dem TXT im Hintergrund laufender ipython3-Prozess mit Notebook Web-Oberfläche benötigt ca. 50MB im RAM und benötigt ca. 7 Sekunden um zu starten. Wenn man sich dann von aussen verbindet und ein Python3 Notebook aufmacht, wird ein weiterer Prozess (python-kernel) gestartet (1-2 Sekunden), der dann zusätzlich ca. 85 MB im RAM benötigt.

[...] Das Ding in Buildroot ist IPython 2.0.4, und aktuell ist 5.0. Da macht es vermutlich mehr Sinn, wenn Torsten seinen IPython-Build für die Originalfirmware an die Community-Firmware anpasst.

Ich habe damals die Version 4 von ipython gebaut, die bei mir sowohl unter der original- als auch unter der community-Firmware läuft. Hier ist eine Liste, der Pakete, die ich dafür installiert habe:
Jinja2-2.8 MarkupSafe-0.23 decorator-4.0.4 ipykernel-4.1.1 ipython-4.0.0 ipython.tgz ipython_genutils-0.1.0 ipywidgets-4.1.1 jsonschema-2.5.1 jupyter-1.0.0 jupyter_client-4.0.0 jupyter_console-4.0.3 jupyter_core-4.0.6 nbconvert-4.1.0 nbformat-4.0.1 notebook-4.0.6 path.py-8.1.2 pexpect-4.0.1 pickleshare-0.5 ptyprocess-0.5 pyzmq-14.7.0 qtconsole-4.1.0 setuptools-18.4 setuptools-scm-1.0.0 simplegeneric-0.8.1 tornado-4.2.1 traitlets-4.0.0 vcversioner-2.14.0.0

Da ich das alles ohne build-system von Hand gebaut habe, habe ich ein paar Stunden damit verbracht, bis alles lief. Kurzfristig könnte ich einfach mein ganzes Installationsverzeichnis irgendwo hochladen (ca. 250 MB). Eine saubere Installation mit buildroot wird sicher noch eine Weile dauern.

@Richard: Soweit ich mich erinnern kann, hattest Du Dir mein Installationsverzeichnis auf der ftConvention ja sogar schonmal kopiert oder ?

Gruss
Torsten

[richard.kunze]

Hallo Torsten,

Ich habe mir das eben mal angeschaut: CPU-Zeit wird fast keine verbraucht. Allerdings ist der RAM-Bedarf nicht zu vernachlässigen. Ein auf dem TXT im Hintergrund laufender ipython3-Prozess mit Notebook Web-Oberfläche benötigt ca. 50MB im RAM und benötigt ca. 7 Sekunden um zu starten.

Echt so viel? Was macht das Ding denn in dem ganzen Speicher?
Auf jeden Fall ist das ein Argument dafür, das nicht immer im Hintergrund laufen zu lassen sondern nur auf Anforderung. Eventuell sogar in eine App "verpackt" (so ähnlich wie die originale FT-GUI), dann hätte man während iPython läuft auch den Touchscreen für die Programme aus dem Notebook frei.

Da ich das alles ohne build-system von Hand gebaut habe, habe ich ein paar Stunden damit verbracht, bis alles lief. Kurzfristig könnte ich einfach mein ganzes Installationsverzeichnis irgendwo hochladen (ca. 250 MB). Eine saubere Installation mit buildroot wird sicher noch eine Weile dauern.

Ich denke ich probiers mal. Auch wenn ich eigentlich aktuell eher daran arbeite, von Buildroot wegzukommen. Aber eine Weihnachtsedition der Community-Firmware mit Direct-Mode für ftrobopy und eingebautem iPython hätte schon was...

Wenn die Pakete selbst keine allzu exotischen Buildsysteme verwenden, dann ist das recht schnell in Buildroot eingebaut. Und wenn irgendwo irgendwas beim Crosscompile zu arg rumzickt, dann frag ich den Experten, der das alles schon mal gebaut gekriegt hat

@Richard: Soweit ich mich erinnern kann, hattest Du Dir mein Installationsverzeichnis auf der ftConvention ja sogar schonmal kopiert oder ?

Ja, das hab ich hier alles noch liegen.

PS und etwas Off-Topic: Was hältst Du davon, wenn ftrobopy bei einer Initialisierung ohne Parameter automatisch versucht herauszufinden, in welcher Umgebung es läuft (TXT mit Community-/Original-Firmware, PC, ...) und dann selbst den passenden Modus auswählt? Das dürfte vor allem interessant sein, wenn man TXT-Apps am PC entwickelt und online (über die ROBOPro-Schnittstelle) testet, und sie dann später autonom auf dem TXT (dann im direct-Mode) laufen lässt. So wie es aktuell ist, muss man da entweder immer im Quelltext Parameter ändern, oder halt genau die Logik für die Umgebungserkennung selbst programmieren.

[Torsten]

Hallo Richard,

Was hältst Du davon, wenn ftrobopy bei einer Initialisierung ohne Parameter automatisch versucht herauszufinden, in welcher Umgebung es läuft (TXT mit Community-/Original-Firmware, PC, ...) und dann selbst den passenden Modus auswählt? Das dürfte vor allem interessant sein, wenn man TXT-Apps am PC entwickelt und online (über die ROBOPro-Schnittstelle) testet, und sie dann später autonom auf dem TXT (dann im direct-Mode) laufen lässt. So wie es aktuell ist, muss man da entweder immer im Quelltext Parameter ändern, oder halt genau die Logik für die Umgebungserkennung selbst programmieren.

Die Idee finde ich super und habe sie auch schon eingebaut

Code: Alles auswählen

txt = ftrobopy.frobopy('auto', special_connection='10.0.2.7')

(der special_connection parameter steht für die IP-Adresse des TXT im privaten Heimnetzwerk, mir ist noch kein besserer Name eingefallen. Diese Adresse wird als Letztes ausprobiert, wenn alles Andere fehlschlägt.)

Wenn TxtControlMain noch läuft, wird automatisch auch die '127.0.0.1' verwendet. Ich habe noch keine Sicherheitsabfrage für die Camera eingebaut, die ja im 'direct'-Modus anders angesprochen werden muss.

Gruss
Torsten

[MasterOfGizmo]

Wie wäre es denn, wenn die Commuity-Firmware auf irgendwelche magischen Broadcast-Pakete reagieren würde? Dann könnte man das im LAN sogar auto-konfigurierend machen und die ftrobopy würde selbst rausbekommen, unter welcher IP der TXT erreichbar ist.

Damit könnte sich dann auch zwei TXTs automatisch gegenseitig finden etc. Bei einem Kinderspielzeug mit IP-Adresse hantieren zu müssen ist ja eh schon etwas knifflig. Kann man dann später auch für eine Handy-App nutzen, die den TXT alleine findet und dann den Browser entsprechend öffnet.

[MasterOfGizmo]

Wobei das "Scratch-ähnliche" so wie ich das aktuell plane aber wohl eher etwas auf Basis von https://developers.google.com/blockly/ werden würde

Oh, ja, JA!! Genau sowas ist toll. Möglichst simpel. Wer mehr will nimmt dann iypthon-notebook. Wer noch mehr will schreibt python-Apps. Und wer's ganz hart will nimmt den Cross-Compiler aus der Build-Umgebung und codet in C. Das hätten wir dann alles recht sauber integriert. Das ist dann auch vom didaktischen Aspekt absolut rund.

Ich habe eh nie verstanden, warum RoboPro immer komplexere Dinge kann. Für Anfänger ist das ja prima. Aber wer baut denn echt komplexe Dinge freiwillig in RoboPro? Das ist weder effizient noch lernt man da dann noch was sinnvolles ...

Blockly kann ja sogar mit Server-Side-Execution laufen lassen. Und es kann Python-Code erzeugen. Das klingt alles perfekt.

[MasterOfGizmo]

Hab' mal aus Spass blockly in ein App-ZIP gewickelt:
http://harbaum.org/blockly.zip

Hab' s selbst auf dem TXT noch nicht getestet, sondern nur auf dem PC. Ist auch wieder so ein 22MB-Riesen-Install.

Wenn man's installiert hat geht man per Web-Browser auf den TXT, dort zur "Blockly"-App und klickt auf "Open local application pages".