photron

Wir haben das gerade noch mal getestet und es funktioniert hier. Wenn der Stick nicht direkt im Mobile Internet Tab auftaucht, dann taucht er aber nach einem Klick auf den Refresh Knopf auf. Wir wird der RED Brick mit Strom versorgt? Was ist sonst noch am RED Brick angeschlossen? Ist der Stick direkt am RED Brick angeschlossen oder per Hub?

GMT-2? Wir haben hier eigentlich gerade GMT+2. http://wwp.greenwichmeantime.com/time-zone/gmt-2/ Does GMT-2 observe Daylight Saving Time? GMT-2 does not operate Daylight-Saving Time Ist also alles korrekt. Du hast einfach auf dem RED Brick eine Zeitzone eingestellt, die kein DST kennt. Du kannst über den Brick Viewer im RED Brick Settings Tab Uhrzeit und Zeitzone mit deinem PC synchronisieren. Dass sollte das Problem beheben.

TCP/IP funktioniert so leider nicht. Und auch das Disconnect Probe hilft da leider nicht so richtig. Was unserem TCP/IP Protokoll momentan fehlt ist ein richtiger Heartbeat um Verbindungsverlust in beide Richtungen zu erkennen. getConnectionState() sagt dir ob die TCP/IP Verbindung besteht. Das hat allerdings nicht damit zu tun ob du gerade auch Daten übertragen kannst, bzw. ob eine WLAN Verbindung besteht. TCP/IP ist absichtlich so entworfen worden, dass zwischendurch auch mal keine Daten übertragen werden können, weil die unterliegende Verbindung wie z.B. WLAN gerade nicht besteht. Deine " Echtzeit-ConnectionState Funktion" gibt es schon. du kannst einfach anstatt getConnectionState() abzufragen irgendeinen Getter aufrufen. Wenn dieser einen Timeout liefert, dann besteht die WLAN Verbindung gerade nicht.

Ja.

Das hat nichts direkt mit der Last zu tun. Okay, einmal in die technischen Details. Auf dem Bricklet ist ein IC der RS232 spricht und inter einen 60 Byte Lesebuffer für über RS232 eingehende Daten hat. Das Bricklet ließt diesen Buffer jede Millisekunden aus und schickt dir die Daten per Callback. Wenn deine 30 Byte vom RS232 IC so empfangen werden, dass er gerade die ersten 10 Byte in seiem Lesebuffer gespeichert hat, wenn das Bricklet ihn abfragt, dann bekommst du einen Callback mit diesen 10 Byte. Die restlichen 20 Byte bekommst du dann im nächsten Callback.

Die Abweichung aggregiert sich von Takt zu Takt. Du kannst die Abweichung einer Uhr recht einfach durch einen Faktor X beschreiben mit dem sie zu schnell oder zu langsam geht. Dieser Faktor X hängt von verschiedenen Einflüssen, wie Temperatur und Bauteiltoleranzen ab. Wenn der Brick mit seiner Uhr also 5 Minuten gemessen hat, dann waren dass in Wirklichkeit 5 / X Minuten. Wenn jetzt keine großen Temperaturänderungen auftreten, dann ist das für einen festen Aufbau recht stabil.

Du kannst mehrere Callbacks bekommen und musst die Daten wieder zusammensetzen. RS232 hat in dem Sinne ja erstmal kein definiertes Packetformat. Das Bricklet weiß also nicht wie deine Daten zu interpretieren sind. Der Callback wird sofort aufgerufen, wenn Daten empfangen wurde. Das Bricklet fügt da keine künstliche Verzögerung ein. Das Bricklet kann das nicht. Dafür wäre ein Zwischenspeicher auf dem Bricklet notwendig, der so nicht vorhanden ist. Das Bricklet sendet dir einfach alle empfangenen Daten so schnell wie mögliche. Jegliche Interpretation der Daten ist dann deine Aufgabe. Dadurch hast du die Flexibilität die Daten in jeglicher Weise zu interpretieren, ohne eine feste Vorgabe durch das Bricklet gebunden zu sein.

Warum ist -1 erwartungsgemäß? Ich würde erwarten, dass der PC weiss ob DST ist oder nicht. Hier von meinem PC: >>> import time >>> time.localtime() time.struct_time(tm_year=2016, tm_mon=4, tm_mday=7, tm_hour=9, tm_min=30, tm_sec=47, tm_wday=3, tm_yday=98, tm_isdst=1) Hier von einem RED Brick, dessen Uhr ein paar Tage daneben ist: >>> import time >>> time.localtime() time.struct_time(tm_year=2016, tm_mon=4, tm_mday=4, tm_hour=14, tm_min=32, tm_sec=24, tm_wday=0, tm_yday=95, tm_isdst=1) Was sagt denn date im Terminal dazu? PC: Do 7. Apr 09:34:31 CEST 2016 RED Brick: Mon Apr 4 14:38:14 CEST 2016 Das S in CEST zeit Sommerzeit an. Eigentlich sollte die Umstellung Winter-/Sommerzeit automatisch passieren, wenn du die Zeitzone richtige eingestellt hast.

