Nic

@haentschman Thema. Delphi-Bindings: Hättest Du ev. Lust zusammen die Delphi-Portierung voran zu bringen ? Den Framework, den ich bisher erreicht habe, unterstützt prima, die TCPIP Connection, Anmelden eines Devices, und das Callen der Funktionen. Jedenfalls was das Steuern des Stepper-Bricks und IO-Bricklet angeht. Offen sind eig. nur noch das threadsichere Queueing und Callbacks. Die Portierung ist in D7. Allerdings wäre das alles obsolet, falls von TF diesbezgl in kürze was fertig gestellt wird. Ich habe zwar nach einem Veröffentlichungstermin nachgefragt, aber keine Antwort erhalten.

Wie ist dann das Verhältnis von Winkel zu Geschwindigkeit ? Verstehe ich das richtig hier geht es NICHT um Servos oder Schrittmotoren !?

Verstehe noch nicht ganz, wie die Winkeländerungen ü.NN, die vom IMU ermittelt werden auf den DC-Motor umgesetzt werden, beim Servo ist das klar aber beim einfachen Motor ?

@haentschman Ahh, endlich jemand der sich für Delphi interessiert, dachte schon ich bin hier alleine Bist Du in Delphi fit ?

Nein, ich meinte das nicht speziell auf Delphi bezogen, sondern prinzipiell wie das exemplarisch in C# zw. blocking und non-blocking unterschieden wird. C# kann ich eher lesen als Java oder Phyton, darum habe ich das C# Binding analysiert, allerdings waren die Socket-Sachen noch Neuland. Jetzt ist das klarer für die Lsg. in Delphi.

Ist das Gyroskop nicht eine kardanische Aufhängung wie in einer Steadycam ? Verstehe ich das richtig, dass IMU soll quasi als 3D Wasserwaage arbeiten, die Winkeländ. an die Motoren senden und ausgleichen ? Sind einfache Motoren bzw. Servos genau genug anzusteuern um die Kamera immer exakt auszurichten ?

Also ich bin in Hobby-Sachen immer locker Skype ist nicht vorhanden, also alles andere ist obsolet... Wenn ich mich richtig erinnere gibt es non-blocking mode von Sockets, in diesem Fall würde der Thread am Read nicht warten sondern weiterlaufen ?

Genau der Block hätte gereicht. Den Rest und der zynische Unterton gehören hier nicht ins Forum. Es ist durchaus möglich, das man als Anwend.entw. unterscheidet zw. eigener Implm. und der eingeb. Framework-API in der ich i.d.R. nix zu suchen habe. Insofern kann "sobald du Stream.Read aufrufst" ev. zu Irritationen führen.

Tage mit einem Akku ist sicher zu hoch gegriffen, dies müsste unterstützt werden durch ein Solarpanel, dass nachlädt. So wie die Nachtlichter für den Garten aus dem Baumarkt. Hier gibt es z.B. einen 380mAh in 35 x 20 x 7,0 mm http://shop.lipopower.de/Einzelzellen-37V Bei Segor habe ich einen 200mAh gesehen, 30x20x5,5mm 3g: http://www.segor.de/#Q%3DLiPo%203V7-%20200mAh Es war nicht die Rede davon Lipos on Block mit 2000mAh reinzuquetschen. Idee war diese Kapazität ev. über mehere Akku-Brick gestackt zu erhöhen. Andererseits kann dieser Akku-Brick auch als Art End-Bodenplatte sein, wie das Step-Down-Supply, darunter passt ja auch nix mehr. Im Thread http://www.tinkerunity.org/forum/index.php/topic,280.0.html habe ich einen externen Akku-Pack von YAYAGO zweckentfremdet. Dieser liefert 1400mAh und die Abmasse sind nur unwesentlich grösser als die 40x40. Und eine Bodenplatine muss ja nicht genauso gross sein, wie die Bricks. Alle TF-Stecker hängen bis zu 2-3cm über Platinenkante raus, und bisher scheine ich der einzige zu sein der sich darüber stört. Und warum muss eigentlich am Brick-Format von 40x40 so päpstlich festgehalten werden ? Verstehe ich nicht, vielleicht geht auch mal 2 oder 4 Platinen als Matrix nebeneinander zu verbinden...

Ev. kann man mit Gewichten nachhelfen. Wichtig auch ist die reibungsarme Lagerung, Rillenkugellager etc. Schwierig wird es wenn das direkt dem Wetter ausgesetzt ist (Salzwasser).

