Hendelsesstyrt programmering i FTC: 4 trinn

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

I år har teamet vårt jobbet mye med hendelsesdrevet programvareutvikling for roboten vår. Disse programmene har gjort det mulig for teamet å nøyaktig utvikle autonome programmer og til og med repeterbare tele-op-hendelser. Siden programvarearbeidet det krever er komplekst, bestemte vi oss for å dele kunnskapen vi har fått om å utvikle hendelsesdrevet kode for FTC-roboter.

Trinn 1: Hva er hendelsesstyrt programmering?

Generelt sett er hendelsesdrevet programmering, ifølge Techopedia, utviklingen av programmer som reagerer på brukerens innspill. I denne forstand regnes mange programmer som hendelsesdrevne, inkludert et teams tele-op-program, som er avhengig av innspill fra en kontrollert av mennesker for å utføre enhver handling. Når det gjelder arbeidet vårt team har gjort, handler hendelsesdrevet programmering imidlertid om å lage programvare fra forskjellige innganger; med andre ord, vi dokumenterer hendelser basert på inngangene til kontrollere og sensorer, så kan vi stille disse hendelsene i kø og bruke filen til å kjøre den registrerte hendelsen på nytt.

Denne metoden for å utvikle programmer for vår robot har flere fordeler:

• Det lar oss lage nøyaktige autonome programmer. Siden vi lager programvaren i sanntid mens vi gjennomgår hendelsen, vil sensorverdiene samlet og brukt være veldig nøyaktige, ettersom de kommer direkte fra den opprinnelige hendelsen.
• Det lar oss lage autonome programmer raskt. Å lage autonome programmer er like enkelt som å spille inn en serie hendelser og justere hendelsen etter behov.
• Det lar oss lage automatiske prosesser for tele-op. For gjentatte handlinger i tele-op tillater hendelsesdrevet programmering oss å registrere disse handlingene og tilordne hendelsen til en knapp i de førerkontrollerte kampene. Disse automatiserte hendelsene kan påvirkes av sensorer for å muliggjøre nøyaktig utførelse.

Trinn 2: Logisk flyt av hendelsesdrevet programmering

Følgende viser den logiske flyten til et hendelsesdrevet program: rødt viser opprettelsen av en hendelse, og blå viser den som kaller hendelsen. For å lage en hendelse blir en sekvens av innspill tatt inn gjennom robothandling og registrert som hendelser; disse hendelsene skrives til en fil. For å ringe en hendelse leses den filen, og inngangene sendes til en hendelsesprosessor for å gjøre filkoden til robothandling.

Trinn 3: Event Creator

Hendelsesskapere brukes til å dokumentere handlinger eller "hendelser" basert på en rekke sensorer og knapper. Når roboten utfører handlinger på feltet, oppretter en hendelsesskaperklasse hendelser for hver av disse handlingene parallelt, og refererer til hendelsen som er klassifisert i en hendelsesklasse. Etter å ha blitt opprettet, blir hendelsen satt i en kø med hendelser i hendelsesklassen: den første hendelsen tar topplasseringen, deretter tar den andre hendelsen topplasseringen og skyver ned eventuelle hendelser under den, og dette fortsetter til programmet stopper. Når programmet stoppes, går hendelsene ut til en fil som kan leses av mennesker, for eksempel en JSON-fil. Denne filen kan brukes til å bedre autonome rutiner.

Eksempelkoden ovenfor setter opp parametrene for hendelsen, som i dette tilfellet er en sving ved hjelp av en IMU -sensor. Vi legger deretter hendelsen i kø i hendelseskøen. Til slutt avkorter vi hendelsen, som i hovedsak tilbakestiller hendelsen slik at vi kan bruke den til å stille fremtidige hendelser i kø.

Trinn 4: Hendelsesprosessor

Arrangementsklasser tar den menneskelesbare filen som er produsert i hendelsesskaperklassen, og gjør hva hver hendelse i kø forteller den å gjøre ved å ringe til metoder som er beskrevet i en hendelsesprosessorklasse. Hendelsesprosessorklassen forteller deretter roboten hvilken hendelse den skal spille på nytt. Enten det er en enkel "drive forward" -hendelse eller en kompleks hendelse full av avstander, svinger og straffer, vil prosessoren spille av alle hendelser som er gitt den. Denne prosessen er veldig nyttig under autonome, siden et team kan registrere sensorer og Tele-Op-handlinger før de matcher, og deretter bare spille av hendelsene på nytt i autonome. Denne prosessen kalles Memory Replay. Dette gjør at et autonomt program kan konfigureres 100% gjennom en enkelt fil. Når eventskaperen og prosessoren er etablert, kan et team ganske enkelt endre ut autonome rutiner gjennom den lesbare filen.

Eksemplet ovenfor starter først med å sjekke JSON -filen for en hendelse, og deretter kontrollere den hendelsen ved hjelp av en saksuttalelse for å se hva slags hendelse det er, i dette tilfellet en sving ved hjelp av en IMU -sensor. Når den kan fortelle at det er en sving som bruker IMU -hendelsen, behandler den deretter behandlingen av hendelsen, som vanligvis innebærer å kjøre koden som hendelsen kom fra ved å bruke variabler fra hendelsen, sendt inn for å replikere hendelsen som ble gjort før.