Community-Firmware für den TXT

[MasterOfGizmo]

Was ich noch gerne machen würde ist, den "Apps" HTML-Seiten mitzugeben, die man dann per Browser vom PC aus zu sehen bekommt. Da könnte jede App z.B. eine Bauanleitung für ein passendes Modell dabei haben. Man könnte sogar Webseiten mitliefern, über die sich das Modell bedienen lässt.

So viele neue Möglichkeiten ...

[Torsten]

Ich verwende schon seit längerem ein ipython-notebook auf dem TXT, das automatisch beim Hochfahren gestartet wird. Das dürfte auch problemlos mit der ftCommunity-Version laufen. Damit ist es möglich, den TXT über eine Browserobefläche direkt in Python (ich verwende hier die Version 3.5m auf dem TXT) zu programmieren. Die Oberfläche erinnert dabei an "Mathematica".

Die ipython-notebook Installation auf dem TXT war nicht ganz trivial und hat mich etwas Zeit gekostet, ausserdem ist sie auch recht gross (>100MB).

Gibt es schon eine Entscheidung darüber, in welchem Verzeichnis solche Anwendungen installiert werden sollten ? (/usr/bin, /usr/local/bin oder etwas anderes ?)

Sollte ein so großes Paket bereits vorinstalliert sein ? ... oder soll dafür ein Paketmanager verwendet werden ? (z.B. pkg, rpm, ... )

Wird in der ftCommunity-Software auch ein gcc/g++ integriert sein (könnte ich bauen) oder sollen die Anwender Executables woanders cross-compilieren ?
Mit den Python-Installationstools (python setup.py) wird es recht kompliziert, falls man zusätzliche C-Sourcen cross-compilieren muss (es funktioniert allerdings!), deshalb würde ich für einen standard gcc auf dem TXT plädieren. Das vereinfacht Software-Installtionen erheblich (kostet aber natürlich mehr Speicherplatz)

Torsten

[ski7777]

Sollte ein so großes Paket bereits vorinstalliert sein ? ... oder soll dafür ein Paketmanager verwendet werden ? (z.B. pkg, rpm, ... )

Also ich würde gerne mit apt und den Raspberry Pi Quellen arbeitetn.

Raphael

[MasterOfGizmo]

Gibt es schon eine Entscheidung darüber, in welchem Verzeichnis solche Anwendungen installiert werden sollten ? (/usr/bin, /usr/local/bin oder etwas anderes ?)
...
Wird in der ftCommunity-Software auch ein gcc/g++ integriert sein (könnte ich bauen) oder sollen die Anwender Executables woanders cross-compilieren ?

Meine Meinung ist dazu: Echte Regeln und Entscheidungen haben wir hier bisher nicht. Und es wird auch keine generellen Regeln geben, was man darf/soll und was nicht. Jeder Beitrag ist willkommen. Natürlich wäre eine Paketverwaltung schick. Aber die muss erst mal jemand bauen. Zur Zeit haben wir nur das Buildroot.

Ich persönlich habe nichts dagegen, wenn Du ein paar größere Pakete fest einbaust. Ob man dann irgendwann doch noch beschliesst, dass es vielleicht eine kleine "User-Version" geben wird und eine große "Developer-Version" sei mal dahin gestellt. Aber zur Zeit sehe ich auch dafür keinen Bedarf.

Und ja, iPython klingt echt cool. Genau sowas stelle ich mir auf dem TXT vor.

[MasterOfGizmo]

Die ipython-notebook Installation auf dem TXT war nicht ganz trivial und hat mich etwas Zeit gekostet, ausserdem ist sie auch recht gross (>100MB).

Eine IPython-Config ist bei buildroot dabei. Funktioniert die nicht?

[MasterOfGizmo]

Ich muss am Launcher noch etwas tun. Wenn der mehr als 9 Apps sieht wird's unschön. Ist aber nur 1-2 Abende Arbeit.

Erledigt. Der Launcher kommt jetzt mit mehr als 9 Apps zurecht und kann die Apps in Kathegorien sortiert anzeigen.

[ski7777]

Und bei mehr als 9Apps pro Kategorie?

[MasterOfGizmo]

Ich hab gerade ftrobopy global mit in die Firmware eingebaut, die Ampel sollte jetzt also auch funktionieren

Geht! Bei meiner Amptel ist nun keine ftrobopy mehr dabei. Muss ich mir mal genau anschauen, was Du da gemacht hast. Mit der WeDo-Lib würde ich dann das gleiche machen.

- zu wenige Lampen hier )

Wenn Du morgen ein paar Lampen in der Post findest weisst Du, dass FT hier mitliest ....

[MasterOfGizmo]

Und bei mehr als 9Apps pro Kategorie?

