fischertechnik community forum

Hallo zusammen,

hier der Thread für "RoboBlocks", unsere künftige Scratch-Variante auf dem TXT. Ein paar erste Gedanken dazu gibt es hier und dort, und alles was sich generell mit browserbasierten Entwicklungsumgebungen auf dem TXT beschäftigt statt mit spezifischen Varianten davon gehört da hin. Hier geht es speziell um RoboBlocks.

MoG hatte hier diese klasse Idee gehabt:

Was wir auch gebrauchen können wäre jemand, der sich mit CSS und SVG prima auskennt und dem ganzen Web-seitig einen FT-Style verpasst. Diese Steckverbinder in Blockly schreien ja quasi danach, wie FT-Zapfen auzusehen ... So jemanden gibt es hier doch bestimmt, oder?

Ich denke, das sollten wir machen. Allerdings gibt es ein paar Nebenbedingungen, die wir dabei beachten sollten:

• Die Blöcke sollten zwar einen "Fischertechnik-Look" haben, aber trotzdem noch erkennbar "Scratch-artig" aussehen
• Wir sollten die Erfahrungen der Blockly-Designer (die findet ihr - auf Englisch - hier) berücksichtigen. Bei einem "Fischertechnik-Look" ist da denke ich insbesondere der Punkt zu symmetrischen Verbindern wichtig, weil Fischertechnik-Zapfen halt immer gleich aussehen, es aber für eine Block-Sprache vorteilhaft ist, wenn waagrechte Verbinder anders aussehen als senkrechte.
• Nicht zu doll mit Farben austoben. Will sagen: Innerhalb eines Blocks nur eine Farbe verwenden (und wenn möglich auch nicht zu viele Schattierungen). Die verschiedenen Farben brauchen wir nämlich, um die Kategorie anzuzeigen, zu der der Block gehört (Kontrollstrukturen, Motorsteuerung, Input-Abfrage, Grafik- und Tonausgabe, Variablen, Funktionen, Datenstrukturen, ...)
• ... und bestimmt ganz viel, das ich vergessen habe. Ich bin nämlich alles mögliche, aber ganz bestimmt kein Designer.

Und wegen dem letzten Punkt ist das auch etwas, wo wir prima Hilfe gebrauchen können. Wenn sich hier also jemand mit Grafikdesign allgemein (oder sogar mit UI-Design im speziellen) auskennt: Bitte hier mitduskutieren. Dafür braucht man auch keine Programmierkentnisse, was wir hier zuerst brauchen ist ein schlüssiges Layout für die Blöcke.

Hallo,
Ihr dreht aber gerade am ganz grossen Rad! (Jupyter, Blockly, ...)
Zum Thema Blockly/Snap/Scratch, die ja alle in eine aehnliche Klasse fallen, kann ich nur sagen.
Am besten orientiert man sich am Scratch Stil - relative simple Symbole, innerhalb der Symbole nur leichter 3D Effekt und wenig Gebrauch von Farben. Die Verbinder würde ich lassen wie bei Scratch. Die o.a. Programme nutzen recht kräf'tige Farben um verschiedene Funktionsgruppen von einander abzutrennen. Das gefällt mir eigentlich ganz gut.
Zwei Vorschläge:
1 - Alle fischertechnik spezifischen Blöcke in fischertechnik rot (grau für die Puristen ist schon belegt)
2 - Die fischertechnik spezifischen Blöcke in die jeweiligen Kategorien einsortieren (Z.B. sensing) und mit eine grauen breiten Rand kenntlich machen.

Gruesse Joachim

PS: Kennt Ihr blockPy von Virginia tech_ http://think.cs.vt.edu/blockpy/

Hallo Joachim,

jona2004 hat geschrieben:Ihr dreht aber gerade am ganz grossen Rad! (Jupyter, Blockly, ...)

Na ja, zumindest für mich war eine webbasierte Scratch-Entwicklungsumgebung für den TXT (bzw. genauer: Der Wunsch meines Ältesten nach einer solchen) der Auslöser, um überhaupt anzufangen für den TXT Software zu basteln. Und die Community-Firmware ist halt langsam so weit, dass man da sowas auch integrieren kann.

jona2004 hat geschrieben:Zum Thema Blockly/Snap/Scratch, die ja alle in eine aehnliche Klasse fallen, kann ich nur sagen.
Am besten orientiert man sich am Scratch Stil - relative simple Symbole, innerhalb der Symbole nur leichter 3D Effekt und wenig Gebrauch von Farben. Die Verbinder würde ich lassen wie bei Scratch.

Sehe ich ähnlich - mit einer Ausnahme: Gerade bei den Verbindern unterscheiden sich die diversen Scratch-Varianten doch erheblich - vergleich nur einfach mal Scratch und Blockly. Da denke ich, dass man da ruhig ein wenige "Fischertechnik-Look" reinbringen kann. Ob das klappt weiss ich natürlich nicht, aber einen Versuch ist es allemal wert.

jona2004 hat geschrieben:Die o.a. Programme nutzen recht kräf'tige Farben um verschiedene Funktionsgruppen von einander abzutrennen. Das gefällt mir eigentlich ganz gut.

Ja, sehe ich auch so - da sollten wir auch ganz definitiv nichts dran ändern.

