CanSat - Nybegynnerguide: 6 trinn

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

Hovedmålet med denne instruksen er å dele utviklingsprosessen til en CanSat, trinn for trinn. Men før vi starter, la oss gjøre det veldig klart hva en CanSat er, og hva er de viktigste funksjonene, og også benytte sjansen, vi skal introdusere teamet vårt. Dette prosjektet startet som et forlengelsesprosjekt ved vårt universitet, Universidade Tecnológica Federal do Paraná (UTFPR), campus Cornélio Procópio. Guidet av vår rådgiver utviklet vi en handlingsplan med den hensikt å komme inn på CanSats, som innebar å studere alle aspektene og egenskapene for å kunne forstå hvordan det fungerer, noe som til slutt ville resultere i konstruksjon av en CanSat, og utviklingen av denne guiden. En CanSat er klassifisert som en picosatellitt, noe som betyr at vekten er begrenset til 1 kg, men normalt veier CanSats omtrent 350 g, og strukturen er basert på en brusboks, en sylinder på 6, 1 cm i diameter, 11, 65 cm høy. Denne modellen ble presentert med den hensikt å forenkle utviklingen av en satellitt, for å gjøre universitetenes tilgang til disse teknologiene mulig, og oppnå popularitet på grunn av konkurransene som tok i bruk dette mønsteret. Generelt er CanSats basert på 4 strukturer, det vil si kraftsystemet, sensingsystemet, telemetrisystemet og hovedsystemet. Så la oss se nærmere på hvert system: - Strømsystem: Dette systemet er ansvarlig for å levere elektrisk energi til de andre, i henhold til dets behov. Med andre ord, det skal levere systemene den nødvendige spenningen og strømmen, i henhold til grensene. Den kan også inneholde beskyttelseskomponenter for å garantere sikkerheten og riktig oppførsel til de andre systemene. Vanligvis er det basert på et batteri og en spenningsregulator krets, men mange andre funksjoner kan legges til, for eksempel strømstyringsteknikker og flere typer beskyttelse. - Sensing system: dette systemet består av alle sensorer og enheter som er ansvarlige for å samle inn nødvendige data. det kan kobles til hovedsystemet på flere måter, serielle protokoller, parallelle protokoller blant andre, det er derfor det er veldig viktig å mestre alle disse teknikkene, for å kunne bestemme den mest praktiske. Generelt er den serielle protokollen de som ofte velges, på grunn av deres mindre antall tilkoblinger og allsidighet, er de klart mest populære protokollene SPI, I2C og UART. - Telemetrisystem: Dette systemet er ansvarlig for å etablere den trådløse kommunikasjonen mellom CanSat og bakkekontrollstasjonen, som inkluderer den trådløse kommunikasjonsprotokollen og maskinvaren. - Hovedsystem: Dette systemet er ansvarlig for å koble sammen alle de andre systemene, på en måte som det også styrer og synkroniserer driftssekvensen som en organisme.

Trinn 1: Hovedsystemet

Av mange grunner har vi valgt en ARM® Cortex®-M4F-basert mikrokontroller, det er en MCU med lav effekt, som gir mye høyere prosessorkraft, pluss flere funksjoner som ikke er vanlig å se i RISK-mikrokontrollere, for eksempel DSP-funksjoner. Disse egenskapene er interessante fordi de muliggjør økning i kompleksiteten til funksjonene i CanSat -applikasjonene, uten at det er nødvendig å endre mikrokontrolleren (selvfølgelig også med respekt for grensene).

Så lenge prosjektet hadde flere økonomiske begrensninger, skulle den valgte mikrokontrolleren også være rimelig, så etter spesifikasjonene endte vi med å velge ARM® Cortex®-M4F Basert MCU TM4C123G LaunchPad, det er en lanseringsplate som nettopp passet til prosjektet vårt. Også dokumentasjonen (datablad og kjennetegn dokumentasjon levert av fabrikanten) og IDE for MCU var fordeler som virkelig burde vurderes, så lenge de hjalp utviklingsprosessen mye.

