DC servomotor bij zeer laag toerental

Vertraging erachter zetten.

bedoel je dan het heel traag draaien of het heel accuraat draaien.

maan normaal zit er op een servomotor een snelheidsregelaar die de motor stuurt

indien de motor weinig moet bewegen => weinig kracht of snelheid
bij groote gewenste beweging gaat hij de motor snel laten draaien.

ik hoop dat dit een iets of wat helpend antwoord is, maar ik snap niet helemaal wat juist achter vraagt

Hallo
ik heb niet alles verteld. De bedoeling is om dat motortje ook bij zeer hoog toerental te laten draaien. Max is dat meestal 6000t/min.
Het laagste bij 6t/min, dus een verhouding van 1/1000 liefst iets meer nog. Nu gebruik ik steppers: ideaal voor lage maar voor hoog toerental niet goed geschikt. Kom slechts aan een verhouding van 1/350. 't Is voor een telescoop.

het motortje dat ik nu heb heeft een schijfje voor 180 counts/t. Dat wordt x4 met een HCTL2030. Op het eerste zicht werkt mijn schakeling goed want bij een variabele belasting verandert het toerental praktisch niets, maar bij het meten op een scoop varieert de breedte van het quadratuursignaal wel 50%: dus de langetermijn stabiliteit(over bv 1 sec gezien) is goed, maar de kortetermijn stabiliteit is slecht (70Hz). Het is dus een zware eis die ik stel, maar het moet mogelijk zijn, want ik heb het gezien zelfs bij heel goedkope toestelletjes.

[Bericht gewijzigd door Henry S. op zondag 8 augustus 2010 19:07:14 (43%)]

Twee motortjes in serie zetten: Één voor laag toerental en één voor het snelle werk. Een van de twee moet dan een doorlopende as hebben. je kunt dan voor het lage toerental een stappem motor nemen vertragingskast er tussen zetten, want 0,1 omw./s is wel héél langzaam.... Kan je ook een goedkoop motortje nemen.

Verder moet de niet aangestuurde motor dan van het circuit losgeschakeld worden om te zorgen dat je dat niet opblaast door de dynamowerking.

Als ik hier een servomotor neem kan ik die rustig 1 omw/uur laten maken, stabiel en zonder trillerij. En van daaruit laat ik 'm ook binnen 0,2s op de 6000 toeren draaien. Dan bind ik ze wel aan de werktafel met een spanband, anders word ie gelanceerd.
Die 6 toeren/minuut en 6000 toeren/minuut zijn voor een moderne servomotor/drive combinatie geen enkel probleem, maar zal voor de hobbiebob echt voor de nodige hoofdbrekens zorgen.

Als je geen geld wilt uitgeven is Tidak's idee nog niet zo verkeerd. Die stappenmotor voor het kruipwerk en die DC motor voor het snelle werk.
Wel even kijken of die stappenmotor qua lagering wel tegen die hogere toerentallen kan.

Dat het je zelf niet lukt met een DC motortje en een regelaar, verbaast me eerlijk gezegd niets. De regellussen in een servoregelaar zijn niet bepaald eenvoudig. Ten eerste moet je een goed model van de motor hebben (weerstand, inductie, tegen-EMK, koppelconstante, I^2t constante, nominale en maximale stromen, massatraagheidsmoment), met een zeer snelle en goed afgeregelde lus om de motorstroom te regelen. Dit is ook meteen de koppel regeling. Vervolgens heb je een snelheidsregeling, die een koppelvraag oplevert afhankelijk van de huidige positie, gewenste positie, en huidige snelheid. Daar voor zit weer een positieregeling, die, afhankelijk van de gevraagde snelheid, positie setpoints genereert.

Misschien kun je hier wat mee.
http://elm-chan.org/works/smc/report_e.html

