Überprüfen ob eine Verbindung zum BrickDaemon besteht.

[xPunkt]

Ich habe den Brickdaemon auf dem Raspberry Pi installiert und habe ein Python Programm das auf meinem PC läuft und sich mit dem brickd auf dem Raspberry Pi verbindet.

 

Meine Frage ist nun ob es möglich ist vom Raspberry Pi aus zu prüfen ob eine Verbindung zu dem Pc besteht.

 

 

Der Grund dahinter:

 

Ich die Bricks die mit dem Raspberry Pi verbunden sind steuern Motoren an und der Raspberry Pi wird vom PC aus gesteuert. Sollte nun die Verbindung zum PC aus irgendeinem Grund abbrechen möchte ich das die Motoren automatisch gestoppt werden. Nach meinem Verständnis müsste also auf dem Raspberry Pi lokal ein Python Programm laufen das überprüft ob der Brickd auf dem Rpi noch mit dem PC verbunden ist. Die einzige Lösung die mir dazu eingefallen ist, ist die brickd.log Datei zu öffnen und diese ständig auf einen Disconnect zu durchsuchen. Meine Frage ist nun ob es eine sauberer Lösung als die .log Datei gibt.

 

 

Grüße

[photron]

Ein Möglichkeit wäre, dass sich der PC nicht nur mit brickd auf dem RPi verbindet sondern auch mit deinem Programm auf dem RPi. Der PC sendet dann jede Sekunden eine Nachricht and dein Programm auf dem RPi. Sobald dein Programm für ein paar Sekunden keine Nachricht empfangen hat weißt du dass der PC nicht mehr da ist. Dann kann dein Programm auf dem RPi einspringen und übernehmen.

 

Oder der PC steuert nicht direkt die Bricks, sondern sendet Nachrichten an dein Programm auf dem RPi und das Programm macht dann lokal die Steuerung der Bricks. Auch hier kannst du es dann so bauen, dass der PC jede Sekunde eine Nachricht schickt, um zu sagen "Ich bin noch da". Sobald dein Programm auf dem RPi keine Nachrichten vom PC mehr empfängt weiss es dass der PC nicht mehr da ist und kann übernehmen.

[xPunkt]

Darüber habe ich auch schon nachgedacht. Wäre nur leider etwas aufwändig.

Gibt es aktuell keine Möglichkeit sich mithilfe des brickdaemons alle aktuellen Verbindungen anzuzeigen? Ähnlich wie sie in der .log Datei zu sehen sind?

[photron]

Nein, an die Information kommst du so leider nicht dran.

 

Alternativ kannst du dir natürlich etwas in brickd einbauen. Zum Beispiel, dass er bei jedem Connect/Disconnect in eine fixe Date in /tmp die aktuelle Anzahl der Verbindungen schreibt.

 

Ich hab dafür mal einen Patch angehängt.

brickd_connection_count.patch

[xPunkt]

Hab das ganze jetzt so gelöst das sich mein Programm auf dem Pc auch mit einem einem Programm auf dem Rpi verbindet und sobald die Verbindung zum Pc abbricht, verbindet sich der Rpi lokal mit dem brickdaemon setzt die Geschwindigkeit der Motoren auf 0 deaktiviert sie und trennt die IPConnection.

 

Nur leider tritt hier ein sehr ungewöhnliches Problem auf. Sobald ich die Motoren im Brick Viewer wieder aktiviere drehen diese sich mit der Geschwindigkeit vor dem Programmabbruch weiter. Per dc.get_velocity und im Brick Viewer wird die Geschwindigkeit trotzdem als 0 angezeigt. Auch mehrmaliges neu setzen der Geschwindigkeit auf 0 lässt die Motoren weiter drehen. Einzige Lösung die ich bisher gefunden habe ist den DC Brick Stapel zu resetten.

 

Habe keine Ahnung wodurch das Problem genau entsteht bzw. wie man es lösen kann.

[xPunkt]

Problem besteht weiterhin. Habe eine weitere Lösung gefunden(statt reset).

 

Wenn ich die Geschwindigkeit auf 0 setze, 1 Sekunde warte bis die Motoren wirklich stehen und dann dc.full_brake() ausführe und dann den Motor disable und anschließend die IPConnection trenne, so tritt das Problem mit der Motordrehung trotz Geschwindigkeit 0 beim erneuten enablen nicht mehr auf.

 

Laut Dokumentation soll man aber dc.full_brake() nur in Notsituationen benutzen.

Hat das ausführen von dc.full_brake() irgendwelche negativen Effekte wenn die Motoren bereits mit dc.set_velocity(0) auf 0 gesetzt sind und bereits stehen?

 

[photron]

Da ist ein Bug. Wenn die Velocity von != 0 auf == 0 geändert wird während der Motor deaktiviert ist, dann wird diese Velocity Änderung nicht an die Motorsteuerung weitergegeben und der Motor läuft dann später mit der alten Velocity weiter.

 

Das ist in DC Brick Firmware 2.3.1 jetzt behoben. Danke für den Hinweis.