Kiirusemõõtja PIC-ga

[sebastian]

Soov oleks siis selline asjandus teha...
Kaks laserit vahemaaga 1m on asetatud rajale, auto katkestab esimese kiire ja siis teise. Katkestuste vaheline aeg on 3,6/kiirus(km/h)=x sek.
Ehk siis auto liikudes kiirusega 200km/h katkestab kiired 18ms jooksul.
PIC-le saab järele panna 7-segmendilised LED-tablood, nagu aru saan? Mõte olekski kasutada nelja sellist indikaatorit, mis näitaksid kiirust täpsusega xxx,x km/h.
Nüüd selline küsimus, et kuidas oleks see PIC-ga kuidagi lahendatav? Kas programm oleks üle mõistuse keeruline? Või on äkki mõõtmiseks mingi loogilisem variant netiavarustest saadav. Küll otsisin, aga mitte ei leidnud..

Ise oma lolli peaga mõtlesin, et võiks olla mingi 555-baasil stabiliseeritud generaator, mis esimese katkestusega tööle pannakse ja teise katkestusega seisatakse. PIC saab impulsside arvu ja kuvab kiiruse tablool.
Äkki on see mõte liiga lihtne, et hea olla?

(edit: tabloo kõlab kuidagi suureliselt, mõtlesin ikka mingeid 1...2cm 7-segment indikaatoreid..:-) )

[felch]

Vs: Kiirusemõõtja PIC-ga

Esimesest pulsist läheb käima PICi sisemine taimer, teine pulss paneb ta seisma. Edasi teisendad ja kuvad.
Samal põhimõttel tegin Tipis mitmed praksiseadmed. Aega mõõdetakse ms täpsusega.

[bloody-orc]

Re: Kiirusemõõtja PIC-ga

Tehtav. ja suhteliselt lihtne. Alusta sellest, et osta omale see PIC ja siis need tablookesed. Saa nendega suhtlemine korda. Siis andurid. Ühele poole passiivne laser, teisele poole fotosensor (laserandur on täiesti olemas ja töötab kuradima hästi. äkki saame äri teha (mul on 2 tk üle). Need toidavad siis laserit vastavate pulsidega ja loevad siis seda ka ise. Kui laser on, siis on väljundis 1, kui teda pole, siis on 0. Seda siis PICuga taga ajadgi. ootad falling edge interrupti, kui see tuleb käivitad taimeri (nii kiire kui võmalik, aga mitte liiga kiire, et see 10 korda overflowiks selle 1m ajal) ja Kui teine interrupt tuleb teise jalaküljest, siis lööd taimeri kinni. ja ongi asi lahendatud.

[felch]

Vs: Kiirusemõõtja PIC-ga

Täpselt nii ma tegingi. Ainult LEDide asemel on LCD. LEDe saaks draivida otse koodist aga saaks ka MAX7219 kivi abil. viimane variant on lihtsam sest kivi tegeleb pildi laotamisega ise. Kallim ka kahjuks: http://www.tevalo.ee/cgi-bin/web_sto...-54#!73-721-54

Kui soovi, võin koodi ja skeemi jagada.

[sebastian]

Vs: Re: Kiirusemõõtja PIC-ga

Bloody-orc, sa vist mõtled, et olen jõle teadlane PIC-de kohalt
Kaugel sellest.
Willem programmaator mul on, HexWorkshop'i oskan natuke kasutada ja flash mälude .bin faile natuke mõikan.
Sellega mu tarkus esialgu piirdubki

Äkki saate härrased mingi lingi visata, kuidas indikaatoreid PIC-ile külge aretada, need kiirust mõõtma panna ja siis impulssidega mängida...
Või on ehk keegi nõus lausa skeemi joonistama, teatud tasu eest muidugi?

Kas laseri enda pulsitamisest piisab, kui täpsus peab olema u. 0,01ms?
PIC-i sisemine taimer peaks vist üsna täpne olema kui seda kvartsiga stabida?
Peaks veel olema selline võimalus, et programmi muutes liigutada laserid näiteks teineteisest 2m kaugusele (ja laseri -> anduri vaheline kaugus arvatavasti ~6m)...juhul, kui asi pole piisavalt täpne.
Seejuures laserid ja andurid polegi eriliseks probleemiks, selliseid skeeme ikka liigub, aga just see PICitamine millest ma suurt tuhkagi ei jaga.
Muidu äri võib teha ikka, kui asi sobib.

Täpselt nii ma tegingi. Ainult LEDide asemel on LCD. LEDe saaks draivida otse koodist aga saaks ka MAX7219 kivi abil. viimane variant on lihtsam sest kivi tegeleb pildi laotamisega ise. Kallim ka kahjuks: http://www.tevalo.ee/cgi-bin/web_sto...-54#!73-721-54

Kui soovi, võin koodi ja skeemi jagada.

Seda MAX-i olen isegi vaadanud. Kas äkki saab kasutada...Skeem palun ikka saada :-)

