SONIC LED FEEDBACK: 7 trinn (med bilder)

2024 Forfatter: John Day | [email protected]. Sist endret: 2024-01-30 11:23

Hei igjen, Hater du at roboten din støter på alt? Dette vil fikse det problemet. Med 8 soniske sensorer ser dette komplisert ut … men faktisk gjorde jeg dette veldig enkelt. Jeg prøver å legge ut prosjekter som hjelper deg med å lære om Arduino og vise et "utenfor boksen" -konsept. Dette innlegget vil hjelpe deg med å forstå 595 bytte, pro-minis som en programmerbar sensor, og den store bruken av tilbakemelding fra ledet i sanntid. Hvis du liker Arduino som en "kopier og lim inn og plug-in", kan du bare hoppe over dette.

Jeg liker å bruke pro-minis. De er omtrent $ 2,50, fungerer som en fullstendig uno, og installering av overskrifter gjør dem veldig fleksible. Brukt som en sensormikro kan du få den til å "gjøre hva du vil" i stedet for hva en kjøpt sensor dikterer. Med I2C som bare bruker 2 ledninger, kan de bindes sammen på en linje. Så flytt over MEGA. Jeg kan ha 4 minier som kjører 4 separate kodelinjer samtidig, til bare $ 10,00. Her bruker jeg en mini til å stikke de soniske sensorene gjennom en 595 og vise sanntid ledd avstand. Deretter er det bare å dele 8 bit data med hovedkortet. Dette tar belastningen av hovedkortet og gjør koden hennes veldig enkel.

Det er et problem med soniske sensorer … ingen visuell tilbakemelding. Du vet aldri om sensoren bare er en egenvekt eller fungerer! Jeg tror hvem som noen gang har kommet med 'BLINK' er smartere enn Einstine. Bare ÉN ledet og en verden av informasjon formidles av blinkingen. Så en sonisk sensor trenger tilbakemelding i sanntid. Her brukte jeg en rekke lysdioder for å overvåke hver sensor. Du trenger dem ikke, bare lag sensorene uten lysdioder. Men å ha lysdiodene på kretskortet er nyttig.

Trinn 1: LAG PCB

lage PCB og fylle ut. FORSIKTIG… Jeg gjorde en feil på kretskortet ved 4 -pinners tilkoblinger som de soniske sensorene skulle plugges inn i. ECHO og TRIGGER Vcc og begrunnelse kom til å koble til PCB. Det er ikke nok plass til kontakter, så jeg har nettopp laget kretet med pin-outs. Så du kan lodde en ledningskontakt til kretskortet og koble til de faktiske soniske sensorene. Når det gjelder lysdiodene, satte jeg gule lysdioder på innsiden og rødt på utsiden. Dette hjelper deg med å se på avstand om sensorene måler riktig.

Dette er en av de FÅ 2 -siders PCB jeg noen gang har laget. Jeg vil heller lage 2 ea enkeltside og løpehoppere. Men for å få LED -skjermen trenger du minst den øverste kretskortet. Jeg skilt oppsettet i nedlastingen.

Kretskortet er for en pro-mini med A4-A5 inne i kantoverskriften. Uansett, bare koble A4-A5 til Master A4-A5. Ikke glem Vcc and Grounds også.

Trinn 2: MANGE FEIL

Nå for mine feil … Jeg prøvde å slå utløserne på en gang (alle knyttet sammen), og dette fungerte bra, men noen interaksjoner fant sted. Så nå går alle ECHOS til mikro (8) og TRIGGERS settes med en 595. Tre pinner til (3). Når det gjelder lysdioder, fungerer ikke multipleksing. Du trenger full PÅ -tid for hver LED. Dette betyr at hver rad med 7 lysdioder må ha sin egen 595. Når du har oppdatert 595, forblir lysdiodene opplyst til neste oppdatering. Når multiplexing av LED -en bare lyser i den tiendedelen av et sekund. Dette fungerer bra i leserne mine, og det trenger en dedikert mikro. Ingen tid til å skanne 8 soniske sensorer og måle avstander. Jeg prøvde og fikk svært dårlige resultater. Multiplexing av lysdiodene vil også bety et rutenett med rad + kolonne, og det betyr rundt 64+ gjennomføringer i kretskortet.

