Jump to content

Servo Brick als "Moderator" für Versuchsaufbau


Recommended Posts

Hallo Tinker,

 

Ich würde gern einen Servo Brick zur Ansteuerung eines Schnellschlussventils und einer Kamera in einem Versuchsaufbau benutzen. Bevor ich jedoch den Brick bestelle, würde ich gern wissen, ob die Art der Programmierung die mir vorschwebt realisierbar ist.

Sowohl das Ventil, als auch die Kamera benötigen einen bestimmten Spannungsimpuls um angesteuert zu werden. Der Servo Brick hat 7 Anschlüsse und die verfügbaren Impulslängen und –höhen aus dem Datenblatt passen schonmal sehr gut.

 

Über die folgenden Fragen bin ich mir jedoch im Unklaren:

 

1) Kann man den Abstand zwischen 2 Spannungsimpulsen z.B. durch eine Art Timer künstlich strecken? (bei der maximalen Periodendauer im Datenblatt landet man bei ca. 15Hz, könnte man diesen Wert irgendwie auf z.B. 3Hz oder sogar auf einen einzelnen Impuls herabsenken?)

 

2) Die Kamera soll um einige hundert Mikrosekunden versetzt zum Ventil angesteuert werden. Kann man in der Programmierung einen solchen Bezug zwischen den Ansteuerungszeiten von zwei Anschlüssen herstellen? (Periodenversatz durch einen Timer?)

 

3) Kann man die ganzen Parameter des Servo Bricks über den USB-Anschluss „online“ variieren? (der Abschnitt Test your Servo Brick im Datenblatt vermittelt den Eindruck, dass dies möglich ist)

 

Vielen Dank und beste Grüße,

 

Markus

Link to comment
Share on other sites

Interessant, geht es hier um Hochgeschwindigkeitsaufnahmen, z.B. von einem fallenden Wassertropfen ?

http://www.cognisys-inc.com/stopshot/stopshot.php

 

Ich bezweifel, dass die derzeitige Brick-Hardware und Design in der Lage ist µs genaue Steuerung zuzulassen. Wobei das Timing-Problem Echtzeitfähigkeit des Betriebssystems voraussetzt.

 

Ev. sieht das anders aus wenn die OnDevice-Programmierung möglich ist: http://www.tinkerforge.com/doc/Programming_Interfaces.html#pi-hlpi

Link to comment
Share on other sites

@ Nic

 

Hi,

 

Mit dem Ventil wird ein Druckstoß erzeugt und die Kamera nimmt dessen Auswirkungen auf.

 

Die Steuerung müsste eine Genauigkeit im Bereich von 0,1ms aufweisen - wenn Du sagst, dass eine µs-Genauigkeit nicht realisierbar ist, meinst Du die Skalen von 1µs bis 10µs?

Würdest Du denn sagen, dass die Programmierung von Zeitverzögerungen (auch mit Abhängigkeiten zwischen verschiedenen Steuerausgängen) möglich ist?

 

Grüße,

 

Markus

 

Link to comment
Share on other sites

also was ich bisher mitbekommen hab, sind mit Tinkerforge - dank USB Beschränkungen - nur knapp 1000 Nachrichten pro Sekunde möglich. d.h. 1ms-Takt is maximal möglich...

 

und das gilt für ALLES was an Master-Brick hängt. wenn also 2 Sachen per Callback abgefragt werden geht dies mit maximal 500 Nachrichten für jedes bricklet... USB kann einfach nicht mehr.

 

(hoffe dass ichs richtig erklär  ::))

Link to comment
Share on other sites

Ich frage mich auch ob das exakte Delay mit Genauigk. von 0.1ms so zuverlässig auf einem Windows-system sein kann...

Wenn ich Markus richtig verstehe möchte er auf das Event des Ventils mit einer zeitl. Verzögerung von z.B. 231,3 ms genau die Kamaera auslösen.

