AuronX

@Fabian: An die bloße Schalldruck-Sache habe icha uch schonmal gedacht und mich gefragt ob ein Analog-In mit angeschlossenem Mikrofon ausreichen würde. Ein Mikrofon wandelt ja nur Schwingung in Strom um (umgedrehter Lautsprecher ^^). Ich habe aber keine Ahnung, ob dabei Spannungen rumkommen die man mit dem Analog-In messen kann oder nicht. Villt kann das ja mal jemand ausprobieren...

Keine Ahnung wie das in Rapid-Q genannt wird, aber es sieht zumindest aus als könnte man über diese Ereignisse Callbacks abbilden. Mehr wollte ich gar nciht sagen ^^

Kurze Erklärung: Die Callbacks werden soweit ich weiß bei allen Bindings innerhalb eines einzelnen Threads abgearbeitet. Das heißt also es kann nur ein Callback nach dem anderen bearbeitet werden. Deswegen das von dir beobachtete Verhalten, dass die Callbacks hinterherrennen. Die Lösung ist so simpel wie kompliziert: Du solltest nicht so lange zum Bearbeiten der Callbacks brauchen. Wie geht das? Ich vermute jetzt gerade mal, dass du die ganze GUI-Zeichnerei einfach sofort beim Abarbeiten des Callbacks machst. Aber das ist teuer, also GUI allgemein ist teuer, das heißt es dauert lange (für die Verhältnisse eines Computers). Lösen kann man das durch folgenden Trick: Wenn dein IMU neue Daten hat, dann schreibst du dir das irgendwo auf (also von mir aus Winkel, Neigung, whatever). Du kannst auch schon irgendwelche Umrechnungen machen, aber mache keine GUI-Arbeit, dabei kommt es zu IO, das dauert. In einem extra Thread oder per Timer lässt du jetzt regelmäßig die GUI aktualisieren, diese kann die per Callback gesetzten - jeweils aktuellen - Daten zeichnen. Das bringt dir aber auch die Verantwortung für eine gute Synchronisierung der Threads zu sorgen :/ Das sind jetzt leider nur Stichwörter dessen was du tun musst, kein Code. Ich hätte bestenfalls C#-Beispiele parat ^^ Ist leider recht viel auf das man da so achten muss... Aber das lässt sich m.E. nicht vermeiden, auch nicht durch tollere Programmiersprachen, denn die Probleme sind überall die gleichen und können nur schlecht allgemein-gültig gelöst werden. Viel Glück, villt hat jemand anders noch konkretere Tipps parat...

Hallo, ich machs heute mal kurz: Beim Servo Brick ist die Output Voltage mit 2-9V angegeben, im Brick Viewer sind aber 5-27V einstellbar. Erklärung?

Da gab es ja schonmal die Frage wie viel Leistung an einem IO4/IO16 noch okay sind. Die Antwort war glaube ich so ungefähr "WTF sehr wenig, aber IO16 kann mehr als IO4". Beim IO4 hängt glaube ich jeder Ausgang direkt im Mikro-Controller und der darf insgesamt gerade mal 0,5 A loswerden. Beim IO16 weiß ich es nicht ganz genau.

Oh cool, dann war Python doch besser als ich in Erinnerung hatte hatte befürchtet die Deklaration müsste im Code "vorher" erfolgen. Wegen Rapid-Q: Sieht auf jeden Fall schön simpel aus ^^ Und Offensichtlich werden ja sogar Delegates unterstützt (OnClick = Geklickt) Ich befürchte allerdings, dass es so schnell keine Rapid-Q Bindings geben wird ^^ Zumindest habe ich in diesem Thread das erste Mal davon gehört...

Hallo, ich möchte langsam anfangen mein aktuelles Projekt zu dokumentieren. Ich habe ein altes Chassis von einem "Pajero" RC-Auto. Da ich inzwischen auch mein erstes Equipment für selbständiges Fahren habe (Distance IR, Servo) habe ich begonnen Steuerungssoftware für selbiges Fahrzeug zu schreiben. Da ich eher aus dem Software-Engineering Umfeld und weniger aus der Hardware-Ecke komme, versuche ich meinen Fokus darauf zu halten, dass die entstehende C#-Bibliothek möglichst allgemein eingesetzt werden kann. Das heißt ich möchte alle Komponenten zur Steuerung des Fahrzeuges leicht austauschbar gestalten. Welche (nicht GUI-) Komponenten gibt es bisher? Eine Klasse zur Repräsentation radialer Distanz-Messungen (Screenshot enthält Visualisierung dieser Daten ^^) Eine Steuerung um mithilfe eines Servos und eines Distance-IR ebensolche Daten zu erfassen Eine sehr simple Motorsteuerung basierend auf der Distanz zum nächsten Hindernis Aber genug der Worte... Den Code für alle Interessierten gibt es hier: GitHub Ich hänge schonmal einen ersten Screenshot meines Test-Fensters an (alles was dort zu sehen ist gab es aber vorher schon bei anderen zu sehen ) Bilder vom Chassis gibt es dann später noch ^^