jona2004 hat geschrieben:Zwei Vorschläge:
1 - Alle fischertechnik spezifischen Blöcke in fischertechnik rot (grau für die Puristen ist schon belegt)
2 - Die fischertechnik spezifischen Blöcke in die jeweiligen Kategorien einsortieren (Z.B. sensing) und mit eine grauen breiten Rand kenntlich machen.

Das denke ich eher nicht. Zum einen ist die ganze Umgebung schon "Fischertechnik-spezifisch" (weil RoboBlocks nur auf TXTs mit Community-Firmware läuft - zumindest solange, wie niemand die Community-Firmware auf irgendwas anderes portiert), und zum anderen dürfte es denke ich etwas verwirrend sein, wenn z.B. ein [Lies Input X] - Block plötzlich seine Farbe (oder den Rand) wechselt, wenn man X per Dropdown von "TXT I1" (ganz klar Fischertechnik-spezifisch) auf z.B. "WeDo@USB0 I2" (so Fischertechnik-unspezifisch wie es in dem Kontext überhaupt geht, kann aber von einem TXT mit Community-Firmware angesteuert werden) ändert.

Da halte ich es für sinnvoller, diese Blöcke nur nach den "traditionellen" Kategorien ("Sensing", "Movement", ...) zu sortieren und einzufärben.

jona2004 hat geschrieben:PS: Kennt Ihr blockPy von Virginia tech_ http://think.cs.vt.edu/blockpy/

Bis eben nicht - und auf den ersten Blick sieht das auch nur wie eine "normale" Blockly-Applikation aus (RoboBlocks wird wohl auch nicht arg viel anders aussehen, modulo einen eventuellen Fischertechnik-Look für die Blöcke).

Was ist denn daran so besonders? Die Python-Generierung? Die bringt Blockly schon von Haus aus mit (und das ist einer der Hauptgründe, warum ich für die Community-Firmware was Neues aus Basis von Blockly anfange statt einfach ft-robo-snap weiterzuentwickeln).

Hallo Richard,
Ein paar kurze Anmerkungen -
Ob es den Aufwand wert ist da eigene Verbinder zu bauen lasse ich mal dahingestellt sein.

Zum Thema - fischertechnik Blöcke:
Ich war nicht davon ausgegangen, dass die Blöcke die Farbe ändern, aber ich hatte erwartet, dass es einige spezifische Blöcke geben würde. Z.B. zur Ansteuerung von Motoren, damit man nicht immer beide Ausgänge "von Hand" ansteuern muss.
Das wirft für mich die Frage auf was genau das Einsatzgebiet sein soll.
Zum einen gibt es RoboPro - ist ja nicht tot - Da sind solche Dinge wie Motoren, Lampen, Fototransistoren recht übersichtlich grafisch und m.E. kindgerechter dargestellt.
Zum anderen textbasiertes Python.
Und Blockly basierte Programmierung steht irgendwo dazwischen. Bei RoboPro "verschwendet" man m.E. viel Zeit den code gut leserlich d.h. grafisch ansprechend zu machen. Das geht mit den Blockly Sprachen schneller, trotzdem für mich langsamer als ASCII Python.

Zum Thema BlockPy -
Der Sinn des Hinweises war einfach, ob man sich da was abschauen kann. BlockPy unterstützt z.B. Python list und dict. Aber wenn man so tief eintaucht, kann man da nicht gleich Python hacken?
Auch gibt es da Blöcke um Grafik und Text auf den Bildschirm zu kriegen.
Zudem ist alles opensource.

Grüsse Joachim

Ich denke auch, dass es verschieden abstrakte Blöcke geben wird. Z.B. einen Turtle-Robot, bei dem man einfach einstellt, an welchen beiden Ausgängen die beiden Radmotoren hängen. Wie man das nachher darstellt muss man wohl klären, wenn es soweit ist.

Das "aber es gibt doch RoboPro"-Argument greift m.E. immer weniger. In welchem Kinderzimmer steht denn heute noch ein PC? Das wird immer seltener. Von daher ist gerade Blockly noch ein Level einfacher. Da muss niemand etwas auf dem PC einrichten. Da öffnet man den Browser und legt los. Das ist das, was Kinder heutzutage kennen und erwarten. Und für komplexe Dinge ist sowas wie RoboPro oder Blockly eh nicht geeignet. Da geht es dann mit IPython und Python weiter.

Hallo MoG,
Bezüglich der Kinderzimmerausstattung wäre ich mal an eine paar Meinungen interessiert.
Die Kids haben m.E. einen PC-Laptop zum Spielen (Die dicken Spiel brauchen immer noch dicke hardware) und zur Erstellung von Präsentationen, Referaten, Hausaufgaben etc. Auf einem Tablet (ohne Tastatur) ist das schon sehr hart.
Also fuer mich ist programmieren auf dem Tablet nichts egal ob mit Blocky oder per Tastatur.
Zudem wird TXT bei den meisten mit RoboPro gekauft resp. es liegt bei.
Aber ich denke das ist nicht so wichtig, für diese Projekt - Ich würde Jupyter nehmen.
Grüsee Joachim

Hallo zusammen,

jona2004 hat geschrieben:Ob es den Aufwand wert ist da eigene Verbinder zu bauen lasse ich mal dahingestellt sein.

Essentiell ist es nicht, schön wäre es denke ich schon. Mal sehen was da draus wird.