I denne Cansat bestemte vi oss for å holde det enkelt og bare utvikle det ved å bruke lanseringsplaten, men selvfølgelig i fremtidige prosjekter vil dette ikke være et alternativ, med tanke på at flere funksjoner som er inkludert i lanseringsplaten faktisk ikke er nødvendige for prosjektet vårt, pluss formatet begrenset mye prosjektet med strukturen til vår CanSat, så lenge dimensjonene til en CanSat er minimale.

Så etter å ha valgt den riktige 'hjernen' for dette systemet, var neste trinn utvikling av programvaren, også for å gjøre det enkelt bestemte vi oss for å bare bruke et sekvensielt program som gjør følgende sekvens med en frekvens på 1Hz:

Sensormålinger> datalagring> dataoverføring

Sensordelen blir forklart senere i sensingsystemet, så vel som dataoverføringen forklares i telemetrisystemet. Til slutt var det å lære å programmere mikrokontrolleren, i vårt tilfelle trengte vi å lære følgende funksjoner til MCU, GPIO -ene, I2C -modulen, UART -modulen og SPI -modulen.

GPIO -ene, eller rett og slett generelle innganger og utganger, er porter som kan brukes til å utføre flere funksjoner, så lenge de er riktig angitt. Med tanke på at vi ikke bruker noen C -biblioteker for GPIO -ene, ikke engang for de andre modulene, skulle vi konfigurere alle nødvendige registre. Av denne grunn har vi skrevet en grunnleggende veiledning som inneholder eksempler og beskrivelser knyttet til registrene til modulene vi bruker, som er tilgjengelige nedenfor.

For å forenkle og organisere koden ble det også opprettet flere biblioteker. Så ble biblioteker opprettet for følgende formål:

- SPI -protokoll

- I2C -protokoll

- UART -protokoll

- NRF24L01+ - transceptor

Disse bibliotekene er også tilgjengelige nedenfor, men husk at vi har brukt Keil uvision 5 IDE, så disse bibliotekene kommer ikke til å fungere for kodekomponist. Til slutt, etter å ha opprettet alle bibliotekene og lært alle nødvendige ting, ble den endelige koden satt sammen, og som du kanskje kan forestille deg, er den også tilgjengelig nedenfor.

Trinn 2: Sensing System

Dette systemet består av alle sensorer og enheter som er ansvarlige for å samle informasjon om driftsforholdene til CanSat. I vårt tilfelle har vi valgt følgende sensorer:

- et 3 -akset digitalt akselerometer - MPU6050

- et 3 -akset digitalt gyroskop - MPU6050

- et 3 -akset digitalt magnetometer - HMC5883L

- et digitalt barometer - BMP280

- og en GPS - Tyco A1035D

Valgene var hovedsakelig basert på tilgjengeligheten, noe som betydde at så lenge de mekaniske og elektriske (kommunikasjonsprotokollen, strømforsyningen osv.) Var kompatible med prosjektet vårt, ble det ikke pålagt ytterligere parametere for valgene, også fordi det for noen sensorer var tilgjengelighet av alternativer var begrenset. Etter å ha anskaffet sensorene, var det på tide å sette dem i gang.

Så den første som ble utforsket var det 3 -aksede digitale akselerometeret og gyroskopet, kalt MPU6050 (det kan lett bli funnet hvor som helst, så lenge det er mye brukt i ARDUINO -prosjekter), kommunikasjonen er basert på I2C -protokollen, en protokoll der hver slave eier en adresse, slik at flere enheter kan kobles parallelt, med tanke på at adressen er 7-bits lang, kan omtrent 127 enheter kobles til den samme serielle bussen. Denne kommunikasjonsprotokollen fungerer på to busser, en databuss og en klokkebuss, så for å utveksle informasjonen må masteren sende 8 sykluser med klokke (for øvrig må informasjonen passe til en byte, så lenge denne kommunikasjonen er basert på byte -størrelsen) enten i en mottak eller i en overføringsoperasjon. MPU6050s adresse er 0b110100X, og X brukes til å ringe (indikerer) en lesing eller en skriveoperasjon (0 indikerer en skriveoperasjon og 1 indikerer en leseoperasjon), så når du vil lese sensoren, bruk bare adressen som 0xD1 og når du vil skrive, bare bruk adressen som 0xD0.

