benatweb

Hehe, das wollt ich auch schon bauen Sogar recht einfach in der Umsetzung, es gibt ja den Pibow, da müsste man bloß eine Austausch-Bodenplatte basteln, die seitlich unter dem Pi rausragt und dort Platz für einen Stack bietet. Zum SD-Karten-Logger: Sehr schön, den hätte ich mir auch als nächstes gewünscht.

Nein, auf den Bricks läuft eine in C geschriebene Firmware. Python ließe sich über einen Interpreter auf dem Brick (oder evtl. einem Python -> C Übersetzer) nutzen. @equinox Das selbe gilt aber ganz genauso für Python. Und es wurde ja schon gesagt, das Java wenn dann nur langsam auf den Bricks möglich wäre. Ich sehe da keinen guten Grund für. (Außer dass es für einige die vertraute Sprache ist)

Thinking of it, I like the idea of having some possibility to differentiate multiple bricklets of the same type in brickv. No need for multi line tabs, just add the UID behind the type of the bricklet in brackets. Would be nice to have.

Also ich bin auch dafür, hohen Nachrichtendurchsatz zu haben, allerdings meiner Meinung nach nicht auf Kosten der OnDevice-API. Heißt, ich wäre eher dafür zweistufig in naher Zukunft überhaupt eine API zu haben auch wenn sie nicht schneller als jetzt ist und eine neue Firmware erst danach anzugehen. Ich geh ja mal davon aus, die komplette Firmware neu zu schreiben ist für Tinkerforge auch mit einem gewissen Risiko verbunden. (Die Zeit, die das braucht gibt es ja weiterhin keine OnDevice-API und das wird sicher auch sonst Ressourcen abziehen)

Ich unterschreibe FabianB's Ausführungen einfach mal, besser könnt ichs sowieso nicht ausdrücken. Letztendlich geht es bei der OnDevice-API ja schließlich darum, dass man anstatt Tinkerforge am PC nur noch Tinkerforge allein hat. Letztendlich wird man also in den allermeisten Fällen außer sicher ein paar math. Berechnungen beim Programmieren nicht mehr als Tinkerforge-Funktionen brauchen. Und dafür ist es nunmal herzlich egal, was unter der API für eine Programmiersprache liegt, mit der hat man ja dann (bis auf die Syntax) fast nix zu tun. (Ich programmier seit ner Weile Arduinos - mehr als die Arduino-Referenz hab ich dazu nie gebraucht...) Klar ist C keine einsteigerfreundliche Sprache, klar wäre Java auf dem Brick langsam, usw. Aber wenn Tinkerforge darüber eine sinnvoll gebaute, gut dokumentierte und einfach zu benutzende API legt, haben wir mit dem darunter glaube ich nicht viel mehr zu tun als jetzt, wenn wir das nicht wollen. Wäre ich dafür. Edit: @borg Könntet ihr dafür nicht ein Tool anbieten, das man mit seinem Quellcode (einfach reinkopieren) füttert und das dann den Quellcode mit der Firmware und was sonst noch dazu muss zusammenführt und auf den Brick schreibt. Also quasi analog zur Arduino-IDE. Oder ist das zu viel Aufwand?

Was wäre in dem Fall denn mit dem bisherigen Modell über USB und Bindings, das klingt ja so, als würde das dann wegfallen?

