CanSat - Nybörjarguide: 6 steg

2024 Författare: John Day | [email protected]. Senast ändrad: 2024-01-30 12:45

Huvudsyftet med dessa instruktioner är att dela utvecklingsprocessen för en CanSat, steg för steg. Men, innan vi börjar, låt oss göra det riktigt klart vad en CanSat är, och vad är dess huvudsakliga funktioner, även om vi tar tillfället i akt, kommer vi att presentera vårt team. Detta projekt började som ett förlängningsprojekt vid vårt universitet, Universidade Tecnológica Federal do Paraná (UTFPR), campus Cornélio Procópio. Guidad av vår rådgivare utvecklade vi en handlingsplan med avsikt att komma in i CanSats, vilket innebar att studera alla dess aspekter och egenskaper, för att kunna förstå hur det fungerar, vilket i slutändan skulle resultera i byggandet av en CanSat och utvecklingen av denna guide. En CanSat är klassad som en picosatellit, vilket innebär att dess vikt är begränsad till 1 kg, men normalt väger CanSats cirka 350 g, och dess struktur är baserad i en burk läsk, en cylinder på 6, 1 cm i diameter, 11, 65 cm lång. Denna modell presenterades med avsikt att förenkla utvecklingen av en satellit, för att möjliggöra universitets tillgång till denna teknik och uppnå popularitet på grund av tävlingarna som antog detta mönster. I allmänhet är CanSats baserade på 4 strukturer, det vill säga kraftsystemet, avkänningssystemet, telemetrisystemet och huvudsystemet. Så låt oss ta en närmare titt på varje system: - Kraftsystem: detta system ansvarar för att leverera elektrisk energi till de andra, enligt dess behov. Med andra ord, det är tänkt att ge systemen nödvändig spänning och ström, med respekt för dess gränser. Det kan också innehålla skyddskomponenter för att garantera säkerheten och det korrekta beteendet hos de andra systemen. Vanligtvis är det baserat på ett batteri och en spänningsregulatorkrets, men många andra funktioner kan läggas till, till exempel energihanteringstekniker och flera typer av skydd. - Sensing system: detta system består av alla sensorer och enheter som är ansvariga för att samla in nödvändig data. det kan anslutas till huvudsystemet på flera sätt, seriella protokoll, parallella protokoll bland andra, det är därför det är verkligen viktigt att behärska alla dessa tekniker för att kunna bestämma den mest praktiska. I allmänhet är det seriella protokollet de som ofta väljs, på grund av deras mindre antal anslutningar och mångsidighet, de överlägset mest populära är SPI-, I2C- och UART -protokollen. - Telemetrisystem: detta system är ansvarigt för att upprätta den trådlösa kommunikationen mellan CanSat och markkontrollstationen, som inkluderar protokollet för trådlös kommunikation och hårdvara. - Huvudsystem: detta system är ansvarigt för sammankoppling av alla andra system, på ett sätt som det också styr och synkroniserar deras arbetssekvens som en organism.

Steg 1: Huvudsystemet

Av många anledningar har vi valt en ARM® Cortex®-M4F-baserad mikrokontroller, det är en MCU med låg effekt, som erbjuder en mycket högre processorkraft, plus flera funktioner som inte är vanliga i RISK-mikrokontroller, till exempel DSP-funktioner. Dessa egenskaper är intressanta eftersom de möjliggör ökad komplexitet hos funktionerna i CanSat -applikationerna, utan att behöva byta mikrokontroller (naturligtvis även med respekt för dess gränser).

Så länge projektet hade flera ekonomiska begränsningar, skulle den valda mikrokontrollern också vara överkomlig, så efter specifikationerna valde vi ARM® Cortex®-M4F-baserad MCU TM4C123G LaunchPad, det är en startplatta som just passade vårt projekt. Även dokumentationen (datablad och dokumentation om egenskaper som tillhandahålls av tillverkaren) och IDE för MCU var proffs som verkligen borde beaktas, så länge de hjälpte utvecklingsprocessen mycket.

I denna Cansat bestämde vi oss för att hålla det enkelt och bara utveckla det med hjälp av startplattan, men naturligtvis i framtida projekt kommer detta inte att vara ett alternativ, med tanke på att flera funktioner som ingår i startplattan faktiskt inte är nödvändiga för vårt projekt, plus dess format begränsade mycket projektet för strukturen på vår CanSat, så länge måtten på en CanSat är minimala.

Så, efter att ha valt rätt "hjärna" för detta system, var nästa steg utvecklingen av dess programvara, också för att hålla det enkelt bestämde vi oss för att helt enkelt använda ett sekventiellt program som gör följande sekvens med en frekvens av 1Hz:

Sensormätningar> datalagring> dataöverföring

Sensordelen kommer att förklaras senare i avkänningssystemet, liksom dataöverföringen kommer att förklaras i telemetrisystemet. Slutligen var det att lära sig att programmera mikrokontroller, i vårt fall behövde vi lära oss följande funktioner i MCU: n, GPIO: erna, I2C -modulen, UART -modulen och SPI -modulen.

GPIO: erna, eller helt enkelt allmänna in- och utgångar, är portar som kan användas för att utföra flera funktioner, så länge de är korrekt inställda. Med tanke på att vi inte använder några C -bibliotek för GPIO: erna, inte ens för de andra modulerna, skulle vi konfigurera alla nödvändiga register. Av dessa skäl har vi skrivit en grundläggande guide som innehåller exempel och beskrivningar relaterade till registren för modulerna vi använder, som finns tillgängliga nedan.

För att förenkla och organisera koden skapades också flera bibliotek. Så bibliotek skapades för följande ändamål:

- SPI -protokoll

- I2C -protokoll

- UART -protokoll

- NRF24L01+ - transceptor

Dessa bibliotek är också tillgängliga nedan, men kom ihåg att vi har använt Keil uvision 5 IDE, så dessa bibliotek kommer inte att fungera för kodkompositör. Slutligen, efter att ha skapat alla bibliotek och lärt sig alla nödvändiga saker, sattes den slutliga koden ihop, och som du kan föreställa dig är den också tillgänglig nedan.

Steg 2: Sensing System

Detta system består av alla sensorer och enheter som är ansvariga för att samla information om driftsförhållandena för CanSat. I vårt fall har vi valt följande sensorer:

- en 3 -axlig digital accelerometer - MPU6050

- ett 3 -axligt digitalt gyroskop - MPU6050

- en 3 -axlig digital magnetometer - HMC5883L

- en digital barometer - BMP280

- och en GPS - Tyco A1035D

Valen baserades främst på tillgängligheten, vilket innebar att så länge de mekaniska och elektriska (kommunikationsprotokollet, strömförsörjningen etc) var kompatibla med vårt projekt, infördes inga ytterligare parametrar för alternativen, även för att det för vissa sensorer var tillgänglighet antalet alternativ var begränsade. Efter att ha skaffat sensorerna var det dags att sätta dem i arbete.

Så den första som utforskades var den 3 -axliga digitala accelerometern och gyroskopet, kallad MPU6050 (den kan lätt hittas var som helst, så länge den används flitigt i ARDUINO -projekt), dess kommunikation är baserad på I2C -protokollet, ett protokoll där varje slav äger en adress, så att flera enheter kan anslutas parallellt, med tanke på att adressen är 7-bitars lång, kan cirka 127 enheter anslutas till samma seriebuss. Detta kommunikationsprotokoll fungerar på två bussar, en databuss och en klockbuss, så för att utbyta informationen måste befälhavaren skicka 8 cykler med klockor (förresten, informationen måste passa en byte, så länge denna kommunikation är baserad på byte -storleken) antingen i en mottagning eller vid en sändningsoperation. MPU6050: s adress är 0b110100X, och X används för att kalla (indikerar) en läsning eller en skrivoperation (0 indikerar en skrivoperation och 1 indikerar en läsoperation), så när du vill läsa sensorn använder du bara dess adress som 0xD1 och när du vill skriva, använd bara adressen som 0xD0.

Efter att ha undersökt I2C -protokollet studerades faktiskt MPU6050, med andra ord dess datablad lästes, för att få nödvändig information för att få det att fungera, för den här sensorn behövde endast tre register konfigureras, energihanteringen 1 register - adress 0x6B (för att garantera att sensorn inte är i viloläge), gyroskopets konfigurationsregister - adress 0x1B (för att konfigurera hela skalområdet för gyroskopet) och slutligen accelerometerns konfigurationsregister - adress 0x1C (i för att konfigurera hela skalområdet för accelerometern). Det finns flera andra register som kan konfigureras, vilket möjliggör optimering av sensorns prestanda, men för detta projekt räcker dessa konfigurationer.

Så, efter att ha konfigurerat sensorn korrekt, kan du nu läsa den. Den önskade informationen sker mellan registret 0x3B och registret 0x48, varje axelvärde består av två byte som är kodade på 2: s komplement sätt, vilket innebär att läsdata måste konverteras för att vara meningsfulla (dessa saker kommer att vara diskuteras senare).