Wird dran liegen, dass meine ganze Familie HTC Handys hat ^^ Da ist diese Bauform (Netzteil getrennt von Kabel) der Standard ^^ Deswegen das Totschlagen Die von dir angesprochenen habe ich tatsächlich nicht in großer Stückzahl vorrätig, deswegen vermutlich mein Unverständnis... Ich befürchte einfach nur, dass der Platz auf den Bricks zu begrenzt ist um noch viele weitere Anschlüsse bereitzustellen und wollte deswegen USB als universelle Möglichkeit lobpreisen ^^ Aber du hast recht, bei etwas wie der Ethernet-Extension wäre ja möglicherweise Platz und wenn es elektrisch möglich ist das zu machen, dann wären die paar Cent für eine Buchse okay ^^ ---- Edit: Inzwischen kam ein weiterer Post von dir... Ich denke unser Misverständnis besteht darin, dass du massenweise Rundstecker übrig hast, ich keine und bei mir ist es genau andersrum ^^ Wie gesagt, meine Netzteile hab ich nciht extra gekauft sondern geliefert bekommen ^^

Was ist denn jetzt das Problem? Die Leistung ist grundsätzlich schon von USB gedeckt. Jedes Netzteil was nen USB-Ausgang hat liefert 5V und verträgt mindestens 500 mA (weil USB das bietet), tlw auch mehr, das steht aber auf dem Netzteil in jedem Fall drauf. Netzteile wie die abgebildeten sind auch unabhängig von Mini oder Micro, weil du ja das Kabel noch dranpappen kannst. Ansonsten ist es halt unterschiedlich, die gängigste Bauform ist für Ladegeräte Micro, es gibt aber auch Mini (nur viel viel viel seltener).

Richtig, mir geht es um Netzteile die auf der einen Seite in die Steckdose kommen und an der anderen Seite steckst du dein USB-Kabel beliebiger Bauform (Mini, Micro, etc) rein. So sieht mein Handyladegerät z.B. aus ^^ Mal noch eben schnell die Google Bildersuche angezapft... Denke das ist die Zukunft der ich-kann-dich-damit-totschlagen-weil-ich-zu-viele-davon-habe-Netzteile

Also was war jetzt gegen USB als "Steckerform" einzuwenden? Also es müssen ja keine Daten drüber fließen, ein einfaches USB-Netzteil reicht ja aus... Oder verstehe ich das Problem nicht?

Sagen wir es so: GUI-Programmierung ist immer ziemlich übel, weil du neben der Programmiersprache auch gleich noch mittelgroße Frameworks und deren Konzepte mitverstehen musst. Allerdings gibt es auch schlanke GUIs, aber meist ist das nen Stück mehr Aufwand als ne Konsolenanwendung. @Plenz: was war der Grund warum du nicht einfach ne Konsolenanwendung gemacht hast? Du hattest am Anfang angedeutet, dass dir ne GUI leichter schien als ne Konsole

Das liegt daran, dass ich eben ein Dummkopf bin Also wenn das ne Endlosschleife ist dann sollte der Code natürlich nochd avor sein. Aber auch NACHDEM app definiert wurde. Also genau zwischen diesen beiden Zeilen: app = App(root) root.mainloop() War mein Fehler ^^

Head up display. Da werden quasi irgendwelche relevanten Informationen direkt auf die Windschutzscheibe geworfen, so muss man den Blick nicht vom wichtigen (die echte Welt) abwenden um die Geschwindigkeit/Neigung/usw zu sehen.

Nein, Geld reicht ^^

ich gehe davon aus, dass neu den o-bereich einschließt? oder verstehe ich grad was falsch?

@Plenz: Absolut geiles Video ^^ Die Konstruktion ist ziemlich fett, aber man sieht sie dem Video nicht an ^^ Richtig gut!

+1

Das wäre dann entweder Fehlverhalten oder aber unterspezifiziert. Ich vermute aber es ist ein Copy & paste Fehler in der Firmware... Zur Erklärung: inside ist ja: x > minX && x < maxX && y > minY && y < minY Das Gegenteil dieses Ausdrucks würde ich outside nennen: !(x > minX && x < maxX && y > minY && y < minY) Wenn wir das auflösen kommt der gute alte De Morgan ins Spiel: !(x > minX && x < maxX && y > minY && y < minY) = !(x > minX) || !(x < maxX) || !(y > minY) || !(y < minY) Kurz: Es hätten ODER's hingehört, aber vermutlich aus Versehen wurden UND's gesetzt. @TF: Zustimmung oder Widerspruch? Bug-Fix? Viele Grüße Jan

Klingt interessant und scheint ja in Richtung Rasenmähen zu gehen ^^ Ich versuch mir gerade die Jumper-Armee auf dem armen kleinen Bricklet vorzustellen ^^ Aber keine Ahnung ob das machbar ist. Glaube ja, dass die Bricklets eigentlich nur "Verlängerungen" der Mikrocontroller sind, also kA wie gut sich da ein Standalone-Betrieb realisieren lässt.

