CFW: Brickly (war Blockly)

[MasterOfGizmo]

Dies ist die Forführung der Diskussion aus dem "Python mit TXT"-Thread.

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"

Da stellt sich dann recht schnell die Frage, ob man das Server-seitig (also auf dem TXT) oder Client-seitig (also auf dem PC/Tablet/Handy) ausführen lassen will. Intuitiv hätte ich erstmal Server-seitig gesagt, da man ja möglichst latenzarm den TXT steuern will. Aber das erschwert im Gegenzug alles, was man dann mit dem Client machen will. Also 'ne schöne Modell-spezifische GUI im Browser.

[MasterOfGizmo]

Das hier ist dann wohl die Vereinigung von Snap/Scratch und Blockly und sieht mal verdächtig wie die Lego-WeDo-GUI aus ...

https://github.com/llk/scratch-blocks

[MasterOfGizmo]

OMFG: Mal eben Scratch-Blocks anschauen: 100MB download ... Bin ich der einzige, der das etwas übertrieben findet, was die Frameworks inzwischen so an Speckschicht mit sich rumtragen.

[richard.kunze]

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

Da ist ja auch ein Haufen Zeug bei, das wir eigentlich gar nicht brauchen - insbesondere die (unkomprimiert) gut 23 MB in "demos", der Grossteil der 3.6 MB in "msg" (auch wenn ich die Community-Firmware gerne sauber internationalisieren will werden wir die allermeisten da vertretenen Sprachen so schnell wohl nicht brauchen) und die kompletten 3.6 MB in "tests". Was übrig bleibt ist nicht mehr so arg groß, und - auch wenn ich mir das noch nicht genau angeschaut habe - dazu auch noch wohl zu einem großen Teil redundant.

Ich vermute, am Ende brauchen wir von dem ganzen Kram nur "blockly_compressed.js" (und das bringt dann grade mal etwas über 600kB auf die Waage) und etwas eigenes HTML und Javascript drumrum um daraus ein System zu bauen mit dem man auch Modelle steuern kann. Aber viel mehr als ein MB alles zusammen wird das wohl eher nicht werden.

Da stellt sich dann recht schnell die Frage, ob man das Server-seitig (also auf dem TXT) oder Client-seitig (also auf dem PC/Tablet/Handy) ausführen lassen will. Intuitiv hätte ich erstmal Server-seitig gesagt, da man ja möglichst latenzarm den TXT steuern will.

Ganz klar serverseitig. Clientseitig hätte ich auch genausogut mit Snap! weitermachen können.

Der wesentliche Grund, warum ich mit Blockly was neues anfangen will ist, dass Blockly nicht nur (anders als Snap!) von vornherein darauf ausgelegt ist, aus den Blöcken Code in einer "traditionellen" Sprache zu generieren, sondern sogar schon einen fertigen Codegenerator für Python mitbringt.

Aber das erschwert im Gegenzug alles, was man dann mit dem Client machen will. Also 'ne schöne Modell-spezifische GUI im Browser.

So arg schwer ist das auch nicht. Auf "Blockebene" läuft das auf die "üblichen Verdächtigen" raus (Sprites, sowas wie "Turtle Graphics" für deren Bewegung, Bilder, mit denen man Sprites "kostümieren" kann, irgendeine Art Textausgabe, ...), und die Implementation untendrunter ist ein bißchen Fingerübung in Javascript und Websockets.

Aber das ist denke ich auch ziemlich nachrangig. Scratch-artige Systeme, die irgendwelche Bilder im Browser hin- und herschieben gibts inzwischen wie Sand am Meer. Und einige davon sind verdammt beeindruckend - schau dir z.B. mal https://blockly-games.appspot.com/ an, das ist ein kompletter Anfänger-Programmierkurs mit Blockly, als Browserspiel verpackt. Und es macht echt Spaß Mit sowas kann (und will) ich gar nicht konkurrieren.

