Probleme mit Installation - install script / directory / etc.

[ch0lert1nu]

Hallo zusammen,

Ich bin neu bei Tinkerforge, habe mir ein paar Bricks und Bricklets zugelegt und bin nun daran, das ganze mit Python (weil bei den ersten Schritten empfohlen) zum Leben zu erwecken.

 

Mein erster Eindruck: Die Hardware sieht vielversprechend aus, die Anleitungen/Instruktionen setzen aber an vielen Stellen Vorwissen voraus, es sind keine Dummy-tauglichen Schritt-für-Schritt Anleitungen. Ein Nobody ohne tieferes Systemverständnis wird wohl so seine Mühe haben mit dem System.

(Was ich damit meine resp. wo mir Detail-Infos fehlen schreibe ich nachfolgend kursiv)

 

Die Umgebung:

->Windows7 Host, da funktionieren BrickDaemon/BrickViewer soweit, dass das PiezoSpeaker Bricklet am MasterBrick ertönte, ebenfalls konnten 2 Futabe Modellbauservos am ServoBrick angesteuert werden.

->LinuxMint17.1 (32Bit) in VMWarePlayer auf Host, BrickViewer und BrickDaemon konnten mit den .deb Files problemlos installiert werden (Doppelklick drauf ->ist so nirgends beschrieben...)

 

So, nun ging es weiter: netterweise ist Python in Version 2.7.6 bereits installiert.

Im Erste-Schritte Tutorial steht dann, dass die API-Bindings installiert werden müssen - aus dem Download-Bereich. (Soll nun der "Downloadbereich" oder "API-Bindings" Link gewählt werden?) Egal, auf "Umwegen" landet man in beiden Fällen bei der Datei tinkerforge_python_bindings_2_1_4.zip. (ich nehme jetzt einfach an, dass das richtig ist. Aber: nächstes Problem: wohin speichere ich die Datei jetzt sinnvollerweise?)

Ich habe die Datei mangels besserem Wissen einfach nach /home/myUser/tinkerforge/ gespeichert und hier entpackt.

 

Die Bindings müssen jetzt installiert werden, ja.

Also habe ich mal die angegebene Datei "readme.txt" gesucht/gefunden/geöffnet und versucht, die dort angegebene Datei "setup.py" auszuführen. (ah, befindet sich im Ordner ...bindings_2_1_4/source).

Ausführen klappt natürlich nicht, execute-Rechte fehlen. (ein Anfänger hat dann wohl Mühe, daraus auf "chmod 775 setup.py" zu schliessen).

./setup.py motzt dann wegen fehlenden Schreibrechten und auch noch wegen fehlenden Argumenten (da könnte man in der Anleitung ja gleich schreiben, dass "sudo setup.py install" ausgeführt werden muss)

 

Oh, jetzt fehlen noch die "setuptools". Bei "Python - API Bindings" steht zwar, dass die in source/ zu finden seien, aber wo? (dürfte ruhig etwas ausformuliert sein)

Such...such... Auf python.org finden sich Angaben zu den setuptools, eien Datei "ez_setup.py" soll ausgeführt werden im "target python environment" (ist setuptools jetzt bei den bindings enthalten oder muss die externe Datei geholt werden?)

Ich habe die Datei von python.org geholt, executable gemacht und mit sudo ausgeführt (muss man wissen wie...)

Da wurde dann irgendwas installiert. Soweit, so gut.

 

Anschliessend war es möglich, "sudo ./setup.py install" auszuführen, was offenbar dazu geführt hat, dass die Bindings installiert wurden. (aus welchem working dir soll die Installation erfolgen, damit die Dateien am richtigen Ort landen?)

 

Ich habe wohl nun ein ziemliches Chaos veranstaltet, jedenfalls kann ich keine Beispiele ausführen.

- Wechsel nach examples/bricklets/piezo_speaker

- Datei editiert, UID = "knJ"

- chmod 775 example_beep.py

- ./example_beep.py ausführen

 

Nun erhalte ich folgende Fehlermeldungen:

./example_beep.py: line 1: #!/usr/bin/env: No such file or directory

./example_beep.py: line 4: HOST: command not found

./example_beep.py: line 5: PORT: command not found

./example_beep.py: line 6: UID: command not found

from: can't read /var/mail/tinkerforge.ip_connection

