remotecontrol

lang ist's her ... Jetzt habe ich endlich das APK als ZIP in die Projektseite gehängt http://www.tinkerunity.org/wiki/index.php/DE/Projekte/RC_Fernsteuerung_%C3%BCber_Tablet#Software (mit den aktuellsten Bindings).

Hallo TF-Team, bei den neuen C++ Bindings bekomme ich eine neue Compiler-Warnung auf dem Raspi, die bei meinen Settings zum Compile-Abbruch führt (-O2 -Wall -Werror): ip_connection.c:49:3: error: ‘gcc_struct’ attribute directive ignored [-Werror=attributes] ip_connection.c:60:3: error: ‘gcc_struct’ attribute directive ignored [-Werror=attributes] Das stammt von diesem Code #elif defined __GNUC__ #define ATTRIBUTE_PACKED __attribute__((gcc_struct, packed)) Im Header dazu ist eine ähnliche Stelle, dort wird aber nur packed verwendet und nicht gcc_struct,packed. Die packed Option sollte überall gleichartig definiert sein - oder nicht? (Interessanterweise führt das bei OpenSuse mit der identischen Compiler-Version nicht zu einer Warnung) Und noch eine Stelle, die zu einer Warnung führt. Daher wäre folgende Änderung in ip_connection.c noch sinnvoll (hatte ich bisher von Hand geändert): 1275,1276c1275 < length = ((PacketHeader *)pending_data)->length; --- > PacketHeader *ptr = (PacketHeader *)pending_data; > length = ptr->length;

Nein, der PI wird ja nicht über den USB mit Strom versorgt, sondern über den Micro-USB. Der Stack holt sich den Strom über die Step-Down und in Summe wird alles über eine Stromquelle gespeist. Bei mir ist der Aufbau analog. Ich betreibe das mit einem 12V Netzteil. Die Strom-/Spannungabfrage der Step-Down zeigt an, dass das Netzteil 11,2V liefert und ca 310mA benötigt werden (Stack mit 2 Master, LCD, ein paar Bricklets + PI mit WLAN Stick). D. h. Du benötigst ein Netzteil mit mindestens 5 Watt (== 12V 400mA oder 9V 600mA).

Ich habe mir ein aufrollbares USB-Kabel besorgt, weil der Stecker sehr kurz war. In mein Gehäuse (kein Wetterstation-Gehäuse) hatte ich einige Platzprobleme mit den teilweise sehr langen steifen USB Steckern. Bzgl. Micro-USB mit dem der PI versorgt wird: - entweder ein USB-Kabel nehmen, abschneiden und die richtigen Adern raussuchen. Wikipedia hilft hier weiter. - ich habe mit bei Reichelt USB Stecker zum löten besorgt: auch hier wird der Stecker dadurch kürzer. Siehe http://such002.reichelt.de/index.html?ACTION=3;ARTICLE=124013;SEARCH=usb%20micro%20stecker Kann dann so aussehen:

Das ist sicher möglich. Den Code der Demo-Anwendung habe ich mir noch nicht angesehen, ich weiss gerade nicht, welche Sprache das ist.

Ich habe in meiner Anwendung ein "Grundwissen" über die maximale Anzahl erwarteter Bricklets hinterlegt (z.B. 6) und wenn nach 1 Sekunde 6 Bricks+Bricklets erkannt wurden gehe ich davon aus, dass der Enumerate beendet ist. Wenn nicht warte ich noch etwas. Das mache ich bis max 3 Sekunden lang. Wenn dann immernoch nicht alle Bricklets da sind, liegt in der Regel tatsächlich ein Fehler vor (Stack hat sich aufgehängt ...).

der Satz hat mich etwas abgeschreckt, weil dann doch sehr viele Erläuterungen notwendig werden könnten. Hast Du schon mit irgendwelchen Skript- oder Programmierspachen o.ä. erste Erfahrungen? Den PI hast Du schon im Betrieb? Vom Prinzip habe ich so eine Anwendung auf dem PI am laufen: - Auslesen von Temperatur (Temperatur-Bricklet), Druck und Luftfeuchtigkeit - Anzeige der Daten auf dem LCD mit aktuellen Werten, Durchschnitt etc. - Wechsel der Anzeige über Steuerung der ans LCD anschließbaren Buttons - Speichern dieser Daten 1x pro Minute in CSV-Datei - Zeitsteuerung eines Dual-Relais (Zeitschaltuhr) - Einstellung der Zeitschaltuhr auch über die Buttons des LCD Das Ganze ist in C++ für Linux geschrieben (OpenSuse 12.1 hat z.B. die identische Compiler-Version wie der PI, das macht die Entwicklung bei mir schneller, weil die Arbeit direkt auf dem PI eher zäh ist). Generell ist C++ aber nicht jedermanns Sache, d. h. Du müstest Dir auf jeden Fall überlegen, mit welcher Skript- oder Programmiersprache Du die Anwendung schreiben möchtest.