Ich will auf was anderes raus: Einen Code-Editor, mit dem man vollwertige Apps für die Community-Firmware entwickeln kann. Vielleicht nicht so komplex wie deinen Rubiks-Cube-Solver, aber für den Anfang allemal auf dem Level der Roboter aus dem TXT Discovery Set. Und dafür braucht man am Anfang vor allem die IOs (haben wir, macht ftrobopy), dann das lokale Display (da verpackt man dann halt QT-Widgets in passende Blöcke, für den Anfang dürfte da sogar eine simple Message-Box und vielleicht eine Dialogbox reichen) und vielleicht Gimmicks wie Soundausgabe (Basis: Dein MP3-Player). Blöcke für Kameraansteuerung, Bilderkennung, Zeug am I2C-Bus, sonstige Hardware und so weiter kann man immer noch später nachrüsten.

Wichtig ist meiner Meinung nach erst mal ein sauberes Programmiermodell als Basis. Und das darf durchaus fortgeschritten sein: Für Modellsteuerung drängt sich ein eventgetriebenes Programmiermodell schließlich quasi auf - und das läßt sich zum einen in blockorientierten Sprachen auch richtig schön intuitiv umsetzen. Das ist da mehr oder weniger das natürliche Modell (zumindest wenn man von Scratch das Konzept des "Hut-Blocks" am Anfang jedes Blockstapels borgt, der dann auf irgendwelche Events anspringt und den zugehörigen Codeblock triggert).

Und die naheliegende Umsetzung "nach hinten raus" ist dann ebenso natürlich ein Python-Programm, das beim Start anfängt auf Events zu lauschen und die dann passend auf die einzelnen Codeblöcke verteilt. Die natürlich jeweils in einem eigenen Thread laufen. Und sich gegenseitig durch Abschicken eigener "Events" triggern.

Der Nutzer sieht davon natürlich erst mal nicht viel - nur seine Codeblöcke. Von denen wird einer halt auf irgendeine magische Art und Weise aufgerufen, wenn jemand auf den Schalter an I1 drückt, und startet dann den Motor an M1. Und der andere Codeblock wird aufgerufen, wenn C1 > 100 ist, und stoppt den Motor wieder.

Et voila, eine waschechte Multi-Thread-Modellsteuerung mit Kommunikation per Message Passing, programmiert von einem Anfänger.

Und wenn man erst mal so weit ist, ist der Schritt zu einem verteilten System auch nicht mehr weit - da löst man dann halt ein Event aus, das einen Codeblock auf einem anderen TXT (oder im Browser - bzw in irgendeinem der Browser, die vielleicht gerade mit der laufenden Applikation verbunden sind) anstößt.

Und wenn der Anfänger irgendwann mal kein Anfänger ist, bleibt ihm immer noch eine saubere, nach dem aktuellen Stand der Technik programmierte TXT-App in Python als Basis für weitere Experimente und Erweiterungen. Die fällt bei der Blockly-App nämlich als "Objektcode" hinten raus

[MasterOfGizmo]

Na da sind wir uns ja ziemlich einig. Wenn ich Zeit habe schaue ich mal, wie man remote-Python aus Blockly ausführt.

Gestern habe ich spasseshalber noch eine QT-GUI aus einem ipython-notebook heraus erzeugt. Mal abgesehen von der Tatsache, dass der IPython-Core exakt jedes zweire Mal abgestürzt ist hat es erstaunlich gut funktioniert. Da ist mit ein paar Beispielen und ein paar simplen Wrappern sicher viel anfängertaugliches zu machen.

Und ja, ein paar Sprites und etwas Turtle-Graphics ist für Blockly sicher ein guter Start. Aber z.B. den Programmlauf durch Highlights der Blocky-Graphic zu visualisieren dürfte nicht ganz trivial sein. Aber das kann Blocky wohl eh nicht, auch nicht wenn's Client-seitig läuft.

[MasterOfGizmo]

Hier mal ein Screenshot von Blockly (live von meinem TXT), um mal einen Eindruck zu geben:



Das ist ein wenig wie das WeDo oder RoboPro, aber alles im Browser und damit auch von Tablet oder Handy nutzbar. Man programmiert graphisch per drag'n drop.

[richard.kunze]

Na da sind wir uns ja ziemlich einig. Wenn ich Zeit habe schaue ich mal, wie man remote-Python aus Blockly ausführt.