from: can't read /var/mail/tinkerforge.bricklet_piezo_speaker

....

 

Hmmm.... wundert nicht wirklich, weil unter /var/mail/ schlicht gar nichts abgelegt ist.

Die Dateien scheinen sich in source/tinkerforge zu befinden, jedenfalls liegt dort eine Datei ip_connection.py

 

OK, wahrscheinlich habe ich das System ziemlich verkonfiguriert.

Egal - es ist eine vorkonfigurierte VM, die ist schnell wieder erstellt.

Was muss ich aber wo genau anders installieren, damit es beim zweiten Versuch klappt?

 

(Es wäre wohl eine gute Idee, die "Erste Schritte" Anleitung zu präzisieren, sonst kann ein "richtiger" Anfänger damit relativ wenig anfangen. Eventuell ist das ja gewollt, dass sich nur die technik-affinen Freaks mit Tinkerforge zurechtfinden und nicht auch die Arduino-style-Dummys. Ich bitte diesbezüglich um Aufklärung)

 

So, genug gelabert, eventuell hilft mir ja trotzdem jemand weiter...

Gruss!

[photron]

Du hast recht wir setzen etwas Basiswissen voraus, z.B. das du weißt wie man ein Debian Package installiert oder die gewählte Programmiersprach grundsätzlich verwendest.

 

 

Der Link im Tutorial zeigt jetzt direkt auf den API Bindings Abschnitt der Download Seite.

 

 

Die readme.txt in den ZIPs der API Bindings beinhaltete früher eine Installationsanleitung. Im Zuge der Überarbeitung der Anleitungen steht in den readme.txt jetzt ein Verweis auf die Dokumentation auf tinkerforge.com. Ich habe die readme.txt jetzt so erweitert, dass sich explizit auch auf die Installationsanleitung auf tinkerforge.com hinweist.

 

 

Dass das Tutorial auf die readme.txt für eine Installationsanleitung verweist war früher richtig. Das haben wir wohl vergessen im Zuge der Überarbeitung der Anleitungen zu ändern, sorry. Das habe ich jetzt nachgeholt, danke für den Hinweis.

 

sudo python setup.py install

 

ist hier als Kommando der Wahl zur Installation dokumentiert:

 

http://www.tinkerforge.com/de/doc/Software/API_Bindings_Python.html#vom-quelltext

 

 

setuptools wird von setup.py verwendet und ist nicht teil des ZIPs. Ich habe die Anleitung umformuliert, um dass besser herauszustellen.

 

 

Für die Installation ist das Working Direktory belanglos, die Setuptools sorgen dafür, dass es an der richtigen Stelle landet.

 

 

Bezüglich

 

./example_beep.py: line 1: #!/usr/bin/env: No such file or directory

 

Da ist was wirklich Faul mit deinem Linux. env ist teil der coreutils zu denen auch Dinge wie cp und mv gehören. Die sind eigentlich immer installiert. Alle anderen Fehler danach sind Folgefehler und verschwinden sobald der erste Fehler behoben ist.

 

Versuch mal "python example_beep.py" statt "./example_beep.py" auszuführen.

 

 

Wir wollen keinen mit der Art und Weise der Dokumentation ausgrenzen. Aber irgendwo müssen wir den Schnitt setzen zwischen dem was wir erklären und dem was wir voraussetzen. In diesem Fall setzen wir voraus, dass du grundsätzlich mit dem verwendeten Betriebssystem und der verwendeten Programmiersprache vertraut bist.

 

 

Falls du noch weitere Verbesserungsvorschläge hast bitte immer her damit und danke dass du dir die Zeit genommen hast das hier so ausführlich aufzuschreiben.

[ch0lert1nu]

Danke für die Antwort, photron.

Ich gehe das ganze jetzt nochmals mit einer "frischen" VM an, mal sehen...

Die Befunde werden wohl laufend eintrudeln.

 

http://www.tinkerforge.com/de/doc/Tutorials/Tutorial_Extending/Tutorial.html#tutorial-first-steps

->Typo: Schließe als erstes einen Motor und eine Stromversorgung

 

Habe jetzt die Bindings mit

sudo pip install tinkerforge

installiert, klappt soweit.

 

Sehe ich das richtig, dass beim Installieren mit pip die source/ und example/ Ordner nicht mitkommen? Oder wo werden die abgelegt.