Efter att ha gjort klart med MPU6050 var det dags att studera den 3 -axliga digitala magnetometern, som heter HMC5883L (den kan också lätt hittas var som helst, så länge den används flitigt i ARDUINO -projekt), och igen är dess kommunikationsprotokoll det seriella protokollet I2C. Dess adress är 0b0011110X och X används för att kalla (indikerar) en läsning eller en skrivoperation (0 indikerar en skrivoperation och 1 indikerar en läsoperation), så när du vill läsa sensorn använder du bara dess adress som 0x3D och när som helst du vill skriva, använd bara adressen som 0x3C.

I det här fallet, för att initiera HMC5883L, krävdes tre register, konfigurationsregistret A - adress 0x00 (för att konfigurera datautmatningshastigheten och mätläget), konfigurationsregistret B - adressen 0x01 (för att konfigurera sensorns förstärkning) och sist men inte minst lägesregistret - adress 0x02 (för att konfigurera enhetens driftsläge).

Så, efter korrekt konfigurering av HMC5883L, är det nu möjligt att läsa den. Den önskade informationen sker mellan registret 0x03 och registret 0x08, varje axelvärde består av två byte som är kodade på 2: s komplement sätt, vilket innebär att läsdata måste konverteras för att vara meningsfulla (dessa saker kommer att vara diskuteras senare). Särskilt för den här sensorn ska du läsa all information på en gång, annars fungerar det kanske inte som föreslaget, så länge utdata bara skrivs till dessa register när alla register skrevs. så se till att läsa dem alla.

Slutligen studerades den digitala barometern, en annan I2C -protokollsensor, även kallad BMP280 (den kan också lätt hittas var som helst, så länge den används flitigt i ARDUINO -projekt). Dess adress är b01110110X också X används för att kalla (indikerar) en läsning eller en skrivoperation (0 indikerar en skrivoperation och 1 indikerar en läsoperation), så när du vill läsa sensorn använder du bara dess adress som 0XEA och när som helst du vill skriva, använd bara adressen som 0XEB. Men för den här sensorn kan I2C -adressen ändras genom att ändra spänningsnivån på SDO -stiftet, så om du applicerar GND på denna pin kommer adressen att vara b01110110X och om du applicerar VCC på denna pin kommer adressen att gå för att vara b01110111X, också för att aktivera I2C -modulen i denna sensor måste du tillämpa en VCC -nivå på sensorns CSB -stift, annars fungerar det inte som det ska.

För BMP280 skulle bara två register konfigureras för att få det att fungera, ctrl_meas -registret - adressen 0XF4 (för att ställa in datainsamlingsalternativen) och konfigurationsregistret - adressen 0XF5 (för att ställa in hastigheten, filtret och gränssnittsalternativen för sensorn).

Efter att ha gjort klart med konfigurationsgrejerna är det dags för det som verkligen är viktigt, själva datan, i detta fall sker den önskade informationen mellan registren 0XF7 och 0XFC. Både temperaturen och tryckvärdet består av tre byte som är kodade på 2: s komplement sätt, vilket innebär att de lästa data måste konverteras för att vara meningsfulla (dessa saker kommer att diskuteras senare). För den här sensorn, för att få en högre precision, finns det flera korrigeringskoefficienter som kan användas vid konvertering av data, de är placerade mellan registren 0X88 och 0XA1, ja det finns 26 byte korrigeringskoefficienter, så om precisionen är inte så mycket viktigt, glöm bara dem, annars finns det inget annat sätt.

Och sist men inte minst GPS - Tyco A1035D, den här förlitar sig på det seriella UART -protokollet, specifikt med en hastighet av 4800 kbps, inga paritetsbitar, 8 databitar och 1 stoppbit. UART, eller Universal Asynchronous Receiver/Transmitter, är ett seriellt protokoll där synkroniseringen av informationen görs via programvara, varför det är ett asynkront protokoll, även på grund av denna egenskap, är hastigheten i vilken informationen överförs och tas emot mycket mindre. Specifikt för detta protokoll måste paketen börja med en startbit, men stoppbiten är valfri och storleken på paketen är 8 bitar lång.

För GPS - Tyco A1035D krävdes två konfigurationer, nämligen setDGPSport (kommando 102) och Query/RateControl (kommando 103), all denna information plus fler alternativ finns tillgängliga i NMEA -referenshandboken, protokollet används i de flesta GPS -moduler. Kommandot 102 används för att ställa in överföringshastigheten, mängden databitar och förekomsten av paritetsbitar och stoppbitar. Kommandot 103 används för att styra utmatningen av standard NMEA -meddelanden GGA, GLL, GSA, GSV, RMC och VTG, de beskrivs med detaljer i referensmanualen, men i vårt fall var den utvalda GGA som står för Global Positioneringssystemets fasta data.