Das würde man eher so machen. Die Beispiele haben verschiedene Abschnitte und man würde die Beispiele in ihre Abschnitte zerlegen und diese dann zusammenfügen: #!/usr/bin/env python # -*- coding: utf-8 -*- HOST = "localhost" PORT = 4223 UID_GPS = "qG8" # Change to your UID UID_IQR = "roq" # Change to your UID from tinkerforge.ip_connection import IPConnection from tinkerforge.bricklet_gps import BrickletGPS from tinkerforge.bricklet_industrial_quad_relay import BrickletIndustrialQuadRelay import time ende = 7 if __name__ == "__main__": ipcon = IPConnection() # Create IP connection gps = BrickletGPS(UID_GPS, ipcon) # Create device object iqr = BrickletIndustrialQuadRelay(UID_IQR, ipcon) # Create device object ipcon.connect(HOST, PORT) # Connect to brickd # Don't use device before ipcon is connected while True: start = 0 while start <= ende: course, speed = gps.get_motion() # speed in 1/100 km/h start = start + (speed/3600) time.sleep(0.1) print("Summe", start) iqr.set_value(0b1111) time.sleep(0.3) iqr.set_value(0b0000) ipcon.disconnect() Der sleep Aufruf hält das Programm (genauer gesagt den einzigen Thread des Programms) da an. Die Neuberechnung wird also auch angehalten. Damit das gleichzeitig laufen kann, kannst du entweder einen weiteren Thread benutzten, oder den Motion Callback des GPS Bricklets, der im Hintergrund auch in einem weiteren Thread ausgeführt wird. Du solltest dich wahrscheinlich erstmal zumindest kurz mit Threads und Nebenläufigkeit beschäftigen. Mit Threads kann man in einem Programm mehrere Dinge parallel ausführen. Du musst dazu in deinem Programm also den Zustand des IO-4 Bricklet Abfragen und dann entweder die Berechnung durchführen, oder weiter das IO-4 Bricklet abfragen. Dann ist der Brick im Booten stecken geblieben? Ist das eine SD Karte von uns? Wenn nicht, wie schnell ist beim lesen. Es kann Probleme mit sehr langsamen SD Karten geben. Wenn es dass nicht ist, dann versuch mal das Image neu auf die SD Karte zu schreiben.

There is no ready-made script for that, but you just need to combine existing examples for the two Bricklets to make that work.

I took a quick look at the code of this tinkerforge_laser_transform_node module and I think it should just work fine if you only have an IMU Brick 2.0 connected. But I've never used ROS, so I cannot be certain. You should probably just give it a try. You could also directly ask the author of the module about this.

Can you explain more detail what you did? Did you upload a bunch of class files or a JAR file? If you put your own code into a package, did you also put the class files into the correct directory hierarchy?

Firmware: DC Brick 2.3.1 Make setting velocity to 0 work while motor is disabled Download: DC Brick

Firmware: DC Brick 2.3.1 Velocity auf 0 setzen funktioniert jetzt auch, wenn der Motor deaktiviert ist Download: DC Brick

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.

Okay, that should not consume too much power at all. Does this stack work on another PC? Does it work if you use another USB cable to connect the Master Brick to the RPi? Does it work if you only connect the Master Brick to the RPi? Do you have any other USB devices or hats connected to the RPi? What does dmesg say? Connect the stack, then disconnect it from USB, then run dmesg > /tmp/dmesg-dump.txt and attach the /tmp/dmesg-dump.txt file here? There is no Color Bricklet case because it would be in the way in most setups because you need to get the sensor close to the object.

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

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.

Periode.

Wie genau die Zeitmessung der Bricklets ist hängt von vielen Faktoren ab. Für die üblichen Zeitspannen im Sekunden- bis mehrere Minutenbereich die bei Period-Callbacks und z.B. auch Monoflops zu erwarten sind ist die Zeitmessung der Bricklets hinreichend gut genug. Im Stundenbereich wirst du schon merkliche Abweichungen sehen. Daher meine Aussage, dass wenn du z.B. Callbacks zur vollen und halben Stunde über mehrere Stunden oder Tage hinweg haben willst, dann ist die interne Zeitmessung der Bricklets dafür nicht gut genug.