Falls man die Beispiele bei pip noch händisch holen muss, sollte evtl. ein Hinweis dazu in die Dok.

 

Ok. Das Beispiel example_config.py läuft...

Bemerkung dazu: Ich täte da am Ende nach dem Drücken der Taste den Motor auch wieder abstellen, sonst fragt sich der "Erste-Schritte-Durcharbeiter", wie er den Motor jetzt wieder stehend bekommt.

z.B. so:

    ...
    dc.set_velocity(32767) # Full speed forward

    raw_input('Press key to exit\n') # Use input() in Python 3
    dc.set_velocity(0) # motor stop
    dc.disable()
    ipcon.disconnect()

 

So, jetzt probieren wirs noch ohne installierte Bindings aus, zuerst einmal ein

sudo pip uninstall tinkerforge

-->ok. Beispielprogramm geht nicht mehr, Fehlermeldung: ImportError tinkerforge.ip_connection

 

tinkerforge/ Ordner aus source/ ins Arbeitsverzeichnis kopiert: geht.

Sodele, das wars dann mal für heute - bis jetzt ein erfolgreicher Abend...

Gruss!

[photron]

http://www.tinkerforge.com/de/doc/Tutorials/Tutorial_Extending/Tutorial.html#tutorial-first-steps

->Typo: Schließe als erstes einen Motor und eine Stromversorgung

 

Ist korrigiert.

 

Sehe ich das richtig, dass beim Installieren mit pip die source/ und example/ Ordner nicht mitkommen? Oder wo werden die abgelegt.

Falls man die Beispiele bei pip noch händisch holen muss, sollte evtl. ein Hinweis dazu in die Dok.

 

Der source/ Ordner wird installiert, aber der example/ Ordner ist nicht dabei wenn du die Bindings über pip installierst. Hab eine Hinweis zur Dokumentation hinzugefügt.

 

Ok. Das Beispiel example_config.py läuft...

Bemerkung dazu: Ich täte da am Ende nach dem Drücken der Taste den Motor auch wieder abstellen, sonst fragt sich der "Erste-Schritte-Durcharbeiter", wie er den Motor jetzt wieder stehend bekommt.

 

Stimmt, das fehlt im ersten Beispiel, im zweiten ist es drin. Hab's jetzt auch im ersten eingefügt.

[ch0lert1nu]

Ok, klar soweit.

Python, C und Java funktionieren jetzt.

Es sind ja nicht wirklich C++ Libs, sehe ich das richtig?

Da ist nix von Brick-Objekten in objektorientierten Sinne...

 

Jetzt gehts an den RedBrick, mal sehen...

Gruss!

[ch0lert1nu]

Der RedBrick macht Ärger - oder macht zumindest nicht das was erwartet.

Ich habe mir eine 8GB SanDisk Ultra microSDHC besorgt und im Linux Mint wie in der Anleitung beschrieben das RedBrick Image 1.3 aufgespielt.

Das dauerte in der Konsole eine gefühlte Ewigkeit, aber schlussendlich kam der Befehl zu einem Ende und es waren Daten auf der microSD Karte aufgespielt.

Die microSD Karte meldete sich fortan im Linux Mint als "RED-Brick-Linux".

 

Ich habe diese microSD Karte dann im RedBrick installiert und diesen per USB an den PC angeschlossen.

Resultat:

- blaue LED leuchtet

- rote LED blinkt kurz auf und erlöscht dann gleich wieder

- kein Lebenszeichen einer grünen LED

- RESET Button während 5s: blaue LED schaltet ab

- wieder RESET Button: blaue LED schaltet wieder ein

 

Im BrickViewer:

- kein Lebenszeichen des RedBrick

 

Das ganze dann an den HDMI Fernseher angeschlossen, bestromt über USB:

- kein Lebenszeichen am HDMI

- gleiches Verhalten der LEDs wie am PC

 

Im Anhang befindet sich ein Bild der Daten auf der microSD Karte, so wie sich diese im Linux Mint präsentiert.

-> Kann da jemand etwas nicht passendes erkennen?

-> irgendwie scheinen die Startdateien zu fehlen.

-> Welche Dateien müssten sich im root Verzeichnis der microSD Karte befinden?

 

Danke für Antworten.

Gruss!

[ch0lert1nu]

