Tipsy Tinker

Hey, das habe ich vermutet und leuchtet auch ein. Gleiches wird es wohl mit z.B. Numpy und ähnlichem sein, bzw den Paketen die auf dem RED (vor-) installiert sind. Die Pythonversion ist nicht das eigentliche Problem.. eher die Spyder Version.. und daraus resultierend der entsprechende Kernel... Nunja. Dankeschön schonmal

Hey Tinkerforge Community, das Zusammenspiel der Python Versionen sowie Varianten von Bibliotheken, Kernels in Spyder und Interpreter oder Virtual Envoirement und was weiß ich nicht noch alles verwirrt mich. Ich benötige also mal Nachhilfe, um da etwas Licht in´s Dunkel zu bringen. Wenn ich ne Python File auf dem RED-Brick ausführen möchte, lade ich Sie mittels Brickviewer dort hoch und wähle Python 3.5.3 im Tab Python Configuration im Brickviewer. Was passiert, wenn ich dieses Python Skript in Spyder mit Python 3.7.9 geschrieben habe und dann hoch lade? Funktioniert das trotzdem? Abwärtskompatibilität? Wie ist das Zusammenspiel mit anderen Python Versionen? Kann da jemand was zu sagen? (Und weiß jemand zufällig, wie ich Spyder dazu bringe, mit Python 3.5.3 zu arbeiten? Also in welchem Spyder-Kernel die unterstützung für 3.5.3 steckt? Krieg da nichts zu gegoogelt) Vielen Dank, Gruß Tipsy

Moin, Ja, das konnte ich reproduzieren. Hatte ich in einem anderen Post von Dir schonmal wo gelesen. Mein Problem konnte ich lösen, in dem ich set_sensor_fusion_mode(0) gewählt habe. Hatte zunächst set_sensor_fusion_mode(2) versucht, allerdings hat das ja, wie oben beschrieben keine Abhilfe geschaffen. Hat wohl nicht ausgereicht, das Magnetometer abzuwählen. Die Verwendung von unkalibrierten und unkompensierten Sensorwerten genügt wohl im dargelegten Anwendungsfall. Im Zeitlupenvideo kann ich diese nicht erkennen. Naja, jetzt passt es ja. :) Trotzdem vielen Dank! Gruß Tipsy

Hallo Zusammen, Ich hatte für ein studentisches Projekt auch den Versuch unternommen, mittels des IMU Bricks eine Rotationsbewegung aufzuzeichnen und kämpfe scheinbar mit einer Art Sensordrift, den ich aber mit imu.SetSensorFusionMode(2) wie hier vorgeschlagen, nicht wegbekomme. Am orangen Graph der ermittelten Daten erkennt man das recht gut. Die Werte der Drehbewegung laufen nach dem Nulldurchgang wieder ins Positive, was ja bedeuten würde, dass Real eine Art "Wendung" stattfindet. Allerdings ist real der Bewegungsablauf abgeschlossen. Die Beschleunigungswerte (blauer Graph) und die visuelle Beobachtung entsprechen dem. Den Versuchsaufbau habe ich mal vereinfacht dargestellt. Die Bewegung von Pos. 1.) nach Pos. 2.) soll aufgezeichnet werden. Nach dem Ablauf werden aber weiter Werte aufgezeichnet, die gegenläufig sind. Sind das eigentlich die gleichen Werte, die den IMU in der 3D Anzeige des Brickviewers weiter drehen lassen, wenn er nach dem rumspielen wieder ruhig liegt? Und könnte ein Zusammenhang mit der Kalibrierung, bzw. automatischen Dauerkalibrierung bestehen? Vielleicht hat wer einen Tip, was man prüfen könnte? Gruß Tipsy

Ok, scheint soweit geklappt zu haben 🙂 Selten lagen Verwunderung und Firmware-Update so nah beieinander *gg* Vielen Dank auch für Deine Ausführungen zu den Ticks. Gruß Tipsy

