photron

Die OpenGL Header kommen also vom RED Brick aus /usr/include? Selbst wenn dem so ist, lösch die mal aus deinem Verzeichnis. Es muss dennoch gehen.

Schau an, lauter Compile Fehler im Zusammenhang mit OpenGL. Such mal in der Ausgabe nach "error:". Wenn ich das richtig sehe ist an allen Fehlern "../bin/glu.h" beteiligt. Hast du einen besonderen Grund warum du deinen eigenen glu.h (und wahrscheinlich auch gl.h) mitbringst? Entferne mal alle OpenGL Header die du selbst mitbringst, damit nur die aus /usr/include verwendet werden. Ich vermute, dass das Gemisch aus deinen und den System OpenGL Headern das Problem ist.

Tja, sieht an sich gut aus. So wie das Makefile gebaut ist müsste es alle Befehle ausgeben bevor es sie ausführt. Zeig mal die komplette Ausgabe von make. Falls es nicht den g++ Befehl anzeigt bevor es in ausführt, dann kannst du das Makefile editierten, um an diese Information zu kommen. In Zeile 428 echo ">>> $(CXX) -c $(CXXFLAGS) $(INCPATH) -o main.o ../bin/main.cpp <<<" zwischen diesen beiden Zeilen einfügen: ../bin/bricklet_io4.h $(CXX) -c $(CXXFLAGS) $(INCPATH) -o main.o ../bin/main.cpp Achte, darauf, dass die echo Zeile auch mit einem Tab eingerückt ist wie die $(CXX) Zeile. Worauf ich hinaus will. Normalerweise solltest du von g++ selbst eine Fehlermeldung bekommen. Das scheint aber hier nicht der Fall zu sein, sondern make gibt selbst diesen komischen Fehler aus. Daher meine Vermutung, dass der g++ Befehl an sich kaputt ist. Du kannst auch mal "make -d" ausführen, damit make dir mehr Debug Informationen ausgibt.

Das ist nicht der eigentliche Fehler, denke ich. Das muss vorher in der Ausgabe noch der richtige Fehler stehen. Bzw. zeig mal was in Makefile an Zeile 428 (plus 10 Zeilen davor und danach) steht, oder häng das ganze Makefile mal an.

Naja, der gleiche Fehler kann es ja nicht sein. Denn wenn du den windows.h Include entfernst hast, dann kann dieser ja nicht mehr an der Abwesenheit von windows.h scheitern. Tritt der Fehler jetzt an einer anderen Stelle auf, oder hast du nicht die richtige gl.h Datei editiert?

This should just work. WIFI and USB should not make a difference like this, Which callback is this? How do you power the stack when you use the WIFI Extension?

Ist es. gl.h versucht hier auf komische Art und Weise Windows zu detektieren. Wenn WINGDIAPI nicht definiert aber APIENTRY definiert ist dann will es windows.h includen. Dein Problem hier wird sein, dass irgendwer anders APIENTRY definiert. Das gl.h an diesem doch eher generischen Namen versucht Windows zu erkennen ist problematisch. Paste mal den Anfang der gl.h Datei bis zu der Stelle wo der Fehler auftritt, oder häng die ganze gl.h Datei an einen Post an. Entweder wird vor dieser Stelle ein anderer Header included, der APIENTRY definiert, oder APIENTRY wird im Compiler-Befehl per -D Option definiert. Dass gilt es zu finden und zu beheben. Oder du kannst gl.h hacken und #if !(defined(WINGDIAPI) && defined(APIENTRY)) durch #if 0 ersetzen und sehen wie weit du dann kommst.

Das sollte kein Problem sein. Ich wüsste gerade auf Anhieb nichts was dagegen spricht.

Link ist korrigiert. Der L/R Aufdruck auf dem Bricklet ist korrekt. Es war im Plugin vertauscht. Das ist aber schon vor 1,5 Jahren mit Version 2.0.2 behoben worden. Wahrscheinlich hast du Bricklets bekommen, die nicht auf dem letzten Softwarestand sind. Du kannst das also durch ein Update des Bricklet Plugins beheben.

Du musst beim Servo Brick zwischen der Ausgangsspannung und der Spannung des PWM-Steuersignals unterscheiden. Die Ausgangsspannung ist zwischen 2V und 9V einstellbar, aber sie ist für alle 7 Servos gleich. Die Spannung des PWM-Steuersignal-High-Pegels ist fix bei 5V. Der DC Brick gibt ein PWM Signal mit der Eingangsspannung als fixen High-Pegel aus. Über die Velocity kannst du den Dutycycle des PWM Signals einstellen und damit die durchschnittliche Ausgangsspannung zwischen 0V und der Eingangsspannung einstellen.

Das kann eigentlich nur am Magnetometer liegen. Versuch es noch mal zu kalibrieren. Was du tun musst, ist die maximale und minimale Magnetfeldstärke für alle 3 Achsen zu finden. Dazu jeweils jede Achse in positive und negative Richtung nach Norden richten und mit der IMU etwas kreisen, bis die Werte im Kalibrierungsfenster sich nicht mehr ändern. Falls das nicht hilft, versuch mal die IMU an einem anderen Ort zu benutzen. Möglicherweise hast du ungewöhnliche Magnetfeldstörungen an deinem Tisch.