jona2004 hat geschrieben: Zum Thema - fischertechnik Blöcke:
Ich war nicht davon ausgegangen, dass die Blöcke die Farbe ändern, aber ich hatte erwartet, dass es einige spezifische Blöcke geben würde. Z.B. zur Ansteuerung von Motoren, damit man nicht immer beide Ausgänge "von Hand" ansteuern muss.

MasterOfGizmo hat geschrieben:Ich denke auch, dass es verschieden abstrakte Blöcke geben wird. Z.B. einen Turtle-Robot, bei dem man einfach einstellt, an welchen beiden Ausgängen die beiden Radmotoren hängen. Wie man das nachher darstellt muss man wohl klären, wenn es soweit ist.

Ja, solche Blöcke wird es geben. Vielleicht nicht direkt zum Start, aber später denke ich schon.

Die sind dann aber auch nicht wirklich Fischertechnik-spezifisch, sondern eher spezifisch für eine Klasse von Modellen (ein [Fahre X Schritte vorwärts] ist für einen Fahr-Roboter sinnvoll, für ein Industriemodell oder eine Kugelbahn eher nicht) oder sogar spezifisch für ein spezielles Modell (für ein [Dreh dich um X° nach rechts] muss man nicht nur wissen, an welchen Ausgängen die Fahrmotoren hängen, sondern auch, wieviele Motor-Schritte einem Zentimeter Bewegung von Radumfang/Kette entsprechen und wie weit die Räder voneinander entfernt sind).

Wie ich das am Besten abbilde weiß ich noch nicht. Möglicherweise über eine zusätzliche Konfigurationsseite, wo man genau solche Einstellungen machen kann (an welchen Ausgängen hängen Motoren, wieviele Motorschritte entsprechen einem Zentimeter Bewegung, welcher Eingang ist ein Schalter, welcher ist ein Widerstand, ...). Die Einstellungen wiederum wählen letztendlich aus, welche Blöcke und Blockeinstellungen man sieht (wenn das Modell keine Fahrmotoren hat, dann braucht man auch keine "Turtle-Blöcke", und wenn an O1 eine LED hängt, dann muss man in der Auswahl für die Motoren M1 auch nicht anzeigen).

Und wo ich diese Blöcke einsortiere weiß ich auch noch nicht genau. Ich tendiere zu allgemeinen Kategorien wie "Aktoren" und "Sensoren", aber da muss man eventuell einfach etwas experimentieren (oder sich von existierenden Projekt inspirieren lassen).

jona2004 hat geschrieben: Das wirft für mich die Frage auf was genau das Einsatzgebiet sein soll.
Zum einen gibt es RoboPro - ist ja nicht tot - Da sind solche Dinge wie Motoren, Lampen, Fototransistoren recht übersichtlich grafisch und m.E. kindgerechter dargestellt.
Zum anderen textbasiertes Python.

Nicht jedes Kind mag RoboPro (mein Sohn mag es z.B. nicht ).

Und - wichtiger - um mit RoboPro den TXT zu programmieren, braucht man zwingend einen Windows-PC (oder zumindest Linux mit Wine - das geht zwar, aber nicht perfekt). Mein Ziel für die Community-Firmware ist, da Entwicklungsumgebungen mitzubringen für die man außer dem TXT nur "irgendwas mit einem Browser" braucht - egal ob das jetzt ein Windows-PC, Linux-PC, Mac, Tablet oder sogar ein Smartphone ist. Sicher, Einschränkungen wird es immer geben (Jupyter ist ohne Tastatur etwas unhandlich, und auch mit RoboBlocks wird man auf dem Winz-Bildschirm eines Smartphones wohl nicht allzu glücklich), aber im Prinzip will ich so viele Clients wie nur irgendwie möglich unterstützen.

Außerdem können wir mit unserer eigenen Umgebung auch neue Konzepte ausprobieren und umsetzen, während wir bei RoboPro darauf angewiesen sind, dass Fischertechnik diese Ideen ebenfalls gut findet und unterstützt. Ein Beispiel: Ich habe vor, in RoboBlocks von Anfang an ein eventbasiertes Programmiermodell zu verwenden, bei dem die einzelnen Codeblöcke dann gegebenenfalls auch parallel ausgeführt werden. Soweit ich weiß geht das in RoboPro nicht (ich kenne RoboPro allerdings auch nur oberflächlich, mag sein dass ich mich da irre und es doch Mutithreading gibt). Und wenn man erstmal so ein eventbasiertes System hat, dann ist der Schritt zu einem verteilten System - in dem dann mehrere TXTs über WLAN zusammenarbeiten - nicht mehr weit. Und das geht mit RoboPro ganz definitiv nicht, während es mit der Community-Firmware und Blockly nicht allzu schwer umzusetzen ist.

Und zuguterletzt soll RoboBlocks auch den Übergang zu textbasiertem Programmieren unterstützen: Aus den Blöcken wird Python-Code generiert, und diesen Python-Code kann man sich selbstverständlich auch anschauen (dass der dann auch ansehnlich ist ist unsere Aufgabe). Und wenn man mit seinem Programm irgendwann an die Grenzen von RoboBlocks stößt, dann ändert man einfach den Programmtyp in den Metadaten von "RoboBlocks" auf "GenericPython", und entwickelt mit einer "klassischen" Python-IDE weiter - mit dem vorher von RoboBlocks erzeugten Python-Code als Basis.

