[News] Multimachine Lichtgeschwindigkeit präzise

OSEG Projekte Projektinkubator ("PROTO")
21

Um jedes Smartphone oder Tablet nutzen zu können, bedeutet dies, dass wir irgendwie das langsame USB-Protokoll umgehen müssen (da nur der Audioanschluss echtzeitfähig sein könnte).
Wir könnten die Software ändern und die USB-Hardware/-Stecker verwenden. Ich habe jedoch keine Ahnung, wie schwierig das sein wird. Es wird einfacher sein, als die (proprietäre) Hardware/Verkabelung zu modifizieren.

EDIT: Es stellt sich heraus, dass das USB-Protokoll nicht so langsam ist; es gibt zwei Geschwindigkeitsmodi. Es ist für Echtzeitanwendungen geeignet, bei denen das Verpassen einer Frist toleriert werden kann (da ein Jitter von wenigen Millisekunden auftreten kann). [USB-Protokoll Echtzeitfähigkeitsanalyse]

Das BeagleBoneBlack ist nach wie vor die Alternative, um den oben beschriebenen Software-Stack darauf auszuführen (und weitaus praktikabler) – oder ein Desktop/PC/Smartphone/Tablet/… mit paralleler Schnittstelle (oder einem vergleichbaren echtzeitfähigen E/A-Protokoll). Solche tragbaren Geräte mit mehreren echtzeitfähigen Ein- und Ausgängen existieren jedoch möglicherweise nicht.

22

Korrektur: BeagleBoneBlack 1GHz → Quad Core (wahrscheinlich UDOO), da das BBB einfach nicht genug Rechenleistung hat und somit nicht bereit für zukünftige Upgrades wie AMOR (3D-Kamera-Software-Stack), Blender für ARM und Touch-Geräte ist. Für LinuxCNC (ehemals LinuxEMC2) könnte das BBB jedoch ausreichen.

23

Die dritte Möglichkeit ist die Verwendung eines SCARA-Roboterarms. Wahrscheinlich die universellste Lösung (abgesehen von einem 6-Achsen-Roboterarm). Als Nebeneffekt könnten die für den Rahmen benötigten Materialien reduziert werden. Ich würde mir etwas Input von euch wünschen.

Auf jeden Fall werden wir das BeagleBoneBlack nicht verwenden, da es nicht leistungsfähig genug ist, um unseren Linux- / Steuerungssystem- / Bildverarbeitungs-Stack auszuführen. Das UDOO Quad Core ist Arduino-kompatibel und verfügt über integrierte GPIOs (im Gegensatz zum Wandboard Quad Core, fürchte ich).

Werfen Sie einen Blick auf dieses nicht allzu voreingenommene UDOO vs.Competitors.pdf und Sie werden sehen, was ich meine.
Sollten wir nicht aufhören, das Rad immer wieder neu zu erfinden? Ich denke, das ist im Sinne von Arduino – und daher ist die Nutzung von Echtzeit-ARM-Linux auf dem UDOO Cortex A9 und einer reinen C+±Teilmenge von Arduino auf dem Arduino Due-Prozessor (SAM) von UDOO ideal.

Sowohl Wandboard als auch UDOO sind vollständig Open-Source-Hardware + Software (sogar die GPU, wenn ich mich nicht irre).

24

Hey Jan :wink:

Ich glaub dieser Typ ist ungeeignet, Du brauchst tatsächlich einen 6-Achser.

Zitat WIkipedia:

Dieser Robotertyp wurde auf Grund seiner schnellen und wiederholgenauen Bewegung speziell für sogenannte Montage- und Fügeaufgaben, sowie für Pick-and-Place-Anwendungen, bei der ein Bauelement von Platz (a) nach Platz (b) gebracht wird (typisch für Handhabungs- und vorbereitende Montagearbeiten), entwickelt. Seine Stärke ist das vertikale Fügen mit hohen Fügekräften (teilweise >300N), ohne dass es zu seitlichem „Ausweichen“ kommt. Ein Nachteil des Scara-Roboters besteht darin, dass er stets nur parallel zu einer Arbeitsebene hantieren kann, da ihm für nicht planparallele Flächen die Freiheitsgrade fehlen. Für solche Anwendungen sind 5- oder 6-Achs-Roboter geeignet.

