Roadmap Community-Firmware V1.0

[MasterOfGizmo]

Die 0.9 ist draußen. Eine 0.9.1 wird demnächst folgen mit Bugfixes. Aber parallel soll es natürlich weitergehen.

Ich sehe die wesentlichen Punkte für eine 1.0:

• Bluetooth-Unterstützung
• bessere RoboPro-Anbindug

Zum Bluetooth müsste man klären, wozu man es eigentlich verwenden will. Ich persönlich sehe den Nutzen des Bluetooth-Netzwerks nicht so. WLAN ist dafür m.E: bequemer. Allerdings könnte Bluetooth-Netz dort nett sein, wo man kein WLAN hat. Ansonsten eignet sich Bluetooth natürlich auch für so Sachen wie die Anbindung eines GPS oder einer Wiimote oder eines PS3-Controllers.

Die RoboPro-Anbindung schaue ich mir gerade an. Wir haben da als Vorab-Version mal ein paar Dateien von FT bekommen. Da ist zwar auch nicht der komplette Source-Code dabei. Aber immerhin die Bindings für die Biblotheken. Die ROBOPro-Lib besteht zwar eigentlich drauf, direkt per SDL auf den Bildschirm zu malen. Aber das sollte sich auch gegen irgendwas linken lassen, das sich als SDL-Bibliothek ausgibt und die Zeichenbefehle dann umleitet. Ich würde die Zeichenbefehle dann über einen IP-Socket nach Außen bereit stellen. Dann kann sich da eine beliebige Anwendung drauf verbinden und das Malen übernehmen. Das würde diesen Knoten mal ein wenig auflösen und mit etwas Glück lässt sich die ganze RoboPro-Funktionalität in die neue GUI abbilden.

[richard.kunze]

Für mich sind die wichtigsten Punkte

• Ansteuerung der I/O-Pins ohne TxtControlMain
• Eine Schnittstelle für Erweiterungen, die über die einfachen Apps hinausgeht die wir aktuell haben.
• ebenfalls bessere RoboPro-Anbindung
• eine (browserbasierte) IDE für den TXT
• Dokumentation auch auf Deutsch

Zur Ansteuerung der I/O-Pins haben wir ebenfalls schon was von Fischertechnik bekommen, mein Plan ist da zunächst eine Schnittstellenbeschreibung herauszuziehen und auf Github zu stellen und im zweiten Schritt eine Beispielimplementation in Python zu machen.

Für die Erweiterungsschnittstelle haben wir mit den Apps und dem "Appstore" auf Github ja auch schon einiges. Aber mittel- bis langfristig denke ich, dass wir mindestens noch zwei Kategorien von Erweiterungen zusätzlich brauchen: "Services" und "Libraries". Services stelle ich mir ähnlich wie Apps vor, nur mit dem Unterschied dass sie keinen direkten Zugriff auf das Display haben und dass - anders als bei den Apps - mehr als ein Service gleichzeitig laufen kann. "Libraries" sind Sammlungen von Funktionen, die von Services und Apps verwendet werden können, die aber selbst keine aktiven Prozesse anstoßen. Und um das Ganze zu verwalten (vor allem die Abhängigkeiten zwischen den einzelnen Teilen) werden wir nicht drumrumkommen, eine Art Paketmanager zu bauen (inzwischen denke ich auch, dass wir das eher selbst machen sollten statt auf eine "große" Distribution wie Debian umzuschwenken. Oder zumindest mal bei den etwas moderneren Ansätzen zum Paketmanagement abgucken).

Für RoboPro stelle ich mir eine möglichst weitgehende Integration in unser UI vor: Permanent auf dem TXT gespeicherte RoboPro-Programme sind ganz normale Apps, und "ins RAM" heruntergeladenen Programme sowie der Online-Modus von RoboPro macht ebenfalls ein TXT-Gui-Fenster auf in dem sich die Programme dann austoben dürfen.

