Main Page

From BlenderBlog

Jump to: navigation, search

Controlling industrial robots using Blender

This site will show the progress of the Master thesis' of Adriaan Vandeplas en Jan Yskout


Welkom allemaal op onze Wiki.

Op deze Wiki houden we alles bij over ons Gcode/Blender-Project.

Wij zijn twee laatstejaars studenten aan de Hogeschool GroepT te Leuven. In het kader van onze MasterProef hebben wij gekozen om vanuit twee verschillende afstudeerrichtingen de hoofden samen te steken om een thesis te maken die zowel een deel elektromechanica als een deel ICT bevat.

Hieronder kunt u ons project mee opvolgen. Alles wat we doen en realiseren gaan we hier bijhouden. De exacte omschrijving van ons project vindt je hier.



Give Feedback

Contents

Het Project, De doelstellingen

Image:Robot-Orocos-Blender.jpg


De bedoeling zal zijn om een Gcode bestand te kunnen uitvoeren in Blender. Blender zal de instructies hieruit dan kunnen simuleren of door een echte robot laten uitvoeren. Dit zal gebeuren via een Orocos controller [Open RObot COntrol Software]die mbv IP-communicatie in verbinding staat met Blender. Meer uitleg over deze Orocos controller volgt later nog. Wij zullen alleen gebruik maken van deze bestaande controller en IP-communicatie. Het is niet de bedoeling dat we ook hier nog aan gaan sleutelen. Het bouwen van een controlepaneel in Blender om de nodige bewerkingen te doen zal ook deel uitmaken van onze thesis. Het tweede deel van onze thesis zal er uit bestaan dat we de commando's die de robot uitstuurt via diezelfde Orocos controller gaan gebruiken in Blender om de bewegingen hier dan te visualiseren.

Logboek

10 juni 2008

Het resultaat is te bekijken op Youtube:

23 april 2008

Ondertussen hebben we een voorlopige versie van de tekst opgesteld. Verder zijn we nog enkele tests aan het doen met Blender-OROCOS. Hieruit gaan we dan de afwijkingen op de snelheden bepalen tegenover de ingestelde waarden.

9 april 2008

We hebben nog extra experimenten gedaan met de KUKA 361 robot, zoals het uitfrezen van figuren. Daarnaast zijn we begonnen met een eerste versie te schrijven van zowel de engineering als de integrale context tekst.

14 maart 2008

Vandaag zijn we er in geslaagd om een robot onderstaand paard te laten tekenen. Met een stift bevestigd aan het uiteinde van de robot konden we op een white-board het paard laten tekenen. Dit wilt dus zeggen dat ons zelfgeschreven Orocos component werkt, alsook onze python-code in Blender. Bekijk hier een filmpje. (Voorbeelden in hogere kwaliteit komen nog)

13 maart 2008

We zijn bezig met de laatste stap om te kunnen communiceren met de robot, namelijk de Orocos controller. Deze controller bestaat uit verschillenden software componenten: een controle-lus, een robot-daq en nog enkele anderd componenten die wij niet zo zeer nodig hebben zoals een pad-generator. Om te communiceren met Blender zijn we onze eigen component aan het bouwen. Deze zal een serversocket bevatten waarnaar Blender kan connecteren. Deze component is geïmplementeerd in C++. Omdat het OROCOS systeem nogal uitgebreid is, krijgen we hulp van Ruben, een doctorandus.

7 maart 2008

De doorvoer snelheid: We generen eerst een IPO curve waarvan de horizontale as een tijds as is met frames. We maken 100 frames aan per seconde. Om deze naar orocos te sturen zullen we om de 10 milliseconden (=1/100) 1 frame doorsturen. Zo weet de Orocos dat tussen twee ontvangen frames er 10 milliseconden zitten. De Orocos heeft een eigen controle lus met terugkoppeling van de positie en snelheid. Deze hele lus wordt doorlopen tegen een frequentie die in te stellen is op 100Hz, 200 Hz of 500 Hz.

De nauwkeurigheid van onze bewegingen is gekoppeld aan deze frequentie aangezien wij om de 10 milliseconden een nieuwe positie doorsturen. Hoe kleiner deze stappen hoe nauwkeuriger. In onze toepassing is een nauwkeurigheid van 100 posities per seconde meer dan genoeg. We stellen de frequentie van de Orocos gelijk aan de snelheid waarmee wij hem nieuwe data geven om een perfect match te bekomen.