Sorry, verstehe nur Bahnhof Ich rufe explizit nicht stream.read auf sondern dies passiert im Thread RecvLoop, innerhalb der while-Schliefe. Der Thread wird instanziert und sofort gestartet, sobald IPConnection erzeugt wurde. Irgendwann rufe ich in der Anwendung AddDevice auf, damit schreibe ich in den SocketStream. Was und wann triggert dann in RecvLoop das im SocketStream gelesen wird ? Solange dieser Thread nicht terminiert oder destroyed wird, bleibt der Thread aktiv und pollt im Stream ob er lesen kann ?

Verstehe ich das richtig, es gibt für das Socket kein OnReceive Event, das ihm sagt, jetzt lese aus ? Der Thread bleibt beim Lesen solange stehen (Endlosschleife), bis das Stream.Read Daten lesen kann und evaluiert ? Ist das also eine asynchrone Kommunikation ?

Nicht unbedingt. Die Kardanaufhängung der "Steadycam" könnte genausogut über der Kamera und deren Schwerpunkt liegen, d.h. die Kamera macht die Masse aus und braucht kein Gegengewicht. Gab es früher auf den Fischerbooten nicht die karadanisch aufgehängten Lampen, die jeden Sturm getrotzt haben ?

Das ist m.E. auch abhängig von der Kabellänge: http://www.yachtbatterie.de/de/Installationsmaterial/Kabel.htmlindex.shtml Dort gibt es einen Calculator.

Zusammengefasst Thread RecvLoop agiert wie ein Listener bei Änderung des Device-Stacks und der Thread CallbackLoop wie ein Event-Handler bei Device-Rückantworten wie z.b. nach getter-Anfragen (GetCurrentPosition beim Stepper) ?

1) Für den autonomen Satellitenbetrieb z.b. bei Chibi oder WLAN plus IMU, Bricklets wie Temp./Feuchtemessung etc. Für Stepper oder Servo nicht. 2) Abhängig vom Verbrauch, für die Bricklets einige Tage ? Std. für Bricks etwa 2000mAh, Größe ev. bis die max. Abmaße der 40x40 erreicht sind Ich würde das so auslegen, dass mehere Akku_brick gestappelt werden können um die Akku-Kapazität zu erhöhen und somit die Laufzeit, wer also länger arbeiten möchte braucht x-Akku-Bricks 3) Aufladen per Mini-USB, entweder vom PC also 5V input, oder parktischer über Solarpanel Falls Platz auf der Platine ist, herkömmliche Steckerbuchse 4) bis 30 Euro

Der Thread des RecvLoop läuft dauerhaft ? Wenn ja was triggert den Einsprung ? Oder bewirkt das die interne Endlos-Schleife while(RecvLoopFlag) solange das Flag true bleibt ? Wenn ich einen Breakpoint innerhalb der while Schleife setze, bleibt der Debugger nur dann stehen, wenn ich Devices hinzugefüge.

Die beiden Threads RecvLoop und CallbackLoop in der IPConnection-Klasse sind für das Auswerten der Rückantworten der Devices zuständig ? Arbeiten diese parallel zum Hauptthread nur solange, bis die Devices hinzugefügt wurden und werden abschließend beendet ? Oder bleiben beide suspended ? Ich würde das Prinzip gerne verstehen, um es passend in Delphi zu portieren.

Was ist mit einer Steadycam-Lsg. ? Wenn es das Zittern und schaukeln von Kameraffahrten ausgleichen kann, sollte es ev. bei nicht zu starkem Seegang zumindest die Ausschläge dämpfen, die Feinheiten ev. im kameraeigenen Stabi.

Ich vermisse hier in der Auflistung ein Akku-Brick (mit LiPo) als Stack-Stromversorgung ? Oder ist damit der 5V Step-up gemeint ?

Mich interessiert aus welchem Material der Pullover ist ? Polyester, Nylon, Gore-Tex etc. Ev. steht da was auf dem Label mit den Waschinfos.

Das war ironisch gemeint. Niemand muss sich hier rechtfertigen. Aber dennoch, hoffe der Nachwuchs ist wohlauf.

Komisch, aber zur Cebit oder Ifa immer hinfahren und die Besucher dort sind das alles Nicht-Hobbiesten aus der Region nen Haufen Südländer hier, müsste man mal sozio-ökonomisch untersuchen lassen... Gruß aus Berlin.

Andere Idee: so eine Art Anwendertreffen bei TF. Oder eine Hausmesse um ein paar Inspirationen zu bekommen und Erfahrungen mit den Brick-Meistern und Anwendern auszutauschen.

@AuronX Also haben wir damit die gleiche Situation wie mit USB, Daten wie auch Stromversorgungsleitung. http://de.wikipedia.org/wiki/Power_over_Ethernet Ich meinte, falls man vom PC entkoppelt ist, aber dennoch den Brick mit Strom zu versorgen hat, reicht es eine 5V Stromquelle über USB anzuschliessen.