CanSat - Begynderguide: 6 trin

2024 Forfatter: John Day | [email protected]. Sidst ændret: 2024-01-30 08:28

Hovedformålet med disse instruktører er at dele udviklingsprocessen for en CanSat, trin for trin. Men før vi starter, lad os gøre det virkelig klart, hvad en CanSat er, og hvad er dens vigtigste funktioner, og også benytte lejligheden, vil vi introducere vores team. Dette projekt startede som et udvidelsesprojekt på vores universitet, Universidade Tecnológica Federal do Paraná (UTFPR), campus Cornélio Procópio. Guidet af vores rådgiver udviklede vi en handlingsplan med det formål at komme ind på CanSats, hvilket betød at studere alle dens aspekter og egenskaber for at kunne forstå, hvordan det fungerer, hvilket i sidste ende ville resultere i konstruktion af en CanSat, og udviklingen af denne vejledning. En CanSat er klassificeret som en picosatellit, hvilket betyder, at dens vægt er begrænset til 1 kg, men normalt vejer CanSats cirka 350 g, og dens struktur er baseret på en dåse sodavand, en cylinder på 6, 1 cm i diameter, 11, 65 cm høj. Denne model blev præsenteret med den hensigt at forenkle udviklingen af en satellit for at gøre det muligt for universiteter at få adgang til disse teknologier og opnå popularitet på grund af de konkurrencer, der vedtog dette mønster. Generelt er CanSats baseret på 4 strukturer, det vil sige elsystemet, sensingsystemet, telemetrisystemet og hovedsystemet. Så lad os se nærmere på hvert system: - Strømsystem: Dette system er ansvarligt for at levere den elektriske energi til de andre i henhold til dets behov. Med andre ord skal det levere systemerne den nødvendige spænding og strøm under overholdelse af dets grænser. Det kan også indeholde beskyttelseskomponenter for at garantere sikkerheden og den korrekte adfærd for de andre systemer. Almindeligvis er det baseret på et batteri og et spændingsregulator kredsløb, men mange andre funktioner kan tilføjes, såsom strømstyringsteknikker og flere former for beskyttelse. - Sensing system: dette system består af alle de sensorer og enheder, der er ansvarlige for at indsamle de nødvendige data. det kan forbindes til hovedsystemet på flere måder, serielle protokoller, parallelle protokoller blandt andre, derfor er det virkelig vigtigt at mestre alle disse teknikker for at kunne bestemme den mest bekvemme. Generelt er den serielle protokol dem, der ofte vælges på grund af deres mindre antal forbindelser og alsidighed, langt de mest populære er SPI-, I2C- og UART -protokollerne. - Telemetrisystem: Dette system er ansvarligt for at etablere den trådløse kommunikation mellem CanSat og jordkontrolstationen, som inkluderer den trådløse kommunikationsprotokol og hardware. - Hovedsystem: Dette system er ansvarligt for at forbinde alle de andre systemer på en måde, som det også styrer og synkroniserer deres driftssekvens som en organisme.

Trin 1: Hovedsystemet

Af mange grunde har vi valgt en ARM® Cortex®-M4F baseret mikrocontroller, det er en MCU med lav effekt, der giver en meget højere processorkraft plus flere funktioner, der ikke almindeligvis ses i RISK-mikrokontrollere, f.eks. DSP-funktioner. Disse egenskaber er interessante, fordi de muliggør en stigning i kompleksiteten af funktionerne i CanSat -applikationerne, uden at det er nødvendigt at ændre mikrokontrolleren (selvfølgelig også med respekt for dens grænser).

Så længe projektet havde flere økonomiske begrænsninger, skulle den valgte mikrokontroller også være overkommelig, så efter specifikationerne endte vi med at vælge ARM® Cortex®-M4F Baseret MCU TM4C123G LaunchPad, det er en startplade, der lige passede til vores projekt. Også dokumentationen (datablade og egenskabsdokumentation leveret af fabrikanten) og IDE for MCU var fordele, der virkelig skulle overvejes, så længe de hjalp udviklingsprocessen meget.