Man kann seitenweise blättern. Es gibt eh auch eine "All"-Kathegorie, wo man alle Apps wie bisher sieht.

[Torsten]

Die ipython-notebook Installation auf dem TXT war nicht ganz trivial und hat mich etwas Zeit gekostet, ausserdem ist sie auch recht gross (>100MB).

Eine IPython-Config ist bei buildroot dabei. Funktioniert die nicht?

iPython ist nur ein kleiner Teil einer iPython-notebook Installation. Ein paar Beispiele, was man alles mit ipython-notebook machen kann, findet man z.B. unter https://wakari.io/gallery

Python-notebook ist sowas wie eine graphische Oberfläche für Python, die im Browser läuft.

[richard.kunze]

Geht! Bei meiner Amptel ist nun keine ftrobopy mehr dabei. Muss ich mir mal genau anschauen, was Du da gemacht hast. Mit der WeDo-Lib würde ich dann das gleiche machen.

Ist https://github.com/itdaniher/WeDoMore die Wedo-Lib die Du verwendest?

Wenn ja, dann sollte das analog zu https://github.com/ftCommunity/ftcommun ... 9bc2aa6fe4 für ftrobopy funktionieren.

[richard.kunze]

Eine IPython-Config ist bei buildroot dabei. Funktioniert die nicht?

Wenn ich das richtig sehe, dann wurde die 2014 zuletzt angefasst und referenziert eine Uralt-Version von iPython die gar nicht mehr angeboten wird.

Wäre aber zumindest mal eine Grundlage, und wenn wir die kaputte Config reparieren kann man ja auch mal was an Buildroot zurückgeben...

[richard.kunze]

Hier mal mein Senf zum Thema "Release".

Ich denke, wir sollten demnächst eine Version 0.9 (gute Idee vom MoG) herausgeben.

Zum einen haben wir jetzt langsam genug Funktionen, um tatsächlich was mit der Community-Firmware anfangen zu können. Und zum anderen fürchte ich, dass wir Gefahr laufen uns in immer mehr halbfertigen Features zu verzetteln wenn wir einfach weiter vor uns hin basteln - ein Release macht da einen sauberen Schnitt und hilft dabei, das was wir bisher haben erstmal zu konsolidieren. Und wir kriegen mit einem Release (hoffentlich) auch mehr Leute, die die Community-Firmware mal ausprobieren (hat die aktuell außer MoG und mir überhaupt schon mal wer installiert?) und uns Rückmeldungen über ihre Erfahrungen damit geben.

Von daher hier mal meine Sicht der offenen Baustellen, die wir vor 0.9 noch angehen sollten:

• Dokumentieren, was wir längerfristig als Schnittstellen für "TXT-Anwendungen" unterstützen wollen. Das halte ich sogar für den wichtigsten Punkt, weil wir hier die Basis dafür schaffen, dass die Anwendungen dann auch mit der übernächsten Version noch laufen.
• von Python 2 auf Python 3 wechseln (entweder auf 3.4 aus Buildroot oder - wenn das mit erträglichem Aufwand klappt - gleich auf 3.5.1). Python ist Teil unserer Anwendungsschnittstelle, und Python 2 ist da doch reichlich angestaubt.
• von Qt 4 auf Qt 5 wechseln (aus dem gleichen Grund wie bei Python)
• iPython in die Firmware einbauen
• ft-robo-snap in die Firmware einbauen
• Bugs und Probleme dokumentieren (wozu haben wir auf Github einen Issue-Tracker?) und reparieren
• Ein Installations-Image zusammenbauen und Anleitungen schreiben

An Schnittstellen würde ich erstmal das unterstützen was wir aktuell schon haben:

• Die "RoboPro-Schnittstelle" auf Port 65000 um mit den Programmen für die Originalfirmware kompatibel zu bleiben
• Eine Python-Umgebung mit
  • Python 3 als Programmiersprache
  • ftrobopy für die I/O-Steuerung
  • Qt für Grafik, (Touch-)Input und Sound
  • dem Format der GUI-Apps als das Äquivalent zu den .rpp-Dateien von RoboPro

Und auch bei der Implementierung würde ich für Version 0.9 bei dem bleiben was schon da ist, sprich: Wir verwenden TxtControlMain sowohl für die RoboPro-Kompatibilität als auch als Backend für ftrobopy.

Alles weitere (direkte Ansteuerung der I/O-Platine, RoboPro-Kompatibilität ohne TxtControlMain, zusätzliche Schnittstellen, WeDo-Steuerung aus RoboPro, ROS-Integration, Kontrolle der Power-Button-LED, ...) sind dann Themen für spätere Versionen.

[MasterOfGizmo]

