Vision-Erkennung bei Bestückungsautomaten

[Holle]

Klar kommst du auch weitestgehend mit Billigteilen aus, aber die kritischen Stellen sind kritisch und damit muss man sie ordentlich durchdenken und auch Geld hinblättern.
Das sind: Führungen, Kugelumlaufspindeln und das Image Aquisition System. Der Rest ist Vergleichsweise günstig: Eine Vakuumpumpe kann man sich vom Schrott besorgen, bzw aus Schrotteilen selbst zusammen bauen. Ein kleiner Überschlagswert: Spindeln und Führungen 400 Euro, Kamera gebraucht sind knappe 200 Euro (Ich bekomme eine für 35. Vllt lässt sich für dich auchnoch eine rausschlagen. Eine günstige Framegrabberkarte gibt es sicher auch günstig irgendwo gebraucht zu kaufen. Alles in allem wirst du aber einen knappen tausender für eine solche Maschine hinlegen! Holz kannst du ganz vergessen, damit habe ich die letzten Projekte gemacht. Ausserdem verzieht sich Holz schon bei geringsten Temperaturunterschieden derart dramatisch, das du niemals eine Genauigkeit von 1/10 hinbekommen wirst, ohne alle halbe Stunde neu einzumessen. Weiterhin ist Holz auch sehr Feuchtigkeitsempfindlich: Das bedeutet einmal das Garagentor oder die Tür zur Aussenwelt geöffnet und schon hast du wieder Ungenauigkeiten drin.

Ja, eine finale Lösung ist das nicht mit dem Holz, aber zum testen reicht das aus. Es wäre schade wenn man sich etwas aus Alu fräsen lässt und stellt nachher fest dass es so garnicht funktioniert. Zum Thema alle halbe Stunde neu kalibrieren:
Das wäre in meinen Augen OK, solange es sich um einen Prototypen handelt. Wenn es dann alles so funktioniert wie gewünscht kann man immer noch die Teile aus Alu fertigen lassen uns austauschen. Wahrscheinlich wird man zwischendurch aber immer wieder etwas ändern, so dass die Zwischenlösung mit Holz "schneller" und "viel günstiger" wäre.
...wie gesagt, während der Testphase als Zwischenlösung. Dass Holz nicht das endgültige Material sein kann ist klar.
Also 1000 Euro kann ich derzeit nicht aufbringen. Mein Plan geht eher in die Richtung alles provisorisch zu basteln, Probleme auszumerzen und wenn es soweit zufriedenstellend läuft mit der Erfahrung/Steuerung/... "gescheit" zu bauen. Bis dahin habe ich dann vielleicht auch genügend Geld um da 1-2k zu investieren.

Mit der Bilderkennung kannst du ganze Vorlesungen füllen, das ist alles kein Problem. Die Frage ist, welche Kamera eine gute Genauigkeit liefert und dabei nicht zu teuer ist. Ausserdem muss sie relativ weit verbreitet sein oder zumindest überall verfügbar. Spezialkameras bringen uns nicht weiter. Ich weiß noch nicht einmal, wie weit ich mit der CameraLink Kamera komme, die ich nun bekomme. Vielleicht gibt es dafür keine Treiber, die die Bilder an Video4Windows weitergeben oder ich kann allgemein gar nicht darauf zugreifen? Auch hier muss noch eine ganze Weile Forschung betrieben werden. Ich hoffe hier auf die Erfahrungen der anderen Nutzer dieses Boards die vielleicht schon einmal etwas mehr gemacht haben, als nur mit einer Gameboykamera herumgespielt. Die Erwartungshaltung, die du von der Optical Image Aquisition (OAI) und der damit verundenen Bilderkennung hast, scheint mir eine "naja, wird nicht so wirklich schwer sein" zu sein (Ich hoffe, ich missinterpretiere das jetzt nicht!). Auch hier will ich nochmal dran erinnern: Die Maschine zu bauen wird das leichteste sein, was auf uns zukommt! Die Bilderkennung verschlingt bei den Firmen (Siemens, etc) zehntausende, wenn nicht sogar hunderttausende von Euros. Man sollte sich mit Matrizen und Mathe auskennen, wenn man da ran gehen möchte. Ich schätze, ich habe noch bei weitem nicht genug Erfahrung und Wissen, um Bildverarbeitung richtig zu verstehen. Das kommt dann erst im achten Semester, sprich in der Industrie.

Ich denke auch dass die Bilderkennung die härteste Nuss wird, aber mit ein paar Tests werden wir da schon etwas "zusammen schustern". Mit der Zeit können wir das dann vielleicht auch verbessern. Ein großer Schritt wäre gemacht wenn wir "Kanten/Linien" erkennen können.

Kannst du mir mal erklären, wie die Shapes in den aktuellen Bestückungsautomaten erzeugt werden? Ich habe leider noch keinen gesehen, daher habe ich davon keine Ahnung. Vielleicht ist das ja ganz ähnlich zu der Methode die ich oben gepostet habe. Danke!

Klar kann ich das...
Zuerst wählt man eine Shape-Klasse (BGA, QFP, usw.). Als nächstes wird die Gehäuse-Größe angegeben (Länge/Breite). Nun noch die Anzahl der Beine/Balls, sowie deren Größe. Beim QFP z.B. gibt man X/Y Gehäusemaße ein und X/Y Gesamtmaße. Das (Gesamtmaß - Gehäusemaß) / 2 ist die Beinlänge. Die Beinbreite und den Pitch muss man auch eingeben. Aus diesen Daten wird ein 2D-Bauteilbild erzeugt. Nun noch die Höhe und der Shape ist fertig. Es fehlen aber noch die Angaben zur Nozzle (welche soll verwendet werden), Geschwindigkeit (wie schnell darf das Bauteil in X/Y bewegt werden und in Theta (gedreht). Weiterhin werden in dem Shape noch Angaben zum Feeder gemacht (welcher wird verwendet, wie tief liegt das Bauteil in der Tasche, ...).
Der Shape selber ist aber schnell erzeugt. Man hat natürlich einige Klassen zur Auswahl und kann zusätzlich noch Optionen angeben (Bestückversatz, Abholversatz, abweichende Toleranzen, fehlende Beine/Balls, usw.) ...das ist aber nur eine Option und nicht zwangsläufig nötig.

Die Kamerabeleuchtung ist nicht ganz unerheblich. Schlechtes Licht führt zu sehr schlechten Erkennungsraten und damit zur Verzweiflung des Programmierers (ich! ). Weiterhin muss der Abstrahlwinkel der LED's berücksichtigt werden und das Field of View (FOV), das man erreichen will. Das FOV errechnet sich aus dem Abstand des Objekts zum Sensor und aus der Brennweite der Linse. Durch die Brenweite der Linse kann man den Fokuspunkt (focal point) und das FOV in der Diagonale in ° berechnen. Das hängt dann von der Größe der Bauteile ab und wie hoch die Auflösung der Kamera ist. Schlechtere Bildqualität benötigt eine höhere Vergrößerung um die Unschärfe zu kompensieren. Damit vergrößert sich aber auch wieder die Region of Interest (ROI) und damit die Rechenleistung und Zeit, die man braucht um das Bild zu berechnen und die Position zu korrigieren. Das ganze ist eine Gratwanderung zwischen Rechenleistung, Geschwindigkeit, Qualität und und und. Es sind so viele Faktoren zu berücksichtigen, dass ich nicht wirklich weiß, wo ich anfangen soll. Deswegen erst einmal mit der Kamerabeleuchtung weil das so ziemlich das einfachste ist was man bauen kann, ohne vorher schon alles konstruiert zu haben. Da weiß ich, dass die Beleuchtungsdichte direkt über der Öffnung der Halbkugel gleichbleibend sein muss um eine gute Bildqualität zu erzielen. Mit deiner Angabe von "2 Winkel" kan ich mir den Rest für den Dome herleiten. Wichtig ist eben nur die Flächendeckung.

Ich bin heute nicht dazu gekommen Fotos zu machen, aber die kommen noch, versprochen. Bei der MSF kann man zwischen 2D und 3D Kamera wählen und das jeweils zwischen Large und Small. Es ist zwar nur EINE 2D-Kamera und nur EINE 3D-Kamera im Portal verbaut, aber mit "Small" nutzt man eine Vergrößerung. Die Small und Large Kamera haben eigene Offset-Werte, also sind da entweder 2 Kameras in einem Gehäuse oder ein mechanischer Zoom, denn wenn das nur ein digitaler Zoom wäre, dann bräuchte man keine 2 Offsets. Die Rechenleistung sollte keine Probleme bereiten, denn wenn es ein Pentium 233 schafft 20 Köpfe sau schnell zu handeln (und natürlich auch den Rest der Maschine), dann sollte ein Ein-Kopf-Bestückautomat (der zudem noch recht langsam ist) mit einem "modernen" PC recht unterfordert sein.

Die NC Steuerungen sind meist so aufgebaut, dass das komplette Programm in den Speicher der NC geladen wird und dann Schritt für Schritt ausgeführt wird. Da das MAterial dabei abgenommen wird, ist es kein Problem, das Programm zu pausieren und an der Aussprungadresse wieder einzuspringen. Vielleicht mag das bei Profimaschinen nicht der Fall sein (Laserschneidanlagen haben durch ihre Hardwarebeschaffenheit sehr viel mehr Einsprungmöglichkeiten zu haben), doch bei den normalen NC Fräsen habe ich das so kennen gelernt. Also laden und ausfüren mit pausieren, aber immer nur das komplette Programm. Nun haben wir aber eine Pick and Place Maschine. Die muss die G-Codes "on the fly" im Programm erzeugen und dann Befehl für Befehl in die NC laden (zb bei einer Korrektur der Lage des Bauteils), die das dann ausführt. Das ist nicht wirklich praktikabel. Die großen Firmen haben auch da eigene Steuerungen gebaut, die mit den Programmen, die auf dem Rechner laufen interagieren. Da herrscht eine sehr starke Bindung zwischen Hard- und Software. Leider bin ich zumindest erst einmal an die USBCNC gebunden. Vielleicht wird das später anders. Es wird auf jeden Fall ein Modul "cnc" geben, das die ganze Maschine einstellt und handelt. Dieses Interface muss recht allgemein gehalten werden, dass man später, wenn man eine andere Maschine mit dem Programm nutzen möchte, einfach das Modul umschreibt und nicht das ganze Programm umschreiben muss. Schön ist da das Klassenmodell von C++, mit dem ich die Schnittstelle, die das Programm benutzt öffentlich haben kann und den Rest des Moduls (Umsetzung der Maschinenkoordinaten, initialisierung, Verbindungserstellung mit der NC, bewegen der Achsen, eventuelle E-Stops oder Sicherheitsschalter, usw, usf) einfach vor dem Programm verstecken kann, so dass es sich nicht mehr darum kümmern muss. Das wird alles vom Modul erledigt.

Das mit dem Programm ist bei SMD-Automaten überhaupt kein Problem. Es wird Zeile für Zeile abgearbeitet, somit ist jederzeit eine Unterbrechung möglich.
Bei Siemens-Bestückautomaten ist das schon wieder anfälliger (ein winziger Stromausfall und man kann die LP wieder abwaschen). Panasonic handelt das etwas anders, da kann man selbst nach einem Stromausfall problemlos weiter machen wo man aufgehört hat. Problematischer wird es wenn man mitten im Programmablauf manuell dazwischen rum fummelt. In dem Fall ist es dann nötig den Startblock anzugeben, wo die Maschine weiter machen soll. Bei einer Maschine mit mehreren Köpfen ist das aber oftmals nicht so einfach weil 10 Bauteile auf einmal abgeholt werden, aber dann z.B. ein Bauteil nicht gesetzt wurde (z.B. Erkennungsprobleme). Wenn ich nun den Shape anpasse und einfach im Programm nachsehe welchen Block dieses Bauteil hatte und diesen als Startblock angebe kann es sein dass die anderen 9 Bauteile "doppelt" bestückt werden. Beispiel: Das Bauteil war Block Nr. 50. Der Kopf hat nun aber Block 50 bis 59 auf einmal abgeholt. Das Bauteil von Block 50 wurde nicht erkannt, aber die anderen (Block 51 bis 59) wurden erkannt und gesetzt. Wenn ich nun den Startblock 50 angebe (das Bauteil fehlt ja noch auf der Karte) würden die Blöcke 51 bis 59 ebenfalls nochmal mit bestückt werden. Aus diesem Grunde gibt es auch 3 Betriebsmoden: Auto, Block, Step
Auto: Das Programm wird automatisch abgearbeitet
Block: Es wird immer nur ein Block abgearbeitet (vom abholen bis zum setzten)
Step: Es wird immer nur ein winziger Teil gemacht. Z.B.: Nozzle über das Bauteil fahren - Nozzle auf das Bauteil aufsetzten - Das Bauteil aufnehmen - Zur Kamera fahren - Über die Kamera fahren - Zur Bestück-Position fahren, Das Bauteil auf die LP aufsetzten - Nozzle wieder hoch fahren.
Der Step-Betrieb wird zum Einrichten und zur Fehlersuche gebraucht.

Wichtig ist die Dokumentation der Arbeits- und Entwicklungsschritte und eine Buchführung über die verschiedenen Revisionen. Bei der Software, die ich baue ist github das Mittel der Wahl. Ich hoffe, dass ich dadurch das Chaos in meinen Projekten bändigen kann

Ja, das ist in jedem Programm so ....und VIEL Kommentare verwenden, damit man sich auch Jahre Später schnell wieder im Quellcode zurecht findet.

PS: Dann zieh du mal um und sag mir, wenn du fertig bist. Vllt können wir zusammen ein Konzept erarbeiten. Mittelfranken dürfte ich nach 3-4h Zugfahrt erreicht haben. Bin gespannt, wie euer Kaffee schmeckt und ob ihr damit in Konkurrenz zu dem Schwäbischen Kaffee treten könnt

Ich ziehe nicht um, wir renovieren nur. Meinst du es macht Sinn jetzt schon ein Konzept zu erarbeiten? Ich dachte wir machen erst ein paar Tests (wie steuern wie die Schrittmotoren richtig an, welche Methoden zur Bilderkennung funktionieren in der Praxis, usw.). Wenn dann die einzelnen Schritte erfolgreich erprobt wurden wäre ein Konzept dran wie man das am besten nutzen kann. Derzeit wissen wir ja noch nicht mal ob die Motoren geeignet sind, oder welches Interface geeignet ist.