I denne Cansat besluttede vi at holde det enkelt og bare udvikle det ved hjælp af startpladen, men selvfølgelig i fremtidige projekter vil dette ikke være en mulighed, i betragtning af at flere funktioner, der er inkluderet i startpladen, faktisk ikke er nødvendige for vores projekt, plus dets format begrænsede meget projektet med strukturen i vores CanSat, så længe dimensionerne på en CanSat er minimale.

Så efter at have valgt den rigtige 'hjerne' til dette system, var det næste trin udvikling af dens software, også for at holde det enkelt besluttede vi simpelthen at bruge et sekventielt program, der udfører følgende sekvens med en frekvens på 1Hz:

Sensormålinger> datalagring> dataoverførsel

Sensordelen forklares senere i sensingsystemet, ligesom dataoverførslen forklares i telemetrisystemet. Endelig var det at lære at programmere mikrokontrolleren, i vores tilfælde havde vi brug for at lære følgende funktioner i MCU'en, GPIO'erne, I2C -modulet, UART -modulet og SPI -modulet.

GPIO'erne, eller simpelthen generelle input og output, er porte, der kan bruges til at udføre flere funktioner, så længe de er indstillet korrekt. I betragtning af at vi ikke bruger nogen C -biblioteker til GPIO'erne, ikke engang til de andre moduler, skulle vi konfigurere alle de nødvendige registre. Af denne grund har vi skrevet en grundlæggende vejledning med eksempler og beskrivelser relateret til registre over de moduler, vi bruger, som er tilgængelige nedenfor.

For at forenkle og organisere koden blev der også oprettet flere biblioteker. Så biblioteker blev oprettet til følgende formål:

- SPI -protokol

- I2C -protokol

- UART -protokol

- NRF24L01+ - transceptor

Disse biblioteker er også tilgængelige nedenfor, men husk, at vi har brugt Keil uvision 5 IDE, så disse biblioteker fungerer ikke for kodekomponist. Endelig, efter at have oprettet alle bibliotekerne og lært alle de nødvendige ting, blev den sidste kode sat sammen, og som du måske forestiller dig, er den også tilgængelig nedenfor.

Trin 2: Sensing System

Dette system består af alle de sensorer og enheder, der er ansvarlige for at indsamle oplysninger om driftsbetingelserne for CanSat. I vores tilfælde har vi valgt følgende sensorer:

- et 3 -akset digitalt accelerometer - MPU6050

- et 3 -akset digitalt gyroskop - MPU6050

- et 3 -akset digitalt magnetometer - HMC5883L

- et digitalt barometer - BMP280

- og en GPS - Tyco A1035D

Valgene var hovedsageligt baseret på tilgængeligheden, hvilket betød, at så længe de mekaniske og elektriske (kommunikationsprotokol, strømforsyning osv.) Var kompatible med vores projekt, blev der ikke pålagt yderligere parametre for valgene, også fordi tilgængeligheden for nogle sensorer var tilgængelig mulighederne var begrænsede. Efter at have erhvervet sensorerne var det tid til at sætte dem i gang.

Så den første, der blev undersøgt, var det 3 -aksede digitale accelerometer og gyroskop, kaldet MPU6050 (det kan let findes overalt, så længe det bruges i vid udstrækning i ARDUINO -projekter), dets kommunikation er baseret på I2C -protokollen, en protokol, hvor hver slave ejer en adresse, der gør det muligt at tilslutte flere enheder parallelt, da adressen er 7-bit lang, kan omkring 127 enheder tilsluttes på den samme serielle bus. Denne kommunikationsprotokol fungerer på to busser, en databus og en urbus, så for at udveksle oplysningerne skal masteren sende 8 cyklusser med ur (i øvrigt skal oplysningerne passe til en byte, så længe denne kommunikation er baseret på byte -størrelsen) enten i en modtagelse eller i en transmissionsoperation. MPU6050s adresse er 0b110100X, og X bruges til at kalde (angiver) en læsning eller en skriveoperation (0 angiver en skriveoperation og 1 angiver en læseoperation), så når du vil læse sensoren, skal du bare bruge dens adresse som 0xD1 og når du vil skrive, skal du bare bruge dens adresse som 0xD0.

