ThomasKl

Bin auch Chemiker (Richtung instrumentelle Analytik) und kurz vor dem Abschluss meiner Diss. Programmiere gerne auch in verschiedenen Sprachen in letzter Zeit vorzugsweise in Javascript.

wie beschrieben muss man dass wohl im fertigen Aufbau ausprobieren, eventuell lässt sich das IMU auch etwas entfernt von den Motoren anbringen.

ich würde mal sagen dass ist ein must-have  für alle Nerd-Brillen Träger :-D

hehe sieht echt witzig aus, für den Sommer müsste man eigentlich sowas für Wasserbomben bauen. Wahl

Die verwendeten Räder sehen aus wie die von diesem Auto

http://www.conrad.de/ce/de/product/235244/Silverlit-Modellauto-mit-Fernsteuerung-82333/1202014&ref=list

Ich sehe den Aufwand auch eher auf der Konstruktionsseite, was wohl etwas tricky werden könnte ist die Ballzuführung die vermutlich aktiv mit einer Schnecke oder einem Förderband erfolgen muss.

Aber einen ersten Prototypen aus einem Stück Wasserrohr, einem DC Motor und einer einfachen Walze, und etwas Holz um alles zusammen zuhalten wäre bestimmt schnell zusammen gezimmert.

Soweit ich das verstanden habe kommt die absolute Referenz vom Magnetfeld der Erde, dessen Richtungsvektor wird beim Kalibrieren gespeichert.

Das Szenario lässt sich als Regelkreis beschreiben.

Wenn man oft genug die Geschwindigkeit ändern kann, wird vermutlich ein P (roportional) Regler, wie von Plenz beschrieben reichen. Also die neue Geschwindigkeit wird proportional zur Abweichung des tatsächlichen Wertes vom Sollwert berechnet. Das Problem hierbei ist, dass man immer dem Sollwert hinterherläuft und ihn "nie" erreicht, aber unendlich nahe kommt :-).

Ansonsten wird man die neu berechnete Geschwindigkeit zusätzlich zu

diesem Proprotionalteil nochmal abhängig von der D(ifferenz) eines tatsächlichen Wertes zu seinem vorhergehenden erhöhen. Die Erhöhung soll im Prinzip die erwartete Bewegung ausgleichen, sodass man direkt zum Sollwert kommt und ohne sich ihm ständig von einer Seite zu nähern.

Softwareseitig müsste man einen PID Regler basteln und auf der Hardwareseite muss man bestimmt etwas mit dem convergence speed spielen, um eine sinnvolle Einstellung zu finden. Aber ich denke wenn man es schafft die Position 10-20 mal pro Sekunde nach zuführen, sollten die Bewegungen recht flüssig wirken.

Mainz

wenn man sich per websocket am brickd anmelden kann umso besser, hatte dazu bisher noch nichts gesehen.

Ist denn das Ziel die Kamera immer waagerecht zu halten oder es immer auf einen Punkt z.b. den Horizont zu halten. Bei immer waagerecht würde, wenn das Boot über Wellen fährt, der Horizont hoch und runter schwanken.

ich hatte da jetzt eher an einen mehr oder weniger transparenten webserver gedacht, für den es dann javascript bindings gibt. Also dass man anstatt Phyton/Java/C... zu nutzen, einen Browser und Javascript nimmt.

Aber ich sehe ein, dass das wenig mit php zu tun hat :-)

ich denke für Webanwendungen wären Callbacks dann interessant, wenn sie über Websockets laufen würden.

Dann könnte man sich mit Client seitigem Javascript vollständige Anwendungen bauen.

Von den Spezifikationen sehe ich nichts was dagegen spricht. Man müsste vermutlich nur die PWM Frequenz anpassen.

Vielen Dank für den Link. Die Bricks funktionieren alle auch einzeln am PC, der Master ist nur nötig wenn sich mehrere Bricks eine USB Verbindung teilen sollen. Wenn du willst/kannst ist es auch möglich das Brick mit eigener Firmware auszustatten, dann brauchst du keinen PC, dieser low level Zugang ist im Moment aber noch nicht offiziell unterstützt.

Ich bin mir nicht sicher ob eine PWM Erzeugung für ein Bricklet nicht etwas zuviel verlangt ist. Zumal das Servobrick ja schon 7 separate PWM Signale erzeugt.

