Händelse-driven programmering i FTC: 4 steg

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

I år har vårt team gjort ett stort arbete med eventdriven mjukvaruutveckling för vår robot. Dessa program har gjort det möjligt för laget att exakt utveckla autonoma program och till och med repeterbara tele-op-evenemang. Eftersom mjukvaruarbetet som det kräver är komplext bestämde vi oss för att dela med oss av den kunskap vi har fått om att utveckla händelsedriven kod för FTC-robotar.

Steg 1: Vad är händelsedriven programmering?

I allmänna termer är händelsestyrd programmering, enligt Techopedia, utvecklingen av program som svarar på användarens input. I den meningen betraktas många program som händelsedrivna, inklusive ett teams tele-op-program, som förlitar sig på inmatningar från en kontrollerad person för att utföra alla åtgärder. Men när det gäller det arbete som vårt team har gjort handlar händelsestyrd programmering om att skapa programvara från olika ingångar; med andra ord, vi dokumenterar händelser baserade på ingångar från kontroller och sensorer, sedan kan vi köa dessa händelser och använda filen för att köra om den inspelade händelsen.

Denna metod för att utveckla program för vår robot har flera fördelar:

• Det gör att vi kan skapa exakta autonoma program. Eftersom vi skapar programvaran i realtid medan vi genomgår händelsen kommer sensorvärdena som samlas in och används att vara mycket exakta, eftersom de kommer direkt från den ursprungliga händelsen.
• Det gör att vi snabbt kan skapa autonoma program. Att göra autonoma program är lika enkelt som att spela in en serie händelser och justera händelsen efter behov.
• Det gör att vi kan skapa automatiska processer för tele-op. För upprepade åtgärder i tele-op tillåter händelsestyrd programmering oss att spela in dessa åtgärder och tilldela händelsen till en knapp under de förarstyrda matchperioderna. Dessa automatiserade händelser kan påverkas av sensorer för att möjliggöra deras exakta körning.

Steg 2: Logiskt flöde för händelsedriven programmering

Följande visar det logiska flödet av ett händelsebaserat program: rött visar skapandet av en händelse och blått visar händelsens kallelse. För att skapa en händelse tas en sekvens av ingångar in genom robotaktion och spelas in som händelser; dessa händelser skrivs till en fil. För att ringa en händelse läses den filen och ingångarna skickas till en händelseprocessor för att förvandla filkoden till robotåtgärd.

Steg 3: Event Creator

Händelseskapare används för att dokumentera åtgärder eller "händelser" baserat på en mängd olika sensorer och knappar. När roboten gör åtgärder på fältet skapar en händelseskaparklass händelser för var och en av dessa åtgärder parallellt och refererar till händelsen som klassificerats i en händelseklass. Efter att ha skapats placeras händelsen i en kö av händelser i evenemangsklassen: den första händelsen tar den översta platsen, sedan den andra händelsen tar den översta platsen och trycker ner eventuella händelser under den, och detta fortsätter tills programmet stannar. När programmet stoppas går händelserna ut till en fil som kan läsas av människor, till exempel en JSON-fil. Denna fil kan användas för att bättre förbättra autonoma rutiner.

Exempelkoden ovan ställer in parametrarna för händelsen, som i detta fall är en sväng med en IMU -sensor. Vi köar sedan händelsen i händelsekön. Slutligen avkortar vi händelsen, vilket i huvudsak återställer händelsen så att vi kan använda den för att köa framtida händelser.

Steg 4: Eventprocessor

Händelseklasser tar den människoläsbara filen som produceras i händelseskaparklassen och gör vad varje händelse som står i kö säger till den att göra genom att anropa metoder som beskrivs i en händelseprocessorklass. Händelseprocessorklassen berättar sedan för roboten vilken händelse som ska spelas om. Oavsett om det är en enkel "kör framåt" -händelse eller en komplex händelse full av avstånd, svängar och straff, kommer processorn att spela om varje händelse som ges till den. Denna process är mycket användbar under autonoma, eftersom ett team kan spela in sensorer och Tele-Op-åtgärder innan de matchar, sedan helt enkelt spela om händelserna i autonoma. Denna process kallas Memory Replay. Detta gör att ett autonomt program kan konfigureras 100% genom en enda fil. När evenemangsskaparen och processorn är etablerad kan ett team helt enkelt ändra ut autonoma rutiner genom den läsbara filen.

Exemplet ovan börjar först med att kontrollera JSON -filen för en händelse och sedan kontrollera den händelsen med hjälp av ett ärendebesked för att se vilken typ av händelse det är, i det här fallet en sväng med en IMU -sensor. När den väl kan berätta att det är en tur som använder IMU -händelsen, behandlar den sedan behandlingen av händelsen, vilket vanligtvis innebär att koden som händelsen kom från använder variabler från händelsen, som skickades in för att replikera händelsen som gjordes tidigare.