Nic

Wenn es so ein Encoder-Bricklet geben sollte, müsste aber die Verbindung bzw. der Soll-Ist-Datenstrom direkt an das DC-Brick bzw. Motor gehen. Ich persönlich hätte sonst Magenschmerzen , wenn der Datenstrom erst über Umweg des (langsamen) USB und Host-Systems verarbeitet und wieder den "langen Weg" zurück zum DC-Brick geht. Was die zuverlässige und schnelle Steuerung von Motoren angeht, kann es mir nicht echtzeitnah genug sein. Es sind Pläne bekannt wonach der direkte Datenaustausch zw. Brick und verknüpftem Bricklet möglich werden soll. Bessere Voraussetzungen wird m.E. auch das OnDevice-Programming schaffen. Also das direkte Progr. der Bricks. Beides ist aber (noch) Zukunft.

Möchte den neuen LCD 20x4 plus Joystick-Bricklet als quasi Fernsteuerung benutzen, also kabellos via Master 2.0 und einer Chibi-Extension. Die Versorgungsspannung dabei über USB und externem Akku 5,2V. Reicht das für alle Komponenten aus, oder wie hoch darf die Spannung am USB-Port des Stacks maximal sein ? Für ein Power-Supply ist leider kein Platz.

Würde alternativ ein Schrittmotor nicht ausreichen, wenn es um genauere Positionsbestim. geht als mit einem DC-Motor ?

Very interesting idea, but what I dont understand how you will get a very precise position for stack A at first ? And that brings me to a next general question to TF guys about the coming soon GPS-Bricklet if it will accept and receive data from Galileo and/or Glonass System and combine it with Navstar ?

Ich würde eher schreiben: "Dies kann in jeder der unterstützten Programmiersprachen geschrieben werden. In diesem Tutorial wird exemplarisch Python verwendet." Es ist Geschmackssache, ob Python einfach zu lesen und zu verstehen ist. Für mich wäre dies Delphi bzw. C# bzw. Java etc. Für jemand anderes könnte es eher C oder C++ sein.

Das passt schon, danke und Gruß.

Das Objekt IPConnection instanzieren und anschl. enumerate aufrufen, damit wird der Enum-Callback pro Brick/Bricklet ausgelöst. http://www.tinkerforge.com/doc/Low_Level_Protocols/TCPIP.html#enumerate

Möchte das o.g. Kabel am neuen LCD 20x4 Bricklet 1.2 unter rauen Klimabedingungen verwenden. Welcher kleinste Biegeradius des Kabels (ohne Bruch) ist möglich? Wenn es geht bitte auch eine Empfehlung für externe, robuste Taster zum Anlöten.

@neomutant Not really, most people here are not familiar with any rendering stuff, but you are welcome to share your experience especially and at best Tinkerforge stuff combined with your favourite graphic engine. I assume most people can understand you if you write down your postings in pure English. @rif Danke für den Hinweis, probiere das mal am WE aus wenn mich meine Familie lässt . Mein IMU könnte mal ein bisschen Beschäftigung brauchen...

Ich vermute mal mit VisualStudio von M$ wird man für das C#-Scripting in Unity nicht weit kommen, braucht man dafür zwingend Mono ? PS: Kann ich selber beantworten, geht anscheinend auch mit VS: http://docs.unity3d.com/Documentation/Manual/VisualStudioIntegration.html

Hört sich sehr interessant an, berichte hier ruhig weiter über Deine Ergebnisse. Zu C# und im speziellen die C#-API zu Tinkerforge-Produkten gibt es hier reges Feedback - einen der Experten hast du weiter oben schon kennengelernt - , da wird Dir sicher geholfen wenn es mal nicht weitergehen sollte. Zu Deinem Wissen würde ich nicht so tief stappeln, immerhin scheinst du konkrete Vorstellungen zu haben. Ich vermute mal um Unity handelt es sich um Echtzeit-Rendering mit der Option externe Hardware zum Steuern des Viewpoints/Standpunkts anzusprechen. Das was Du mit Kamera erwähnst, meint sicher eine virtuelle Kamera(-fahrt), richtig ? Hmmh, ich vermute es ist das hier: http://de.wikipedia.org/wiki/Unity_(Spielengine) Die Basisversion scheint kostenlos, Programmiersprachen C#, C++ und Javascript(!), hat also mit Java nix zu tun.

Prima. Aber ich werde ev. wieder die Schraubklemm-Blöcke nehmen, rechtwinklig zu den Lötpunkten, so ähnlich habe ich das schon problemlos beim Stepper-Brick praktiziert. http://de.rs-online.com/web/p/leiterplatten-printklemmen/7176634/

Prima, danke. Die Lötpunkte für eigene Taster sind äußerst praktisch, in welchem Rastermaß liegen die Lötpunkte zueinander ?

Sorry, aber welches neue Display ? Das ist bisher an mir vorbei gegangen Würde aber prima in meine Wunschliste für den Weihnachtsmann passen...