Zo kunnen we de orocos dus real-time aansturen zonder buffer. We hebben hiervoor gekozen om het mogelijk te maken dat we op ieder moment parameters kunnen aanpassen (snelheid, positie, ...). Ter controle stuurt de orocos telkens een ontvangstbevestiging na ieder nieuw frame naar Blender. Blender zal na ontvangst pas het volgende frame sturen.


De laatste stap vóór we een robot kunnen aansturen is het configureren van de Orocos. Er moet een component gemaakt worden in orocos die de netwerkverbinding uitleest en de posities doorstuurt naar de controller-poort van de Orocos besturing.

5 maart 2008

We zijn blender via IP sockets aan het laten verbinden met een server-programma. Dit server programma hebben we geschreven in C++ en zal worden geïntegreerd in de OROCOS robot controller.

3 maart 2008

We hebben een GUI (graphical user interface) gemaakt om gemakkelijker te kunnen werken met ons programma. Het is mogelijk om een cannonical machine instructions -bestand (CMI-bestand) te selecteren en uit te voeren. Daarnaast is het ook mogelijk om een IP-adres en poort in te geven om te connectoren met een ander systeem (orocos of computer)om deze CMI door te sturen.

27 februari 2008

Aan de kant van Blender hebben we een programma geschreven dat data-pakketjes doorstuurt via IP-sockets. Aan de andere kant staat een andere computer te "luisteren" om deze pakketjes aan te krijgen. Het is dan ook perfect mogelijk om PC1 een CMI-bestand uit te laten voeren, de IPO hiervan te laten genereren en deze dan via die IP-sockets door te laten sturen naar PC2. Deze laatste krijgt deze data doorgestuurd en maakt op basis daarvan exact dezelfde IPO aan. Nu is er dus communicatie tussen twee PC's, de volgende stap is ipv de tweede PC de Orocos-controller aan te sluiten. De Orocos controller werkt in C++ dus moeten we nu in C++ een programma schrijven dat via IP-sockets de data binnenkrijgt van Blender en de data terug parsed (ontleed) in commando's specifiek voor de Orocos.

20 februari 2008

Na een week te werken aan de code om een helix te maken vonden we dat het tijd werd om al onze code beter te organiseren in classes. Hieronder een UML-voorstelling van het project

13 februari 2008

Om ons script compatibel te maken met andere commando's uit de Canonical Machine Instructions moeten we ieder commando weten om te zetten naar ipo instructie 's. Een belangrijk commando is de ARC_FEED. Deze beschrijft een helix (of cirkel indien de hoogte = 0). Deze is nodig omdat we tot nu toe krommingen benaderde door zeer kleine lijn stukjes die zo de kromming vormen. Het ARC_FEED commando definieert een een boog (of helix) mbv enkele punten:

ARC_FEED(double first_end, double second_end, double first_axis, double second_axis, int rotation, double axis_end_point, double a, 
double b, double c)
Het beginpunt van de boog is gegeven door het punt waar we het laatst gestopt waren
[1]double first_end:      Dit is de X coördinaat van het eindpunt van de boog
[2]double second_end:     Dit is de Y coördinaat van het eindpunt van de boog
[3]double first_axis:     Dit is de X coördinaat van het middelpunt van de (grond)cirkel
[4]double second_axis:    Dit is de X coördinaat van het middelpunt van de (grond)cirkel
[5]int rotation:          Dit is het aantal rotaties dat de helix doet.
[6]double axis_end_point: Dit is de Z coördinaat (hoogte) van de Helix
[7]double a:              Dit is de "rotatie-oriëntatie" in de X richting van de spindel 
[8]double b:              Dit is de "rotatie-oriëntatie" in de Y richting van de spindel
[9]double c:              Dit is de "rotatie-oriëntatie" in de Z richting van de spindel


*dit voorbeeld is voor een helix die staat op het XY vlak, het is ook mogelijk om een helix op de andere vlakken te zetten.
Dit wordt ingegeven met het commando SELECT_PLANE (CANON_PLANE plane)
de mogelijkheden zijn: CANON_PLANE_XY, CANON_PLANE_XZ en CANON_PLANE_YZ.
*Het is een fout als de afstand (straal) tussen het middelpunt (x = double first_axis, y = double second_axis) en respectievelijk het   
beginpunt en het eindpunt verschillend is.
*Het is niet mogelijk om een schuine helix te maken

12 februari 2008