Jeg brukte bare 7 utganger fra 595 på grunn av rot på PCB. På avstand kan du ikke se om det er 7 eller 8 lysdioder bare deres bevegelse. Du kan bli fristet til å knytte alle lysdiodene til en enkelt motstand, og dette fungerer, men lysstyrken til matrisen endres med mengden lysdioder som er lite. Så en motstand per LED er best. Jeg bare elsker 595, men hvis de bare flyttet Vcc- og 0-out-pinnene eller laget en 18-pins IC med ALLE utganger på samme side … ville det være så enkelt å koble til alle åtte utgangene. Men da ville den ikke selge for mindre enn 30 øre.

Trinn 3: MONTER SENSORER

Lim soniske sensorer på kaffelokket. hannkontakten må bøyes innover på hver sensor. Dette fungerer bedre hvis du bøyer en pinne om gangen. Jeg brukte 2 sideskumbånd bare så vibrasjonen er mindre. Sensorene mine er for nære, og de trenger en 1/4 tommers plass for å matche kretskortet bedre. Jeg har brukt soniske sensorer før, og noen ganger klarer man ikke å måle nøyaktig, og du må huske på dette. Så ikke GLUE dem alle permanent.

Det hjelper også å kjøre en rask distansetest på hver enkelt før du bruker dem. Jeg får omtrent en sensor med dårlig lesing i en gruppe på 20. Ikke verst for prisen jeg betalte.

Trinn 4: HARD WIRE

Jeg trodde det ville være plass til kontakter og plugger fra PC -en til

soniske pins, men jeg gikk tom for rom. Så jeg koblet hardt til PCB -enden og lagde bare ekko og utløserledninger med hunkontakter (8ea). Jeg knyttet 8ea Vcc og 8ea grunnene til sensorene sammen, så dette gjorde bare 2 tilkoblinger til PCB for dem.

Med 8 sensorer og 8 595s kan en uno eller pro-mini IKKE drive denne. Det må være en 5v regulert kilde som en del av dette prosjektet. Min robot har en enkel 7805 @ 1amp fra batteriene. Dette knytter seg til alle 5v Vcc for alle enheter. 7805 faller omtrent en volt, så du trenger minst 6,5 volt for å mate den. Det vil si to litiumbatterier på 3,3v. Min robot har gamle nikader fra brukte borepakker og 8 nikader kjører den typiske 12V -motoren i Kina i chassiset på 20 dollar.

Trinn 5: LAST NED SONIC SKETCH

Last ned skissen og installer. Det er mange måter å snakke med

en annen uno, men jeg liker I2c. forvirringen er adressering og herre/ slave. Som med de fleste sensorer (tenk på den andre mini som en sensor), adresserer du sensoren og ber om x byte. det samme her. I den andre mini setter du av x mengden byte du vil sende. Forvirringen er at navn ikke spiller noen rolle. Det hjelper deg bare å huske hvis du deler navnene. Så i skissen sender jeg de 8 soniske avstandsmålingene i cm som sendR1, sendR2, sendR3, sendR4, sendL1, sendL2, sendL3, sendL4. Mesteren får bare 8 byte hvis data, og du kan kalle disse byteene for alt du vil. Jeg leste dem som gotR1, gotR2, got….. Den sendte rekkefølgen av byte er den samme. Så byte A, B, C….. ikke tro at ved å endre navnet vil gi deg forskjellige data. Og den andre fangsten, du kan bare motta data som blir fortalt å bli sendt. Så hvis du vil ha andre data må du bytte BÅDE master og slave.

Trinn 6: KOMMUNIKASJON