Die Bricks werden bei mir über die Step-Down Power-Supply mit Strom versorgt und der PI hängt auch der Step-Down (5V Ausgang). Den Stack habe ich dann direkt an einen der USB-Anschlüsse des PI angeschlossen. Das ist kein Problem, wenn die Bricks über die Step-Down versorgt werden. Generell habe ich den PI erstmal: - installiert und konfiguriert - zu der Zeit mit USB-Tastatur, Bildschirm am HDMI und LAN - dabei habe ich noch ein Handy-Ladegerät als Stromversorgung für den PI benutzt - dann SSH von externem Rechner via LAN konfiguriert - SD-Karte zum 1. mal gesichert - danach Micro-USB-Kabel hergestellt, welches zwischen Step-Down und PI hängt und den PI dann über die Step-Down mit Strom versorgt - Boot test (d. h. Stack mit PI unter Strom setzen, USB noch getrennt) - Stack ans USB des PI anschließen - Software testen ... - irgendwann habe ich das LAN dann durch einen WLAN-Stick im 2. USB Ausgang ersetzt und jetzt ist das Ganze recht "mobil" - SD-Karte nochmal gesichert mit WIFI Config

Dir rote LED leuchtet eigentlich immer, wenn Spannung anliegt (leuchtet bei mir auch nach dem shutdown). Wenn ein LAN Label angeschlossen ist, muessen mehr LEDs leuchten. Ohne LAN kann man Aktivität nur schwer erkennen, darum solltest Du mal mit Bildschirm und Tastatur booten. Hast Du eine Sicherung von der SD-Karte gemacht?

Ich suche schon länger nach einem passenden Gehäuse für das Dual-Relais (nicht zu groß, nicht zu klein), welches ich unter eine Arbeitsplatte anschrauben kann. Das Relais ist ca. 2m weit weg vom Brick und das möchte ich nicht "nackt" montieren. => ich finde dieses Gehäuse auf jeden Fall gut . Ich bin auch dafür, die Schrauben nur durch Öffnen des Gehäuses zugänglich zu machen und eine Zugentlastung zu haben. Bei der Wetterstation war ich schon zu schnell und habe nach langem Suchen und viel Bohren ein Gehäuse hergestellt. Wenn sowas raumkommt, baue ich vielleicht nochmal alles um ...

Du musst Dir ja einen Micro-USB Stecker gebastelt haben, der an den 5V Ausgang der Step-Down passt: sicher, dass dort die Spannung korrekt anliegt und kein Wackelkontakt drin ist? Oder ggf. ein Teil der feinen Adern im Kabel beschädigt ist? Ich habe auch einen PI an die Step-Down angeschlossen und das läuft problemlos. Ich nutze ein 12V Netzteil mit nur 7 Watt, brauche bei max. Last ca 5 Watt mit allem drum und dran.

- Zeigt das Projekt in der TreeView auch die CPP-Dateien an? (ich musste die manuell neu aufnehmen nach dem Umbenennen) - Die Projekt-Datei hast Du angepasst bzw. hat nur noch die CPPs? - Wie sieht die Compiler-Ausgabe aus, wenn Du erst alles bereinigst und dann neu bauen lässt. Ich habe nochmal einen Screenshot des Compilers angehängt: hier sieht man, dass erst alle Sourcen mit g++ übersetzt werden und ganz am Ende kommt der Link-Schritt.

Ich habe mir mal den QTCreator (auf Linux) installiert: - die TF-Sourcen liegen bei mir im Unterverzeichnis "bindings" - im .pro-File habe ich als Include-Verzeichnis "bindings" ergänzt - add-hoc habe ich auch nichts gefunden, um den Compiler für C-Sourcen von gcc auf g++ zu ändern. Editieren des generierten Makefiles hilft nicht. - Compiliere ich das so ohne Änderungen bekomme ich den gleichen Linkfehler wie Du, aber sehe auch, dass "gcc" verwendet wird, nicht g++ Ich habe jetzt alle Sourcen von .c nach .cpp umbenannt und das Projekt-File bereinigt, damit dort nur noch die cpp drin stehen => dann linkt es ohne Fehler. Hast Du die TF-Sourcen wirklich umbenannt? Anbei noch ein Screenshot, wie meine Projektdatei aussieht.

