remotecontrol

Der Effekt tritt auch auf, wenn ich das direkt vom Tablet aus ausführe. Allerdings merkt man, dass es vom Tablet aus minimal langsamer läuft (CPU nicht so stark).

Ist der Stack im Access Point Mode habe ich nach einer Weile auch Hänger, allerdings bekomme ich die oft erst beim 2. Durchlauf. Auch dann hilft nur noch der Reset, um WIFI wieder ansprechbar zu machen.

Hallo Admins,

anbei habe ich ein neues Testprogramm (siehe src/bricktest/Main.java) mit dem ich den Effekt zumindest in wenigen Sekunden soweit bekomme, dass der Stack

• mehrere Sekunden lang aussetzt und die Servos danach die Befehle "nachholen" (das würde ich gerne mal auf Video aufnehmen ...).
  Das die Servos die Befehle nachholen deutet darauf hin, dass die Befehle in einem Netzwerkpuffer (auch dem Socket-Puffer) oder im Puffer der WLAN-Ext. stehen und dann verarbeitet werden.
  
• der Client eine TimeoutException bekommt
  
• der Stack danach meist per WLAN nicht mehr ansprechbar ist und neu gestartet werden muss, weil eine Exception beim erneuten Connect kommt:
  Exception in thread "main" java.io.IOException: Connection failed: Keine Route zum Zielrechner
  Über USB ist der Stack dann meist noch ansprechbar!
   
  
• Oder ich kann noch connecten, aber der enumerate liefert nichts mehr zurück. Über USB geht es dann oft noch!
  

Was ich leider nicht geschafft habe: dass der Stack von alleine neu bootet.

Einmal kam eine "kaputte" Response, die zu dieser Exception geführt hat:

Exception in thread "Brickd-Receiver" java.lang.ArrayIndexOutOfBoundsException: 5
at com.tinkerforge.IPConnection.getFunctionIDFromData(IPConnection.java:760)
at com.tinkerforge.IPConnection.handleResponse(IPConnection.java:676)
at com.tinkerforge.ReceiveThread.run(IPConnection.java:102)

In Summe schicke ich hier recht schnell Befehle zum Stack.

Der Testaufbau benötigt:

- Masterbrick mit WLAN

- Step-Down-Power Supply