Ihr hattet doch mal gesagt, ihr würdet bei der On-Device Geschichte erstmal abwarten wollen, bis das Arduino-Team den Due fertig hat, weil der nen ähnlichen ARM-Core hätte und ihr evtl. von deren Arbeit was übernehmen könntet. Mittlerweile ist der Due ja draußen, habt ihr euch das nochmal angeschaut oder ist das ne Sackgasse? +1 Persöhnlich würde ich auch eher zu C tendieren, das "passt" einfach mehr zu On-Device. Allerdings sollte es dann leicht verständlich aufgebaut und gut dokumentiert sein (Arduino ist da ein gutes Vorbild). Wenn es allerdings "kryptisches C" werden sollte, dürfte das viele abschrecken. Edit: Würde das dann bedeuten, das wir quasi unsere eigene Firmware schreiben würden? Also eure als Basis nehmen, unser Programm da reinbauen und dann flashen? Das fände ich dann nicht so gut. Das würde ja unter anderem Firmware-Updates richtig kompliziert machen. Da würde mir dann der python-Ansatz (mal unabhängig von der Programmiersprache) besser gefallen, eigenes Programm schreiben, auf den Brick spielen und das existiert da unabhängig von der eigentlichen Firmware und wird von der nur ausgeführt. Hab ich das so richtig verstanden?

7,5m? Das wär mir allerdings was wert, im Vergleich zu den IRs ist das ja ne ganze Menge. Ich würde aber mal sagen, (deutlich) über 50€ sollte es trotzdem nicht kosten.

Ich würde mal sagen, das hängt von der Genauigkeit ab. Wenns genauso genau ist wie das Distance IR Bricklet, würd ich auch nicht viel mehr Geld für ausgeben wollen. (Oder unterscheidet sich die Technik der beiden so sehr? Das IR ist ja empfindlich gegenüber Lichtstörungen, aber sonst messen beide doch nur Entfernungen...) Für nen sehr genauen Sensor würd ich natürlich entsprechend auch mehr ausgeben.

Bezüglich Starterkits ein konkreter Vorschlag: Als ich das erste Mal von Tinkerforge gehört hab, war ich ein Informatikschüler mit halbwegs passablen Programmierkenntnissen und in Physik hab ich mich bei nem Experiment mal gefragt, was denn eigentlich diese "Masse" in dem Stromkreis sein soll. Mittlerweile studiere ich Elektrotechnik, hab immer noch halbwegs passable Programmierkenntnisse und bastle nebenbei an ner Schrittmotorsteuerung für nen Plotter. Nachdem ich mich jetzt seit über nem Jahr mit der Thematik beschäftige, weiß ich, wie ich Schrittmotoren einschätzen kann, wie ich Motor und Controller passend zueinander aussuchen muss und was für ne Stromversorgung ich dem ganzen mitgeben muss. Der Informatikschüler vom Anfang weiß nicht mal so wirklich was ein Schrittmotor ist, aber Tinkerforge programmieren ist kein Problem. Was ich mit der kleinen Geschichte sagen will: Der Informatikschüler wird genausoviel Spaß damit haben, einen Schrittmotor drehen zu sehen wie der Elektrotechnikstudent, nur ihm fehlt all das Wissen, die Teile zu beschaffen, die er dafür braucht. Tinkerforge leistet hier schon einen großen Teil, indem der Schrittmotortreiber hier sowohl elektrotechnisch einfach zu handhaben als auch leicht zu programmieren ist. ABER: Wie schon cfranz geschrieben hat: Softwareleute finden Tinkerforge cool, weil sie damit einfach "aus ihrer Welt heraus" Hardware ansteuern können. Genau für diese Leute wäre ein Schrittmotor-Starter-Kit perfekt, das aus einem Stepper Brick, einem Schrittmotor, einem passenden Netzteil und allen nötigen Kabeln (+ DC Jack Adapter). Einfach zusammenbastlen, anschließen, schon dreht sich da was. Schnelles Erfolgserlebnis und danach noch jede Menge Langzeitmotivation kreativ zu werden und eigene Ideen umzusetzen. Momentan ist da als Neuling noch jede Menge Einarbeitung nötig, bis sich endlich der Motor dreht... Analog dazu natürlich könnte man das auch z.B. fürs Servo Brick machen oder auch den IO-Bricklets einfach noch ein paar LEDs beilegen, dann kann da direkt was losblinken. Ne gut bebilderte Anleitung dazu, evtl. noch für den Druck aufbereitet ("alte Schule" bekommt da ne vollkommend neue Bedeutung ) eignet sich sowas auch super für den Bildungsbereich.

