photron

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.

Also, ich bin jetzt mit der ersten Implementierung durch. Es wird folgendes neu geben: - Date/Time und Timestamp Callback für die beiden Getter entsprechend dem Muster des GPS Bricklets: set_date_time_callback_period(uint32 period) get_date_time_callback_period() -> uint32 period CALLBACK_DATE_TIME -> uint16 year, uint8 month, uint8 day, uint8 hour, uint8 minute, uint8 second, uint8 centisecond, uint8 weekday set_timestamp_callback_period(uint32 period) get_timestamp_callback_period() -> uint32 period CALLBACK_TIMESTAMP -> int64 timestamp - Alarmfunktion nach cron Vorbild: set_alarm(int8 month, int8 day, int8 hour, int8 minute, int8 second, int8 weekday) get_alarm() -> int8 month, int8 day, int8 hour, int8 minute, int8 second, int8 weekday CALLBACK_ALARM -> uint16 year, uint8 month, uint8 day, uint8 hour, uint8 minute, uint8 second, uint8 centisecond, uint8 weekday, int64 timestamp Damit kann man jetzt z.B. einen wiederholenden Alarm für jeden Samstag um 15:36 Uhr einstellen: set_alarm(-1, -1, 15, 36, -1, 6) Die -1 für Monat, Tag und Sekunde besagt, dass Monat, Tag und Sekunde egal sind. Der Alarm Callback wird ausgelöst, wenn sich an einem Samstag (6) die Uhrzeit von 15:35 Uhr auf 15:36 Uhr ändert. Der Alarm Callback gibt dann Datum und Uhrzeit (plus Zeitstempel) zurück zu dem der Alarm ausgelöst wurde. Um den Alarm zu deaktivieren ruft man set_alarm() mit -1 für alles auf: set_alarm(-1, -1, -1, -1, -1, -1) Entspricht das den Vorstellungen? Jetzt es ist noch früh genug da noch Änderungen zu machen.

FlyingDoc, leider noch nicht. Tests laufen noch.

Can you describe your setup in more detail? What Bricks and Bricklets do you have and and how are they connected?

Nic, es geht mir nicht darum dem Nutzer Funktionalität vorenthaltenen, oder das etwas nicht machbar wäre. Es geht mir darum zu verstehen warum du diesen Callback verwenden willst, was da der Nutzen für dich ist, warum das besser/einfacher ist als ein Timer aus der Stdlib deiner Programmiersprache. Damit ich da am Ende die beste Lösung für heraus kristallisieren kann. Also, die nächste Softwareversion für das RTC Bricklet wird einen Date/Time Callback wie das GPS Bricklet bekommen und eine set/get_alarm Funktion mit Alarm Callback. Vielleicht bekomme ich beim Alarm auch noch ein Feld für den Wochentag unter. Das gibt der IC zwar nicht direkt her, aber das könnte vielleicht durch Kombination zweier Funktionen des ICs möglich sein, muss ich testen.

Der periodische Callback des RTC Bricklets wäre nicht besser/genauer als jeder andere Callback. Das GPS Bricklet nutzt für die Taktung der Callbacks nicht die GPS Zeit und das RTC Bricklet würde dafür nicht die RTC Zeit benutzten. Dafür müsste in jedem Tick I2C kommuniziert werden, was nicht möglich ist. Oder willst du darauf hinaus, dass du den Date/Time Callback mit einer Periode von z.B. 1 Sekunde einstellt um dann z.B. Zeitspannen im Minutenbereich zu messen. Du also einfach jede Sekunde Prüfen kannst ob deine Minute schon rum ist. Das hat natürlich dann den Nachteil, dass du da lokal Ungenauigkeit reinbekommst, weil nicht definiert ist wann die Zeit den abgelesen wird. Für solche Kurzzeitmessungen ist meistens ein lokaler Timer am besten, fürchte ich. Jede Programmiersprache bringt dafür irgendwas mit, das für diesen Zweck besser funktionieren wird als das Real-Time Clock Bricklet. Es kommst aber auch darauf an was du machen willst. Wenn du über 100 Minuten hinweg insgesamt 100 Bilder aufnehmen willst, dann willst du möglicherweise keinen sich aufsummierenden Fehler den ein einfacher Intervalltimer hätte. Das Real-Time Clock Bricklet kommt dann zum tragen, wenn es um längere Zeiträume geht und keine andere Zeitquelle verfügbar ist. Zum Beispiel ein RED Brick oder ein Raspberry Pi ohne Internetanbindung. Beide haben keine eigene Real-Time Clock und halten ihre Zeit über den Prozessortakt. In diesen Fällen kann das Real-Time Clock Bricklet als bessere Uhr genutzt werden. Mit der möglichen set_alarm Funktion set_alarm(int8_t month, int8_t day, int8_t hour, int8_t minute, int8_t second) kannst du dir einen wiederholend Alarm für jeden Samstag um 15:36 Uhr bauen. Der nächste Samstag ist der 2. April, also den Alarm auf "2. April 15:36 Uhr" stellen set_alarm(4, 2, 15, 36, 0) Sobald der Alarm ausgelöst wurde kannst du ihn auf den folgende Samsatg, den 9. April einstellen set_alarm(4, 9, 15, 36, 0) usw.