Dafür haben wir doch schon unseren Launcher. Sogar fix und fertig mit Webinterface zum starten von Apps

So wie ich mir das vorstelle, gibts in unserem Blockly-System (das braucht übrigens noch eine vernünftigen Namen - mir fällt da spontan "RoboBlocks" ein, was haltet ihr alle davon?) irgendwo vier Knöpfe:

• "New App": Fragt die App-Metadaten (Name, Modell, Icon, ...) ab, generiert eine UUID und macht einen leeren Blockly-Workspace auf.
• "Save": Schmeisst den Code-Generator an um aus den Blöcken Python zu erzeugen, packt das Resultat zusammen mit den "Sourcen" (d.h. Blockdefinition in XML, oder was auch immer Blockly verwendete um seinen Workspace zu persitieren), den App-Metadaten und statischem Python (für Framework und "main"-Script) in ein Zip-Archiv (bis hierher noch alles im Browser und in Javascript) und lädt das Resultat dann über unser Webinterface hoch (geht per Javascript, ist ja schließlich nichts weiter als ein popeliger Post-Request). Eventuell kann man da unser Webinterface aufbohren dass man auch einzelne Files in einer App direkt hochladen kann, aber das muss denke ich nicht mal sein.
• "Load": Listet die RoboBlocks-Apps auf dem TXT auf (wieder Webinterface, eventuell etwas aufgebohrt damit wir da auch die Programmiersprache aus den Metadaten der Apps kriegen um die Liste passend zu filtern), lädt dann die Metadaten und Blockdefinitonen der ausgewählten App und macht eine passend initialisierten Workspace auf.
• "Run": Macht erstmal dasselbe wie "Save" und schmeißt dann die App per Webinterface an. Ist im wesentlichen Convenience, "Save" und dann auf dem Touchscreen im Launcher auf das passende Icon drücken hat denselben Effekt.

Eventuell kann man da irgendwo noch eine "Stop"-Funktion über das Webinterface nachrüsten (und passend in RoboBlocks anbinden), aber für den Anfang kann man genausogut auch kurz auf den großen blauen Knopf am TXT drücken um eine durchgehende RoboBlocks-App wieder anzuhalten. So wie mit jeder anderen App auch halt.

Und - anders als iPython, das auch im "Leerlauf" auf dem TXT ordentlich Resourcen braucht - würde ich RoboBlocks selbst immer permanent "mitlaufen" lassen. Das ist aus TXT-Sicht letztendlich schließlich nichts anderes als eine paar weitere statische Inhalte, die bei Bedarf halt über das ohnehin laufende Webinterface rausgegeben werden. Das, was da dann wirklich Resourcen verbraucht (und sich gegebenenfalls mit irgendwas anderem um Touchscreen, IOs und so weiter streitet) sind "ganz normale" ftcommunity-Apps, um die sich der Launcher kümmert.

Und ja, ein paar Sprites und etwas Turtle-Graphics ist für Blockly sicher ein guter Start.

Ich würde eher mit Motor-IO und ein paar simplen Textaus- und -eingaben (Messagebox, Dialogbox) anfangen. Eventuell noch Soundfiles abspielen (weils ein nettes Gimmick und einfach umzusetzen ist). Komplexere Widgets auf dem Touchscreen dann später, und Turtlegrafik und so weiter im Browser zuletzt (das ist nett um z.B. einen Roboter im Browser live eine Landkarte der Umgebung zeichnen zu lassen, aber wichtig sind auf dem TXT denke ich eher die anderen Sachen).

Aber z.B. den Programmlauf durch Highlights der Blocky-Graphic zu visualisieren dürfte nicht ganz trivial sein. Aber das kann Blocky wohl eh nicht, auch nicht wenn's Client-seitig läuft.

Doch, Blockly (bzw. auf Blockly basiernde Sachen) können das durchaus - siehe z.B. https://blockly-games.appspot.com/

