robin24

Hmm... Klar, so etwas kann wohl theoretisch immer mal passieren. Allerdings habe ich bei dem zweiten Brick ja auch alle Kabel problemlos einstecken können, ohne dabei irgendetwas zu beschädigen... Daher denke ich zwar schon, dass ich hier die notwendige Sorgfalt habe walten lassen... Aber klar, über so etwas kann man natürlich endlos diskutieren! :-) Vielen Dank, hab ich eben erledigt! :-) LG, Robin

Hi Bastian, erstmal vielen Dank für deine Antwort! Ja, du hast Recht... Es ist leider nicht nur einer, sondern 4 - 5 Pins in dem Steckplatz verbogen... Natürlich könnte ich jetzt versuchen, das wieder gerade zu frickeln... Allerdings habe ich den Brick erst vor einer guten Woche geliefert bekommen, und hatte an dem Steckplatz auch noch nichts angeschlossen... Der Brick wurde mir also so geliefert, mit dem unbrauchbaren Port... Könntest du mir daher evtl. sagen wo ich mich hinwenden muss, um einen Austausch zu veranlassen? Vielen Dank! LG, Robin

Moin, habe hier 2 Master Bricks, die zu einem Stack zusammengesteckt sind. Nun habe ich bei einem Brick ein seltsames Problem: in einen der Bricklet-Anschlüsse (Port A) lässt sich kein Kabel einstecken, ohne erkennbaren Grund... Ich kann das Kabel an jedem anderen Anschluss problemlos anschließen, auch mit anderen Kabeln habe ich es nun schon probiert. Es hilft alles nichts, irgendetwas scheint mit dem einen Anschluss nicht zu stimmen... Ist so ein Problem hier irgendjemandem bekannt und gibt es dafür irgendeine Lösung, oder sollte ich den Brick einfach zu TF zurückschicken? Vielen Dank schonmal für euere Antworten! :-) LG, Robin

Tja, da sind wir wohl beide nicht wirklich weit gekommen! Ist für mich jetzt aber halb so wild... Ich hab mich jetzt mal etwas mit den Python-Bindings beschäftigt und schon erste kleinere Erfolge damit erzielt, obwohl ich Python eigentlich gar nicht beherrsche... Ich denke, dass ich mir nun einfach noch einen Raspberry Pi auf's Mounting Plate schraube, dann den Brick dort anschließe und über den Pi die Sensoren einfach mittels Python auslese und weiterverarbeite... Für iOS-Apps kann ich dann was Eigenes entwickeln, dass eine TCP-IP-Verbindung zum Pi aufbaut und die aufbereiteten Daten abruft - wäre in meinem Fall wohl die vernünftigste Lösung! Natürlich könnte man auch einen RED Brick statt dem Pi benutzen, aber ich hab eh noch einen ungenutzten Pi bei mir rumliegen... :-) Auf jeden Fall vielen Dank für die Antworten! Viele Grüße, Robin

Hi Manni, vielen Dank für deine Antwort! Wenn ich in Objective-C programmieren würde, wäre das wohl die Antwort auf all meine Fragen... Da es hier aber um Swift geht, kann ich mit den Cocoa-Anpassungen so leider aktuell nichts anfangen, da diese in Objective-C geschrieben wurden und es sich hier um 2 verschiedene Programmiersprachen handelt. Mittlerweile hab ich auch mal versucht, die C-Bindings direkt mit Swift einzubinden, dass scheint aber leider auch nicht machbar zu sein. Soweit ich das verstanden habe, ist Swift zwar eingeschränkt kompatibel zu C-Libraries. Bei den Bindings von TinkerForge scheint es aber zu große Unterschiede zu geben, sodass nach meinen ersten Erkenntnissen wohl keine direkte Nutzung möglich ist. Einzige Möglichkeit wäre wohl, die Kommunikation direkt via TCP-IP abzuwickeln - das werde ich mir demnächst mal anschauen... Viele Grüße, Robin

Hi zusammen, ich beschäftige mich aktuell mit der Programmierung mit Swift unter Mac OS und iOS. Es würde mich nun sehr interessieren, ob jemand da schon Erfahrungen im Zusammenhang mit Tinkerforge hat, also der Steuerung von Bricklets mittels Swift-Programmen. Ich vermute, dass man wohl die C++-APIs verwenden kann, hab aber noch keine Erfahrungen damit. Ansonsten geht natürlich immer direkt TCP-IP, was aber von der Implementierung her natürlich komplexer ist, als wenn man direkt die Bindings verwendet. Gibt es hier schon Ansätze / Beispielprojekte in Swift? Danke auf jeden Fall für Tipps / Erfahrungen hierzu! Liebe Grüße, Robin