Das periodische Auslösen des Date/Time Callbacks wird mit der ungenauen Uhr des Bricks gemessen, nicht mit der genaueren Uhr des Real-Time Clock Bricklets. Genau so wie beim GPS Bricklet nicht die GPS Uhr für das Auslösen des Callbacks benutzt wird. Deswegen sagte ich auch vorher schon dieser Callback ist von seiner zeitlichen Beschaffenheit nicht besser als jeder andere Period-Callback irgendeines anderen Bricklets. Sprich, wenn ich den Date/Time Callback auf 30 Minuten Intervall einstelle, dann wird dieses Intervall mit der ungenauen Uhr des Bricks gemessen. Diese Ungenauigkeit sammelt sich über die Zeit auf und die Callback drift recht schnell von seinem 30 Minuten Raster ab. Für die Period-Callbacks ist das normalerweise kein Problem, da diese üblicherweise viel kürzere Intervall verwenden und auch nicht so auf Genaugkeit angewiesen sind. Wenn ich aber einen Alarm zur jeder vollen und halben Stunden haben will, dann ist die Uhr des Bricks nicht gut genug. Bei set_alarm(-1, -1, -1, -1, -1, -1, 1800) wird das 30 Minuten Intervall mit der RTC Uhr gemessen, die viel genauer ist als die Uhr des Bricks. Damit kann ich erreichen, dass der Alarm Callback z.B. in einem recht festen 30 Minuten Raster immer zur vollen und zur halben Stunde aufgerufen wird.

repeat wäre nicht die Anzahl der Wiederholungen, sondern die Zeit in Sekunden zwischen den Wiederholungen. Ich nenne repeat um in interval. Wenn du das int32 interval Parameter auf -1 setzt, gibst du an, dass du keine automatische Wiederholung des Alarm in einem festen interval von X Sekunden haben willst, sondern nur dann einen Alarm haben willst, wenn du wenn das aktuelle Datum/Uhrzeit dem eingestellten Alarm entspricht. Um den Alarm abzustellen musst du dann set_alarm(-1, -1, -1, -1, -1, -1, -1) aufrufen. Mit set_alarm(-1, -1, -1, -1, -1, -1, 45) sagst du, dass dir das aktuelle Datum/Uhrzeit egal ist und du ab sofort einen Alarm alle 45 Sekunden haben willst. Mit set_alarm(4, 21, 13, 27, 59, -1, -1) sagst du, dass du einen Alarm am 21. April um 13:27:59 Uhr haben willst. Mit set_alarm(8, 17, 0, 0, 0, -1, 300) sagst du, dass du ab dem 17. August 00:00:00 Uhr alle 5 Minuten einen Alarm haben willst.

Equinox, so eine Art Alarm sieht der IC erstmal nicht direkt vor. Was ich aber wahrscheinlich machen kann ist der set_alarm Funktion ein int32 repeat (in Sekunden) Parameter geben: set_alarm(int8 month, int8 day, int8 hour, int8 minute, int8 second, int8 weekday, int32 repeat) Wenn das gesetzt ist dann setzt das Bricklet selbst einen neuen Alarm sobald der erste ausgelöst wurde. Zum Beispiel: set_alarm(-1, -1, -1, -1, -1, -1, 5) dies löst 5 Sekunden nach Aufruf dieser Funktion einen Alarm aus. Dann setzt das Bricklet intern den nächsten Alarm auf den aktuellen Tag und Zeit plus 5 Sekunden. Wenn der Alarm also das erste mal am Samstag den 11.06. um 15:23:42 Uhr ausgelöst wurde, dann ruft das Bricklet intern set_alarm(10, 6, 15, 23, 42 + 5, -1, 5) auf, um den nächsten Alarm für in 5 Sekunden zu konfigurieren. Damit kannst du also einen wiederkehrenden Alarm einstellen. Darüber kann dann natürlich auch ein Alarm eingestellt werden, der das erste mal in 2 Tagen ausgelöst wird, dann aber alle 45 Minuten wiederholt wird.

kreaktiv, das funktioniert so nicht. Du gibst da keinen String an und ich kann und will auch Stunden und Minuten nicht auf einen Wert zusammenführen, denn dadurch geht Funktionalität verloren. Mit set_alarm(int8 month, int8 day, int8 hour, int8 minute, int8 second, int8 weekday) kann ich sagen set_alarm(-1, -1, -1, 5, -1, -1) was zu einem Alarm 5 Minuten nach jeder vollen Stunde führt. Das kann ich nicht mehr angeben, wenn Stunden und Minuten zu einem Wert zusammengeführt sind, denn dann muss ich auch immer die Stunde mit angeben. Die -1 wird bleiben, da geht kein Weg dran vorbei. Es wird aber eine Konstante dafür geben: ALARM_FIELD_DISABLED.

Ich kann 0 nicht nehmen, denn 0 ist ein gültiger Wert, z.B. für 00:12 Uhr muss hour auf 0 gesetzt werden. Daher -1 für alle Felder. Mehrere Wochentage sind nicht möglich. Der IC unterstützt nur einen Wert pro Feld.