Sodele,

ich habs jetzt auch noch unter Windows mit dem Win32DiskImager versucht.

Resultat: die grüne LED blinkt jetzt fröhlich vor sich hin mit einer Art Doppelblink-Intervall.

Im BrickViewer sehe ich aber immer noch keinen RedBrick...

 

[ch0lert1nu]

Da bin ich wieder - nach "Gschwelti mit Chäs"...

Der RedBrick zeigt sich jetzt auch im BrickViewer. Anscheinend brauchte das System den einen oder anderen zusätzlichen Reboot...

 

Jetzt tun sich aber bereits weitere Abgründe auf:

Ein RedBrick mit aufgestecktem DC Brick tut nicht

- RedBrick erscheint im BrickViewer

- DC Brick Tab fehlt

 

Stapel umgestellt auf

[DC Brick    ] -> Akku extern -> DC Motor
[Master Brick] -> Hall Sensor Bricklet -> Piezo Speaker Bricklet
[RED Brick   ] => USB to Host

 

- DC Brick erscheint nicht im BrickViewer

- auf Piezo Bricklet kann ein kurzer Ton ausgegeben werden, dann stürzt irgendwas ab, so dass Master Brick und Bricklets aus dem BrickViewer verschwinden

- erst nach Restart des BrickDaemon erscheinen Master und Bricklets wieder

- DC Brick bleibt verschollen

 

Mache ich etwas unerlaubtes?

Sollte nicht der DC Brick auch direkt am RedBrick betrieben werden können? Braucht es dazu immer den Master Brick?

 

Danke für die Antworten.

Gruss!

[photron]

Warum das Image bei dir nicht direkt funktioniert hat kann ich nicht sagen. Normalerweise ist der Ablauf: Image auf SD Karte schreiben, SD Karte in RED Brick stecken, RED Brick mit Strom versorgen, RED Brick bootet. Es kann sein, dass der erste Bootvorgang etwas länger dauert, weil das System dann noch Verschiedenes initialisieren muss, aber es sollte booten.

 

Bezüglich DC Brick, der funktioniert direkt auf dem RED Brick, aber dazu muss er auf der aktuellen Firmware Versino sein: 2.3.0. Wenn auf dem DC Brick eine ältere Firmware ist, kann dass dein Problem erklären. Dies gilt für alle Bricks.

[ch0lert1nu]

Der DC Brick hat tatsächlich die falsche Firmware (2.0.1) - gehabt... jetzt scheint er keine mehr zu haben.

 

Ich habe gemäss Anleitung folgendes gemacht

- Erase Button gedrückt halten

- USB Power einstöpseln

- Reset Button dazu kurz drücken

- Brick Viewer starten

- Auswahl: Updated/Flashing > Brick Tab:

-> Serial Port: /dev/ttyACM0

-> Firmware: DC (2.3.0)

- Klick auf "Save"

--> Resultat: Fehlermeldung.

Could not connect to Brick: No permission to open serial port

 

Scheint ein Login-Problem des Bootloaders oder Rechte-Problem auf dem Host zu sein, aber was genau geht schief?

Was muss ich anders machen um den DC Brick zu flashen?

In der Anleitung habe ich nichts von Login credentials gefunden.

 

Danke für die Antworten.

Gruss!

[ch0lert1nu]

Die Kinder sind im Bett, das Basteln kann weitergehen...

 

Das Zugriffsproblem war (wie wohl von den Spezialisten sofort erkannt) das fehlende "sudo" beim Aufruf des BrickViewers.

-->In der Anleitung fehlt die Angabe, dass der BrickViewer für das Flashen als sudo gestartet werden muss.

Wenn ich den normalen "KlickiBunti-Weg" gehe und den BrickViewer aus dem Menu starte, dann geschieht das nicht per sudo und das Flashen funktioniert nicht. Hinweis: aus Konsole starten mit "sudo brickv"

 

Zweiter Befund: Der Ablauf, um einen Brick in den Bootloader-Modus zu versetzen ist etwas schwer verständlich geschrieben.

Gemäss Beschrieb muss der Erase-Button gedrückt gehalten werden und dann mit gedrücktem Button der USB Anschluss eingesteckt werden, damit Power am Brick ankommt und dieser startet. Und dann soll auch noch Reset gedrückt werden... eine Hand zu wenig?