Ich hab' den QT Creator noch nicht benutzt, aber die erste wichtige Frage ist: werden die TF Sourcen überhaupt übersetzt? Wenn nein müssen die erstmal dem Projekt hinzugefügt werden. Wenn ja und es ist nirgends in den Einstellungen und den Makefiles was von 'gcc' zu finden würde ich die Sourcen mal auf die Endung .cpp umbenennen.

Na super: ich habe wohl 1 Monat rumgetan, ein Gehäuse zu finden, in dem ein Ras-PI, ein Stack mit 2 Mastern + Step-Down und das LCD Platz haben ... Dann noch die ganzen Löcher bohren (auch für Taster), um am Ende festzustellen, dass sich über das Gehäuse zu viel Wärme auf den Temperatursensor überträgt .. Hätte ich jetzt wohl einfacher haben können, wobei ich das Gehäuse in blau auch nicht schlecht finde. Falls Interesse besteht: ich habe C++ Code, um die Wetterstation mit Temperatursensor auf dem RasPI (oder anderem Linux mit g++) zu betreiben und auch noch eine Zeitschaltuhr per Dual-Relais zu steuern. Über die Tasten lässt sich das Ganze steuern, auch die Zeitschaltuhr.

Sorry - den Titel sollte man auch lesen ... Bei Mingw müsstest Du ja ein Makefile haben. Dann musst Du zum einen drauf achten, dass die TF Sourcen mit g++ übersetzt sind (nicht gcc) und beim Linken der Main müssen die TF-Objects mit in der Linkliste drin sein.

