raphael_vogel

Die Messe hört sich cool an.... Persönlich hätte ich auch nix dagegen mit euch was auszustellen. Weiss halt nur noch nicht ob mein Projekt (übers Internet gesteuerter Roboter) überhaupt interessant ist, und ob er diese Jahr noch fertig wird ;-( Hab halt momentan (leider) nur begrenzt Zeit zum basteln :-(

Hallo msa78 Ich hab den Dagu Wild Thumper allerdings nicht mit 6 sondern mit 4 Rädern. Der ist billiger. Da mein Roboter auch noch andere Servos hat (z.B. IP Kamera mit Pan/Tilt Rotate Einheit) hab ich mich für den Servo Brick + ESC entschieden. Bin sehr zufrieden damit. Mein ESC: http://www.pololu.com/catalog/product/777 Der Wild Thumper ist sehr stabil und ich bin voll zufrieden. Du solltest beim Getriebe auch auf die Übersetzung achten. (Ich hab die 1:75) Bin auch gerade dabei eine Ladestation zu bauen, an der er sich wieder aufladen kann. Gesteuert wird der Roboter übers Internet (DynDNS + RasPi). Autonome Funktionen werde ich später hinzufügen. Was noch kommt: IR oder besser Ultraschall Sensor für collision detection; Quad Relais mit Monoflop Schaltung, um den Roboter stoppen zu können wen WLAN mal unterbrochen wird usw.... Zur Leistungsfähigkeit vom 6W Model: Anbei mal 2 Bilder vom aktuellen Stand.

Zu 1. Ich schieb die orangenen Nasen immer mit einem kleinen Schlitz Schraubendreher nach hinten. Dabei wünsch ich mir allerdings auch manchmal 3 Hände Zu 2. Ich hab auch den Stack und einen ESC mit dem selben Akku versorgt. Vom Servo Brick hab ich dann nur noch ein Kabel zum ESC. Ist auch in der Doku zum Servo Brick so beschrieben.

Auch wenn ich sowas nicht gerade benötige find ich's immer gut, wenn jemand sowas postet und damit die Machbarkeit demonstriert. Thx

@Dinonator Ja genau, beim Threadthema bleiben. Daher hab ich mich auch gefragt was Sicherheitslöcher von Java in der Presse mit der On-Device Thematik zu tun haben.

Das Argument mit den vielen Sicherheitslücken von Java ist hier fehl am Platz. Der große Teil der Lücken bezieht sich doch auf die Browser Plug-Ins (Applet/ActiveX) und hat mit der Sprache an sich nichts zu tun. Es ist ein Problem einer Technologie nicht einer Programmiersprache. Vor ca. 1-2 Jahren war es der Flash Player der für Schlagzeilen gesorgt hat. Da hat auch keiner gesagt dass C oder C++ oder ActionScript Scheisse ist.

Wenn 2020 über 30% der Menschen in Deutschland über 60 Jahre sind wäre es für TF sicherlich interessant biometrische Sensoren anzubieten. Ich glaube sowas in der Art hat Zukunft http://www.cooking-hacks.com/index.php/documentation/tutorials/ehealth-biometric-sensor-platform-arduino-raspberry-pi-medical

@FabianB: Warum braucht man den mehr als 1000 Nachrichten/s für eine CNC Fräse? Das Argument "je mehr desto besser" zieht ja immer. Ich hätte gerne mal ein wirklich stichhaltiges Argument für mehr als 1000 Nachrichten/s. Hab mich mit dem Thema CNC noch nicht befaßt, aber ich denke dass hier eher mechanische Faktoren (das Spiel der Spindel?) eine Rolle für die Genauigkeit spielen. Und für einen Raumthermometer mit LCD Anzeige und Relais + WLAN oder Ethernet braucht man sicherlich nicht mehr als 1000 Messungen/s. Sicherlich gibt es Projekte wo man mehr als 1000 Nachtichten brauchen könnte, aber ich denke das sind deutlich weniger als 5% der Leute hier. @TF: Ihr solltet euch genau überlegen ob der ROI (return on invest) bei so einer Aktion mit komplett neuer Firmware hoch genug ist. Wieviel neue Kunden bekommt ihr, wenn mit hohem Aufwand eine komplett neue Firmware entwickelt wird um dann für 10 Leute mehr als 1000 Nachrichten/s zu ermöglichen ? Wäre die Zeit (Manpower) nicht sinnvoller in andere Bereiche investiert die mehr zur Verbreitung und den Umsatz von TF sorgen ? Edit: Und wenn man das noch in Betracht zieht, dann relativiert sich die Forderung nach mehr als 1000 Nachrichten/s noch mehr. Ich denke dass relativ viele Projekte Wifi/Ethernet verwenden werden.

Für mich ist on-device nicht gleichzusetzen mit "auf die Hardware Ebene gehen". Genau das will ich nicht haben. Was ich jedoch will ist ein Programm ohne PC auf den Bricks direkt laufen zu lassen.

Wer ist denn schon an die Grenze von über 1000 Nachrichten pro Sekunde gestoßen? Gibt's den Usecase überhaupt oder will man da was bauen das für 99% der Fälle eh nicht relevant ist?

Hi Soweit ich weiss gab's es letztes Jahr Osterrabatt. Ist da dieses Jahr was in Aussicht ?

Achja, noch eine Bemerkung zu Schleifringen. Die Dinger sind in DE nicht unter 150€ zu bekommen ! Muss daher aus USA importieren. Der http://www.ltn.de/produkte/schleifringe/schleifringe-detail/?tx_news_pi1%5Bcontroller%5D=News&tx_news_pi1%5Baction%5D=detail&tx_news_pi1%5Bnews%5D=9&cHash=52512bc4197644ab09f75a2e4464faf0 kostet über 164€ für so ein elektromechanisches Teil

Hi Ich plane den IR Sensor für meinen Roboter als rundum Entfernungsmesser zu verwenden. Dazu soll der Sensor sich kontinuierlich um seine eigene Achse drehen. Damit die Sensor Kabel sich dabei nicht verdrehen, will ich einen Schleifring verwenden. Dieser hier, https://www.adafruit.com/products/1196 hat 12 Kontakte. Da die TF Sensor Kabel 10 Adern haben haben sollte das doch gehen. Hat das schonmal jemand gemacht? Könnte es Probleme geben, wenn das Sensor Signal über so einen Schleifring geleitet wird?

Definitiv +1 für Python. Habe extra TF gewählt da hier mehr von der Hardware abstrahiert wird und mehrere Bindings angeboten werden. Da ich von Java komme müsste ich zwar auch umlernen, aber wegen des Zeitaufwands würde ich eher Python als C lernen. Sonst kann ich auch gleich Arduino nehmen. Aber die Idee mit dem Speicherchip gefällt mir am Besten!

I think I found something if you plan to use digital IO pins for measuring analog values (e.g. comming from an LDR). Some cheap AD converter. http://letsmakerobots.com/node/13843

@CD108: I'm not very into electronics. So my questions: When using the analogue in bricklet you should add a resistor in serial to the LDR as voltage divider? Is this correct or would it be enough to just use the LDR without any resistor? Could you also elaborate what should be done when you want to use digital IO for such kind of sensors? Thanks

Vielleicht ist das kommenden Sonic Range Bricklet dafür besser geeignet. http://www.tinkerforge.com/doc/Timeline.html Ultraschall ist zur Kollisionserkennung vermutlich besser geeignet, da weniger Störeinflüsse auftreten können.

Hi JavaLaurence I would only buy one if it really dives into details about on device programming. The higher level API is already very well documented by TF and I wouldn't buy a book for that.

IR Sensoren reagieren empfindlich auf Lichtquellen mit hohem IR Anteil. Könnte das bei dir der Fall sein ?

Hab jetzt nochmals alles neu aufgesetzt. Ich hatte ja einen neuen Master bekommen. Hab alles neu geflasht und alle Versionen nochmals überprüft sowie alle Wifi Parameter neu eingegeben. Jetzt funktioniert es

jaja das stimmt schon. masterBrick ist die Instanzvariable und BrickMaster ist die Klasse mit der Konstanten WIFI_POWER_MODE_LOW_POWER

@AuronX: Trotzdem Danke für den Tipp mit getWifiPowerMode(); Habs gerade mal mit masterBrick.setWifiPowerMode(BrickMaster.WIFI_POWER_MODE_LOW_POWER); System.out.println(masterBrick.getWifiPowerMode()); probiert und bekomme folgende Exception: com.tinkerforge.TimeoutException: Did not receive response in time for function ID 36 Da schein noch irgendwas nicht ganz so otimal zu laufen Java Binding ist übrigens 2.0.5

getWifiPowerMode() hab ich noch nicht probiert. Werd das mal machen. Ich weiß nur dass es mit Master Version 2.0.4 funktioniert hat! Dort wurde korrekt Low Power Mode angezeigt. Und mit 2.0.5 kam ja auch ein Fix zum Low Power Mode. Glaube eher dass dabei was schiefgegangen ist.

Hi Meinen Stack initialisiere ich per Java so masterBrick.setWifiPowerMode(BrickMaster.WIFI_POWER_MODE_LOW_POWER); Wenn ich dann mit brickv auf den Master schaue, dann steht dort immer noch Full Speed. Entweder die Anzeige im brickv ist nicht korrekt oder der Wifi Mode wird gar nicht richtig gesetzt. Haben das andere auch schon beobachtet? Master Version 2.0.5 Brickv Version 2.0.3 Grüße

Hi Why don't you just use the hostname. In case of a WIFI module ist will be something like Gainspan...