Efter at have undersøgt I2C -protokollen blev MPU6050 faktisk undersøgt, med andre ord dets datablad blev læst for at få de nødvendige oplysninger til at få det til at fungere, for denne sensor skulle kun tre registre konfigureres, strømstyringen 1 register - adresse 0x6B (for at sikre, at sensoren ikke er i dvaletilstand), gyroskopets konfigurationsregister - adresse 0x1B (for at konfigurere hele skalaområdet for gyroskopet) og endelig accelerometerets konfigurationsregister - adresse 0x1C (i for at konfigurere hele skalaområdet for accelerometeret). Der er flere andre registre, der kan konfigureres, hvilket muliggør optimering af sensorens ydeevne, men til dette projekt er disse konfigurationer nok.

Så efter korrekt konfiguration af sensoren er du nu i stand til at læse den. Den ønskede information finder sted mellem registret 0x3B og registret 0x48, hver akseværdi er sammensat af to bytes, der er kodet på 2's komplement måde, hvilket betyder, at de læste data skal konverteres for at være meningsfulde (disse ting vil være diskuteret senere).

Efter at være blevet færdig med MPU6050, var det tid til at få undersøgt det 3 -aksede digitale magnetometer, navngivet HMC5883L (det kan også let findes overalt, så længe det er flittigt brugt i ARDUINO -projekter), og igen er dets kommunikationsprotokol den serielle protokol I2C. Dens adresse er 0b0011110X, og X bruges til at kalde (angiver) en læsning eller en skriveoperation (0 angiver en skriveoperation og 1 angiver en læseoperation), så når du vil læse sensoren, skal du bare bruge dens adresse som 0x3D og når som helst du vil skrive, bare brug dens adresse som 0x3C.

I dette tilfælde var det nødvendigt at konfigurere tre registre for at få HMC5883L initialiseret, konfigurationsregistret A - adresse 0x00 (for at konfigurere dataudgangshastigheden og målingstilstand), konfigurationsregistret B - adresse 0x01 (for at konfigurere sensorens forstærkning) og sidst men ikke mindst tilstandsregistret - adresse 0x02 (for at konfigurere enhedens driftstilstand).

Så efter korrekt konfiguration af HMC5883L er det nu muligt at læse det. Den ønskede information finder sted mellem registret 0x03 og registret 0x08, hver akseværdi er sammensat af to bytes, der er kodet på 2's komplement måde, hvilket betyder, at de læste data skal konverteres for at være meningsfulde (disse ting vil være diskuteret senere). Især for denne sensor skal du læse alle oplysninger på én gang, ellers fungerer det muligvis ikke som foreslået, så længe outputdata kun skrives til disse registre, når alle registre blev skrevet. så sørg for at læse dem alle.

Endelig blev det digitale barometer, en anden I2C -protokolsensor, undersøgt, også kaldet BMP280 (det kan også let findes overalt, så længe det bruges i vid udstrækning i ARDUINO -projekter). Dens adresse er b01110110X også X bruges til at kalde (angiver) en læsning eller en skriveoperation (0 angiver en skriveoperation og 1 angiver en læseoperation), så når du vil læse sensoren, skal du bare bruge dens adresse som 0XEA og når som helst du vil skrive, bare brug dens adresse som 0XEB. Men i tilfælde af denne sensor kan I2C -adressen ændres ved at ændre spændingsniveauet på SDO -stiften, så hvis du anvender GND til denne pin, vil adressen være b01110110X, og hvis du anvender VCC på denne pin, går adressen for at være b01110111X, også for at aktivere I2C -modulet i denne sensor skal du anvende et VCC -niveau på sensorens CSB -pin, ellers fungerer det ikke korrekt.