Hallo Zusammen, kann jemand sagen warum folgender Code kein Temperaturwert für die Kerntemperatur des IMU 2.0 Bricks zurück gibt? #!/usr/bin/env python # -*- coding: utf-8 -*- HOST = "localhost" PORT = 4223 UID = "6rGa5o" import time from tinkerforge.ip_connection import IPConnection from tinkerforge.brick_imu_v2 import BrickIMUV2 Liste = ["X","X","X","X","X","X"] def cb_quaternion(w, x, y, z): Liste[1] = (w/16383.0) Liste[2] = (x/16383.0) Liste[3] = (y/16383.0) Liste[4] = (z/16383.0) def cb_temperature(temperature): Liste[5] = temperature def main(): ipcon = IPConnection() imu = BrickIMUV2(UID, ipcon) ipcon.connect(HOST, PORT) imu.register_callback(imu.CALLBACK_QUATERNION, cb_quaternion) imu.register_callback(imu.CALLBACK_TEMPERATURE, cb_temperature) imu.set_quaternion_period(100) imu.set_temperature_period(100) time.sleep(1) i = 0 while i < 20: Liste[0] = i print("Übersicht Werte in Liste:") print("Wert 1:" + str(Liste[0])) print("Wert 2:" + str(Liste[1])) print("Wert 3:" + str(Liste[2])) print("Wert 4:" + str(Liste[3])) print("Wert 5:" + str(Liste[4])) print("Wert 6:" + str(Liste[5])) print("") i = i+1 time.sleep(0.5) ipcon.disconnect() if __name__ == "__main__": main() Benutze ich cb_all_data wie in den Beispielen gezeigt, kommt der Temperaturwert mit. Möchte ich ihn einzeln haben, so wie hier in meinem Beispiel, bekomme ich ihn nicht aufgerufen. Vielleicht hat jemand ne Idee, woran das liegen könnte?! Hintergrund ist, das mein IMU regelmäßig aussteigt, und ich die Vermutung habe, dass ihm ein bisschen zu warm ums Herz ist 😉 Das führt mich zu einer weiteren Frage: Gefühlt gibt es ein Performance-Unterschied zwischen: Alle Werte per Callback erheben, diejenigen die ich benötige loggen zu: Nur diejenigen per Callback erheben und loggen, die ich benötige liege ich da richtig? Und wenn ja, was sind so die gängigen Tricks und Kniffe, um ein möglichst hochfrequentes Loggen von spezifischen Werten zu realisieren ? Vielen Dank an alle Tinkerforger da draussen :) Grüße Tipsy

👍

Hey :) Vielleicht liegt hier ein Missverständniss vor. Wenn der Stapel samt RED komplett und gebootet ist, gibt es unter RED eigene Tabs zur IP-Konfiguration. Diese müssen entsprechend passend zum restlichen Netzwerk konfiguriert sein. Hilft das weiter? Grüßle

Hi ! Bei meinen Projekten komme ich immer wieder an den Punkt, an dem ich mir eine Art "Leerbrick", also quasi einen Spacer wünsche, der mir verschiedene Handlungsfreiräume bietet. Kabeldurchführung, Verschraubungen unter dem Brickstapel zugänglich machen, Abstandshalter-Funktion oder gar mit einem Lüfter aufgerüstet sind nur ein paar Ideen. Ich stelle mir in etwa sowas wie in meiner Skizze vor. Toll wäre noch ein ausleiten von 5V auf 2 Lötpunkte, damit man zB. einen Lüfter versorgen könnte. Somit könnte man zB. seinen RED kühl halten, oder Abwärme von den PoE´s weg schaffen. Zusätzlich sind Befestigungsösen für zB. Kabelbinder o.Ä. vorgesehen. Ich habe mal 2 Varianten entworfen: Spacer "Frame" im Standard Tinkerforge Formfaktor Spacer "light" wobei man da pro Ebene jeweils 2 Stück einsetzt. Diese sind wechselseitig verwendbar. Natürlich ist zwingend erforderlich, das die Brick-Connectoren durchgeschleift werden. Interessant wäre für mich auch ein Element, welches die Brick-Connectoren jeweils versetzt trägt und somit ermöglicht, Bricks innerhalb eines Stapels um 90° zu drehen. Hat man sowas schon mal in Erwägung gezogen? Tendenziell würden es für einige Anforderungen auch Brick-Connector Aufsätze in entsprechender Länge tun. Vielleicht kann jemand Auskunft geben, oder Communitymitglieder haben Lösungsvorschläge 🙂 Gruß Tipsy

