Imbafestor

@Eule Siehe Seite 3 in diesem Thread für eine Arch anleitung. Schönen Gruß

Ich hab schon das ein oder andere mit XNA gemacht, das ist eigentlich recht schön. Zu managed dx kann ich nichts sagen Das Distance IR sollte hochkant gestellt werden, weil es sonst einen relativen großen Detektorwinkel (blödes Wort) hat, also es lässt sich nicht allzu genau messen imho.

Ja prinzipiell bräuchte ich den hier momentan nicht das stimmt, es sollte aber trotzdem funktionieren. Laut dem Quote kann also jeder Brick als "Master" auftreten, wenn er an unterster Stelle steckt. Das war wohl mein Fehler. Der Name MasterBrick implizierte in meinen Augen, dass er immer der "Master" des Stacks ist. So gesehen ist er also nur für mehr Bricklet Anschlüsse oder Chibi da? Ist das jetzt so richtig?

Ah danke für die schnelle Antwort, das hatte ich auch gelesen. Wie in der Ergänzung steht funktioniert es auch nicht, wenn ich ganz unten einen Stepp Down Brick einsetze, welcher ja glaube immer ganz unten sein muss. Edit: Ich habe auf den Reset Knopf vom MasterBrick gedrückt, jetzt scheint es zu funktionieren, wobei die blauen LEDs wie verrückt blinken Oo Bleibt nochj die Frage wegen des Position des MasterBricks

Hallo zusammen, da jetzt meine zweite Bestellung endlich eingetroffen ist habe ich gleich Tests durchgeführt. Bauteile in diesem Fall: - Servo Brick mit Akku - Servo an ServoBrick - MasterBrick mit Distance IR Wenn ich beide Bricks getrennt anschließe, werden sie korrekt erkannt. Wenn ich das ServoBrick über den MasterBrick anordne und mit USB ans Master gehe ist auch alles ok. Doch wenn ich das Master über das Servo anbringe erkennt er das ServoBrick nicht mehr. Ist das so gewollt, oder lässt das auf einen Defekt schließen? Schöne Grüße Ergänzung: Wenn ich einen Stack (von unten nach oben : Stepp-Down - Master - ServoBrick) aufbaue, Akku an das Stepp-Down und dann per USB an den PC anschließe, kommt im Windows die Meldung : "USB-Gerät wurde nicht korrekt erkannt"

Cooles Bild. Bei mir sieht es ähnlich aus Allerdings finde ich deine Idee, die Grundplatte mit den L-Profilen zu erhöhen nicht schlecht. Bei mir liegt die direkt auf und deswegen ist da kaum Platz. Werden wohl noch Ebenen dazukommen müssen^^ Am Ende müssen die Bricks, RaspPi, Akku, Webcam, Usb Hub und etliche Kabel drauf. Leider ist das Grundgestell so klein :/ Hast du mittlerweile eine Idee, wie du eine genaue Positionserkennung sicher stellst? Das ist in meinen Augen das größte Problem, wenn es um die Erstellung einer Karte geht. Schöne Grüße

Sieht alles sehr gut organisiert aus Eine Frage wirft sich mir jetzt auf zu: Worin besteht der Zweck den Speicher möglichst gering zu halten? Zum einen benötigt der GC ja auch Leistung, zum anderen wird er ja sowieso regelmäßig bzw. spätestens wenn Speicher benötigt wird, automatisch aufgerufen? Fehlt nur noch nen WebService, der alle Informationen zur Verfügung stellen kann für Apps etc Schöne Grüße

CamStudio ist gut, das hatte ich auch mal verwendet

Ich stimmt da kutte zu, du solltest auf jeden Fall IBOutlets verwenden. Dazu wechselt du einfach in den Assistenzmodus (glaube der hieß so) und ziehst dein Control in das .h file deiner klasse. Dabei wählst du dann Outlet aus und gibst ihm einen Namen. Anschließend überprüfen, ob im .m File ein @synthesize auf dein Outlet steht. Wenn dem so ist, kannst du jetzt in diesem File direkt über das Outlet auf dein Control zugreifen. Ich hoffe, dass ich keinen Mist erzähle, da ich mich nur mit der iOs Programmierung mit obj-c auseinandergesetzt habe, aber ich denke, dass es diesbezüglich identisch ist. @obj-c Die Sprache selbst ist einfach nur ein Graus. Das fängt mit der Syntax an und hört mit den "speziellen" Eigenschaften auf. Man kann sich letztlich auch nie sicher sein, dass eine Funktion auch wirklich aufgerufen wird (Message basiertes invoken von Methoden). Ist aber leider die einzige (vernünftige) Möglichkeit Apps zu programmieren.