Ist https://github.com/itdaniher/WeDoMore die Wedo-Lib die Du verwendest?

Wenn ja, dann sollte das analog zu https://github.com/ftCommunity/ftcommun ... 9bc2aa6fe4 für ftrobopy funktionieren.

Hab's mal eingebaut. Ist aber noch ungetestet. Es beinhaltet einen zusätzlichen Patch, weil pyusb sich auf die gcc-Tools verlässt um die libusb zu finden. Aber die sind bei uns (noch) nicht dabei.

[MasterOfGizmo]

[*] Dokumentieren, was wir längerfristig als Schnittstellen für "TXT-Anwendungen" unterstützen wollen. Das halte ich sogar für den wichtigsten Punkt, weil wir hier die Basis dafür schaffen, dass die Anwendungen dann auch mit der übernächsten Version noch laufen.

Ich befürchte, dass wir genau das in einer V0.9 nicht können. Ich halte es für wahrscheinlich, dass mit den ersten Usern auch nochmal API-Änderungswünsche kommen. So schlimm finde ich es auch nicht. Dann muss man ggf. später seine Apps nochmal geringfügig an ein neues Release der Firmware anpassen. Aber was ich einbauen kann ist eine "expected-firmware-version: 0.9"-Zeile ins manifest. Dann kann die Web-GUI beim Upload eine Warnung ausgeben, dass die App für eine ältere Version der Firmware geschrieben wurde und ggf nicht läuft.

Stabile APIs wären für mich eine Sache für V1.0

[*] von Python 2 auf Python 3 wechseln (entweder auf 3.4 aus Buildroot oder - wenn das mit erträglichem Aufwand klappt - gleich auf 3.5.1).

Ok

[*] von Qt 4 auf Qt 5 wechseln (aus dem gleichen Grund wie bei Python)

Ok

[*] iPython in die Firmware einbauen

Ist eine schönes Feature, aber m.E. kein Muss für eine 0.9

[*] ft-robo-snap in die Firmware einbauen

Wer bin ich, da zu diskutieren

[*] Bugs und Probleme dokumentieren (wozu haben wir auf Github einen Issue-Tracker?) und reparieren

Sehe ich für eine 0.9 auch unkritisch, solange die Hauptfunktion nutzbar ist.

[*] Ein Installations-Image zusammenbauen und Anleitungen schreiben[/list]

Ok

An Schnittstellen würde ich erstmal das unterstützen was wir aktuell schon haben:
...

Da würde ich ein paar kommentierte Demos schreiben und eine Wiki-Seite, die an zwei/drei einfachen Beispielen erklärt, wie man ein simples Modell steuert.

Und auch bei der Implementierung würde ich für Version 0.9 bei dem bleiben was schon da ist, sprich: Wir verwenden TxtControlMain sowohl für die RoboPro-Kompatibilität als auch als Backend für ftrobopy.

Alles weitere (direkte Ansteuerung der I/O-Platine, RoboPro-Kompatibilität ohne TxtControlMain, zusätzliche Schnittstellen, WeDo-Steuerung aus RoboPro, ROS-Integration, Kontrolle der Power-Button-LED, ...) sind dann Themen für spätere Versionen.

[/quote]
Ok

[MasterOfGizmo]

Hmm, qt5 könnte knifflig werden. Beispiel: PyQt und Python-SIP verlangen Qt. Aber Qt schließt Qt5 aus. Also z.Zt kein PyQt mit Qt5 ...

Ggf. fehlen da nur ein paar Abhängigkeiten. Oder aber die Versionen in Buildroot sind tatsächlich inkompatibel mit Qt5.

Das wäre vielleicht der Moment, sich mal mit den Buildroot-Leuten zu unterhalten.

Edit: Und Qt5 baut auch nicht fehlerfrei durch ... vielleicht sollten wir erstmal bei Qt4.8 bleiben ...

[MasterOfGizmo]

Als Speicherplatz für Userdaten würde ich die erste Fat-Partition vorschlagen. Das kann dann jeder PC einfach lesen und man kann einfach Daten austauschen und sichern.

[Torsten]

Als Speicherplatz für Userdaten würde ich die erste Fat-Partition vorschlagen. Das kann dann jeder PC einfach lesen und man kann einfach Daten austauschen und sichern.

Man muss dann halt bloss aufpassen, dass man nicht versehentlich mal das uImage-File löscht oder das am335x-kno_txt.dtb File verändert, welche ja auch in dieser Partition residieren. Ausserdem sollte man die Partition dann natürlich etwas größer machen (derzeit wird im Community-Firmware README ja noch eine Größe von 20-40MB empfohlen).

[richard.kunze]