Hi, I don't know if this will work with the Tinkerforge Bricklet-cables and the LCD-Bricklet, but there are Step-Up-Converters (similar to the Step-Down-Power-Supply, but instead of converting some voltage to a defined lower voltage, their output voltage is higher than their input voltage), e.g. this one. So if a longer cable does not work out, you might want to try putting one of them in beetween if the voltage drop turns out to be to high. (I'm not sure if it can output enough current for the LCD-Bricklet though.) Or maybe you can add a 5V Power Supply in your kitchen to power the LCD from separately (connect the power cables on the LCD-side of the cable to the power supply instead of the stack), but you'll have to ask the Tinkerforge guys about that, not sure if this will cause problems.

Idee: In der Arduino-Welt recht verbreitet sind ja die XBee-Module. Da gibt es dann Shields für den Arduino, in die man die eigentlichen XBee-Module steckt. Die Shields scheinen nicht viel mehr zu machen, als nur die passenden 2mm-Header und 3.3V für die Module zur Verfügung zu stellen, die Logik steckt im Funk-Modul selbst. Diese Module liegen so bei 20-30 €, Shields gibts ab ~10 €. Wäre es denn von Tinkerforgeseite aus möglich, einfach so ein "Shield" zu entwickeln, in das man dann XBee-Module stecken kann?

Also was Schrittmotoren für leichte Lasten angeht, findest du bei watterott deutlich mehr. Ich hab die für 10,16 € bei mir im Einsatz, die ziehen gar net mal so schlecht und vor allem der Preis ist natürlich attraktiv Letztendlich hängt es halt vom zu bewegenden Gewicht ab, wenns wirklich nur zwei Servos sind, langt so ein kleiner schon, ansonsten schau dich einfach mal in der Region bis 0.5 Nm um, das sollte auf jeden Fall genug dafür sein.

Hi, I just added an English translation of the wishlist to the wiki. http://www.tinkerunity.org/wiki/index.php/EN/Product_Wishlist Edit: Also added tips and tricks.

Also ich hab mir zu dem Zweck einfach selbst was aus Holz gebastelt. Einmal in klein mit Platz für Brick und zwei Distance-IRs und dann noch die große "Testprojekte-Platte" mit drei Stackplätzen und 4 noch zu bohrenden Brickletbereichen, jeder mit Bohrungen passend für alle Bricklets. Funktioniert super, man muss nur recht genau bohren.^^ Die Schablone kann ich bei Interesse mal posten, ist aber kein Glanzstück, geht sicher noch mit weniger Löchern und kompakter.

Schließe mich auch an, hätte gern noch ein paar Chibis mehr gekauft.

Also eine Bridge ist da gar nicht nötig, der Raspberry Pi ist ja (halbwegs) ein ganz gewöhnlicher Linux-PC mit USB-Anschlüssen, das funktioniert wie jetzt auch schon. Und fernsteuern des brickd über Ethernet von entfernten Rechnern geht auch schon, so laufen z.B. die Android-Bindings. (müsste man dann durch den Router nach außen leiten, falls man per Internet steuern will.) Aber ne Möglichkeit die Bricklets direkt an den Raspberry Pi anzuschließen wär in der Tat interessant, nur gibts dann halt nicht den Komfort der TF-API, sondern man muss die Ansteuerung selbst schreiben. Edit: Das sollte jetzt auch schon (zwar etwas umständlich) über das Breakout-Bricklet möglich sein.

Haha, cool das das hier so gut ankommt @The_Real_Black Das Bild, das da noch ein Brickletkabel angeschlossen den Arm hoch läuft ist mir auch schon die ganze Zeit im Kopf rumgespukt (sozusagen als zweite, "externe Nervenleitungen", was ziemlich interessant ist), nur mehr Gedanken zu hatt ich mir nicht gemacht. Aber die Idee ist cool, gefällt mir gut. Wär auch als Projekt gut umzusetzen.