Bedankt voor de link Jouke en ook de anderen. Het is bijna analoog met hetgeen ik gebruik al voorbeeld nl: MCS AN#150
De "position capture" wordt gedaan met een HCTL2030, de rest(speedcontrol, Pid regelaar) in een ATmega16. De H-bridge is L6203. De motor positie wordt vergeleken met een nieuwe positie; dit resulteert dan in een error die dan via de pid routine en de gepaste waarde van PWM(8bits) de motor in de verwachte positie duwt. 1 Pid routine(90µS) en 1 positiebepaling(30µS) duurt in totaal dus 120µS. Voor de besturing van de telescoop heb ik 2 modes nodig:
1)Position mode(trapezoïdal): dit lukt al redelijk goed
2)Constant velocity mode: helemaal niet
Het probleem is dat ik niet goed weet wat er in de Pid regelaar gebeurt. Welke parameters voor P I en D ik ook gebruik, het draait niet vlot. Het is alsof de PWM tussen 0 en 255 geslingerd wordt.
Ik ga de code eens wat opkuisen en voorzien van wat commentaar. Zal ook eens een filmpje maken van hetgeen ik al heb, en laat het dan zien.
Voor Tidak Sparky GJ en Jokohoho: aan 2 motoren had ik ook al gedacht want een stepper is toch ongeslagen kampioen voor "kruipwerk"(goed gevonden voor "sideral speed" in 't schoon nederlands). Trouwens ik heb de reductie(x3000) nog niet klaar gemaakt omdat ik nog niet weet of het zal lukken met een servo-DC-motor. In elk geval 2 motoren is niet bevorderlijk voor speling, backlash enz.
Misschien moet ik een vliegwieltje en aparte encoder (om te meten) zetten op het motortje zodat het wat gelijkmatiger draait.

Ok, het klinkt alsof je een heel eind op weg bent, maar wat problemen hebt met het instellen van de PID regelaar.

Ik neem aan de je de code van de PID regelaar al wel geverifieerd hebt? Zo'n stukje code test ik meestal in een console application op de PC, zodat je het gedrag gemakkelijk kunt controleren, en daarna kun je de werking in de controller controleren door data door de UART of met een JTAG controller zichtbaar te maken.

Het instellen van PID regelaars is een beetje zwarte magie, en er is erg veel over geschreven.

Wat gebeurd er als je alleen de P-gain invult, en de I en D gain op 0 zet? Het ding zou dan langzaam op gang moeten komen, en een flinke volgafwijking moeten krijgen, maar hij zou niet mogen oscilleren. Klopt dat?

Daarna is het zaak de I en D gains rustig te verhogen; ik kan hier niet uit gaan leggen hoe dat precies werkt, maar in kleine stapjes en steeds kijken wat het gedrag is, is toch de beste methode.

Ik neem aan dat je de telescoop een object wil laten volgen, om te compenseren voor de rotatie van de aarde en zo?

EDIT: ik lees nu die link pas; ik dacht dat je het zelf geschreven had. De auteur heeft geen handleiding voor het instellen?

Hallo Sparky
Ik ben er inderdaad al enkele maanden mee bezig maar de laatste tijd is er geen vooruitgang meer. Ik heb MCS AP#150 volledig nagevolgd en alleen dat deel eruitgehaald dat voor mij van toepassing is. Van elektronica en programmeren ken ik jammer genoeg niet zo veel.
zeihier een gedeelte van het programma:

Do
   nop
 Loop

 End

'-------------------------------------------------------------------------------

Timer_0:            'timer0 prescale : 256  ===> 3556 µS

   Test_punt = True

For J = 0 To 25     'duurt 119 µsec x 25 = 3000
   Call Hctl_2032   '32 µsec
   Act_speed = Pos_encoder - Old_encoder
   Old_encoder = Pos_encoder
   New_speed = Pos_finale - Pos_encoder
   'Act_speed = Pos_encoder
   Call Exe_pid(new_speed , Act_speed)       '87 µsec
Next J

   Pos_finale = Pos_finale + Speed
   Test_punt = False

   Return

'-------------------------------------------------------------------------------

Sub Exe_pid(setpoint , Actual )

   Error = Setpoint - Actual
   Pid_out = Error * Kp

   Temp = Error - Prev_error
   Prev_error = Error

   Temp = Temp * Kd
   Pid_out = Pid_out + Temp
   Temp = Integral_error * Ki
   Pid_out = Pid_out + Temp
   Pid_out = Pid_out / Scale

   If Pid_out > 255 Then
       Pid_out = 255

   Elseif Pid_out < -255 Then
       Pid_out = -255

   Else
       Error = Error + Integral_error

       If Error > 255 Then
          Error = 255
       Elseif Error < -255 Then
              Error = -255
       End If

       Integral_error = Error
   End If

       If Pid_out => 0 Then Motor_dir = 0
       If Pid_out < 0 Then Motor_dir = 1
       Pid_out = Abs(pid_out)
       If Pid_out => Max_pwm Then Pid_out = Max_pwm

       Motor_pwm = Pid_out

End Sub

'-------------------------------------------------------------------------------

Rs232:

      Char(1) = Inkey()
      Char(1) = Ucase(char(1))
      If Char(1) = Chr(13) Then       '13=carriage return
         Print      'line feed
         If Commando = "" Then Commando = Commando_old
         N_cmd = Split(commando , Cmd_ar(1) , " ")

         Select Case Cmd_ar(1)

                Case "RESET"
                     Print "(RESET)"
                     Start Watchdog

                Case "SKP"
                     Kp = Val(cmd_ar(2))
                     Print "( SKP, " ; Kp ; ")"

                Case "SKI"
                     Ki = Val(cmd_ar(2))
                     Print "( SKI, " ; Ki ; ")"

                Case "SKD"
                    Kd = Val(cmd_ar(2))
                     Print "( SKD, " ; Kd ; ")"

                Case "SPID"
                     Kp = Val(cmd_ar(2))
                     Ki = Val(cmd_ar(3))
                     Kd = Val(cmd_ar(4))
                     Print "( SPID, " ; Kp ; " " ; Ki ; " " ; Kd ; ")"

                Case "GPID"
                     Print "( GPID, " ; Kp ; " " ; Ki ; " " ; Kd ; ")"

                Case "SPD"
                     Speed = Val(cmd_ar(2))

                Case Else
                     Print "(NOT VALID)"

         End Select
         Commando_old = Commando
         Commando = ""
      Else
          Commando = Commando + Chr(char(1))
          Print Commando ; Chr(13);
      End If

Return

'----------------------- uitlezing HCTL 2032 : -----------------

Sub Hctl_2032       ' duurt 32µS

De interrupt routine Timer_0 is niet goed; ik dacht: de timer duurt 3556µs dus daar past een lus in van 25 keren 120µs, dan zal de encoder wel op de juiste plaats staan, maar dat is wat te amateuristisch gedacht? Maar het werkt blijkbaar. Als ik de lus 1x of 25x laat doorlopen, dan is er geen verschil, zodus niet goed zeker? De P, I en D kan ik tijdens de werking(UART) veranderen, alsook nog andere varabelen zoals Speed(kan ook negatief zijn om de draairichting te veranderen). Om te debuggen programmer ik de AT telkens weer opnieuw tot het lukt...(geen JTAG, jammer genoeg weet ik niet hoe die te gebruiken)
Als ik P op 0 zet, dan staat de motor stil, geen oscillatie. Er is een "scale" van 100. Als ik P>500 zet dan werkt het niet goed. Ik heb echt geen inzicht in die Pid routine. Hopelijk komt dat nog...
Ik heb al eens die Pid routine aparte code gemaakt om te simuleren, waar ik verschillende waarden kan ingeven, maar krijg er geen zicht op, want na 1 pid routine verandert al weer de beginsituatie. Er is wel veel te vinden over hoe de regelijg moet geschieden: Matlab en Pidlab enz. maar dat is te moeilijk. Interessant vind ik
dithier
waar een array(20) wordt opgevuld met de Pid-waarde, om dan achteraf uit te lezen. Dat zou ik eens moeten doen.
Nog bijgevoegd enkele filmpjes(hopelijk lukt dit, want dit heb ik nog nooit gedaan)
motor
time
scope
print

Zo op het eerste gezicht lijkt de code op een PID regelaar

Maar ik zie geen variabele declaraties... Welk type hebben de variabelen?? Het lijkt erop dat je geen floating point hebt gebruikt Dat hoeft ook niet.... Maar bij integer berekening kan gemakkelijk gebeuren dat overflows of afrondingsfouten roet in het eten gooit.

Zoals hier al eerder is vermeld: Bij inregelen eerst beginnen met D en I op nul. Dan de P gelijdelijk vergroten vanaf nul. De fout moet daarbij steeds kleiner worden. Bij een te grote P gaat de boel oscilleren. Dan P iets terugnemen en I geleidelijk verhogen. De fout moet daarbij naar 0 lopen. De D-actie is alleen voor snelle veranderingen (van setpoint of feedback). Dus met de D kun je de reactie snelheid beter maken. Bij een te grote D waarde wordt de regeling zenuwachtig.

FullPower.

Ik heb die PID loop vluchtig gelezen, niet tot in het kleinste detail geanalyseerd, maar die lijkt op het eerste gezicht wel te kloppen.

De regeling is in ieder geval op basis van snelheid, niet van positie tracking.

Ik denk dat ik wel weet waar het fout gaat; je probeert een snelheid te berekenen door te bekijken hoeveel pulsen je hebt gekregen binnen een bepaalde tijd, maar op deze manier is de tijd niet meer eenduidig bepaald, en waarschijnlijk veel te kort.

De tijd voor die PID loop is om te beginnen niet constant, vanwege de branch instructies (oftewel, IF statements e.d.).

Maar dat is niet het fundamentele probleem; het probleem is (denk ik) dat je veel te weinig pulsen krijgt tussen de iteraties van de loop.

Je hebt het over een schijfje waarmee je 2x 180 pulsen per omwenteling krijgt, dus 720 flanken per omwenteling. Je wilt 6 omw/minuut kunnen draaien, dus dat is 720 * 6 / 60 = 72 flanken per seconde. Aangezien je maar een heel aantal (integer) pulsen kunt tellen tussen 2 iteraties, zul je er waarschijnlijk het grootste deel van de tijd geen tellen, en af en toe 1.

Om te beginnen zou je de PID berekening maar 1 keer per timer interrupt moeten uitvoeren, zodat de interval altijd bekend is. Dan zit je nog steeds met het probleem dat de pulsfrequentie lager is dan de frequentie waarmee je die loop uitvoert. Je zou de loop trager kunnen laten lopen, maar daar wordt het gedrag op hogere snelheid weer niet beter van.

Bij een dergelijke lage snelheid is het niet handig om te tellen hoeveel pulsen je in een bepaalde tijd krijgt, omdat je op die manier erg lang moet wachten tot je genoeg pulsen hebt om de afrondingsfout klein te maken. Het is dan handiger om de interval (dus de tijd tussen 2 pulsen) te bepalen. Dat zou je kunnen doen door de encoder ook aan een input capture ingang van de controller te hangen, als je die hebt.

Als je het zonder hardware wijzigingen wilt doen, zit er weinig anders op dan het aantal pulsen over een langere tijd te totaliseren, en dan kom je al snel op een IIR of FIR filter uit.

Hoeveel RAM heb je nog beschikbaar? Voor een FIR filter heb je al snel best veel RAM nodig.

Zat ik nu goed met de toepassing, waarbij je de telescoop een object wilt laten volgen? Dit is van invloed op de keuzes in de software; is het belangrijk dat je zo goed mogelijk een bepaalde positie kan volgen, of is het belangrijk dat je een constante snelheid hebt, waarbij een cumulatieve positiefout niet zo veel uit maakt?

Je moet eens goed kijken naar je hardware. Volgens mij wil je een telescoop op bepaalde plekken kunnen richten (snel bewegen), maar ook de beweging van de aarde compenseren voor lange opnames (langzaam bewegen).

Dan begint de vraag: Hoe zit het met de kijk-hoek van je telescoop en het aantal pulsjes van de encoder. Als je beeldhoek dus 2 graden is, en je hebt daar 4000 pixels, moet je stapjes van rond de 2/4000 graden kunnen doen met je telescoop. Met hoeveel graden komt een pulsje van de encoder overeen?

Volgens mij moet je een PID regeling maken op de positie. De I term zorgt er voor dat ie uiteindelijk precies op de bestemming aankomt, de P term dat je netjes harder gaat als het verschil groter is, en de D term zorgt er voor dat je goed gas geeft als er grote verschillen zijn.

Je loop loopt 25x in de timer0 interrupt. Die wordt dus 25x snel achter mekaar aangeroepen, en dan weer een hele tijd niet. Dat heeft geen zin.

Als je hem regelmatig en vaker wilt aanroepen, moet je naar de timer0 instellingen kijken....

hallo
Bedankt voor de reply's.

Welk type hebben de variabelen??

De variabelen zijn Long(32bits gehele getallen) Daarom waarschijnlijk die Scale = 100.

De regeling is in ieder geval op basis van snelheid, niet van positie tracking.

Het is inderdaad geregeld op snelheid, maar moet dat zo zijn? De tijdspanne van meting is inderdaad te kort en zou een interval meting uiteraard veel juister zijn maar ook langer duren. Een input capture is er nog wel denk ik. Maar zou het niet mogelijk zijn het te beschouwen als posionering: om een welbepaalde tijdspanne een(of meer) pulsjes erbij of eraf bij de vorige positie. Dus Act_speed zou moeten zijn: Act_position. Die Timer_0 is niet goed. Als ik nu ForJ=0 to 1 of to 25 zet is juist hetzelfde.
Hoe kan de Exe_pid de Error op 0 krijgen? Dat kan toch niet in 1 keer. Hoe moet het dan? Maar als de positie 1 puls ernaast zit zal de Exe_pid aanstonds reageren met de maximale Pwm waarde. De postitie kan er zo niet een beetje ernaast zitten. Ik weet het niet meer...

Zat ik nu goed met de toepassing, waarbij je de telescoop een object wilt laten volgen?

Inderdaad dat is het hoofddoel: hiervoor is een zeer trage en uiterst gelijkmatige snelheid nodig dus absoluut zonder trilingen.
Die hoeksnelheid is 360° in 24 u.
Tweede doel is "Go-To": na een referentie neming, de telescoop sturen naar een bepaald punt(met 2 coördiaten vogens een soort Cartesisch assenstelsel. Hiervoor zijn dus nodig: 2 servomotoren met hun encoders(bv 500x4 pulsen) en 2 grotere encoders(5000X4) op de assen van de telescoop

Als je een positie wilt volgen, lijkt het me toch beter om een positieregeling te gebruiken, in plaats van alleen een snelheidsregeling.

Maar, zoals ik al zei, is naar mijn idee het fundamentele probleem dat je encoder een veel te lage resolutie heeft om bij zo'n lage snelheid nog een stabiel regelsysteem te kunnen hebben.

Zo'n PID regelaar kan natuurlijk niet in 1 keer de fout terug naar 0 regelen, maar daarom voer je deze gewoonlijk ook met een vaste interval, een flink aantal (denk aan 100-1000 keer) per seconde uit. In principe zal de fout zelfs niet voor lange tijd 0 zijn, aangezien het ding een fout nodig heeft om te kunnen regelen. Hij zal wel altijd proberen de fout 0 te maken. De truc is dus dat de meetresolutie zodanig hoog is, dat een kleine fout toelaatbaar is.

Ik denk dus dat je een paar mogelijkheden hebt; een andere encoder met een veel hogere resolutie gebruiken, of een andere manier van terugkoppeling, zoals een resolver. Die laatste optie is alles behalve eenvoudig, dus dat zou ik niet aanraden.

Misschien is de beste optie nog wel om een vertraging te gebruiken, omdat je op die manier ook indirect de resolutie verhoogt. Dit gaat natuurlijk wel ten koste van de maximale snelheid, en je zult een systeem moet gebruiken met heel weinig speling (backlash). Een tandriem die je goed op spanning zet, zou wel een bruikbare oplossing kunnen zijn. Een verhouding van 5:1 of zo moet goed haalbaar zijn.

Je kunt ook twee tanwdwielen stapelen en die met een veer een offset geven. Dat wordt vaak gedaan bij afstemmingen en prcisie overbrengingen. ost wel extraa w rijving, naar dat heb je mer een tandsnaar ook en die rekt en slijt sneller.

Mijn voorstel is dus dat je als je langzaam moet bewegen in software iets doet van:

gewenste_positie += speed * dt; 

met speed de snelheid, en dt de tijd die verstreken is. Die tijd kan iets van 0.01 seconde zijn of zo.

Als je ergens heenmoet, doe je:

gewenste_positie = refpos; 

De PID regeling doet de rest.

Je moet wel voor "langzaam bewegen" de positie nauwkeuriger bijhouden dan 1 stapje van je encoder. Het kan zijn dat je pas na ieder 10 tijdstappen een stapje van je encoder ziet.

Als je dit wilt doen, dan moet het wel zo zijn dat de encoder op je motor een grotere resolutie heeft als de camera die aan je telescoop hangt.

Dus: hoeveel is je FOV van je telescoop? Hoeveel pixels heb je? Hoe groot is de vertraging van je motor naar de telescoop?

Hallo
past dus beter thuis in robotica.

De truc is dus dat de meetresolutie zodanig hoog is, dat een kleine fout toelaatbaar is.

Die kleine fout kan en mag 2 counts zijn denk ikbv. op...8630: fout= -1 : iets vooruit; op...8631: fout= 0 : OK ! ; op...8632: fout= +1 : iets achteruit. Dus de fout kan dus tss -1 en +1 zijn. Als ge iets moet meten met een lat waarvan de kleinste indeling 1 cm is is de mogelijke fout dan ook niet 2 cm?

een andere encoder met een veel hogere resolutie

De hoogste resolutie op de markt is (500x4) denk ik: zie Maxon motortjes.

Misschien is de beste optie nog wel om een vertraging

Ik denk het niet als ik die verhouding 1:1000 wil behouden. Het max toerental ligt nooit veel hoger dan 6000, zelfs bij 24v. Met een reductie 1:2 zou dan slechts 1:500 haalbaar zijn.

twee tanwdwielen stapelen

zou kunnen misschien.

gewenste_positie += speed * dt;

dt is constant hier. Speed*dt zou minimaal 1 moeten kunnen zijn.

Pid doet de rest

ja, maar hoe toepassen in die Timer_0 routine? moet dat 1x of 20x, of steeds herhalen tot de tijdspanne voorbij is.

..pas na ieder 10 tijdstappen een stapje van je encoder ziet.

Wat meer uitleg: de diameter van de spiegel is 200mm. Het theoretisch scheidend vermogen is dan 0.6bg". Dus detailtjes die dichter zijn dan die hoek, zijn niet meer te onderscheiden. Men neemt aan dat de discrete stapjes waarmee de as van de telescoop draait <= moet zijn dan die 0.6bg" anders zouden die stepjes gezien kunnen worden(in de praktijk zal dat natuurlijk nog lang niet het geval zijn.)
De totale reductie zal 1:3200 zijn (een combinatie van frictiereductie en een Harmonic drive). Dus de maximale stap van de motoras is 0.6*3200=1920bg".
De as van de telescoop draait 1 t in 24u: dat is 15bg"/sec.Dus de motor draait dan aan 15*3200=48000bg"/sec=13.333°/sec.==> 360°/13.3=27sec voor 1 toer(is nog trager dan ik dacht).
Gezien de stapjes slechts 1920bg" mogen zijn is de laagste frekwentie van die stapjes: 13.3*60*60/1920=25Hz.
't Is nog niet gedaan: gezien de servomotor een encoder heeft van 2000 pulsen(voor 360°) moeten er voor 13.3°: 13.3*2000/360=73.888 pulsen per sec passeren, dus 73.888Hz. Dus zou nog goed zijn voor een spegel met 3x hogere resolutie.
FOV hangt af van het gebruikte oculair(visuele waarneming); camera komt later.
Misschien was dat niet de meest logische of klare uitleg.
Voor rew: De encoder op de as van de telescoop kan niet dienen voor de snelheids regeling. De resolutie ervan zou 2000*3200 moeten zijn of zoiets. De posionering is slechts op 60bg" en dat zou al zeer goed zijn.

Nee, de bedoeling is om de encoder op de as van de motor te gebruiken.

Volgens mij heb je uitgerekend dat als je op de juiste momenten 1 encoder-stap van de servo doet, dat het wel goed komt.

Je maakt dus een PID regeling op de encoder positie van de motor. Die kan natuurlijk tig keer "klokkie rond", dus de hogere bits zal je zelf moeten bijhouden (een encoder levert trouwens toch maar de laagste 2 bits van een gray code positie!).

De gewenste positie kan je bijhouden door iedere 100e van een seconde de "step" er bij te tellen. Door in de (integer) positie een paar bits als "achter de comma" te beschouwen, kan je prima 73/100 stapjes per seconde doen. Zodra je inderdaad een stapje moet doen wordt de "error" -1 en zal de PID regeling hem bijregelen tot ie weer nul is. Uiteindelijk zou dit heel soepel moeten lopen.

even ter info: encoders met 10000 ppr zijn prima te krijgen, alleen een beetje duur... technisch is het prima mogelijk.

fripster

@REW: nee, toch niet. Het probleem is dat je een PID regelaar krijgt die moet reageren op een signaal dat even groot is als de meetfout (1 puls van de encoder). Het error signaal naar die PID regelaar is dus keihard aan of uit; een afwijking van 0 pulsen, of +1/-1 puls.

Ik denk dat een ander encoder, met een veel hogere resolutie, of een vertraging om indirect hetzelfde te bereiken, de enige echte mogelijkheden zijn.

[Bericht gewijzigd door SparkyGSX op woensdag 11 augustus 2010 09:51:10 (22%)]

Maar, dat heeft ie niet nodig. Hij heeft een encoder van 180 PPR op z'n servo motor zitten, dat door een goede encoder opgeschroeft wordt naar 720 posities per omwenteling. Met vervolgens een 1:3200 vertraging van de motor naar de telescoop. Dat komt neer op meer dan twee miljoen stapjes per omwenteling van de telescoop. En volgens mij is 360*60*60 (boogminuten/omwenteling / 2.3M stapjes/omwenteling = 0.56 boogseconden/stapje. En dat is minder dan de genoemde 0.6 boogseconde theoretisch optische resolutie....

Toch?

Magelan? Heb ik je 0.6bg" goed gelezen als 0.6 boog seconden? Heb je inderdaad een 1:3200 vertraging?

Met 6000 RPM op je motor, kan je telescoop dus ongeveer 2 RPM draaien, dus 15 seconden over een "nieuwe positie". Op zich wel te doen. Niet super snel, maar te doen. Zeker als je toch plaatjes gaat schieten van minuten tot uren....

dat is waar, maar dan hou je geen rekening met het feit dat er enige encoder pulsen 'aan beide zijden' van een positie nodig zijn om het geheel op die positie te houden (een servo pendelt altijd rond zijn positie). Dus je echte bereikbare resolutie wordt een factor 4 a 5 hoger.

just my two censt....

fripster

Precies; de resolutie van de encoder moet veel hoger zijn om een positie goed vast te kunnen houden.

Een PID regelaar heeft een foutmarge nodig om te kunnen werken. Met deze opstelling is de acceptabele foutmarge minder dan 1 puls van de encoder; dat gaat dus niet werken.