For BMP280 skulle kun to registre konfigureres for at få det til at fungere, ctrl_meas -registret - adresse 0XF4 (for at indstille mulighederne for dataindsamling) og konfigurationsregistret - adresse 0XF5 (for at indstille hastigheden, filteret og grænsefladeindstillingerne for sensoren).

Efter at være færdig med konfigurationsmaterialet, er det tid til det, der virkelig betyder noget, selve dataene, i dette tilfælde finder den ønskede information sted mellem registrene 0XF7 og 0XFC. Både temperaturen og trykværdien er sammensat af tre bytes, der er kodet på 2's komplement måde, hvilket betyder, at de læste data skal konverteres for at være meningsfulde (disse ting vil blive diskuteret senere). Også for denne sensor, for at få en højere præcision, er der flere korrektionskoefficienter, der kan bruges under konvertering af dataene, de er placeret mellem registrene 0X88 og 0XA1, ja der er 26 bytes korrektionskoefficienter, så hvis præcision er ikke så meget vigtigt, bare glem dem, ellers er der ingen anden måde.

Og sidst men ikke mindst GPS - Tyco A1035D, denne er afhængig af UART seriel protokol, specifikt med en hastighed på 4800 kbps, ingen paritetsbits, 8 databit og 1 stopbit. UART eller Universal Asynchronous Receiver/Transmitter, er en seriel protokol, hvor synkroniseringen af oplysningerne udføres via software, hvorfor det er en asynkron protokol, også på grund af denne egenskab, er hastigheden, hvormed informationen transmitteres og modtages, meget mindre. Specielt for denne protokol skal pakkerne begynde med en startbit, men stopbitten er valgfri, og størrelsen af pakkerne er 8 bit lange.

I tilfælde af GPS - Tyco A1035D var to konfigurationer påkrævet, det var setDGPSport (kommando 102) og Query/RateControl (kommando 103), alle disse oplysninger plus flere muligheder er tilgængelige i NMEA referencehåndbogen, protokollen bruges i de fleste GPS's moduler. Kommandoen 102 bruges til at indstille baudhastighed, mængden af databit og eksistensen af paritetsbit og stopbit. Kommandoen 103 bruges til at styre output fra standard NMEA -meddelelser GGA, GLL, GSA, GSV, RMC og VTG, de er beskrevet med detaljer i referencehåndbogen, men i vores tilfælde var den valgte GGA, der står for Global Positioneringssystemets faste data.

Når GPS - TycoA1035D er korrekt konfigureret, er det nu kun nødvendigt at læse den serielle port og filtrere den modtagne streng i henhold til de valgte parametre for at tillade behandling af oplysningerne.

Efter at have lært alle de nødvendige oplysninger om alle sensorerne krævede det kun en ekstra indsats for at sætte alt sammen i det samme program, også ved hjælp af de serielle kommunikationsbiblioteker.

Trin 3: Telemetrisystemet

Dette system er ansvarligt for at etablere kommunikationen mellem jordkontrollen og CanSat, udover projektparametrene, var det også begrænset på nogle flere måder, så længe RF -transmissionen kun er tilladt i nogle frekvensbånd, der ikke er optaget pga. andre RF -tjenester, såsom mobiltjenester. Disse begrænsninger er forskellige og kan ændre sig fra land til land, så det er vigtigt altid at kontrollere de tilladte frekvensbånd til almindelig brug.

Der er mange muligheder for radioer til rådighed på markedet til overkommelige priser, alle disse systemer tilbyder forskellige måder at modulere på forskellige frekvenser, for dette system bestod vores valg i en 2,4 GHz RF -transceiver, NRF24L01+, på grund af det faktum, at det allerede havde en veletableret kommunikationsprotokol, så længe verifikationssystemer såsom automatisk kvittering og automatisk re-transmission systemer. Desuden kunne transmissionshastigheden nå op til 2 Mbps ved et rimeligt strømforbrug.

