AuronX

Genau so habe ich das verstanden. Du könntest das selbe Skript gegen einen brickd laufen lassen, weil die API identisch ist: Es macht also bei der Entwicklung keinen Unterschied (bis auf den eingeschränkten Interpreter) wo dein Skript läuft. Zur Erklärung: Eingeschränkter Interpreter heißt am Ende, dass dir irgendwann doch auf die Füße fallen wird, dass das Teil nicht so viel kann. Weil du an deinem Rechner Sachen machen kannst, die dann da nicht gehen. Wahrscheinlich wird dein Skript auch nicht unendlich groß sein dürfen. Halt die typischen Einschränkungen auf so kleinen Geräten ^^

Na schlecht wird einem meiner Ansicht nach, weil sich die Höhe der Kamera ändert. Du korrigierst ja nur Roll und Pitch, aber keine Verschiebung der Kamera...

Falls es in der Ruby-Community üblich ist auf diese Weise fremde Bibliotheken anzubieten könnte man da meiner Meinung nach drüber nachdenken, dass man ein Git-Repo als "Mirror" für die Bindings anlegt. Ist das denn so? Ich bin bisher nicht so tief drin, aber ist das übliches Vorgehen, dass man Bibliotheken als git-submodule oder so lädt?

Ich denke Python würde eher dem TF-Gedanken entsprechen. Zumindest meiner Idee dieses Gedanken. Würde ich in C auf Hardware programmieren wollen würde ich wohl gar kein TF nutzen. Aber vielleicht übersehe ich da auch andere Vorteile von TF gegenüber Arduino. Wegen Firmware auf 1000 Messages/s: Ist das nicht auch für WiFi und Ethernet-Extension ein Problem? Ich denke da würde icha uch über beide Protokolle mehr als 1000 Nachrichten pro Sekunde kriegen. Ist also kein reines On-Device-Problem oder?

Vermutlich hat er mit aufgeschraubter Kamera keine Kamera mehr zum fotografieren übrig ^^ Da hilft dann nur der Spiegeltrick von Plenz

Das sind mal Distanzen mit denen ich arbeiten wollen würde Ich würde auch gerne 50 Euro dafür ausgeben, könnte aber beim Preis des Sensors alleine schon knapp werden. Oberste Schmerzgrenze wären denke ich 70 Euro. Welche anderen Entfernungen usw. gibt es denn? Habe da eben für I2C nur Std Res auf der verlinkten Website gefunden. (ich war zu unklug, habs gefunden) P.S.: Wenn ein Sensor noch mehr Performance bringen würde als der konkret verlinkte wäre mir das auch wieder mehr Wert ;-)

Das ist ja ein grandios gutes Ergebnis Hätte nicht gedacht, dass das so gut geht.

Huhu, da es in der Timeline traditionell ganz hinten steht auch wenn neues reinkommt: Wie ist hier der Stand? Gibt es schon irgendetwas?

Ich war kürzlich schockiert, dass mit ein Micro-USB Kabel versandkostenfrei aus Frankreich zugesendet wurde und du redest bei 3 Euro von Mondpreisen So unterschiedlich kann die Wahrnehmung sein P.S.: Im Marketplace eines derzeit in den deutschen Medien kritisieren Versandhändlers habe ich auch ein 15cm Kabel (mini usb) für 1,49€ gefunden. Versandkostenfrei! Ich will nicht wissen wessen Blut an meinen Händen klebt, aber sowas habe ich auch schon gekauft!

ICh glaube es gab beim IMU einen Wert mit dem man bei der Lagebestimmung das Verhältnis zwischen Gyros und Beschleunigungssensoren einstellen kann (siehe API): - viel Gyro: keine gute Korrektur über die Zeit, dafür aber keine Probleme bei Bewegung - viel Beschleunigung: gute Korrektur über die Zeit, aber Probleme beim Beschleunigung So oder so ähnlich... edit: warum bin ich eigentlich so faul... hier ist die Doku... da ist das ganze auch viel besser erklärt

