Linear CCD auslesen

Hallo!

Ich überlege, ob es für eine technische Anwendung hier im Unternehmen machbar ist, die Position eines Objektes mit einem Linearsensor zu bestimmen. Das Ganze muss sehr genau sein, deshalb klappt es nicht mit einfachen Lichtschranken oder ähnlichem.

Es geht darum, in einem gewellten Blechteil festzustellen, wo die Mitte des Wellentals ist. Die Wellen sind nicht völlig gleichmäßig und die Wellenberge sind mitunter schief, können also auch nicht als Anhaltspunkt dienen.

Meine Idee ist, im unteren Bereich der Welle einen Linear-CCD-Sensor an die Welle zu legen und entlang der Welle zu beleuchten. Der belichtete Teil des CCD zeigt die Wellenbreite, in der Mitte ist der gesuchte Punkt. Die unbelichteten Teile liegen außerhalb der Welle, das Licht kann sie nicht erreichen, weil es auf die Wellen fällt. Siehe Bild.

Der Sensor müsste möglichst nah an der Welle sein, sollte also bauartbedingt nicht viel Abstand (Glasscheibe) zwischen seiner Oberfläche und den photoempfindlichen Zellen selbst haben. Der Lichtstrahl sollte wenig streuen. Der Sensor muss möglichst tief liegen, weil die Ergebnisse dann besser sind.

Die Wellen sind je nach Fertigung von unter 1 cm bis knapp über 3 cm breit, Die erforderliche Sensorbreite liegt also bei ca 3 cm. Die Ungenauigkeit der Messung (durch Streuung oder ähnliches) sollte unter 0,5 mm liegen. Der ausgegebene Wert könnte als Abweichung (+/-) gegenüber dem Mittelpunkt des Sensors ausgegeben werden und sollte mit einer Genauigkeit von 0,1 mm angegeben sein. 8 Bit genügen.

Das Ergebnis wird in einer SPS zur Steuerung der Maschine verwendet. Die Wellen werden intervallartig mit bis zu 5 Takten pro Sekunde vorgeschoben. Die Messung und Berechnung erfolgt im Moment des Stillstands und muss also sehr schnell gehen, höchstens unterer zweistelliger ms-Bereich. Ich tippe aber, das geht sogar deutlich schneller.

Ich hab schon fleißig gegoogelt - die Ansteuerung dieser CCD scheint recht schwierig zu sein.

(Wie) Könnte man sowas mit Arduino realisieren? Hat jemand Erfahrung mit dem Auslesen solcher Sensoren und kann jemand einen konkreten Sensor in passender Größe empfehlen?

Hat jemand vielleicht noch ganz andere Ideen?

CCD1.jpg

Hallo,
das Prinzip gibt es schon fertig in der Qualitätskontrolle. Da braucht es richtig RechenPower für. Ich glaube nicht,
das der Arduino das schafft.

"wo die Mitte des Wellentals ist"

Ich würde das mit einer Kugel oder einem Rad abtasten. Eine Welle funktioniert doch immer gleich...
Höchster Linker Punkt, tiefster Mitte Punkt, höchster rechter Punkt. Diese Punkte kannst Du doch messen und
sie Dir merken.
Gruß und Spaß
Andreas

Wenn du die Rollenmechanik vermeiden willst oder das Blech nicht verkratzen darfst, würde auch Lasermessung gehen. Ultraschall dürfte zu langsam sein und dazu eine Keule ausbilden, also keinen definierten Messpunkt. So bekommt man viel zu viel Ungenauigkeit rein.

CCD-Zeile auslesen wäre eine Möglichkeit, aber da du mit einer Lichtquelle arbeiten willst und keine genauen Wellen hast wird das berechnen der Reflexionen des Lichtes sehr kompliziert, dürfte die Verarbeitungsmöglichkeiten des Arduinos übersteigen. Mit einer Messung alleine wird zuviel von der Ausrichtung des Lichtes und dem Wellenverlauf abhängen. Und dann auch der genaue Messzeitpunkt.

Jedenfalls nichts was man typischerweise mit Atmel Prozessoren macht. Lasermessung erscheint mir hier die eleganteste Lösung. Den eine Rolle die 5x sec hoch runter rollt muss ganz schön Druck haben um dem Verlauf zu folgen. Das könnte im Blech sichtbare Spuren hinterlassen.

Ja, wenn s so einfach wäre, wäre es ja einfach. Leider sind die Wellen nicht gleichmäßig und das Auskugeln würde auch viel zu lange dauern. Aber mal im ernst... das Auslesen von ein Paarhundert Zellen kann doch nicht so lange dauern? Die Dinger werden im mittleren Kilohertzbereich betrieben. Im Grunde brauche ich ja auch nur den ersten und den letzten hellen Punkt... Eine Digitalkamera schafft es, im Sekundentakt Bilder mit 16 Megapixeln zu schießen... Für meinen Zweck würden 120 Pixel völlig reichen... Wenn ich die beiden Punkte binär suche, hab ich genau 12 Pixel auszulesen...