Så før vi arbejder på denne transceiver, lad os lære lidt mere at vide om NRF24L01+. Som nævnt før er det en 2,4 GHz baseret radio, der kan konfigureres som modtager eller sender. For at etablere kommunikationen får hver transceiver en adresse, der kan konfigureres af brugeren, adressen kan være 24 til 40 bit lang i henhold til dine behov. Datatransaktionerne kan ske på en enkelt eller på en kontinuerlig måde, datastørrelsen er begrænset til 1 byte, og hver transaktion kan muligvis ikke generere en bekræftelsesbetingelse i henhold til transceiverens konfigurationer.

Andre flere konfigurationer er også mulige, f.eks. Forstærkningen mod output af RF-signalet, eksistensen af en automatisk genoverførselsrutine eller ej (i så fald kan forsinkelsen, mængden af forsøg blandt andre egenskaber vælges) og flere andre funktioner, der ikke nødvendigvis er nyttige til dette projekt, men under alle omstændigheder er de tilgængelige i databladet for komponenten, hvis der er interesse for dem.

NRF24L01+ 'taler' SPI -sproget, når det kommer til seriel kommunikation, så når du vil læse eller skrive denne transceiver, skal du bare gå videre og bruge SPI -protokollen til det. SPI'en er en seriel protokol som tidligere nævnt, hvor valget af slaverne foretages via en CHIPSELECT (CS) pin, der sammen med fuld duplex (både master og slave kan transmittere og modtage parallelt) karakteristik af denne protokol tillader meget højere hastigheder for datatransaktion.

Databladet til NRF24L01+ indeholder et sæt kommandoer til at læse eller skrive denne komponent, der er forskellige kommandoer for at få adgang til de interne registre, RX- og TX -nyttelasten blandt andre operationer, så afhængigt af den ønskede operation kan det tage en bestemt kommando til udføre det. Derfor ville det være interessant at tage et kig på databladet, hvor der er en liste, der indeholder og forklarer alle de mulige handlinger over transceiveren (vi vil ikke liste dem lige her, for det er ikke hovedpunktet i denne instruks).

Udover transceiveren er en anden vigtig komponent i dette system protokollen, hvorigennem alle de ønskede data sendes og modtages, så længe systemet formodes at arbejde med flere byte information samtidigt, er det vigtigt at kende betydningen af hver byte, det er det, protokollen fungerer for, det giver systemet mulighed for på en organiseret måde at identificere alle de modtagne og transmitterede data.

For at holde tingene enkle bestod den anvendte protokol (til senderen) af et header dannet af 3 bytes efterfulgt af sensordata, så længe alle sensordata bestod af to bytes, fik hver sensordata et identifikationsnummer, der startede fra 0x01 og følger i en halvmåne rækkefølge, så hver to byte er der en identifikationsbyte, på den måde kunne header -sekvensen ikke tilfældigt gentages i henhold til sensorens aflæsninger. Modtageren endte med at være lige så enkel som senderen, protokollen skulle bare genkende overskriften sendt af senderen, og efter at den bare havde gemt de modtagne bytes, besluttede vi i dette tilfælde at bruge en vektor til at gemme dem.

Så efter at have opnået al den nødvendige viden om transceiveren og fastlagt kommunikationsprotokollen, er det tid til at sætte alt sammen i det samme stykke kode og endelig få CanSat -firmwaren udført.

Trin 4: Strømsystemet

Dette system holdes ansvarligt for at levere de andre systemer den energi, de har brug for for at fungere korrekt, i dette tilfælde besluttede vi simpelthen at bruge et batteri og en spændingsregulator. Så for batteristørrelsen blev nogle driftsparametre i CanSat analyseret, disse parametre ville hjælpe med at definere modellen og den nødvendige effekt til at fodre hele systemet.