Und so arg schwer ist das in unserem Fall auch nicht. Den clientseitigen Teil können wir uns bei existierenden Implementationen abgucken (wenn es nicht eh schon dokumentiert ist - die Doku von Blockly ist ziemlich gut und umfangreich), und für den serverseitigen Teil können wir in einem naiven ersten Ansatz einfach den generierten Python-Code mit passenden "Highlight An/Aus"-Aufrufen um die einzelnen Codeabschnitte instrumentieren, die dem Browser dann sagen, welchen Block er gerade aufleuchten lassen soll (die passende Netzwerkverbindung - vermutlich am simpelsten ein Websocket - kann der Browser nach dem Start der App per App-lokaler HTML-URL aufmachen - braucht halt eine kleine Erweiterung im Webinterface, um Requests dynamisch an die gerade laufende App durchschleifen zu können).

Macht halt den generierten Code etwas hässlicher wenn da überall die Instrumentierungen drin sind, aber das kann man ja über einen Schalter lösen, mit dem man zwischen "Debugmode" und "schönem Python-Code" umschalten kann. Oder wir generieren einfach immer gleich beide Versionen, und entscheiden dann beim/nach dem App-Start welcher Variante verwendet wird (z.B. danach, ober der Browser den Debug-Websocket aufmacht oder nicht).

Oder wir machen gleich das ganz grosse Fass auf, und bauen uns einen echten Einzelschritt-Modus mit grafischer Anzeige über den Python-Debugger. Wäre wohl die eleganteste Lösung, aber vermutlich auch die aufwändigste.

[MasterOfGizmo]

RoboBlocks finde ich gut. Mein erster Arbeitsname war Roboly ....

[MasterOfGizmo]

So, viele Sachen brauchen wir also gar nicht.

Ja, man kann zwar direkt per TCP mit dem launcher kommunizieren, aber das geht aus Javascript nicht so ohne weiteres. Aber wir haben ja einen Web-Server, der Python-CGI ausführt. Genau das nutzt ja das aktuelle Web-Interface auch, wenn es anzeugt, welche App gerade läuft und wenn man eine neue App startet oder die laufende stoppt. Diese Scripte müssen ja nur ein wenig aufgebohrt werden, damit man aus dem Javascript raus den "Objectcode" 'post'en und dann starten kann.

Bisher bin ich davon ausgegangen, dass auf TXT-Seite eine Art Blockly-Master-App läuft, die diesen ganzen Kram abwickelt. Aber Du hast recht, man kann die Blockly-Programme als ganz normale TXT-Apps auftauchen lassen. Bei einem "New" veranlasst man den Webserver, ein App-Template inkl. manifest und allem anzulegen und bei "save" wird einfach das darin enthaltene Python-Script ersetzt. Dann könnte man später das Program auch direkt am TXT starten. Das gefällt mir immer besser und dürfte noch nichtmal sehr aufwändig sein ...

[MasterOfGizmo]

Ich habe noch ein wenig rumexperimentiert. Es sieht jetzt so aus und nennt sich nun "Brickly":



Das Ganze ist z.B. sehr bequem mit einem einfachen Android-Tablet zu bedienen.

Video dazu: https://www.youtube.com/watch?v=5yJAkeNl9z8

Das hat zunächst nur wenig mit Richards RoboBlocks zu tun, könnte aber irgendwann auf die gleiche technische Basis rauslaufen. Allerdings verfolgen wir sehr verschiedene Ziele, die sich m.E. aber prima ergänzen. Ich will das hier weiter vereinfachen und das möglichst simpel halten. Richard baut auf der gleichen Blockly-Technik ein wesentlich leistungsfähigeres System. Am Ende wird man so mit etwas Glück etwas ganz simples für kleine Kinder auf der einen Seite haben und die große Version, die dann mehr in Richtung RoboPro-Ersatz geht.

Die aktuelle Testversion von Brickly gibt es im App-Store der Community-Firmware.

[MasterOfGizmo]

Neu in Version 1.03:
- Deutsche Texte etwas angepasst
- Neuer Block "spiele Geräusch""

[raspberrypi]

Wird es in Brickly auch Blöcke für Bilderkennung geben? Das wäre für mich persönlich erst dann ein Grund, Brickly zu verwenden. Ansonsten ist das das "Killerfeature", was ROBOPRo aktuell Benutzerfreundlich anbietet.