Nein, kein Problem ->einfacher: USB Power anschliessen, Brick starten lassen, Erase Button drücken und während gedrücktem Erase noch Reset kurz drücken, fertig.

Oder ist das ein "unsauberer" Weg?

 

Übrigens: der Stapel gemäss obiger Beschreibung tut jetzt was er soll.

 

Nächster Schritt: eigenes Programm auf dem RED laufen lassen...

[Loetkolben]

Das Zugriffsproblem war (wie wohl von den Spezialisten sofort erkannt) das fehlende "sudo" beim Aufruf des BrickViewers.

-->In der Anleitung fehlt die Angabe, dass der BrickViewer für das Flashen als sudo gestartet werden muss.

 

Vielleicht muss aber auch nur die Berechtigungen fuer das /dev/flash_device angepasst werden oder eine /etc/group richtig gesetzt werden?

 

Gemäss Beschrieb muss der Erase-Button gedrückt gehalten werden und dann mit gedrücktem Button der USB Anschluss eingesteckt werden, damit Power am Brick ankommt und dieser startet.

[Danach bitte den Erase Button loslassen] Und dann soll auch noch Reset gedrückt werden... eine Hand zu wenig?

 

Nein, kein Problem ->einfacher: USB Power anschliessen, Brick starten lassen, Erase Button drücken und während gedrücktem Erase noch Reset kurz drücken, fertig.

Oder ist das ein "unsauberer" Weg?

 

Ne, macht im Prinzip das gleiche.

 

 

Der Loetkolben

[photron]

Das Zugriffsproblem war (wie wohl von den Spezialisten sofort erkannt) das fehlende "sudo" beim Aufruf des BrickViewers.

-->In der Anleitung fehlt die Angabe, dass der BrickViewer für das Flashen als sudo gestartet werden muss.

Wenn ich den normalen "KlickiBunti-Weg" gehe und den BrickViewer aus dem Menu starte, dann geschieht das nicht per sudo und das Flashen funktioniert nicht. Hinweis: aus Konsole starten mit "sudo brickv"

 

Welche Linux Distribution verwendest du?

 

Serielle Schnittstellen sind normalerweise der Gruppe dialout zugeordnet und normalerweise ist der Standardnutzer auch in dieser Gruppe. In diesem Fall funktioniert alles wie beschrieben. Wenn der Nutzer nicht in der dialout Gruppe ist kann man das Problem mit sudo umgehen. Alternative kann der Nutzer auch der dialout Gruppe hinzugefügt werden.

 

Ich habe die Fehlermeldung in brickv jetzt um den Hinweis erweitert brickv als root zu starten und den entsprechenden Hinweis auch in die Dokumentation aufgenommen.

 

Zweiter Befund: Der Ablauf, um einen Brick in den Bootloader-Modus zu versetzen ist etwas schwer verständlich geschrieben.

Gemäss Beschrieb muss der Erase-Button gedrückt gehalten werden und dann mit gedrücktem Button der USB Anschluss eingesteckt werden, damit Power am Brick ankommt und dieser startet. Und dann soll auch noch Reset gedrückt werden... eine Hand zu wenig?

Nein, kein Problem ->einfacher: USB Power anschliessen, Brick starten lassen, Erase Button drücken und während gedrücktem Erase noch Reset kurz drücken, fertig.

Oder ist das ein "unsauberer" Weg?

 

Wo hast du gelesen, dass du den USB Stecker einstecken sollst während du Erase gedrückt hältst?

 

Was eigentlich passieren muss ist, dass Erase gedrückt ist wenn der Brick startet. Das kannst du auf zwei Wegen erreichen:

 

- Entweder wie dokumentiert: Brick an USB anschließen, Erase gedrückt halten und dabei Reset drücken. Das Ziel ist, dass beim Loslassen von Reset der Erase Knopf gedrückt ist.

 

- Die andere (undokumentierte) Weise: Erase gedrückt halten und dabei USB anstecken. Der Brick startet dann beim Anstecken von USB, kein Reset Knopf nötig.

 

Beides führt zum Ziel. Wir haben aber absichtlich nur eine Weise dokumentiert, um Verwirrung zu vermeiden. Hat scheinbar nicht geklappt

 

Ich habe die Beschreibung in der Dokumentation jetzt hoffentlich verständlicher umformuliert.