remotecontrol

Die API sagt aber: int accelerometer_get_acceleration(Accelerometer *accelerometer, int16_t *ret_x, int16_t *ret_y, int16_t *ret_z) Also alles int. D.h. hier müsstest bzw. solltest Du einen int16 (short) verwenden. Vielleicht ist der Typ im Beispiel falsch. Welche Stelle meinst Du genau?

Can you post the configuration you use (how is it called on the RED)? Are you able to start the program from the command line on the PC where you have your Eclipse?

I understand that you want to use Tinkerforge RED Brick API to connect to the RED Brick, or do you want to upload the Eclipse project and then start the Java program on RED? In both cases: if you start the Java program via command line, the "target" or "bin" folder must be part of the classpath (depends how your Eclipse project is set up), otherwise the classes are not found. If the Tinkerforge API is packed into a JAR, this must be in the classpath too. If you start the main class out of Eclipse: does this work?

Mit "250" meinst Du den absoluten Wert, der bei "setPosition()" übergeben wird, also 2.5°? Das ist ein recht kleiner Schritt... Oder meinst Du 250 weiter in eine Richtung und dann zurück? Hast Du zuerst mit "setDegree()" den min/max Wert für den Winkel eingestellt? Die meisten Servos können nur +-/45°.

Den Effekt habe ich auch. Ich vermute, dass es an der Art der Ansteuerung der LED-Strip allgemein liegt: die sind nicht dauerhaft an, das sieht nur so aus, sondern werden mit einer hohen Frequenz geschaltet (das lässt sich ja auch über die API einstellen - Takt&Frame) und dadurch sinkt der Stromverbrauch.

Meines Wissens nach nicht, in der Masterbrick-Doku steht auch: ...

Ist es dabei egal, wie weit weg die Steckdosen sind? Wie viele LEDs hast Du am LED-Strip? Da gibt es ja eine Begrenzung (50 LEDs pro Port), die sich auf andere Bricklets auswirken. Die StepDown braucht im Master sicher noch ein paar Byte RAM für das Auslesen Spannung/Strom und evtl. macht genau das Probleme. Kannst Du die Bricklets mal einzeln abstecken und prüfen ob es mit den verbleibenden 3 funktioniert?

1a habe ich noch nicht probiert, ich würde aber vermuten, dass Du den Stapel dann nicht mehr über WIFI ansprechen kannst, da ein Master die WIFI Extension steuert, aber der RED ja der Hauptmaster im Stack ist und gerade der kann die WIFI Extension nicht. Ein Bricklet von 2 Quellen steuern geht. Mit WLAN Stick verhält sich der RED wie ein Stack mit WIFI-Extension. Ich kann problemlos den RED (mit WIFI-Stick) mit dem brickv per Netzwerk ansprechen. Dann sehe ich alle am RED angeschlossenen bricks + bricklets und kann die ganz normal steuern. Daher wurde bisher auch kein WIFI-Extension-Support bereit gestellt: weil die WIFI-Sticks analog funktionieren.

Ja, wenn Du Dich per USB mit dem brickv gegen den RED verbindest, dann kannst Du darüber eine Shell öffnen und Dateien kopieren.

Häng doch bitte die Java-Source mit an den Post. Das kann auch ein Softwarefehler sein.

Bzgl. Gehäuse habe ich selber mal den Tipp mit "Forex" Platten bekommen: die verwende ich inzwischen in Kombination mit Makerbeams als "Tragegestell". Die Platten kann man gut passend zurecht schneiden und dann auf Makerbeams schrauben oder (bei 3mm) in die Schlitze der Makerbeams stecken (geht aber auch ohne Makerbeams). Vorteil ist, dass man kein teures Gehäuse wegwerfen muss, wenn es zu klein wird. Eine Platte 25x50cm kostet unter 4€. Solche Platten gibt es u.a. bei modulor.de. Nachteil: wenn es durchsichtig sein soll oder gar wetterfest, dann wird es schwieriger.