Hast du den schon mal das PHP Beispiel angesehen, dass 4223 auf das Display schreibt? http://www.tinkerforge.com/de/doc/Software/Bricklets/SegmentDisplay4x7_Bricklet_PHP.html#simple Um die Uhrzeit anzuzeigen muss du dann in Zeile 24 die feste Auswahl der Ziffern 4 2 2 3 durch die Ziffern der aktuellen Uhrzeit ersetzen.

Loetkolben, ich denke nicht, dass du zwingend ein Programm schreiben muss. Unter Linux kannst du über das Dateisystem mit USB Devices arbeiten, Stichwort usbfs. Siehe /dev/bus/usb und /sys/bus/usb.

Was für Probleme hast du denn genau?

Ah, ich hatte es so verstanden, dass der Brick an sich noch funktioniert und die LEDs leuchten, er aber das System stört. Versuch den problematischen Master Brick noch mal in den Bootloader Modus zu versetzen. Dazu am besten den Master Brick von allem abstecken, den Erase Knopf drücken, mit gedrücktem Erase Knopf an USB anstecken und erst jetzt wieder den Erase Knopf loslassen. Wenn sich der Master Brick dann nicht flashen lässt dann - teste mal ein andere USB Kabel - einen anderen USB Anschluss am PC - schau dir alle 4 Bricklet Anschlüsse genau an, ob da nicht vielleicht Pins verbogen sind und Kurzschlüsse machen Eigentlich kann es aber ja nicht am PC oder am USB Kabel liegen, denn du konntest ja den Master Brick vorher updaten. Es liegt wahrscheinlich am Master Brick selbst.

Loetkolben, wie borg schon sagt kannst du dir das alles im brickd anschauen. Was du grob gesagt tun musst ist: - den Brick in der Liste der USB Devices finden - einen USB Handle für den Brick öffnen - Interface 0 claimen Dann kannst du Requests als Bulk Transfer an den Interface 0 OUT Endpoint senden und Responses als Bulk Transfer vom Interface 0 IN Endpoint empfangen. Die Pakete sind die gleichen die auch über TCP/IP versendet werden. Um mit USB zu interagieren kannst du z.B. libusb verwenden.

Okay, hier das Start-Program Beispiel in Java: http://www.tinkerforge.com/de/doc/Software/Bricks/RED_Brick_Java.html#start-program

Dass heißt, auf dem "kaputten" Master Brick ist Firmware 2.3.3 drauf? Was passiert wenn du die gleiche Firmware wie auf dem heilen Master Brick auf den "kaputten" flasht? Ältere Firmware Versionen kannst hier finden: http://download.tinkerforge.com/firmwares/bricks/master/ Im Brick Viewer dann "Custom" statt "Master" auswählen und die Firmware Datei angeben.

Hier ein Beispiel wie man ein Program auf dem RED Brick über die Python API startet: http://www.tinkerforge.com/en/doc/Software/Bricks/RED_Brick_Python.html#start-program Leider ist die Dokumentation der RED Brick API noch unvollständig und es gibt bisher nur dieses eine Python Beispiel.

Für eine neue Power Supply müssen wir erst noch mehr Forschung betreiben. Im Sinne von, welche Features soll sie wirklich haben und wie diese sinnvoll umgesetzt werden können. Wir haben schon einen ersten Prototypen entwickelt. Da das Thema aber komplex ist erfordert der Prototyp aufwändigere Langzeittests. Dazu sind wir aus Zeitgründen bisher noch nicht gekommen und die weitere Entwicklung liegt da gerade auch auf Eis. Einem OLED Display sind wir noch nicht weiter nachgegangen.

Der Brick Daemon leitet die Pakete unseres TCP/IP Protokolls unverändert durch und kümmert sich dabei um das Routing zwischen mehreren Bricks und mehreren TCP/IP Verbindungen. Du kannst also mit einem Brick auch direkt per USB sprechen und ihm die gleichen Pakete schicken, wie sie für unser TCP/IP Protokoll definiert sind: http://www.tinkerforge.com/de/doc/Low_Level_Protocols/TCPIP.html Deutlich einfach ist es aber eine WIFI Extension zu verwenden. Dafür steckst du einen Master Brick unter den Servo Brick und eine WIFI Extension oben auf den Servo Brick. Dann kannst du die WIFI Extension als Access Point konfigurieren, dich vom Smartphone aus damit verbinden und dein bisheriges Steuerprogramm für die Schlange weiterverwenden.

Das ist eine Variante dieses Problems: http://www.tinkerunity.org/forum/index.php/topic,3132.0.html Es liegt an der Master Brick Firmware 2.3.2. Wir arbeit gerade an einer Lösung. Bis dahin kannst du das Problem umgehen indem du Master Brick Firmware 2.3.1 verwendest.

See brickd.log on the RED Brick: http://www.tinkerforge.com/en/doc/Hardware/Bricks/RED_Brick.html#system-logs

As also stated in the documentation that borg mentioned, you need to add ws2_32.lib and advapi32.lib as additional dependencies to the Visual Studio project.

Welche Baudrate hast du bei den RS485 Extensions eingestellt? Der RED Brick unterstütz die hohen Baudrate über 500 kBaud nicht: http://www.tinkerforge.com/de/doc/Hardware/Bricks/RED_Brick.html#rs485-extension