jona2004 hat geschrieben: Zum Thema BlockPy -
Der Sinn des Hinweises war einfach, ob man sich da was abschauen kann. BlockPy unterstützt z.B. Python list und dict. Aber wenn man so tief eintaucht, kann man da nicht gleich Python hacken?
Auch gibt es da Blöcke um Grafik und Text auf den Bildschirm zu kriegen.
Zudem ist alles opensource.

Ah, ok - danke. Nein, ich denke wir werden direkt von BlockPy eher nicht so viel abschauen können. Soweit ich das beim Überfliegen sehen kann, liegt bei BlockPy das Hauptaugenmerk auf generischer Python-Programmierung, während RoboBlocks klar auf die Steuerung von Modellen ausgelegt sein wird. Da gibt es nicht so arg viele Überschneidungen. Und auch für Text und Grafik haben wir mit dem kleinen TXT-Touchscreen und unserem Darstellungskonzept da auch eine eher ungewöhnlich Umgebung. Da ist (auch dank PyQt) selberbauen vermutlich ebenfalls einfacher, als irgendwas halbwegs passendes zu suchen und anzupassen. Genauso bei generischen Datenstrukturen - sowas ist schnell runtergeschrieben. Wenn wir es irgendwann tatsächlich brauchen (für den Anfang sehe ich das ehrlich gesagt nicht - noch nicht mal die Listen, die Blockly schon direkt mitbringt).

Ich denke wenn wir irgendwo was abgucken, dann eher bei OpenRoberta oder ähnlichen Projekten. Und da dann auch eher Konzepte als Code.

Ich habe heute noch eine Weile an RoboBlocks gebastelt und der TXT hat das erste Python-Fragment selbst ausgeführt. Für mich persönlich schält sich da langsam eine ganz einfache Vorgehensweise raus: Es gibt einfach mehrere RoboBlocks. Klingt zunächst aufwändig. Aber RoboBlocks besteht nachher selbst nur aus etwas HTML, Javascript und Python. HTML und Javascript lädt sich der Client, mit dem Python machen wir die Server-seite.

Wer sich mal die Blockly-Demos angesehen hat wird gesehen habe, dass man das weitgehend konfigurieren kann. Das geht von einer Simpel-Variante a la WeDo zu ziemlich komplexen Dingen. Und genau so würde ich es auch handhaben,

Beispiel: Für den Änfänger, der sich das Discovery Set gekauft hat gibt es dann "RoboBlock Mobile Beginner". Das was der User da im Webbrowser sieht ist dem hier echt ähnlich: https://blockly-games.appspot.com/maze. Keine Kategorien, nur drei Block-Typen, nix weiter. Da klickt man sich dann einen trivialen Roboter zusammen. Das kann jedes Vorschulkind.

Natürlich kann man auch die "Profi-Variante" machen, die mehr kann: https://blockly-games.appspot.com/pond-duck, wobei auch das noch recht simpel ist. Blockly kann recht komplexe Dinge. Dort gibt's dann auch die fundamentaleren FT-Blöcke zum direkten Schalten und Abfragen von Motoren, Sensoren etc ... wie RoboPro in der komplexeren Einstellung.

Und wenn dann noch der CSS/SVG-Profi das ganze mit einen "Mobile Robot"-Theme unterlegt kann das echt cool aussehen.

Technisch werden sich die ganzen Varianten kaum unterscheiden. Sie sind nur unterschiedlich schwierig zu bedienen. Der technische Core und eine Variante ist dann auf dem TXT vorinstalliert, aber man sich dann Dinge wie "RoboBlock Mobile Beginner" nachinstallieren, indem man ein ein paar Kilobytes groesses ZIP mit passendem HTML und Python z.B. aus dem Store installiert

So stelle ich mir das zumindest vor ...

Mir fehlt bei RoboPro der sanfte Einstieg. Ich wüsste nicht, wie ich einer ersten Klasse in der Grundschule in45 Minuten was interessantes in RoboPro vermitteln könnte. Ich würde die ganze Zeit nur "jetzt klick hier, dann klick da" kommandieren. Aber ich weiss, wie ich RoboBlocks aussehen lassen würde, damit ein paar Erstklässler nach ein paar Minuten einen kleinen mobilen Roboter programmieren können (s.o.).

MasterOfGizmo hat geschrieben:Ich habe heute noch eine Weile an RoboBlocks gebastelt und der TXT hat das erste Python-Fragment selbst ausgeführt. Für mich persönlich schält sich da langsam eine ganz einfache Vorgehensweise raus: Es gibt einfach mehrere RoboBlocks. Klingt zunächst aufwändig. Aber RoboBlocks besteht nachher selbst nur aus etwas HTML, Javascript und Python. HTML und Javascript lädt sich der Client, mit dem Python machen wir die Server-seite.

Beispiel: Für den Änfänger, der sich das Discovery Set gekauft hat gibt es dann "RoboBlock Mobile Beginner". Das was der User da im Webbrowser sieht ist dem hier echt ähnlich: https://blockly-games.appspot.com/maze. Keine Kategorien, nur drei Block-Typen, nix weiter. Da klickt man sich dann einen trivialen Roboter zusammen. Das kann jedes Vorschulkind.