Man bräuchte nur eine kleine Erweiterung, die die Signale mit einer externen Spannung bzw der Leistungsleitung des Bricks verknüpft. Vielleicht gibt es so was ja schon.

Die Steuerung der Dioden geschieht ja dann per Software, da lässt sich bestimmt ein Satz Funktionen/Klassen schreiben, die einem alle Wünsche erfüllen.

Könnte man da einen Transistor zwischen setzen, also Signal und Leistungspin an den Transistor löten und an den Emitter dann die LED hängen?

Wie wäre es denn mit dem Servo Brick, da hat man 7 separate Ausgänge deren PWM man einzeln steuern kann. Zudem kann eine Spannung zwischen 2 und 9 Volt  gewählt werden.

LED Leisten und Kühlkörper gibt es z.B. hier

http://www.leds.de/LED-Leisten-Module/

Hi, da hab ihr euch aber ein ambitioniertes Projekt ausgesucht. Wie wäre es denn mit Qt als Framework, da könnte man den Brickviewer als Grundlage verwenden und den dann Schritt für Schritt aufbohren. Der Brickviewer kennt schon alle Bricks und Bricklets, da wäre der erste Schritt, einfache Verknüpfungen zu erstellen, recht einfach. Man könnte ein Tab hinzufügen auf dem man "einfach" Getter mit Setter verbinden könnte. Wie z.b. Joystick.getPosition ----> Motor.setposition.

Darauf aufbauend könnte man eine "einfache" Flusskontrolle (if then else) einbauen evt. zusammen mit Timern.

Richtig mächtig würde so ein Programm dann werden, wenn man sein Programm per LowLevelProgrammierung direkt auf die Bricks schreiben könnte. Im Beispiel also das Motor Brick dem Herren des Joystickbricklets einmal mitteilt, dass es doch die Position vom Joystick schicken soll und darauf hin die Position unmittelbar ohne Umweg über einen PC zum Motorbrick geschickt wird und sich dann der Motor entsprechend bewegt.

It would be possible to write a special RS485 mode that makes it possible to speak to other RS485 devices, but i have no idea if thats worth the effort.

Thats what i meant, i still think that having a serial port within the TF setup would be very handy.  There are lots of higher level instruments that can be controlled via RS232/RS485.

Hi,

will it be possible to use the rs485 extension to "speak" to regular RS485 or even RS232 connections.

I think this would be a very nice feature, since there a alot of devices that can be controlled via RS232/RS485.

would it be possible to stack the bricklet connectors? looking at the pictures it seems like there could be enough room above the upper connectors for an additional row of connectors. 

Elegant wäre es doch eigentlich wenn man per USB jederzeit eine Reinitialisierungs Kaskade lostreten könnte.

Dann wäre man immer in der Lage, einen definierten Zustand herzustellen.

Ungefähr so

1.) Power an -> alle Teile im Stack und der PC fahren hoch

-> da die Reihenfolge des Hochfahrens nicht geregelt ist, ist der Zustand des Systems relativ undefiniert

2.) PC sendet ein USB Signal an den Master zur Reinitialisierung

3.) Der Master resetted sich und gibt anschließend ein Signal zum Reset an alle angeschlossenen Bricks.

=> Resultat wäre ein definierter Zustand

In den Ablauf könnte man dann noch Logik zur Autokonfiguration der Bricks stecken, wie automatische Master/Slave Erkennung.

 

Man kann natürlich wenn das Linux Board hochgefahren ist beim Master einmal auf Reset drücken, dann läufts.

 

Könnte man dem Master im Nachhinein einen Resetbefehl schicken, der das gleiche macht? Oder "hört" der Master gar nicht auf USB, wenn es beim Starten nicht verfügbar war?

die neue die [...] hat neben dem 6-27V Eingang auch noch einen 5V Ausgang (exakt für Sachen wie das Beagle Board oder das Raspberry Pi).

Macht es dabei eigentlich Probleme, dass die Bricks und der PC gleichzeitig Strom bekommen. Ich nehme mal an, dass die Bricks deutlich schneller hochgefahren als der PC, und somit nicht wissen ob sie an einem PC hängen oder nicht?