Community-Firmware für den TXT

[DerInder]

Moin,

könnte man durchaus machen, aber villeicht bin ich ja nur ein Sonderfall, so das der Aufwand nicht lohnt

[MasterOfGizmo]

könnte man durchaus machen, aber villeicht bin ich ja nur ein Sonderfall, so das der Aufwand nicht lohnt

Nee, genau dafür haben die Kolegen das ja eingebaut. Nur sollte das dann imho halbwegs selbsterklärend ablaufen. Du hast ja durchaus recht, wenn Dir nicht klar ist, warum diese Frage kommt. Sie soll verhindern, dass irgendjemand fremdes Deinen TXT via Internet kapert solange kein Passwort gesetzt ist. Wenn Du ein Paswort gesetzt hast kann sich niemand fremdes mehr einloggen, also braucht man diese Abfrage auch nicht mehr.

[DerInder]

Moin

OK, dann wäre ein kleiner Infotext schon sinnvoll.
Man kann soetwas zwar auch in ne Doku packen, aber ich lese die meist erst wenn ich ganichtmehr weiterkomme

[richard.kunze]

Wie waere es wenn man noch 'never ask again' auswaehlen koennte?

Keine gute Idee. Das wäre der große rote Scheunentor-Aufmach-Knopf...

Oder einen kleineren Text unten drunter wie 'set a user password to get rid of this request'?

Könnte man als kurzfristigen Workaround machen. Fragt sich nur, ob man das in intuitiv verständlich auf dem zur Verfügung stehenden Platz auf dem TXT-Display unterbekommt.

Edit: Das passiert immer beim Login und wenn der FTC-User sudo benutzen will?

Genauer: Das passiert beim SSH-Login und beim Aufruf von sudo (jeweils egal durch wen), wenn der entsprechende Benutzer (bei SSH der, der sich einloggt, bei sudo derjenige, der es aufruft) kein Passwort gesetzt hat.

Könnte man dann nicht jeweils auf der Console den Text 'Please acknowledge this operation on your TXTs touchscreen for security reasons. You can set a user password to get rid of this request.' einblenden.

Prinzipiell ja (und das wäre auch die schönste Lösung).

Allerdings leider nicht mit der aktuellen, schnell dahingefrickelten Umsetzung über "pam_exec", weil "pam_exec" leider keine Möglichkeit bietet ein Prompt über die aufrufende Applikation auszugeben. Dazu müsste man ein eigenes PAM-Modul schreiben. Das ist zwar auch kein Hexenwerk, aber halt doch etwas aufwendiger als aktuell die zwei PAM-Konfigurationsfiles und ein kleines Python-Scriptchen...

[MasterOfGizmo]

Könnte man als kurzfristigen Workaround machen. Fragt sich nur, ob man das in intuitiv verständlich auf dem zur Verfügung stehenden Platz auf dem TXT-Display unterbekommt.

Ich baue Euch mal was, dass ihr da kleinere Schrift für nutzen könnt. Aber irgendwas sollten wir machen, da das wirklich nicht intuitiv ist.

[Andy42]

Hallo,

kann jemand einen Hinweis geben, wie man die Ein- und Ausgänge des TXT direkt ansprechen/abfragen kann?

Andy42


Info dazu:

1) es gibt offenbar folgende IO-Kanäle, diese werden beim Start des controllers (Original ft) automatisch erzeugt:

# ls /sys/class/gpio -latr
total 0
--w------- 1 root root 4096 Jan 1 01:15 unexport
lrwxrwxrwx 1 root root 0 Jan 1 01:15 gpiochip96 -> ../../devices/ocp/481ae000.gpio/gpio/gpiochip96
lrwxrwxrwx 1 root root 0 Jan 1 01:15 gpiochip64 -> ../../devices/ocp/481ac000.gpio/gpio/gpiochip64
lrwxrwxrwx 1 root root 0 Jan 1 01:15 gpiochip506 -> e0b000.i2c/i2c-0/0-002d/tps65910-gpio/gpio/gpiochip506
lrwxrwxrwx 1 root root 0 Jan 1 01:15 gpiochip32 -> ../../devices/ocp/4804c000.gpio/gpio/gpiochip32
lrwxrwxrwx 1 root root 0 Jan 1 01:15 gpiochip0 -> ../../devices/ocp/44e07000.gpio/gpio/gpiochip0
--w------- 1 root root 4096 Jan 1 01:15 export
drwxr-xr-x 43 root root 0 Jan 1 01:15 ..
drwxr-xr-x 2 root root 0 Jan 1 01:15 .

