Event-driven programmering i FTC: 4 trin

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

I år har vores team udført et stort arbejde med event-drevet softwareudvikling til vores robot. Disse programmer har givet teamet mulighed for nøjagtigt at udvikle autonome programmer og endda gentagelige tele-op-begivenheder. Da softwarearbejdet, det kræver, er komplekst, besluttede vi at dele den viden, vi har fået om at udvikle hændelsesdrevet kode til FTC-robotter.

Trin 1: Hvad er hændelsesstyret programmering?

Generelt er hændelsesdrevet programmering ifølge Techopedia udviklingen af programmer, der reagerer på brugerens input. I denne forstand betragtes mange programmer som hændelsesdrevne, herunder et teams tele-op-program, der er afhængigt af input fra en controller, der drives af mennesker, for at udføre enhver handling. Med hensyn til det arbejde, som vores team har udført, handler hændelsesstyret programmering om at skabe software fra forskellige input; med andre ord, vi dokumenterer hændelser baseret på input fra controllere og sensorer, så kan vi stille disse hændelser i kø og bruge filen til at genudsende den registrerede hændelse.

Denne metode til at udvikle programmer til vores robot har flere fordele:

• Det giver os mulighed for at oprette nøjagtige autonome programmer. Da vi skaber softwaren i realtid, mens vi gennemgår begivenheden, vil sensorværdierne indsamlet og brugt være meget nøjagtige, da de kommer direkte fra den originale begivenhed.
• Det giver os mulighed for hurtigt at oprette autonome programmer. At lave autonome programmer er lige så enkelt som at optage en række begivenheder og justere begivenheden efter behov.
• Det giver os mulighed for at oprette automatiske processer til tele-op. Ved gentagne handlinger i tele-op giver hændelsesdrevet programmering mulighed for at registrere disse handlinger og tildele begivenheden til en knap i løbet af de førerkontrollerede perioder med kampe. Disse automatiserede hændelser kan påvirkes af sensorer for at muliggøre deres nøjagtige udførelse.

Trin 2: Logisk flow af hændelsesdrevet programmering

Følgende viser den logiske strøm af et hændelsesdrevet program: rødt viser oprettelsen af en begivenhed, og blå viser hændelsens kald. Til oprettelse af en hændelse optages en sekvens af input via robotaktion og registreres som hændelser; disse hændelser skrives til en fil. For at kalde en begivenhed læses den fil, og input sendes til en hændelsesprocessor for at omdanne filkoden til robothandling.

Trin 3: Event Creator

Begivenhedsskabere bruges til at dokumentere handlinger eller "begivenheder" baseret på en række sensorer og knapper. Da robotten udfører handlinger på feltet, opretter en hændelsesskaberklasse hændelser for hver enkelt af disse handlinger parallelt og refererer til hændelsen, der er klassificeret i en hændelsesklasse. Efter oprettelsen sættes begivenheden i en kø af begivenheder i begivenhedsklassen: den første begivenhed indtager den øverste plads, derefter tager den anden begivenhed den øverste plads og skubber eventuelle begivenheder under den, og dette fortsætter, indtil programmet stopper. Når programmet stoppes, går hændelserne ud til en fil, der kan læses af mennesker, f.eks. En JSON-fil. Denne fil kan bruges til bedre at forbedre autonome rutiner.

Eksempelkoden ovenfor opsætter parametrene for begivenheden, som i dette tilfælde er en tur ved hjælp af en IMU -sensor. Vi sætter derefter hændelsen i kø i begivenhedskøen. Endelig afkorter vi begivenheden, som i det væsentlige nulstiller begivenheden, så vi kan bruge den til at stille fremtidige begivenheder i kø.

Trin 4: Hændelsesprocessor

Begivenhedsklasser tager den menneskelæsbare fil, der er produceret i hændelsesskaberklassen, og gør hvad hver begivenhed i kø fortæller den at gøre ved at kalde metoder beskrevet i en hændelsesprocessorklasse. Eventprocessorklassen fortæller derefter robotten, hvilken begivenhed der skal afspilles. Uanset om det er en simpel "drive forward" -begivenhed eller en kompleks begivenhed fuld af afstande, sving og straffe, vil processoren afspille enhver begivenhed, der er givet til den. Denne proces er meget nyttig under autonome, da et team kan registrere sensorer og Tele-Op-handlinger før de matcher, og derefter blot afspille begivenhederne i autonome. Denne proces kaldes Memory Replay. Dette tillader, at et autonomt program kan konfigureres 100% gennem en enkelt fil. Når hændelsesskaberen og processoren er etableret, kan et team simpelthen ændre autonome rutiner gennem den menneskelæsbare fil.

Eksemplet ovenfor starter først med at kontrollere JSON -filen for en hændelse og derefter kontrollere den hændelse ved hjælp af en sagserklæring for at se, hvilken slags hændelse det er, i dette tilfælde en tur ved hjælp af en IMU -sensor. Når den kan fortælle, at det er en tur ved hjælp af IMU -hændelsen, behandler den derefter behandlingen af hændelsen, hvilket normalt indebærer at køre koden, som hændelsen kom fra ved hjælp af variabler fra hændelsen, videregivet til at replikere den begivenhed, der blev udført før.