Wenn ich das richtig verstehe, dann kann dieser Typ zwar den Saugbecher (oder wie das in der Melker-Fachsprache heisst) bis unter die Zitze bringen, aber dann nicht in einer Aufwärtsbewegung daran anschliessen.

Ausserdem scheint der zwar auf „hohe Fügekräfte“ ausgelegt zu sein, aber was Du brauchst ist schätzungsweise eher sowas wie Feingefühl mit schnellem Feedback-Loop. Eine klassische Testaufgabe für Robothände besteht darin, ein rohes Ei aufzunehmen - ohne es dabei zu zerquetschen, sowas in der Art meine ich.

Jetzt noch was zum Arm-Board:

Soweit ich bis jetzt verstanden habe gehts Dir um mehr Leistung um die Bildverarbeitung „flüssig“ genug hinzubekommen und daher wären also mehrere Kerne wünschenswert. Und Preis wäre auch noch ein Kriterium.

Ich kenn zwar den Udoo nicht, aber hab hier seit nem halben Jahr den Odroid U3, am laufen und bin bislang damit ganz zufrieden.
Kannst Dir den ja mal anschauen, der hat im gegensatz zum Udoo 2GB Ram statt nur einem, die CPU ist mit 1.7Ghz deutlich schneller (und auch quad), aber der Preis dafür beträgt rund die Hälfte :wink:

Oder falls Du doch soviel ausgeben möchtest bekämst Du dafür den neuen Odroid XU3, der hat sogar 8 Kerne, davon 4 mit 1,7Ghz getaktet und 4 sogar mit 2 GHz. Im Vergleich mit dem BBB hat der Odroid eine eigene GPU und damit eine deutlich bessere (bzw. schnellere) Grafik. Was mir ausserdem noch sehr gut daran gefällt, das ist die Odroid-community, sowas ist für mich auch immer ein wichtiges Kriterium und die Odroid-community scheint mir ganz passabel zu sein.

OK, das vielleicht als Anregung.

Gruss, Oliver

25

Absolut. Nice to hear first-hand experience, I’ve already played with the thought of adopting Odroid.

Über SCARA, du hast recht, eine translatorisches Gelenk muss eingefügt werden. Der Vorteil ist, dass die Theorie für the SCARA in Übungen zu einer Robotervorlesung schon vollständig erschlossen wurde, das heißt die ganzen Kontroll-Algorithmen wären schon da. Die zusätzliche translatorische Achse ließe sich einpflegen.

Wenn ich in LinuxCNC Entwicklung eingearbeitet bin, dann wird sich zeigen, ob die dortigen 6-Achsen Algorithmen verwendbar sind.

Für die Fräse wäre der Roboter geeignet da SCARA, wie du bereits hilfreich zitiertest, robust ist und nicht zur Seite wegrutschen kann. Der Hauptvorteil von derart Robotern ist, dass wenig Gerüst/Mechanikstruktur im Weg ist. D.h. man kann sperrige Objekte platzieren. Und man benötigt kein Grundgerüst, da der Roboter direkt auf dem Boden operieren könnte.

Es ließen sich also schwere Teile - z.B. Motor- oder Roheisenblöcke in den Roboterarbeitsbereich ziehen, evtl. mit Schrauben im Boden fixieren, dann das ein oder andere ausfräsen oder mittels Schweiß-3D-Drucker Aufsatz hinzuschweißen (das alles ohne das sperrige Teil heben zu müssen).

Anschließend könnte man den Platz wieder anderweitig verwenden, weil der Roboter so platzsparend ist.
Vor allem mit sperrigen Teilen hat man ein Fixierproblem bei herkömmlichen Fräsen (die auch meist eine gewisse Grundhöhe haben).

Natürlich müsste man das ganze in die Waage bringen, d.h. entweder

  • 3D Scan Funktionalität in den Roboter einbauen, damit planare Flächen erkannt und die kartesischen X,Y,Z Achsen dementsprechend kalibriert werden können.
  • Oder das Werkstück mithilfe beispielsweise einer Wasserwaage so montieren, dass die Achsen passen.