Das was du das tun willst funktioniert auch mit Callbacks. Aber fang am besten erst mal einfach mit Gettern an: #!/usr/bin/env python # -*- coding: utf-8 -*- HOST = "localhost" PORT = 4223 UID = "qG8" # Change to your UID from tinkerforge.ip_connection import IPConnection from tinkerforge.bricklet_gps import BrickletGPS import time ende = 6.5 if __name__ == "__main__": ipcon = IPConnection() # Create IP connection gps = BrickletGPS(UID, 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 time.sleep(0.1) print("Summe", start) time.sleep(1) ipcon.disconnect() Mit ist nur nicht klar, warum du den speed aufsummieren möchtest bis die Summe 0,065 km/h erreicht hat.

Wir legen eine AG1 Batterie mit 1,55V und 20mAh (31mWh) bei. Der RTC IC auf dem Bricklet schaltet nur dann auf Batterieversorgung um, wenn wenn er nicht vom Brick versorgt wird. Der IC benötigt laut Datenblatt im Batteriemodus 1,06µW (typisch) bis 1,58µW (maximal): 31mWh / 1,06µW = 29250h (1291 Tage) 31mWh / 1,58µW = 19620h (817,5 Tage) Die Batterie sollte also mindestens für 2 Jahre ohne externe Stromversorgung reichen. Es gibt keine "Batterie Low" Abfrage, 1) weil der IC das so nicht kann und 2) weil es nicht einfach ist die Batterie zu messen ohne sie dabei auch deutlich zu entladen. Du kannst also entweder a) "Batterie Low" Abfrage haben oder b) eine deutlich längere Lebensdauer der Batterie. Wir haben uns für b) entschieden. Du kannst den Batteriehalter selbst als Lötpad verwenden, wenn es sein muss. Die Batterie sitzt recht stramm im Halter. Wenn du mit solchen Erschütterungen rechen musst, dass dir die Batterie abhanden kommt, dann ist das Abhandenkommen der Batterie nicht dein einziges Problem. In dem Fall kannst du das Bricklet z.B. auf eine Montageplatte schrauben und vor den Batteriehalter einen Bolzen setzen. Wir haben da nichts für vorgesehen, weil der Halter eben recht stramm sitzt und es das Bricklet in den allerallermeisten Fällen unnötig größer gemacht hätte. Das Real-Time Clock Bricklet ist dafür da die Zeit zu halten, wenn keinerlei andere Zeitquelle zur Verfügung steht. Zum Beispiel in einer Unterwassermessstation die Monate lang Messungen machen soll. Das System würde dann zwischen den Messungen eine Stunde schlafen und alles bis auf einen Watchdog abschalten, um Strom zu sparen. In diesem Fall hält das Real-Time Clock Bricklet die Uhrzeit, damit ich den Messungen nachher einen Timestamp zuweisen kann. Unterwasser kann ich weder DCF77 noch GPS empfangen, darüber hinaus ist DCF77 eine Deutsche Sache. Sicherlich ist das Real-Time Clock Bricklet nicht so genau wie DCF77 und GPS sein können, aber darum geht es beim Real-Time Clock Bricklet auch nicht unbedingt.

Einen Date/Time Callback nach GPS Vorbild können wir einbauen. Dessen Periode würde dann genau wie beim GPS Bricklet mit der internen Uhr des Bricks gemessen. Ein generischer Timer ist das schon schwieriger. Der IC auf dem Bricklet bietet aber eine Alarmfunktion bei der man einstellen kann zu welchem Datum und Uhrzeit sie ausgelöst werden soll: set_alarm(int8_t month, int8_t day, int8_t hour, int8_t minute, int8_t second) Das funktioniert dann nach dem Muster von cron unter Linux: set_alarm(4, 2, 20, 15, 0) Diese setzt einen Alarm für 20:15 Uhr am 2. April. Der Alarm würde dann per Callback mitgeteilt. Wäre das was? Oder was stellt ihr euch da vor?

Richtiges RS232 arbeitet mit bis zu +15V und -15V für 0 und 1. Es gibt dann noch RS232 für TTL mit 0V für 0 und +3,3V oder +5V für 1. Der MAX232 IC kann dazwischen umwandeln. Das RS232 Bricklet kann mit beidem umgehen, es hat so einen Umwandler-IC integriert. Wenn ich das richtig verstehe, dann spricht der MB7369 vereinfachtes RS232 mit +15V für 0 und 0V für 1. Die Beschreibung spricht da von Invertieren, weil RS232 +15V für 0 und -15V für 1 verwendet, RS232 für TTL 0V für 0 und +3,3V oder +5V für 1. Du solltest den MB7369 einfach an den D-Sub 9 Stecker oder die Schraubklemmen anschließen können. Du brauchst in keinem Fall einen MAX232 IC für die Verwendung mit dem RS232 Bricklet.