Ja, so in etwas stelle ich mir das auch vor. Mit einem Unterschied: Statt "mehrerer RoboBlocks" gibt es nur ein RoboBlocks, und die Konfiguration kommt aus der jeweiligen App, die man in RoboBlocks lädt. Für Dein Beispiel würde man sich also dann einfach die "RoboBlock Mobile Beginner"-App im Store herunterladen und in RoboBlocks öffnen. Das Resultat wäre dann dasselbe wie in deinem Beispiel - ein simpler, auf Anfänger ausgelegter Workspace, um ein bestimmtes Modell (oder die Modelle aus einem Kasten) zu steuern.

MasterOfGizmo hat geschrieben:Wer sich mal die Blockly-Demos angesehen hat wird gesehen habe, dass man das weitgehend konfigurieren kann. Das geht von einer Simpel-Variante a la WeDo zu ziemlich komplexen Dingen. Und genau so würde ich es auch handhaben

Technisch ja, auf jeden Fall. Ich würde aber wie gesagt die Konfiguration (und eventuell auch irgendwelche Spezialblöcke) eher in Apps (bzw. besser: App-Templates) verlagern. Macht denke ich die Handhabung etwas leichter als zwischen diversen RoboBlocks-Varianten auswählen zu müssen. Und man kann auch leichter mal eben schnell ein Spezial-Template (z.B. für eine Robotik-AG, oder ein Roboter-Programmier-Event auf eine Ausstellung, ...) aufsetzen und verteilen als eine spezielle Firmware-Version mit angepasstem RoboBlocks (oder hab ich Dich da irgendwo falsch verstanden?)

MasterOfGizmo hat geschrieben:Und wenn dann noch der CSS/SVG-Profi das ganze mit einen "Mobile Robot"-Theme unterlegt kann das echt cool aussehen.

Eher SVG-Profi (Hallo Raphael ).

Die Umrisse der Blöcke werden soweit ich sehen kann in core/block_render_svg.js aus SVG-Path-Schnipseln für die einzelnen Elemente (Ecken, Seiten, Verbinder, ..., die werden ebenfalls in core/block_render_svg.js definiert) zusammengebaut. CSS macht das ganze dann im Wesentlichen nur noch bunt.

MasterOfGizmo hat geschrieben:Technisch werden sich die ganzen Varianten kaum unterscheiden. Sie sind nur unterschiedlich schwierig zu bedienen. Der technische Core und eine Variante ist dann auf dem TXT vorinstalliert, aber man sich dann Dinge wie "RoboBlock Mobile Beginner" nachinstallieren, indem man ein ein paar Kilobytes groesses ZIP mit passendem HTML und Python z.B. aus dem Store installiert.

Ah, ok - das ist ja ziemlich genau das was ich mir auch dazu gedacht habe. Nenn das "paar Kilobytes groesses ZIP" doch einfach auch "TXT-App", wie die ganzen anderen ZIPs im Store auch

Und bevor hier jetzt alle auf eigene Faust losrennen und durcheinander basteln: Ich bin gerade dabei, ein passendes Repository für RoboBlocks aufzusetzen und in die Community-Firmware einzubinden. Heute krieg ich das zwar wohl nicht mehr fertig, aber bis zum Wochenende ist auf jeden Fall was da. Da wirds dann auch ein "block_paths.js" oder so ähnlich geben, in dem man sich dann austoben kann um die Blockumrisse zu verändern.

Blockly selbst will ich dabei ungern direkt als Quellcode in RoboBlocks haben. Da ist zum einen zu viel überflüssiger Ballast (zumindest für unsere Zwecke) drin, und zum anderen hat der Build-Prozess, mit dem man aus den eigentlichen Sourcen dann blockly_compressed.js macht, ein paar unschöne Abhängigkeiten (sprich: Der wirft den ganzen Kram einem Google-Online-Javascript-Vermantscher vor und funktioniert daher auch nur, wenn man gerade online ist) die ich in RoboBlocks und/oder der Community-Firmware nur ungern hätte. Daher will ich da ein bereits fertig "kompiliertes" Blockly einbauen und im wesentlichen einfach nur als Bibliothek verwenden. Eventuelle Änderungen von uns an Blockly direkt, die man nicht pder Konfiguration über die "offizielle" API abhandeln kann (z.B. die angepassten Pfade für Block-Umrisse) kommen da dann als "Monkey Patch" rein (das genau zu erklären würde hier jetzt zu weit führen - schaut euch später im Repository an was damit gemeint ist, oder werft den Begriff mal in die Suchmaschine Eurer Wahl). Aber das sauber aufzusetzen dauert halt ein wenig.

richard.kunze hat geschrieben:Eher SVG-Profi (Hallo Raphael ).

Profi wäre jetzt übertreiben, aber anhand von fertigen svgs (ich werde die lizenzen wahren) oder Ideen in sonstiger Form sollte ich das hinbekommen.

Raphael

richard.kunze hat geschrieben: Ja, so in etwas stelle ich mir das auch vor. Mit einem Unterschied: Statt "mehrerer RoboBlocks" gibt es nur ein RoboBlocks, und die Konfiguration kommt aus der jeweiligen App, die man in RoboBlocks lädt.

Genau so meine ich das doch auch. Die technische Basis hat man nur einmal auf dem TXT, aber jeweils angepasste Konfigurationen.

Tach auch!

So rein interessehalber: Was würde man denn mit einem RoboBlocks machen können, was man mit RoboPro nicht oder nur schwer hinbekommt? Gibt's ein Killer-Feature?

