CFW: Brickly (war Blockly)

[MasterOfGizmo]

Nicht die Frage!
Das Problem finde ich Hä!
Und ich meinte weitere verständnisfragen

Kannst Du bitte versuchen, etwas freundlicher zu sein?

[EstherM]

Das habe ich auch so gedacht. Wenn man aber nur eine Entfernung setzt, wird "der Motor hat gestoppt" niemals wahr.
Korrektur: wenn ich die Entfernung bei M1 setze, wird "M1 hat gestoppt" niemals wahr. "M2 hat gestoppt" aber schon. Ist das ein Bug oder ein Feature?

Da musst Du den Entwickler der ftroboypy bzw den Entwickler der TXT-Hardware fragen. An der Stelle reicht Brickly einfach "nach oben" durch, was es von den Bibliothgeken und der Hardware geliefert bekommt.

Gut. Ich habe mal versucht, die Funktion mit RoboPro nachzuvollziehen. Auch da funktioniert das irgendwie nicht so richtig, wenn nur ein Motor die Entfernung gesetzt bekommt. Ich schreibe dann in die Doku: "Damit beide Motoren wirklich synchron laufen und auch zur gleichen Zeit ein Stopp-Signal geben, solltest Du bei beiden Motoren die gleiche Entfernung einstellen". Ist das recht so?
Wenn ich mich noch in ftrobopy einarbeite, wird die Doku nie fertig.
Gruß
Esther

[Torsten]

Hallo Esther,

Da musst Du den Entwickler der ftrobopy [...] fragen.

So richtig verstanden habe ich das auch nicht ...

In der fischertechnik Dokumentation findet man den folgenden Absatz zu diesem Thema:

This is used to synchronize one motor to another motor. 0 means the motor is independent. 1..4 means the motor is synchronized to motor 1..4. If a value of 5..8 is given, it is possible to program deviations from the synchronization using the m_motor_distance values. This is called “sync error injection”. This is useful e.g. for closed loop trail tracking.

Die "sync error injection"-Funktion (s.o.) habe ich in ftrobopy bisher noch nicht eingebaut, weil mir die Funktionsweise nicht ganz klar ist.

Ich habe mal versucht, die Funktion mit RoboPro nachzuvollziehen. Auch da funktioniert das irgendwie nicht so richtig, wenn nur ein Motor die Entfernung gesetzt bekommt.

Das wäre auch meine Empfehlung: einfach bei beiden Motoren die gleiche Distanz einstellen.

Viele Grüße
Torsten

[PHabermehl]

Hallo Zusammen,

mit einem taufrischen Build des aktuellen cfw-0.9.3-repos geht mein wireless gamepad

Und anbei das Brickly-Programm, daß man braucht, um ein Raupenfahrzeug oder unseren ft-rowr *) mit dem Joystick zu steuern:

*) nein, das steht nicht für "Rover", sondern für "robot wreck"

[EstherM]

Hallo Zusammen,

mit einem taufrischen Build des aktuellen cfw-0.9.3-repos geht mein wireless gamepad

Und anbei das Brickly-Programm, daß man braucht, um ein Raupenfahrzeug oder unseren ft-rowr *) mit dem Joystick zu steuern:

Screenshot_20170304_145938.jpeg

*) nein, das steht nicht für "Rover", sondern für "robot wreck"

Sehr schön! Gehen jetzt wohl alle Wireless Gamepads? Und wie werden die dann an den TXT angeschlossen? Nicht per Stecker über die USB-Schnittstelle, nehme ich an.
Ihr wisst: alle sinnvollen Antworten verbessern die Anleitung.
Gruß
Esther

[PHabermehl]

Hallo Esther,
Meine wired-pads gehen immer noch nicht, demzufolge werden auch nicht alle wireless pads gehen.

Und, doch, genau am USB-anschluß werden die Geräte angeschlossen.

Gruß
Peter

[EstherM]

Hallo Esther,
Meine wired-pads gehen immer noch nicht, demzufolge werden auch nicht alle wireless pads gehen.

Und, doch, genau am USB-anschluß werden die Geräte angeschlossen.

Gruß
Peter