Welches Betriebssystem soll den benutzt werden ?

Link to comment
Share on other sites

@ Nic

 

Jop genauso hatte ich mir das vorgestellt. Ich will ein Linux-System aufstezen.

 

@ Christian

 

USB gibt aber keinen "eigenen Takt" vor oder?

 

Das heißt, wenn das System (wenn es denn echtzeitfähig ist) die Befehle/Nachrichten zum richtigen Zeitpunkt sendet (und z.B. bei 15Hz dürften das ja deutlich weniger sein als 1000) könnte es doch funktionieren oder? Also solange nicht zwei Befehle mit weniger als einer Millisekunde Abstand losgeschickt werden.

 

Viele Grüße,

 

Markus

Link to comment
Share on other sites

Ich vermute, dass ein IO4 genauso gut geeignet sein müsste, kannst du ja mal schauen, wäre ein wenig günstiger ^^

 

Beim Timing weiß ich nciht ob man per USB mit einer besseren Auflösung als 1ms klarkommt. Also selbst wenn ich das Signal auf 0.1ms genau "losschicke", weiß ich nicht, ob die Latenz zwischen senden und empfangen immer die gleiche ist. (oder ausreichend gleich)

 

Ich denke auch, dass die sicherste Variante eine eigene Firmware auf dem Brick wäre, allerdings ist das halt viel schwerer umzusetzen.

Link to comment
Share on other sites

Hi,

prinzipiell sollte, das mit dem ServoBrick möglich sein.

Wenn du z.B. eine Frequenz von 15 Hz einstellst hast du genug Zeit um per USB den Servo zu aktivieren und deaktivieren. So sollten sich Einzelpulse bewerkstelligen lassen.

Zu der Verzögerung:

Die Pulsbreiten der einzelnen Servo Ausgänge lassen sich einzeln definieren.

Gibst du dem ersten Ausgang eine Breite von z.b. 10 ms und dem zweiten eine von 10.5 ms dann hast du eine Verzögerung von echten 0.5 ms.

 

Für Verzögerungen die größer als 65ms sind muss man entsprechend Takte warten

 

Beispiel du möchtest 400 ms Verzögerung

 

1.) Servo 1 und 2 sind disabled Pulsbreite ist auf 0 Periodendauer auf Maximum (65ms)

2.) schicke servo enable für 1 und 2

-Warte 65 ms (Das ServoBrick startet seine erste Periode

3.) schicke pulsbreite für 1 zb 10 ms für 2 vollebreite (65 ms)

-Warte 65 ms (Das ServoBrick vollended seine erste periode und hat ab der 2ten die neuen Werte)

4.)servo 1 disable

-warte floor((400-65)/65)*65 = 325 ms (Das ServoBrick vollended seine 2te periode, der eingang 1 geht aus, nun warten wir entsprechend viele runden (5) bis es zeit wird servo 2 zu triggern

5.)  Setze Pulsbreite an servo 2 auf mod(400,65) = 10 ms

(servoBrick vollended seine letzte "volle" Perioden und führt anschließend noch eine mit dem Rest aus).

-warte 65 ms

6.) disable servo 2

nach dem rest wird ausgeschaltet

 

 

So habe ich zumindest die API verstanden, sollte ich hier Denkfehler haben bitte korrigieren.

 

man müsste dann natürlich noch aus der fallenden Flanke des PWM Signals das gewünschte Triggersignal basteln, je nachdem wie das aussehen soll muss man sich da noch was kleines zusammen löten

Link to comment
Share on other sites

Danke für die vielen Antworten!

 

@ Nic

 

Ich möchte über einen Ausgang die Kamera und über einen anderen Ausgang das Ventil ansteuern. Die Periodenlänge sollte dabei für beide Ausgänge gleich sein, lediglich zeitversetzt zueinander. (ich wollte nicht über einen Ausgang abwechselnd Kamera und Ventil ansteuern)

 