Etter å ha utforsket I2C -protokollen, ble MPU6050 faktisk studert, med andre ord ble databladet lest, for å få nødvendig informasjon for å få det til å fungere, for denne sensoren måtte bare tre registre konfigureres, strømstyringen 1 register - adresse 0x6B (for å garantere at sensoren ikke er i hvilemodus), gyroskopets konfigurasjonsregister - adresse 0x1B (for å konfigurere hele skalaområdet for gyroskopet) og til slutt akselerometerets konfigurasjonsregister - adresse 0x1C (i for å konfigurere hele skalaområdet for akselerometeret). Det er flere andre registre som kan konfigureres, slik at optimalisering av sensorytelsen kan oppnås, men for dette prosjektet er disse konfigurasjonene nok.

Så, etter riktig konfigurering av sensoren, kan du nå lese den. Den ønskede informasjonen finner sted mellom registeret 0x3B og registeret 0x48, hver akseverdi er sammensatt av to byte som er kodet på 2s komplement måte, noe som betyr at de lesede dataene må konverteres for å være meningsfulle (disse tingene vil være diskutert senere).

Etter å ha blitt ferdig med MPU6050, var det på tide å studere det 3 -aksede digitale magnetometeret, kalt HMC5883L (det kan også lett finnes hvor som helst, så lenge det er mye brukt i ARDUINO -prosjekter), og igjen er kommunikasjonsprotokollen den serielle protokollen I2C. Adressen er 0b0011110X og X brukes til å kalle (indikerer) en lesing eller en skriveoperasjon (0 indikerer en skriveoperasjon og 1 angir en leseoperasjon), så når du vil lese sensoren, bruk bare adressen som 0x3D og når som helst du vil skrive, bare bruk adressen som 0x3C.

I dette tilfellet, for å få HMC5883L initialisert, var det nødvendig å konfigurere tre registre, konfigurasjonsregisteret A - adresse 0x00 (for å konfigurere datautgangshastigheten og målemodus), konfigurasjonsregisteret B - adressen 0x01 (for å konfigurere sensorens forsterkning) og sist men ikke minst modusregisteret - adresse 0x02 (for å konfigurere enhetens driftsmodus).

Så, etter riktig konfigurering av HMC5883L, er det nå mulig å lese den. Den ønskede informasjonen finner sted mellom registeret 0x03 og registeret 0x08, hver akseverdi er sammensatt av to byte som er kodet på 2s komplement måte, noe som betyr at lesedataene må konverteres for å være meningsfulle (disse tingene vil være diskutert senere). Spesielt for denne sensoren skal du lese all informasjonen samtidig, ellers fungerer det kanskje ikke som foreslått, så lenge utdataene bare skrives til disse registrene når alle registrene ble skrevet. så sørg for å lese dem alle.

Til slutt ble det digitale barometeret, en annen I2C -protokolsensor, studert, også kalt BMP280 (det kan også lett finnes hvor som helst, så lenge det er mye brukt i ARDUINO -prosjekter). Adressen er b01110110X også X brukes til å ringe (indikerer) en lesing eller en skriveoperasjon (0 indikerer en skriveoperasjon og 1 indikerer en leseoperasjon), så når du vil lese sensoren, bruk bare adressen som 0XEA og når som helst du vil skrive, bare bruk adressen som 0XEB. Men for denne sensoren kan I2C -adressen endres ved å endre spenningsnivået på SDO -pinnen, så hvis du bruker GND til denne pinnen, blir adressen b01110110X, og hvis du bruker VCC på denne pinnen, går adressen for å være b01110111X, også for å aktivere I2C -modulen i denne sensoren må du bruke et VCC -nivå på sensorens CSB -pin, ellers fungerer det ikke som det skal.

