AuronX

Elektrischer Zaun soweit ich weiß nen Draht unter Strom, dadurch gibts nen spürbares Magnetfeld das du mit dem Roboter wahrnehmen kannst (k.A. wie genau... Reed-Kontakt? Hall-Sensor? <-- wikipedia-hilfswörter ^^) Ein Trick um zur Station zu finden ist beispielsweise, dass sie genau am Rande des "Zauns" liegt. Dann müsstest du nur dem Zaun folgen bis du zu hause bist (unter der Vorraussetzung, dass das Finden des Zauns einfach ist).

Mich würden definitiv Fotos interessieren wie so ein Panzer umgerüstet aussieht Mechanisch hab ich leider keine Ahnung, kann dir bei den Ketten also Kaum helfen... zwei Ideen: - Spannung auf der Kette erhöhen - seitliche FÜhrung der Kette verbessern Müsste man mal schauen wie die überhaupt aussehen, ist aber möglicherweise auch totaler unsinn was ich schreibe ^^

I believe the brickd keeps track of the connections requesting events. If so you could simply open two connections and register your callbacks only on one of the connections. Then the events/callbacks should only occur on that connection.

Fas Problem ist halt, dass es leider völlig transparent ist. Das heißt es gibt soweit ich weiß keinen Weg das herauszufinden. Über Implementierungsdetails könnte es gehen (glaube man könnte die Stack IDs nutzen, weil die Geräte in ner bestimmten Reihenfolge enumeriert werden -> die Stack ID also Rückschlüsse auf den Anschluss zulassen könnte), aber das ist unzuverlässig und da wäre es dann einfacher und sicherer sich lieber selbst die Funkteilnehmer zu "notieren".

Oh lol... irgendwie war ich hier in Gedanken auch voll im Mähroboter-Thread

Dan würde ich den kürzesten Sensor nehmen. Das könnte funktionieren. Problematisch könnte sein, dass der Sensor ja im schlechtesten Fall genau zwischen die Wurzeln zweier Grashalme schaut. Dann würde dir der Wind allerdings helfen, da der ja die Halme bewegt. Du wirst vermutlich ein wenig experimentieren müssen wodurch du gute Ergebnisse erzielst, möglicherweise ist es hilfreich wenn der Sensor sich selbst etwas bewegen kann (sehr kurzes vom Wind bewegtes Pendel???). Am Ende denke ich kannst du ja einfach über einen Zeitraum von x Sekunden messen und die geringste Distanz ist dann dein Messwert (weil du annehmen kannst, dass genau dann der GRashalm vor den Sensor geweht wurde).

Die Stack-ID ist nicht die ID des Stack sondern die ID des Bricklets im Stack.

Verstehe die Frage noch nicht ganz... Bisher ist ja ein Teil des Stacks immer per Kabel mit dem PC verbunden, nämlich per USB. Chibi gibts ja nur zwischen zwei Stacks. Für was willst du also wissen ob es per Funk verbunden ist? Ein Brick? Ein Bricklet? Ein ganzer Stack? (Wobei ich bei letzterem nichtmal wüsste wie man den adressieren könnte)