@ AuronX

 

Die Latenz wird für meine Anwendung in der Tat nur zum Problem, wenn sie stark schwankt - in einem anderen Forum habe ich dazu gelesen, dass die Latenzzeiten stark von den übertragenen Datenmengen abhängig sind. Vermutlich muss ich es einfach mal ausprobieren.

 

@ ThomasKI

 

So in etwa könnte ich mir das vorstellen. Du meinst also man könnte den Zeitversatz einfach über die Startzeiten von 1 und 2 einstellen.

Da Du anscheind auch von der prinzipiellen Machbarkeit überzeugt bist, werd ich mir den Brick einfach mal bestellen und mit einem Oszilloskop durchmessen, was tatsächlich an Spannungen rauskommt.

 

Vielen Dank und beste Grüße,

 

Markus

Link to comment
Share on other sites

  • 1 month later...

Hallo Tinker,

 

ich habe jetzt schon seit einiger Zeit den Servo-Brick und bin ziemlich zufrieden mit den Ergebnissen. Das Ventil lässt sich genauso ansteuern, wie ich mir das vorgestellt hatte.

 

Um auch niedriger Frequenzen abbilden zu können, habe ich mir in C eine Krücke gebastelt:

 

for(counter = 1; counter < npuls; counter++)

{

servo_enable(&servo, 0);           // Servo an

servo_set_position(&servo, 0, counter);     // Servo einen weiter

servo_disable(&servo, 0);     // Servo aus

usleep(apuls);         // z.B. 0,5 Sekunden Pause für apuls = 500000

}

 

Das Ganze klappt ganz gut für sehr niedrige Frequenzen (unter 4Hz) – darüber allerdings hat die Schwankung von usleep() (vermutlich auch die USB-Latenz) einen starken Einfluss. Immerhin kann ich jetzt die Frequenz zumindest in den niedrigen Bereichen (<4Hz) und den hohen Bereichen (>13Hz) genau einstellen.

 

Aber: Wenn ich  zwei Servos (bzw. zwei Ausgänge für Ventil und Kamera) innerhalb der for-Schleife ansteuere, springt das Signal des als zweites angesteuerten Servos wie wild durch die Gegend, bzw. ist sehr unsynchron (lt. Oszilloskop).

 

Ich kann so zwar prinzipiell meine Versuche durchziehen, aber ich habe mir zwei Dinge überlegt, die ich gerne noch ändern würde:

 

1) ich habe mir überlegt, dass wenn ich die Servo-Perioden-Funktion auf dem Brick so umschreiben könnte, dass sie für einen Wert von „65500“ (als Eingabewert) nicht 65500, sondern 655000 Mikrosekunden rausgibt (für mehr Spielraum bei den Frequenzen). Kurzum: ein 10er Multiplikator in die Brick-Software einbauen.

 

2) eine sichere Variante, um 2 Signale, die der Brick an verschiedenen Ausgängen ausgibt mit einem vorgegebenen Versatz zu synchronisieren (z.B. Kamera macht immer 1000ys nachdem das Ventil geöffnet hat ein Bild) - könnte etwas tricky werden

 

Über Anregungen und Ideen würde ich mich sehr freuen!

 

Beste Grüße,

 

Markus

 

Link to comment
Share on other sites

Hast du bereits gesehen, dass die Perioden der Servo-Bricks inzwischen auch kürzer eingestellt werden können? (neue Firmware)

 

Bezüglich der asynchronität würde ich denke, dass es dir helfen sollte wenn du deine Servos "in Ruhe" konfigurieren kannst und dann mit einem einzigen Befehl starten könntest:

servo.EnableMany(bitMask);

 

Leider gibt es eine solche API-Funktion nicht, aber möglicherweise würde es ja hinzugefügt werden wenn bedarf besteht und dem nichts entgegenspricht.

Link to comment
Share on other sites