For BMP280 skulle bare to registre konfigureres for å få det til å fungere, ctrl_meas -registeret - adressen 0XF4 (for å angi datainnsamlingsalternativene) og konfigureringsregistret - adressen 0XF5 (for å sette hastigheten, filteret og grensesnittalternativene for sensoren).

Etter å ha blitt ferdig med konfigurasjonsmaterialet, er det på tide med det som virkelig betyr noe, selve dataene, i dette tilfellet finner ønsket informasjon sted mellom registerene 0XF7 og 0XFC. Både temperaturen og trykkverdien er sammensatt av tre byte som er kodet på 2s komplement -måte, noe som betyr at lesedataene må konverteres for å være meningsfulle (disse tingene vil bli diskutert senere). Også for denne sensoren, for å få en høyere presisjon, er det flere korreksjonskoeffisienter som kan brukes under konvertering av dataene, de er plassert mellom registrene 0X88 og 0XA1, ja det er 26 byte korreksjonskoeffisienter, så hvis presisjon er ikke så viktig, bare glem dem, ellers er det ingen annen måte.

Og sist men ikke minst GPS - Tyco A1035D, denne er avhengig av UART seriell protokoll, spesielt med en hastighet på 4800 kbps, ingen paritetsbiter, 8 databiter og 1 stoppbit. UART, eller Universal Asynchronous Receiver/Transmitter, er en seriell protokoll der synkroniseringen av informasjonen utføres via programvare, hvorfor det er en asynkron protokoll, også på grunn av denne egenskapen, er hastigheten der informasjonen overføres og mottas, mye mindre. Spesielt for denne protokollen må pakkene begynne med en startbit, men stoppbiten er valgfri og størrelsen på pakkene er 8 bits lange.

Når det gjelder GPS - Tyco A1035D, var det nødvendig med to konfigurasjoner, det var setDGPSport (kommando 102) og Query/RateControl (kommando 103), all denne informasjonen, pluss flere alternativer er tilgjengelige i NMEA -referansehåndboken, protokollen brukes i de fleste GPS -moduler. Kommandoen 102 brukes til å angi overføringshastigheten, mengden databiter og eksistensen av paritetsbiter og stoppbiter eller ikke. Kommandoen 103 brukes til å kontrollere produksjonen av standard NMEA -meldinger GGA, GLL, GSA, GSV, RMC og VTG, de er beskrevet med detaljer i referansehåndboken, men i vårt tilfelle var den valgte GGA som står for Global Posisjonering av systemets faste data.

Når GPS - TycoA1035D er riktig konfigurert, er det bare nødvendig å lese serieporten og filtrere strengen som mottas i henhold til de valgte parameterne, for å tillate behandling av informasjonen.

Etter å ha lært all nødvendig informasjon om alle sensorene, tok det bare litt ekstra innsats for å sette alt sammen i det samme programmet, også ved å bruke de serielle kommunikasjonsbibliotekene.

Trinn 3: Telemetrisystemet

Dette systemet er ansvarlig for å etablere kommunikasjonen mellom bakkekontrollen og CanSat, i tillegg til prosjektparametrene, var det også begrenset på flere måter, så lenge RF -overføringen bare er tillatt i noen frekvensbånd, som ikke er opptatt pga. andre RF -tjenester, for eksempel mobiltjenester. Disse begrensningene er forskjellige og kan endres fra land til land, så det er viktig å alltid sjekke de tillatte frekvensbåndene for vanlig bruk.

Det er mange alternativer for radioer tilgjengelig på markedet til rimelige priser. Alle disse systemene tilbyr forskjellige måter å modulere på forskjellige frekvenser. For dette systemet besto vårt valg av en 2,4 GHz RF -mottaker, NRF24L01+, på grunn av det faktum at den allerede hadde en veletablert kommunikasjonsprotokoll, så lenge verifikasjonssystemer som automatisk bekreftelse og automatiske re-overføringssystemer. Videre kan overføringshastigheten nå hastigheter på opptil 2 Mbps ved et rimelig strømforbruk.