[MasterOfGizmo]

Ist technisch kein Problem, kommt aber eher nicht in brickly. Brickly ist für Grundschulkinder. Da ist bestenfalls eine einfache Farberkennung brauchbar. Komplette Bilderkennung ist eher was fuer RoboBlocks. Wobei RoboPro da nicht das Mass der Dinge ist. Die Bilderkennung dort kann ja angeblich auch nicht sehr viel. Hab ich aber selbst nie gesehen muss ich zugeben. Auf unserem Kinder-Pc laeuft RoboPro nicht so toll. Das ist einer der Gründe für Brickly.

[raspberrypi]

Die Bilderkennung in RoboPro ist von der Bedienerfreundlichkeit auf jeden Fall deutlich komfortabler als zum Beispiel OpenCV, das ist aber klar...
Es gibt zwar keine Funktionen wie die Kantenerkennung oder dem Vergleichen von Bildern, aber Elemente wie Linienerkenner oder Farberkenner sind ganz gut realisiert und sind auch für Unerfahrene mit etwas Herumprobieren ganz gut zu verwenden. Aber "nicht viel" ist immerhin etwas womit sich arbeiten lässt - wobei die Kamera bei mir der haubt Kaufgrund für einen TXT im Gegensatz zu einem billigeren TX war.

[richard.kunze]

Wird es in Brickly auch Blöcke für Bilderkennung geben?

Ist technisch kein Problem, kommt aber eher nicht in brickly. Brickly ist für Grundschulkinder. Da ist bestenfalls eine einfache Farberkennung brauchbar. Komplette Bilderkennung ist eher was fuer RoboBlocks.

In RoboBlocks wird es ganz bestimmt Blöcke für Bilderkennung geben. Wie das genau aussehen wird und was da alles reinkommt weiß ich allerdings noch nicht - da muss man vermutlich etwas experimentieren um die richtige Balance zwischen "interessante Funktionalität" und "anfängertauglich" herauszubekommen.

Und es wird wohl auch eher nicht in der ersten Version von RoboBlocks kommen. Die will ich rausbringen, sobald ich die Grundfunktionen (Programme laden/bearbeiten/speichern/starten) und einen minimalen Satz an "I/O-Blöcken" für die Ansteuerung von Motoren, Schaltern und Lampen fertig habe.

[MasterOfGizmo]

Es geht ja nicht darum RoboPro nachzubilden. Da ist es wie mit der Originalfirmware: Wer damit zufrieden ist hat keinen Grund umzusteigen. Die Blockly-basierten Ansätze zielen primär auf ganz andere Features, wie eben die Nutzung per Handy oder Tablet. Wenn Du sowieso einen Wndows-PC hast und dafür nutzt und auch RoboPro schon besitzt und damit zufrieden bist, dann bist Du erstmal zumindest nicht meine Zielgruppe.

Aber ich hatte heute ein krankes Kind hier und habe es mit TXT, ein paar Lampen, einem Taster und dem Tablet völlig unkompliziert auf dem Sofa rumspielen lassen können. Das war der erste echte Einsatz von Brickly und es hat erstaunlich reibungslos funktioniert. Das wäre mit einem PC kaum so probemlos gewesen, nehme ich an.

Das beste an Blockly und Co ist, dass alles offen und mit wenig HTML-, Javascript- und Python-Kenntnissen erweiterbar ist. Wer gerne Bilderkennungs-Blocks haben möchte kann sie theoretisch jederzeit auch selbst nachrüsten bzw. jemanden mit genug Know-How überreden.

[Torsten]

Die Bilderkennung in RoboPro ist von der Bedienerfreundlichkeit auf jeden Fall deutlich komfortabler als zum Beispiel OpenCV, das ist aber klar...
Es gibt zwar keine Funktionen wie die Kantenerkennung oder dem Vergleichen von Bildern, aber Elemente wie Linienerkenner oder Farberkenner sind ganz gut realisiert und sind auch für Unerfahrene mit etwas Herumprobieren ganz gut zu verwenden. Aber "nicht viel" ist immerhin etwas womit sich arbeiten lässt - wobei die Kamera bei mir der haubt Kaufgrund für einen TXT im Gegensatz zu einem billigeren TX war.