3D Scan hat den Vorteil, dass (Skalierung und) Rotation der Fertigungs-Zeichnungs automatisch ausgerichtet/gematcht werden könnte.

Das ließe sich mittels einer integrierten Tool-Kamera auch manuell matchen (insbesondere korrekte Rotation der Zeichnung), falls dies einfacher ist als das Werkstück zu drehen. Skalierungs-Matchen ist optional, da man beim CAD-Zeichnen eh auf korrekte Maße achten muss. Als End-Kontrolle wäre es dennoch hilfreich zu sehen, ob die Maße auch wirklich passen. (mittels Overlay von Kameraaufnahme/3DScan und Zeichnung)

3D Scan hat weitere Vorteile:

  • Nutzbar als 3D-Vorlage Objekt, also als Ausgansobjekt zur Modifikation, d.h. man kann ohne viel Modellieraufwand direkt die CAD-Pläne davon ableiten.
  • Automatische Kanten-/Eckenerkennung. D.h. man kann den Nullpunkt automatisch setzen. (Das muss man sonst immer manuell machen - und das geht auch noch wenn man ein komplett neues Teil aus z.B. einer Eisenplatte ausfräsen will. Es wird jedoch kritisch, wenn man aus einem vorhandenen Teil nur etwas Spezifisches wegfräsen/hinzuschweißen muss. )
26

Leuchtet mir soweit ein.

Hab grad mal geschaut was thingiverse so zu dem Thema hergibt, esgibt dort sehr viele robot arm designs, aber folgende zwei scheinen mir ganz gut zu Deinem scara-vorschlag zu passen:

und

Interessant fand ich auch noch dieses hier:

und als Zubehör dieses:

Gruss, Oliver

27

Interessant fand ich auch noch dieses hier:

Multi Use Robotic Arm SCARA Equivalent MURASE by pghauff - Thingiverse

Das fand ich auch sehr nützlich. Von den anderen wusste ich nichts. Dein erster Vorschlag ist sehr gut. Das blaue, das du als zweites gepostet hast, muss definitiv vereinfacht werden. Die Ästhetik ist in Ordnung, aber man muss es erst einmal konstruieren können. Einfachheit gewinnt. Der Leitfaden, dem ich zu folgen versuche, ist die Verwendung von rein planaren Teilen, sodass sie aus einem Blech/Kunststoff/was auch immer (Graphen? :slight_smile:) geschnitten werden können.

Für den Melkroboter werden mehrere robotische Manipulatoren konstruiert, einfachere und kompliziertere, vielleicht sogar einer mit 6 Kugelgelenken (rotatorisch).

28

Es scheint, als wären die Cura Engine (C++) + Cura (Python) immer noch ziemlich aktiv. Das sieht nach einem Projekt mit längerer Lebensdauer aus. Es ist derzeit die einzige Alternative/Notlösung, sollte mein RT-Linux + LinuxCNC-Ansatz fehlschlagen.
Edit: Wobei ich möglicherweise nicht über parallele Fortschritte bei all den anderen Open-Source-Entwicklungen informiert bin. Die Redundanz ist hier ziemlich intensiv.

29

Du hattest Cura ja schon vor ein paar Monaten mal erwähnt, von daher hatte ich es auf dem Schirm. Aber ziemlich bald stolperte ich über einen review wo jemand aus dem Nähkästchen paluderte. Demzufolge scheint Cura einigen KlickiBuntischeiss zu haben, den die Welt nicht braucht, aber dafür einige gravierende Bugs.

Habs dann wieder von meinem Schirm gestrichen. :wink:

Ausserdem: was heisst schon groß C++ ? Das ist für mich ein Synonym für grottenlangsam :wink: Wenns wenigstens ANSI-C wär. Wenns nicht auf Performance ankommt, dann nehm ich gleich Java.

Ausserdem2: Eigentlich ist es piepegal wie performant ein Slicer ist. Worauf es ankommt, das ist, ob er zB. damaged 3D-Files reparieren kann.

Just my 2cents.

Gruss, Oliver

