[News] Multimachine lightspeed precise

[J.R.I.B]

To use any smartphone or tablet this means we have to somehow get around the slow USB protocol (because only the audio jack may be realtime-capable).
We could change the software and use the USB hardware/plug. No idea though how difficult this will be. It will be easier than modding the (proprietary) hardware/wiring.

EDIT: Turns out the USB protocol is not that slow, there are 2 speed modi. It’s suited for realtime where missing a deadline can be tolerated (as jitter of a few milliseconds may occur). [USB-Protocol Realtime Capability Analysis]

The BeagleBoneBlack still is the alternative to run the above-described software stack ontop (and much more feasible) - or a desktop/pc/smartphone/tablet/… with parallel port (or any comparable realtime capable IO protocol). Though such portable devices with multiple realtime capable in- and outputs might be non-existant.

[J.R.I.B]

Correction: BeagleBoneBlack 1GHz → Quad Core (probably UDOO) as BBB simply has not enough calculating power and thus is not ready for future upgrades like AMOR (3D camera software stack), blender for ARM and touch devices. For LinuxCNC (formerly LinuxEMC2) the BBB might be enough though.

[J.R.I.B]

The third possibility is to use a SCARA robotic manipulator. Probably the most universal solution (aside from a 6-axis robotic manipulator). As side effect the materials required for the frame could be reduced. I’d wish some input of you guys and gals.

In any case, we won’t use the BeagleBoneBlack as it’s not powerful enough to run our Linux / control system / Image processing stack. UDOO Quad Core is Arduino compatible and has GPIO built in (contrary to Wandboard Quad Core, I’m afraid).

Have a look at this not too biased UDOO vs.Competitors.pdf and see what I mean.
Shouldn’t we stop reinventing the wheel over and over again? I think that’s in the sense of Arduino - and thus the usage of realtime ARM Linux on UDOO Cortex A9 and bare C++ subset Arduino on UDOO’s Arduino Due processor (SAM) is ideal.

Both Wandboard and UDOO are fully open source hardware + software (even the GPU if I’m not mistaken).

[case]

Hey Jan

@J.R.I.B.

The third possibility is to use a SCARA robotic manipulator. Probably the most universal solution (aside from a 6-axis robotic manipulator). As side effect the materials required for the frame could be reduced. I’d wish some input of you guys and gals.

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

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

[J.R.I.B]

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. )

[case]

@J.R.I.B.

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).

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:

Polar 3d Printer by Torleif

und

Printable Robot Arm by 4ndreas

Interessant fand ich auch noch dieses hier:

Multi Use Robotic Arm SCARA Equivalent MURASE by pghauff

und als Zubehör dieses:

Hypocycloid Robot Arm Joint by bkorsedal

Slew bearing, 160x60x8mm by i-make-robots

Gruss, Oliver

[J.R.I.B]

Interessant fand ich auch noch dieses hier:

Multi Use Robotic Arm SCARA Equivalent MURASE by pghauff - Thingiverse

That one I also found very useful. Didn’t know of the others. Your first proposal is very nice. The blue one you posted 2nd definitely must be simplified. Esthetics is fine, but first you have to be able to construct it. Simplicity wins. The guideline I try to follow is using planar parts only such that they are cuttable from a sheet of metal/plastic/whatver (graphene? ).

For the milking robot several robotic manipulators will be constructed, easier and more complicated, perhaps even one 6 spherical joints (rotatory).

[J.R.I.B]

Seems the Cura Engine (C++) + Cura (Python) are still quite active. That looks like getting a more long-living project. It’s currently the only alternative/hot-fix should my RT-Linux + LinuxCNC approach fail.
Edit: Though I might be uninformed about parallel progress in all the other open source develpments. Redundancy here is quite intense.
https://github.com/daid/Cura
https://github.com/Ultimaker/CuraEngine

[case]

@J.R.I.B.

Seems the Cura Engine (C++) + Cura (Python) are still quite active. That looks like getting a more long-living project. It’s currently the only alternative/hot-fix should my RT-Linux + LinuxCNC approach fail.

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.

Ausserdem: was heisst schon groß C++ ? Das ist für mich ein Synonym für grottenlangsam 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

[J.R.I.B]

Generally prefer C++ over C for complex programs. Much easier to code dynamic solution. All the workarounds in C using structs is often counter-productive for complex things (while they work!) - because reuse is not so easy, can’t extend a struct for example. Thus C++ code is less redundant.
Though I’m a fan of C too of course. For simple things that’s epic.

My major concern with programming is not about speed but about dynamic and reusable solutions. Without single source principle big projects will strip you off all your time.

As of JAVA, had some issues with it … getting a JAVA virtual machine ported to a new architecture and run there is also something I not really want to do. Too much fiddling, when the program also just could be compiled from source.

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. So I think it’s still mostly a manual process unless one deals with toys but we surely don’t - toys don’t help this planet very much - ok, if they serve education or building imagination of children, then it’s okay. Nothing against that.

[case]

@J.R.I.B.

As of JAVA, had some issues with it … getting a JAVA virtual machine ported to a new architecture and run there is also something I not really want to do. Too much fiddling, when the program also just could be compiled from source.

Naja, im Normalfall würd ich mich darauf verlassen, das die JVM-Implementation dann schon von jemand anderem gemacht wurde 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