Das aktuelle ftrobopytools ( https://github.com/ftrobopy/ftrobopy/bl ... pytools.so )

enthält unter anderem auch einen Linienerkenner und einen Farberkenner, der unter Python relativ einfach abgefragt werden kann.

Voraussetzung ist, das das Python-Programm im Download-Modus auf dem TXT ausgeführt wird (die ftrobopytools.so Library ist bisher nur für den TXT compiliert, PC wäre aber auch möglich).

Ich denke, das wäre recht einfach in RoboBlocks oder Blockly einzubauen.

Viele Grüße
Torsten

Code: Alles auswählen

import time
import ftrobopytools.so

# initialize camera (/dev/video0)
fps    = 15  # frames per second
width  = 320 # width of camera image
height = 240 # height of camera image
videv  = ftrobopytools.camInit(fps, width, height, 0, 0)
time.sleep(2) # give camera some time to adjust to brightness

# detect lines along horizontal line
yhorizon       = 100 # horizontal line y coord
xmin           = width + 20
xmax           = width - 20
min_line_width = 3  # minimum width of detected lines
max_line_width = 20 # maximum width of detected lines
numlines       = 5  # number of lines to detect (max 5)
threshold      = 30 # threshold value for contrast
brightness     = 20 # brightness of lines
lines=ftrobopytools.detectLines(videv, width, height, horizon, min, xmas, min_line_width, max_line_width, numlines, threshold, brightness, 0)
print("found ", len(lines), " lines along horizonal" )
for k in range(len(lines)):
  print("line ", " nr. ", k," :")
  print("position (center of line) = ", lines[k][0])
  print("width of line             = ", lines[k][1])
  print("red value                 = ", lines[k][2])
  print("green value               = ", lines[k][3])
  print("blue value                = ", lines[k][4])

# measure average red, green, blue color within a rectangular region of the image
xtopleft         = 20
ytopleft         = 20
xbottomright     = 80
ybottomright     = 80
red, green, blue = ftrobopytools.measureRGBColor(video, width, height, xtopleft, ytopleft, xbottomright, ybottomright, 0)
print("average red, green and blue color = ", red, green, blue)

ftrobopytools.camClose(videv)


[MasterOfGizmo]

Klingt interessant. Blockly/Brickly führt so wie wir das vor haben den Code immer auf dem TXT aus. Wäre also kein Problem.

[Torsten]

Klingt interessant. Blockly/Brickly führt so wie wir das vor haben den Code immer auf dem TXT aus. Wäre also kein Problem.

Die ftrobopytools-Library (mir ist noch kein besserer Name eingefallen) ist für mich einfach eine lose Sammlung von "C"-Routinen mit Python-Interface, die in reinem Python zu langsam wären, also z.B. Bildverarbeitung, Camera Framegrabbing, Ansteuerung des TXT-Displays, u.s.w. Man könnte natürlich einfach opencv verwenden. Ich wollte aber etwas kleines Kompaktes haben. Ausserdem wollte ich selbst einfach mal ein bisschen mit Bilderkennung herumspielen.
Die Library kann für Python2 oder für Python3 cross-compiliert werden. Die ftrobopytools.so auf github ist für Python2 übersetzt, wenn ich mich richtig erinnere.

[PHabermehl]

Hallo MasterOfGizmo,
ich habe Brickly gerade installiert, das ist ein wunderbarer Einstieg für die Kids, denke ich.
Vielen Dank an Dich für die bisherige Arbeit.
Kannst du schon sagen, wie es mit der App weitergeht? Speichern und Laden von Programmen wäre toll. Du hast schon Mathe-Operatoren eingebaut, gibt es demnächst auch Variablen? Und wird man z.B. Encoder-Motoren steuern können?
Start und Stopp des Programmes ohne Trennen der Verbindung wäre auch toll.
Fragen über Fragen, aber das liegt daran, daß ich von dieser universellen und einfachen Lösung sehr angetan bin...
Gruß
Peter