Ist zwar sicher nicht die Art Verwendung, für die die Dinger vorgesehen sind, aber ich hab beim Auspacken meiner ersten Lieferung schon direkt gedacht, die sehen eigentlich besser aus, als dass sie ausschließlich in irgendwelchen Basteleien verschwinden sollten. Großes Lob an der Stelle an das Tinkerforge-Team, das Design ist euch echt gut gelungen, sowohl visuell als auch vom Konzept und Bedienung. Nachdem ich die Bricklets ne Weile in der Hand hatte, ist mir irgendwann die Idee gekommen, ein Armband draus zu machen. Kurzerhand grad nicht benötigtes Ambient Light-Bricklet geschnappt, als provisorisches Band paar Haargummis zerschnitten und verknotet, fertig. Sieht stylisch aus, ist gar nicht mal teuer und gefällt mir persöhnlich auch weit besser als das meiste Zeug, was man sonst so an sich rumtragen kann. Hat sich jetzt auch seit zwei Wochen schon im Praxiseinsatz bewährt, nur die Bebänderung lässt mittlerweile nach, da muss was ordentliches dran.^^

Farnell hat mir Ende Juni als Liefertermin genannt, mal schauen.^^ Allgemeine Verfügbarkeit sollte dann so ab August/September gegeben sein, dann sollte die Produktion genug laufen.

Um mal wieder zum Thema zu kommen: Hier hockt ein noch ein TF-Begeisterter in der Pfalz. Und bin grad im Loch zwischen Abi und Studium.^^

Hm, da stimmt was nicht. Soweit ich weiß, sollte es doch einmal Projekte geben für "richtige" Anwendungsprojekte mit TF (Roboter, Wetterstation, Dachfenstersteuerung, usw.) und in der Code-Sammlung sollten Code-Snippets, Beispiele und so weiter gesammelt werden. Wenn ich da richtig bin, wär das Projekte in der Codesammlung da falsch.

Von der Struktur passt das jetzt alles so mMn, gute Arbeit. Was ich noch verbessern würd: Momentan sieht man in der Codesammlung einfach nur die Unterkategorien, aber nicht, was jeweils in denen zu finden ist. Fänd es ganz gut, wenn das direkt auf der Codesammlung aufgelistet ist, z.B. so: PHP: -PHP-Projekt 1 -PHP-Projekt 2 -noch ein PHP-Projekt Python: -ein Python-Projekt -und weils so schön ist: noch eins C#: -ja, auch hier wieder was -[Anfänger] Erstes C#-Tutorial usw. Ansonsten ist das Layout ja momentan, sagen wir mal, zweckmäßig. Können wir denn da direkt was dran ändern oder ist das vmtl. Adminsache? Selecht Language würde ich z.B. rechts oben positionieren (Seitenübergreifend, also wie bei der normalen Wikipedia), Startseite würd ich (wieder wie Wikipedia, bzw. besser beim Raspberry Pi-Wiki) mit solchen Kästen für die einzelnen Kategorien machen, usw.

So viel Bewegung seit vorhin, respekt.^^ Schaut alles schon ganz gut aus. Code-Kitchen ist ja jetzt eig. obsolet, oder? Die Verlinkung auf die einzelnen Kategorien ist ja eher was für die Hauptseite.

Wenn wir bei "Haus der Zukunft" sind, würde mir noch eine Anbindung ans Smartphone/Tablet einfallen. Also z.B. eine Art "Steuertafel"-App mit Anzeige von Sensorwerten, Zuständen (z.B. Jalousie auf/zu), etc. und manuellen Steuerungsmöglichkeiten für die Aktoren. Vom Sofa aus bequem das Licht ausmachen, die Heizung hochdrehen und mal eben noch schnell das Dachfenster zu machen, quasi "das ganze Haus mit nur einer Hand kontrollieren". Ist glaub ich auch als Motivationsgedanke für die Schüler nicht zu verachten, die sind ja grundsätzlich allem zugetan, was einen faul sein lässt