[bloody-orc]

Re: Vs: Re: Kiirusemõõtja PIC-ga

ära 2m peale küll pane. viimnegi täpsus kaob ära. Mina paneks need 2 laserit mingi sentimeetrise vahega... mikrokontroller on kuradima kiire ja mida lühemad ajavahemaad, seda täpsem (minu kogemused).

Äkki leiame mingi kokkuleppe ja saaks selle asja ära teha? skeem+progre+laserandurid vmt... või soov ise teha? Mis ajaks vaja läheb?

Rain

[sebastian]

Vs: Re: Vs: Re: Kiirusemõõtja PIC-ga

ära 2m peale küll pane. viimnegi täpsus kaob ära. Mina paneks need 2 laserit mingi sentimeetrise vahega... mikrokontroller on kuradima kiire ja mida lühemad ajavahemaad, seda täpsem (minu kogemused).

Äkki leiame mingi kokkuleppe ja saaks selle asja ära teha? skeem+progre+laserandurid vmt... või soov ise teha? Mis ajaks vaja läheb?

Rain

Ei ole mul väga soovi ise teha.
...aga selle osa mida oskan, võin küll valmistada. Ei tahaks väga kulutada, kui isegi seadme toimivuses pole kindel.

Vahemaadest...vaat probleem selles, et täpsus just kannatabki. Kui auto liigub kiirusega 200km/h (ja sellised mõõdetavad kiirused ongi) kahe laseri/anduri vahelt läbi, siis toimub see "1m andurite vahega" 18ms-ga. Kui nüüd andurite vahe on ainult millimeeter väiksem, siis näitab tabloo kiiruseks 200,2km/h. Nagu näed, "error" juba 0,2km/h. Kujuta nüüd ette kui täpne vahe peab anduritel olema, kui nad asetsevad teineteisest ainult sentimeetri kaugusel! Suurusjärgus 0,01 millimeetrit! Arvestades laseri kiire "laiust" on nii täpne gradueerimine minumeelest võimatu. Seda enam, et laseri ja anduri vahe peab olema ~6 meetrit, et auto täiesti vabalt ja suure varuga vahelt läbi läheks. Noh...spetsiaalse kollimaatoriga annaks ehk midagi teha, lihtsalt asja hind läheb väga astronoomiliseks.
Aga see selleks

Kiire mul pole. Selle aasta lõpuks võiks valmis olla. Et toimivust kontrollida, siis võiks saada varemgi. Vihma- või lumega ei viitsi minna lennuväljale proovima
See MAX7219 variant on vist täiesti söödav displeide jaoks. Lasermoodulid saab Tevalost, need sobivad küll (oli mul selline). Mehaanilise osa, reguleeritavad jalad anduritele, samuti peeglitele mõtleb ka välja.