Als Speicherplatz für Userdaten würde ich die erste Fat-Partition vorschlagen. Das kann dann jeder PC einfach lesen und man kann einfach Daten austauschen und sichern.

Prinzipiell ja.

Aber dann verschwenden wir mit unserem aktuellen Partitions-Layout entweder sehr viel Speicherplatz auf der SD-Karte (wenn wir eine kleine FAT-Partition nehmen) oder wir bekommen gigantische Images, weil wir vor unseren wenigen 100 MB Systemdaten noch zig Gigabyte leere FAT-Partition unterbringen müssen (und wir brauchen dann für jede SD-Kartengröße eigene Images). Und die Partitionierung umdrehen klappt ebenfalls nicht, weil U-Boot den Kernel und DTB von der ersten Partition liest (und die muss FAT sein).

Was ich im Moment überlege ist, das System in einem per Loopback gemounteten Image-File auf der FAT-Partition unterzubringen. Das hätte den Charme, dass die Installation absolut simpel ist (einfach Kernel, DTB und Root-Image auf die Karte kopieren), Upgrades wären ebenfalls einfach (das alte Image umbenennen und das neue unter dem alten Namen schreiben sollte eigentlich sogar im laufenden System klappen) und wir brauchen uns um verschieden große SD-Karten keinen Kopf machen.

Nachteil wäre eventuell, dass Schreiben auf der System-"Partition" in so einem Setup noch langsamer ist als eh auf SD-Karte. Aber eigentlich brauchen wir im System selbst auch nicht schreiben (Logs können wir auch im RAM halten oder direkt auf FAT abspeichern, und Konfigurationsdaten gehören eh in den "Benutzer-Bereich"). Und wir müssten auf jedenFall nochmal an die U-Boot-Konfig, um mit anderen Boot-Parametern zu starten. Vermutlich bräuchten wir außerdem noch eine Initrd um das Loop-Device für das Rootfilesystem einzurichten.

Aber ausprobieren werde ich das die Tage auf jeden Fall mal.

[TiniTech]

Erst mal: Toll, was ihr hier auf die Beine stellt. Vielen Dank!

@ Testen:
Ich helfe gerne beim Testen - mittlerweile habe ich auch alles dafür vorbereitet: TXT zum Booten von der SD-Karte umkonfiguriert, 16GB SD-Karte partitioniert, GIT-Repository gezogen.
Fehlt nur noch ein Build. Auch das habe ich gestern früh angestoßen. Allerdings: Mein (eben erst dafür eingerichteter Linux-Rechner) ist ein 850MHz Pentium III mit 256 MB RAM - nach 8h Buildprozess war immer noch kein Ergebnis in Sicht.
Daher: Würde mir jemand die erforderlichen Dateien für die SD-Karte via DropBox o.ä. bereitstellen? Dann teste ich gerne und gebe Rückmeldung, was einem "externen" Nutzer auffällt.
[NB: Klappt die USB-Netzwerk-Verbindung auch von Linux aus? Dazu habe ich bisher nichts gefunden, wäre für mich aber wg. des Testrechners ganz hilfreich.]

@ Apps:
Eine tolle Idee, die Apps zu Paketen zu schnüren aus Python-Skripten und ggf mit Webinterface/Erläuterung. Nach einem Blick auf deren Inneres: Ich würde als "best practice" vorschlagen, die App-Pakete mit einer Standard-(Ordner)struktur zu versehen. Im Wurzelverzeichnis sollte dann nur das Manifest und eine main.py liegen; Weiteres dann in ./res für (Bild)Ressourcen, ./webif für die (angedachte) Web-Bedienschnittstelle, ./doc für eine Dokumentation, ./lib für weitere Programmkomponenten.

@ Dateisystem/Partitionsaufbau:
Wenn sich da was ändert - und damit die TXT-Boot-Konfiguration angepasst werden muss: Reicht es, einfach die neue Konfig in den TXT zu schreiben? Nicht, dass ich meinen TXT an dieser Stelle Boot-Unfähig mache, weil ich nicht vom Out-Of-The-Box-Status komme sondern die Boot-Konfiguration schon mal angepasst hatte.

@ Doku:
Ich bin recht neu dabei, mit dem TXT zu experimentieren und auch was Linux/die Kommandozeile angeht, aber es interssiert mich und ich lass' i.d.R. nicht locker, bis es dann auch geht.
Mit diesem Hintergrund würde ich anbieten, für ebenso interessierte Neulinge aufzuschreiben, was - ausgehend von einem aktuellen Lubuntu-Linux und einem TXT-Controller frisch aus der Verpackung - zu tun ist, um die Community-Firmware selbst zu bauen und zum laufen zu kriegen.
Wenn da Interesse besteht: Wo soll so ein Dokument hin? Am Besten wohl in ein Wiki?