x=31
Lese Pixel x
Wenn dunkel x-16, sonst x+16
Lese Pixel x
Wenn dunkel x-8, sonst x+8
Lese Pixel x
Wenn dunkel x-4, sonst x+4
Lese Pixel x
Wenn dunkel x-2, sonst x+2
Lese Pixel x
Wenn dunkel x-1, sonst x+1

Das Ganze für beide Seiten... das kann doch nicht länger als "ein paar" Taktzyklen dauern.

Werft bitte noch mal einen Blick auf die Zeichnung. Blech und Sensor stehen bei der Messung still. Der Sensor liegt vorne direkt mit Kontakt an den Wellen. Es wird vom anderen Wellenende auf den Sensor geleuchtet. Ich muss nur wissen, welche äußersten Punkte des Sensors noch Licht bekommen. Ich messe sozusagen nur die Breite des (Nicht-)Schattens.

Hallo,
das ist alles schöne graue Theorie...
Man könnte Zeilenweise lesen, und erst rechnen, wenn in der Zeile etwas besetzt ist.
Und dann nur die rechnen, die besetzt sind.
Was kommt denn aus so einem MessSensor raus? Was liefert der denn?
Gruß und Spaß
Andreas

So ein Sensor wird meines Wissens sozusagen gelöscht, dann für einen gewissen Moment belichtet und dann werden die Ladungen auf den Sensorzellen wie bei einem Schieberegister nacheinander rausgeschoben und und über einen D/A-Wandler ausgelesen...
Wäre halt nett, wenn sich jemand meldet, der sich damit auskennt...

Gnom67:
So ein Sensor wird meines Wissens sozusagen gelöscht, dann für einen gewissen Moment belichtet und dann werden die Ladungen auf den Sensorzellen wie bei einem Schieberegister nacheinander rausgeschoben und und über einen D/A-Wandler ausgelesen...
Wäre halt nett, wenn sich jemand meldet, der sich damit auskennt...

Das ist der klassische CCD Ansatz.
Oft wurden zwei Zeilen nebeneinander gelegt, eine beleuchtet und eine abgedeckt,
mit dem Shutter Signal wurden die Ladungen in den abgedunkelten Bereich verschoben
und dann wie geschildert 'seriell' ausgelesen.

Wenn du einen Sensor ausgesucht hast, könntest du festellen ob du wahlfreien Zugriff auf die Zellen hast,
oder ob du die in einem Schwung auslesen musst, wie schnell das Ding ist etc.

Gearbeitet habe ich mit den Dingern noch nicht.

Ich könnte mir vorstellen, dass ein Due mit DMA dir die Daten einfach in den Speicher knallt.

CCD = charge-coupled device = ladungsgekoppeltes Dingsbums

Bei der Wiki-Suche bin ich gerade über diesen Zeilensensor gestolpert, da wird auf Seite 6 das Prinzip gezeigt.

Ja, genau so stell ich mir das vor. Die Ladungen auf dem Chip sind ja keine digitale Information und müssen erstmal irgendwie raus aus der Photozelle und digitalisiert werden... Wahrscheinlich muss man ein Taktsignal reingeben und am Ausgang den A/D-Wandler anwerfen.
bis 500K fps - heißt das 500.000 Pixel pro Sekunde - wären 2 ms für eine komplette Zeile. Das würde reichen. Und die Inhalte von 1024 Bytes auf hell/dunkel zu untersuchen, kann für den ATMega auch keine Sache von Stunden sein... nur zu schmal ist das Ding sicher.

Nur, wer weiß, wie man so ein Ding steuert? Und mit integriertem A/D-Wandler und direktem Speicherzugriff wäre es sicher überschaubarer.

Inzwischen bin ich auf Contact Image Sensoren (CIS) gestoßen. Das sind die Dinger, die in einfachen Flachbettscannern eingebaut sind. Ich hab einen geeigneten gefunden. 10,4 cm breit bei 203 dpi, 864 Pixel, läuft mit 5 V. Siehe Datenblatt.
Hat jemand schon mal einen CIS angesteuert?

Grundsätzlich funktioniert der sehr einfach und liefert analoge Werte. Es wäre einen Versuch wert, die direkt vom ATmega lesen zu lassen. Allerdings schafft der D/A-Wandler im ATmega nur ca. 10.000 Samples pro Sekunde. Das würde knapp 100 ms für die Zeile brauchen, während der Sensor die in 0,4 ms liefern kann.
Vielleicht genügt es schon, einen schnellen A/D-Wandler-IC zu benutzen und die digitalen Werte zu weiteren Auswertung in den Arduino zu geben. Dafür dürfte er schnell genug sein. Ein A/D-Wandler mit 100 KHz würde genügen.
Hat da jemand Erfahrung?

datasheet.pdf (57.2 KB)

Du brauchst im Prinzip nur eine hell - dunkel Unterscheidung. Der Komperator im ATmega sollte wohl ein Stück schneller sein, als das ganze AD-Wandler Gedöns.

Ansonsten, ein weiterer Ansatz zum Messen der Trapeze wäre meiner Meinung nach ein Rotationslaser. Die Winkelgeschwindigleit ist auf dem Tal eine andere, als an der Schräge :wink:

Oder erschlage das Problem mit einem Raspi und einer Cam, der kann auch rudimentäre Bildverarbeitung

nix_mehr_frei:
... Die Winkelgeschwindigleit ist auf dem Tal eine andere, als an der Schräge :wink:

Ich finde das Problem so interessant, dass ich den Thread lese, ohne aus dem Stand Sinnvolles beitragen zu können. Meinst Du mit „auf dem Tal“ so, wie man „neben der Spur“ sagt?

CNR

Gregor

PS: Damit der OP wenigstens eine Frage bekommt: Wie sind die Dimensionen (in mm oder wasauchimmer) des Problems?

[OT]

Müsste man die tiefste Position des Blechs nicht auch mit ein paar Hall-Sensoren lokalisieren können?

(Unter dem Blech, versenkt in der Lauffläche vielleicht?)

[OT]

Hier wurde so etwas (Line Sensor) mit einem PIC gemacht:
https://hackaday.com/2014/01/05/image-sensor-for-filling-wine-bottles

Gnom67:
Allerdings schafft der D/A-Wandler im ATmega nur ca. 10.000 Samples pro Sekunde. Das würde knapp 100 ms für die Zeile brauchen, während der Sensor die in 0,4 ms liefern kann.

Du meinst A/D-Wandler. Du kannst ja mal schauen, ob Du einen Arduino mit schnellerem A/D-Wandler findest. Ein Teensy ist zwar kein Arduino, läßt sich aber wie einer programmieren.

Meßwerte:

100 analogRead UNO Zeit:        11308 µs
100 analogRead Teensy 3.2 Zeit:  1061 µs

Mir schwebt immer wieder das Kürzel FPGA durch das Neuron. Sind das nicht die Dinger, die für besonders schnelle Datenverarbeitung bekannt sind? Ich hatte noch nie mit so einem Ding zu tun, habe aber den Eindruck, dass so ein Ding Teil der Lösung sein könnte.

Sagt die Stimme aus dem ahnungslosen Off :slight_smile:

Gregor

Ein FPGA wäre wohl eher ein Overkill.

Ein DSP wäre wahrscheinlich schnell genug,
für die von mir verlinkte Anwendung reichte ein PIC der in der Arduino Klasse liegt.

Whandall:
Ein FPGA wäre wohl eher ein Overkill.

Ein DSP wäre wahrscheinlich schnell genug,
für die von mir verlinkte Anwendung reichte ein PIC der in der Arduino Klasse liegt.

Danke für die Erhellung! Ich habe einfach zu wenig Erfahrung, aber was ich über FPGAs gelesen habe, klang als schnell genug für alles, was ich mir bis dato vorstellen konnte. Noch eine dieser Sachen, mit denen ich mich ja eigentlich mal gerne beschäftigen würde. Aber da gibt es immer mehr, als ich leisten kann.

Gruß

Gregor

FPGA ist hardwaremässig gebrannte Software. Statt also eine Berechnung komplett auszuführen wird eine Umrechnung programmiert die aus bestimmten Eingangsmuster bestimmte Ausgangsmuster innerhalb eines Taktes erzeugt.

Nehmen wir Kreisberechnung

Input: Radius
Output: Umfang
Formel: Raduis2Pi()
Berechnung:
Wert1 holen
Wert2=Wert12
Wert3=Wert2
3,14
Mindestens 6-7 Speicherzugriffe und einige Takte für Berechung.

FPGA werden bei sowas dann hochoptimiert:
Für Input 1 Output 3,14
Für Input 2 Output 12,56
Also wird die Formel praktisch zusammengefasst zu einer Berechnung, die dann ohne Rechen-CPU direkt in Logicbausteinen umgesetzt wird.

Und das jeweils in einem Takt. Aber mehr können die dann eben nicht. Probleme die man nicht auf diese Art lösen kann, sind mit FPGA nicht zu machen.

Allerdings wird hier inzwischen auch gemischt, sprich, teilweise in Logigarrays vorbereitet und dann an eine reguläre CPU weiter gereicht die dann zuende rechnet. FPGA sind kundenspezifisch hergestellt. Zwar gibt es auch universelle FPGA, aber heute sind die meisten genau aufs Problem hin gearbeitet. zB wenn man 20 Kupferaderpaare hat (Telefonie) und die digitalisieren muss und an ein Bussystem weiter reichen. 20x immer das selbe machen. Aus einem Analogeingangswert wird ein Digitalwert und das dann komprimmiert. Die Komplexität kann durchaus hoch sein, aber man kann zb keine Unterscheidungen und Verzweigungen programmieren.

chefin:
FPGA ist hardwaremässig gebrannte Software. Statt also eineAber mehr können die dann eben nicht. Probleme die man nicht auf diese Art lösen kann, sind mit FPGA nicht zu machen.

Das ist Quatsch.

Es gibt fertige Prozessor-Cores (zum Beispiel ARM) und DSP-Cores die in einem FPGA residieren können.

Und gebrannt werden die nicht, sondern beim jedem PowerUp neu geladen.