Gruß und tiefen Respekt vor der starken Arbeit, die ihr da alle leistet,
Stefan

Hallo Stefan,

steffalk hat geschrieben:So rein interessehalber: Was würde man denn mit einem RoboBlocks machen können, was man mit RoboPro nicht oder nur schwer hinbekommt? Gibt's ein Killer-Feature?

TXT-Programme auf einem Smartphone oder Tablet schreiben

Etwas ernsthafter: Von der Funktionalität her wird es - zumindest am Anfang - wohl eher kein echtes "Killerfeature" geben. Eher im Gegenteil, die erste Version von RoboBlocks wird mit Sicherheit deutlich weniger können als RoboPro.

Die Unterschiede liegen eher im Entwicklungs- und Programmiermodell.

RoboPro ist ein abgeschlossenes System, wird als Closed Source entwickelt, und wie es intern funktioniert ist (zumindest mir) völlig unbekannt. RoboBlocks soll von vorn herein auf Erweiterbarkeit ausgelegt sein (bzw. darauf, dass man, wen man irgendwann an die Grenzen stößt, nahtlos mit Python weiterentwickeln kann), es wird öffentlich entwickelt, und jeder kann sich bis ins Detail anschauen wie das System funktioniert. Von daher würde ich erwarten, dass sich RoboBlocks schneller entwickeln wird als RoboPro, und wahrscheinlich in irgendwelche Richtungen, die keiner der aktuell Beteiligte schon jetzt im Blick hat.

Außerdem verfolgen beide Systeme leicht unterschiedliche Programmieransätze: RoboPro kennt (zumindest soweit ich weiß) nur das "grüne Ampelmännchen" als Startpunkt für vom Benutzer geschriebenen Programmcode, während ich RoboBlocks konsequent evengetrieben halten will. Will sagen, in RoboBlocks wird es viele verschiedene Startblöcke (oder "Hutblöcke", wie die in Scratch heißen) geben, die den zugehörigen Block-Stapel immer dann ausführen wenn irgendein Ereignis eintritt. Ereignisse können dann z.B. einfache, fest eingebaute Reaktionen auf externe Einflüsse sein (z.B. "Schalter an I1 wurde gedrückt"), aber auch komplexere Ereignisse, die von einem RoboBlocks-Programm selbst definiert und ausgelöst werden (z.B. "Das Bilderkennungs-Unterprogramm hat einen gelben Ball in Blickrichtung der Kamera erkannt"). Ich vermute, dass so ein Programmiermodell es einfacher machen wird, Programme für mehrere vernetzte, kooperierende TXTs zu schreiben (mit entsprechender Unterstützung in der Community-Firmware für die Vernetzung, aber da sind wir schon ziemlich weit). Vom Konzept her ist es schließlich nur ein ziemlich kleiner Schritt von "Starte diesen Block wenn Schalter 1 gedrückt wurde" zu "starte diesen Block, wenn Schalter 1 am anderen TXT gedrückt wurde", während die entsprechenden Programmelemente bei RoboPro (Sender und Empfänger) eher nicht so im Vordergrund stehen und einen deutlich komplexeren Eindruck machen.

Was denke ich am ehesten an ein "Killerfeature" rankommen könnte ist die Offenheit des von RoboBlocks erzeugten "Objektcodes": Das ist nämlich schlicht und ergreifend Python, und kann dementsprechend leicht mit anderem Python- oder sogar C-Code erweitert werden wenn RoboBlocks nicht mehr ausreicht. Das geht mit RoboPro meines Wissens nach überhaupt nicht.

steffalk hat geschrieben:Gibt's ein Killer-Feature?

Das sind für mich klar die einfach zu bedieneden Dinge. Ich denke, dass die EInstiegshürde für RoboPro oft noch zu hoch ist. Eine echt simple Web-GUI für z.B. eben die "Mobile Robots", wo selbst ein Kind unter dem Weihmnachtsbaum nach fünf Minuten kapiert hat, wie es den Roboter so programmiert, dass er einmal die Runde um den Christbaum dreht. Das ist mein Killer-Feature.

"TXT Einschalten, Handy anmachen, Browser öffnen, ein wenig leicht verständliches Drag'n Drop" -> Instant-Spass!

Hat mal einer von Euch das aktuelle WeDo 2.0 benutzt? Ziemlich genau sowas meine ich. Nur mit weniger didaktischem Zeigefinger und mehr Spass

Wichtigstes Feature bei z.B. meinen Kindern: Man muss selbst Sounds aufnehmen können. Und wenn der Roboter dann vor jedem Hindernis "Och Männo, hier steht ja schon wieder was im Weg rum" sagt, dann lachen sie sich kringelig ...

Hallo zusammen,

unter https://github.com/ftCommunity/robo-blocks gibt es seit ein paar Tagen ein Projekt für RoboBlocks, und inzwischen gibt es da auch einen ersten Eindruck davon, wie ich mir das vom Layout und den Bedienelementen her vorstelle. Funktionieren tut noch nicht allzuviel - man kann zwar Blöcke durch die Gegend schieben, aber Load/Save/Run usw. machen noch nichts. Und die ganzen TXT-spezifischen Blöcke (in "Actions", "Events", "Sensors") fehlen ebenfalls noch.