Hi Unex, vielen Dank für deine Antwort und dem Interesse daran, den Viewer zugänglicher zu machen! :-) Leider gibt es beim QT-Framework einige Probleme... Das grundlegende Problem hier ist wohl die Einbindung bestimmter APIs vom Betriebssystem, welche die Inhalte von Fenstern barrierefrei nutzbar machen. Dabei geht es nicht nur um die Auslesbarkeit / Bedienung mit Screen Reader wie bei mir der Fall, sondern auch um die Anbindung von anderen Bedienungshilfen wie z.B. Textvergrößerung für Menschen mit Sehschwäche. Jedes Betriebssystem stellt mittlerweile solche APIs zur Verfügung, die auch direkt von den nativen UI-Frameworks unterstützt werden. Wenn du z.B. unter Mac OS mit Xcode und Interface Builder ein User Interface bastelst, musst du dich nichtmehr groß um Zugänglichkeit für blinde User kümmern, weil das System die meiste Arbeit erledigt - das gilt, soweit ich weiß, auch z.B. für Visual Studio unter Windows. Bei QT ist es nun aber so, dass es ja ein komplett eigenes UI-Framework ist, welches seine eigenen APIs mitbringt und so wenig wie möglich auf Methoden des Betriebssystems zugreift, um plattformunabhängig arbeiten zu können. Somit müssten die Entwickler von QT eigene Schnittstellen einbauen, die QT-Interfaces für Screen Reader zugänglich machen. Die Vergangenheit hat aber leider gezeigt, dass denen Menschen mit Behinderungen wohl herzlich egal sind, leider muss man das wirklich so sagen... Es gab schon etliche Petitionen usw. zu dem Thema, die aber leider nichts Nennenswertes bewirkt haben. Es ist ab QT 5 etwas besser geworden, aber irgendwie scheint sich das auch von Interface zu Interface zu unterscheiden, sodass ich aus meiner Erfahrung leider keine konkrete Aussage machen kann. Vielleicht wäre es ja möglich, mal einen Test-Build mit QT 5 zu erstellen, den ich dann sehr gerne auf Bedienbarkeit testen würde! Allerdings weiß ich leider nicht, wie Aufwändig das ist und ob das schnell hinzubekommen wäre, da kennt ihr bei TF euch auf jeden Fall besser mit aus... :-) Prinzipiell würde ich persönlich dazu raten, QT auf keinen Fall zu verwenden und auf ein anderes Framework umzusteigen... Aber ich fürchte, dass so ein Schritt wohl zu Aufwändig wäre! Vielleicht wäre es ja aber auch machbar, die Konsolen-Tools noch weiter auszubauen, so dass z.B. Bricklets per Konsole geflasht werden könnten, oder andere Funktionen des Viewers auf diese Art nutzbar wären... Leider ist das alles, was mir dazu einfällt... Die Sache mit QT ist extrem schwierig, daher kann ich leider auch keine leicht umsetzbaren Ratschläge anbieten... Auf jeden Fall nochmal vielen Dank für dein Interesse, vielleicht lässt sich ja doch noch etwas machen! :-) Viele Grüße, Robin

Hi Loetkolben, vielen lieben Dank für deine weiteren Erklärungen, die mir wirklich sehr geholfen haben!!! Was das Tool zum Flashen betrifft, so hab ich grad mal bei mir nachgeschaut... Ich verwende hier Mac OS und auf meinen Server-Systemen wie geschrieben Debian Linux, Windows hab ich hier gar nicht in Verwendung und damit kannst du mich auch echt jagen... :-P Ich hab grad mal in das Paketverzeichnis vom Brick Viewer geschaut, den ich auf meinem Mac installiert habe. Leider scheint es dort keine Tools für die Kommandozeile zu geben, die sind also wohl Linux vorbehalten... Ist aber eigentlich auch kein Problem, da ich den Brick ohnehin an einen Raspberry Pi mit Debian hängen und auch von dort aus ansteuern würde, wo ich dann auch das Deb-Paket mit dem Kommandozeilen-Tool installieren kann. Es ist auf jeden Fall sehr schön zu wissen, dass man alles auch erstmal in Betrieb nehmen kann, ohne vorher noch zu flashen! Es ist mir aber natürlich klar, dass man nach Möglichkeit auf dem aktuellen Stand sein sollte, es ging mir hauptsächlich darum zu wissen, ob man vor der Inbetriebnahme noch zwangsweise alles flashen muss, was ja zum Glück nicht der Fall zu sein scheint! Dein grafisches Kunstwerk hat mir auch sehr geholfen, um alles nochmal genauer zu veranschaulichen - vielen Dank natürlich auch dafür! Ich denke dass ich nun genug weiß, um einen Einstieg zu wagen! Muss mir nur noch überlegen, welche Bricklets ich mir erstmal zulege, interessant ist ja irgendwie alles! :-) Auf jeden Fall nochmal vielen Dank für deine Tipps und Ratschläge, du hast mir damit wirklich sehr weitergeholfen!!! Liebe Grüße, Robin