2) Daten der Kanäle kann ausgelesen werden wie folgt:

# for f in `ls -d /sys/class/gpio/gpiochip*`; do echo $f `cat $f/label $f/base $f/ngpio` ; done

/sys/class/gpio/gpiochip0 gpio 0 32
/sys/class/gpio/gpiochip32 gpio 32 32
/sys/class/gpio/gpiochip506 tps65910 506 6
/sys/class/gpio/gpiochip64 gpio 64 32
/sys/class/gpio/gpiochip96 gpio 96 32

Das bedeutet offenbar:

gpiochip0 heißt gpio und hat Kanäle 0... 31 (32 Stück)
gpiochip32 heißt gpio und hat Kanäle 32... 63 (32 Stück)
gpiochip64 heißt gpio und hat Kanäle 64... 95 (32 Stück)
gpiochip96 heißt gpio und hat Kanäle 96...127 (32 Stück)
gpiochip506 heißt tps65910 und hat Kanäle 506...511 ( 6 Stück, I2C Bus?)

3) Z.B im Verzeichnis /sys/class/gpio/gpiochip0 müßte es die Dateien 'Direction' und 'Value' geben, die die bisherige Definition angeben. Angezeigt werden diese jedoch nicht.

[MasterOfGizmo]

Das sind die gpios der Sitara-Cpu im TXT. Die Ft-Anschluesse werden aber von einer zweiten CPU betrieben und sind daher nicht als gpios direkt vom Linux aus ansprechbar. Man kommt nicht herum, per seriellen device mit der zweiten CPU zu sprechen und der entsprechende Befehle zu erteilen. Genau diese Info wie die Kommunikation dort abläuft fehlt uns aber noch.

[MasterOfGizmo]

Könnte man als kurzfristigen Workaround machen. Fragt sich nur, ob man das in intuitiv verständlich auf dem zur Verfügung stehenden Platz auf dem TXT-Display unterbekommt.

Der Launcher versteht nun ein paar Escape-Sequenzen in dem String des Confirmation-Dialog. Zum einen kann man "\n" verwenden, um eine neue Zeile zu beginnen. Und wenn am Anfang einer Zeile "\s" steht wird sie "small" gezeichnet und wenn dort "\t" steht wird sie "tiny" gezeichnet.

So nutzt man das dann:

Code: Alles auswählen

echo "confirm Bitte bestaetigen\n\sKleiner Zusatz\n\tDies ist sehr klein und bricht um, weil es recht lang ist" | nc txt 9000

[chehr]

Sobald ich damit fertig bin werde ich aber mal versuchen, die Motorplatine direkt (also ohne den aktuellen verwendeten Umweg über die Binaries aus der originalen Firmware) anzusteuern. Falls mir niemand anders dabei zuvorkommt

Wenn das jemand hinbekommt, dann Hut ab...
Ist der Programmcode vom ARM Cortex M3 welcher vermutlich die beiden MC33879 mit den H-Brücken ansteuert überhaupt zugänglich oder muß man da ein EPROM o.ä. ändern?

[richard.kunze]

Sobald ich damit fertig bin werde ich aber mal versuchen, die Motorplatine direkt (also ohne den aktuellen verwendeten Umweg über die Binaries aus der originalen Firmware) anzusteuern. Falls mir niemand anders dabei zuvorkommt

Wenn das jemand hinbekommt, dann Hut ab...

Vielleicht hab ich mich da missverständlich ausgedrückt: Mit "Motorplatine direkt ansteuern" war gemeint, ftrobopy (oder eigene C-Programme) direkt mit der (Original-)Firmware auf der Motorplatine "reden" zu lassen (über die interne serielle Schnittstelle, über die die beiden "Hälften" des TXT kommunizieren) statt wie bisher den Umweg über "TxtMainControl" aus der originalen Linux-Firmware zu nehmen. Nicht die Firmware der Motorplatine zu ändern (das könnte irgendwann auch mal kommen - aber definitiv später. Viel später).