Deine def vom anschlo ist kaputt: def anschlo(tx): richtig wäre def anschlo(self, tx): Ich bin auch nie drauf klargekommen, dass man in python das self explizit als ersten Parameter mit übergibt ^^ Also das ist mira uch oft passiert P.S.: Ah okay, das war nur die Halbe Lösung ^^ Oben im Callback nutzt du ja App (großgeschrieben), das wäre dann vermutlich ein statischer Aufruf (bin mir unsicher), bei dem gäbe es aber kein self. Ich entwirr das ganze mal noch kurz in meinem Kopf und dann poste ich hier drunter neuen Code ^^ from Tkinter import * # ich habe mal zur Entwirrung alles sortiert (globals ganz oben, dann defs, dann class, dann main-code) # wenn das nen Unterschied macht muss es irgendwann zu Irritation kommen # lieber rechtzeitig vorbeugen app = None # der aktuelle Code braucht das als global (muss man in Python doch vorher definieren oder?) def cb_interrupt(interrupt_mask, value_mask): if ((interrupt_mask == 4) & ((value_mask & 4) == 0)): print "EIN" # das funktioniert noch! app.anschlo("EIN") # das sollte jetzt hoffentlich auch gehen class App: def __init__(self, master): frame = Frame(master) frame.pack() self.anschl1 = Label(frame, text="x") self.anschl1.pack(side=LEFT) self.button = Button(frame, text="QUIT", command=self.ende) self.button.pack(side=LEFT) def anschlo(self, tx): self.anschl1.text = tx def ende(self): ipcon.destroy() print "IP destroyed." root.destroy() UID_IO4 = "7Qo" # IO-4 Bricklet io4 = IO4(UID_IO4) # Create device object ipcon = IPConnection(HOST, PORT) # Create IP conn. to brick ipcon.add_device(io4) # Add device to IP conn. root = Tk() app = App(root) root.mainloop() # callback erst dann registrieren, wenn die Variable "app" auch gesetzt ist # sonst würde die "cb_interrupt" methode explodieren (viel Rauch und Schutt) io4.set_interrupt((1 << 2)|(1 << 3)) io4.register_callback(io4.CALLBACK_INTERRUPT, cb_interrupt) Dieser Code ist bei mir gerade rausgekommen und sollte laufen... hoffe ich ^^ DAs Problem ist, dass ich gar nicht so gut bin in Python. Normalerweise hätte ich dir auch dazu geraten, dass du die cb_interrupt-methode in deine App-Klasse hineinziehst, aber ich glaube nicht, dass das geht, weil ja der explizite self-parameter stören würde. In anderen Sprachen ginge das tatsächlich, hier hab ich gerade keine hübsche Idee. Deswegen auch app als globale Variable (nicht soooo toller Stil). Hoffe ich konnte helfen.

Habe keinen Joystick, aber da dir niemand antwortet habe ich mal in die C#-Doku geschaut (sollte überall gleich sein): http://www.tinkerforge.com/doc/Software/Bricklets/Joystick_Bricklet_CSharp.html#BrickletJoystick::SetPositionCallbackThreshold__c.short-.short-.short-.short- In der Tabelle steht als option das o. Denke das ist es was du suchst.

Ist aber soweit ich was das gängige Prinzip. Also einen stromdurchflossenen Draht zu verwenden und dessen statisches Magentfeld zu spüren. Zumindest arbeiten die meisten Roboter auf dem Markt mit so einem "Elektrozaun".

Da steht es schon ^^ http://www.tinkerforge.com/doc/Software/Bricklets/DualRelay_Bricklet_Java.html#BrickletDualRelay::getState (Im setState drüber steht sogar der Hinweis wie man nur eines von beiden schaltet ) Oder meinst du, dass nicht klar wird, dass man relay1 von getState() abfragen kann?

In der Firmware direkt war ich noch nicht groß unterwegs. Ich habe nur eine grobe Vorstellung vom Protokoll ^^ Insgesamt findet halt sehr viel sehr zustandslos statt. Das heißt ein Brick oder Bricklet weiß zum Teil nur sehr wenig über sich selbst und seine Umwelt. Was m.E. gehen sollte (nur anhand meiner groben Idee, ohne irgendwelche Belege) ist es das Teil das auch von der Chibi-Signal-Strength bescheid weiß danach zu fragen (Funktionsruf) ob es Master oder Slave ist. Das sollte denke ich implementierbar sein. Ein Brick oder gar Bricklet danach zu fragen ob zwischen dir (also dem PC) und ihm eine Funkstrecke liegt ist denke ich nicht möglich, da das Bricklet gar nicht weiß woher die Frage kommt. Die Bricklets bekommen ihre Anfragen jeweils "vom Bus" und dorthin antworten sie halt auch. Die Antworten wiederum werden vom Master weitergeleitet, allerdings ohne dass der weiß, ob das was die Bricklets auf den Bus geschrieben haben gerade eine Antwort auf irgendwas war oder beispielsweise nur ein Callback. Insofern kann auch dort nur weitergeleitet werden. So weit zu meinem Verständnis, man möge mich gerne korrigieren wenn Unsinn dabei war