AuronX

Glaube ich nehm mir einfach mal nen Servo ^^ Is ja quasi mein aktuelles Hauptbrick Ich bin zwar nicht TF, aber ich versuche mich trotzdem mal: Dein Wunsch wäre ja quasi etwas wie enum Brick {Master, Servo, DC, ...} Das lässt sich denke ich mit den vorhandenen Generator-Daten nicht umsetzen. Bisher hat man eine Liste von Python-Dateien (pro Brick/Bricklet eine) aus denen die Bindings generiert werden. Damit ließe sich zwar ein enum generieren, aber das wäre nicht kompatibel erweiterbar. Das heißt sobald ein neues Brick dazukommt rutscht es alphabetisch (auch das ist genaugenommen nur zufall ^^) dazwischen und würde damit andere IDs generieren. Lange Erklärung kurz zusammengefasst: Man müsste die IDs explizit festlegen, weil es ansonsten bei der Einführung neuer Bricks durcheinander wuselt. Habe noch nicht reingeschaut, aber woran ich schonmal ein oder zwei halbe Gedanken verschwendet habe: Es gibt z.B. mindestens drei Bricks die die Aufgabe "Antrieb links" übernehmen können. DC, Servo, Stepper. Der Servo kann sogar Antrieb links, Antrieb rechts, "Kameraneigung" und "Toaster-Auswurf" gleichzeitig wahrnehmen. Das sollte irgendwie modellierbar sein ^^

Was mir grad noch nicht ganz klar ist: Hat das was mit deinem Roboter zu tun oder ist das ein Projekt das du parallel verfolgst? ^^ Weil das ja eher so nach "Brick-Management" aussieht... wahrscheinlich hab ich da irgendwo den entscheidenden Post mal überlesen Was mir grad noch einfällt: Falls dein Code irgendwann mal woanders als unter Windows laufen soll schau mal ob es deine Datenbank-Lib auch woanders gibt. Ansonsten gibt es ja noch sqlite, das sollte recht portabel sein und es gibt bestimmt auch gute .NET-Libs dafür (Dieser Absatz enthält quasi ausschließlich Vermutungen ^^)

Wenn dein Badezimmer kein Fenster hat (bei manchen Toiletten ist das so), dann ist da immer ein Lüfter drin. Der dient dazu die Feuchtigkeit (manchaml auch Gerüche) aus dem Raum zu bekommen. Üblicherweise wird er mit dem Lichtschalter + Zeitschalter gesteuert, einfach weil es keinen besseren Indikator gibt wann Lüften sinnvoll ist. Einen solchen Lüfter könnte man nur mit einem Humidity-Bricklet steuern P.S.: Da da Humidity eines der teuren Bricklets ist und das Temp recht günstig könnte das aber eine Konstellation sein, wo der Preisunterschied eher gering ist, das wäre ein Punkt für dich ^^

Baust du dir etwa eine Build-Ampel? Bei uns in der Uni gab es ein Projekt, da wurde ne Ampel rot wenn der Build fehlschlug Sonst war sie permanent grün ^^

Also DB scheint zu laufen ^^ Habe alles so gemacht und vorm beenden auch noch eine Frage gestellt: SELECT * FROM Bricks Die Antwort war "Nicht eins", wenn das bedeutet es gab keine Daten ist alles okay Mir ist nur nicht klar was ich durch den Klick auf "Default DB" getan habe (Code nicht angesehen ^^).