Du kan hoppe over dette hvis du vet hvordan du konfigurerer 2 Unos for å snakke med hverandre. Jeg har en del informasjon på slutten. For å gjøre det enkelt vil jeg kalle unoen i robotbasen M1 og den soniske sensoren som S2. Koble Vcc, bakken, A4, A5 til hverandre.

I skissen for S2 begynner det med #include

Lag deretter de 8 bytes som skal sendes. byte R1, byte R2, byte L1 etc. Uno er en 8 -biters mikro, så de sender 1 byte om gangen ved å bruke 'byte' i stedet for 'int' er riktig.

I 'setup ()' legg til 'Wire.begin (adresse)' forteller dette I2c hvilken enhet dette er. Adressen er vanligvis et hvilket som helst tall du liker mellom 4 - 200. størrelsen på en byte. Her brukte jeg tallet 10. Så for å snakke med denne sensoren S2 må masteren ringe Wire.requestFrom (10, 8). Dette er adresse 10 og 8 er hvor mange byte som ønsket. Legg også til i 'setup ()' Wire.onRequest (isr anyName). Når M1 ringer forespørselen, reagerer S2 -sensoren med avbruddet. Dette kaller bare funksjonen anyName. Så denne anyName -funksjonen må opprettes. Se på skissen og se funksjonen 'sendThis ()' Det er her bytes faktisk blir sendt til M1. Byte alene går og IKKE navnene og i rekkefølgen sendt. Det er her størrelsen og mengden data som skal sendes starter fra. I dette enkle byteformatet skal sendingen og mottaket stemme overens. Her er 8 byte sendt og 8 byte mottatt. En merknad her er å kalle en funksjon som krever (). Som forsinkelse (), millis (), Serial.print (). Når du bruker en ISR (interrupt service routine) ringer funksjonen ned (). Så Wire.onRequest (sendThis) ikke Wire.onRequest (sendThis ()).

Forvirringen jeg hadde var mesteren/slaven. Først trodde jeg at mesteren ALLTID var mesteren. Men innenfor skissen kan du bytte master/slave til forespørsel fra andre mikroer eller sende til andre mikroer. Så lenge du fulgte grunnformatet som er skissert ovenfor. Husk … du deler KUN data som er tildelt.

To biter av veggen. ISR -avbruddet avbryter bare mellom skisselinjer. Hvis du er låst i en 'mens eller for' sløyfe, skjer det ingenting før løkken går ut. INGEN stor sak da dette kan være noen mikrosekunder og dataene er gamle.

Det andre problemet er, "inne" i en mikro, det er 100% feilfri beregning. All "ekstern" (ledning) kommunikasjon er gjenstand for feil. Det er mange måter å kontrollere at dataene som er levert er feilfrie og samsvarer med kilden. Den enkleste måten er med kontrollsum. Bare legg til totalene til sendebytes (faktiske verdier) og send totalene, og i mottakerenden legg til totalene og se om de stemmer overens. Hvis de stemmer overens eller kaster det datasettet hvis de ikke gjør det. Selvfølgelig innebærer dette å sende en heltallsverdi og ikke byte. Så du deler bare heltallet i HI -byte og LO -byte og sender som separate byte. Sett deretter sammen på mottakeren.

LETT:

int x = 5696; (enhver gyldig int -verdi, maks er 65k eller 32k negativ)

byte hei = x >> 8; (22)

byte lo = x; (64)

send byte og kombiner i den andre enden….

byte hi = Wire.read ();

byte lo = Wire.read ();

int newx = (hei << 8) + lo; (5696)

Trinn 7: LUKKING

For å lukke, gir denne soniske sensoren hovedkortet rå avstandsdata i sanntid. Dette frigjør mikroen og gjør skissen mye mindre komplisert. Mikroen kan nå ta en god beslutning om å bremse, snu, stoppe eller reversere basert på gode data i stedet for tilfeldige gjetninger. Se mitt andre innlegg om bluetooth IDE for å laste opp skisser uten ledninger og måtte koble roboten din hele tiden for bare en rask endring i skissen din. Takk for at du så på dette. oldmaninsc.