Und neben RoboPro hätte ich gerne eine direkt in die Firmware integrierte IDE, die man einfach nur per Browser aufrufen muss um loslegen zu können. Idelaerweise gleich mit integrierte Anbindung an Github, so dass man seine eigenen TXT-Programme dann auch direkt veröffentlichen kann wenn man will. Die Bestandteile für sowas gibt es ebenfalls schon fertig, das ist also auch nicht so ein Riesenaufwand wie es auf den ersten Blick scheint.

Und zuguterletzt denke ich ist es durchaus sinnvoll, wenn wir unsere Doku auf Github zweisprachig führen. Schließlich dürften die allermeisten TXT-Benutzer Deutsch als Muttersprache haben. Das wäre übrigens auch der Punkt, an dem auch jemand ohne Programmierkenntnisse sehr gut helfen kann.

[richard.kunze]

Aber das sollte sich auch gegen irgendwas linken lassen, das sich als SDL-Bibliothek ausgibt und die Zeichenbefehle dann umleitet. Ich würde die Zeichenbefehle dann über einen IP-Socket nach Außen bereit stellen. Dann kann sich da eine beliebige Anwendung drauf verbinden und das Malen übernehmen. Das würde diesen Knoten mal ein wenig auflösen und mit etwas Glück lässt sich die ganze RoboPro-Funktionalität in die neue GUI abbilden.

Ich hätte da eher gedacht, dass wir für RoboPro eher sowas machen wie hier angedeutet http://stackoverflow.com/a/144953 - d.h. wir starten eine App (oder eine "Pseudo-App") die dem RoboPro-Programm den (bzw einen Teil des) Displays zur Verfügung stellt und lassen RoboPro dann halt per SDL nach Belieben in seinen Teilbereich malen.

[MasterOfGizmo]

Ich hätte da eher gedacht, dass wir für RoboPro eher sowas machen wie hier angedeutet http://stackoverflow.com/a/144953 - d.h. wir starten eine App (oder eine "Pseudo-App") die dem RoboPro-Programm den (bzw einen Teil des) Displays zur Verfügung stellt und lassen RoboPro dann halt per SDL nach Belieben in seinen Teilbereich malen.

Ich befürchte das klingt einfacher als es ist. Auf modernen Grafikkarten könnte man den Framebuffer irgendwo offscreen legen und die GraKa blendet das dann an passender Stelle passend skaliert ein. Aber wir haben nur einen einzige recht dummen Framebuffer. Das hiesse, dass wir dem SDL einen Fake-Framebuffer irgendwo manuell hinmappen müssen und dann manuell den passenden Ausschnitt im echten Display regelmäßig einblenden. Geht sicher auch irgendwie, klingt aber m.E. nach recht viel Aufwand für eine am Ende doch nicht richtig integrierte Lösung.

Wenn ich das recht verstehe steuert RoboPro den TXT-Bildschirm genau wir den des TX an, korrekt? Auf PC-Seite wird da kein Unterschied zwichen TX und TXT-Bildschirm gemacht, oder? Dann könnte man ja ggf. eine exakte Kopie des TX-Bildschirms auf dem TXT einblenden. Dann sähen die Programme zumindest wieder aus wie auf dem PC vom User entworfen.

Die RoboProLib abstrahiert schon ein paar Sachen ganz nett. Man wird z.B. problemlos ein paasendes Verzeichnis auf der Community-Firmware zum Speichern der Programm mitgeben können. Auch das Starten und Stoppen von RoboPro-Programmen von der FTC-GUI aus sollte kein Problem sein. Aber ein paar Sachen sind leider direkt in die RoboProLib reinkodiert. Dazu gehört die gesamte Ausgabe per SDL, die Ansteuerung der MotorIOLib (was wiederum harmlos ist, da wir deren Source-Code haben). und es scheint, dass der Zugriff auf I2C direkt per Zugriff auf die KeLib (Ke == Knobloch Elktronik?) erfolgt.

Die schönste Lösung wäre natürlich eine RoboPro-Lib, die das alles über eine halbwegs klare API regelt. Aber wenn man das alles per LD_PRELOAD bzw. direkt in ein FtcTxtControl reinkopiliertes Fake-SDL schafft, dann wäre zwar dieses Binary ein großer Hack, aber alles außenrum wäre recht sauber und halbwegs elegant.