Damit es mal was zu sehen gibt: Habe das Video mit meinem Handy erstellt, aber man sieht das wesentliche ^^ Grundsätzlich befolgt das Auto bisher nur folgende einfache Regeln: - wenn der Abstand groß genug ist fahr los - wenn er viel zu klein ist, fahr zurück - dazwischen bleib stehen Aktuelle Probleme: - Funktioniert nur bei geringen Geschwindigkeiten zuverlässig (insbesondere da der ESC den Motor jeweils ausrollen lässt wenn man Stillstand verlangt, also keine Bremse) - Geschwindigkeit ist stark abhängig von Spannung des Akkus (und bei vollem Akku ist auch die geringste Geschwindigkeit zu hoch -.-) Werde mir also noch Gedanken über das Geschwindigkeitsmanagement machen müssen, möglicherweise werd ich auch mal versuchen die Geschwindigkeit (also Radumdrehungen) zu messen. Was ich auch schon absehen kann: Den Distanzsensor wie geplant regelmäßig schwenken zu lassen, so wie es ja auch viele andere hier machen, wird noch eine Herausforderung, da dort die Daten jeweils deutlich verzögerter verfügbar sind. Ist auf jeden Fall spannend und macht Spaß ^^ @The_real_black: (Falls du mitliest) Bin schon auf ein wenig live-action von deinem Robo gespannt ^^ (Du planst ja auch mit Distanz-IR + Servo)

Fehler 404: URL nicht gefunden

Es stellt sich heraus, dass volle Akkus den Motor ziemlich schnell laufen lassen. Auch bei geringster Stufe ist dem Fahrtenregler kein langsamer Motorlauf zu entlocken ^^ Mit leeren Akkus läuft das besser. Werde versuchen mir ne Softwarelösung einfallen zu lassen, sonst muss ich das anders hinbekommen (ESC oder Motor tauschen). Simples Video gibts bald ^^

Das Problem ist halt, dass es KEINE klaren Regeln gibt welche zwei Sensoren zusammengehören. Der eine braucht das der andere was anderes. Deswegen kann man ja an ein Brick auch viele bricklets hängen, um das so zusammen zu schustern wie man es braucht. Wenn da jetzt irgendwelche Kombi-Lösungen entwickelt werden ist das Zeit die nur für die Entwicklung von Teilen draufgeht die es in flexibler (weil einzeln) schon gibt... Das ist denke ich mit Modularität gemeint.

Das Master-Brick ist die günstigste Platine die du draufstecken kannst

Samba ist nicht mehr nötig. Vielleicht möchtest du nochmal kurz zusammenfassen welche Symptome bei dir auftreten. Wird dein Brick als Unbekanntes Gerät erkannt? gar nicht? Hast du bereits versehentlich auf Erase gedrückt?

Im von mir verlinkten Post schreibt Borg, dass das IO4 direkt an den Pins des COntrollers hängt und der hat für alle 100 Pins insgesamt nur 150 mA zur verfügung. Glaube mich zu erinnern, dass bspw. das IO16 mehr kann, aber Quelle fehlt, insofern hoffe ich auf eine noch detailreichere Antwort von TF auf deine Frage ^^

http://www.tinkerunity.org/forum/index.php/topic,543.msg3069.html#msg3069 Denke das IO4 solltest du dafür nicht nutzen. P.S.: Irgendeine Zahl (wenn auch pessimistisch) sollte villt mal ins Datenblatt des IO4...

Denke gerade Luftdruck ist ein klassisches "stand-alone" bricklet, weil es eben nicht nur für Wetter sondern auch für Höhenmessung geeignet ist.

Bugreport für Version 1.1.0: Die Under Voltage Dialogbox des Servo-Bricks taucht immer wieder auf, auch wenn ich den Haken bei "show again" deaktiviere.

Sorry wegen OT, aber das interessiert mich Du hast natürlich recht, beim Fokussieren verändert sich der Maßstab ein wenig... aber was mich noch irritiert: Wenn ich die Kamera vom Objekt entferne (oder näher heran schiebe), dann verändert das doch auch den Abbildungsmaßstab, weil ja der bisher fokussierte Bereich jetzt etwas weiter entfernt ist und somit auf dem Sensor kleiner sein müsste. Wo liegt hier mein Denkfehler? (Ich denke schon, dass du weißt wovon du redest, also muss der Fehler ganz sicher bei mir zu suchen sein )

