Gebeurtenisgedrewe programmering in FTC: 4 stappe

2024 Outeur: John Day | [email protected]. Laas verander: 2024-01-30 07:25

Hierdie jaar het ons span baie werk gedoen met die ontwikkeling van sagteware-ontwikkeling vir ons robot. Hierdie programme het die span in staat gestel om outonome programme en selfs herhaalde tele-op-geleenthede akkuraat te ontwikkel. Aangesien die sagtewarewerk wat dit vereis, ingewikkeld is, het ons besluit om die kennis wat ons opgedoen het oor die ontwikkeling van gebeurtenisgedrewe kode vir FTC-robots, te deel.

Stap 1: Wat is gebeurtenisgedrewe programmering?

In die algemeen is gebeurtenisgedrewe programmering volgens Techopedia die ontwikkeling van programme wat reageer op gebruikersinvoer. In hierdie sin word baie programme as gebeurtenisgedrewe beskou, insluitend 'n span se tele-op-program, wat staatmaak op insette van 'n menslike bestuurder om enige aksie uit te voer. In terme van die werk wat ons span gedoen het, gaan gebeurtenisgedrewe programmering egter oor die skep van sagteware uit verskillende insette; met ander woorde, ons dokumenteer gebeurtenisse gebaseer op die insette van beheerders en sensors, dan kan ons hierdie gebeurtenisse in die ry plaas en die lêer gebruik om die opgeneemde gebeurtenis weer uit te voer.

Hierdie metode om programme vir ons robot te ontwikkel, het verskeie voordele:

• Dit stel ons in staat om akkurate outonome programme te skep. Aangesien ons die sagteware intyds skep terwyl ons die geleentheid ondergaan, is die sensorwaardes wat ingesamel en gebruik word, baie akkuraat, aangesien dit direk van die oorspronklike gebeurtenis afkomstig is.
• Dit stel ons in staat om outonome programme vinnig te skep. Dit is so eenvoudig om outonome programme te maak as om 'n reeks gebeurtenisse op te neem en die gebeurtenis aan te pas soos nodig.
• Dit stel ons in staat om outomatiese prosesse vir tele-op te skep. Vir herhaalde aksies in tele-op, kan gebeurtenisgedrewe programmering ons toelaat om hierdie aksies op te neem en die gebeurtenis aan 'n knoppie toe te wys tydens die bestuurder-beheerde periodes van wedstryde. Hierdie outomatiese gebeurtenisse kan deur sensors beïnvloed word om die akkurate uitvoering daarvan moontlik te maak.

Stap 2: Logiese vloei van gebeurtenisgedrewe programmering

Die volgende beeld die logiese vloei van 'n gebeurtenisgedrewe program uit: rooi toon die skepping van 'n gebeurtenis, en blou beeld die roeping van die gebeurtenis uit. Vir die skep van 'n gebeurtenis word 'n reeks insette ingeneem deur robotaksie en as gebeurtenisse opgeteken; hierdie gebeure word in 'n lêer geskryf. Vir die oproep van 'n gebeurtenis word die lêer gelees en die insette word na 'n gebeurtenisverwerker gestuur om die lêerkode in robotaksie te verander.

Stap 3: Event Creator

Skeppers van geleenthede word gebruik om aksies of 'gebeure' te dokumenteer op grond van 'n verskeidenheid sensors en knoppies. Terwyl die robot aksies op die veld doen, skep 'n gebeurtenis -skepper -klas gebeurtenisse vir elkeen van die aksies parallel, en verwys na die gebeurtenis wat in 'n gebeurtenisklas geklassifiseer is. Nadat die gebeurtenis in die gebeurtenisklas geskep is, word die gebeurtenis in 'n ry van gebeurtenisse geplaas: die eerste gebeurtenis neem die eerste plek, dan neem die tweede byeenkoms die boonste plek en druk die gebeure daaronder neer, en dit duur voort totdat die program stop. As die program gestaak word, gaan die gebeure oor na 'n lêer wat deur mense gelees kan word, soos 'n JSON-lêer. Hierdie lêer kan gebruik word om outonome roetines beter te verbeter.

Die voorbeeldkode hierbo stel die parameters vir die gebeurtenis op, wat in hierdie geval 'n draai is met behulp van 'n IMU -sensor. Ons staan dan die gebeurtenis in die tou vir die gebeurtenis. Uiteindelik word die gebeurtenis afgesny, wat die gebeurtenis in wese herstel, sodat ons dit kan gebruik om toekomstige gebeure in die ry te plaas.

Stap 4: Gebeurtenisverwerker

Gebeurtenisklasse neem die menslik-leesbare lêer wat in die skepper van die gebeurtenisklas geproduseer word, en doen wat elke gebeurtenis in die ry vir hom sê, deur metodes te noem wat in 'n gebeurtenisverwerkerklas uiteengesit word. Die geleentheidsverwerkerklas vertel die robot dan watter gebeurtenis hy moet herhaal. Of dit nou 'n eenvoudige "ry vorentoe" gebeurtenis is of 'n komplekse gebeurtenis vol afstande, draaie en straffe, die verwerker sal enige gebeurtenis wat aan hom gegee word, weer speel. Hierdie proses is baie handig tydens outonome, aangesien 'n span sensors en Tele-Op-aksies kan opneem voordat dit bymekaar pas, en dan eenvoudig die gebeure in outonome herhaal. Hierdie proses word Memory Replay genoem. Hierdeur kan 'n outonome program 100% konfigureerbaar wees deur 'n enkele lêer. Sodra die skepper en verwerker van die gebeurtenis gevestig is, kan 'n span outonome roetines eenvoudig verander deur die menslik leesbare lêer.

Bogenoemde voorbeeld begin eers deur die JSON -lêer vir 'n gebeurtenis na te gaan, en dan die gebeurtenis na te gaan met 'n saakverklaring om te sien watter soort gebeurtenis dit is, in hierdie geval 'n beurt met 'n IMU -sensor. As dit eers kan sien dat dit 'n beurt is om die IMU -gebeurtenis te gebruik, gaan dit dan oor die verwerking van die gebeurtenis, wat gewoonlik behels dat die kode waaruit die gebeurtenis gekom het, gebruik word deur veranderlikes van die gebeurtenis in te gee om die gebeurtenis wat voorheen gedoen is, te herhaal.