[Computing]

Hi,

ich hätte auch noch ein paar Ideen:
1.: Wenn gute RoboPro Anbindung vorhanden: dass man auch im Online Modus auf den TXT Bildschirm zugreifen kann.(so wie im Download Modus)
2.: Im Menüfenster (auf TXT) ist ja unten rechts bzw. oben links ein Pfeil, wenn mehr Apps drauf sind als eine Seite fassen kann. Man könnte hier das gleiche verfahren machen, wie z. B. im Appsorte, dass ein Balken zum "nach unten schieben" da ist!
3.: Dass man auch im Browser (besser!!) auf den TXT zugreifen kann (z. B. auf Kamera klicken, dann Launch this application on the TXT und dann noch irgendwo draufklicken, dass man die Kamera sieht.)
4.: Wenn eine App lädt, dass dann nicht einfach nur das "Drehteil" über den Bildschirm kommt, sonder dass z. B. der Bildschirm blau wird und dann Laden von "Appname"... und drunter der Drehkreis!

[MasterOfGizmo]

ich hätte auch noch ein paar Ideen:

Eigentlich hatte ich gehofft, dass hier vor allem eigene Beiträge gesammelt werden. Mit Wünschen allein ist es ja nicht getan, Irgendwer muss die Sachen ja auch umsetzen.

Aber zu Deinen Ideen:

1.: Wenn gute RoboPro Anbindung vorhanden: dass man auch im Online Modus auf den TXT Bildschirm zugreifen kann.(so wie im Download Modus)

Da haben wir wohl keinerlei Einfluss drauf. Im Online-Modus bestimmt der PC was passiert. Und wenn der dem TXT nicht mitteilt was auf dem Bildschirm dargestellt werden soll, dann können wir auf dem TXT nichts machen.

2.: Im Menüfenster (auf TXT) ist ja unten rechts bzw. oben links ein Pfeil, wenn mehr Apps drauf sind als eine Seite fassen kann. Man könnte hier das gleiche verfahren machen, wie z. B. im Appsorte, dass ein Balken zum "nach unten schieben" da ist!

Das widerum ist keine schlechte Idee. Ich bin mir aber nicht ganz sicher, ob man die Icons so weit zusammenschieben kann, dass genug Platz für den Scrollbar ist.

3.: Dass man auch im Browser (besser!!) auf den TXT zugreifen kann (z. B. auf Kamera klicken, dann Launch this application on the TXT und dann noch irgendwo draufklicken, dass man die Kamera sieht.)

Wenn Du Deine Kamera nicht siehst ist es am einachsten, dem Kabel zu folgen, das in den TXT eingesteckt ist. Wenn an einem Ende des Kabels der USB-Stecker ist wirst Du am anderen die Kamera sehen.

4.: Wenn eine App lädt, dass dann nicht einfach nur das "Drehteil" über den Bildschirm kommt, sonder dass z. B. der Bildschirm blau wird und dann Laden von "Appname"... und drunter der Drehkreis!

Welchen Vorteil hätte das? Ich nehme ja an, dass Du nicht während das Programm lädt schon vergessen hast, auf welches icon Du vorher geklickt hast.

[MasterOfGizmo]

Hier läuft nun ein massiv abgespecktes TxtControlMain ohne chroot und tut zumindest mal das was die chroot-Loesung auch tat. Von hier sollte ich weiter arbeiten können. Als erstes versuche ich mal den Robopro-Download bzw. den Offline-Betrieb wieder herzustellen.

Aber es ist schon recht wildes Flickwerk, da auf dem PC RoboPro 4.2.3 laueft, der Original-Tarball von FT nur die TXT-Seite zu 4.1.5 enthaelt und wir von FT noch Details zu 4.2.2 bekommen haben. Das passt alles nicht so 100%ig zusammen ... Irgendwann wünsche ich mir mal alle Unterlagen in einer gemeinsamen Version ....

