remotecontrol

OK, das erklärt ein paar Punkte: * bei dieser Startart ist stdin geschlossen, d. h. der getchar() beendet sich sehr schnell. Zu der Zeit sind einige IPConnection-Threads noch in der "Startphase" aktiv und das ganze kommt durcheinander weil direkt im Start alles wieder beendet wird und der Stack mit dem IPConnection-Objekt weg ist. => der sleep(10) löst das * ein fopen liefert NULL, wenn die Log-Datei nicht geöffnet werden kann, der fprintf bringt das Programm dann zu Absturz. Der User hatte auf das Arbeitsverzeichnis keine Schreibrechte, mit dem ganzen Pfad geht es dann. * Hast Du einen Temperature-IR Sensor angeschlossen oder nur einen einfachen Temperatur-Sensor? Wenn Du einen Temperature-IR Sensor dran hast, sieht alles gut aus. Dann kommt die Last eher vom HTOP plus die Aktivität auf der Console.

.. ist mir noch nicht passiert. Vielleicht hilft es, die orange-farbenen Nasen reinzudrücken (das löst ja den Druck aufs Kabel) und dann leicht schütteln. Kann aber gut sein, dass das nicht reicht. Wenn Du auch nicht mit einer Mini-Zange oder einem anderen kleinen Gegenstand in die Öffnung kommst, um etwas am Restdraht zu ziehen (immer bei gedrückter Nase!), dann habe ich leider auch keine Idee, was noch helfen könnte.

Ein sleep(10) wartet ja jeweils 10 Sekunden. Um mit der Tinkerforge-API (auch auf einer schwachen CPU wie dem Raspi) eine Auslastung von 10% zu erreichen, muss Du schon relativ viel machen. Das hört sich noch danach an, dass da etwas nicht stimmt. Wenn Du unter Linux einen Dienst über ein init-Skript startest, dann ist (ohne besondere Massnahmen) das Arbeitsverzeichnis das root-Verzeichnis ("/"). Dort hat der root-User Schreibrechte. Init-Dienste haben auch kein stdin, d. h. der getchar() müsste sofort EOF liefern. Du solltest vielleicht man die ganzen Sourcen posten, dann ist Hilfestellung leichter.

Ich habe das Display über einen Ambilight-Sensor gesteuert. Bei weniger als 8 Lux, geht das Display aus. Das reicht, um auch bei Energiesparlampen zu reagieren. Das Ganze habe ich dann noch mit einer gewissen Trägheit (erst nach 2 Sek. einschalten und 10 Sekunden nach "Dunkelheit" wieder ausschalten) versehen. Das bedeutet aber auch: tagsüber ist das Display im wesentlichen an, weil Tageslicht weit über 8 Lux sind. Den Ambilightsensor habe ich oben im Wetterstation-Gehäuse und das Gehäuse steht auf dem Schreibtisch. Für meine Aufbau klappt das sehr zuverlässig.

Übersetz die Tinkerforge Sourcen mal selber mit dem Java-Compiler. Dann müsste es gehen. Das tinkerforge.jar scheint mit Java 7 übersetzt zu sein, Du hast aber ein älteres Java 6 (noch verbreitet, aber schon aus der Wartung...). Der NoClassDefFoundError kommt, wenn das tinkerforge.jar nicht im classpath ist.

Hast Du sehr "stromarme" Relais gefunden oder hast Du einfach noch einen Transistor davor geschaltet?

Das Servobrick versorgt über die 3-poligen Steuerleitungen angeschlossene Servos mit Strom. Das dürfen in Summe über alle Servos max. 3A sein. Wenn Du 7 Servos gleichzeitig anschließen würdest und sich alle bewegen und je 500mA ziehen kann das knapp werden. Ein Fahrtregler hat aber (immer) einen eigenen direkten Anschluß zur Spannungsquelle. Daher spielen die 3A des Servobricks hier fast keine Rolle. Du brauchst einen Fahrtregler, der z. B. 15A Dauerstrom leisten kann, wenn der Motor 10A zieht. Aber beim Anschluss des Fahrtreglers musst Du etwas aufpassen bzgl. der Steuerleitung: hier ist bei der Dokumentation des Servobricks ein gesondeter Abschnitt dazu. 1 oder gar 2 Pole der Steuerleitung sollten abgeklemmt werden, um zu verhindern, dass der Motor direkt Strom über die Steuerleitung zieht.