Die kommt auch. Du kannst also sowas machen: try { ipcon.AddDevice(myDevice); } catch (Tinkerforge.TimeoutException e) { //handle the error }

Du lebst ganz schön warm

Mhhh, so wie es im Moment gedacht ist müsstest du bei der Initialisierung zwei IPConnections aufmachen, könntest aber danach alles so nutzen wie jetzt auch. @Borg: Der brickd ist in Python geschrieben oder? Ich würde mal schauen wie gut es möglich ist den von mir gemachten Vorschlag umzusetzen (brickd kann "IP-Devices" anbinden), vielleicht kannst du da auch ne Einschätzung zum Aufwand abgeben.

Folgender Code stammt von dir: ipcon.enumerate(new IPConnection.EnumerateListener() { public void enumerate(String uid, String name, short stackID, boolean isNew) { if(isNew) { System.out.println("New device:"); if(name.startsWith("Distance IR Bricklet")){ } } else { System.out.println("Removed device:"); } System.out.println(" Name: " + name); System.out.println(" UID: " + uid); System.out.println(" Stack ID: " + stackID); } }); //ipcon.joinThread(); Das ist auseinandergefummelt einmal der Code drumerhum: ipcon.enumerate(DER_TEIL_INNEN_DRIN); //ipcon.joinThread(); und eben der Teil innen drin: new IPConnection.EnumerateListener() { public void enumerate(String uid, String name, short stackID, boolean isNew) { if(isNew) { System.out.println("New device:"); if(name.startsWith("Distance IR Bricklet")){ } } else { System.out.println("Removed device:"); } System.out.println(" Name: " + name); System.out.println(" UID: " + uid); System.out.println(" Stack ID: " + stackID); } } Den Teil innen drin nennt man anonyme Klasse, weil du eine ganze Klasse definierst ohne ihr einen Namen zu geben. Wenn du ihr einen Namen geben willst, dann kannst du den inneren Code irgendwo anders hinschreiben und statt new IPConnection.EnumerateListener() schreibst du dann eben class MeineNeueKlasse implements ActionListener (oder müsste das statt ActionListener eher IPConnection.EnumerateListener sein?) Der dazu passende äußere Code wäre dann ipcon.enumerate(new MeineNeueKlasse()); //ipcon.joinThread();

Du musst halt immer schauen, mein Rechtsverständnis ist ja, dass jeder dem Boden (also ein Grundstück) gehört auch das Recht über dessen Luftraum hat (zumindest bis zu einer gewissen Höhe). Das heißt einfach aml über ein beliebiges Gebäude fliegen und dann villt auch ncoh Fotos/Videos amchen ist ganz fix ein Landfriedensbruch Zum Bastel-Thema: Habe auch zu Anfang überlegt ein Fluggerät zu bauen, aber aufgrund der Verzögerung auch erstmal ausgelassen. Wenn die Steuersoftware auf nem Raspberry Pi oder anderem PC mit Standard-betriebssystem läuft auf jeden Fall daran denken, dass der Steuerungsprozess mit ner hohen Priorität laufen sollte. Allgemein sollten natürlich kaum andere Programme laufen, die die Steuerung unterbrechen können.

kleine DC Motoren lassen sich mit dem Servobrick und einem zusätzlichen Transistor steuern. Dabei ist natürlich auf die Daten des Motors zu achten. Wenn die Motoren größer werden brauchst du einen elektronischen Fahrtenregler (ESC). Das wurde hier im Forum schon öfter vorgeschlagen, ich starte demnächst auch ein Projekt wo ich das nochmal aufzeigen werde

Also grundsätzlich wären 2 IPConnections nötig, aber ich denke es sollte gehen, dass man den Brickd dazu ermächtigt andere Brickd's zu kontaktieren und als "local" einzubinden. Also ich hoffe zumindest, dass es dort keine Protokoll-seitigen Einwände gibt. Die Idee wäre, dass der lokale Brickd-Service so tut als hätte er angeschlossene USB-Devices obwohl er nur andere Brickd's kennt. Achso, die Frage nach der IPv6-Unterstützung ist ja gar nicht so blöd ^^ Aber ich befürchte, dass selbst heute noch die vorherrschende Meinung ist: "Darüber kann man später mal nachdenken"

Also das Raspberry kann die USB-Stromversorgung eigentlich nicht Spezifikationskonform erledigen ^^ 1. Es ist selbst nur ein USB-Gast-Gerät, darf also laut Spec nicht mehr als 500mA ziehen (alles drüber ist ja out-of-spec) 2. Es ist ein USB-Host-Gerät muss also mit Gästen bis zu 500mA klarkommen 3. Es verbraucht Strom ^^ Allerdings weiß ich nicht welche konkreten Toleranzen der Standard hergibt, aber das wäre die einzige Chance da was zu reißen, ansonsten muss ja in eine Richtung die Spec verlassen werden ^^

Oh, das ist deutlich fixer als ich erwartet habe ^^ Ich glaube sowas bau ich mir aus Spaß auch noch Habe ja noch nen alten Fighterbuggy (RC-Fahrzeug) ^^

Tatsächlich sind es ja immer zwei Auflösungen die du Gegeneinander veränderst. Du kannst alle 1° Messen, brauchst dann aber insgesamt sehr lange bis du eine volle Schwenkung geschafft hast: - Hohe räumliche Auflösung (wenige Lücken) - geringe Zeitliche Auflösung (in Bewegung schwierig) Alternativ könntest du halt die Abstände vergrößern, damit würde ein Durchlauf schneller gehen, aber die Lücken würden halt größer und du könntest was übersehen. Wie lange Dauert im Moment ein Scan von 180° wenn du in 1° Schritten misst?

PDF klingt nach der Option "auf Seitengröße einpassen" die im Reader standardmäßig aktiv ist... Dadurch wird das Dokument tlw. um die Druckränder verkleinert...

Naja, die aktuelle Implementierung schließt halt den Socket, was im Receive-Thread zu ner IOException führt ^^ Deswegen meinte ich unsanft, grundsätzlich erfüllt es aber den Zweck eines Close. Close kommt auch der Standard-namensgebung in .NET am nächsten ^^

@Borg: Deswegen habe ich ja jederzeit das Hintertürchen offen gelassen, dass man int haben kann wenn es auf 100% Präzision ankommt. Aber Holy hat halt recht, dass schon alleine durch die Messungenauigkeit jegliche Vergleiche mit == halbwegs unsinnig sind. Ich behaupte noch immer ganz dreist, dass in 99% der Anwendungsfälle die float-genauigkeit ausreicht und dort eine bequeme Programmierung den Verlust rechtfertigt. Ich finde es btw. auch Klasse, dass ihr euch schon Gedanken gemacht habt, dass eben nicht mal eben fix alles nach Gleitkomma gewandelt wird. Vielerorts wird dieses Problem auch gerne weg-ignoriert.

Es ist auch nur eingeschränkt möglich den C-Code für den PC mal eben einfach auf den Brick zu Portieren. Zum einen bietet der Brick viel weniger Luxus was das Programmieren an sich betrifft, zum anderen hast du auf dem Brick ja auch viel weniger Ressourcen (Speicher, Rechenleistung). Deswegen bringt es aus dieser Richtung keinen Vorteil deine "normalen" TF-Programme in C zu schreiben, da würde ich dringend zu was leichtem raten, Java ist z.B. okay ^^

Mach mal statt JoinThread ein Destroy auf der IPConnection, dann müssten die beiden Threads von ihr sterben gehen, die sind nämlich keine Background Threads und verhindern somit, dass das Programm sich beenden kann. Destroy würgt die IPConnection einfach ganz unsanft ab und dann sollte Ruhe im Karton sein

Na dann Fallback Fallback ^^

Wie gesagt, ich möchte die Übertragung überhaupt nciht ändern, nur das was die Bindings ausgeben. Und das auch eigentlich nur Optional, weil es ja schon sinnvoll ist nicht ins Gleitkomma-Milieu abzurutschen wenn man doch auf maximale Präzision angewiesen ist. Für einen Haufen EInsatzzwecke ist es aber einfach umständlich immer "per Hand" umzurechnen.