@ AuronX

 

Hi,

 

für mein Problem (2) wäre eine Funktion, die die Parameter mehrerer Servos und eine Beziehung zwischen diesen an den Brick weiter reicht natürlich die optimale Lösung.

 

Ich befürchte bloß, dass die Komplexität einer solchen Lösung meine Möglichkeiten überfordern würde.

 

Hast Du eine Idee, wie man an Problem (1) rangehen könnte?

 

Grüße,

 

Markus

 

Link to comment
Share on other sites

Bezüglich der asynchronität würde ich denke, dass es dir helfen sollte wenn du deine Servos "in Ruhe" konfigurieren kannst und dann mit einem einzigen Befehl starten könntest:

servo.EnableMany(bitMask);

 

Leider gibt es eine solche API-Funktion nicht, aber möglicherweise würde es ja hinzugefügt werden wenn bedarf besteht und dem nichts entgegenspricht.

 

Die enable Funktion kann das schon, siehe zweiten Abschnitt hier:

 

http://www.tinkerforge.com/doc/Software/Bricks/Servo_Brick_C.html#api

 

servo_enable(&servo, (1 << 1) | (1 << 5) | (1 << 7));

 

Wenn Bit 7 gesetzt ist dann werden Bit 0 bis 6 als Bitmask interpretiert. Das Beispiel enabled Servo 1 (1 << 1) und Servo 5 (1 << 5). Alle Zählungen hier sind Null-basiert.

Link to comment
Share on other sites

@ photron

 

Danke für den Tipp. Die Funktion dürfte ideal sein, um Kamera und Beleuchtung aufeinander abzustimmen. (anscheinend hatte ich das mit der Bitmask in der API-Beschreibung einfach nicht richtig verstanden, als ich es zum ersten Mal gelesen hatte^^)

 

Das einzige was ich jetzt noch bräuchte ist eine Möglichkeit, die Frequenzlimitierung der Servo-Funktion aufzulösen.

Meine for-Schleifen-Variante ist extrem ungenau und völllig ungeeignet für mehrere Signale.

 

Meinst du, die Idee mit dem 10er Multiplikator in der Brick-Software ist möglich, oder ist die Dauer des Spannungspulses irgendwie über die Hardware beschränkt?

 

Vielen Dank und beste Grüße,

 

Markus 

 

 

Link to comment
Share on other sites

Ich gucke mir das mit der Frequenz nochmal an, das ist aber an der Stelle leider wirklich nicht so einfach wie es aussieht. Die PWM und Timer Counter Hardwareeinheiten haben 16bit register, von daher gibt es dort eine Beschränkung auf 65535. Das ist an der Stelle erstmal Einheitslos, da kommt es dann jetzt drauf an auf welche Frequenzen die Clocks usw stehen. Dort könnte man evtl. noch dran drehen und die Frequenzen nach Bedarf umstellen, es ist aber keine Sache von 5 Minuten.

Link to comment
Share on other sites

  • 2 weeks later...

@ borg

 

Hallo,

 

hast du dir das mit den niedrigen Frequenzen schon angeschaut? Falls dir der Aufwand zu groß ist, wäre ich dir sehr dankbar, wenn du eine Art "Schlachtplan" posten könntest - ich würde mir das dann hier am Institut mit jemandem angucken, der hin und wieder Controller programmiert.  ::)

 

 

 

Vielen Dank und beste Grüße,

 

Markus

 

Link to comment
Share on other sites

@ borg

 

:D

 

Mit "Schlachtplan" meinte ich eigentlich sowas wie: "guck dir am besten zuerst Clock XY an" ;D

 

Mach dir aber bitte wegen mir keinen Stress - mein Aufbau läuft ja auch so einigermaßen!

 

Ich lasse von mir hören, falls ich in der Sache irgendwas gebacken kriege!

 

Vielen Dank und beste Grüße,

 

Markus

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...