remotecontrol

Ich habe leider schon wieder ein Problem : Testaufbau: Master mit Step-Down unten + WIFI Extension oben DC-Brick ganz oben Current/Voltage Bricklet hängt im Eingangsstrom des Stack und misst quasi den Stack; es sendet max. alle 0,5 Sekunden per Callback aktualsierte Werte für Strom,Spannung+Leistung (3 Callbacks) Rotary Poti hängt am Master und sendet per Callback Wertänderungen max alle 0,2 Sekunden (also max 5x Sekunde) Soweit klappt alles: wenn ich am Poti drehe werden die Werte auf der Console ausgegeben und dazu erscheinen ab und zu geänderte Werte für den Energieverbrauch. Wenn ich nun im Callback des Rotari Poti die Velocity des DC Bricks steuere, um damit die Motorgeschwindigkeit zu regeln, dann kommt es ab und zu vor, dass die IPConnection "hängt" und keine Callbacks mehr liefert. Strom am DC-Brick auslesen liefert dann immer rc=-1, Befehle zum DC Brick gesendet bleibt ohne Effekt. Manchmal fängt sich das wieder, manchmal aber auch nicht oder Mischformen: die Poticallbacks kommen an, die Änderungen in der Velocity haben aber keinen Effekt: Motor läuft unverändert weiter, dc_set_velocity liefert aber E_OK. Beende ich das Programm hart und starte es neu, dann reagiert der Stack meist normal, ich kann den Motor wieder steuern (kein Stack-Reset). Ich muss den Stack vereinzelt aber auch resetten. CPU-Last auf PC ist quasi 0. Ich habe keine Response-Expected flags gesetzt (alles Default). Aktuell sieht es danach aus, dass der Effekt verstärkt dann auftritt, wenn ich die Velocity auf Maximum gesetzt habe (Poti -150 -> Velocity -32767, Poti 150 -> Velocity 32767). Der Accellaration-Wert ist auf 32767 gesetzt, was den Motor binnen 1 Sekunde auf max beschleunigen kann. Die Menge an WIFI Paketen pro Sekunde dürfte 20 nicht übersteigen (max. 6 vom Voltage/Current, 5 vom Poti + 5 zum DC Brick - anders als damals beim Servo-Brick, wo es sehr viele Pakete waren. Dennoch hängt die Verbindung ab und zu. Firmware ist aktuell, Umgebung ist Intel Linux auf PC mit g++ 4.6.2 und C Bindings 2.0.8. Der Stack wird mit ca. 12V LiPo Akku versorgt, der Motor zieht ca. 150mA; Stack gesamt ca 250mA, die Spannung sackt auch nicht ab. Stacktraces zwischendurch sind nicht so richtig ergebnisreich, da das Programm ja mit gdb gestoppt wird, sieht z. B. so aus: Thread 5 (Thread 0x7fc599577700 (LWP 4028)): #0 0x00007fc59a49a2bc in send () from /lib64/libpthread.so.0 #1 0x000000000041e020 in socket_send (length=<optimized out>, buffer=0x7fc599576d60, socket=<optimized out>) at ip_connection.c:274 #2 ipcon_send_request (ipcon=0x7fff69a71df8, request=0x7fc599576d60) at ip_connection.c:1532 #3 0x000000000041ec46 in device_send_request (device=0x7fc588009f10, request=0x7fc599576d60, response=0x0) at ip_connection.c:924 #4 0x0000000000411a02 in dc_set_velocity (dc=0x7fc588009f10, velocity=-13106) at brick_dc.c:362 #5 0x000000000040db71 in brickapi::MotorBrick::accelerateTo (this=0x7fc588009ec0, speed=-13106) at Brick.cpp:152 #6 0x00000000004037fe in PotiEvent::valueChanged (this=0x7fff69a73050, item=0x7fc588008090, newValue=-60) at bricktests.cpp:89 #7 0x000000000040f796 in brickapi::SensorItem::valueChanged (this=0x7fc588008090, _value=-60) at SensorItem.cpp:249 #8 0x000000000040a26a in brickapi::Potentiometer::callback (value=-60, user_data=0x7fc588008090) at Potentiometer.cpp:82 #9 0x000000000041e1f8 in ipcon_dispatch_packet (packet=0x7fc590000b40, ipcon=<optimized out>) at ip_connection.c:1115 #10 ipcon_callback_loop (opaque=0x630140) at ip_connection.c:1144 #11 0x000000000041d74e in thread_wrapper (opaque=<optimized out>) at ip_connection.c:534 #12 0x00007fc59a492f05 in start_thread () from /lib64/libpthread.so.0 #13 0x00007fc599a5f10d in clone () from /lib64/libc.so.6 Thread 4 (Thread 0x7fc598d76700 (LWP 4030)): #0 0x00007fc59a4971eb in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000041d8e6 in event_wait (event=0x7fff69a72f00, timeout=<optimized out>) at ip_connection.c:399 #2 0x000000000041f355 in ipcon_disconnect_probe_loop (opaque=0x7fff69a71df8) at ip_connection.c:1197 #3 0x000000000041d74e in thread_wrapper (opaque=<optimized out>) at ip_connection.c:534 #4 0x00007fc59a492f05 in start_thread () from /lib64/libpthread.so.0 #5 0x00007fc599a5f10d in clone () from /lib64/libc.so.6 Thread 3 (Thread 0x7fc598575700 (LWP 4032)): #0 0x00007fc59a49a12c in recv () from /lib64/libpthread.so.0 #1 0x000000000041e481 in socket_receive (length=800, buffer=0x7fc598574b50, socket=<optimized out>) at ip_connection.c:270 #2 ipcon_receive_loop (opaque=0x7fff69a71df8) at ip_connection.c:1275 #3 0x000000000041d74e in thread_wrapper (opaque=<optimized out>) at ip_connection.c:534 #4 0x00007fc59a492f05 in start_thread () from /lib64/libpthread.so.0 #5 0x00007fc599a5f10d in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x7fc597d74700 (LWP 4033)): #0 0x00007fc59a4971eb in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x0000000000407c92 in __gthread_cond_timedwait (__cond=0x7fff69a72fe8, __mutex=0x7fff69a73018, __abs_timeout=0x7fc597d73c50) at /usr/include/c++/4.6/x86_64-suse-linux/bits/gthr-default.h:853 #2 0x0000000000408d49 in std::condition_variable::__wait_until_impl<std::chrono::system_clock, std::chrono::duration<long, std::ratio<1l, 1000000l> > > (this=0x7fff69a72fe8, __lock=..., __atime=...) at /usr/include/c++/4.6/condition_variable:158 #3 0x0000000000408a3b in std::condition_variable::wait_until<std::chrono::duration<long, std::ratio<1l, 1000000l> > > ( this=0x7fff69a72fe8, __lock=..., __atime=...) at /usr/include/c++/4.6/condition_variable:95 #4 0x0000000000408703 in std::condition_variable::wait_for<long, std::ratio<1l, 1000l> > (this=0x7fff69a72fe8, __lock=..., __rtime=...) at /usr/include/c++/4.6/condition_variable:127 #5 0x0000000000407f07 in brickapi::AsyncTask::shouldFinish (this=0x7fff69a72fd0, waitMs=1000) at AsyncTask.cpp:76 #6 0x00000000004031e7 in PowerLog::run (this=0x7fff69a72fd0) at bricktests.cpp:69 #7 0x0000000000407e1a in brickapi::AsyncTask::callRunMethod (this=0x7fff69a72fd0) at AsyncTask.cpp:48 #8 0x0000000000409f00 in std::_Mem_fn<void (brickapi::AsyncTask::*)()>::operator() (this=0x630b08, __object=0x7fff69a72fd0) at /usr/include/c++/4.6/functional:551 #9 0x0000000000409e69 in std::_Bind_result<void, std::_Mem_fn<void (brickapi::AsyncTask::*)()> (brickapi::AsyncTask*)>::__call<void, , 0>(std::tuple<>&&, std::_Index_tuple<0>, std::_Bind_result<void, std::_Mem_fn<void (brickapi::AsyncTask::*)()> (brickapi::AsyncTask*)>::__enable_if_void<void>::type) (this=0x630b08, __args=...) at /usr/include/c++/4.6/functional:1287 #10 0x0000000000409e03 in std::_Bind_result<void, std::_Mem_fn<void (brickapi::AsyncTask::*)()> (brickapi::AsyncTask*)>::operator()<>() ( this=0x630b08) at /usr/include/c++/4.6/functional:1378 #11 0x0000000000409d42 in std::thread::_Impl<std::_Bind_result<void, std::_Mem_fn<void (brickapi::AsyncTask::*)()> (brickapi::AsyncTask*)> >::_M_run() (this=0x630af0) at /usr/include/c++/4.6/thread:117 #12 0x00007fc59a1f6058 in ?? () from /usr/lib64/libstdc++.so.6 #13 0x00007fc59a492f05 in start_thread () from /lib64/libpthread.so.0 #14 0x00007fc599a5f10d in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7fc59ab7a720 (LWP 4024)): #0 0x00007fc599a5118d in read () from /lib64/libc.so.6 #1 0x00007fc5999f6d18 in _IO_new_file_underflow () from /lib64/libc.so.6 #2 0x00007fc5999f7d8e in _IO_default_uflow_internal () from /lib64/libc.so.6 #3 0x00007fc5999f3108 in getchar () from /lib64/libc.so.6 #4 0x00000000004033e6 in runTests (host=0x7fff69a74110 "tinkertest") at bricktests.cpp:132 #5 0x00000000004035c5 in main (argc=3, argv=0x7fff69a731e8) at bricktests.cpp:163 ======================= 2. Stacktrace =============================== --------------------------------------------------------------------- Thread 5 (Thread 0x7f2b16106700 (LWP 4364)): #0 0x00007f2b17028010 in sem_wait () from /lib64/libpthread.so.0 #1 0x000000000041e175 in semaphore_acquire (semaphore=<optimized out>) at ip_connection.c:479 #2 queue_get (length=<synthetic pointer>, data=<synthetic pointer>, kind=<synthetic pointer>, queue=0x630148) at ip_connection.c:731 #3 ipcon_callback_loop (opaque=0x630140) at ip_connection.c:1126 #4 0x000000000041d74e in thread_wrapper (opaque=<optimized out>) at ip_connection.c:534 #5 0x00007f2b17021f05 in start_thread () from /lib64/libpthread.so.0 #6 0x00007f2b165ee10d in clone () from /lib64/libc.so.6 Thread 4 (Thread 0x7f2b15905700 (LWP 4366)): #0 0x00007f2b170261eb in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000041d8e6 in event_wait (event=0x7fff32d5c8f0, timeout=<optimized out>) at ip_connection.c:399 #2 0x000000000041f355 in ipcon_disconnect_probe_loop (opaque=0x7fff32d5b7e8) at ip_connection.c:1197 #3 0x000000000041d74e in thread_wrapper (opaque=<optimized out>) at ip_connection.c:534 #4 0x00007f2b17021f05 in start_thread () from /lib64/libpthread.so.0 #5 0x00007f2b165ee10d in clone () from /lib64/libc.so.6 Thread 3 (Thread 0x7f2b15104700 (LWP 4367)): #0 0x00007f2b1702912c in recv () from /lib64/libpthread.so.0 #1 0x000000000041e481 in socket_receive (length=800, buffer=0x7f2b15103b50, socket=<optimized out>) at ip_connection.c:270 #2 ipcon_receive_loop (opaque=0x7fff32d5b7e8) at ip_connection.c:1275 #3 0x000000000041d74e in thread_wrapper (opaque=<optimized out>) at ip_connection.c:534 #4 0x00007f2b17021f05 in start_thread () from /lib64/libpthread.so.0 #5 0x00007f2b165ee10d in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x7f2b14903700 (LWP 4368)): #0 0x00007f2b170261eb in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x0000000000407c92 in __gthread_cond_timedwait (__cond=0x7fff32d5c9d8, __mutex=0x7fff32d5ca08, __abs_timeout=0x7f2b14902c50) at /usr/include/c++/4.6/x86_64-suse-linux/bits/gthr-default.h:853 #2 0x0000000000408d49 in std::condition_variable::__wait_until_impl<std::chrono::system_clock, std::chrono::duration<long, std::ratio<1l, 1000000l> > > (this=0x7fff32d5c9d8, __lock=..., __atime=...) at /usr/include/c++/4.6/condition_variable:158 #3 0x0000000000408a3b in std::condition_variable::wait_until<std::chrono::duration<long, std::ratio<1l, 1000000l> > > ( this=0x7fff32d5c9d8, __lock=..., __atime=...) at /usr/include/c++/4.6/condition_variable:95 #4 0x0000000000408703 in std::condition_variable::wait_for<long, std::ratio<1l, 1000l> > (this=0x7fff32d5c9d8, __lock=..., __rtime=...) at /usr/include/c++/4.6/condition_variable:127 #5 0x0000000000407f07 in brickapi::AsyncTask::shouldFinish (this=0x7fff32d5c9c0, waitMs=1000) at AsyncTask.cpp:76 #6 0x00000000004031e7 in PowerLog::run (this=0x7fff32d5c9c0) at bricktests.cpp:69 #7 0x0000000000407e1a in brickapi::AsyncTask::callRunMethod (this=0x7fff32d5c9c0) at AsyncTask.cpp:48 #8 0x0000000000409f00 in std::_Mem_fn<void (brickapi::AsyncTask::*)()>::operator() (this=0x630b08, __object=0x7fff32d5c9c0) at /usr/include/c++/4.6/functional:551 #9 0x0000000000409e69 in std::_Bind_result<void, std::_Mem_fn<void (brickapi::AsyncTask::*)()> (brickapi::AsyncTask*)>::__call<void, , 0>(std::tuple<>&&, std::_Index_tuple<0>, std::_Bind_result<void, std::_Mem_fn<void (brickapi::AsyncTask::*)()> (brickapi::AsyncTask*)>::__enable_if_void<void>::type) (this=0x630b08, __args=...) at /usr/include/c++/4.6/functional:1287 #10 0x0000000000409e03 in std::_Bind_result<void, std::_Mem_fn<void (brickapi::AsyncTask::*)()> (brickapi::AsyncTask*)>::operator()<>() ( this=0x630b08) at /usr/include/c++/4.6/functional:1378 #11 0x0000000000409d42 in std::thread::_Impl<std::_Bind_result<void, std::_Mem_fn<void (brickapi::AsyncTask::*)()> (brickapi::AsyncTask*)> >::_M_run() (this=0x630af0) at /usr/include/c++/4.6/thread:117 #12 0x00007f2b16d85058 in ?? () from /usr/lib64/libstdc++.so.6 #13 0x00007f2b17021f05 in start_thread () from /lib64/libpthread.so.0 #14 0x00007f2b165ee10d in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7f2b17709720 (LWP 4363)): #0 0x00007f2b165e018d in read () from /lib64/libc.so.6 #1 0x00007f2b16585d18 in _IO_new_file_underflow () from /lib64/libc.so.6 #2 0x00007f2b16586d8e in _IO_default_uflow_internal () from /lib64/libc.so.6 #3 0x00007f2b16582108 in getchar () from /lib64/libc.so.6 #4 0x00000000004033e6 in runTests (host=0x7fff32d5d110 "tinkertest") at bricktests.cpp:132 #5 0x00000000004035c5 in main (argc=3, argv=0x7fff32d5cbd8) at bricktests.cpp:163

Hier die Service-Definition: [unit] Description=Tinkerforge Brick Daemon After=syslog.target network.target auditd.service [service] Type=forking ExecStart=/usr/bin/brickd --daemon KillMode=process [install] WantedBy=multi-user.target sollte gespeichert werden unter /usr/lib/systemd/system/brickd.service. Danach noch systemctl enable brickd.service systemctl start brickd und dann lief er bei mir (und nach dem Reboot auch wieder).

Das Thema trifft sich gut: ich bin gerade dabei den brickd auf einem Cubieboard2 mit Fedora 19 zum Laufen zu bekommen. brickd kann ich mit händischem Eingriff inzwischen übersetzen, aber es fehlen z. B. die systemd-Skripte: Fedora 19 basiert (wie einige andere Distributionen inzwischen) auf systemd und nutzt keine init-Skripte mehr. Wenn ich das systemd-Startskript fertig habe, würde ich es hier posten, dann kann es mit in die Sourcen aufgenommen werden. Das Build-Skript müsste mindestens so verändert werden, dass es ohne "dpkg" klarkommt, das gibt es bei Fedora,Redhat,Suse,... ja nicht.

Wenn Du per brickv schon mittels IP auf den Stack zugreifen kannst: der Stack hängt nicht per USB an Deinem Rechner - oder? Du greifst nicht über 127.0.0.1 zu? Dann müsstest Du die Extension ja schon einmal konfiguriert haben und solltest diese eigentlich auch in Deinem Router sehen (sofern Du keine statische IP verwendest - ist etwas vom Router abhängig). Die Ethernet-Extension hat kein Web-Interface, du musst die Tinkerforge API in einem Skript/Programm nutzen, um die Werte abzurufen. Das Skript greift dann per API über das Netzwerk auf den Stack zu und liest die Werte aus. Du brauchst dazu auf jeden Fall einen Rechner, auf dem das Skript läuft. Das kann ein PI oder irgendein anderer Rechner sein. Auch ein Android Gerät oder z. B. auch ein NAS, sofern Du darauf selber Skripte ausführen kannst (bei Synology geht das z. B.).

Ich finde das Verhalten vom brickv OK. Ich frage mich aber dennoch ob es prinzipiell überhaupt möglich wäre, einen Event zu verteilen, wenn durch eine andere Anwendung callbacks gelöscht werden. Das geht dann doch in Richtung Firmware. Für den normalen Betrieb ist das eher ein Sonderfall, da nicht zwei Anwendungen gegen einen Stack arbeiten sollten. Aber das "mal eben den Detailstatus auslesen" z. B. über brickv ist doch nicht so selten. Dann wäre es gut, wenn die Anwendung solche Fälle erkennen kann.

Das bedeutet aber, dass eine 2. Anwendung die Callbacks der 1. ebenfalls löscht, ohne dass die 1. das mitbekommt. Ist für mich erstmal kein Problem, da es wohl eher die Ausnahme ist, dass sich eine 2. Anwendung connected. In meinem Fall prüfe ich nun ob x Sekunden kein einziger Sensor-Callback erfolgt ist, wenn ja starte ich den Enumerate neu und registriere damit die Callbacks neu.

Ist mir bisher auch nicht aufgefallen. Ich versuche aber gerade, meine Anwendung gegen Ausfälle und externe Connects zu stabilisieren und dabei ist mir aufgefallen, dass ich nicht mitbekomme, wenn sich z.B. der brickv disconnected. Danach sind aber "fast" alle Callbacks weg: - von den Sensoren (temp, baro, ambi, humi) kommt nichts mehr (hier hatte ich 5 Sekunden Callback-Period eingestellt) - die Buttons des LCDs senden aber noch Callbacks

Hallo, wenn ich zwei Hosts gegen einen Stack connecte, so bekommt der 1. Host einen erneuten enumeration Callback, wenn sich der 2. connected (-> OK). Der 1. Host muss dann die Callbacks neu registrieren (-> OK). Disconnected sich nun der 2. Host, so bekommt der 1. Host aber keinen enumeration Callback mehr und alle Bricklet-Callback sind dennoch weg. Oder habe ich was übersehen? Wie kann ich mitbekommen, wenn sich der 2. Host disconnected und der 1. seine Callbacks neu registrieren muss?

Ich glaub' ich hab den Fehler : in ipcon_receive_loop: ipcon_handle_response(ipcon, pending_data); memmove(pending_data, pending_data + length, pending_length - length); pending_length -= length; Muss der memmove so aussehen: memmove(pending_data, ((uint8_t *)pending_data) + length, pending_length - length); da pending_data grob gesagt ein Array von structs ist und "pending_data + length" das x.-te Element aus einem Array ist und nicht ein Byte Offset um "length" Bytes. Der Fehler ist immer genau dann passiert, wenn mehr als 1 Paket vom recv() gelesen wurde und der memmove tatsächlich was verschoben hat.

Optimierung ist nun in allen Teilen aus. Ein paar Traces habe ich eingebaut, das sieht dann so aus: ipcon_callback_loop: ipcon_dispatch_meta Wait before socket_receive ipcon_receive_loop: got 34 bytes ipcon_receive_loop: got 34 bytes ipcon_handle_response(func = 253) Wait before socket_receive ipcon_callback_loop: ipcon_dispatch_packet(dc351631,34,253, ipcon_receive_loop: got 102 bytes ipcon_receive_loop: got 34 bytes ipcon_handle_response(func = 253) ipcon_receive_loop: got 0 bytes ipcon_handle_response(func = 0) ipcon_handle_response: ignoring response for an unknown device ipcon_receive_loop: got 0 bytes ipcon_handle_response(func = 0) ipcon_handle_response: ignoring response for an unknown device ipcon_receive_loop: got 0 bytes ipcon_handle_response(func = 0) ipcon_handle_response: ignoring response for an unknown device ipcon_receive_loop: got 0 bytes ipcon_handle_response(func = 0) ipcon_handle_response: ignoring response for an unknown device ipcon_receive_loop: got 0 bytes ipcon_handle_response(func = 0) ipcon_handle_response: ignoring response for an unknown device ipcon_receive_loop: got 0 bytes ipcon_handle_response(func = 0) .. binnen von 2 Sekunden wird 1 Gigabyte and log-Daten geschrieben wird: es loopt in der receive-loop, es kommen immer 0 Bytes zurück, die pending_data sind 0-initialisiert, pending_length steht aber auf 214. Die ersten Pakete a 34 Bytes sind mal mehr mal weniger, aber meist loopt es nach 2-5 Paketen.

OK, ich werde auch die Optimierung mal abschalten, dann sieht man ggf. einige Werte besser. Da komme ich die nächsten Tage aber nicht zu. Das Programm läuft eigentlich schon seit einigen Monaten stabil. Ich habe jetzt durch den Umbau in ein neues Gehäuse mal die Firmware aktualisiert und dabei auch die Bindings. Vorhin hat es 1-2x auch mit Bindings 2.0.7 funktioniert, d. h. irgendwie kommt mehr oder weniger oft im Startup was durcheinander, je nach Initialisierungsreihenfolge der Threads. Wenn die Initialisierung OK ist, dann läuft es danach auch sauber weiter.

Mein Vermutung ist, dass es an den Bindungs 2.0.7 liegt: wenn ich die 2.0.5 nutze sieht es gut aus (bekomme das Problem zumindest nicht reproduziert und hatte bisher ja auch keine Probleme damit). Bei 2.0.7 bekomme ich die Probleme. Ich hab' gerade 2x hin und her gewechselt ... Auf dem PI habe ich auch noch die 2.0.5, vielleicht lief es deswegen ohne Probleme. Host-CPU ist ein Quad-Core.

das sieht dann so aus: Thread 3 (Thread 0x7f280a80e700 (LWP 15655)): #0 0x00007f280b730010 in sem_wait () from /lib64/libpthread.so.0 No symbol table info available. #1 0x000000000042dc75 in semaphore_acquire (semaphore=<optimized out>) at ip_connection.c:479 No locals. #2 queue_get (length=<synthetic pointer>, data=<synthetic pointer>, kind=<synthetic pointer>, queue=0x647aa8) at ip_connection.c:731 item = <optimized out> #3 ipcon_callback_loop (opaque=0x647aa0) at ip_connection.c:1125 callback = 0x647aa0 kind = <optimized out> data = <optimized out> length = <optimized out> #4 0x000000000042d24e in thread_wrapper (opaque=<optimized out>) at ip_connection.c:534 thread = <optimized out> #5 0x00007f280b729f05 in start_thread () from /lib64/libpthread.so.0 Thread 2 (Thread 0x7f280980c700 (LWP 15658)): #0 table_get (table=0x7fff7f872fa0, key=0) at ip_connection.c:639 No locals. #1 0x000000000042e07e in ipcon_handle_response (response=0x7f280980bb50, ipcon=0x7fff7f872f58) at ip_connection.c:1233 device = <optimized out> sequence_number = 0 '\000' #2 ipcon_receive_loop (opaque=0x7fff7f872f58) at ip_connection.c:1309 ipcon = 0x7fff7f872f58 socket_id = 1 pending_data = {{header = {uid = 0, length = 0 '\000', function_id = 0 '\000', sequence_number_and_options = 0 '\000', error_code_and_future_use = 0 '\000'}, payload = '\000' <repeats 26 times>, "0\237\000\000\"\375\b\000d7C\000\000\000\000\000\066\062DrY6\000\000c\001\000\000\002\000\001\335\000\000\000\000\000", optional_data = "\000\000\000\000\000\000\000"}, {header = {uid = 0, length = 0 '\000', function_id = 0 '\000', sequence_number_and_options = 0 '\000', error_code_and_future_use = 0 '\000'}, payload = '\000' <repeats 63 times>, optional_data = "\000\000\000\000\000\000\000"}, {header = {uid = 0, length = 0 '\000', function_id = 0 '\000', sequence_number_and_options = 0 '\000', error_code_and_future_use = 0 '\000'}, payload = '\000' <repeats 63 times>, optional_data = "\000\000\000\000\000\000\000"}, {header = {uid = 0, length = 0 '\000', function_id = 0 '\000', sequence_number_and_options = 0 '\000', error_code_and_future_use = 0 '\000'}, payload = '\000' <repeats 63 times>, optional_data = "\000\000\000\000\000\000\000"}, {header = {uid = 0, length = 0 '\000', function_id = 0 '\000', sequence_number_and_options = 0 '\000', error_code_and_future_use = 0 '\000'}, payload = '\000' <repeats 63 times>, optional_data = "\000\000\000\000\000\000\000"}, {header = {uid = 0, length = 0 '\000', function_id = 0 '\000', sequence_number_and_options = 0 '\000', error_code_and_future_use = 0 '\000'}, payload = '\000' <repeats 63 times>, optional_data = "\000\000\000\000\000\000\000"}, {header = {uid = 0, length = 0 '\000', function_id = 0 '\000', sequence_number_and_options = 0 '\000', error_code_and_future_use = 0 '\000'}, payload = '\000' <repeats 63 times>, optional_data = "\000\000\000\000\000\000\000"}, {header = {uid = 0, length = 0 '\000', function_id = 0 '\000', sequence_number_and_options = 0 '\000', error_code_and_future_use = 0 '\000'}, payload = '\000' <repeats 63 times>, optional_data = "\000\000\000\000\000\000\000"}, {header = {uid = 0, length = 0 '\000', function_id = 0 '\000', sequence_number_and_options = 0 '\000', error_code_and_future_use = 0 '\000'}, payload = '\000' <repeats 63 times>, optional_data = "\000\000\000\000\000\000\000"}, {header = {uid = 0, length = 0 '\000', function_id = 0 '\000', sequence_number_and_options = 0 '\000', error_code_and_future_use = 0 '\000'}, payload = '\000' <repeats 63 times>, optional_data = "\000\000\000\000\000\000\000"}} pending_length = 34 length = 0 #3 0x000000000042d24e in thread_wrapper (opaque=<optimized out>) at ip_connection.c:534 thread = <optimized out> #4 0x00007f280b729f05 in start_thread () from /lib64/libpthread.so.0 Thread 1 (Thread 0x7f280be11720 (LWP 15654)): #0 0x00007f280b72b1cf in pthread_join () from /lib64/libpthread.so.0 No symbol table info available. #1 0x000000000042d479 in ipcon_disconnect_unlocked (ipcon=0x7fff7f872f58) at ip_connection.c:1509 No locals. #2 0x000000000042eae2 in ipcon_disconnect (ipcon=0x7fff7f872f58) at ip_connection.c:1656 callback = <optimized out> meta = {function_id = 232 '\350', parameter = 64 '@', socket_id = 140735332953808} #3 0x000000000042eb15 in ipcon_destroy (ipcon=0x7fff7f872f58) at ip_connection.c:1585 No locals. #4 0x000000000041eaab in brickapi::BrickConnector::~BrickConnector (this=0x7fff7f872f50, __in_chrg=<optimized out>) at BrickConnector.cpp:68 No locals. #5 0x000000000040ce6d in showStatus (host=0x7fff7f876112 "pi", props=0x430441 "application.properties", logName=0x430226 "weather.csv", noWelcome=true) at main.cpp:103 connector = {_vptr.BrickConnector = 0x4320f0, ipcon = {host = 0x6471c0 "pi", port = 4223, timeout = 2500, auto_reconnect = true, auto_reconnect_allowed = false, auto_reconnect_pending = false, sequence_number_mutex = {handle = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}}, next_sequence_number = 13, devices = {mutex = {handle = {__data = { __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}}, used = 5, allocated = 16, keys = 0x6470e0, values = 0x647130}, registered_callbacks = {0x0 <repeats 253 times>, 0x41edec, 0x0, 0x0}, registered_callback_user_data = { 0x0 <repeats 253 times>, 0x7fff7f872f50, 0x0, 0x0}, socket_mutex = {handle = {__data = {__lock = 1, __count = 0, __owner = 15654, __nusers = 1, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = "\001\000\000\000\000\000\000\000&=\000\000\001", '\000' <repeats 26 times>, __align = 1}}, socket = 0x6471e0, socket_id = 1, receive_flag = false, receive_thread = {handle = 139809934853888, function = 0x42df00 <ipcon_receive_loop(void*)>, opaque = 0x7fff7f872f58}, callback = 0x647aa0, disconnect_probe_flag = false, disconnect_probe_thread = {handle = 139809943246592, function = 0x42ede0 <ipcon_disconnect_probe_loop(void*)>, opaque = 0x7fff7f872f58}, disconnect_probe_event = {condition = { __data = {__lock = 0, __futex = 10, __total_seq = 5, __wakeup_seq = 5, __woken_seq = 5, __mutex = 0x7fff7f874090, __nwaiters = 0, __broadcast_seq = 0}, __size = "\000\000\000\000\n\000\000\000\005\000\000\000\000\000\000\000\005\000\000\000\000\000\000\000\005\000\000\000\000\000\000\000\220@\207\177\377\177\000\000\000\000\000\000\000\000\000", __align = 42949672960}, mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, flag = true}, wait = {object = { __size = "\000\000\000\000\200", '\000' <repeats 19 times>, "0h\341\v(\177\000", __align = 549755813888}, pointer = 0x7fff7f8740c0}}, devices = {<std::_List_base<brickapi::DeviceItem*, std::allocator<brickapi::DeviceItem*> >> = { _M_impl = {<std::allocator<std::_List_node<brickapi::DeviceItem*> >> = {<__gnu_cxx::new_allocator<std::_List_node<brickapi::DeviceItem*> >> = {<No data fields>}, <No data fields>}, _M_node = {_M_next = 0x7f27fc002690, _M_prev = 0x7f27fc00be10}}}, <No data fields>}, master = 0x7f27fc0025f0, motorMaster = 0x0, servo = 0x0, lcd = 0x7f27fc006310, dualRelay = 0x0, quadRelay = 0x0, distanceIR = 0x0, ambiLight = 0x7f27fc006220} master = 0x7f27fc0025f0 lcd = 0x7f27fc006310 log = 0x647860 rc = 4 #6 0x000000000040d345 in main (argc=5, argv=0x7fff7f874668) at main.cpp:233 host = 0x7fff7f876112 "pi" pidFile = 0x0 noWelcome = true props = 0x430441 "application.properties" ... Ich werde mir nochmal die C-Bindings 2.0.5 runterladen, die ich bis dato im Einsatz hatte. Damit ging es auch remote ohne Probleme. Auf dem PI direkt läuft aus auch mit 2.0.7 ohne Probleme.

Hallo, ich habe ein Problem im Disconnect, wenn der Enumerate bzw. die Netzwerkverbindung "langsam" ist: das Aufräumen klappt dann nicht, der Prozess loopt im pthread_join und lässt sich nur noch durch "kill -9" beenden: 0x00007f36bda2d1cf in pthread_join () from /lib64/libpthread.so.0 (gdb) where #0 0x00007f36bda2d1cf in pthread_join () from /lib64/libpthread.so.0 #1 0x000000000042d469 in ipcon_disconnect_unlocked (ipcon=0x7fff85466888) at ip_connection.c:1509 #2 0x000000000042ead2 in ipcon_disconnect (ipcon=0x7fff85466888) at ip_connection.c:1656 #3 0x000000000042eb05 in ipcon_destroy (ipcon=0x7fff85466888) at ip_connection.c:1585 #4 0x000000000041ea6b in brickapi::BrickConnector::~BrickConnector (this=0x7fff85466880, __in_chrg=<optimized out>) at BrickConnector.cpp:68 ... Wenn ich mich remote gegen einen auf dem PI laufenden Brickd connecte kommt das relativ oft vor. Die WLAN-Verbindung zum PI reagiert aber teilweise sehr träge. Beim Beenden loopt es dann (Multi-Core CPU) bzw. der Enumerate bringt nicht alle Devices, was zum Beenden führt und dann auch loopt. Noch habe ich keine Idee woran das liegen kann. Scheint mit den Bindungs 2.0.6 auch zu passieren. Läuft das Programm direkt auf dem PI, so beendet es sich normal (Single-Core CPU). In beiden Fällen g++ 4.6.2 mit Linux.

Für die Korrekturberechnung der Luftfeuchtigkeit habe ich was gefunden: http://de.wikipedia.org/wiki/S%C3%A4ttigung_%28Physik%29#S.C3.A4ttigung_von_Gasen_am_Beispiel_des_Wasserdampfs. Wenn ich damit die rel. Luftfeuchtigkeit auf die andere Temperatur umgerechne komme ich recht gut an die Werte, die mein anderes Hygrometer hier anzeigt. Bleibt die Frage nach dem Barometer: wie wirkt sich die Temperaturänderung hier aus?

Hallo zusammen, ich habe gerade die Wetterstation mit einem PI in Betrieb genommen und (wie zu erwarten) ist die Temperatur im Gehäuse durch die Abwärme des PI ca. 6° über Zimmertemperatur. Das ist erstmal kein Problem, die Temperatur messe ich mit separatem Temp.-Bricklet außerhalb des Gehäuses. Aber: Barometer- und Humidity-Bricklet arbeiten ja relativ zur Temperatur und diese Werte sind stark verfäscht. Kann ich das softwareseitig mit Hilfe des Temp.-Bricklets umrechnen / korrigieren? Man merkt nämlich deutlich, dass innerhalb der ersten 20 Minuten nach Einschalten der Station die Innentemperatur (gemmessen vom Barometerbricklet), von z. B. 25 auf 31° ansteigt und gleichzeitig der ausgelesene Luftdruck fällt. Analog zeigt das Humidity-Bricklet extrem trockene Luft an (30%), obwohl ein externes Termometer, welches daneben steht, 48% anzeigt.

Hallo TF-Team, ich habe gerade meine "Wetterstation" aus meinem Gehäuse raus und in das Gehäuse der Wetterstation aus dem Shop umgebaut. Dabei ist mir aufgefallen, dass für das Display und Montage des Bricks/Stop-Down längere Schrauben notwendig sind. Das ist in der Montage-Abbildung sogar erkennbar, aber erstmal denkt man da nicht dran. Beim Gehäuse für das Dual-Relais sind jede Menge Schrauben für die Montage dabei, beim Gehäuse der Wetterstation leider nicht. Zumindest die langen Schrauben wären hilfreich, den Rest hat man eigentlich, wenn man ein paar Bricks+Bricklets angeschafft hat. Daher als Anregung: vielleicht packt Ihr die 8 langen Schrauben zum Gehäuse mit dazu, da die bei den Einzelkomponenten so nicht dabei sind. Viele Grüße

Ich habe auch eine "Wetterstation" mit dem PI gebaut, allerdings mit einem komplett anderen Gehäuse. Zu Beginn hatte ich die Sensoren außen am Gehäuse befestigt. Der erste Probelauf hat aber gezeigt, dass sich doch 3-5°C an Abwärme vom PI über das Kunststoffgehäuse auf den Temp.-Sensor übertragen. Jetzt habe ich den Sensor ca. 5 cm entfernt vom Gehäuse, das hilft merklich (ist allerdings nicht so schön).

Ein Punkt ist mir noch aufgefallen zum Thema Kettenfahrzeug: ich hatte mal einen Hydraulik-Bagger ins Auge gefasst und zumindest schon mal drüber nachgedacht: Ich hätte jede Kette einzeln mit eigenem Fahrtregler angesteuert und den Mischer quasi in der Software implementiert. Solche Funktionen wollte ich haben, über ein Kreuzfeld gesteuert: vor/zurück + links/rechts => beim links/rechts muss ja eine Kette langsamer laufen als die andere, abhängig von der aktuellen Geschwindigkeit (Mischfunktion). Und dabei ist es wichtig, dass ich den Geschwindigkeitsunterschied der Ketten fein steuern kann. Auf der Stelle drehen => Ketten bewegen sich entgegen gesetzt; das ist auch Teil der Mischfunktion: ist die Geschwindigkeit 0, wird auf der Stelle gedreht. Ich weiss nicht, ob der eine Chip das so macht, da solltest Du zumindest mal drüber nachdenken.

Meiner Meinung nach müsstest Du das "Servo" (Fahrtregler) auch über den Brick aus "disable" setzen können. Das Risiko ist aber das dann beim Einschalten nicht die 0-Position anliegt und der Fahrtregler sofort Gas gibt, wenn die Software den Kanal wieder auf "enable" setzt. Darum würde ich (wann immer möglich) versuchen, erst die 0-Stellung zu senden und dann den Regler abschalten oder disable. Beim Einschalten sollte auch noch die 0-Stellung da sein. Ich würde auf keinen Fall die Signalleitung zwischen Servo-Brick und Fahrtregler via Relais schalten. Ich schalte den Regler normalerweise nie ab. Wenn die 0-Stellung anliegt brummt nichts (was nicht korrekte 0-Stellung wäre) und zuckt nichts. Der Ruhestrom ist recht gering. Die GPIOs vom PI habe ich noch nicht benutzt, aber mich schon eingelesen und PIN-Header (Kabel) besorgt, die ich einzeln auf die PIN-Leiste stecken kann (will nur bestimmte Funktionen nutzen, z. B. darüber einen Summer schalten ohne weiteres Bricklet). Das Bild sieht vom Grundaufbau erstmal korrekt aus. Viele Grüße

das mit der Antwort war Zufall - ich habe gerade mal reingeschaut . Was meinst Du mit ? Die Fahrtregler hängen direkt am Servo. Den mechanischen Schiebeschalter, der den Fahrtregler abschaltet, habe ich anfangs einfach überbrückt. Beim Einschalten des Systems ruckt nichts. Wenn man den mechanischen Schalter per Quad-Relais ein/ausschaltet, um beim Verlassen der WLAN-Reichweite einen "Not-Aus" zu haben, dann ruckt es nicht, sofern das Relais aktiviert wird, bevor irgendwelche Servo-Befehle den Fahrtregler erreichen. Der Fahrtregler gibt 1x einen Ton von sich, wenn er den Betrieb aufnimmt. Das passiert bei mir erst, wenn ich die Steuerung benutze (== Servobefehle sende), nicht schon beim Einschalten des Modells. Wenn die Software den Connect aufgebaut hat und den Servobrick aktiviert, dann gibt der Fahrtregler erst die Initialisierungston von sich. Wenn vorher das Relais geschaltet wird und etwas danach erst angefahren wird, ruckt es nicht. Nur wenn man einen Disconnect und erneuten Connect macht, muss man aufpassen, dass das Servobrick beim Disconnect auf die 0-Stellung eingestellt ist. Sonst könnte das Modell beim Reconnect losfahren, wenn das Relais geschaltet wird: das Servobrick sendet den Impuls ja weiter, nur der Hauptschalter des Fahrtreglers war aus ...

Hallo Winbug, als Fahrtregler nutze ich diese hier: http://www.conrad.de/ce/de/product/207369/. Davon habe ich aktuell zwei im Modell (1 Antrieb, 1 Seilwinde). Die sind recht klein und günstig (damals gab's noch ein 3er Pack). Ich steuere die direkt über ein Servo-Brick, also nicht über den DC Brick. Und das ist eigentlich sehr einfach. Nur auf die Polung des Motors muss man aufpassen, da die Fahrtregler in der Regel nicht symmetrisch beschleunigen & bremsen (vorwärts schneller als rückwärts). An den Servo-Einstellungen (PWM etc.) habe ich Softwareseitig nur die Spannung auf 6V erhöht, da die Regler und die angeschlossenen Servos das vertragen. Die übrigen Einstellungen sind die Defaultwerte vom Servo-Brick. Beim Anschluss der Fahrtregler aber unbedingt die Tinkerforge-Doku zum Servobrick lesen. Zum L293D kann ich nicht viel sagen, für mich war die Lösung mit Servobrick + Standard-Fahrtregler ausreichend. Ich habe auch mangels Platz kein DC-Brick genommen: der Stack hätte zwei gebraucht und den Servobrick auch noch und dann wäre mein Stack zu hoch geworden. Die Fahrtregler brauchen mit Kabel zwar mehr Platz als ein DC-Brick, aber eben "irgendwo anders" im Modell. Bei den Servos habe ich 4 völlig unterschiedliche (Micro bis "Lastservo" mit Metalllager), die jedoch alle 6V vertragen und den gleichen Winkelbereich haben (+/- 45°). Für diverse Schaltfunktionen habe ich zwei Industrial Quad-Relais eingebaut. Zuerst dachte ich, ich müsste darüber Relais schalten, die mehr Strom schalten können. Am Ende benötigen meine Verbaucher aber weniger als 500mA, d.h. ich kann alles direkt damit schalten. Nachtrag zur Stromversorgung: die Fahrtregler sind offiziell nur bis 7,2V, machen aber auch bei 9,6V keine Probleme. Viele Grüße

Woran machst Du fest, dass der brickv Adminrechte benötigt? Zum Installieren brauche ich Adminrechte. Zum Ausführen brauche ich aber weder auf Linux, noch auf Windows welche?

Ich würde den Lüfter auf jeden Fall in irgendeiner Form schaltbar machen. Im einfachsten Fall z. B. über einen Jumper auf "immer ein" und wenn der Jumper nicht drauf ist über einen (per IO Bricklet oder Relais) geschalteten Eingang ein/aus (oder gar geregelt ..). Hintergrund: wenn der Lüfter z.B. das DC Brick kühlen soll, aber der Motor nicht immer an ist - warum soll der Lüfter immer laufen?

Da kommt diese Meldung: ip_connection.c: In function ‘void ipcon_receive_loop(void*)’: ip_connection.c:1275:43: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]