Genau, aber ich raffe noch nicht, wie ich mit dem Script auf den Alarm reagiere. def main(): ipcon = IPConnection() rtc = BrickletRealTimeClockV2(UID_Clock, ipcon) led = BrickletRGBLEDV2(UID_Led, ipcon) ipcon.connect(HOST, PORT) led_green(led) time.sleep(1) led_red(led) rtc.set_alarm(-1, -1, -1, -1, -1, -1, 5) ### led_green(led) ipcon.disconnect() Vielleicht könnte mal jemand anhand des Codebeispiel zeigen, was an stelle ### stehen muss, damit die Led nach 5* Sekunden (oder eingestelltem Alarmwert) wieder auf grün schaltet. Ich hab da irgendwie grad nen Knoten. Die nächste Frage wäre, wie ich das parallel zum eigentlichen Programm bewerkstellige :) Vielen Dank. Grüßle Tipsy

rtrbt, vielen Dank für deine Eingaben. Hat mir sehr weiter geholfen. import subprocess subprocess.run(["sudo", "reboot"]) Hat direkt funktioniert, wird allerdings langfristig ein Sicherheitsproblem darstellen, schätze ich. Werd mal noch ein bisschen damit herum experimentieren, wäre schon nice das auf einen Alarm zu legen. Hab allerdings noch nicht so ganz raus wie ich auf den Alarm aus dem Skript heraus reagieren kann. Den Monoflop find ich großartig :) So naheliegend und doch so fern. Langfristig wirds der wohl werden.. 🙂 Grüßle Tipsy

Hallo Zusammen 🙂 Besteht die Möglichkeit, den RED Brick aus einem python-Script heraus zu rebooten? Wenn ja, wie ? Besteht die Möglichkeit, den Alarm aus dem "Real-Time Clock Bricklet 2.0" zu benutzen, um einen reboot auszulösen? Und aller guten Dinge sind 3: Besteht die Möglichkeit, irgendwie zu erkennen, das sich der RED aufgehängt hat, um ihn dann zu rebooten? Klingt irgendwie widersprüchlich, aber ihr versteht schon...🤣 Vielleicht hat wer Hinweise, wie ich diese Fragestellungen lösen kann, oder hat Recherchehinweise die mich weiter bringen. Grüßle, Tipsy

Der Allwinner10s ist das SoC des RED-Brick. Für die Ethernet Extension (mit/ohne PoE) steht hier auf Seite 60 : -40 bis +85°C

Hab grad nochmal in die Datensätze geschaut. Als max.Temp erreiche ich am Einsatzort des Humidty Bricklets 146 °C, im niedrigen Temperaturbereich bis zu 90% rel. Feuchtigkeit. Das hier verlinkte Allwinner 10s Datenblatt verrät auf Seite 47: -20 bis +70°C Aber ob das so für den RED-Brick im allgemeinen gilt ?! Es führt kein Weg vorbei, es muss gemessen werden. 😐

Jap, wird wohl notwendig sein noch zwei Thermocouple Bricklet mit rein zu hängen. Müsste dann immer zum Aufzeichnungende hin in den Daten erkennbar sein. Bisher habe ich die deutlich über Handwarme Temperatur aussen am Gehäuse festgestellt. Jetzt werden Tatsachen geschaffen. 🙂