Jump to content

remotecontrol

Members
  • Gesamte Inhalte

    625
  • Benutzer seit

  • Letzter Besuch

Alle erstellten Inhalte von remotecontrol

  1. Ja, der Effekt passt zum genannten Thread oder ist gar der Gleiche. Interessant ist für mich, dass nicht jedes Paket langsam ist, sondern nur jedes 2./3. Und im Massentest (wenn viele Pakete über die Leitung gehen) ist es nicht nachvollziehbar: der Durchschnitt ist im erwarteten Bereich (6-7ms) und somit OK. Das sieht für mich nach einem fehlenden "flush()" (oder Ähnliches) auf Brick-Seite aus. Ich habe den "flush()" mal in die IPConnection auf Anwendungsseite eingebaut. Das hat den Effekt nicht behoben.
  2. Hallo zusammen, ich habe ein Testprogramm, welches über einen Switch des Quad-Relay eine Leuchtdiode so lange einschaltet, wie ein Button in einer GUI gedrückt gehalten wird. Ist das Relais über einen Master per USB verbunden kann ich quasi "morsen": die Diode reagiert ohne merkliche Verzögerung. 3-4 Ein- / Ausschaltvorgänge pro Sekunde sind problemlos möglich, so schnell wie ich eben clicken kann. Per WLAN-Extension angesprochen reagiert das Relais träge: nur noch 1-2 Ein- / Ausschaltvorgänge pro Sekunde sind möglich. Man merkt eine erhebliche Verzögerung. Zum Schalten brauche ich einen "getValue()" und einen "setValue()" für das Relais. Der getValue() braucht per USB 1-2ms, per WLAN ca 6-7ms (so meine Messung im Massentest). Aber selbst 7ms würden locker ausreichen, um mehrmals pro Sekunde ohne merkliche Verzögerung zu schalten. Ein Trace gibt aus, dass jeder 2. oder 3. Schaltvorgang 180ms benötigt, die übrigen 6-8ms (wie erwartet). Kann man diese Verzögerung noch irgendwie erklären? Mir ist aufgefallen, dass die Methode IPConnection.write() keinen out.flush() beinhaltet (Java API). Ein out.flush() wird nur im Konstruktor der IPConnection aufgerufen, hier halte ich ihn nicht für notwendig. Theoretisch kann das dazu führen, dass Verzögerungen auftreten, gerade wenn wenig Datenpakete übertragen werden. Genauso "riskant" wäre es, wenn der Brick die Daten zurück sendet, ohne den Stream zu flushen. Dann kann die Response merklich langsamer werden. Anders kann ich mir nicht erklären, dass einzelne Pakete teilweise extrem langsam sind. Im Massentest fällt sowas nicht so auf, weil immer genügend Daten im Stream stehen, damit der dann gesendet wird.
  3. Hallo Administratoren, beim Industrial Quad Relay kann man aktuell beim setMonoflop jeden Switch einzeln ansteuern über eine Bitmaske, die angibt welche Schalter vom Befehl "betroffenen" sind. Beim setValue() geht das aber leider nicht. Der setValue setzt immer alle 4 Switches auf den angegebenen Zustand. Daher mein Verbesserungswunsch: zusätzlich zum setValue() noch ein setValue() welches auch eine Bitmaske akzeptiert und nicht immer zwingend alle 4 Switches auf einen neuen Zustand setzt. Das benötigt wohl neue Brickletfirmware. Mein Anwendungsfall: Ich wollte zwei Schalter als Monoflop verwenden und zwei andere "normal". Die kommen sich aber in die Quere: wenn der Monoflop aktiv ist (ein) und ich mit getValue() den Zustand auslese, dann ein weiteres Bit setze, dann wieder setValue() aufrufe => der Monoflop ist abgeschaltet und der eine Switch des Monoflop ist nun dauerhaft an. Außerdem brauche ich zwingend getValue() Aufruf, wenn ich nur ein Bit ändern will (getValue -> Bit ändern -> setValue). Mit einer anderen setValue-Funktion wäre das einfacher, der getValue kann entfallen und damit ein Befehlspaket. Wenn es ein setValue mit Bitmaske gibt, ist das Ansteuern einzelner Schalter effizienter: der getValue kann entfallen.
  4. Die Android API ist recht gut dokumentiert, aber auch recht umfangreich und ein Tablet (Mobiltelefon) ist eben kein PC. Da gibt es andere Systemdienste, die man auch erstmal kennen muss. Der Haupteinstieg ist http://developer.android.com/index.html. Darunter sind dann die API Beschreibungen. Weitere Beispiele habe ich in den Foren gesucht. Widgets gibt es relativ viele. Es ist dann eher so, dass ich das Verhalten noch etwas beeinflussen will, z. B. einen Button mit 3 oder mehr Zuständen & Symbolen gibt es im Standard so nicht, ist aber einfach zu realisieren. Das mit dem Thread-Handling wurde schon gut erklärt ("NetworkOnMainThreadException").
  5. Hallo Nic, die Umgebung läuft auch problemlos unter Windows. Ich habe das Projekt aus Linux ohne Änderung nach Windows kopiert, dort im Android-Eclipse importiert => läuft auch dort im Emulator. Nur ist der Emulator zum Testen eben etwas langsamer. Die Controls sind spezielle Android-Controls, kein AWT. Hier ist viel Android-API im Spiel und das kostet mich die meiste Zeit (bin kein Android Experte). Die Tinkerforge-API kann 1:1 verwendet werden. Mit dem Thread-Handling muss man etwas aufpassen. Ich habe keine Rücksicht auf ältere Android-Versionen oder Geräte kleiner 7 Zoll genommen. Ich setze erst bei Android 4.1 oder höher auf (Nexus 7, bzw. 10). Das macht es an ein paar Stellen etwas einfacher.
  6. Ich nutze die Standard-Android-Umgebung: Eclipse (Java) mit zusätzlichen Google-Tools. Ich arbeite meist unter Linux, auch wenn USB-Debugging dann nicht funktioniert. Der Geräte-Emulator läuft bei mir unter Linux Faktor 5 schneller als unter Windows - warum auch immer ...
  7. Ich habe daran in den letzten beiden Wochen gearbeitet, immer so ca. 3h pro Tag. Die meiste Zeit habe ich am Anfang damit verbracht, in Android-Foren nach spezifischen Problemlösungen zu suchen. Das Feintuning der Servosteuerung (damit z. B. nicht zu viele Befehle pro Sekunde übers WLAN gesendet werden) war auch aufwendig. Zuletzt habe ich z. B. eine Funktion ergänzt, um das Fahrlicht über Ambi-Light-Sensor automatisch einzuschalten, wenns zu dunkel wird. Das ging straight forward in ca. 1 Stunde. Testfahrten muss man dann aber auch noch machen ...
  8. Vielen Dank, das hilft mir weiter. 10x 500mA ist wohl deutlich mehr, als ich brauche. Um den Kabelsalat so gering wie möglich zu halten werde ich erstmal keine separate Leitung legen.
  9. Mit dem ausgetauschten Sensor lässt sich ein automatisches Licht jetzt sehr schön steuern: fährt ein Fahrzeug in einen dunklen Bereich reagiert der Sensor 'korrekt' => Fahrlicht kann eingeschaltet werden. Fährt es aus dem dunklen Bereich raus und es bleibt hell für mehrere meiner Messzyklen geht as Licht wieder ein.
  10. In dieser Diskussion ist etwas zur Reaktionszeit beschrieben: http://www.tinkerunity.org/forum/index.php/topic,37.0.html Ich habe ein ähnliches "Problem" bei der Servosteuerung: ein Servobrick kann bis zu 7 Servos ansteuern, wobei ich davon quasi gleichzeitzig 4 ansteuere, also immer 4 Befehle über WLAN an den Stack sende, plus weitere Befehle, die von Sensoren abgeleitet werden. Bei mir reicht die Performance aus, ich hatte aber schon mal "WLAN-Hänger" für 1-2 Sekunden.
  11. Nachdem ich in den letzten beiden Wochen auch öfter Fragen in das Forum gestellt habe, möchte ich kurz vorstellen, was aktuell dabei rausgekommen ist: Eine Tablet basierte Fernsteuerung für RC Funktions-Modelle, die Kommunikation erfolgt über WLAN (Modell ist dann ein Access Point). Ich mache hier auch gleich die Einschränkung auf Funktionsmodelle, da sich alles andere nicht recht lohnt. Klassische Fernsteuerungen sind sehr zuverlässig, haben eine gute Reichweite und Reaktionszeiten. Bei der Steuerung vieler Einzelfunktionen wird es aber kompliziert. Eine programmierte Steuerung fürs Tablet kann man optimal auf die Bedürfnisse des jeweiligen Modells anpassen. Momentan ist das auch eher noch ein Softwareprojekt: 90% besteht aus Android-Programmierung. Die Bastelei am Modell momentan auch eher ein geringer Anteil. Mein Testaufbau zur Steuerung eines "THW Unimogs" mit Zusatzfunktionen nutzt aktuell - Step-Down-Power Supply - Masterbrick mit WLAN Extension - Servo Brick - Industrial Quad Relay Ergo: schon 11 Kanäle möglich bei dem einfachen Aufbau ... Um den Platz im Modell zu bekommen musste ich leider den Hebemechanismus der Ladefläche entfernen. Ich konnte die im Modell vorhandenen Fahrtregler aber wiederverwenden: alten Empfänger raus, Servos und Fahrtregler ans Servobrick anschließen: tut! Damit sind die Kanäle 1,2,3 (Lenkung, Antrieb und Seilwinde) versorgt. Noch ein kleines Soundmodul eingebaut und über Relais ein/aus, wobei auf dem Tablet eine Taste ist (Hupe), die das Relais nur schaltet, solange die Taste gedrückt ist. Dabei ist mir aufgefallen, dass der Fahrmotor Spannungsschwankungen (Brummen) ins System bringt und die Hupe bei Fahrt komisch "brummt". Ein Kondensator am Modul hat Abhilfe gebracht. Dann habe ich das Modul aber mal an den 5V Ausgang der Step-Down-Power Supply angeschlossen: tut auch - ohne extra Kondensator => Ausgangsspannung ist sehr konstant und Kanal 4 verbaut. Kanal 5 ist Fahrlicht ein/aus über einen weiteren Relais-Kontakt. Was noch kommt ist ein Suchscheinwerfer ein/aus (Kanal 6), der per Servo gedreht werden kann (Kanal 7). Und auf der Ladefläche wäre noch Platz für einen Kran... Die Servosteuerung kann per Benutzer-Einstellung eines Feintunings unterzogen werden - linear / exponentiell - Wegbegrenzer - Taste um den Steuerweg der Oberfläche z. B. auf nur 50% des Servoweges zu begrenzen: gut für sehr feine Steuerungen, per Click geht es dann zurück auf normale Steuerung. In Summe noch ein erster Test, wie zuverlässig das Ganze funktioniert: Kommunikationsabbrüche sind fatal, insbesondere dann, wenn das Modell in voller Fahrt ist und einfach weiter fährt . Was aber schon auffällt: auch hier ist ein "Testsystem für Trockenübungen" hilfreich, sonst muss man immer alles aus dem Modell ausbauen oder z. B. das WLAN umkonfigurieren, also ein zweiter identischer Stack wird notwendig. Anbei noch ein paar Bilder: im ersten die der Stack liegend im Modell zu sehen. Zuerst wollte ich die externe Antenne aufs Dach platzieren. Dann ist mir aber aufgefallen, dass es auch so geht. Aktuell reicht mir die Reichweite aus. Im zweiten Bild die Steuerung über ein Nexus 7 Tablet: das liegt recht gut in der Hand. Die grauen Kästen simulieren ein zwei-Wege Steuerung (z. B. links/rechts + vor/zurück).
  12. Hallo, eine Frage zur Stromversorgung: mein Stack wird über eine Step-Down Power-Supply versorgt. Die Stromversorgung am Eingang ist ein 9,6V Akku. Das Servo Brick zieht seinen Strom aktuell über den Stack. Ist es prinzipiell besser, wenn die Eingangsspannung über eine Y-Weiche am Akku auch direkt an das Servo-Brick angeschlossen wird? Das Servo-Brick regelt die Eingangsspannung ja selber auf die über Software eingestellte Spannung runter - oder? Damit würden dann die recht feinen Kontakte des Stacks nicht so belastet. Ein Servo kann bei Aktivität schon mal 300 mA ziehen. Wenn mehrere gleichzeitig aktiv sind, kann das auch mehr werden.
  13. Nachdem mir Tinkerforge einen neuen Sensor gesendet hat (vielen Dank!), ich zudem noch einen weiteren bestellt habe (== 3 Sensoren) und ich auch einen weiteren Master habe zeigt sich: * der alte Sensor zeigt 55 Lux an, geht bei Schatten auf 52 Lux runter, "rauscht" auch am neuen Master sporadisch (erst nicht, nach Nutzung eines 15cm Kabel dann doch wieder...) * beide neuen Sensoren zeigen jedoch nur 16-17 Lux an und gehen bei Schatten auf 8-9 Lux runter und rauschen nicht. => den alten werde ich dann wohl in die Tonne werfen.
  14. Vielleicht noch eine allgemeine Anmerkung bzgl. der WLAN Steuerung: wenn eine WLAN-Extension verwendet wird, ist es auch möglich, die Steckdose nur von "Zeit zu Zeit" via WLAN mit dem PC zu verbinden. Ansonsten hält das Relais einfach seinen Zustand, solange der Brick nicht von seiner Stromversorgung getrennt wird. Das klappt dann von jedem Rechner im WLAN Netz, auf dem die (selbst zu programmierende) Steuersoftware läuft. Die Steuersoftware kann z. B. beim Start den Zustand des Relais auslesen, dann kann man den Zustand ändern und das Programm wieder schließen und ggf. auch den Rechner ausschalten.
  15. Für eine "spätere" Version wäre toll. Ich hab' schon mehr als eine Extension ...
  16. Bei mir hat es auf zwei Arten funktioniert: 1) mittels Brickviewer + USB die WLAN-Extension auf mein lokales WLAN konfiguriert (WLAN AccessPoint / AP ist eine FritzBox), d.h. SSID + Key eingestellt und schon klinkt sich die Extension in mein Netz ein und ich kann von jedem Rechner aus zugreifen. Die IP vergibt die FritzBox (DHCP Host). 2) mittels Brickviewer die WLAN-Extension als AP konfiguriert, z. B. mit IP == Gateway == 192.168.100.1 plus Security Token. Beim Token muss man aufpassen: da dürfen nur Hex-Werte rein, also z. B. 12345678. IP und Gateway waren bei mir gleich. Dann muss der Client aber auch so konfiguriert werden, dass er diesen AccessPoint nutzt und der Client braucht auch eine statische IP (z. B. 192.168.100.2 und Gateway == AP == 192.168.100.1), da die WLAN-Extension kein DHCP Server ist. Wenn der Client einen WLAN-Browser hat, müsste er die Extension als AP erkennen (tut zumindest mein Android Tablet). Dann beim Connect aber: - statische IP - Gateway == IP der Extension - Security Token wieder so eingeben: 12345678 Wenn die gelbe LED an der Extension nicht dauerhaft leuchtet ist die Extension nicht mit WLAN verbunden. Wenn sie aus ist, dann die die COnfig fehlerhaft. Das war bei mir der Fall, als ich beim AP Modus den Key nicht hex eingegeben hatte, sondern mit Buchstaben.
  17. Ich hab die Steuerung gerade an ein erstes Fahrzeug gehängt: das Lenkservo zuckt beim Einschalten auch. Der Fahrtregler dieses (billigen) Modells scheint aber träger zu sein und das Fahrzeug macht beim Einschalten keine Bewegung vorwärts. Für das Modell also ausreichend. Aber gut zu wissen, dass es kein Einzelfall ist.
  18. Hallo, mein "Fernziel" ist es, ein RC Funktionsmodell mittels WLAN über mein Android Tablet zu steuern. Prinzipiell kann ich schon alle notwendigen Bricks / Bricklets übers Tablet mit spezifischen GUI Controls steuern: Servos, DC Brick, Relais ... Beim Servo habe ich aber noch ein Einschaltproblem: wenn der Stack an die Stromversorgung angeschlossen wird, macht mein Testservo eine kurze Drehung in eine bestimmte Richtung, bei jedem Einschaltvorgang etwa um den gleichen Winkel in die gleiche Richtung unabhängig von der aktuellen Stellung. D. g. 2x einschalten dreht das Servo dann 2x um einige Grad. Starte ich dann meine Anwendung, welche das Servo initial erstmal auf "0" stellt, geht es in die korrekte 0-Stellung zurück. Kann das am Servo liegen oder ist es möglich / tatsächlich so, dass das Servo Brick einen Einschaltimpuls gibt? Oder kann ich den per Software verhindern. Allerdings passiert das ja, bevor die Software Zugriff auf den Stack bekommt. Beim Servo ist das nicht dramatisch. Wenn ich aber einen Fahrtregler anschließen würde, wäre das nicht so gut, wenn das Modell gleich Power gibt. Viele Grüße
  19. Vielen Dank. Ich wollte eh noch was bestellen, dann schicke ich nach der Bestellung noch eine Mail. Einen schönen Abend noch.
  20. Dadurch ergibt sich keine Änderung. Das "Rauschen" entsteht erst, wenn es dunkler wird, z. B. durch einen großflächigen Schatten (30x30cm und der Sensor liegt in der Mitte). Ich habe mal einen Screenshot vom Brickviewer angehängt, wie die Kurve dann aussieht. Da wo es unruhig wird lag der Sensor im Schatten (Licht ausschalten erzeugt ähnlichen Effekt). Wenn ich die Beschreibung korrekt gelesen habe, dann wechselt der Senor je nach Helligkeit zwischen drei unterschiedlichen Bereichen. Vielleicht ist die Helligkeit gerade so, dass der analoge Wert an der Grenze liegt, und der Bereich zu oft gewechselt wird. Kleiner Nachtrag: als Stromversorgung nehme ich mal 7,2V Akku (+WLAN, DualRelay und Display) oder USB Verbindung. Der Effekt ist der Gleiche.
  21. Das Zimmer wird über zwei Energiesparlampen beleuchtet, keine LED. Richte ich zusätzlich eine kleine grüne LED auf den Sensor (ca 5cm Abstand), dann geht der Wert um ca 3 Lux hoch, fängt dadurch nicht an zu schwanken. Ich teste heute mal, wie sich der Sensor bei Tageslicht verhält.
  22. Hallo Administratoren, die WIFI Extension find ich prinzipiell super, habe aber noch einen Verbesserungsvorschlag: den Hostnamen, mit dem sich die Extension im DHCP-Modus beim DHCP-Server anmeldet, sollte man konfigurieren können. Aktuell meldet sich meine Extension mit "GainSpana01343" an. Ich hoffe, dass die Nummer hinten eine Art Seriennummer ist, d. h. wenn ich mehr als eine Extension im Netz habe, die Zweite einen anderen Namen hat. Dennoch wäre es hilfreicher, wenn ich den Extensions einen eigenen Namen zuordnen kann. Dann ist das korrekte Erkennen einfacher. Viele Grüße
  23. Hi, beim Ambilight Sensor habe ich ein größeres Rausch-Problem: liegt der Sensor ruhig bei Zimmerlicht auf dem Tisch ist der im Sekundentakt über getIlluminance() ausgelesene Wert recht konstant (~500-600). Wird es aber dunkler im Raum, fängt er extrem an zu rauschen. Je dunkler, umso stärker scheint das Rauschen zu sein. Die Werte springen dann zwischen 100 und 1200 (10 und 120 Lux) hin und her. Auch mit Mittelwertbildung über mehrere Sekunden wird es schwierig, mit einem Schwellwert z. B. ein Relais zu schalten. Ist das ein generelles Problem des Sensors? Oder muss ich noch was beachten? Firmware ist auf dem aktuellen Stand. Viele Grüße
×
×
  • Neu erstellen...