Moin Loetkolben, vielen Dank für deine sehr ausführliche und hilfreiche Antwort!!! :-) Das klingt ja wirklich alles sehr einfach... Ich hatte es mir zwar auch ein Bisschen so vorgestellt, nachdem ich die Beschreibungen und Tutorials mal überflogen hatte. Allerdings wollte ich einfach auf Nummer sicher gehen, und da hat mich deine Antwort schon extrem weitergebracht! Nein, Strommodule und Servo-Steuerungen brauche ich aktuell wirklich nicht, würde im ersten Schritt wie gesagt erstmal gern ein paar Sensoren zum Laufen bekommen und die entsprechenden Daten auswerten und aufbereiten, um z.B. eine kleine Wetterstation zu realisieren. Danach kann ich mir ja noch überlegen, was mir sonst noch so in den Sinn kommt! :-P Zu den Kommandozeilen-Tools: könntest du mir da vllt. noch verraten, wo ich die finden kann? Im Downloads-Bereich hab ich erstmal nur den Brickd und den grafischen Brick Viewer gefunden, der sich ja leider für mich nicht nutzen lässt... Wie läuft das denn eigentlich genau mit den Firmwares, die man flashen kann? Haben die Bricks und Bricklets bei der Auslieferung schon eine Firmware drauf, oder muss man die zwangsläufig selber flashen? Es ist natürlich nicht so, dass ich im Fall der Fälle nicht auch auf sehende Hilfe zurückgreifen könnte, z.B. Familie oder Freunde. Allerdings versuche ich bei solchen Dingen nach Möglichkeit Mittel und Wege zu finden um es allein hinzubekommen, damit ich nach Möglichkeit auch selber damit "herumspielen" kann und z.B. ein Firmware-Upgrade auch selbst durchführen könnte. Auf jeden Fall nochmal vielen Dank für deine Antwort, du hast mir damit schon sehr weitergeholfen! :-) Viele Grüße, Robin

Hallo zusammen, und frohes neues Jahr allerseits! Ich interessiere mich schon länger für TinkerForge und die Projekte, die man damit realisieren kann. Allerdings hatte ich wegen Uni etc. bisher noch kaum Zeit mich damit zu befassen, was sich aber nun hoffentlich ändern wird! Erstmal ist es bei mir so, dass ich mich sehr für Computer und Technik interessiere, ich administriere mehrere (Debian) Linux-Server und schraube auch mal gerne an meinen Kisten herum, falls notwendig. Allerdings ist es in meinem Fall so, dass ich von Geburt an vollständig blind bin, und somit bei der Benutzung meines Computers, Handys oder anderer Geräte auf gewisse Hilfsmittel angewiesen bin, insbesondere sog. Screen Reader. Ein Screen Reader ist kurz gesagt ein Programm, dass den Bildschirm-Text ausließt und über eine synthetische Sprachausgabe vorliest, sodass man auch ohne zu sehen weiß, was gerade zu sehen ist. Außerdem wird die Bedienung durch zusätzliche Tastaturbefehle so erweitert, dass man den Rechner nur via Tastatur bedienen kann, da die Maus für Blinde schwer nutzbar ist. Unter Mac OS gibt es z.B. den Screen Reader VoiceOver, der bereits im Betriebssystem integriert ist und nur eingeschaltet werden muss, unter Linux gibt es hingegen Orca für den Gnome-Desktop. Nun würde es mich brennend interessieren, wie gut man evtl. als Blinder mit der Hardware von TinkerForge arbeiten kann, wobei hauptsächlich die Aspekte Handhabung und Software wichtig sind. Was die Handhabung betrifft würde es mich z.B. sehr interessieren ob es sehr kompliziert ist, die TinkerForge-Elemente untereinander zu verbinden. Wie schon geschrieben bin ich es z.B. gewöhnt, an meinen Rechnern herumzuschrauben, bin also recht vertraut mit technischen Basteleien. Am Anfang würde ich z.B. sehr gerne mal versuchen, wie in der Anleitung beschrieben eine Wetterstation aufzubauen. Hierbei würde ich allerdings das LCD-Display weglassen, da ich es ohnehin nicht ablesen könnte. Stattdessen hätte ich gern ein System, dass z.B. Daten an einen Raspberry Pi sendet, der mir dann die Daten mit selbst programmierten Scripts auswertet und anzeigt, z.B. via Web-Interface. Wäre das mit den TinkerForge-Komponenten schwer aufzubauen, oder muss man hier wirklich nur die Einzelteile zusammenstecken und fertig? Man kommt damit vollkommen ohne löten aus, ist das richtig? Was die Software betrifft, so muss man ja sowieso den Großteil selber programmieren und über die API auf die Daten zugreifen, die vom jeweiligen Brick geliefert werden - soweit kein Problem. Allerdings habe ich nun festgestellt, dass das Interface des Brick Viewers leider für Screen Reader nicht zugänglich ist, wahrscheinlich wurde hier QT für das User Interface verwendet... Gibt es daher irgendeinen Weg, am Brick Viewer vorbeizukommen? Ist es z.B. möglich, Bricks auch per Kommandozeile zu flashen? Sorry für den langen Post und die vielen Fragen, aber die Materie interessiert mich wirklich sehr und ich würde sehr gerne ins Basteln mit TinkerForge einsteigen! :-) Danke schonmal im Voraus für Antworten! Viele Grüße, Robin