strex

Hi Leute, ich hab mal wieder Hardware übrig, die ich aktuell nicht benötigt. Eventuell kann ich damit ja wen erfreuen. Folgendes steht zum Verkauf: 1x IMU Brick 2: 50€ 1x Ethernet Master Extension (without PoE): 30€ 1x Servo Brick: 40€ 1x IO-16 inkl. Gehäuse: 12€ Zahlung per Paypal + Versand 4,99€ (DHL) Bei Interesse bitte bei mir melden.

Hi Leute, ich hab mal wieder übrige Hardware abzugeben, die ich aktuell nicht brauche nach einigen Tests - wurde einfacher realisiert als gedacht. Alle sind vollständig funktionsfähig und haben keinerlei Beschädigungen. Folgendes steht zum Verkauf: 1x IO-16 Bricklet mit Gehäuse + Kabel (1m): 16€ 1x Ethernet Master Extension ohne PoE Revision 1.0: 30€ 1x Servo Brick Revision 1.1: 40€ 1x IMU Brick Revision 2.0: 50€ Bei Interesse mir einfach eine Nachricht schicken. Vorzugsweise auch alles zusammen, dass spart Versand. Alles zusammen kann ich euch für 133€ inklusive Versand per DHL anbieten. Zahlung Paypal oder Überweisung. Grüße strex

Von möglichen Performance-Probleme sprechen und dann auf WLAN ausweichen ist echt gut. Wenn dann schon Ethernet, aber kein WLAN. Alleine durch CSMA/CA im WLAN kommen extra Latenzen dazu.

Oder wer nicht basteln möchte für 5 bis 10€ von der Bucht:

Jo die montierten Relais verwende ich auch. Gibt es auch zum Beispiel von Sainsmart massig auf ebay. Die gibt es auch mit solid State Relais.

Preis? Fertig als Treiber zum Anschließen gibt es das bereits für unter 15€. Zur Kühlung, kleiner aktiver Kühler und fertig. Ein großer Kühlerblock reicht auch für den passiven Betrieb. Müssen die Steckkontakte eben höher sein. Jedenfalls für die China Böller reicht ein passiver und die laufen ohne Probleme über Stunden. Warum man die Motortreiber nicht als Bricklet baut wundert mich seit jeher. Damit kann die Größe der Leistung anpassen und günstigere Kombos mit 2 oder 4 Treiber auf einem Board bauen. Dann können auch die Treiber direkt in der nähe des Motors betrieben werden. So muss man dann auch nicht die dicken Kabel des Motors bis zum Brick ziehen und holt sich damit auch nicht Störungen der IMU mit in's Boot.

@Nic Das ist auch mehr oder weniger von der Programmiersprache abhängig. Thread.sleep muss entsprechend kurz verfügbar sein. Bei 11000 Schritte/s sprechen wir ja auch von 0,091ms pro Schritt. Ich denke aber, dass maximal 1000 Schritte pro Sekunde möglich sind. Denn ich glaube das TF Protokoll überträgt auch nur 1000 Pakete pro Sekunde. Dabei darf man auch die Latenz bei der Übertragung nicht vergessen. Alternativ kann man die Treiber auch per PWM antreiben. Das geht zum Beispiel über das Servo Brick. Alternativ einfach für die für Treiber einen billigen Arduino mit serieller Schnittstelle. Den an den RedBrick und für die Motortreiber verwenden. So eine ähnliche Kombination habe ich für das auslesen eines Maussensors für die Bewegung. Das schafft das TF auch nicht. Für meinen Fall, 5NM pro Motor und über 50 KG für den Roboter reicht die Geschwindigkeit mit dem IO Bricklet völlig aus. Mehr konnte ich per PWM auch nicht wirklich bekommen. Ich steuere die Treiber mit je einem Java Thread an. Aber toll wäre ein Brick mit 5A Dauerlast schon. Da spart man sich die externe Steuerung. Nur leider billig sind die Bricks für den Schrittmotor nicht. Für 4 Motoren komme ich mit einem IO-16 und 4x TB6600 für 10€ viel billiger hin.

Also die ganzen Schrittmotortreiber mit TB6600 oder ähnlich wie dem HY-DIV268N-5A laufen mit dem IO-16 Bricklet sehr gut. Für jeden Schritt muss nur ein Puls über das IO-Bricklet erzeugt werden.