Onze eerste script om de canonical machine code om te zetten naar een ipo curve bevatte nog enkele onvolledigheden. We konden enkel een straight traverse uitvoeren. Naast dit commando zijn er nog tal van andere commando's die we moeten opnemen in ons script. (een lijst van al deze Canonical Machine Instructions/commando's) Om dit te doen hebben we on script onderverdeeld in verschillende sub-scripts zoals de parser en de exec. In de parser worden alle Canonical Machine Instructions opgezocht (lijn per lijn), alle waarden worden er dan uitgehaald. Na iedere lijn roept hij de exec aan en stuurt zijn waarden door naar deze exec. de exec zal op zijn beurt de waarden die hij krijgt van de parser gebruiken om een ipo curve aan te maken.

stap 1: lijn 1 van de Canonical Machine Instructions wordt ingelezen
stap 2: de parser kijkt welk commando er op deze eerste lijn staat. hij gebruikt hiervoor een lijst van alle Canonical Machine Instructions
stap 3: de parsrer stuurt een commando met de bijhorende waarden naar de exec
stap 4: de exec zet dit commando om naar een actie op de ipo curve mbv de meegegeven waarden.
stap 5: de volgende lijn wordt ingelezen 
stap 6: ....

17 december 2007

Het is ons gelukt om een object (pointer/kubus) een bepaald traject te laten volgen. In enkele stappen hoe het werkt:

1) we lezen een ngc-file (gcode) in.
2) deze wordt vertaald door de SAI in canonical machine code.
3) de canonical machine code wordt dan omgezet in een IPO curve.
4) Tenslotte voegen we de IPO curve toe aan het object (pointer)

Het is nu deze pointer die later gaat vervangen worden door een frees.

We hebben alles over ons ngc2ipo script meer in detail uitgeschreven, er staat ook een demo-filmpje.

3 december 2007

Vandaag hebben we een eerste versie kunnen maken van de implementatie van de RS274 in Blender. We hebben effectief een Gcode bestand ingelezen in Blender en dit hem laten uittekenen. Meer informatie is te vinden onder RS274

Deze eerste versie van ons script kan alleen maar het commando STRAIGHT_TRAVERSE interpreteren. Om de rest van de Cannonical Machine instructies te implementeren gaan we gebruik maken van een parser. Dit zal later worden uitgewerkt.

We hebben ook al een GUI gebouwd waarmee we ongeveer dezelfde interface hebben als AXIS in EMC2. Dit hebben we gebouwd met een handig programma om via een python script een GUI te maken download instructies.Hiermee zouden we later gemakkelijk dezelfde bewerkingen doen als in AXIS.

Na een gesprek met HB hebben we besloten om de volgende stappen te volgen:


1) we gaan de cannonical machine instructions mbv een parser vertalen naar Blender commando's. Deze parser zorgt ervoor dat alles netjes vertaalt kan worden en overzichtelijk blijft.


2) indien de meest voorname commando's vertaald kunnen worden zullen we deze proberen in een IPO om te zetten. De IPO is een curve waarin alle bewegingen in de tijd worden weergegeven.


3) via de game engine zouden deze bewegingen uit de IPO gebruikt kunnen worden om IK (inverse kinematics) toe te passen. Dit zou dan de "laatste" stap in Blender zijn naar de machine toe.

26 november 2007

We hebben een Gcode (RS274) interpreter gevonden. Hiermee kunnen we Gcode omzetten naar kanonieke machine instructies. Alle info op: NIST

  The RS274/NGC Interpreter (the Interpreter) is a software system that reads numerical control code in the "NGC"                  
  dialect of the RS274 numerical control language and produces calls to a set of canonical machining functions. 
  The output of the Interpreter can be used to drive machining centers with three to six axes. Two earlier                
  versions of the RS274/NGC Interpreter were built. This report describes a new version, version 3.

Enkele python scripts mbt RS274

21 november 2007

Afspraak met HB op PMA

We hebben het EMC2 project bekeken en komen nu samen met HB om deze te bespreken. We hebben zowat alle code afgezocht om te weten te komen hoe zij de gcode omzetten naar machinetaal. Dit heeft geen resultaat opgeleverd. Verder zoeken is de boodschap.

We hebben hier nog een ander project gevonden, maar zijn er nog niet achtergekomen of dit wel is wat we nodig hebben. Xdobs

12 november 2007

Meeting met HB

We hebben uitleg gekregen over het pythonscript van Ruben (IP communicatie)

Uitleg over python script van Ruben:

  1. In één frame inlezen van UDP-packet
  2. Data eruit halen en omzetten in blenderobjecten
  3. Model aanpassen via de aangepaste blender objecten
  4. Visualiseren ahv de game engine