[Rei Vilo]

Für mich sind die wichtigsten Punkte
Und zuguterletzt denke ich ist es durchaus sinnvoll, wenn wir unsere Doku auf Github zweisprachig führen. Schließlich dürften die allermeisten TXT-Benutzer Deutsch als Muttersprache haben. Das wäre übrigens auch der Punkt, an dem auch jemand ohne Programmierkenntnisse sehr gut helfen kann.

And finally it I think is quite reasonable, if we carry our documentation on Github bilingual. Finally, the vast majority TXT users are likely to have German as their mother tongue. It's also the point at which someone without programming skills can help very well.

I'd like to stress how important English is. If the community wants to lure some developers into the project, English is a must-have. Keep in mind the MPU comes from Texas Instruments. All the documentation and activity for the Raspberry Pi and BeagleBone are in English.

Should this project switch to German only, I'm sorry I couldn't follow as I don't speak German. Please note English is not my mother tongue; I could have posted on another European language.

Ultimately, a German-only community may encourage non-German fischertechnik users to change for a more international-minded system.

Thank you!

[Marspau]

@ Rei Vilo,

I agree,

Grub
Marspau

[richard.kunze]

Hello Rei Vilo,

I'd like to stress how important English is. If the community wants to lure some developers into the project, English is a must-have. Keep in mind the MPU comes from Texas Instruments. All the documentation and activity for the Raspberry Pi and BeagleBone are in English.

That is exactly the reason why we use English as the primary language for the project on Github. And this will definitely not change.

But on the other hand, I don't want to exclude people who don't speak (or rather, read) English well enough to understand the documentation. As an example, I know that at least three of our current users are children of age 12 to 14, who are probably not fluent enough in English to get by with documentation in English only. That is why I'd like to see our documentation (as in Wiki pages, Readmes etc.) in other languages as well. I picked German as an example simply because it is probably the native language of the biggest part of our user base.

Should this project switch to German only, I'm sorry I couldn't follow as I don't speak German. Please note English is not my mother tongue; I could have posted on another European language.

No worries, as far as I am concerned, English will stay the primary language for the community firmware.

But I'd certainly welcome additional translations to other languages. If you have the time and inclination, feel free to translate e.g. the wiki pages or the project documentation (such as it is, for now we basically have the readme.md and the wiki) to your native language. I'll happily integrate any and all translations into the project.

[ski7777]

I don't have any problem with reading / listening and understanding technical articles. On my side we could open an English thread for questions and ideas of Rei and Marspau. We could involve more English users and for the Germans could have a german thread, too.

Raphael

[ski7777]

I think if a only-german user found an issue he should write it in github in english. I volunteer to transtlste it in English.

Raphael

[Rei Vilo]

@Marspau, @ski7777, @richard.kunze

Thank you for your answers.

Teens willing to play with technology in my country do read English enough to understand technical documents. Additionally, I'm not sure there are many ft-fans in my country.

So I'd better focus on debugging instead of translating.

[LarsKusch]

#Englisch
For my is it a little bit tricky but OK to read and speak English documents and instructions
Feel free to make it only in English!
And if I can't read anything I'm be able to translate it with Google translator.
Lars

[Computing]

3.: Dass man auch im Browser (besser!!) auf den TXT zugreifen kann (z. B. auf Kamera klicken, dann Launch this application on the TXT und dann noch irgendwo draufklicken, dass man die Kamera sieht.)

Wenn Du Deine Kamera nicht siehst ist es am einachsten, dem Kabel zu folgen, das in den TXT eingesteckt ist. Wenn an einem Ende des Kabels der USB-Stecker ist wirst Du am anderen die Kamera sehen.

Ich meinte eigentlich, dass man das Kamera Bild (was sie gerade "sieht") sieht!
LG Robin (Computing)

[MasterOfGizmo]

Ich meinte eigentlich, dass man das Kamera Bild (was sie gerade "sieht") sieht!

Dafür müsstest Du in die Camera-App einen Web-Service wie diesen hier integrieren:

https://pypi.python.org/pypi/webcam-streamer/1.0.5