Ach so, das ist wie bei den drahtlosen Mäusen: der Empfänger wird in den USB-Anschluss gesteckt.
Wie detailliert sollen wir denn in der Anleitung darauf eingehen, welche Modelle funktionieren?
Gruß
Esther

[PHabermehl]

Hallo Esther,

ich denke, da ist das letzte Wort noch nicht gesprochen, weil ich vorhin erst festgestellt habe, daß da ggf. noch Kernel-Module fehlen.
Ansonsten würde ich auf jeden Fall den Hinweis aufnehmen, daß nicht jeder Joystick/Gamepad funktioniert.
Bitte verweise auch auf Tills jstest-App aus seinem GitHub-Repo. Die zeigt nämlich an, ob und wie viel von einem Gamepad/Joystick funktioniert. Ich hoffe ja immer noch, daß Till die Apps mal wieder in den cfw-Appstore überführt....

Gruß
Peter

[ski7777]

Ich hoffe ja immer noch, daß Till die Apps mal wieder in den cfw-Appstore überführt....

Ich hoffe, dass er uns mal erklärt warum er die vollkommen unproblematischen Apps überhaupt überführt hat.

Raphael

[MasterOfGizmo]

Ob der Gamepad-Teil je wirklch toll funktionieren wird weiss nicht nicht. Er wird wohl irgendwann in ein optionales separates Paket wandern. Ich würde in die Doku des Joystick-Teils daher auch nicht zuviel Arbeit stecken. Dafür funktioniert er nicht zuverlässig genug. Und suf externe Tools wie das alte jstest solte man ja auch nicht angewiesen sein.

[richard.kunze]

Ob der Gamepad-Teil je wirklch toll funktionieren wird weiss nicht nicht. Er wird wohl irgendwann in ein optionales separates Paket wandern.

Ich denke mal, wir sollten zumindest versuchen die "offiziellen" Joystick/Gamepad-artigen Eingabegeräte über die "Gampad"-Funktionen in Brickly zu unterstützen: Die beiden Fernsteuerungen von Fischertechnik (sowohl das "alte" Infrarot-Control-Set als auch die neue Bluetooth-Fernsteuerung).

Wenn der Kram zusätzlich noch mit manchen anderen Gampads/Joysticks funktioniert, ist das ein netter Bonus.

[EstherM]

Die erste vollständige Version der Anleitung für Brickly ist fertig: https://github.com/EstherMi/ft-brickly- ... brickly.md
Es fehlen noch Bilder. Ich möchte euch aber jetzt bitten, den Text zu lesen und kritisch zu prüfen: Tippfehler, inhaltliche Fehler usw.
Wenn der Text soweit passt, füge ich auch noch Abbildungen hinzu.
Eine Kleinigkeit ist mir noch unklar: Im Kontextmenü gibt es eine Art Getter- und Setter-Methode. Dort steht 'Erzeuge "Schreibe u"' und es kommt ein Baustein 'setze u auf:`. Ist der Text im Kontextmenü so vorgegeben, oder könnte man den Text anpassen, damit er zu den Bausteinen passt?
Wenn die Anleitung fertig ist, können wir uns über die Verlinkungen dazu und über ein Tutorial Gedanken machen.
Gruß
Esther

[MasterOfGizmo]

Wow, wirklich sehr toll. Brickly gibt es nun via App-Store, von daher ist die Einleitung schon nicht mehr aktuell.

Gefällt mir wirklich sehr gut. Danke!

[ski7777]

Wenn wir das auf readthedocs oder so hosten könnten könnte man das noch besser strukturieren.
Aber sonst, wow, gute Arbeit.

Raphael

[PHabermehl]

@ EstherM: leider noch keine Zeit gehabt, aber ich hoffe, wir (Kids+ich) können noch eine "Ladung" tutorials nachlegen. Vorab schon mal Danke für Deine Mühe!

@ Till: Doppel-Danke für die Entscheidung.

[EstherM]

Wenn wir das auf readthedocs oder so hosten könnten könnte man das noch besser strukturieren.
Aber sonst, wow, gute Arbeit.

Raphael