Die beiden Tabs ganz links (die ebenfalls noch nichts tun sollen später mal zwischen dem normalen "Programmier-Modus" und einem "Konfigurations-Modus" umschalten. Im Konfigurationsmodus puzzelt man dann zwar ebenfalls Blöcke zusammen, die repräsentieren dann aber keine Programmelemente, sondern den TXT selbst mit seinen Ein- und Ausgängen und die Sachen, die an den TXT angeschlossen sind (Schalter, Lichtschranke, Ultraschallsensor, normaler Motor, Encoder-Motor, Lampe, Kamera, ...). Diese Konfiguration bestimmt dann, welche Blöcke im Programmiermodus angezeigt werden (z.B. ein Sensor-Block [read distance] nur dann, wenn auch ein Ultraschallsensor angeschlossen ist). Die Idee dazu ist auch nicht auf meinem Mist gewachsen, das hab ich bei https://lab.open-roberta.org/ gesehen (nachdem ich da mal auf den Trichter gekommen bin, auf "Roboterkonfiguration" zu klicken) und fand es so git, dass ich es für RoboBlocks direkt übernehmen wollte.

Hallo zusammen,

ich bin durch Zufall auf diesen Thread aufmerksam geworden.

Wir bei Roberta - bzw. Fraunhofer IAIS, wären sehr daran interessiert, auch die fischertechnik Roboter mit unserem Open Roberta Lab programmieren zu können.
Gerne stehen wir hierzu mit Rat und Tat zur Verfügung.

Bei Interesse einfach eine E-Mail an roberta-zentrale@iais.fraunhofer.de schicken.

Viele Grüße,
Thorsten

Hallo Thorsten,

Roberta hat geschrieben: Wir bei Roberta - bzw. Fraunhofer IAIS, wären sehr daran interessiert, auch die fischertechnik Roboter mit unserem Open Roberta Lab programmieren zu können.

Das wäre natürlich prima, und ich (und der Rest hier ebenfalls, denke ich) fänden es auch sehr gut, wenn Fischertechnik ebenfalls bei Open Roberta Lab vertreten wäre.

Ich würde dafür allerdings das Projekt hier - "RoboBlocks" - nicht aufgeben wollen, auch wenn es an vielen Stellen Überschneidungen zu Open Roberta Lab gibt. Soweit ich sehen kann (und bitte korrigiere mich, wenn ich da falsch liege - so gut kenne ich Open Roberta Lab jetzt auch wieder nicht), gibt es da trotzdem noch einige Unterschiede in der Zielsetzung die mir wichtig genug sind um zwei ähnlich Projekte parallel zu verfolgen:

• Soweit ich das sehen kann, braucht man für Open Roberta Lab außer dem Roboter (und dem Client mit Browser) noch einen Server. Bei RoboBlocks ist eins meiner wichtigsten Ziele, außer dem TXT und einem Browser nichts weiter zu brauchen - der (minimale) Server, den ich für RoboBlocks brauche, läuft direkt auf dem TXT.
• Außerdem will ich ein etwas anderes Programmiermodell implementieren. Open Roberta Lab ist soweit ich sehen kann darauf ausgelegt, Single-Threaded-Programme zu erstellen. RoboBlocks soll Multi-Threaded und eventbasiert werden, d.h. ich will in der Blocksprache mehr als einen "Startblock" zulassen, und die einzelnen Startblöcke sollen von verschiedenen Events getriggert werden können. Events sollen dabei sowohl von der Hardware ausgelöst werden können ("Schalter gedrückt" usw.) als auch durch Nachrichten aus dem Programm selbst.
• Und zuguterletzt will ich (zumindest auf mittlere bis längere Sicht) in RoboBlocks nicht nur den einen TXT ansteuern, auf dem das eigentliche Programm läuft, sondern auch Erweiterungen, die per USB, I2C oder Bluetooth angebunden werden (z.B. Kamera, zusätzliche IO-Bausteine, ...) und sogar andere TXTs (über WLAN). Ich weiß nicht, wie gut sich das in Open Roberta Lab umsetzen ließe.

Auf der anderen Seite gibt es aber denke ich auch genug Überschneidungen, um sowohl RoboBlocks als auch eine Integration in Open Roberta Lab hinzubekommen, auch wenn ich nur begrenzt dafür Zeit habe (ist für mich hier halt "nur" Hobby, und konkurriert mit Familie und Erwerbsarbeit um meine Zeit).

Und was generell Roboterprogrammierung in einer Scratch-ähnlichen Sprache angeht, kann ich bestimmt eine ganze Menge von Euch lernen. Oder mich auch gleich ganz frech bei euch bedienen - wenn ihr nichts dagegen habt, würde ich nämlich gern Euren Blockly-Fork als Basis für RoboBlocks nehmen. Den finde ich deutlich besser als das Original - sowohl was das Aussehen angeht als auch von der Benutzbarkeit her (besonders die Idee mit den passend zum Blocktyp eingefärbten Verbindern gefällt mir da sehr gut).

Roberta hat geschrieben: Gerne stehen wir hierzu mit Rat und Tat zur Verfügung.

Ein guter Startpunkt wäre ein Überblick, wie Open Roberta Lab technisch aufgebaut ist, und was man machen muss um einen neuen Roboter zu integrieren. Gerne auch als RTFM, aber auf Anhieb wüßte ich jetzt nicht which FM to R

Roberta hat geschrieben: Bei Interesse einfach eine E-Mail an roberta-zentrale@iais.fraunhofer.de schicken.

Ist parallel hierzu rausgegangen, aber mir wäre es ehrlich gesagt lieber, öffentlich hier im Forum weiter zu diskutieren.

Liebe Grüße,

Richard

Hallo Richard,
NEPO, bzw. das Open Roberta Lab ist zur Zeit nur Single-Threaded, dass stimmt. Allerdings warten wir derzeit nur darauf, ein geeignetes System dazu zu nehmen, dass eventbasiert ist. Die aktuell implementierten System und deren Firmware unterstützen eventbasierte Programmierung bisher nicht oder unzureichend. Auch sehen wir gerade für Anfänger die Schwierigkeit mit konkurrierenden Threads / Events zu arbeiten. Ich kann mir aber durchaus vorstellen, dass der Fischertechnik Roboter im Anfängermodus z. B. nur das Startevent (Startblock) zur Verfügung hat und im Expertenmodus alle verfügbaren Event.

Der Server, den man bei Open Roberta braucht stellen wir permanent zur Verfügung, s. lab.open-roberta.org. Wir haben das so entwickelt, damit insbesondere Anfänger oder Leute mit wenig Zeit (z. B. Lehrkräfte) keinen Installationsaufwand haben und gleichzeitig die Features eine Cloudprogrammierung nutzen können. So können die Programme gespeichert und auch geteilt werden. Ein Dashboard für Gruppenverwalter ist ebefalls auf dem Weg. Außerdem können verschiedene Hardwaresysteme (zur Not auch die Simulation) gleichzeitig im Unterricht verwendet werden. Wir denken, dass ein Angebot für verschiedene Systeme jedes einzelne System aufwertet und sichtbarer macht.

Evtl. könnte es für den Benutzer etwas verwirrend sein, wenn es zwei (ähnliche) Programmiereditoren gibt. Open Roberta ist sehr flexible, gerade das Ansteuern von Erweiterung lässt sich auch hier gut implementieren.

Wir arbeiten mit separaten Plugins für die einzelnen Robotersysteme, die Entwicklung eines solchen Plugins ist mehr oder weniger autark und man muss nicht von ganz vorne beginnen, sondern man findet bei uns mittlerweile leicht ein geeignetes Plugin dass man entsprechend ändern und erweitern kann. Gerne sind wir dabei behilflich.

Viele Grüße
Beate

Hallo,

Roberta hat geschrieben: Wir bei Roberta - bzw. Fraunhofer IAIS, wären sehr daran interessiert, auch die fischertechnik Roboter mit unserem Open Roberta Lab programmieren zu können.

Ja klar, das wäre super und im direkten Vergleich mit dem EV3 würde das auch die Sichtbarkeit des TXT weiter verbessern.

richard.kunze hat geschrieben:Hallo Thorsten,
[...] RoboBlocks soll Multi-Threaded und eventbasiert werden, d.h. ich will in der Blocksprache mehr als einen "Startblock" zulassen, und die einzelnen Startblöcke sollen von verschiedenen Events getriggert werden können. Events sollen dabei sowohl von der Hardware ausgelöst werden können ("Schalter gedrückt" usw.) als auch durch Nachrichten aus dem Programm selbst.

Derzeit ist ftrobopy nicht threadsafe. Um parallel mit mehreren Prozessen auf die Motorplatine zuzugreifen, muss da noch einiges gemacht werden (auf der Motorplatine des TXT läuft auch nur ein einziger Thread, der die Steuerbefehle entgegen nimmt). Man könnte über eine "Befehlsqueue" in ftrobopy nachdenken, in die sich die Steuerbefehle für die Motorplatine einreihen.

richard.kunze hat geschrieben:Hallo Thorsten,
[*] Und zuguterletzt will ich (zumindest auf mittlere bis längere Sicht) in RoboBlocks nicht nur den einen TXT ansteuern, auf dem das eigentliche Programm läuft, sondern auch Erweiterungen, die per USB, I2C oder Bluetooth angebunden werden (z.B. Kamera, zusätzliche IO-Bausteine, ...) und sogar andere TXTs (über WLAN). Ich weiß nicht, wie gut sich das in Open Roberta Lab umsetzen ließe. [/list]

Das geht ja schon in die Richtung von ROS (Robot Operating System). Da können wir uns sicherlich auch ein paar Dinge abschauen. Ich habe sogar mal darüber nachgedacht, einen ROS-Port für den TXT zu machen, im Prinzip sollte das möglich sein. (Im Moment habe ich aber keine Zeit dafür)

Beate hat geschrieben: Auch sehen wir gerade für Anfänger die Schwierigkeit mit konkurrierenden Threads / Events zu arbeiten.

Ich denke, dass auch Anfänger relativ schnell die Konzepte mit parallelen Threads verstehen können. Insbesondere bei der Programmierung von Robotern lassen sich Dinge wie Nebenläufigkeit fast intuitiv vermitteln. Auch die von fischertechnik zum TXT mitgelieferte Programmierumgebung ROBOPro unterstützt die Verwendung paralleler Threads und die Anwender scheinen damit nicht überfordert zu sein (zu diesem Schluss kommt man auf jeden Fall, wenn man sich die Ergebnisse anschaut).

Viele Grüße
Torsten