Ich hatte mir direkt zu Beginn einen gesichert und bis letzte Woche gewartet. Letzte Woche Woche habe ich noch einen bestellt, der soll wohl KW 32 kommen. Andere Möglichkeit wäre ebay, da werden sie auch langsam bezahlbar, wenn auch teurer als der Originalpreis. Direkt auf dem Pi ausführen wäre natürlich praktisch, allerdings müsste man dann ja direkt dort coden oder die Programme ständig übertragen. Notfalls ist ändern auf Java kein allzu großes Unterfangen, wegen der ähnlichen Syntax. Allerdings hab ich keine Ahnung wie die Java Performance ist.

@Real_Black Es ist die Frage, wie du den Rasp einsetzen möchtest. Wenn du ihn nur wie ich, also als Wlan Brücke verwenden möchtest, gibt es ja nicht allzuviel einzurichten. Dadurch dass die Hardware ja überall identisch ist, gibt es auch für fast alles eine Anleitung Laut den Machern ist dies voerst nicht geplant. Im Fokus stehen jetzt erstmal Erweiterungen für den Pi. Ein Kameramodul wird ja bereits getestet. Ich habe es heute geschafft den neuen WLanStick zum laufen zu bekommen. Jetzt läuft also die Steuerung via brickd und das Streamen meiner ps3 Webcam über das WLan. Als letzten Schritt fehlt nur noch die unabhängige Stromversorgung via Batterie. Da muss ich allerdings noch auf die Teile warten.

Es wuerde auch nicht laufen, weil der SoC auf dem Pi nur ARMv6 unterstützt, wohingegen Win 8 ARMv7 benötigt

Für Debian gibt es bereits eine Anleitung, siehe http://www.tinkerforge.com/doc/Embedded/Raspberry_Pi.html

Nach einigem hin und her, habe ich es geschafft, brickd auf Arch Linux zum laufen zu bekommen. Für diejenigen, die es interessiert, so bin ich vorgegangen: - Laden vom ArchLinux Image von der Raspberry Pi Seite (http://www.raspberrypi.org/downloads) - Mit Win32DiskImager auf eine SD Karte kopieren - Starten und zuerst mit "passwd root" das root Password ändern. - Nun müssen die benötigten Pakete installiert werden. Dies geht mit: pacman -Syu pacman -S python2 pacman -S twisted pacman -S libusb - Anschließend läd man sich die Source Files von brickd hier herunter (https://github.com/Tinkerforge/brickd). Benötigt wird nur der Unterordner /src/brickd Ich habe die Dateien auf einem USB Stick gespeichert und dann auf RaspPi gemountet. Anschließen den Ordner in einen von mir erstellen Ordner kopiert. - Nun in das Verzeichnis wechseln und mit "nano brickd_linux.py" die Datei in einem Texteditor öffnen. Es muss die erste Zeile angepasst werden. Aus "#!/usr/bin/env python" muss "#!/usr/bin/env python2" gemacht werden. Dies sorgt dafür, dass brickd mit python verwendet wird. Nun mit Strg + X beenden und mit Y das speichern bestätigen. - Nun kann brickd mit "./brickd_linux.py" gestarted werden. - Um zu überprüfen ob brickd läuft, eignet sich der Befehl "ps ax". Dort müsste brickd aufgelistet sein. Ich musste den Pi erstmal neustarten und dann nochmal ausführen bis es ging. - Spaß haben! Nach dieser Methode muss brickd bei jedem Start manuell gestartet werden (denke ich zumindest). Um den Startvorgang zu automatieren, kann der Startbefehl in die Datei /etc/rc.local (mit nano) geschrieben werden. Dann wird der Code bei jedem Start ausgeführt. Ich hoffe, ich konnte helfen. Falls es Fragen dazu gibt, gerne her damit, bin aber selbst nicht der Linux Experte. Schöne Grüße PS: HotPlug funktioniert bei mir hier nicht bzw. bin ich mir nichtmal sicher ob es generell funktioniert. Ich habe die Bricks also die ganze Zeit angeschlossen

Hey, bin jetzt kein Python Experte, allerdings musst du die Callbacks nur einmal (vor der while Schleife) hinzufügen. Dann würde ich als nächstes überprüfen, ob die von dir definierten Callbacks (posi und cb_pressed) die korrekte Signatur (dh. die Argumente bzw deren Typen in Ordnung sind), siehe dazu die Doku (http://www.tinkerforge.com/doc/Software/Bricks/DC_Brick_Python.html#callbacks). Als nächstes mit dem Debugger überprüfen, ob er überhaupt in die Callbacks reinläuft. Sollte es noch fragen geben, einfach her damit, gibt aber bestimmt noch jemanden hier, der sich mehr mit Python auskennt.