@Nic: Wozu braucht man beim Focus Stacking irgendwas bewegliches? Hätte es dem Begriff nach für das Zusammenblenden gleicher Bildaufnahmen mit unterschiedlichem Fokus gehalten. Wikipedia würde mir dabei recht geben ^^ Die Frage: Wenn ich gleiche Bilder mit lediglich anderem Fokus haben will, wozu dann eine Schiene? Die Kamera soll doch beim Focus Stacking gar nicht bewegt werden oder?

Die Spammer werden ja eh gelöscht. Das heißt also die Spam-Accounts sind eh nur "Einweg-Accounts": Anlegen, Posten, gelöscht werden... Dort spielt es also keine Rolle bzw. würde nur eine spielen wenn sie mehr als einmal posten dürften. Wegen "Captcha schadet ja nicht": Bedenkt immer, dass das Internet nicht nur aus 100% gesunden Menschen besteht. Es beginnt bei Schwierigkeiten im Farbsehen (rote schrift auf grünem Grund oder so) und endet bei völlig seh-behinderten die keine normalen Displays sondern Braille-Zeilen haben. Damit kann man dann auch den Text auf Websites lesen. Ein Captcha bei der Anmeldung lässt sich jetzt villt noch mit Hilfe oder so umgehen, wird aber auch die ein oder andere Anmeldung verhindern -> keine Lust. Ein Captcha pro Posting würde solches Publikum gänzlich frustieren und effektiv aussperren. Viele Grüße Jan

Diese Dinger nennt man Captcha Ich persönlich würde es hassen diese Dinger vor einem jeden Post lösen zu müssen. Vor der Registrierung halte ich es allerdings für okay ^^

Klingt danach, dass du die Callbacks nicht einschaltest. Wenn dann der Viewer dazukommt schaltet er sie ein. Hast du den interrupt mittels set_port_interrupt aktiviert?

Das klingt danach als würden diese Funktionen keine High-Resolution-timer benutzen. Eine kurze Suche auf Stackoverflow hat mir aber auch keine besseren Kandidaten gebracht :/ Zumindest sollte das noch ein lösbares Problem sein. Das rechtzeitige ausführen sollte durch anheben der Prozess-priorität in den Echtzeitbereich auch erzielt werden können (wenn es dann manchmal doch schiefgeht ists ja nicht schlimm). Bin gespannt ob deine Mikrofonlösung zum Erfolg führt... halte uns auf dem Laufenden

Das mit dem echten Abschalten der Callbacks war mir gar nicht bewusst. Dann sollte es auch wenige Probleme geben das Brick/Bricklet einfach zu "vergessen". Die IPConnection kennt es halt weiterhin und würde Nachrichten von diesem Brick/Bricklet entsprechend zustellen. Es sollten aber eigentlich keine Nachrichten kommen wenn du es nicht mehr benutzt und die Callbacks aus sind. Allerdings bleibt das Device-Objekt im Speicher... ist aber nicht besonders groß ^^

Versteh ich nicht... Zum Schreiben hier ist doch ein Account und das "Eingeloggt sein" pflicht. Um eingeloggt zu sein brauchst du das Session-Cookie. Und warum sollte ein Spam-Bot keine Cookies verarbeiten können?

Tatsächlich denke ich, dass das bisher nicht vorgesehen ist. Bestimmt könnte man es vorsehen, aber die Frage ist warum. Also was ist dein Anwendungsfall? Ich habe erst überlegt dir vorzuschlagen einfach das Device zu vergessen und nie zu entfernen... Aber das könnte mit der Zeit unangenehme Nebeneffekte haben (muss ich nochmal drüber nachdenken ob das wirklich problematisch ist)...

Bei den Kabeln bin ich halt sehr skeptisch... Das sind ja ganz viele Adern ineinander verdreht... ich befürchte halt, dass das Wasser da nach und nach entlang krabbelt. Aber wenn du das mit dem Silikon schön zuschmierst, dann könnte das klappen ^^