Hallo André, prinzipiell sollte es keinen Unterschied machen welchen RasPi Modell Du wählst. Die sollten sich alle mit der TF-Hardware vertragen, solange mindestens ein USB-Port vorhanden ist. Die älteren RasPi-Modellen verbrauchen noch vergleichsweise viel Strom. Da werden die Neueren und auch der RED-Brick deutlich besser sein. Eine StepDown ist nicht zwingend notwendig. In Summe must Du aber alles irgendwie mit 5V versorgen. Wenn Du keine StepDown verwendest, dann wird der Stack über den USB-Port mit Strom versorgt, um die 5V für den Raspi musst Du Dich dann selber kümmern. Einen kleinen Unterschied macht es evtl., wenn Du den RasPi mit am USB angeschlossenen Bricks bootest: hier muss der brickd dann beim Hochfahren gleich die Bricks erkennen und hier kann sich die USB-Hardware ggf. unterschiedlich verhalten. Bisher hatte ich damit aber nie Probleme (älterer RasPi B und anderer Mini-Rechner). Beim RED ist es "garantiert", dass das alles sauber initialisiert. Der RED ist sehr kompakt und einfach (von der Seite fast unschlagbar), den Stromverbrauch finde ich auch recht gering und man hat ein (USB) Kabel weniger. Manche wollen aber gerade den Rechner + Bricks trennen, wegen der Bauhöhe, wenn es er flach sein muss. Du brauchst ja immer einen RED plus einen Brick und wenn dann noch eine StepDown drunter ist, hast Du schon ein gewisse Mindesthöhe. Viele Grüße

Sieht zumindest nicht so aus, als würde das Programm sofort enden. Allerdings macht die while Schleife keine Pausen, d.h. zieht 100% CPU auf einem Core. Bau mal einen Sleep von 1ms ein oder Bau es auf Semaphores um.

Vermutlich endet Dein Programm im "Normalbetrieb" direkt wieder. Du solltest die Sourcen mal mit posten.

Je nach Anzahl LEDs im Strip kannst Du auch den 5V Ausgang der Step-Down verwenden, dann reicht ein Netzteil. Ich habe einen Strip mit 50 LEDs, und brauche max. 400mA bei ca. 11V am Eingang, also ca. 800-900 mA bei 5V, je nach Muster und aktueller Helligkeit. Hast Du mal nachgemessen, was der Strip tatsächlich an Strom benötigt?

Das mit dem Programmstart bei Systemstart kriegst Du hin?

Vielleicht hilft diese Aufstellung dabei: http://blog.philippklaus.de/2011/08/make-rs232-serial-devices-accessible-via-ethernet/

Hmm, ich habe noch nie einen Joystick unter Linux angeschlossen. Aber die Input-Devices (wie auch die Maus) sind mit Devices unter "/dev/input" verknüpft und hier sind in der Regel nur Rechte für root. Da der X-Server unter root läuft kann der drauf zugreifen ... Das Problem scheinen schon mehrere gehabt zu haben, z. B.: http://developer.x-plane.com/2012/09/linux-joystick-permissions/

Hier im Forum hat mal jemand auf 5m verlängert. Damit hatte er aber Probleme, weil I2C ja ein Bussystem ist und die Gesamtbuslänge (Kabellänge) eine Rolle spielt. TF bietet wohl bewusst nur 2m an.

Nachtrag: hier ist das Beispiel mit dem Enumerate: http://www.tinkerforge.com/de/doc/Software/IPConnection_Java.html#enumerate

Direkt gibt es das nicht, aber über die Enumeration bekommst Du indirekt eine Liste aller Bricks und Bricklets im Stack. Und wenn Du Dir diese Werte merkst kannst Du UIDs und Sensor-Typen später abfragen.

Welche Art Servo hast Du? Ist das wirklich ein Servo, welches 180° abdeckt? Die meisten können nur -+ 45°, dann solltest Du auch nur solche Impulse senden (also den Wertebereich und die Grundeinstellung anpassen). Wie oft sendest Du Befehle zum Stack und über welche Verbindung? Ich hatte vor längerer Zeit ziemliche Probleme mit Servo in Kombination mit der WLAN Extension. Das ging bis zum Aufhängen des Stacks, wenn ich sehr viele Daten über die WLAN Extension sende/empfange. Das sollte aber behoben sein ...

Das passt zu dem Thema, wo mir was Ähnliches in C++ aufgefallen ist: http://www.tinkerunity.org/forum/index.php/topic,3254.msg20051.html#msg20051 Laut TCP/IP-API http://www.tinkerforge.com/de/doc/Software/Bricklets/Humidity_Bricklet_TCPIP.html#BrickletHumidity.set_humidity_callback_threshold sind min/max jeweils "unsigned int", den gibt es in Java aber nicht, sondern nur int und short. Das ist hier nicht ganz einheitlich mit den Typen (müsste eher überall "int" sein, um den positiven Wertebereich bis 2^16 abzudecken). Den Timeout erklärt das nicht.

Wenn der RED eine Netzwerkverbindung (WLAN / Ethernet) hat, dann kann man auch mit "scp" Dateien kopieren, sofern der SSH Server läuft. Das geht dann wie ein copy auf der Console. Für Windows gibt es den "putty" bzw. "pscp".

Das Start-Skript habe ich eben auch noch angepasst, dann ist das hier auch weg: ./stub: Zeile 34: cd: src/stubserver: Datei oder Verzeichnis nicht gefunden