Danke für die Komplimente. Von readthedocs hatte ich vorher noch nie was gehört. Nach einem ersten Blick darauf finde ich das auch nicht so überzeugend. Nach der Diskussion (viewtopic.php?f=33&t=4052) hat sich das aber ohnehin erledigt, denke ich.
Wie hättest Du denn die Anleitung gerne strukturiert: Für jeden Level eine eigene Seite? Oder ganz anders?
Eine einzelne Seite lässt sich halt gut im Browser durchsuchen. Für jeden Verbesserungsvorschlag bin ich dankbar.
Gruß
Esther

[richard.kunze]

Von readthedocs hatte ich vorher noch nie was gehört. Nach einem ersten Blick darauf finde ich das auch nicht so überzeugend.

Mich reißt das jetzt auch nicht vom Hocker.

Nach der Diskussion (viewtopic.php?f=33&t=4052) hat sich das aber ohnehin erledigt, denke ich.

Ich lese das mal so, dass Du nicht prinzipiell abgeneigt wärst wenn wir Deine Anleitung da mit einbauen? Fände ich prima, mir gefällt die Anleitung nämlich auch sehr gut.

Wie hättest Du denn die Anleitung gerne strukturiert: Für jeden Level eine eigene Seite? Oder ganz anders?
Eine einzelne Seite lässt sich halt gut im Browser durchsuchen.

Ich würde eine Seite pro Level machen, und eine Einsteigsseite mit den Inhalten, die vor 'Erster Erfahrungsgrad "Anfänger"' stehen.

Und wenn wir die Anleitung auf der CFW-Startseite integrieren wäre es wohl eine gute Idee, sich Gedanken zu machen wie man mehr als eine Sprache unterstützt. Eventuell kannst Du da die Struktur von https://github.com/ftCommunity/ftcommun ... aster/docs übernehmen (ein Verzeichnis pro Sprache, und in jedem Sprachverzeichnis die gleiche Unterstruktur), aber da würde ich an Deiner Stelle erstmal noch abwarten, wie (und ob) sich das bei uns bewährt (ich hab bisher auch noch nie eine mehrsprachige Website mit Jekyll aufgesetzt, d.h. ich bin da selbst auch durchaus noch am rumprobieren).

Durchsuchen ist denke ich eher nicht so ein großes Problem: Mit der Aufteilung in eine Seite pro Level hat man immer noch alles zusammen, was thematisch zusammengehört, und für die übergreifende Suche gibts immer noch Suchmaschinen.

Für jeden Verbesserungsvorschlag bin ich dankbar.

Einen hätte ich: Schreib bei Änderungen Commit-Kommentare, die etwas mehr über die jeweilige Änderung aussagen als "Update brickly.md". Als Beispiel: Bei https://github.com/EstherMi/ft-brickly- ... 10774ba8f2 hätte ich als Commit-Kommentar etwas in der Art von "Added 'Kontextmenü' subsections for levels 2 and 3" geschrieben.

Das ist zwar nicht ganz einfach und braucht auch etwas Zeit (über den Text für das Beispiel oben hab ich jetzt auch etwa 5 Minuten nachgedacht, und ein paar mal umformuliert), hilft aber später - wenn man mal was in der Versionsgeschichte nachschlagen will, oder auch wenn man als (noch) Aussenstehender einfach nur neugierig ist wie sich das Projekt so entwickelt hat - immens weiter.

[EstherM]

Einen hätte ich: Schreib bei Änderungen Commit-Kommentare, die etwas mehr über die jeweilige Änderung aussagen als "Update brickly.md". Als Beispiel: Bei https://github.com/EstherMi/ft-brickly- ... 10774ba8f2 hätte ich als Commit-Kommentar etwas in der Art von "Added 'Kontextmenü' subsections for levels 2 and 3" geschrieben.

Das ist zwar nicht ganz einfach und braucht auch etwas Zeit (über den Text für das Beispiel oben hab ich jetzt auch etwa 5 Minuten nachgedacht, und ein paar mal umformuliert), hilft aber später - wenn man mal was in der Versionsgeschichte nachschlagen will, oder auch wenn man als (noch) Aussenstehender einfach nur neugierig ist wie sich das Projekt so entwickelt hat - immens weiter.