Und die Binaries aus der Original-Linux-Firmware da rauszubekommen ist nicht so arg schwer. Dazu muss man lediglich das Protokoll auf der seriellen Schnittstelle verstehen und eine Open-Source-Implementierung davon schreiben. Und ich (sowie ein paar andere hier) haben dafür von Fischertechnik sogar die "ultimative Dokumentation" (will sagen: Den Quellcode der das implementiert), damit ist das dann noch um einiges einfacher.

Ist der Programmcode vom ARM Cortex M3 welcher vermutlich die beiden MC33879 mit den H-Brücken ansteuert überhaupt zugänglich oder muß man da ein EPROM o.ä. ändern?

Kommt drauf an, was genau Du mit "zugänglich" meinst - die Möglichkeit die Firmware zu ändern oder den Zugang zum Quellcode. Die Firmware flashen geht von der Linux-Seite aus per Software (das hat unter anderem das letzte RoboPro-Update auch gemacht), dazu muss man nicht an der Hardware basteln. Und die Quellen sind zwar nicht öffentlich zugänglich, aber ich und ein paar andere hier haben sie von Fischertechnik bekommen.

[ski7777]

Das Joystickzeugs ist cool.
Dann können wir jetzt aus dem TXT einen fullflight Simulator bauen

Raphael

[Andy42]

Ich habe nach einiger Zeit tatsächlich einen neuen link gefunden, um eine Kommunikation über USB mit ftc-TXT zu ermöglichen:

http://www.java-online.ch/lego/index.ph ... ws.inc.php

Dieses klappte unter Verwendung der Treiber-Version Win7 zusammen mit WinXP. Über einen web browser kann man nun auf den TXT zugreifen. Ein Zugang über ssh (PuTTY oder Cyberduck) klappte allerdings nicht. Aber immerhin.

[ski7777]

Ich habe nach einiger Zeit tatsächlich einen neuen link gefunden, um eine Kommunikation über USB mit ftc-TXT zu ermöglichen:

http://www.java-online.ch/lego/index.ph ... ws.inc.php

Dieses klappte unter Verwendung der Treiber-Version Win7 zusammen mit WinXP. Über einen web browser kann man nun auf den TXT zugreifen. Ein Zugang über ssh (PuTTY oder Cyberduck) klappte allerdings nicht. Aber immerhin.

Das werde ich heute abend mal testen. Wenn der Webbrowser geht, dann geht auch der Rest. Mal sehen, wo der Fehler liegt.

Raphael

[Torsten]

Hallo Richard,

Sobald ich damit fertig bin werde ich aber mal versuchen, die Motorplatine direkt (also ohne den aktuellen verwendeten Umweg über die Binaries aus der originalen Firmware) anzusteuern. Falls mir niemand anders dabei zuvorkommt

die nächste ftrobopy Version wird einen "direct"-Modus haben, der die Motorplatine direkt über den internen seriellen Port des TXT ansteuert, ohne den Umweg über die TxtMainControl und die Sockets. Eine reine Python-Lösung habe ich allerdings nicht hinbekommen. Ich musste eine kleine Hilfslibrary in "C" schreiben, die mit "import ftrobopydirect" eingebunden wird und dann die Kommunikation mit der Motorplatine übernimmt. Abhängigkeiten von irgendwelchen Libraries der ft-Originalfirmware gibt es aber nicht mehr.

Ich werde eine (experimentelle) Version in den nächsten Tagen auf github hochladen, damit ihr sie mit der ftc-firmware testen könnt. I2C, Camera und Sound sind noch nicht verfügbar, Motoren, Lampen und Taster funktionieren aber schon.

Viele Grüße
Torsten

[MasterOfGizmo]

die nächste ftrobopy Version wird einen "direct"-Modus haben, der die Motorplatine direkt über den internen seriellen Port des TXT ansteuert

Das klingt wirklich sehr gut!

Dann fehlt uns eigentlich nur noch der RoboPro-Interpreter ... aber ich befürchte, dass wir da kaum rankommen werden ...

I2C, Camera und Sound sind noch nicht verfügbar