Så før vi jobber med denne transceiveren, la oss bli litt mer kjent med NRF24L01+. Som nevnt før er det en 2,4 GHz basert radio, som kan konfigureres som mottaker eller sender. For å etablere kommunikasjonen får hver transceiver en adresse som kan konfigureres av brukeren, adressen kan være 24 til 40 bits lang i henhold til dine behov. Datatransaksjonene kan skje på en enkelt eller på en kontinuerlig måte, datastørrelsen er begrenset til 1 byte, og hver transaksjon kan eller ikke generere en bekreftelsesbetingelse i henhold til konfigurasjonene til transceiveren.

Andre flere konfigurasjoner er også mulige, for eksempel gevinsten mot utsignalen til RF-signalet, eksistensen av en automatisk overføringsrutine eller ikke (i så fall kan forsinkelsen, mengden forsøk blant andre egenskaper velges) og flere andre funksjoner som ikke nødvendigvis er nyttige for dette prosjektet, men uansett er de tilgjengelige i databladet til komponenten, i tilfelle det er interesse for dem.

NRF24L01+ 'snakker' SPI -språket når det gjelder seriell kommunikasjon, så når du vil lese eller skrive denne transceiveren, er det bare å bruke SPI -protokollen for den. SPI er en seriell protokoll som nevnt tidligere, der valget av slaver gjøres via en CHIPSELECT (CS) pin, som sammen med full dupleks (både master og slave kan overføre og motta parallelt) karakteristisk av denne protokollen tillater mye høyere hastigheter på datatransaksjon.

Databladet til NRF24L01+ inneholder et sett med kommandoer for å lese eller skrive denne komponenten. Det er forskjellige kommandoer for å få tilgang til de interne registrene, RX og TX nyttelast blant andre operasjoner, så avhengig av ønsket operasjon kan det ta en bestemt kommando for å utføre det. Derfor ville det være interessant å ta en titt på databladet, der det er en liste som inneholder og forklarer alle mulige handlinger over transceiveren (vi kommer ikke til å liste dem her, fordi det ikke er hovedpoenget med denne instruksjonene).

I tillegg til transceiveren, er en annen viktig komponent i dette systemet protokollen som alle ønskede data sendes og mottas gjennom, så lenge systemet skal arbeide med flere byte med informasjon samtidig, er det viktig å kjenne betydningen av hver byte, det er det protokollen fungerer for, den lar systemet identifisere alle dataene mottatt og overført på en organisert måte.

For å holde ting enkelt, besto den brukte protokollen (for senderen) av en overskrift dannet av 3 byte etterfulgt av sensordata, så lenge alle sensordata består av to byte, fikk hver sensordata et identifikasjonsnummer som starter fra 0x01 og følge i en halvmåne rekkefølge, så hver to byte er det en identifikasjonsbyte, på denne måten kunne ikke overskriftssekvensen gjentas tilfeldig i henhold til sensorens avlesninger. Mottakeren endte opp med å være like enkel som senderen, protokollen trengte bare å gjenkjenne overskriften som sendes av senderen, og etter at den bare lagret de mottatte byte, i dette tilfellet bestemte vi oss for å bruke en vektor for å lagre dem.

Så etter å ha oppnådd all nødvendig kunnskap om transceiveren og fastslått kommunikasjonsprotokollen, er det på tide å sette alt sammen i samme kode, og til slutt få ferdig CanSat -fastvaren.

Trinn 4: Strømsystemet

Dette systemet holdes ansvarlig for å forsyne de andre systemene med energien de trenger for å fungere skikkelig, i dette tilfellet bestemte vi oss for å bare bruke et batteri og en spenningsregulator. Så, for batteristørrelsen, ble noen driftsparametere for CanSat analysert, disse parameterne ville hjelpe definisjonen av modellen og kraften som er nødvendig for å mate hele systemet.