Also ich bin ja selbst nicht TF, deswegen ist meine Antwort nur zum Teil gültig Aber ich denke nicht, dass es möglich wäre die aktuelle Vielfalt an unterstützten Programmiersprachen ohne automatische Erzeugung der Bindings zu erreichen. Es gibt viele Situationen wo das Generieren sinnvoll ist: Beim Hinzufügen eines neuen Bricks/Bricklets (generiere für alle Sprachen das neue Device) Beim Hinzufügen neuer API zu einem/vielen Bricks/Bricklets (generiere für alle Sprachen die neuen Funktionen) Bei Veränderung des Zusammenspiels zwischen IPConnection und Devices (vor kurzem passiert; generiere für eine Sprache ALLE Devices neu) Bei grundlegenden Design-Änderungen (Upgrade auf Protokoll 2.0; generiere für alle Sprachen alles neu) Bestimmt habe ich noch etwas vergessen ^^ Das Generieren der Bindings hat halt immense Vorteile für die Entwicklung, dadurch wird das alles erst möglich. Der Nachteil: Die API einzelner Sprachen ist suboptimal, aber noch immer besser als vieles was ich sonst so gesehen habe P.S.: Es wäre traurig wenn nach Schema F generierte Bindings eleganter wären als deine mit viel Schweiß erzeugten Handcrafted Bindings Das Argument mit Humidity vs. Value sehe ich nur zur Hälfte ein: Ja es wäre natürlich leichter, weil du im Zweifel nur einen einzigen Wrapper brauchst. Aber nein, es wäre schlechter Stil, weil eine API (und das haben wir hier) immer aussagekräftig und lesbar sein sollte. P.P.S.: In meinem eigenen Code gehe ich sogar so weit, dass ein DistanceSensor keinen int zurückliefert sondern eine Distance, dort unterscheidet sich also sogar der Rückgabetyp

Gerade bei den Relays fällt das ganz schön auf Ich würde behaupten die aktuelle Art wie die Bindings generiert werden lässt keine Verallgemeinerung auf eine gemeinsame Oberklasse zu. Gegen eine einheitlich aussehende API spricht nichts außer backwards-compatibility. Aber die würde man auch durch doppelt angebotene Methoden herstellen können. Ansonsten würde ich dir empfehlen solche Dinge durch eigene Wrapper zu abstrahieren, das habe ich bei einem meiner (derzeit schlafenden) Projekte auch schon für bestimmte Bricklets gemacht, z.B.: abstraktes Interface eine mögliche Implementierung Der Vorteil dessen ist übrigens auch, dass wenn TF irgendwann mal das Protokoll 3.5 rausbringt (oder auf sonst merkwürdige Ideen kommt), dass du nur deine Wrapper aktualisieren musst, dein restlicher Code aber davon unberührt bleibt weil er den TF-Kram gar nicht kennt.

Auch wenn das für mich vermutlich nie relevant sein wird noch meine Bonusfrage: Welche Nebenwirkungen hat das runterlöten dieses Widerstandes?

Falls noch nciht geschehen sollte das wohl mit ins FAQ ^^

Das was Acane beschreibt deckt den Fall eines Verbindungsabbruch ab. Monoflop heißt, dass dein Relais alleine abschaltet, wenn ihm niemand regelmäßig sagt "bleib an". Im Funkloch würde das "bleib an" nicht durchkommen und es geht aus. Bei Stromausfall deines Stacks sollte es aber noch immer Scherben geben, sofern durch den Stromausfall nicht auch die Kamera stehen bleibt. @Acane: Bei deinem Beispiel sollte doch der Schlitten im schlimmsten Fall eine volle Sekunde weiterlaufen oder? Ich erneuere auf 1 Sekunde und dann reißt die Verbindung ab. Mal grob überschlagen: Ich denke der Monoflop sollte auf 70 ms stehen (und alle 50 ms aktualisiert werden). Dann läuft die Kamera knapp einen Meter bevor sie anfängt zu bremsen. 50 ms Aktualisierungszeit sollten auch ausreichen, denn damit kann das Signal noch 20 ms zu spät kommen. Wenn es tatsächlich noch langsamer wäre, dann ist anhalten wahrscheinlich eh keine schlechte Idee. Am besten sollte man aber den Bremsweg für eine solche Notbremsung vorher ausmessen und schauen, dass man dementsprechend auch die Notabschaltzeit und den Außenbereich des Seils auslegt.