Es gibt schon einie Unterschiede zwischen den Bricklets: IO-16: max 3,3 oder 5V am Ausgang, max 20mA (und es kann auch als Eingang verwendet werden) Industrial Digital Out: kann bis zu 36V Ausgangsspannung aber auch "nur" 25mA Quad-Relais: schaltet den Eingang auf den Ausgang (galvanisch getrennt), max 30V, max 1,2A (Strom wesentlich höher als bei den anderen). Mit dem Quad-Relais könnte man wiederum z.B. 12V Spulen-Relais schalten, die dann die 220V Leitung schalten. Ginge wohl auch mit dem IO-16, wenn man noch einen Transistor dazwischen packt. Mit 20mA direkt ein Spulen-Relais zu schalten wird schwer. Das IO-16 eigent sich auch gut, um Tasteneingänge bereit zu stellen, eben weil es viele Anschlüsse hat.

Die Entstörkondensatoren sind schon dran. Die Schottky-Diode scheidet aus wegen der Polumkehr. Bleibt noch der Einbau von Drosseln übrig. Ein Fahrtregler zeigt sich völlig unbeeindruckt von dem Motor. Nur das DC Brick mag das nicht, d. h. ich brauche eine Entsörung, die speziell dieses Phänomen löst. Was ich wohl mal versuchen werde: 2 Zener-Dioden (z.B. 16V) in Reihe aber gegenläufig zwischen die Pole. D. h. die Sperrspannung in Summe ist dann etwas höher als die Zenerspannung. Ob das schnell genug reagiert, um weniger Spannungsspitzen auf das DC Brick zu übertragen, ist die Frage.

Nach diversen Test bin ich jetzt der festen Überzeugung: der Bürstenmotor bringt den Stack zum Absturz, wenn die Bürstenfunken zu stark werden. Das ganze überträgt sich über die Motoranschlüsse zurück zum DC Brick und stört dann alles. Nehme ich ein schwächeres Akku (9,6 statt 12) ist alles OK. Nehme ich einen Motor mit 16V Nennspannung und 12V Akku ist auch alles OK. Der Abstand des Motors zum Brick spielt keine Rolle. Die Frage ist nun: kann ich den Stack noch durch irgendeine Schutzschaltung vor sowas schützen? Die Entstörkondensatoren allein reichen nicht aus. Habt Ihr eine Idee?

Die WLAN Extension ist kein eigener Reiter im Brickv, sondern wird beim Master mit angezeigt: dort erscheint sie bei Dir nicht? Bzgl. Barometer: Was ist deutlich zu niedrig bei Dir? In welcher Höhe über normal Null wohnst Du?

"Funkioniert nicht" bedeutet: Firmware läuft, aber LED ist noch an? Es gibt noch eine "led_tick_task", die die blaue LED auch einschalten kann. Man kann ja auch vereinzelt beobachten, dass die blaue LED kurzzeitig im Betrieb aus-/eingeschaltet wird bei bestimmter Datenübertragung. Vielleicht passiert das schon recht früh nach dem init und damit geht die LED wieder ein.

Ein eigenes Programm wäre auch OK, es sollte nur möglichst einfach in der Anwendung sein. In den Bindings hat es den Vorteil, dass es zur Laufzeit über den Client ein-/ausgeschaltet werden kann und relativ einfach umzusetzen ist. Aber damit verbunden auch den Nachteil: der Client muss die Befehle kennen und aufrufen und da die IPConnection handgeschrieben ist relativiert sich das mit "einfach" über alle Bindings wohl. Ein Replay der aufgezeichneten Commands, die ich über eine 2. Socket-Connection zum Stack sende funkitoniert im ersten Test wie erwünscht: das Relais bekommt z. B. Monoflop Befehle und über die erste Verbindung der IPConnection kommt der Callback wenn der Monoflop beendet ist. Die Servos bewegen sich zeitgesteuert wie von Geisterhand ... Jetzt muss ich "nur" noch Aktions-Commands von Zustands-Commands (z. B. callback setzen) auseinander halten können.