Kann ähnliches berichten, I/O-16-Bricklet an die IMU ganz oben im Stack und wird nicht am Master erkannt. I/O-16-Bricklet an den Master unten im Stack und das Bricklet wird erkannt wie alle anderen im Stack auch. Wenn das Bricklet an der IMU ist, kann es dafür sorgen das fast alle Bricklets am Stack nicht mehr erkannt werden. Die IMU selbst wird dann auch nicht mehr im Brickv angezeigt. Könnte natürlich auch daran liegen das unter der IMU auch ein Servo Brick liegt. I/O-16-Bricklet am Servo und es läuft ebenfalls. Ich habe es nur lösen können in dem ich an die IMU kein I/O-16-Bricklet anschließe. Firmware ist überall aktuell. edit:// IMU (v2) mit I/O-16-Bricklet im Stack und USB an der IMU statt am Master und nur die IMU mit dem I/O-16-Bricklet wird erkannt. Also ok. Scheint so auszusehen, als denke die IMU mit einem I/O-16 das es alleine im Stack ist und stellt die Stack Kommunikation ein, direkt selbst kann es aber mit dem I/O-16 kommunizieren. I/0-16 irgendwo anderes als an der IMU und alles läuft. Kann also das Servo Brick ausschließen und den Fehler auf I/0-16 und IMU eingrenzen.