edit: üks asi siiski...üle meetri ei tohi vist laserite vahe olla. Auto kiirus pole ju konstantne vaid kiirenev ja seade hakkab mõõtma mingit suvalist keskmist.

[KaruTEC]

Vs: Kiirusemõõtja PIC-ga

Mnjah, lihtne keskkoolimatemaatika on abiks !

V = S/t

dV/dS = 1/t

dV = dS/t

ehk siis dV/V = dS/S ja kuna dS ehk anduri paigutamise viga on teatud piirides konstante (mõõdulindiga mõõtmise täpsus on paari meetri kohta umbes millimeeter) siis on ju siililegi selge et dV/V ehk viga väheneb S kasvades.

ja teistpidi

V = S/t

dV/dt = -S/t2

dV = -S*dt/t2

dV/V = -dt/t

Mis siis omakorda tähendab et kuna ajaviga on kah enamvähem konstante (tingitud katkestuse jms latencyst, kvarts (ka odav) on piisavalt täpne (0.05%) siis mida pikemat ajavahemikku mõõdad seda toredam.

Kokkuvõtlikult peaks viga olema midagi sellist dV/V = Sqrt((-dt/t)^2+(ds/S)^2) ehk siis suhtelise ajavea ruut + suhtelise kaugusevea ruut ja summast ruutjuurikas.

Bloodyorci väide väiksest vahemaast on matemaatiliselt ümber lükatud MOTT.

[KaruTEC]

Vs: Kiirusemõõtja PIC-ga

Ja veel. "juba 0.2kmh" tähendab viga 0.1%. See on liigagi täpne. Ei maksa oma pead vaevata. 1% kogutäpsust on juba hea tulemus.
Eelnevast valemist võid arvutada - oletame et ajamõõtmine on ideaalne.
Kui tahad 0.1% siis peaksid panema nt. 10m andurite vahe korral täpsusega +-5mm või parem. Oletame et sul on andurid alumiiniumprofiilil. Nii pikk latt pikeneb / lüheneb 0.3 mm per kraad ja temperatuurimuut 20kraadi tähendaks pikkuse muutu 6mm. Pluss ebatäpsused koostamisel(+-3mm tundub reaalne). Vot nii.

Muuseas, tegemist on palju suurema tööga kui sa ette kujutad ja palju keerulisema probleemiga kui sa loodad. Mina soovitan otsida valmislahenduse.

[sebastian]

Vs: Kiirusemõõtja PIC-ga

Ja veel. "juba 0.2kmh" tähendab viga 0.1%. See on liigagi täpne. Ei maksa oma pead vaevata. 1% kogutäpsust on juba hea tulemus.
Eelnevast valemist võid arvutada - oletame et ajamõõtmine on ideaalne.
Kui tahad 0.1% siis peaksid panema nt. 10m andurite vahe korral täpsusega +-5mm või parem. Oletame et sul on andurid alumiiniumprofiilil. Nii pikk latt pikeneb / lüheneb 0.3 mm per kraad ja temperatuurimuut 20kraadi tähendaks pikkuse muutu 6mm. Pluss ebatäpsused koostamisel(+-3mm tundub reaalne). Vot nii.

Muuseas, tegemist on palju suurema tööga kui sa ette kujutad ja palju keerulisema probleemiga kui sa loodad. Mina soovitan otsida valmislahenduse.

Ma ei suhtuks asjasse nii pessimistlikult 0,1% viga on muidugi palju tahetud, aga et parem 1%-st, seda julgen küll arvata. Samas, absoluutsetest kiirustest on olulisemad siiski ühe "korra" suhtelised kiirused erinevate autode vahel. Ei ole vahepealset seadistamist mis mõõtmisviga suurendaks.

Andurite vahet pole mõtet nii pikaks ajada, aga ma tahan proovida. Ilmselt pole raske teha soft 3-le variandile, 10cm - 50cm - 100cm...esimene variant siis lihtsalt "laua peal" seadme toimivuse testimiseks. Ilmne, et laseri kiiri väga täpselt (suht odavate vahenditega) ei saa paika, aga latil ei pea andurid tingimata asuma e. siis paisumisest tingitud viga jääb ära.
Valmislahenduse peale enne ei mõtle, kui isetehtu osutub jamaks.
Proovima ikka peab.

[6p45s]

Vs: Kiirusemõõtja PIC-ga

Kasutaksin juhust sarnase rakenduse jaoks abi küsida.

Seadmeks on tahhomeeter ning pöörlemissageduse vahemikuks esialgu 100 kuni 5000 RPM. Periood siis vastavalt 12 kuni 600 ms. Andurina kasutan TTL-vastava väljundnivooga optokatkestit, väljundisse on ühendatud 2,5 numbrikohaga (188) 7-segmendiline numberindikaator ning MCU-ks pic16f84a. Kuna asi on eelkõige õppeotstarbeline, pole esialgu plaanis lisada numbrikohti ega arvutada mitmebaidiliste suurustega.

Põhiliselt tekitab raskusi asjaolu, et samaaegselt
impulssidevahelise intervalli mõõtmise ja/või impulsi frondile (langevale) reageerimisega tuleb multipleksida ka indikaatori numbrikohti. Impulssidevahelise intervalli sammuks on 4,096ms (prescaler´i jagamistegur 1/16, määratud TMR0 sisendisse), mis iseenesest lubaks kasutada ,,Elmer's PIC Lessons"-is
http://www.amqrp.org/elmer160/lessons/
toodud multitasking-u lahendust (tund nr 13). Kuna seal kasutatakse vaid TMR0 ületäitumise puhul tekkivat katkestust, tuleks sisendimpulsiga tegeleda siis, kui vastava programmiosa ,,kord" on kätte jõudnud, seega ajalise kõrvalekaldega kuni 8 ms, mis oleks antud juhul täiesti vastuvõetav. Kuna oluliselt arendavam ja edaspidiste katsete tarvis parem oleks koostada programm, mis suudaks reageerida nii TMR0 ületäitumisele kui RB0 langevale frondile vahetult pärast nende olukordade ilmnemist, peaks programmi struktuur olema midagi lingil toodu taolist: www.hot.ee/hkraav1/prog.JPG

(Vabandan, kui leidub loogikavigu, idee alles küllaltki toores). Kõik ,,katkestuse" poolel paiknevad programmiosad peaksid asuma vastavas alamprogrammis ning ülejäänu põhiprogrammis. Seega katkestused on lühikesed ning eelistatult ainult kestuse suhtes kriitilised programmiosad. Intervalli mõõdetakse üle täispöörde. Siit ka konkreetne küsimus: kuidas katkestuse alamprogrammist tulla tagasi põhiprogrammi kindlasse punkti (antudjuhul punkti ,,A" või ,,B")? Kas PCL-registrisse panna sellele punktile vastav väärtus ning mis saaks sellisel juhul stack-iga? Programmeerimise keelena kasutan assemblerit.

PS. lihtsa loenduri sain juba käima.

[felch]

Vs: Kiirusemõõtja PIC-ga

Katkestusest välja tulekul minnakse tagasi sellesse kohta, kust katkestuse hetkel oldi. Enamasti sellest piisab.
PCLi ja PCLATHiga mängimine vist ei anna tulemusi sest prose kasutab oma sisemist stacki ja järgmise RETi puhul läheb sinna kuhu stacki viit näitab. PIC18 seeria prosedel saab stackiga rohkem mängida. Neil on ka katkestuste prioriteet olemas.

[6p45s]

Vs: Kiirusemõõtja PIC-ga

Nüüdseks on õnnestunud tahhomeeter teatud määral tööle saada.
Multitasking-u tekitamiseks võtsin kasutusele olekumuutuja, milles leiduvad bitid määravad, milliseid alamprogramme põhiahela läbimisel välja kutsutakse. Põhiahelat läbitakse TMR0 ületäitumise korral, nagu eelpool toodud lingil asuvas materjalis, kuid INTCON,TOIF asemel kasutatakse lipuna ühte olekumuutuja bitti. See seatakse katkestuse
alamprogrammis ning nullitakse põhiprogrammi ahela läbimise järel. Nimetatud lahendus võimaldab erinevatele katkestustele (antud juhul TMR0 ületäitumine ja RB0 langev front) anda erinevad prioriteedid. Praegu vajavad lahendamist veel ajamuutuja liiga väikse ulatusega seotud probleemid. Nimelt täidetakse Võlli kiirel pöörlemisel muutujas vaid mõned järgud. Hiljem TMR0 ületäitumise ja pöörlemiskiiruse teisendamise tulemusena saadud konstanti mõõdetud aja väärtusega jagades muutub skaala ,,ülemine ots* väga astmeliseks. Näiteks kui aeg on 1, tekib tabloole number 150, kui aeg = 2, arv 75 jne. Kui asi korralikult tööle hakkab, riputan ka algoritmi ja koodid kodulehele.

[felch]

Vs: Kiirusemõõtja PIC-ga

Päris kaval! Aga 18-seeria katkestusi ta vist ikkagi ei löö? Sa ju ei saa katkestuses olles kõrgema prioriteediga katkestusse minna? Aga ilmselt pole seda vajagi.

[6p45s]

Vs: Kiirusemõõtja PIC-ga

... Sa ju ei saa katkestuses olles kõrgema prioriteediga katkestusse minna?...

Jah ja ei. Päris ühest katkestusest teise ei saa, kuid enamus ühele või teisele katkestusele vastavast programmiosast paikneb nüüd harilikes alamprogrammides. Näiteks impulsside tagafrontide-vahelise aja arvutamine ja teisendus BCD-ks on täielikult ,,väljaspool katkestust". Seega võib mõlemast nimetatud programmiosast minna tagasi TMR0 ületäitumisega tegelema ja teoreetiliselt ka uut intervalli mõõtma. Viimane olukord on praktikas kahtlane, sest vaevalt, et arvutamise ja BCD-ks muundamisega millisekundeid läheb. Olen kaalunud ka intervalli mõõtmist ainult 1 kord, ehk pärast näidu uuendamise lipu seadmist , mis ise toimub alles pärast teatud arvu TMR0 ületäitumisi. Näiteks seadme jalgratta (mopeedi, mootorratta) spidomeetrina kasutamisel võivad impulssidevahelised ajad olla piisavalt pikad, et näitu uuendada näiteks iga 2 pöörde järel, nagu tahhomeetri esialgses variandis.

Praegu ootavad lahendamist 2 probleemi:
1)Mingil põhjusel muutuvad skaala ,,ülemise otsa" numbrid liiga sujuvalt,
näiteks ühe numbri kaupa. Arvatavasti mõjutab katkestus programmimälusse
paigutatud tabelist võetava mustri aadressi. Idee järgi minnakse sellesse
alamprogrammi, numbrile vastav arv W-registris, liidetakse see PC-le otsa
ja võetakse vastav muster. Pärast retfie-d tullakse tagasi aga järgmisele
PC-aadressile.
2)Tsükli kestus muutub sõltuvalt RB0 katkestuse esinemise sagedusest.
Loodetavasti mõni portA kirjutamise koht kahe silma vahele jäänud.
Teatud arvu põhiprogrammi läbimiste järel muudetakse RA0 (sinna on
ühendatud valgusdiood) olek vastupidiseks. Halvemal juhul ei seata teise
katkestuse täitmise ajal TMR0 ületäitumise lippu. Kui seatakse, tuleb
MCU kohe pärast RB0 poolt kutsutud katkestusega tegelemist TMR0
oma juurde. Vaja mingi lihtsama programmi abil järgi uurida.