Hallo TF-Team, ich habe in die IPConnection am Anhang eine einfache Art des Recordings der zum Stack gesendeten Daten eingefügt. Ich nutze dass, um Command-Sequenzen mit Zeitstempel zu extrahieren, die ich "manuell" angesteuert habe. Auch für Analysezwecke könnte das recht hilfreich sein, wenn ein record+replay verfügbar wäre. Der Trace hat folgendes Format (nur auf Linux übersetzt): SEC.USEC LEN UID FUNC OPT PAYLOAD DATA 1376724754.011230 0C 00009C4C 08 68 - F4 01 00 00 1376724754.011323 10 00009442 03 70 - 01 00 01 00 D0 07 00 00 1376724754.017937 0C 00009C4C 0A 88 - F4 01 00 00 1376724754.023898 09 DC332931 01 90 - 00 1376724754.023926 0B DC332931 07 A0 - 00 FF FF 1376724754.023946 0B DC332931 0A C0 - 00 FF FF 1376724754.023975 0D DC332931 10 D0 - 00 6C EE 94 11 Vielleicht übernehmt Ihr sowas in der Art in die API. ip_connection.h ip_connection.c

In beiden Fällen über dieselbe Spannungsversorgung, wobei ich die Eingangsspannung immer an die Step-Down und auch an den Eingang des RC/Servo-Bricks lege, damit nicht zwingend alles über die internen Leitungen des Stacks geht. Das scheint aber keinen Effekt zu haben, da eine externe Spannung am DC/Servo-Brick wohl etwas höher sein muss als die Stack-Spannung damit das als solche erkannt wird - oder?

Ich hab's mal andersrum gemacht: nicht 'nen stärkeren Akku, sondern einen Schwächeren genommen (weniger Spannung). => der Effekt tritt deutlich seltener auf bzw. wird extrem schwer zu reproduzieren. Das verstärkt den Verdacht, dass der Motor den Stack stört. Wenn ich den Motor an einen Fahrtregler anschließe und per Servobrick steuere klappts (Motor ist in etwa in gleicher Entfernung). Das würde bedeuten, dass über die Motor-Stromzufuhr Spannungsspitzen zurück auf den Stack übertragen werden, die diesen dann zum Absturz bringen. Wie kann ich das verhindern? Die Entstörkondensatoren scheinen nicht ausreichend zu sein.

Ich kann den Hänger recht schnell reproduzieren, wenn ich mit Acceleration 0 das Poti auf Maximum drehe und damit max Velocity am DC Brick setze. Danach läuft der Motor weiter und nimmt keine Commands mehr an. Meist muss ich den Stack dann resetten, nur ab und zu fängt sich das System. Manchmal beendet sich das Programm nach ENTER drücken noch, der Motor läuft dann aber dennoch weiter! D. h. der dc_disable wird gesendet, aber ohne Wirkung. Bei einem Neustart der Anwendung hängt der Connect dann (Anwendung kann sich nicht mehr verbinden - hängt, hilft nur noch reset). Komplett ohne Last konnte ich das nicht reproduzieren . Allerdings kommen dann von Haus aus nur max 5-6 Callback (5 vom Poti + evtl. 1 vom Power-Sensor). Nur mit Last erzeugt der Power-Sensor ja geänderte Werte. Ich habe zwei gdb-Traces hier angehängt, sonst wäre der Post zu groß gewesen: beim ersten läuft der Motor schon unkontrolliert und lässt sich nicht mehr steuern. ENTER wurde noch nicht gedrückt. Bei diesem Testfall hat sich das Programm nach ENTER noch normal beendet, aber den Motor lief dennoch weiter. Der zweite hat einen Zustand, nach ENTER wo das Programm eigentlich schon enden will, aber in der Netzkommunikation zum Stack hängt. Ich scheitere gerade an einer 12V Glühbirne die ich nicht habe, um eine andere Last-Art zu testen. gdb_traces.txt