Das main.cpp ruft aber ipcon_connect schon auf - oder nicht? Das hier ist ein klassischer Linkfehler, der kann auf zwei Arten entstehen: 1) Du linkst die TF Objects nicht hinzu: was steht in Deinem Solution-File / Makefile an Linkoptionen? Sind TF Objects mit dabei? 2) die TF Sourcen sind im C-Mode compiliert, Deine main.cpp aber im C++ Mode, dann ist das Name-Mangling der Funktionen anders. 2) kann entstehen, da die TF-Sourcen die Endung ".c" haben. Je nach Compiler kann der dann in den C-Mode gehen und dann entsteht im Object-File eine Funktion _ipcon_connect (also ohne diese Argumentliste im Namen und '_' am Anfang). Die main.cpp wird aber als C++ compiliert und sucht nach einer ipcon_connect-Methode mit C++ Name Mangling. Prüfe mal die Compile-Ausgabe beim Übersetzen der TF-Sourcen: hier sollte /Tp verwendet werden, um dem Compiler die Source als C++ Source zu übergeben (siehe auch http://msdn.microsoft.com/de-de/library/vstudio/fwkeyyhe.aspx)

Also, als Fahrtregler habe ich diesen hier: http://www.conrad.de/ce/de/product/207369/, allerdings gab es den "damals" (vor ca. 4 Monaten) noch im 3er Pack günstiger. Jetzt ist es schon ein 5er Pack. Der ist schön klein und hat ausreichend Leistung. Ich betreibe den mit 9,6V Nennspannung, effektiv über 10V. Die Stecker habe ich einfach abgeschnitten und andere Verbindungen genutzt. Den Regler kann man einfach ans Servo-Brick anschließen. Generell ist aber dieser Hinweis zu beachten: http://www.tinkerforge.com/de/doc/Hardware/Bricks/Servo_Brick.html#brushless-motoren-mit-escs-verwenden. Bei mir hat das auch ohne Abklemmen der zwei Leitungen funktioniert (und es ist nichts kaputt gegangen), ich habe aber zur Sicherheit die zwei Leitungen des Servo-Signals nachträglich noch abgeklemmt (siehe Video-Link). Außerdem ist bei Fahrtreglern zu beachten, dass sich die meist nicht symmetrisch verhalten: die Beschleunigung beim Vorwärtsfahren ist meist größer als bei Rückwartsfahren. Der oben genannte BEC hat auch eine elektronische Bremse, leider nur in eine Richtung (wie die meisten Fahrtregler): wenn man bei Vorwartsfahren direkt auf "rückwärts" schaltet. Da ich das auch gerne in die andere Richtung haben wollte, habe ich hier softwareseitig nachgeholfen: wenn ich beim Rückwärtsfahren schlagartig bremsen will steuert meine Software einen ca. 10%igen Vorwärtsantrieb an, was zum Blockieren der Räder führt, ohne direkt loszufahren und damit eine recht effektive Bremsung macht. An den Fahrtreglern ist auch immer ein Ein/Aus-Schalter, den kann man an ein Quad-Relais mit Monoflop Funktion anschließen: Fällt die Kommunikation der Software zum Stack aus, schaltet der Monoflop nach X Millisekunden den Fahrtregler ab (Fahrzeug stoppt). Seeeeehr hilfreich bei Fahrzeugen, die über WLAN mit der Steuersoftware kommunizieren .

OK, vielen Dank. Jetzt muss ich dann mal meinen Code anpassen... Aber anderen wird es sicher helfen, da das Verhalten eingängiger ist.

Ich habe bei Conrad damals einen 'Dreierpack' Mini-Fahrtregler gekauft (ca 45 €, bis 20Amp pro Regler), die ich an ein Servobrick angeschlossen habe. War eigentlich recht einfach: Fahrtregler wie Servo anschließen und was beim Servo die Steuerbefehle für den Winkel sind, bewirken beim Fahrtregler vor/zurück. Ich kann das die Tage bei Bedarf mal zusammen stellen.

Ich habe nichts im Programm, was alle 18 Sekunden Daten überträgt, eher im Sekundentakt (Uhrzeit). Die blaue LED war auch immer so ca. 0,5 Sekunden aus, also relativ lange, sonst wäre mir das nicht aufgefallen. Nach dem Reset ist der Effekt auch weg: jetzt leuchtet sie wieder quasi dauerhaft und geht nur sehr kurz / kaum merklich aus. Das passt zur Datenübertragung. Irgendwie hatte sich die Relaiskommunikation verabschiedet.

... da ich eh gerade ein Update meiner TF-Anwendung eingespielt habe, musste ich nach Neustart der Anwendung feststellen, dass die Verbindung zum Dual-Relay futsch war ... Da hat nur noch ein Reset des Masters geholfen. Jetzt ist das Dual-Relay wieder ansprechbar und die Blaue LED leuchtet wieder dauerhaft. Mit dem Dauerbetrieb des Stacks (ist auch eine Art 'Wetterstation' mit Zeitschaltuhr) klappt es bei mir noch nicht so gut.

Hallo TF Team, mir ist gerade aufgefallen, dass die blaue LED am Master so ca. alle 18 Sekunden kurz ausgeht und dann wieder an. Ist das ein Feature, welches mit dem Watchdog gekommen ist (Firmware 2.0.6)? Oder ist mir das bisher nur nie aufgefallen? Viele Grüße

Für alle, die auf der Suche nach einem Endlos-Poti sind (da es noch kein entsprechendes Bricklet gibt): mit z.B. diesem Schalter http://www.conrad.de/ce/de/product/705538/DDM-Hopt-Schuler-Encoder-Dig-Potentiometer-5-VDC-Serie-427-427-021101AL001-Vertikale-Betaetigung-DIL-Max-5-W und einem Digital-In-4 Bricklet lässt sich mit relativ wenig Aufwand ein Endlos-Poti / Schalter umsetzen der folgende Zustände erkennen kann: links drehen schnell links drehen rechts drehen schnell rechts drehen Taste drücken Taste gedrückt und link/rechts drehen in Kombination Das angehängte Java-Beispiel geht davon aus, dass die Drehkontakte auf PIN 0+1 des Digital-In geschaltet sind und der Druckkontakt auf Pin 2. PIN 3 bleibt dann noch zur freien Verfügung übrig. Der oben genannte Schalter reagiert etwas träge, d.h. extrem schnelles Drehen erzeugt sogar weniger Events ... PotiTest.java

Aktuell ist mein Gefühl, dass ich hier mit statischen Entladungen zu kämpfen habe. Das System lief gestern + ganze Nacht völlig stabil, konnte auch alle Tasten bedienen ohne das was "Schlimmes" passiert wäre. Dann habe ich heute 1x die Metallbesfestigung des Stapels berüht (eigentlich um die Erwärmung zu prüfen) => reboot des Stacks! Noch habe ich keine Idee, wie das reduzieren/vermeiden kann.