30

Im Allgemeinen bevorzuge ich C++ gegenüber C für komplexe Programme. Es ist viel einfacher, dynamische Lösungen zu programmieren. All die Workarounds in C unter Verwendung von Structs sind für komplexe Dinge oft kontraproduktiv (auch wenn sie funktionieren!), da die Wiederverwendbarkeit nicht so einfach ist; man kann zum Beispiel ein Struct nicht erweitern. Daher ist C+±Code weniger redundant.
Obwohl ich natürlich auch ein Fan von C bin. Für einfache Dinge ist es episch.

Mein Hauptanliegen bei der Programmierung ist nicht die Geschwindigkeit, sondern dynamische und wiederverwendbare Lösungen. Ohne das Single-Source-Prinzip rauben einem große Projekte die gesamte Zeit.

Was JAVA betrifft, hatte ich einige Probleme damit … eine JAVA Virtual Machine auf eine neue Architektur zu portieren und dort auszuführen, ist auch etwas, das ich nicht wirklich tun möchte. Zu viel Herumgefummel, wenn das Programm auch einfach aus dem Quellcode kompiliert werden könnte.


> Ausserdem2: Eigentlich ist es piepegal wie performant ein Slicer ist. Worauf es ankommt, das ist, ob er zB. damaged 3D-Files reparieren kann.

Ja, und das ist ein kompliziertes Problem. Ich mag dafür immer noch Blender und vielleicht MeshLab am liebsten. 3D-Modelle können chaotisch sein. Es könnte für einen Computer schwierig sein, automatisch herauszufinden, wie das Modell hätte aussehen sollen, bevor es beschädigt wurde. Daher denke ich, dass es meistens ein manueller Prozess bleibt, es sei denn, man hat es mit Spielzeug zu tun, aber das tun wir sicher nicht – Spielzeug hilft diesem Planeten nicht sehr – okay, wenn es der Bildung dient oder die Vorstellungskraft von Kindern fördert, dann ist es in Ordnung. Nichts dagegen.

31

Naja, im Normalfall würd ich mich darauf verlassen, das die JVM-Implementation dann schon von jemand anderem gemacht wurde :wink: Aber anyway, ob Java oder C++, das ist wohl eine Frage des jeweiligen perönlichen Geschmacks, tut sich also nicht viel. Ich hub nur darauf ab, weil es Dir um Performance zu gehen schien. In Sachen Maintainbarkeit von großen Projekten ist aber sicherlich C++ oder Java zu bevorzugen.

Ausserdem2: Eigentlich ist es piepegal wie performant ein Slicer ist. Worauf es ankommt, das ist, ob er zB. damaged 3D-Files reparieren kann.

Yes, and that’s a complicated problem, still like blender and perhaps MeshLab best for that. 3D models can be messy. It might be difficult for a computer to automatically figure what the model should have resembled before it was messed up.

Ja, aber da gibts spezielle Reparatur- und Test-programme, hab neulich z.B. mal netfabb ausprobiert, das scheint ganz gut zu gehen. Abe prinzipiell ists natürlich besser wenn erst gar keine Fehler in die 3D-Datei eingebaut werden und diesbezüglich hat mir Blender tatsächlich schon vielfach geholfen. Soll heissen, regulärer Workflow ist bei mir (für Einzelteile) FreeCad → Blender → Slic3er, wobei der Zwischenschritt über Blender genau zum Zweck hat, die Datei zu validieren. Und wenn ich sage „die Datei“, dann meint das eigentlich .stl-Format, in der Praxis hat sich aber als Transferformat zwischen FreeCad und Blender das .wrl-Format (also VRML) als am erfolgreichsten erwiesen, d.h., das hilft oft auch in ansonsten hoffnungslosen Fällen. Wahrscheinlich weil es am ehesten einem True-BREP-Format entspricht und ausserdem auch schon alt genug ist um halbwegs sauber implementiert zu sein. Aber wie gesagt, der Zwischenschritt mit Blender ist segensreich und ausserdem brauch ich den sowiso, sobald ums assemblieren von in FreeCad konstruierten Einzelteilen geht.

Gruss, Oliver