Die Netzkommunikation kann ich mir mal ansehen und auch mal ohne Motor testen. Am Akku liegt es nicht: ich hatte erst einen 9,6V Akku 1,8Ah und dann auch noch einen 3-Zellen LiPo Akku (voll geladen 2,5Ah). Der Motor zieht nur 80-200mA und der Effekt tritt mit beiden Akkus auf. Nochmal zu 3): ja - wenn der Effekt auftritt hängt das Programm nach drücken von Enter im dc_disable() und lässt sich nur noch durch ein SIGKILL beenden. Ein response-expected ist nicht explizit gesetzt, alles ist quasi "Default", auch die Timeout-Werte. Ich werde mal der Reihenfolge nach - einen Stacktrace (Snapshot) liefern im Normalbetrieb - einen Stacktrace liefern, wenn's klemmt - ohne Motor testen - die Netzkommunikation mitschneiden

Ja, über das Poti steuere ich testhalber die Geschwindigkeit des Motors. Zu den Fragen: 1a) Ja: ich kann am Poti drehen und nichts passiert. Außerdem kommen normalweise immer wieder Änderungen per Callback vom Power-Sensor, da mit geänderter Drehzahl sich ja auch die Stromstärke ändert und der Akku immer ein paar Millivolt verliert. Es kommen normalerweise mindestens 2 Callbacks pro Sekunde (Ausgabe in Console). Diese Callbacks bleiben aus. Im guten Fall kommt nach X Sekunden (z. B. 15) ein ganzer Schwung an Messwerten und Poti-Werten und das System fängt sich wieder. Im Worst Case muss ich den Stack neu booten, da auch ein erneuter Connect sonst nicht mehr funktioniert. 1b) ich habe ihn noch nie länger laufen lassen, kann ich mal versuchen. 2a) der Motor ist recht klein und hat kleine Entsörtkondensatoren an den Anschlüssen und zum Gehäuse. Er liegt ca. 20cm vom Stack entfernt. Wie kann ich erkennen, ob der den Stack ggf. stört? Es ist aber schon auffällig, dass gerade bei Aufdrehen auf max. Geschwindigkeit der "Hänger" eher auftritt. 3) ja: wenn sich der Stack nicht fängt zeigen ausgehende Befehle keine Reaktion mehr. Drücke ich zu einer Zeit ENTER, wo der Stack normal reagiert, dann stoppt der Motor wie gewollt. 4) korrekt, hat nichts mit den Bindings zu tun.

Das mit dem segfault bekomme ich nicht mehr reproduziert. Vermutlich habe ich beim Extrahieren der Testsource aus der Komplettanwendung einen Fehler gemacht. Ich glaub am Anfang hatte ich in der Testsource eine Init-Sequenz der Art ...create ...register_callback ...create ...register_callback Und dabei ist es möglich, dass direkt nach dem ersten register_callback dieser schon aufgerufen wird uns auf das unitialisierte zweite Device zugreift. Die normale Anwendung initialisiert anders und dort ist das nie aufgetreten. Die Probleme mit dem DC Brick bestehen noch, auch mit dem letzten Update der Power-Sensor Firmware.

Hallo TF-Team, ich habe hier noch zwei DC-Bricks und hadere etwas mit dem Einsatz: der Vorteil ist die feine Steuerung, gleiche Beschleunigung vor/zurück, Bremsfunktion, ... Aber: bricht mir die WLAN Verbindung zusammen, läuft der angeschlossene Motor einfach weiter. Ist es möglich hier auch einen Timer (Monoflop) ähnlich wie beim Quad-Relais einzubauen: wenn X Sekunden kein Request mehr kommt, wird die Velocity automatisch auf 0 gesetzt. Das Verhalten müsste per API explizit aktiviert werden. Aktuell geht sowas nur mit Servobrick + Quad-Relais: das Quad-Relais steuert per Monoflop den "Not-Aus" des Fahrtreglers. Sowas im DC-Brick wäre super, dann ist der DC-Brick einem Fahrtregler von den Möglichkeiten her deutlich überlegen und sicher zu steuern.

