Roadmap Community-Firmware V1.0

Community-Firmware (cfw), Selbstbaucontroller (TX-Pi, ftduino, usw.), usw.
Forumsregeln
Bitte beachte die Forumsregeln!
Benutzeravatar
MasterOfGizmo
Beiträge: 1822
Registriert: 30 Nov 2014, 07:44

Roadmap Community-Firmware V1.0

Beitrag von MasterOfGizmo » 06 Mai 2016, 11:06

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.
Für fischertechnik: Arduino ftDuino http://ftduino.de, Raspberry-Pi ft-HAT http://tx-pi.de/hat

richard.kunze
Administrator
Beiträge: 556
Registriert: 26 Dez 2015, 23:49
Wohnort: Rhein-Main-Gebiet

Re: Roadmap Community-Firmware V1.0

Beitrag von richard.kunze » 07 Mai 2016, 10:53

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
Administrator
Beiträge: 556
Registriert: 26 Dez 2015, 23:49
Wohnort: Rhein-Main-Gebiet

Re: Roadmap Community-Firmware V1.0

Beitrag von richard.kunze » 07 Mai 2016, 11:01

MasterOfGizmo hat geschrieben: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.

Benutzeravatar
MasterOfGizmo
Beiträge: 1822
Registriert: 30 Nov 2014, 07:44

Re: Roadmap Community-Firmware V1.0

Beitrag von MasterOfGizmo » 07 Mai 2016, 11:43

richard.kunze hat geschrieben: 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.
Für fischertechnik: Arduino ftDuino http://ftduino.de, Raspberry-Pi ft-HAT http://tx-pi.de/hat

Benutzeravatar
Computing
Beiträge: 57
Registriert: 17 Aug 2014, 16:51
Wohnort: Nürnberg

Re: Roadmap Community-Firmware V1.0

Beitrag von Computing » 07 Mai 2016, 11:44

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!

Benutzeravatar
MasterOfGizmo
Beiträge: 1822
Registriert: 30 Nov 2014, 07:44

Re: Roadmap Community-Firmware V1.0

Beitrag von MasterOfGizmo » 07 Mai 2016, 20:44

Computing hat geschrieben: 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:
Computing hat geschrieben: 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.
Computing hat geschrieben: 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.
Computing hat geschrieben: 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.
Computing hat geschrieben: 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.
Für fischertechnik: Arduino ftDuino http://ftduino.de, Raspberry-Pi ft-HAT http://tx-pi.de/hat

Benutzeravatar
MasterOfGizmo
Beiträge: 1822
Registriert: 30 Nov 2014, 07:44

Re: Roadmap Community-Firmware V1.0

Beitrag von MasterOfGizmo » 07 Mai 2016, 23:24

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 ....
Für fischertechnik: Arduino ftDuino http://ftduino.de, Raspberry-Pi ft-HAT http://tx-pi.de/hat

Rei Vilo
Beiträge: 79
Registriert: 19 Dez 2015, 15:39

Re: Roadmap Community-Firmware V1.0

Beitrag von Rei Vilo » 08 Mai 2016, 18:21

richard.kunze hat geschrieben: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.
Automatic translation hat geschrieben: 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!

Benutzeravatar
Marspau
Beiträge: 226
Registriert: 01 Nov 2010, 00:01
Wohnort: Canada

Re: Roadmap Community-Firmware V1.0

Beitrag von Marspau » 08 Mai 2016, 18:36

@ Rei Vilo,

I agree,

Grub
Marspau

richard.kunze
Administrator
Beiträge: 556
Registriert: 26 Dez 2015, 23:49
Wohnort: Rhein-Main-Gebiet

Re: Roadmap Community-Firmware V1.0

Beitrag von richard.kunze » 08 Mai 2016, 20:53

Hello Rei Vilo,
Rei Vilo hat geschrieben: 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.
Rei Vilo hat geschrieben: 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.

Benutzeravatar
ski7777
Beiträge: 844
Registriert: 22 Feb 2014, 14:18
Wohnort: Saarwellingen

Re: Roadmap Community-Firmware V1.0

Beitrag von ski7777 » 08 Mai 2016, 21:04

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

Benutzeravatar
ski7777
Beiträge: 844
Registriert: 22 Feb 2014, 14:18
Wohnort: Saarwellingen

Re: Roadmap Community-Firmware V1.0

Beitrag von ski7777 » 08 Mai 2016, 21:06

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
Beiträge: 79
Registriert: 19 Dez 2015, 15:39

Re: Roadmap Community-Firmware V1.0

Beitrag von Rei Vilo » 10 Mai 2016, 16:23

@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
Beiträge: 54
Registriert: 21 Apr 2015, 19:03
Wohnort: Oberfranken
Kontaktdaten:

Re: Roadmap Community-Firmware V1.0

Beitrag von LarsKusch » 12 Mai 2016, 22:00

#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

Benutzeravatar
Computing
Beiträge: 57
Registriert: 17 Aug 2014, 16:51
Wohnort: Nürnberg

Re: Roadmap Community-Firmware V1.0

Beitrag von Computing » 19 Mai 2016, 20:39

MasterOfGizmo hat geschrieben:
Computing hat geschrieben: 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)

Benutzeravatar
MasterOfGizmo
Beiträge: 1822
Registriert: 30 Nov 2014, 07:44

Re: Roadmap Community-Firmware V1.0

Beitrag von MasterOfGizmo » 21 Mai 2016, 08:18

Computing hat geschrieben: 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.
Für fischertechnik: Arduino ftDuino http://ftduino.de, Raspberry-Pi ft-HAT http://tx-pi.de/hat

Benutzeravatar
Computing
Beiträge: 57
Registriert: 17 Aug 2014, 16:51
Wohnort: Nürnberg

Re: Roadmap Community-Firmware V1.0

Beitrag von Computing » 21 Mai 2016, 09:36

MasterOfGizmo hat geschrieben: 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.!

nq30
Beiträge: 144
Registriert: 25 Feb 2017, 07:44

Re: Roadmap Community-Firmware V1.0

Beitrag von nq30 » 28 Feb 2017, 11:33

Ich könnte ein bisschen übersetzen...
Mit freundlichen Grüssen
nq30

ft:cool :)

Benutzeravatar
ski7777
Beiträge: 844
Registriert: 22 Feb 2014, 14:18
Wohnort: Saarwellingen

Re: Roadmap Community-Firmware V1.0

Beitrag von ski7777 » 28 Feb 2017, 17:33

nq30 hat geschrieben: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

nq30
Beiträge: 144
Registriert: 25 Feb 2017, 07:44

Re: Roadmap Community-Firmware V1.0

Beitrag von nq30 » 01 Mär 2017, 07:02

Also ich würde eine Settings-App bestehend aus NetInfo, WiFi, Sprache und Netzwerk vorschlagen.
Ausserdem fände ich es cool wenn Calc und Clock vorinstalliert sind.
Mit freundlichen Grüssen
nq30

ft:cool :)

Antworten