- Servobrick (Servos müssen nicht dran hängen, mit Servo auf Kanal 0+1 sieht man's aber besser)

- 1 Ind. Quad Relais

- 1 Ambilight Sensor (müsste auch ohne gehen)

Ich werde noch versuchen, das Testprogramm direkt auf dem Tablet auszuführen und den Stack als Access Point zu konfigurieren. Dann ist weniger Netzwerkhardware dazwischen, die das beeinflussen kann.

test.zip

Da ich leider immernoch sporadische Reboots und Hänger des Stack habe noch ein paar Zwischenergebnisse:

• Das Problem tritt nur auf, wenn ich den Stack per WIFI verbinde
  
• Ist der Stack per USB angeschlossen und der Client kommuniziert mit dem brickd, habe ich den Absturz gar nicht, auch nicht sporadisch.
   
  

Das hilft für eine genaue Fehleranalyse leider nicht weiter, verstärkt aber die Vermutung, dass noch im Bug im WIFI-Code versteckt ist.

Hast Du in der Zeit Aktivität (wenn ja, wie viele Requests) oder ist der Stack einfach "idle"?

Die ganze Kommunikation findet nur über die WIFI-Extension statt, das können ca. 50-100 Messages / Sekunde sein. Und der Fehler ist leider sehr sporadisch: ich hab schon mal nach nur 300 Servo-Commands plus weniger Bricklet-Status-Abfragen den Stack zum Absturz gebracht (reboot), dann bekomme ich auch wieder weit über 15.000 Commands durch, ohne Probleme ... Der Effekt ist immernoch ähnlich wie der aus diesem Thread http://www.tinkerunity.org/forum/index.php/topic,1339.msg8469.html#msg8469.

Eine andere evtl. nützliche Meldung ist noch das hier:

[drivers/usb/USBDDriver.c:550]: (warning) memset() called to fill 0 bytes of 'pInterfaces'.

Das dürfte aber auch nichts mit meinem Problem zu tun haben.

Ich habe das Gefühlt, dass im WIFI ein noch Overflow bei hoher Last passiert (wegen den Stack-Reboot). Ich werde den Test-Stack über USB anschließen und dann länger so testen. Wenn dann kein Fehler mehr auftritt, könnte das noch mehr in Richtung WIFI deuten. Viel helfen wird diese Erkenntnis für die Fehlerbehebung leider nicht ...

Hallo Admins,

ich habe leider immernoch das Problem, dass mein Stack ab und zu hängt (d.h. für mehrere Sekunden nicht reagiert, Client bekommt Timeout), dann wieder reagiert (auf einmal werden sogar die Servo-Befehle nachgeholt obwohl der Client schon disconnected ist und die Servos werden "hektisch") und sehr sporadisch bootet der Stack dann auch von alleine neu ...

Darum habe ich Teile des Codes mit "cppcheck" durchforstet.

CppCheck wird in der Bricklib fündig:

[com/spi/spi_stack/spi_stack_slave.c:166]: (error) Array 'spi_slave_pins[2]' accessed at index 3, which is out of bounds

Die Meldung sieht korrekt aus: das Array hat nur 2 Elemente, der Index ist aber 3 => 2 Elemente übers Ziel hinaus.

Ich habe nur Master-Brick, Servo-Brick, Ambilight und Quad-Relay damit geprüft und das war die einzige Meldung. Die Funktion wird in diesen Modulen jedoch nicht aufgerufen => vermutlich kein Problem.

Nur als Info, vielleicht schaut Ihr Euch das mal an.

Ich versuche weiter, mein Problem mit einem Testfall zu reproduzieren 

Das APK bekomme ich nicht ins WIKI, es kommt immer der Fehler

File extension ".apk" does not match the detected MIME type of the file (application/zip).

Das kommt, wenn ich das APK nochmal zippe (.apk.zip), aber auch, wenn ich das APK (was ja ein zip-File ist) nach '.zip' umbenenne. Die Meldung wundert mich insbesondere beim einfachen Umbenennen.

Habt Ihr eine Idee?

Da ich auch noch ein Dual-Relais daheim habe ...

Folgendes ist auf jeden Fall möglich:

• Dual Relais bekommt einen Monoflop Impuls zum Ausschalten für 10 Sekunden (wenn es aktuell aus ist, bleibt es weitere 10 Sekunden aus)
  
• wird dieser Impuls nicht innerhalb von 10 Sekunden wiederholt, schaltet das Relais eigentständig ein, das steuert das Bricklet selber
  
• wenn hierüber ein Hardware-Reset des Servers gesteuert wird, sollte der Reset klappen. Einen Software gesteuerten Reboot würde ich wohl gar nicht erst versuchen
  

Mögliche Probleme:

• Wenn sich der Kernel aufhängt, dann sollte der Impuls ausbleiben, weil hoffentlich die Anwendungen dann auch einfrieren, garantiert ist das aber nicht.
  
• Ob beim Reset des Servers, auch die USB-Stromversorgung und damit der Stack resettet wird müsste mit der entsprechenden Hardware getestet werden.
  

Vielleicht hilft das nicht bei jeder Fehler-Konstellation, aber ein Ansatz ist es schon. Da sich der Aufbau nicht so schwer anhört würde ich es einfach mal ausprobieren.

Bei dem Ansatz verlässt Du Dich darauf, dass der Stack neu gestartet wird, wenn der Rechner neu bootet - oder?

Ich habe bei meinem Desktop PC schon mal festgestellt, dass die USB-Verbindung noch Strom abgibt, wenn der Rechner ausgeschaltet wird - ich konnte problemlos noch ein Headset oder Handy laden. Das wäre bei Dir aber gerade das, was Du nicht haben willst.

Du kannst es recht einfach testen:

Stack an den Rechner anschließen, Dual-Relais über den Brickv "einschalten" und den Rechner per Menü neu starten. Wenn der Stack dann auch neu bootet müsste Dein Vorhaben klappen.

Viele Grüße

Dem kann ich mir nur anschließen: macht echt was her!

Ein weiteres Bild - mal beides zusammengefasst und aktuelles Bild der Steuerung.

Wie kann ich eigentlich direkt über das media-Wiki neue Bilder hochladen? Da habe ich nichts gefunden. Im Forum geht das.

Die Seite habe ich schon gesehen - kann ich auch erweitern.

Da das aber ein paar Stunden in Anspruch nimmt kann das schon ein paar Tage dauern.

Does your AccessPoint also has a DNS server included?

And do the network clients use your AP as DNS server?

If not, setting only the hostname in the WIFI extension will not help.

My FritzBox is also a DNS server. In this case the WIFI ext. registers at the FritzBox AP with the given hostname, the Fritzbox also adds the name + the IP to its DNS mapping.

All network client in my network use by FritzBox as DNS server, so I can connect to any other WIFI device using the hostname with was defined during WIFI connect - this was really easy, but a DNS server in the AP is a must have I think.

Ich habe mich nicht informiert, was solche Hardware kostet: bei unter 30€ würde ich nicht nachdenken und sofort kaufen. Bis 50€: ja geht noch, würde ich wohl ausprobieren; bei mehr würde ich genauer überlegen, wo und wie ich den einsetzen will. Hat aber diverse Vorteile gegenüber den IRs, irgendwann kommt man nicht dran vorbei ...

Das lässt sich machen. Kommendes Wochenende kann ich mal etwas knipsen.

Viele Grüße

Ich kann jetzt nur sagen, wie es bei mir auf Windows7 schon x-mal funktioniert hat:

- aktuellen brickd mit aktuellem USB-Treiber verwenden

- ebenso aktuellen brickv nutzen

- Masterbrick an USB anschliessen

- Erase + Reset Button gleichzeitig drücken

  => blaue LED geht aus.

- USB trennen, 5 Sekunden warten und neu verbinden

  Blaue LEDs bleiben aus! Das ist Dein aktueller Stand.

- der Rechner sollte nach einer Weile ein Device erkennen

- brickv starten und "updates flashing" clicken

- es sollte als Device eine Art „GPS Camera Detect” angezeigt werden

  (wie in Doku beschrieben) - hat bei mir immer geklappt.

- das kann man dann flashen

Da bei Dir beim Anstecken die blauen LEDs schon aus sind, ist der Brick schon im passenden Modus. Dann sollte bei passendem Treiber+brickd im Brickv auch das GPS Device fürs flashen angezeigt werden.

Du schreibst, dass das Brick gefunden wurde - in welcher Form?

Hallo Bastian,

das könnt Ihr verlinken, kein Thema.

Bzgl. Bilder: vom kompletten Innenaufbau im Fahrzeug?

Kann ich bei Gelegenheit machen.

Viele Grüße

Dann passt das Quad Relais bei Dir eigentlich sehr gut: damit kannst Du mit einem Befehl die 4 Schalter der Fahrtregler gleichzeitig schalten. Das Relais kann pro Schalter etwas mehr als 1A, das reicht für den Schaltkontakt der Regler auf jeden Fall.

Viel Spaß 

Noch eine Frage interessehalber:

Du treibst den Schlitten über einen Motor mit Fahrtregler an und das ServoBrick steuert den Fahrtregler? Oder machst Du nur Motor ein/aus?

Je nach Fahrtregler reicht es nämlich, die Signalleitung vom Servobrick per Relais zu unterbrechen. Dann schaltet der Fahrtregler ab. Der Mechanismus geht analog wie vorher beschrieben über die Monoflop-Funktion. Zur Trennung der Steuerimpulse reicht aber auch das Industrial Quad Relay. Das braucht auch weniger Strom.

Bei Anschluß eines Fahrtreglers mit BEC ans ServoBrick den Hinweis von TF bei der Beschreibung der ServoBrick beachten ...

Bzgl. Winkel und Störungen durch anderes Licht wäre der sicher besser. Wenn der Motor die Übertragung stören sollte, dann würde das den anderen Sensor ggf auch beeinflussen.

Meine "Teststrecke" wird durch kleine Halogenstrahler von der Decke her beleuchtet. Der Fussboden könnte auch etwas reflektieren. Allerdings ist der Sensor horizontal ausgerichtet und bekommt zumindest kein direktes Licht ab.

Hallo,

ich habe gerade in mein Modellfahrzeug noch einen Distance-IR eingebaut und den so ins System eingebunden, dass der Fahrtregler eine Vollbremsung auslöst, wenn ein bestimmter Schwellenwert des Distance-IR unterschritten wird. Dazu nutze ich den "DistanceReachedListener".

Funktioniert eigentlich recht gut, sogar mit dynamischem an die Geschwindigkeit angepassten "Bremsweg"  .

Ein Problem habe ich leider doch : das Modell macht nun ab und zu sporadisch eine Vollbremsung, ohne dass etwas vor dem Sensor ist. Etwas löst den Callback aus.

Meine Vermutung sind evtl. Störungen auf dem Bricklet-Kabel: ich verwende ein 50cm Kabel ohne Schirmung. Das Geschirmte bekomme ich leider nicht verlegt - ist zu dick. Das Kabel passiert auch den Motor (der hat Entstörkondensatoren). Könnte der Motor dennoch eine Störung auf das Kabel bringen, wodurch der Callback ausgelöst wird?

Oder könnten ggf. bestimmte Reflexionen auch den Callback auslösen?

Danke für den Hinweis, dann muss ich nichts mehr tun.

Hallo,

ich habe einen DistanceReachedCallback (in Java) aktiviert in etwa in der Art

ir.setDebouncePeriod(500);
ir.setDistanceCallbackThreshold('<', (short)minDistance, (short)0);
ir.addDistanceReachedListener(this);

Der wird auch korrekt aufgerufen, allerdings immer 2x, mein Protokoll sieht so aus:

07:57:37.917: W/System.err(2188): Set callback for distance 100
07:57:46.168: W/System.err(2188): Distance-callback call #1
07:57:46.168: W/System.err(2188): Distance-callback call #2
07:57:46.668: W/System.err(2188): Distance-callback call #3
07:57:46.668: W/System.err(2188): Distance-callback call #4
07:57:47.498: W/System.err(2188): Distance-callback call #5
07:57:47.508: W/System.err(2188): Distance-callback call #6
07:57:48.008: W/System.err(2188): Distance-callback call #7
07:57:48.008: W/System.err(2188): Distance-callback call #8
07:57:48.558: W/System.err(2188): Distance-callback call #9
07:57:48.558: W/System.err(2188): Distance-callback call #10

Der Zeitstempel zeigt, dass der Callback immer 2x aufgerufen wird, der Callback-Zähler geht entsprechend hoch. Bei Aufruf 5+6 war parallel noch Servo-Aktivität, wodurch sich der Aufruf dann ninimal verzögert, aber dennoch kommt. Zwischen 4 und 5 war der Abstand wohl kurzzeitig über dem Minimum.

Soll/muss das so sein oder muss ich noch etwas anderes setzen, damit der Callback alle 0,5 Sekunden 1x aufgerufen wird?

The latest firmware allows to set a hostname to the WIFI extension, so it is even easier to distinguish the stacks if you have more than one in a network. You don't need to know the "gainspana.." number any more if you set a hostname via brickv.