Hi, da einige wie ich hier an den Rovers mit Tinkerforge Module basteln, gibt es aktuell ja fast alles. Eines fehlt aber, um den korrekten Weg zu bestimmen der auch wirklich zurückgelegt wird nutzen viele Encoder oder co. um die Drehzahl der Räder zu bestimmen und von dort den zurückgelegten Weg zu berechnen. Das ist aber nicht wirklich genau, mit der Kombination aus Encoder und IMU ergeben durch Messfehler ala Schlupf oder der Integration der IMU Werte größere Abweichungen, wenn man es nicht immer wieder per GPS korrigiert. So ist dann natürlich eine Indoor-Navigation auch mit Lidar und Odometrie ziemlich ungenau. Um das auszugleichen bastel ich aktuell mit Maussensoren die schön über SPI Delta X, Y liefern und somit auch den zurückgelegten Weg. Damit lässt sich die Navigation per Lidar und Maussensor perfekt in SLAM integrieren. Dazu habe ich diesen Optical Flow Sensor (http://copter.ardupilot.com/wiki/common-mouse-based-optical-flow-sensor-adns3080/) verwendet, der schön eine exakte Wegemessung erlaubt und die Navigation um größere Faktoren verbessert. Unschön ist das ich nicht einfach im Red Brick per SPI koppeln kann. Somit muss ich über einen FDTI USB to SPI erst eine Bridge bilden. Perfekt wäre also dann ein Bricklet das einen ADNS, am Besten den ADNS 9800, einbindet und die Daten bereitstellt. Bricklet sollte sich einfach bauen lassen, da der Sensor ja direkt per SPI erreichbar ist. Dazu noch ein paar Wechsellinsen als Zubehör die bestimmte Fokusbereich liefert. Das dürfte einigen hier die mit Encoder und co. die zurückgelegte Strecke messen ziemlich helfen und lässt sich auch für andere Zwecke verwenden.

Also ich würde das etwas anders aufziehen und die Idee von Equinox aufgreifen. Warum braucht jedes Bricklet (Sensor) ein Master + Funkstrecke? Besser wäre doch ein Wifi Bricklet Extension für einen Stappel mit Master zu entwickeln, dass alle Daten der externen Bricklets einsammelt und zum Master des Stapels liefert. Es ersetzt dann das Kabel zwischen Bricklet und Master. Also statt einer dezentralen Aufteilung mit Master pro Bricklet, einen Master und ein Funkmodul mit vielen Bricklets. Würde viel billiger kommen, weil nur ein Master im Stappel gibt und die Bricklets nur ein Funkmodul ala Remote Bricklet Extension. Dieses könnte man dann auch mit mehr Ports ausstatten. Als Bilddarstellung: Stapel: (<->: Steckverbindung) Master<->Bricks<->Wifi Bricklet Extension Sensor 1: (<++>: Kabel) Remote Bricklet Extension (Wifi)<++>Bricklet Sensor 2: (<++>: Kabel) Remote Bricklet Extension (Wifi)<++>Bricklet Hier haben wir dann ein Stapel mit Master, Bricks und der Wifi Bricklet Extension. Der Master in diesem Stapel verwaltet alles. Die Sensoren 1 und 2 werden über eine Funkstrecke (Bluetooth, Wifi,..) an den Stappel per Remote Bricklet Extension angebunden in dem dies das Kabel zwischen Bricklet und Master per Funk ersetzt. Im Brick Viewer würde ich jetzt auf den Master im Stapel verbinden und alle Sensoren die über die Wifi Bricklet Extension angebunden sind sehen. Wäre doch die Beste Lösung, Bricklets brauchen kein Master also ist die Remote Bricklet Extension billig. Soll ja nur das Kabel ersetzen. Wenn ma jetzt weiter denkt kann die im Stapel befindliche Bricklet Extension statt Wifi auch Ethernet oder Rs458, so lassen sich die Sensoren billig von extern anbinden ohne einen Stapel oder Master beim Sensor zu haben. Die (Wifi) Bricklet Extension kann man dann mit Akkuanschluss und ohne anbieten. Dann sollte man doch weitere Sensoren für um die 10€ anbinden lassen, weil man sich die ganzen Master spart.

Hi, Leute wie man sieht bin ich ja mit dem Roverbau ziemlich beschäftigt. Auch wenn es nicht so aussieht habe ich mich in den letzten Monaten ziemlich intensive mit der Entwicklung beschäftigt und sehr weit gekommen. Ich bin jetzt aber an eine Grenze gestoßen, bei der ich leider von den Tinkerforge Modellen absehen muss. Ich möchte gerne Bilderkennung und einen Laserscanner implementieren, dass können die kleinen Bricks leider nicht leisten Aus diesem Grund steige ich direkt auf Microcontroller um. Aus diesem Grund werden einige Bricks und Bricklets frei. Eventuell such ja aktuell einer günstige Hardware. Hardware ist weder beschädigt noch verhunzt durch Löten oder ähnliches. Folgendes steht aktuell zur Verfügung und sucht einen neuen Besitzer: 1x Masterbrick 2.0 2x DC Brick 1x Wifi Master Extension 1x Servo Brick 2x Analog IN 1x LCD 20x4 Bricklet 1.2 1x IO-16 1x Step Down Sollte wer Interesse daran haben, einfach mit Preisvorstellung eine PM. Ich denke da lässt sich eine Lösung finden, obwohl ich Sie ungern hergebe. edit:// Verkauft!

Bei uns sind Bewegungsmelder verbaut und bis dato ist noch nie das Licht ausgegangen. Dürften aber auch über den Kabinen hängen. Wer das entgehen will, kann auch gerne Temperatursensoren von Alarmanlagen verwenden. Die die Raumtemperaturen überwachen, sind aber nicht billig.

Ich würde ein Bewegungsmelder verbauen (gibt´s wie Sand am Meer) der mit einem Schaltkontakt oder Relais ausgestattet ist, das nicht 230V schaltet sondern die eigene Versorgungsspannung. Wenn das zu teuer ist, einfach an den 230V Schaltkontakt ein passendes Relais/Schütz anschließen. Dann das ganze an ein IO Bricklet und fertig. Alternativ könnte man per AnlaogIN auch die Spannung der Überwachungsled prüfen, die geht in der Regel an wenn das Licht geschaltet wird. Die etwas teurere Variante wäre ein Radarsensor, macht aber dasselbe. Vorteil der Lösung ist das auch unabhängig vom Licht der Zustand gemessen werden kann und somit eine zuverlässige Prüfung ermöglicht.

Es geht weiter, hauptsächlich mechanische Updates und eine Sensordarstellung in der Software. 3x IR 4-30cm (vorne), 1x 20-150cm (am Sensorarm) und 2x Ultraschall 6,50M Sensoren (am Sensorarm und hinten) sind nun verbaut. Auf das IMU warte ich gerade noch, bis das verfügbar wird.