När GPS - TycoA1035D väl är korrekt konfigurerad är det nu bara nödvändigt att läsa serieporten och filtrera strängen som mottagits enligt de valda parametrarna för att möjliggöra behandling av informationen.

Efter att ha lärt mig all nödvändig information om alla sensorer tog det bara lite extra ansträngning för att sätta ihop allt i samma program, även med hjälp av seriekommunikationsbiblioteken.

Steg 3: Telemetrisystemet

Detta system är ansvarigt för att upprätta kommunikationen mellan markkontrollen och CanSat, förutom projektparametrarna var det också begränsat på några fler sätt, så länge RF -överföringen endast är tillåten i vissa frekvensband, som inte är upptagna pga. andra RF -tjänster, till exempel mobiltjänster. Dessa begränsningar är olika och kan ändras från land till land, så det är viktigt att alltid kontrollera de tillåtna frekvensbanden för vanligt bruk.

Det finns många alternativ med radio tillgängliga på marknaden till överkomliga priser, alla dessa system erbjuder olika sätt att modulera vid olika frekvenser, för detta system valde vi att bestå av en 2,4 GHz RF -sändtagare, NRF24L01+, på grund av att det redan hade ett väletablerat kommunikationsprotokoll, så länge verifieringssystem som automatisk kvittering och automatiska överföringssystem. Dessutom kan överföringshastigheten nå upp till 2 Mbps vid en rimlig strömförbrukning.

Så innan vi arbetar med denna sändtagare, låt oss få veta lite mer om NRF24L01+. Som nämnts tidigare är det en 2,4 GHz baserad radio, som kan konfigureras som mottagare eller sändare. För att upprätta kommunikationen får varje sändtagare en adress som kan konfigureras av användaren, adressen kan vara 24 till 40 bitar lång enligt dina behov. Datatransaktionerna kan ske på ett enda eller på ett kontinuerligt sätt, datastorleken är begränsad till 1 byte och varje transaktion kan eventuellt generera ett kvitteringsvillkor i enlighet med konfigurationerna för sändtagaren.

Andra flera konfigurationer är också möjliga, såsom förstärkningen mot utsignalen från RF-signalen, förekomsten av en automatisk omöverföringsrutin eller inte (i så fall kan fördröjningen, mängden försök bland andra egenskaper väljas) och flera andra funktioner som inte nödvändigtvis är användbara för detta projekt, men de är i alla fall tillgängliga i databladet för komponenten, om det finns intresse för dem.

NRF24L01+ "talar" SPI -språket när det gäller seriell kommunikation, så när du vill läsa eller skriva den här transceivern är det bara att fortsätta och använda SPI -protokollet för den. SPI är ett seriellt protokoll som nämnts tidigare, där valet av slavar görs via en CHIPSELECT (CS) pin, som tillsammans med full duplex (både master och slaven kan överföra och ta emot på ett parallellt sätt) karakteristik av detta protokoll tillåter mycket högre hastigheter för datatransaktioner.

Databladet för NRF24L01+ ger en uppsättning kommandon för att läsa eller skriva den här komponenten, det finns olika kommandon för att komma åt de interna registren, RX- och TX -nyttolasten bland andra operationer, så beroende på önskad operation kan det behöva ett specifikt kommando för att utför det. Det är därför det skulle vara intressant att ta en titt på databladet, där det finns en lista som innehåller och förklarar alla möjliga åtgärder över transceivern (vi kommer inte att lista dem här, för det är inte huvudpoängen med dessa instruktioner).

Förutom sändtagaren är en annan viktig komponent i detta system protokollet genom vilket all önskad data skickas och tas emot, så länge systemet är tänkt att arbeta med flera byte med information samtidigt är det viktigt att känna till innebörden av varje byte, det är vad protokollet fungerar för, det gör att systemet på ett organiserat sätt kan identifiera all data som tas emot och överförs.

För att hålla sakerna enkla bestod det använda protokollet (för sändaren) av en rubrik som består av 3 byte följt av sensordata, så länge alla sensordata bestod av två byte fick varje sensordata ett identifieringsnummer som startade från 0x01 och följer i en halvmåneordning, så att varje två byte finns en identifieringsbyte, på så sätt kunde rubriksekvensen inte upprepas av en slump enligt sensorns avläsningar. Mottagaren blev så enkel som sändaren, protokollet behövdes bara för att känna igen rubriken som skickades av sändaren och efter att den bara lagrade de mottagna bytena, i det här fallet bestämde vi oss för att använda en vektor för att lagra dem.

