När man bestämmer upplösning på en sevomotor så ska man tänka på att den inte ligger lika exakt i steg som en stegmotor, hela principen är ju att man kompenserar kraften på motorn om positionen är fel.
Motorerna till min maskin på jobbet verkar ha en upplösning på typ 1000000000 steg/varv med andra ord analog upplösning.
Om jag "peter" på motoraxeln så ser jag att positionen ändras.
Med så hög upplösning är det lättare att göra en kontroller som styr perfekt och är lugn men ändå aggressiv.
Det är hyffsat lätt att göra en encoder om man gör det på rätt sätt, jag kan förklara det en annan gång.
Att ta läsgafflarna från en mus går väl(förutsatt att stig och fall-tiden är ok) men det är roligare att köpa nytt till ett sånt seriöst projekt.
Servomotor-styrning, PID, diverse tester
Chribbe76,
Hur ser protokollet mellan dator och PIC ut? Och vad använder du för program för att titta på datat? Buffrar du data eller kan du se vad som händer, ändra PID-parametrar m m i realtid?
Jätteintressant projekt! Jag har ett halvfärdigt projekt som har legat på hyllan i över ett år nu, med ett färdigbyggt kort med en FPGA, kvadraturencoderingångar och analoga utgångar tänkta just för momentstyrning av servomotorer (m a p position - siktet är inställt på en CNC-fräs, förstås
). Jag körde fast lite på VHDL-implementeringen av regulatorn. När jag la av så kunde jag läsa av motorposition i realtid men inte så mycket mer.
Tanken var att börja med en PID-regulator för att se hur bra den funkar, men sen fortsätta med en state-space-regulator istället. Bättre prestanda och lättare att trimma in, vad jag har förstått.
Arvid
Hur ser protokollet mellan dator och PIC ut? Och vad använder du för program för att titta på datat? Buffrar du data eller kan du se vad som händer, ändra PID-parametrar m m i realtid?
Jätteintressant projekt! Jag har ett halvfärdigt projekt som har legat på hyllan i över ett år nu, med ett färdigbyggt kort med en FPGA, kvadraturencoderingångar och analoga utgångar tänkta just för momentstyrning av servomotorer (m a p position - siktet är inställt på en CNC-fräs, förstås
). Jag körde fast lite på VHDL-implementeringen av regulatorn. När jag la av så kunde jag läsa av motorposition i realtid men inte så mycket mer.Tanken var att börja med en PID-regulator för att se hur bra den funkar, men sen fortsätta med en state-space-regulator istället. Bättre prestanda och lättare att trimma in, vad jag har förstått.
Arvid
Vridpot går inte att använda dels för att den inte kan rotera kontinuerligt och pga slitaget.
Exprimenten fortsätter.
Det här är samma test som tidigare fast med all info på samma bild.
Det blir lite grötigt så det underlättar om man zoomar.
P finns inte med för den är ändå väldigt förutsägbar, den är linjär med Error(svart).
I och D har korrekt upplösning (1 pixel = 1).
Summan är dividerad med 2 (1 pixel = 0.5).
Rörelsemönstret är samma som tidigare så det är inte heller med i bilderna.
P=2.625
I=0.0488
D=15.75
http://ake.myftp.org/forum/ServoTest1_Err-I-D-Sum.gif
Så här ser det ut om jag försöker vrida motorn fram och tillbaka för hand, motorn har inget rörelsemönster utan försöker bara stå still.
http://ake.myftp.org/forum/ServoTest1_E ... _kraft.gif
Nu har jag ökat PID-parametrarna för att få motorn att bli snabbare på att kompensera för externa krafter.
Motorn låter inte alls bra, och man ser tydligt den låga upplösningen på D(blå).
Problemet med att få D att ge mjuka förändringar är att värdet ligger mellan c:a -5 till +5 och har inga decimaler och måste sen multipliceras med ett högt värde för att ge en korrekt D-kompnent, i exemplet nedan multipliceras den med 31.5
P=5.31
I=0.098
D=31.5
http://ake.myftp.org/forum/ServoTest2_Err-I-D-Sum.gif
Här har jag lagt in ett primitivt filter på D, den räknar ut medelvärdet av dom 2 senaste värdena vilket fungerar förvånanvärt bra, motorn låter inte alls lika mycket.
Man ser tydligt att upplösningen på D(blå) är bättre.
Det optimala skulle vara ett filter som inte försämrar responstiden men som ändå ger mjuka förändringar och hög upplösning, jag får fundera mer på det senare.
P=6.25
I=0.106
D=33.25
http://ake.myftp.org/forum/ServoTest3_Err-I-D-Sum.gif
Extern påverkan som i Test1, nu kompenserar den snabbare.
http://ake.myftp.org/forum/ServoTest3_E ... _kraft.gif
Resultatet som jag har nu skulle kunna duga för en cnc-maskin tycker jag, med 4000 steg/varv så är det väl ok med 20 steg fel vid snabba förändringar av kraften.
Avvikelsen på Error i testerna som uppstår varje gång den accelererar är omöjliga att få bort helt eftersom motorn aldrig kan accelerera oändligt snabbt.
När man styr en motor från ett riktigt cnc-kontroller-program bestämmer man hur snabbt motorn ska kunna accelerera och verktygsbanan anpassas efter det, då kommer man bara få stora avvikelser vid förändring av belastningen.
Men det går givetvis att förbättra detta ytterligare och det ska jag försöka göra.
Exprimenten fortsätter.
Det här är samma test som tidigare fast med all info på samma bild.
Det blir lite grötigt så det underlättar om man zoomar.
P finns inte med för den är ändå väldigt förutsägbar, den är linjär med Error(svart).
I och D har korrekt upplösning (1 pixel = 1).
Summan är dividerad med 2 (1 pixel = 0.5).
Rörelsemönstret är samma som tidigare så det är inte heller med i bilderna.
P=2.625
I=0.0488
D=15.75
http://ake.myftp.org/forum/ServoTest1_Err-I-D-Sum.gif
Så här ser det ut om jag försöker vrida motorn fram och tillbaka för hand, motorn har inget rörelsemönster utan försöker bara stå still.
http://ake.myftp.org/forum/ServoTest1_E ... _kraft.gif
Nu har jag ökat PID-parametrarna för att få motorn att bli snabbare på att kompensera för externa krafter.
Motorn låter inte alls bra, och man ser tydligt den låga upplösningen på D(blå).
Problemet med att få D att ge mjuka förändringar är att värdet ligger mellan c:a -5 till +5 och har inga decimaler och måste sen multipliceras med ett högt värde för att ge en korrekt D-kompnent, i exemplet nedan multipliceras den med 31.5
P=5.31
I=0.098
D=31.5
http://ake.myftp.org/forum/ServoTest2_Err-I-D-Sum.gif
Här har jag lagt in ett primitivt filter på D, den räknar ut medelvärdet av dom 2 senaste värdena vilket fungerar förvånanvärt bra, motorn låter inte alls lika mycket.
Man ser tydligt att upplösningen på D(blå) är bättre.
Det optimala skulle vara ett filter som inte försämrar responstiden men som ändå ger mjuka förändringar och hög upplösning, jag får fundera mer på det senare.
P=6.25
I=0.106
D=33.25
http://ake.myftp.org/forum/ServoTest3_Err-I-D-Sum.gif
Extern påverkan som i Test1, nu kompenserar den snabbare.
http://ake.myftp.org/forum/ServoTest3_E ... _kraft.gif
Resultatet som jag har nu skulle kunna duga för en cnc-maskin tycker jag, med 4000 steg/varv så är det väl ok med 20 steg fel vid snabba förändringar av kraften.
Avvikelsen på Error i testerna som uppstår varje gång den accelererar är omöjliga att få bort helt eftersom motorn aldrig kan accelerera oändligt snabbt.
När man styr en motor från ett riktigt cnc-kontroller-program bestämmer man hur snabbt motorn ska kunna accelerera och verktygsbanan anpassas efter det, då kommer man bara få stora avvikelser vid förändring av belastningen.
Men det går givetvis att förbättra detta ytterligare och det ska jag försöka göra.
Programmet i datorn är gjort i VB och är inget färdigt program det är bra ett test.
Jag kan avslöja att det hela buggar lite ibland, när jag trycker på start ska programmet skicka styrdata till motorn men ibland händer inget alls.
"Protokollet" ser ut så att Picen skickar ut 2 byte varje Pid-loop.
Första byten är 126 ellet 127 beroende på om Picen tycker att styrdata-bufferten börjar bli tom eller ej andra byten är en parameter.
VB skickar styrdata eller nya Pid-parametrar med en byte som beskriver vad som ska skickas och sen datan (1 eller flera byte).
Styrdatan är helt enkelt antal Pidloopar(2 byte) och hur mycket positionen ska förändras varje loop(2byte), inte så märkvärdigt och duger inte till en cnc-kontroller.
Picen kan bara skicka 1 parameter år gången(skulle gå att skicka fler men det blir lite ont om tid) så man väljer vilken parameter man vill uppdatera i realtid genom att klicka på den knappen, all annan grafik blir fryst så man kan se dom olika parametrarna samtidigt.
Det här state-space-köret låter intressant, ska försöka läsa lite om det nån gång.
Om man bara tittar på hur motorn går obelastad eller med en konstant belastning så ser det mycket bra ut.
Den felande länken är I som fortfarande är för trög och för dum, jag ska försöka förbättra den biten.
Jag kan avslöja att det hela buggar lite ibland, när jag trycker på start ska programmet skicka styrdata till motorn men ibland händer inget alls.
"Protokollet" ser ut så att Picen skickar ut 2 byte varje Pid-loop.
Första byten är 126 ellet 127 beroende på om Picen tycker att styrdata-bufferten börjar bli tom eller ej andra byten är en parameter.
VB skickar styrdata eller nya Pid-parametrar med en byte som beskriver vad som ska skickas och sen datan (1 eller flera byte).
Styrdatan är helt enkelt antal Pidloopar(2 byte) och hur mycket positionen ska förändras varje loop(2byte), inte så märkvärdigt och duger inte till en cnc-kontroller.
Picen kan bara skicka 1 parameter år gången(skulle gå att skicka fler men det blir lite ont om tid) så man väljer vilken parameter man vill uppdatera i realtid genom att klicka på den knappen, all annan grafik blir fryst så man kan se dom olika parametrarna samtidigt.
Det här state-space-köret låter intressant, ska försöka läsa lite om det nån gång.
Om man bara tittar på hur motorn går obelastad eller med en konstant belastning så ser det mycket bra ut.
Den felande länken är I som fortfarande är för trög och för dum, jag ska försöka förbättra den biten.
-
Greensilver
- Inlägg: 1305
- Blev medlem: 21 januari 2005, 21:24:57
- Ort: Sverige
- Kontakt:
Jäkligt fint program! Är ju väldigt trevligt att kunna sitta direkt i PC-miljön och ändra parametrarna tills man hittat något som fungerar, om du vill dela med dig av källkoden är jag helt klart intresserad. Håller på att experimentera med samma sak, se min plattformstråd i projektdelen. Skall bara försöka fixa ett bättre gyro sen kan jag på allvar börja labba med PID. Har just nu bara P.
Det borde väl funka om du utökar det till 3 axlar? Styckvis linjär interpolering borde funka ganska bra, jag räknade på det där förut och felet vid t ex en cirkel blir på mikrometernivå även i rätt bra hastigheter, om du kör i 115200 b/s. Nu kommer jag inte ihåg exakt hur jag räknade, men det såg bra ut i vilket fall.Chribbe76 skrev:*snip*
Styrdatan är helt enkelt antal Pidloopar(2 byte) och hur mycket positionen ska förändras varje loop(2byte), inte så märkvärdigt och duger inte till en cnc-kontroller.
*snip*
Det går ut på att titta på så många parametrar som möjligt hos det som regleras; i motorfallet blir det väl typiskt position och hastighet. Med state-spacereglering kan du även ha många styrsignaler och många utsignaler. Tyvärr är fortsättningskursen i reglerteknik typ den enda som jag fortfarande inte har tagit tentan på på KTH. Det var lite för mycket komplexanalys och matrisalgebra som dök upp där... tror den kursen är riktad mer åt elektro än åt data, som jag går. Men jag jobbar på det.Chribbe76 skrev:*snip*
Det här state-space-köret låter intressant, ska försöka läsa lite om det nån gång.
*snip*
Arvid
Det jag menade med att det inte duger till en cnc-kontroller är att jag bara skickar tid och fart.
Om man ska styra något ska man ange absolut-positioner istället.
Jag har oxå räknat på det och visst kan man göra noggrann interpolering i hög fart genom com-porten.
Tillbaka till testerna.
Integratorn hade ganska dålig upplösning pga att jag använder en 8bitars multiplikation som var ganska dåligt anpassad.
Jag tog bort hela multiplikationen och flyttar bitarna istället, då kan man bara multiplicera med 0.5 eller 0.25 eller 0.125 osv.
Nu kunde jag ha högre I utan att upplösningen påverkar negativt.
Resultatet är helt ok även om den överkompenserar lite på vissa ställen.
P=6.25
I=0.25
D=33.25
http://ake.myftp.org/forum/ServoTest4_Err-I-D-Sum.gif
Och med extern påverkan.
http://ake.myftp.org/forum/ServoTest4_E ... _kraft.gif
I det här testet har jag ökat I ännu mer så den överkompenserar ganska mycket men resultatet är ändå ganska ok.
P=6.25
I=0.5
D=33.25
http://ake.myftp.org/forum/ServoTest5_Err-I-D-Sum.gif
Nu blir felet inte alls stort vid extern påverkan.
http://ake.myftp.org/forum/ServoTest5_E ... _kraft.gif
Om man ska styra något ska man ange absolut-positioner istället.
Jag har oxå räknat på det och visst kan man göra noggrann interpolering i hög fart genom com-porten.
Tillbaka till testerna.
Integratorn hade ganska dålig upplösning pga att jag använder en 8bitars multiplikation som var ganska dåligt anpassad.
Jag tog bort hela multiplikationen och flyttar bitarna istället, då kan man bara multiplicera med 0.5 eller 0.25 eller 0.125 osv.
Nu kunde jag ha högre I utan att upplösningen påverkar negativt.
Resultatet är helt ok även om den överkompenserar lite på vissa ställen.
P=6.25
I=0.25
D=33.25
http://ake.myftp.org/forum/ServoTest4_Err-I-D-Sum.gif
Och med extern påverkan.
http://ake.myftp.org/forum/ServoTest4_E ... _kraft.gif
I det här testet har jag ökat I ännu mer så den överkompenserar ganska mycket men resultatet är ändå ganska ok.
P=6.25
I=0.5
D=33.25
http://ake.myftp.org/forum/ServoTest5_Err-I-D-Sum.gif
Nu blir felet inte alls stort vid extern påverkan.
http://ake.myftp.org/forum/ServoTest5_E ... _kraft.gif
Jag måste skaffa lite grejer och börja experimentera själv tror jag!
Har funderat lite på att skriva ett eget cnc program, Jag tycker det känns lite föråldrat med step/direction styrning.. Skulle hellre se att programmet skickar koordinater och kontrollen buffrar dom så den får lite "föraning" om vad som ska ske i nästa steg. Bör göra mycket för att optimera accelerationerna!
Problemet är att jag vill ha en sexaxlig kontroller då jag vill bygga en hexapod, och om det inte "ryms" på ett chip så kan det bli tungt att synka koordinaterna Vad tror ni?
Har funderat lite på att skriva ett eget cnc program, Jag tycker det känns lite föråldrat med step/direction styrning.. Skulle hellre se att programmet skickar koordinater och kontrollen buffrar dom så den får lite "föraning" om vad som ska ske i nästa steg. Bör göra mycket för att optimera accelerationerna!
Problemet är att jag vill ha en sexaxlig kontroller då jag vill bygga en hexapod, och om det inte "ryms" på ett chip så kan det bli tungt att synka koordinaterna
Vad tror ni?En hexapod, nice.. Om det är en fräsmaskin du vill bygga så har du egentligen en axel för mycket men det gör ju inget.
Jag har inte studerat hur hexapod-beräkningarna ser ut men det borde vara tungt som fan.
Jag tycker inte att synkningen av axlarna borde vara svårare än alla andra delar av ett sånt projekt.
En maskin på jobbet hade c:a 0.003 sek fel mellan 2 axlar och det är på tok för mycket i vissa fall.
Och nu till mina tester...
Pid-parametrarna i testerna nedan är
P=3.125
I=0.125
D=25
I det här exemplet har jag gjort en konstant friktions-kompensering(kompnivå=25) som motvarar den lägsta friktionen som konstruktionen har, i mitt fall motorns egen friktion.
Jag har tagit bort Integratorn så det är en PD-kontroller.
http://ake.myftp.org/forum/ServoTest6_UtanI_MedF25.gif
Liknande test men med en f-komp på 60 och motorn är bromsad för hand med tyg mellan fingrarna och motoraxeln för att få konstant friktion.
Vi ser att även det fungerar bra
http://ake.myftp.org/forum/ServoTest6X_ ... _Kraft.gif
Här kan ni se hur det blir utan friktions-kompensering, obelastad motor.
Med endast P och D får man stationära Error.
Det fåniga är att den stannar exakt på 0 när motorn ska stå stilla vilket den inte gör med f-komp, egentligen är det orimligt att den stannar exakt på 0 utan I.
http://ake.myftp.org/forum/ServoTest6_UtanI_UtanF.gif
Nu ska vi se hur f-kompenseringen samarbetar med I.
En PID-kontroller med f-komp.
Det var inte så bra, jag har försökt justera PID-parametrarna men det går inte.
http://ake.myftp.org/forum/ServoTest6_MedI_MedF25.gif
Och till sist hur det ser se ut om I får jobba ostört.
Det ser bättre ut iaf, parametrarna var kanske inte perfekt inställda.
http://ake.myftp.org/forum/ServoTest6_MedI_UtanF.gif
Slutsatsen är att friktions-kompenseringen fungerar i princip perfekt ensam med P och D och hanterar friktion bättre än den Integrator jag hittils har använt.
Det var lite tråkigt att det inte fungerade ihop med I men det gör kanske inget.
Jag kan förklara hur f-kompen fungerar senare när jag vet om den är användbar eller ej.
Jag har inte studerat hur hexapod-beräkningarna ser ut men det borde vara tungt som fan.
Jag tycker inte att synkningen av axlarna borde vara svårare än alla andra delar av ett sånt projekt.
En maskin på jobbet hade c:a 0.003 sek fel mellan 2 axlar och det är på tok för mycket i vissa fall.
Och nu till mina tester...
Pid-parametrarna i testerna nedan är
P=3.125
I=0.125
D=25
I det här exemplet har jag gjort en konstant friktions-kompensering(kompnivå=25) som motvarar den lägsta friktionen som konstruktionen har, i mitt fall motorns egen friktion.
Jag har tagit bort Integratorn så det är en PD-kontroller.
http://ake.myftp.org/forum/ServoTest6_UtanI_MedF25.gif
Liknande test men med en f-komp på 60 och motorn är bromsad för hand med tyg mellan fingrarna och motoraxeln för att få konstant friktion.
Vi ser att även det fungerar bra
http://ake.myftp.org/forum/ServoTest6X_ ... _Kraft.gif
Här kan ni se hur det blir utan friktions-kompensering, obelastad motor.
Med endast P och D får man stationära Error.
Det fåniga är att den stannar exakt på 0 när motorn ska stå stilla vilket den inte gör med f-komp, egentligen är det orimligt att den stannar exakt på 0 utan I.
http://ake.myftp.org/forum/ServoTest6_UtanI_UtanF.gif
Nu ska vi se hur f-kompenseringen samarbetar med I.
En PID-kontroller med f-komp.
Det var inte så bra, jag har försökt justera PID-parametrarna men det går inte.
http://ake.myftp.org/forum/ServoTest6_MedI_MedF25.gif
Och till sist hur det ser se ut om I får jobba ostört.
Det ser bättre ut iaf, parametrarna var kanske inte perfekt inställda.
http://ake.myftp.org/forum/ServoTest6_MedI_UtanF.gif
Slutsatsen är att friktions-kompenseringen fungerar i princip perfekt ensam med P och D och hanterar friktion bättre än den Integrator jag hittils har använt.
Det var lite tråkigt att det inte fungerade ihop med I men det gör kanske inget.
Jag kan förklara hur f-kompen fungerar senare när jag vet om den är användbar eller ej.
Helt rätt, en roterar ju i samma axel som spindeln och är totalt meningslös hehe.. Däremot behövs ju 6 aktuatorer för att maskinen ska funka! Jag har kodat lite tidigare och det är inte så avancerat, bara lite "inverse kinematics"!
Du gör helt enkelt så att du har en virtuell punkt vid verktygsspetsen... Du bestämmer vart punkten ska vara XYZ och vinklarna AB.
Sedan tar du och använder matriser för att konvertera alla koordinater av plattformens fästen. Sen behöver du bara räkna ut avståndet från Plattformsfäste 1 till Ramfäste 1, osv för alla 6 aktuatorer. Och förståss uppdatera alla aktuatorer till den nya längden. Sen upprepa...
Det jag gruvar mig lite för är kalibreringen. Jag är osäker på om man tvingas använda "forward kinematics" där
Dock har jag källkoden för ett hexapod styrprogram i java nånstans så det ska gå lösa!
Du gör helt enkelt så att du har en virtuell punkt vid verktygsspetsen... Du bestämmer vart punkten ska vara XYZ och vinklarna AB.
Sedan tar du och använder matriser för att konvertera alla koordinater av plattformens fästen. Sen behöver du bara räkna ut avståndet från Plattformsfäste 1 till Ramfäste 1, osv för alla 6 aktuatorer. Och förståss uppdatera alla aktuatorer till den nya längden. Sen upprepa...
Det jag gruvar mig lite för är kalibreringen. Jag är osäker på om man tvingas använda "forward kinematics" där
Dock har jag källkoden för ett hexapod styrprogram i java nånstans så det ska gå lösa!
Nu har jag jobbat med en lite mer verklighetsbaserad integrator, jag förstår er om ni bara suckar och inte orkar läsa.
Integratorn ska motsvara den externa kraften som påverkar motorn men istället för att basera den på hur mycket fel motorn står så har jag valt att basera den på skillnaden mellan bör-acceleration(BörAcc) och verklig acceleration(ÄrAcc).
Den metoden är teoretiskt så nära verkligheten att man kan få fram den korrekta kraften direkt varje pid-loop (fungerar dock bara i teorin).
Det jag ser som ett problem med en integrator som baseras på positions-felet är att för att ha så hög I som behövs för snabba kompenseringar måste även D och kanske även P ökas för att kontrollern ska bli stabil och med så hög D får man mycket brus som gör att motorn inte går bra.
En integrator som baseras på acceleration påverkar inte P och D så dessa kan kallibreras till låga värden sammtidigt som I får påverka kontrollern mycket.
För att få fram BörAcc räknar jag ut medelvärdet av dom senaste 8 PD-summorna, Jag använder medelvärde för att basera skillnaden mellan BörAcc och ÄrAcc på en längre tid än en pid-loop.
För att kunna göra beräkningar med accelerationen måste jag ha hastigheten med väldigt hög upplösning.
Jag gjorde så att jag kollar encodern 64gr varje pid-loop och räknar ut medel-positionen(på så vis får jag en position med decimaler till priset att positionen är en halv pid-loop gammal) och räknar ut differansen mellan varje pid-loop.
Det är hastigheten och för att räkna ut accelerationen så räknar jag ut hur mycket värdet förändras mellan varje pid-loop.
Då har jag accelerationen men det värdet har ganska låg upplösning och mycket brus så jag räknar ut medelvärdet av accelerationen från dom senaste 8 pid-looparna(samma som BörAcc), att accelerationen blir några pid-loopar gammal gör inte så mycket.
För att accelerationsvärdet ska matcha BörAcc så multiplicerar jag det med lämpligt värde.
Sen Räknar jag ut skillnaden mellan BörAcc och ÄrAcc, jag kallar den ErrAcc.
Första testet är en PD kontroller med friktions-komp, ingen integrator alls.
Lila färg är BörAcc.
Grön färg är ÄrAcc.
Blå färg är ErrAcc, den ska jag basera integratorn på.
Motorn är obelastad och det ser ganska bra ut, i teorin ska blå vara 0 hela tiden.
http://ake.myftp.org/forum/ServoTest7_U ... VisarR.gif
Nästa test är samma som innan men med bromsad motor.
Vi ser att det hela inte är så teoretiskt korrekt som man vill att det ska vara.
http://ake.myftp.org/forum/ServoTest7_U ... _Kraft.gif
Jag testade att använda ErrAcc för att sätta I direkt vilket ska vara teoretiskt möjligt men det blev inte alls bra, har ingen bild på det.
Så jag provade att göra en vanlig integrator men baserad på ErrAcc, typ såhär: I=I+ErrAcc*0.05
Det fungerar iaf men det är knappast någon förbättring jämfört med en integrator baserad på felet.
Det stämde dock att I inte påverkar PD-kontrollerns egenskaper och kan trimmas oberoende av varandra.
Motorn låter ganska bra och ser ut att gå ganska bra men det hela självsvänger mer ju snabbare man låter I förändras av ErrAcc, det är inte tillräckligt bra för att jag ska vara nöjd + att hela metoden är väldigt jobbig att implementera och trimma så även om det skulle vara lite bättre är det ändå inte värt det.
En orsak till självsvängningen är nog att värdet från accelerationen är några pid-loopar gammal och att ErrAcc inte har ett tillräckligt teoretiskt korrekt värde.
PD-kontroller + integrator som baseras på ErrAcc + friktions-komp.
Så här ser det ut med obelastad motor.
Blå är integrator-värdet.
http://ake.myftp.org/forum/ServoTest7_M ... I_MedF.gif
Och med belastning.
http://ake.myftp.org/forum/ServoTest7_M ... _Kraft.gif
Motorn försöker stå still och jag bråkar med den.
http://ake.myftp.org/forum/ServoTest7_M ... Kraft2.gif
Det är för tidigt för att komma med en slutsats om den här metoden, man kan säkert förändra sättet som ErrAcc påverkar I och få det hela att fungera bättre.
Jag har iaf provat och är nöjd för stunden, nu ska jag istället prova att förbättra en vanlig pid-kontroller med diverse filter på väl valda ställen.
Fortsättning följer men ni kan naturligtvis ställa frågor, kommentera eller ifrågasätta.
Integratorn ska motsvara den externa kraften som påverkar motorn men istället för att basera den på hur mycket fel motorn står så har jag valt att basera den på skillnaden mellan bör-acceleration(BörAcc) och verklig acceleration(ÄrAcc).
Den metoden är teoretiskt så nära verkligheten att man kan få fram den korrekta kraften direkt varje pid-loop (fungerar dock bara i teorin).
Det jag ser som ett problem med en integrator som baseras på positions-felet är att för att ha så hög I som behövs för snabba kompenseringar måste även D och kanske även P ökas för att kontrollern ska bli stabil och med så hög D får man mycket brus som gör att motorn inte går bra.
En integrator som baseras på acceleration påverkar inte P och D så dessa kan kallibreras till låga värden sammtidigt som I får påverka kontrollern mycket.
För att få fram BörAcc räknar jag ut medelvärdet av dom senaste 8 PD-summorna, Jag använder medelvärde för att basera skillnaden mellan BörAcc och ÄrAcc på en längre tid än en pid-loop.
För att kunna göra beräkningar med accelerationen måste jag ha hastigheten med väldigt hög upplösning.
Jag gjorde så att jag kollar encodern 64gr varje pid-loop och räknar ut medel-positionen(på så vis får jag en position med decimaler till priset att positionen är en halv pid-loop gammal) och räknar ut differansen mellan varje pid-loop.
Det är hastigheten och för att räkna ut accelerationen så räknar jag ut hur mycket värdet förändras mellan varje pid-loop.
Då har jag accelerationen men det värdet har ganska låg upplösning och mycket brus så jag räknar ut medelvärdet av accelerationen från dom senaste 8 pid-looparna(samma som BörAcc), att accelerationen blir några pid-loopar gammal gör inte så mycket.
För att accelerationsvärdet ska matcha BörAcc så multiplicerar jag det med lämpligt värde.
Sen Räknar jag ut skillnaden mellan BörAcc och ÄrAcc, jag kallar den ErrAcc.
Första testet är en PD kontroller med friktions-komp, ingen integrator alls.
Lila färg är BörAcc.
Grön färg är ÄrAcc.
Blå färg är ErrAcc, den ska jag basera integratorn på.
Motorn är obelastad och det ser ganska bra ut, i teorin ska blå vara 0 hela tiden.
http://ake.myftp.org/forum/ServoTest7_U ... VisarR.gif
Nästa test är samma som innan men med bromsad motor.
Vi ser att det hela inte är så teoretiskt korrekt som man vill att det ska vara.
http://ake.myftp.org/forum/ServoTest7_U ... _Kraft.gif
Jag testade att använda ErrAcc för att sätta I direkt vilket ska vara teoretiskt möjligt men det blev inte alls bra, har ingen bild på det.
Så jag provade att göra en vanlig integrator men baserad på ErrAcc, typ såhär: I=I+ErrAcc*0.05
Det fungerar iaf men det är knappast någon förbättring jämfört med en integrator baserad på felet.
Det stämde dock att I inte påverkar PD-kontrollerns egenskaper och kan trimmas oberoende av varandra.
Motorn låter ganska bra och ser ut att gå ganska bra men det hela självsvänger mer ju snabbare man låter I förändras av ErrAcc, det är inte tillräckligt bra för att jag ska vara nöjd + att hela metoden är väldigt jobbig att implementera och trimma så även om det skulle vara lite bättre är det ändå inte värt det.
En orsak till självsvängningen är nog att värdet från accelerationen är några pid-loopar gammal och att ErrAcc inte har ett tillräckligt teoretiskt korrekt värde.
PD-kontroller + integrator som baseras på ErrAcc + friktions-komp.
Så här ser det ut med obelastad motor.
Blå är integrator-värdet.
http://ake.myftp.org/forum/ServoTest7_M ... I_MedF.gif
Och med belastning.
http://ake.myftp.org/forum/ServoTest7_M ... _Kraft.gif
Motorn försöker stå still och jag bråkar med den.
http://ake.myftp.org/forum/ServoTest7_M ... Kraft2.gif
Det är för tidigt för att komma med en slutsats om den här metoden, man kan säkert förändra sättet som ErrAcc påverkar I och få det hela att fungera bättre.
Jag har iaf provat och är nöjd för stunden, nu ska jag istället prova att förbättra en vanlig pid-kontroller med diverse filter på väl valda ställen.
Fortsättning följer men ni kan naturligtvis ställa frågor, kommentera eller ifrågasätta.