Alles was mit Entwicklung zu tun hat, mache ich unter Linux (PC:Opensuse - historisch bedingt, Raspi:Debian, Cubiboard2:Fedora, für Android auch unter Suse). Damit läuft der brickv eigentlich nur auf dem Raspi - und der ist zu schwach dafür. Auf Suse und Fedora bereitet es einiges an Aufwand, die passenden Phython libs zu installieren. Brickd lässt sich noch recht leicht übersetzen.

"Verbindung bricht ab" bedeutet: auch per brickv lässt sich der Stack gar nicht mehr ansprechen - richtig? Oder reagiert "nur" das Relais nicht mehr? Falls Du das nicht eh schon ausprobiert hast: ohne Last betreiben: klappt alles normal ? das Relais und die 220V Leitung testhalber mit längerem Kabel etwas entfernt vom Stack betreiben - ist aktuell schon sehr dicht zusammen. Meine Erfahrung ist, dass ein Stack recht empfindlich auf statische Aufladungen und andere externe Störungen reagiert den Betrieb per USB testen, ob sich der Stack dann auch aufhängt

Ich habe in ip_connection.c zwei printf-Aufrufe eingebaut an Stellen, wo ein unbekanntes Paket kommt bzw. queue_get auf Fehler läuft - die werden aber nicht aufgerufen - darum 2 Zeilen mehr. Per USB scheint es zu funktionieren, d. h. sieht eher nach einem WLAN Problem aus. Die Responses kommen vereinzelt auch stark verzögert wie damals beim Servobrick (erst X Sekunden nichts und dann viele Poti-Callbacks auf einmal, dann reagiert der DC-Brick meist aber auch nicht mehr). Das mit dem segfault prüfe ich nochmal.

Anbei ein Testprogramm mit dem ich das Verhalten reproduzieren kann, wenn ich das Poti hin und her drehe. Manchmal fängt sich der Stack, wenn ich das Programm mit kill -9 beende und neu starte. Vereinzelt hängt sich aber der ganze Stack auf und der Motor läuft einfach weiter ... Nach <ENTER> auf der Console müsste sich das Programm eigentlich beenden, es verharrt aber hier: #0 0x00007f5c279ce8d4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007f5c279ca1c5 in _L_lock_883 () from /lib64/libpthread.so.0 #2 0x00007f5c279ca01a in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x000000000040448d in ipcon_send_request (ipcon=0x7fffa1d9e5d0, request=0x7fffa1d9e5b0) at ip_connection.c:1525 #4 0x00000000004050d6 in device_send_request (device=0x608160, request=0x7fffa1d9e5b0, response=0x0) at ip_connection.c:924 #5 0x0000000000401c42 in dc_disable (dc=0x608160) at brick_dc.c:617 #6 0x0000000000401212 in main (argc=<optimized out>, argv=<optimized out>) at dc_test.cpp:116 Edit: und noch was ist mir gerade in diesem Testprogramm aufgefallen: vereinzelt startet das Programm erst gar nicht, sondern läuft auf einen Segementation fault, weill der Hauptthread schneller ist, als die IP-Connection Threads. Soll bedeuten, wenn ich den sleep(1) hier ergänze: if (ipcon_connect(&ipcon, host, 4223) < 0) { printf("Could not connect to brickd at %s:4223", host); return 1; } sleep(1); rotary_poti_create(&potiDevice, uidPoti, &ipcon); läuft alles OK, ist der weg, kracht's vereinzelt. Der connect sollte intern wohl eine kleine Wartezeit einbauen, damit die Threads alle initialisiert sind (ist aber ein anderes / zusätzliches Thema). dc_test.cpp