Da das auch opencv zum Zugriff auf die Kamera nutzt sollte sich das mit der bestehenden Camera-App kombinieren lassen.

[Computing]

Da das auch opencv zum Zugriff auf die Kamera nutzt sollte sich das mit der bestehenden Camera-App kombinieren lassen.

Das wäre doch eigentlich ganz praktisch, weil man dann die Kamera einfacher "STeuern, bzw. "sehen" kann!

LG Robin (Computing)

PS: Nur weil es so geklungen hat: Ich bin kein Programmierer etc.!

[ski7777]

Ich könnte ein bisschen übersetzen...

Mit übersetzen sind wir so weit fertig. Auf deutsch und auf englisch kriegt man das wägrend der Entwicklung selbst hin. Interessant wären Sprachen wie Niederländisch und Französisch.

Aber wenn der Thread ja schon so weit oben ist, wir brachen mal einen "Zeitplan" für die V1.0 oder so.
Interessante Punkte sind in meinen Augen:

• Bluetooth
• Launcher mit Ordnern und Scrollen
• Ein lebendiger Store
• und was ihr noch so wollt...

Raphael

[MasterOfGizmo]

Aber wenn der Thread ja schon so weit oben ist, wir brachen mal einen "Zeitplan" für die V1.0 oder so.

Wozu brauchen wir den? Das hier ist reines Hobby. Warum sollten wir uns da künstlich unter Druck setzen?

Interessante Punkte sind in meinen Augen:

• Bluetooth
• Launcher mit Ordnern und Scrollen
• Ein lebendiger Store
• und was ihr noch so wollt...

Bluetooth hast Du selbst übernommen, genauso wie die Einbindung des TX und wenn ich mich recht erinnere wolltest Du auch die ALSA-Audio-Anbindung machen sowie Apps für Deinen Convention-Modelle im Store veröffentlichen. Den Zeitplan für diese Dinge bestimmst Du damit weitgehend selbst.

Der scrollende Launcher hat Euch nicht gefallen und ich plane daher nicht, ihn in die offizielle Firmware z uübernehmen.

Und einen lebendigen Store kann man nicht einfach per Zeitplan beschließen. Das ergibt sich ggf. irgendwann ...

[ski7777]

Wozu brauchen wir den? Das hier ist reines Hobby. Warum sollten wir uns da künstlich unter Druck setzen?

Ich weiß, trotzdem könnten wir uns mal eine Liste von Dingen machen, die in der nächsten Version sein sollen.

Bluetooth hast Du selbst übernommen

Ich bin bereits am Werk: https://github.com/ski7777/ftcommunity- ... bluetooth2

genauso wie die Einbindung des TX

Da auch. Ich bin im Moment dabei, mir offizielle Informationen bei fischertechnik zu besorgen.

wenn ich mich recht erinnere wolltest Du auch die ALSA-Audio-Anbindung machen

Die Grundidee funktioniert, jedoch passt das Encoding nicht und ich konnte ich den Fehler noch nicht lokalisieren.

sowie Apps für Deinen Convention-Modelle im Store veröffentlichen

Wenn ich die Dateien finde, werde ich das mal machen.

Den Zeitplan für diese Dinge bestimmst Du damit weitgehend selbst.

Nur, weil ich etwas übernehme, heiß das noch lange nicht, das sich andere nicht einbringen dürfen. Ich werde keine Pull Requests grundlos ablehnen.

Der scrollende Launcher hat Euch nicht gefallen und ich plane daher nicht, ihn in die offizielle Firmware zu übernehmen.

In meinen Augen kam da nur positives Feedback, jedoch waren uns Probleme mit der Touchgenauigkeit aufgefallen. Mit einem einfachen Timer würde sich das lösen lassen

Und einen lebendigen Store kann man nicht einfach per Zeitplan beschließen. Das ergibt sich ggf. irgendwann ...

Ich möchte hier nichts beschließen, sondern, würde gerne haben, dass beliebt Apps wie Brickly wieder in den Store kommen.

Raphael