ADSN [ 17 : voorlopig schema interface RPI <--> Rotor]

Interface tss H bridge en RPI nog te bepalen.

Het schema met de dual bridge rechtsbovenaan

ADSN [ 15 : testen met twee positiegevers + optische scheiding]

Eerst en vooral een optische scheiding gemaakt met vier fotokoppelaars.

Ene kant 24 V die van de encoders komen van de rotors , de andere kant , keuze 5V of 3V3.


Enkele ledjes aangebracht zo ik in één oogopslag de zaken kan evalueren.

Daarna de soft aangepast , want ik moet nu vier interrupts bewaken .
Omdat ik maar één encoder hier op de tafel heb , heb ik deze ontdubbelt.
Hierdoor komen in principe de beide A of B impulsen wel gelijktijdig binnen in de RPI maar het blijkt te lukken.

De bijbehorende foto's.

De soft is in C geschreven en is gewoon een verdere ontwikkeling van het voorbeeld van de PIGPIO biblio.

De pulsen van beide encoders ( ttz één echte en één dummy) komen mooi synchroon binnen .

ADSN [ 14 : testen met één positiegever]

Ik heb een proefopstelling gemaakt met een rotary encoder .
Hiervoor heb ik gebruik gemaakt van een bibliotheek genoemd  PIGPIO.

zie   pigpio.


Deze biblio kan zowel C  C++ als Phyton aan.

Om deze te gebruiken moet je deze eerst downloaden en compileren , alles staat beschreven op die website.

In hun voorbeelden zat gelukkig ook een rotary-encoder voorbeeld welke is heb gebruikt om te starten . Ik zie nu net ook nog dat er een piscope bestaat om de pinnen te monitoren . Dat zal voor later zijn.


Dit is mijn opstelling en mijn metingen.

Geen puls gemist

Op het ogenblik kom ik aan de eis van 0.9ms tussen de beide impulsflanken , maar dit is maar voor één encoder . Ik moet er twee inlezen , dus weet ik niet of ik het ga halen . Anders moet ik eerst AZ aandrijven en daarna pas de EL zoals het eigenlijk met de huidige controller ook zo is .

Een tweede optie is om de motor trager te laten draaien zodat de pulsen ook trager binnenkomen.Dit zou kunnen met PWM , maar ook hier zijn er waarschijnlijk interrupts voor nodig......

Een derde mogelijkheid is om de motor op nominale snelheid te laten draaien , en als hij er bijna is over te schakelen op PWM.

Nog veel ( denk)werk voor de boeg ...

ADSN [ 13 : metingen op de positiegevers]

In de rotor zitten twee positiegevers. Dit zijn er van het incrementele type , dus de positie is relatief , niet absoluut.
Ze bestaan uit twee impulsen A en B en staan in quadratuur ( 90° verschoven)
Hierdoor kan men de richting bepalen.

Ik heb , terwijl het nog goed weer is en omdat mijn besturing nog niet in de shack staat , er gisteren met de scoop metingen op gedaan. Deze zijn wel belangrijk om zelf deze later binnen te lezen in mijn hardware.

Vier metingen zijn noodzakelijk , slechts twee indien men de andere wilt afleiden .Ik heb er vier gedaan.

1.  Richting Oost met de AZ , geel kanaal is impuls A

2. Richting West met AZ , geel kanaal is impuls A

3. Richting omhoog met EL , geel kanaal is impuls A

4. Richting omlaag met EL , geel kanaal is impuls A

Verdere gegevens :

Impuls is 24 V  , in rust blijkbaar +24Vdc

De pulsbreedte is 1.8 ms , dat wil zeggen dat de flank van  puls B  er reeds zal zijn na 0.9ms . Dit is snel ! Welke hardware/software detectie moeten we hier voor gebruiken ? .....

Samengevat: 

AZ : richting Oost  impuls B , dan impuls A
AZ : richting West impuls A , dan impuls B

EL : richting Omhoog impuls A , dan impuls B 
EL : richting Omlaag impuls B , dan impuls A

ADSN [ 10 : xyz positiegever]

Om zekers te zijn van de positie (AZ en EL) ben ik aan het experimenteren geweest met een , door de QRP voorziene, accelerometer bordje van geeetech.
In feite heeft Sparkfun een identiek in hun gamma en ik heb dan ook daar de library van gebruikt.
Ook Adafruit heeft zoiets met hun eigen lib , maar uiteindelijk komt het allemaal op hetzelfde neer , geef mij een xyz positie.

Het type van sensor is een ADXL435

Sparkfun website:

Sparkfun

Hier een foto van de proefopstelling met een arduino uno

Bij de eerste pogingen met een andere lib was het precies of de Zas was gelockt op een vaste waarde . Bij de lib van sparkfun , was de code duidelijker en toen bleek de Zas toch te werken.

Ik heb toen wat " gespeeld" met de sensor .  Alle assen eerst apart uitgeplot en gekeken hoe ge nu eigenlijk moest draaien , rond welk draaipunt eigenlijk , wat dat was mij nog niet geheel duidelijk.
Het is zo , als je de assen als een vector voorstelt , je de vector moet kantelen om de juiste  werking te krijgen .
iets zoals :

CW kantelen

En dan krijg je dit op de arduinoplotter

Gekanteld  rond Xas in CW richting zoals op bovenstaande foto

Gedraaid in Xas in CCW richting

Dit is voor de Yas hetzelfde , maar voor de Zas krijg je dit :

 Zowel CW als CCW hebben dezelfde uitkomst.

Nu heb ik geprobeerd om een opstelling te maken waaruit ik zou kunnen afleiden hoe mijn  AZ ( bv de Yas ) en mij EL ( dan de Xas of de Zas ) zou zijn maar ik kan geen montage vinden die duidelijk op de plotter mijn positie weergaf.

Ik denk dat ik moet overstappen naar een ander systeem zijnde een goniometer ipv een accelerometer.

Het ander printje is gebasserd op een magn kompasrichting en dit ga ik zeker verder niet exploreren want een magn kompaskoers verandert bijna continue
 ( in terms van weken) en vergt dan ook continue kalibratie !


Voor alle duidelijkheid , dit is het NIET