tanker rundt en open source teleskop kontroller

[hedmarkingen Asteroid]

Hei, jeg har noen tanker rundt en open source teleskop kontroller som kjører på foreksempel beagle board,Raspberry Pi , Aurdino eller lignende system.
Tenk hva en 700MHz ARM -kontroller med flere gigabyte utvidbart lagring kan gjøre!
Kretskortene og programvaren skal plasseres under GNU General Public License , eller noe lignende.
https://en.wikipedia.org/wiki/GNU_General_Public_License

Som åpen kildekode designeren er fri til å gjøre endringer og erstatninger , men en må dele sine forbedringer!
En GIT kan brukes for skjemaer og programvare .
https://no.wikipedia.org/wiki/Git

Jeg foreslår Kicad for kretsdesign,fordi det er gratis og går på mange forskjellige systemer .
http://www.kicad-pcb.org/display/KICAD/KiCad+EDA+Software+Suite
Lenke til Kicad symbol / komponent biblioteker :
http://www.kicadlib.org/
http://open-project.ch/kicadlib/
http://library.oshec.org/

Noen tanker om funksjoner og spesifikasjoner:

strøm:
12V dc fra forseglet motorsykkel batteri eller booster pack. Å bruke ett kjøretøys strømforsyning er etter min mening en risikabel affære.
Å bli sittende langt ute i skogen med et flatt batteri , – og temperaturen er – 25 grader celsius og kryper nedover ….

Hoved -boksen:
IP55 kapsling
Kretskortet kan være et “skjold” eller tillegskort som kobles til Beagle board, Raspberry Pi , Aurdino eller lignende system .
Det må ha kretser for styring av steppermotorer , og H broer for motor polaritet kontroll, og bufferkretser for beskyttelse av prosessorpinnene .
De liker ikke overspenning eller kortslutning, samt ESD.

OS :
OS Debian eller lignende (ethernet -støtte, DHCP , GPS-støtte , FTP, SSH , display drivere osv er allerede til stede som frie moduler/”drivere” til de fleste linux baserte systemer)
-500 Gb RAM eller lignende .

Input kanaler :
– luft temperatursensor
– speil temperatursensor (festes på ett passende sted på hovedspeilet)
– RA posisjonsgiver
– DEC posisjonsgiver
– luft trykksensor/barometer
– luftfuktighet sensor
– posisjonsgiver for fokus av kamera
– mulighet for posisjonsgiver på kamera rotering ( for alt/az monteringer)
– varmebånd temperatur
– ST4 autoguider
– mulighet for posisjonsgivere /kontakter for obervatoriums kuppel åpen/lukket
– på/av med sikker avstenging av systemet, det er ikke bra å røske bort strømmen under ett kjørende system.

Dvs 11 innganger med beskyttelse av kretser.

utganger:
RA motor ( 6x ledninger for unipolar stepper , 5 ampere maks )
Desember motor ( 6x ledninger for unipolar stepper , 5 ampere maks )
– Kamera lukkerkontroll
-mulighet for kamera roterer (PWM signal? )
– mulighet for å kontrollere filterjul ( SBIG , OES , DFM , Truetech ptrotokoller)
– viftestyring
– varmeelementstyring
– Fokus kontroll ( robofocus/LX200 , stepper )
– mulighet for kontroll av tak ( reversibel motor eller stepper ? )
– mulighet for Dome kontroll
– lampe/LED for opplysning med rødt lys

Diverse kontakter:
4x USB-drevet kontakter webcamstøtte, USB-kamera , GPS mus og firmware oppdatering ,mulighet for å koble til mobiltelefon for dataoverføring Når WLAN / LAN er utilgjengelig.
– LAN/WAN Connector med DHCP-støtte (live streaming webcam , automatisk oppdatering av objekt tabeller , etc )
– minnekort grensesnitt (for objekt kataloger / PEC tabell , lagre webcam / kamera bilder/film )
– RS232 -grensesnitt
– kontakt for håndkontroller ( RX / TX ) ( bransjestandard kontakt med nok ledere )