Så efter att ha uppnått all nödvändig kunskap om transceivern och bestämt kommunikationsprotokollet är det dags att sätta ihop allt i samma kod och slutligen få CanSat -firmware att göra.

Steg 4: Power System

Detta system hålls ansvarigt för att ge de andra systemen den energi de behöver för att fungera korrekt, i det här fallet bestämde vi oss för att helt enkelt använda ett batteri och en spänningsregulator. Så, för batteristorleken, analyserades några driftparametrar för CanSat, dessa parametrar skulle hjälpa definitionen av modellen och den effekt som krävs för att mata hela systemet.

Med tanke på att CanSat borde kunna vara påslagen i flera timmar, var det mest lämpliga att överväga de mest extrema energiförbrukningssituationer där varje modul och system som är anslutet till CanSat skulle förbruka högsta möjliga ström. Det är dock också viktigt att vara rimlig vid denna tidpunkt att inte överstora batteriet, vilket inte heller är intressant på grund av CanSats viktbegränsningar.

Efter att ha konsulterat alla datablad för komponenterna i alla system var den totala strömförbrukningen av systemet ungefär 160mAh, med tanke på en autonomi på 10 timmar, ett 1600mAh batteri var tillräckligt för att garantera systemet de rätta arbetsförhållandena.

Efter att ha lärt känna den nödvändiga laddningen av batteriet finns det ytterligare aspekter att tänka på trots autonomin, till exempel storlek, vikt, driftstemperatur (så länge CanSat förvaras i en raket), spänningar och krafter att som samma överlämnas till bl.

Steg 5: Strukturen

Strukturen är verkligen viktig för säkerheten för CanSat, även om den var lite försummad i detta projekt (faktiskt var det inte så stort intresse för utvecklingen av den mekaniska delen av CanSat, på grund av att alla medlemmars kurser var relaterad till elektronik). Så länge projektet var baserat på ett befintligt mönster, var CanSat -mönstret, inte mycket tänkande på hur det skulle se ut nödvändigt, så det borde formas i ett cylinderformat, med cirka 6, 1 cm i diameter och cirka 11, 65 cm lång (samma mått på en burk läsk).

Efter att ha gjort klart med den yttre strukturen var all uppmärksamhet inriktad på infästningssystemet, som ansvarade för att hålla alla brädorna inuti den cylindriska strukturen, vilket också möjliggjorde absorption av accelerationerna som CanSat skulle utsättas för, efter några diskussioner om det, beslutades att fästa båda strukturerna genom att gjuta högdensitetsskum, till önskade former.

Den yttre strukturen konstruerades med hjälp av PVC -rör, med önskad diameter, för att stänga strukturen användes några PVC -rörlock

Steg 6: Slutsatser och framtida tankar

CanSat måste fortfarande testas i aktion, vi ansöker faktiskt om en rakettävling (som kommer att hända i december), även efter att ha gått igenom hela byggnaden (typ, vi behöver faktiskt fortfarande göra klart några saker) och utveckling process, några perspektiv och anteckningar som vi tyckte att det skulle vara intressant att dela med er alla observerades, främst om kamp, tips och till och med bra erfarenheter, så här går det:

- Projektets början kom att bli den mest produktiva utvecklingsperioden för hela projektet, tyvärr blev gruppen ganska ointresserad av projektet vid deadline, kanske på grund av brist på omedelbara resultat, eller kanske bara brist på kommunikation, i alla fall flera bra saker kom ut ur projektet

- Det krävdes mycket ansträngning för att få transceivern att fungera, eftersom alla bibliotek utvecklades från grunden, också för att det krävs två olika program och inställningar för att testa den här typen av saker

- I vårt fall var det inte det bästa av idéerna att arbeta med mikrokontroller baserade på registerkonfigurationer, inte alla medlemmar kunde hänga med i resten av gruppen, vilket ledde till vissa problem som uppgiftsdelning. Det finns massor av anständiga C -bibliotek för mikrokontrollern vi använde, så det hade varit en mycket bättre idé att använda dessa resurser, det finns också en IDE som heter Code Composer, som också erbjuder massor av resurser för dessa mikrokontroller

- CanSat behöver fortfarande massor av förbättringar, denna erfarenhet var baserad på grundläggande tekniker och färdigheter, även flera frågor togs inte i beaktande, så förhoppningsvis kan en förstklassig version av denna CanSat bli verklighet med mer ansträngning och hårt arbete.