I betragtning af at CanSat skulle være i stand til at vare flere timer tændt, var den mest hensigtsmæssige ting at overveje de mest ekstreme situationer med strømforbrug, hvor hvert modul og system tilsluttet CanSat ville forbruge den højest mulige strøm. Det er imidlertid også vigtigt at være fornuftig på dette tidspunkt ikke at overstore batteriet, hvilket heller ikke er interessant på grund af CanSats vægtbegrænsninger.

Efter at have konsulteret alle databladene for komponenterne i alle systemer, var den samlede strømforbrug, som systemet forbruger, cirka 160mAh groft set i betragtning af en autonomi på 10 timer, et 1600mAh batteri var nok til at garantere systemet de korrekte arbejdsforhold.

Efter at have lært den nødvendige opladning af batteriet at kende, er der yderligere aspekter at overveje på trods af autonomien, såsom størrelse, vægt, driftstemperatur (så længe CanSat opbevares inde i en raket), spændinger og kræfter til at som det samme indsendes til bl.a.

Trin 5: Strukturen

Strukturen er virkelig vigtig for sikkerheden ved CanSat, selvom den blev lidt forsømt i dette projekt (faktisk var der ikke meget interesse i udviklingen af den mekaniske del af CanSat, fordi alle medlemmer kurser var relateret til elektronik). Så længe projektet var baseret på et eksisterende mønster, var CanSat -mønsteret, det var ikke nødvendigt at tænke meget over, hvordan det skulle se ud, så det skulle formes i et cylinderformat med ca. 6, 1 cm i diameter og omkring 11, 65 cm høj (de samme mål for en dåse sodavand).

Efter at være færdig med den udvendige struktur, var opmærksomheden alle fokuseret på fastgørelsessystemet, der var ansvarlig for at holde alle brædderne inde i den cylindriske struktur, hvilket også muliggjorde absorption af accelerationer, som CanSat ville blive udsat for, efter nogle diskussioner om det, blev det besluttet at fastgøre begge strukturer ved at støbe højdensitetsskum til de ønskede former.

Den udvendige struktur blev konstrueret ved hjælp af PVC -rør med den ønskede diameter, for at lukke strukturen blev der brugt nogle PVC -rørdæksler

Trin 6: Konklusioner og fremtidige tanker

CanSat mangler stadig at blive testet i aktion, vi ansøger faktisk om en raketkonkurrence (som vil ske i december), også efter at have gennemgået hele bygningen (lidt, vi mangler faktisk stadig at afslutte nogle ting) og udvikling proces, nogle perspektiver og noter, som vi syntes, det ville være interessant at dele med jer alle, blev observeret, hovedsageligt om kampe, tips og endda gode oplevelser, så her går det:

- Starten på projektet blev den mest produktive periode med udviklingen af hele projektet, desværre blev gruppen lidt uinteresseret i projektet ved sin deadline, måske på grund af mangel på umiddelbare resultater eller måske bare mangel på kommunikation, alligevel flere gode ting kom ud af projektet

- Det krævede en stor indsats at få transceiveren til at fungere, da alle bibliotekerne blev udviklet fra bunden, også fordi det kræver to forskellige programmer og opsætninger at teste den slags

- I vores tilfælde var det ikke den bedste idé at arbejde med mikrocontrollere baseret på registret konfigurationer, ikke alle medlemmer var i stand til at følge med resten af gruppen, hvilket førte til nogle problemer som opgaver. Der er masser af anstændige C -biblioteker til den mikrocontroller, vi brugte, så det ville have været en meget bedre idé at bruge disse ressourcer, der er også en IDE kaldet Code Composer, der også tilbyder masser af ressourcer til disse mikrokontroller

- CanSat har stadig brug for masser af forbedringer, denne erfaring var baseret på grundlæggende teknikker og færdigheder, også blev der ikke taget flere spørgsmål i betragtning, så i fremtiden forhåbentlig kan en top version af denne CanSat blive til virkelighed med mere indsats og hårdt arbejde.