Gehört das wirklich in ftrobopy? Für das alles gibt es ja bereits Standard-Python-Bindings. Und nichts davon läuft über den Motorcontroller. Selbst für den Sound ist der Moiorcontroller ja nicht mehr als ein DA-Wamdler und die Kommunikation läuft über einen separaten SPI-Kanal. In Kamera und I2C ist der Motorcontroller gar nicht involviert. Die Signale laufen zwar teilweise über die Motorplatine, kommen aber nicht beim Motorcontroller an.

Auf lange Sicht fände ich eine Schicht oberhalb ftrobopy prima, die sämtliche FT-Spezifika wegabstrahiert und Hersteller-spezifische Dinge verbirgt. Dieser Layer würde dann auch Lego-WeDo, FT-RoboLT und I2C-Sensoren einbinden. Das würde die Programme leicht zwischen Modellen mit unterschiedlicher Hardware austauschbar machen und Programme, die für den TXT geschrieben sind würden auch auf einem R-Pi mit angeschlossenem RoboLT laufen. Aber selbst da würde ich Kameras und Sound rauslassen. Dafür gibt es ausgezeichnete APIs und Python-Bindungs. Das kann man nur schlechter machen

[Peterholland]

Hallo,

Ich habe heute ohne Problemen angefangen die Cube-Solver zu bauen.
Elektro anschusse fehlen jetzt noch + ich muss noch eine 4 GB SD-Karte kaufen.

Hat jemand die Cube-Solver auch schon nach gebaut und in Betrieb ?

Gruss,

Peter Poederoyen NL

[Hompi]

Hallo zusammen,
hallo Peter,

ich habe das Modell(Cube-Solver) komplett nachgebaut und die ersten Versuche vorgenommen. Dank der guten Beschreibung und Bilder war der Nachbau auch kein Problem. Vielen Dank nochmals für diese Informationen. Ich habe allerdings ein Problem. Der Einscannvorgang bricht nach 4-5 Würfelseiten ab. Es erscheint dann folgende Fehlermeldung:

No valid cube found

Beim Kalibrieren werden die Farben aber alle korrekt erkannt. Ich setzen auch einen Würfel mit weißen Hintergrund ein.
Hat jemand eine Idee wo der Fehler liegen könnte?

Gruss Jürgen

[MasterOfGizmo]

Er scannt immer alle 6 Seiten bevor er schaut, ob der Wuerfel gueltig ist. Du siehst die debug-Ausgaben? Da muesste auch stehen, was erkannt hat. Daraus kann ich ablesen, was deon problem ist.

Das Problem koennte sein, dass die Farben Deines Wuerfels wohl anders sind als die von meinem. Aber das kann man einstellen. Aber erstmal hilft mir deine komplette Ausgabe auf der Console.

[ski7777]

Da kommt mir noch eine allgemeine Idee. Für den DAU ist es knifflig die Debug ausgaben zu sehen. Wir könnten vielleicht die Ausgaben in einer Datei speichern und diese dann per Webinterface abrufen. Mein nächstes Stichwort wäre Telemetrie, aber dazu wann anders.

Raphael

[MasterOfGizmo]

Hat jemand eine Idee wo der Fehler liegen könnte?

Das Programm gibt (wie die meisten anderen auch) Debug-Informationen auf der Konsole aus. Das ist ganz knapp auch im Wiki beschrieben unter:

https://github.com/ftCommunity/ftcommun ... ps-via-ssh

Schritt für Schritt:

• Am TXT per SSH als user ftc einloggen (das ist hier beschrieben https://github.com/ftCommunity/ftcommun ... ord-policy)
• Dann export PYTHONPATH=/opt/ftc eingeben, damit die cube-App weiss wo sie ein paar Hilfsdateien findet
• Dann /opt/ftc/apps/user/be743ea4-187b-43d8-8f7b-1779fa589bec/cube.py eingeben. Das Cube-Prigramm startet dann auf dem TXT als hättest Du auf das Icon geklickt
• Via SSH sieht man nun auf dem PC die Debug-Ausgaben des Cube-Programmes

Da solltest Du ein paar Zusatzinfos bekommen, was passiert. Ggf. müssen wir für Deinen Würfel die Farbgrenzen etwas anpassen, damit der Solver weiss, welche Farbwerte er erkennen soll wenn die farbigen Aufkleber auf Deinen Cube eine andere Farbe haben aus auf meinem.