Med tanke på at CanSat skal kunne vare flere timer slått på, var det mest hensiktsmessige å vurdere de mest ekstreme situasjonene for strømforbruk, der hver modul og system som er koblet til CanSat ville forbruke høyest mulig strøm. Imidlertid er det også viktig å være rimelig på dette tidspunktet for ikke å overstore batteriet, noe som heller ikke er interessant på grunn av CanSats vektbegrensninger.

Etter å ha konsultert alle databladene til komponentene i alle systemer, var den totale strømforbruket av systemet omtrent 160mAh, med tanke på en autonomi på 10 timer, et 1600mAh batteri var nok for å garantere systemet de riktige arbeidsforholdene.

Etter å ha blitt kjent med den nødvendige ladingen av batteriet, er det ytterligere aspekter å ta hensyn til til tross for autonomien, for eksempel størrelse, vekt, driftstemperatur (så lenge CanSat oppbevares inne i en rakett), spenninger og krefter til som det samme sendes til blant andre.

Trinn 5: Strukturen

Strukturen er virkelig viktig for sikkerheten til CanSat, selv om den ble litt neglisjert i dette prosjektet (faktisk var det ikke så stor interesse for utviklingen av den mekaniske delen av CanSat, på grunn av at alle medlemmers kurs var relatert til elektronikk). Så lenge prosjektet var basert på et eksisterende mønster, var CanSat -mønsteret, det var ikke nødvendig å tenke på hvordan det skulle se ut, så det skulle formes i et sylinderformat, med omtrent 6, 1 cm i diameter og ca., 65 cm høy (de samme målene for en boks brus).

Etter å ha blitt ferdig med den utvendige strukturen, ble oppmerksomheten fokusert på festesystemet, ansvarlig for å holde alle brettene inne i den sylindriske strukturen, noe som også muliggjorde absorpsjon av akselerasjonene som CanSat ville bli utsatt for, etter noen diskusjoner om det, ble det besluttet å feste begge strukturene ved å støpe skum med høy tetthet til de ønskede formene.

Den utvendige strukturen ble konstruert ved bruk av PVC -rør, med ønsket diameter, for å lukke strukturen ble noen PVC -rørdeksler brukt

Trinn 6: Konklusjoner og fremtidige tanker

CanSat må fortsatt testes i aksjon, vi søker faktisk om en rakettkonkurranse (som kommer til å skje i desember), også etter å ha gått gjennom hele bygningen (litt, vi trenger faktisk fortsatt å fullføre noen ting) og utvikling prosess, noen perspektiver og notater som vi trodde det ville være interessant å dele med dere alle ble observert, hovedsakelig om kamper, tips og til og med gode erfaringer, så her går det:

- Starten på prosjektet ble den mest produktive utviklingsperioden for hele prosjektet, dessverre ble gruppen ganske uinteressert i prosjektet innen fristen, kanskje på grunn av mangel på umiddelbare resultater, eller kanskje bare mangel på kommunikasjon, uansett flere gode ting kom ut av prosjektet

- Det krevde mye arbeid for å få transceiveren til å fungere, siden alle bibliotekene ble utviklet fra bunnen av, også fordi det krever to forskjellige programmer og oppsett for å teste slike ting

- I vårt tilfelle var det ikke den beste ideen å jobbe med mikrokontrollere basert på registerkonfigurasjoner, ikke alle medlemmene klarte å holde tritt med resten av gruppen, noe som førte til noen problemer som oppgaveoppdeling. Det er tonnevis med anstendige C -biblioteker for mikrokontrolleren vi brukte, så det hadde vært en mye bedre idé å bruke disse ressursene, det er også en IDE som heter Code Composer, som også tilbyr tonnevis med ressurser for disse mikrokontrollerne

- CanSat trenger fortsatt mange forbedringer, denne erfaringen var basert på grunnleggende teknikker og ferdigheter, og flere saker ble ikke tatt i betraktning, så forhåpentligvis kan en topp versjon av denne CanSat bli virkelighet med mer innsats og hardt arbeid.