Seltsam. Ich habe hier nicht nach Code-Übersetzungen von x nach y angefragt, noch dazu aufgefordert. Oder anders gesagt, dass was borg als Hinweis mitgegeben hat, habe ich nur in anderen Worten gefasst. Gibt also keinen Grund hier was auf die Goldwaage zu legen, noch mit Bestürzung zu reagieren, macht sich auch nicht so gut für die Lesbarkeit und das Feedback des eigentlichen Thread-Themas, denn für ein paar spannende Infos zu Unity3D hat es hier noch nicht gefruchtet.

Ist mit dem GPS-Bricklet bzw. dessen Bestellbarkeit noch innerhalb der Discount-Zeit zu rechnen ?

Lieber Kollege AuronX, lies bitte genauer mein Posting. Und mit in ist also der Threaderöffner gemeint. Vom Threaderöffner Infos zu Unity3D.

In der Tat sehr interessant, BastianR. Könntest Du uns bitte einige Grundlagen zu Unity3D vermitteln. Nun der Code in C# ist ja fast fertig vorhanden. Du müsstest das einfach nur in Java übersetzen.

@AuronX Dein Ping-Pong ist mir doch etwas zu verwirrend Zumindest skippi hat mich verstanden: Ja, und mit was wird dann so ein Pong ausgelöst ? Mit einem periodischen Callback im Master, wenn ich nicht irre... @mikrolinux Man muss hier unterscheiden zw. dem Konzept des Funknetzes via Chibi (das es nicht mehr gibt) und dem dezentralen WIFI. Für ersteres habe ich einen Master-Brick als Chibi-Master, der permanent zentral am Host-PC hängt, der sollte im Dauerbetrieb stabil bleiben. Und nur für diesen ließe sich bei Ausfall eines Funk-Slaves ein Reset auslösen. In Deinem Fall gibt es nur den Stack mit WIFI, also dezentral und dafür ließe sich software-seitig im Host-PC natürlich kein Reset auslösen. Es gibt einige Beiträge bzgl. Reconnect am WIFI, da bin ich nicht am laufenden, ev. gibt es dazu Änderungen durch das neue Protokoll: http://www.tinkerunity.org/forum/index.php/topic,895.0.html http://www.tinkerunity.org/forum/index.php/topic,867.15.html

Dann lass die Callbacks erstmal beiseite. Wenn du in deiner Implementation periodisch abfragst und der Stack ist weggeraucht, solltest du eine Exception bekommen. Versuche beim Auftreten der Exception ev. ein Reset des Stacks auszulösen, das wiederum löst (hoffentlich) den Enum-Callback aus. Von hier erneut das Initialisieren etc. Öffne dann mal den Brick-Viewer und starte eine neue IP-Connection, zeigt der Viewer wieder den Stack an ?

Wenn man das so liest, bewundere ich eure Ausdauer und das Geschick sich zwecks eigenem FW-Build durch diese Materie zu graben. Für den Normalsterblichen reicht nicht die Zeit oder das Expertenwissen, wäre schön wenn ein ausführliches Tutorial irgendwann mal den Weg ins Wiki schafft.

Müsste man nicht wenn das von der TF-Hardware per Callback quasi autom. ausgelöst wird. Wenn du den exakten Zeitpunkt hast wenn der Stack ausfällt, warum löst Du dann nicht softw.seitig den Reset aus ? Was meinst du mit Initialisierung ? Nach dem Reset wird der Enum-Callback der IPConnection ausgelöst, könntest du dann nicht deine Init-Schritte ausführen ?

Ah, wir beide wieder. Gleiches Thema, gleiche Dis­ku­tanten Wie konnte skippi den o.g. Watchdog nur realisieren ? Dafür brauchte er einen Bricklet extra. Könnte nicht der Fall eintreten, dass man ev. alle Pins vom IO braucht etc. Ja dann wäre ein zentraler Callback im Master eine prima Ergänzung. Hast was gegen einen Callb. im Master einzuwenden ? Warum nicht ? Wenn dir ein Callback vom Master/Bricklet periodisch sozusagen mitteilt, der Stack ist noch da, und du beim Eintreten des Events (solange ein Verbind. bestand) einen eigenen Alarmtimer neustartest, also wie skippi beschrieb.

Gute Lösung des Watchdogs, skippi. Wesentlich besser geeignet scheint mir aber ein zentraler Callback im Master-Brick. Dann bräuchte man keine zusätzlichen Bricklets bzw. Bricks dafür zu "verschwenden" Nachteil aber bisher, der Master-Brick ist der einzige Brick der (noch) keinen Callback anbietet.

Über die WIFI-Extension sollte auch der Android kommunizieren dürfen. Bis jetzt gab es hierzu im Forum nur wenig Feedback was die Ansteuerung und Betrieb von TF-Sachen unter Android angeht, z.B.: http://www.tinkerunity.org/forum/index.php/topic,596.msg3604.html#msg3604 Verbesserungen, Ergänzungen oder Projektvorstellungen zum Thema Android sind aber bestimmt hier gern gesehen. Über deine Fortschritte kannst Du gerne im Forum berichten.