Software funksjoner :
– Motor trinn og giveren teller per omdreining , girutveksling satt i konfigurasjonen for å beregne hastighet/utveksling.
– Støtte for https://github.com/OSCAAR/OSCAAR/wiki
– Fokus kontroll
– RA/DEC Motor kontroll med kodere for manuell “push til “
– Identifisere objekt i okular , okularets synsfelt satt i konfigurasjonfil
– beregning av duggpunkt temperatur
– konfigurasjonsprogram med kryss-plattform programvare
– Pulseguiding
– korrigering for Atmosfærisk brytning
– webkamera med streaming støtte (kan brukes til skoler ? )
– Automatisk eller manuell oppdatering av tabeller fra internett
– Autoguider
– facebook/twitter støtte (post informasjon om hva som er synlige i okulær etc )
– Fjernkontroll fra internett over SSH med brukernavn og passord
– Konfigurerbar homePosition
– Sporing av alle himmellegemer , deriblant sol, måne , etc..
– Board RTC ( sanntid klokke med batteri for lagring av dato og klokkeslett)
– GPS-støtte for LAT / LONG , tid oppdatering / synkronisering fra satellitter
– Satellittsporing med valgfri RX / TX rigg kontroll med Doppler korreksjon (kan brukes for radioamatører ! )
– alt/az modus
– Microstepping
– ubegrenset størrelse på katalog da denne kan lagres på minnekort
– objekt filtrering basert på oppløsning teleskoper og størrelsesbegrensning
– Motor beskyttelse (fastkjørt,overstrøm og kortsluttning?)
– Backlash kompensasjon
– Intelligent hastighetskontroll (Ved flytting fra / til objekter trengs det store bevegelser , starter med sakte fart , går raskere, bremser ned for å unngå mekanisk påkjenning / sjokk.
– PEC tabell med 1000 oppførelser.
– rask gjenkjennelse av himmelske konstellasjoner for auto innretningsprosedyre ( sensitivt webkamera eller lignende )
– mulighet for styring av tak/observasjonsdome ( åpne/lukk/roter)
-30 til +40 grader arbeids temperatur

Håndkontrolleren / display:
– IP55 beskyttelsesklasse
– opplyste knapper med rødt lys (potmeter som styrkekontroll? )
– opplyst LED eller OLED-skjerm av tilstrekkelig størrelse , og støtte for gresk / latin tegn ( Unicode ISO / IEC 10646:2012 pluss seks tegn)
RA + og – knapper
+ Og minus Dec knapper
– Meny-knapp
– Enter-knapp
– Exit -knapp
– Goto- knapp
Dvs totalt 8 knapper .
Håndkontrolleren må kanhende takle åtte kanaler + 5V ledninger for strøm og jord , – + signaler for LCD/skjerm

Dessverre kan jeg ikke å programmere og kan ikke så mye elektronikk.
Så, hva har forummedlemene å si ?

[JuliusDeltager Nova]

Hvorfor finne opp hjulet på nytt? Jeg er i utgangspunktet positiv til open source hardware.
Så bare å sette i gang om du har tid og ressurser.
Men det finnes allerede gode løsninger slik som Synta sin Synscan som kan styres fra pc.

[Frank LarsenModerator Super Nova]

Til Linux findes allerede en softwarepakke (husker ikke lige navnet) der er opensource og understøtter et stort udvalg af platforme gennem et standardiseret interface ala ascom. Det kører også på Rpi.

Tror det bliver svært at komme igennem med en helt ny uafhængig hardware platform hvis den skal kunne kobles på eksisterende monteringer.

Men ideen er forfriskende og kunne være en moderne afløser til Mel Bartels telescope control som selvbyggere har anvendt i 10-15 år. Mel Bartels system kan så vidt jeg husker alt det du nævner, men kører under DOS.

Til Linux findes også diverse generelle hardware drivere.

[Frank LarsenModerator Super Nova]

Ps. Jeg udvikler elektronik og hardware til daglig og kan se at der er MANGE udviklingstimer i projektet, men at du har tænkt fornuftige tanker på mange detaljer. Desværre er der også mange dyre dele. Display delen er dyr. Hvorfor ikke gøre den webbaseret så man kan bruge sin smartphone istedet? Ser vi bort fra iphone er der gratis udviklingsværktøjer og det hele kan laves opensource og væsentlig mere flexibelt.

[Frank LarsenModerator Super Nova]

Jeg har lidt dårlige erfaringer med RasberryPi og Realtime systemer som en telescope motorcontroller er. Anbefaler at den del kører i uafhængig hardware.

[alanDeltager Super Giant]

Hej Frank

kan du beskrive lidt nøjere hvordan du har dårlig erfaring med Ras

berryPi. Kører den for ustabilt?

Vh Alan

[hedmarkingen Asteroid]

Det går å titte på:
http://www.cloudynights.com/ubbthreads/showflat.php?Cat=0&Number=4942046

Og
http://opendrive.gizmor.org/forum/index.php?sid=7227066ce2a6040e05eea6534733a202

Det har ikke skjedd noe på forumet på ett år,så det virker som om prosjektet er dødt. Har prøvd å få vite status på prosjektet,hva som er tilgjengelig av printkort ovs uten å bli noe klokere. De skriver jo kun på tysk,-noe som antagelig kan ha bidratt til at det tilsynelatende har gått i stå.

[nightskyDeltager Neutron star]

astroEQ + EQMOD + SGL Observatory Automation (Fokuser m.v.)

Så er pakken vist komplet. Det eneste der kræver en computer er EQMOD

https://github.com/TCWORLD/AstroEQ
http://eq-mod.sourceforge.net/
http://groups.yahoo.com/neo/groups/sgl_observatory_automation/conversations/topics

Der er et par stykker mere.

[hedmarkingen Asteroid]

Nightsky wrote: astroEQ + EQMOD + SGL Observatory Automation (Fokuser m.v.)

Så er pakken vist komplet. Det eneste der kræver en computer er EQMOD

https://github.com/TCWORLD/AstroEQ
http://eq-mod.sourceforge.net/
http://groups.yahoo.com/neo/groups/sgl_observatory_automation/conversations/topics

Der er et par stykker mere.

Problemet er at eqmod ikke er kryssplatform, det kan ikke kjøres på mac eller linux.
Poenget er også at ved å ha alt i en boks så slipper man å dra med seg en bærbar som kjører mac/linux eller windows.

[htj Planet]

Har du kigget på INDI? http://www.indilib.org/

Et interessant project ellers. Jeg ville helt klart gå efter at lave den headless, dvs uden monitor, og så tilgå ting over netværk (men det skulle indi vist være gearet til).

/Henrik

[Frank LarsenModerator Super Nova]

det var netop INDI jeg tænkte på.

Alan: Det har været i forbindelse med netværks burst i/o at jeg føler at processoren bliver belastet så den ikke når at håndtere andre processer. Det har været mest udtalt når jeg har kørt python scripts som skulle køre med lidt tæt timing. Da kom der slinger i valsen hvis abden process begyndte at lave en masse netværks io. Jeg har kun testet rasbian operativ systemet.

Men også såsan helt generelt kan man mærke at processoren skal tage sig af mange ting som på andre platforme varetages i dedikeret hardware. Når man er opmærksom på det er det dog ikke noget stort issue.

[alanDeltager Super Giant]

Frank – Dvs. hvis man er opmærksom på, at man kun har en cpu til rådighed når man bruger en RasP så kan problemerne minimeres. (Er det korrekt forstået!)

Mht hovedspørgsmålt, så lyder det interessant, men skulle man ikke tage mundfulden i små bider, med øje for en programeringsstruktur som åbner mulighed for udvidelser.

Jeg kan ikke gennemskue listen, er nogen der kan lave en prioteret rækkefølge så kunne det måske give lidt mening i mit hoved?

Jeg er absolut interesseret i et sådan projekt, ikke for at spare penge, men processen og ikke mindst udfordringen i at udvikle såden et styringssystem i fællesskab er interessant.

Mvh Alan

[swr Giant]

Hej Alan

Problemet er at Linux systemet er for langsomt til at skifte tasks (f.eks. når der kommer et interrupt) til at det rigtigt kan bruges til noget der har hårde real-time krav, som f.eks. en motorstyring kan have det.

På en lille separat microcontroller går der ganske få clockcykler fra der kommer en interrupt til programpointeren står på interruptvektoren. Til gengæld skal man selv sørge for at pushe og poppe de registre der bruges i interruptrutinen.

Der er lavet varianter af Linux der kan bruges til real-time (se f.eks. RTLinux: http://en.wikipedia.org/wiki/RTLinux), hvor Linux kører som idle-task i realtidskernen og håndterer alle de ting som ikke har hårde realtidskrav.

Mvh Søren

[Frank LarsenModerator Super Nova]

SWR wrote:

Hej Alan

Problemet er at Linux systemet er for langsomt til at skifte tasks (f.eks. når der kommer et interrupt) til at det rigtigt kan bruges til noget der har hårde real-time krav, som f.eks. en motorstyring kan have det.

Jeg er sådanset enig – Det er rigtigt at Linux ikke er realtime, men man kan dog komme meget nært hvis ikke CPU’en er FOR belastet – jeg har for år tilbage haft en 4 akset robot controller kørende med refreshrate på 1kHz uden RTLinux og ilgangshastigheder på 5m/s. Der var dedikeret hardware til det meste, men feedback løkkerne kørte i interrupts. For nuværende kører jeg et visionsystem ved 500Hz uden de helt store vanskeligheder – vanskeligheden består i at hardwaren har interrupts prioriteret således at “mit” interrupt ikke bliver serviceret til tiden hvis der er netværk eller skærmkort eller Harddisk interrupts igang. Det må man så tage højde for med tidsstempler og indrette softwaren til non-fixed samplerate.

Linux er rimelig effektivt til at taskswitche i forhold til forekesempel windows – og det kan tweakes i kernen på bekostning af respons i brugerprogrammer.
Mit problem bundede faktisk i at kernen brugte for meget tid i systemkald for at servicere netop interrupts og andet lowlevel gejl. Netværks og display oplevelsen med en raspberryPi er faktisk meget fin set i forhold til platformens lidenhed ;o)

Der er lavet varianter af Linux der kan bruges til real-time (se f.eks. RTLinux: http://en.wikipedia.org/wiki/RTLinux), hvor Linux kører som idle-task i realtidskernen og håndterer alle de ting som ikke har hårde realtidskrav.

Mvh Søren

RTLInux er et fint stykke mekanik, men lidt bøvlet når man skal lave hardware drivere. Mener at der er lavet en RT udgave til Raspberry – det vil jeg lige tjekke op på – har dog en fornemmelse af at selv med RT er Raspberry langt fra at kunne bruges direkte til realtime processer hvis den også skal lave andet samtidigt.

Så Alan: svaret hænger lidt i luften – i nogle tilfælde vil man med omhu kunne presse rigtig meget ud af RPi – i andre tilfælde skal der ekstra hardware til. Jeg ved ikke hvor grænsen går – så meget har jeg ikke presset min RPi.

[Frank LarsenModerator Super Nova]

Update:

Til RaspberryPi ser det ud til at det er Xenomai kernen man skal bruge for sub-millisekund timing:
http://diy.powet.eu/2012/07/25/raspberry-pi-xenomai/
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?RaspbianXenomaiBuild

og endelig – den “almindelige” raspberry pi kerne kan patches til noget der meget nært hardrealtime med latency målt i microsekunder:
For den nysgerrige så kan denne tråd læses – Advarsel – kun for hardcore Linux nørder!
http://raspberrypi.stackexchange.com/questions/1408/is-it-possible-to-run-real-time-software

Ser ud til at jeg må revurdere min indstilling til RPi – og skal da prøve det af ved lejlighed.

[Forfatter]

Indlæg