Dann nehme ich alles zurück und behaupte das Gegenteil

Habe leider kein Wifi-Modul aber folgenden Rat: Der Brickv ist in der Regel zum Spielen mit dem Stack gedacht und weniger zum "Debuggen". Was meine ich damit: Der Brickv verstellt sich den Stack oft genau so wie er ihn gerade braucht. Er setzt Callbacks und Callback-Periods, ich kann mir auch gut vorstellen, dass er den Power-Mode des Wifi-Moduls nach eigenem Bedürfnis verstellt. Auch wenn er den Power-Mode nicht verstellt kann ich mir vorstellen, dass er die Information welcher Power-Mode aktiv ist nur einmal beim Connecting aktualisiert. Du merkst schon, alles nur Vermutungen meinerseits. Wenn du sichergehen willst, dann frage einfach mithilfe von getWifiPowerMode() selbst nach dem aktuellen Power-Mode. Dann kannst du dir sicher sein, dass kein anderes Programm dazwischenfunkt.

Exakte Synchronität wird kaum möglich sein: - Bei DC-Motoren schon naturbedingt nicht (Fertigungstoleranzen u.ä.) - Sowohl bei DC- als auch bei Stepper-Motoren: Du kannst nicht zwei Bricks exakt zeitgleich ansteuern und Ihnen den gleichen Befehl geben (da wäre im Idealfall eine Millisekunde Zeitdifferenz, wenn es schlechter läuft mehr)

Das ist ja merkwürdig. @TF: Macht ihr in der Extension irgendwelche Annahmen über die Src-IP? Sowas wie "sie muss in meinem Subnet liegen"? Ist ja nur schwer erklärbares Verhalten. @Einstein: Nur zur Sicherheit: Das Gateway erfüllt keine Firewall-Aufgaben und filtert deswegen deine TF-Pakete? Andere Dienste (mehr als "Ping"; am Besten TCP-basiert) funktionieren zwischen den Netzen? edit: Nicht sicher ob das notwendig ist, aber ist das Gateway auch korrekt in der Extension konfiguriert?

Hast du denn ein Gateway das zwischen beiden Teilnetzen vermittelt? Ansonsten ist das ja quasi expected behavior für Netzwerkgeräte.

Vielleicht zum besseren Verständnis: Was war es denn vorher? Warum war das billiger und was war der Nachteil gegenüber einem Fertigmodul?

Zu 5 (Funk): Reicht dir das Angebot durch WiFi-Extension und Step-Down-Supply nicht aus? Was sollte anders sein?

@borg: Danke für die Aufklärung. Ich bin in dieser Hinsicht tatsächlich nicht so fit. Aber ist meine naive Annahme eigentlich richtig, dass ich mithilfe einer Übersetzung (oder heißt das dann Untersetzung?) auch höhere Drehzahlen messen kann, dafür aber nicht mehr mit voller Auflösung? Beispiel: Mein tatsächliches Rad dreht mit 64.000 RPM, aber ich führe die Messung an einem Rad durch das mit einer 4:1 Übersetzung zum Urrad dreht? Dann würde ich dort nur noch 16000 RPM anliegen haben... Ist das so richtig, oder übersehe ich irgendwas?

Die Geschwindigkeit sollte ja nur auf dem kleinen PC in der Fräse eine Rolle spielen oder? Dort ist denke ich das wichtigste, dass du Unterbrechungen durch das Betriebsystem vermeidest. Also am Besten nix anderes laufen lassen und den Steuerungsprozess auf eine hohe Priorität setzen. Die Wahl der Programmiersprache sollte darauf meiner Ansicht nach keinen Einfluss haben ^^ (Zumindest solange du dich von PHP fernhältst )