Danke für den Hinweis. Ich werde Commit-Kommentare einfügen, sobald die einzelnen Speichervorgänge inhaltlich begründet sind und nicht nur mit der Arbeitsorganisation zu tun habe (Sichern, weil ich einen Tee hole, mir gerade nichts einfällt, ich für heute Schluss mache usw.). Lieber ohne Kommentar oft sichern als zu wenig, jedenfalls in einem Ein-Mann-Projekt, solange es keine nutzbaren Zwischenstände gibt, ist meine Erfahrung.
Gruß
Esther

[heikoh]

Hallo,

ich hätte eine Frage zu den unterschiedlichen Stufen. Evtl. ist es auch ein Bug.

Mein Sohn hat zwei Programme mit unterschiedlichem Namen "geöffnet". Wenn er nun mehr Funktionalitiät benötigt und den "Erfahrungslevel" verändert springt Brickly in das andere Programm. Ist es möglich, den Level zu ändern ohne dass in ein anderes Programm gesprungen wird?

Viele Grüße

Heiko

[richard.kunze]

Danke für den Hinweis. Ich werde Commit-Kommentare einfügen, sobald die einzelnen Speichervorgänge inhaltlich begründet sind und nicht nur mit der Arbeitsorganisation zu tun habe

Dafür ist es - zumindest für das, was schon auf Github ist - eigentlich schon zu spät

Dazu müsstest Du nämlich die Versionsgeschichte umschreiben. Und das geht zwar mit Git ganz gut (und dafür gibt es sogar eigene Befehle, wie "git rebase", "git commit --amend" und so weiter), aber die Sache hat einen Haken: Wenn Du das machst, dann ändern sich auch zwangsläufig alle Commit-IDs (das liegt am Aufbau von Git und ist bei sowas unvermeidlich). Und das wiederum macht bei anderen Repositories, die auf den alten Commits (und deren Commit-IDs) aufbauen, beim nächsten "git pull" dann oft Probleme. Die lassen sich zwar auch lösen, aber das macht ziemlich viel Arbeit - und zwar bei allen anderen, die auf Deinem Repository aufsetzen.

Deshalb die Faustregel: Sobald jemand anderes einen Commit sehen kann, sollte man diesen Commit nicht mehr nachträglich ändern.

Github prüft das übrigens sogar automatisch - wenn Du versuchst, eine "umgeschriebene" Versionhistorie per "git push" zu veröffentlichen, lehnt Github das erstmal ab (die Fehlermeldung ist dann sowas wie "! [rejected] master -> master (non-fast-forward)"). Das kann man zwar umgehen (mit "git push --force"), aber das sollte man nur machen, wenn man einen guten Grund dafür hat.

(Sichern, weil ich einen Tee hole, mir gerade nichts einfällt, ich für heute Schluss mache usw.).

Bei solchen Unterbrechungen lasse ich den aktuellen Stand üblicherweise einfach so uncomitted im Arbeitsverzeichnis. Da ist der Kram genauso sicher (oder unsicher) aufgehoben wie in einem (lokalen) Commit auf demselben Datenträger, und in einem öffentlich zugänglichen Repository hat so komplett unfertiges Zeug eigentlich nichts zu suchen.

Lokale Commits mache ich dann, wenn ich einen logisch zusammenpassenden Teilabschnitt fertig habe. Und dann bekommt der commit auch die passende "Überschrift", die kurz anreißt was ich da gemacht habe.

Und wenn ich dann einen "nutzbaren Zwischenstand" erreicht habe (oder zumindestens einen Zustand, von dem ich denke dass er für andere auch interessant sein könnte), gehe ich die Commits ab dem letzten veröffentlichten Stand noch mal durch, schreibe sie gegebenenfalls um (das geht dann noch problemlos, weil sie ja nur in meiner lokalen Kopie liegen), und veröffentliche sie dann per "git push".

Lieber ohne Kommentar oft sichern als zu wenig, jedenfalls in einem Ein-Mann-Projekt, solange es keine nutzbaren Zwischenstände gibt, ist meine Erfahrung.

Im Prinzip ja. Aber das kann man auch lokal machen - entweder mit "git commit" oder auch - wenn man z.B. nur kurz mal einen Stand sichern will auf den man später schnell zurück kann - mit "git stash".