Indien we de CNC-machine uit het labo van GroepT willen interface moeten we uitleg vragen over de mogelijkheden aan Wim Dewulf.

Als dit te moeilijk is zullen we een XY tafel gebruiken aan de KUL/PMA.

We hebben ook nog onze eerste versie van de work breakedown structure en gantchartt gemaakt: WBS‎.

8 november 2007

Meeting met iedereen. We hebben besproken wat het nu uiteindelijk ging worden voor onze thesis.

Het leek heel interessant (met het oog op een gelijke verdeling van EM en ICT) om een CNC machine te interfacen en aan te sturen en visualiseren via blender. Concreet zou dit dan zijn een module bouwen in Blender die een G-code bestand zou kunnen inlezen en de bewegingen omzetten in blender (visualisatie) en deze bewegingen laten laten uitvoeren door de machiene.

Hetgeen we maken MOET generiek zijn. Daarom zouden we naast een CNC machine/XY tafel ook een andere willekeurige robot mee kunnen aansturen. Deze zou dezelfde bewegingen moeten kunnen maken.

Er bestaat al een opensource project dat bezig is met dergelijke CNC systemen die Gcode inlezen en omzetten naar "machinetaal". Dit project noemt EMC2. We zouden van hun vooral de Gcode interpreter willen gebruiken om te kunnen inplementeren in onze eigen toepassing. Enkele websites over Gcode en CNC:


GcodeProject:

  • User Interface for EMC2 (visualisatie): AXIS

30 oktober 2007

Tijdens een kleine meeting met JB hebben we besproken hoever we stonden met onze "voorstudies". We hebben in het algemeen besproken wat de volgende stappen gingen zijn. We hadden dringend een concreet plan nodig en dit zouden we niet op ons eigen hebben kunnen doen, dus hadden we graag expliciet aan HB willen vragen om ons op gang te helpen. Het "grote" probleem was vooral dat er veel ICT werk is maar dat we graag een onderwerp hadden gehad waarbij het ict deel EN het em deel even groot waren.

JB raade ons ook aan om ( met het oog op het plan van aanpak) eens zelf concreet op papier te zetten wat we allemaal al hadden en welke richting we uit zouden kunnen/willen gaan.

22 oktober 2007

Meeting met HB op PMA. We hebben kennis gemaakt met een praktische opstelling van de robot, de orocos controller en een besturings-systeem gelijk Blender. Hierbij zijn we meer te weten gekomen over the big picture van de besturing. conclusie:

  • Blender verstuurt commandos over IP naar Orocos, hiermee moet er rekening gehouden worden met de verschillende snelheden van gegevens overdracht en verwerking. Er is dus een soort van buffer om dit op te vangen.
  • We hebben ook de python scripts die deze IP-communicatie in Blender verzorgt gekregen van HB.


We hebben deze scripts proberen te analyseren, we konden wel niet alle scripts aan de praat krijgen omdat we niet de nodige input kregen van de controllers van de Orocos.

17 oktober 2007:

Afspraak met HB We hebben uitgelegd dat we het Modelica project niet zo goed zagen zitten en hebben toegelicht waarom dat dit zo is. We hebben nogmaals andere mogelijkheden besproken. We zouden het over een andere boeg gooien. Er is een project dat bezig is met het aansturen van de robot via IP (ethernet)

De communicatie tussen de gebruiker en de robot gaat door drie systemen. Het eerste deel is de robot zelf, deze communiceert met een Orocos controller, deze laatste communiceert met een computer waarop bijvoorbeeld Blender draait. In dit project gaan ze in Blender een python script schrijven om deze laatste stap over IP te kunnen realiseren.

wij zouden dan verder werken met dit python script om een robot in Blender aan te sturen terwijl zijn bewegingen gevisualiseerd worden in Blender. In eerste instantie zou deze communicatie gaan van de robot naar blender, eventueel later van blender naar de robot.

Er is ook sprake van het optimaliseren van de sturing van de robot ( op een zo efficiënt mogelijke manier, zo snel mogelijk van het ene punt naar het andere te gaan). Hierbij zouden we een bestaande P-regelaar onderzoeken en eventueel vervangen door PID , ook nog de feedforward lus analyseren en hoe de sensoren ingelezen worden.

Interesting links

  • The open source 3D software we will use: Blender


Cannonical Machining Commands (RS274):

  • RS274 python scripts: RS274


GcodeProject:


  • User Interface for EMC2 (visualisatie): AXIS
Personal tools