Idén utoljára neveztünk, abban a hitben, hogy már tudjuk a formulát az első helyezéshez. A valóságban persze nem számoltunk azzal, hogy a verseny mindig egy Benny Hill show-ra emlékeztet, és ami elromolhat az a versenyen vagy az azt megelőző nap fogja felmondani a szolgálatot. Azzal végképp nem számoltunk, hogy a korona ekkora sikert arat a közönség köreiben, vagy hogy egy rekordidő nem egyenlő a közönségdíjjal. Legyen ez a cikk a mementója, hogy a történelmet nem csak a nyertesek írhatják…
Előző versenynek úgy indultunk neki, hogy van elég tapasztalatunk, technikai tudásunk és tudunk nyerni. Mint tudjuk mindig valami banális kis hibán csúszik el az első hely. Minden csapat mire eljut a versenyre sokat le kell tegyen az asztalra. Úgy váltunk el legutóbb, hogy ki tudja mi lesz jövőre, de vártuk a következő versenykiírást, ami a járvány miatt eleve kétséges volt. Mikor megérkezett a feladatkiírás, vonakodva bár de abban a hitben vágtunk neki, hogy idén nem fogunk bent éjszakázni verseny előtt és persze hobbinak sem utolsó időtöltés. Ahogy ez lenni szokott, jöttek az ötletek meg ambíciók és lassan a készülés mániává nőtte ki magát, mi pedig megszállottan gyártottuk a megoldásokat és következésképpen az újabb problémákat. Itt szeretném összefoglalni milyen kihívásokkal jár egy ilyen verseny. Remélem érdekes, szórakoztató és tanulságos lesz a kedves olvasóknak és jövőbeli versenyzőknek.
Mechanikai célok
Első feladat magától értetődően egy robotszekér összetákolása, amire minden csapat kap egy Strada XT távirányítós autót kiindulási alapnak. Nekünk persze már volt két autó korábbról, így nem vállaltuk a kockázatot, hogy ha beüt a krach akkor vissza kellene fizetni mindent.
Több előnnyel is kecsegtetett a két autó építése:
- egyidőben tudunk tesztelni
- lesz egy jobb kocsink, mert szeretünk kocsit építeni
- általában nem egyszerre hibásodnak meg a kocsik, nem esik ki tesztelési idő
- két konstrukció versenyez a csapaton belül, a jobbik megy a versenyre
- ha az egyik összetörik, vagy nem tud indulni a versenyen, akkor van tartalék
Mint kiderült ezen múlt és bukott is egyben a verseny, de ezt majd a maga helyén kifejtjük. Hogy az elején tisztázzuk: a két éves vázon alapuló autó Tesla, a tavalyi alkatrészekből épített autó pedig Bruce (V2), későbbiekben így fogunk rá hivatkozni. Habár a két autó esetleg eltér mechanikai konstrukcióban, az elvi felépítés nagyrészt azonos, ahogy a rajtuk futó szoftver is pár konstans eltéréssel teljesen megegyezik. A versenyen a Tesla modellt láthattátok, később részletezett okok folytán.
Mint minden valamire való mérnöki munka itt a specifikációkból indultunk ki:
- legyen gyors: könnyű anyagból dolgozzunk
- megfelelő tömegeloszlás: lehetőleg alacsonyan, és a kamera hátsó terhelése miatt előre tolva
- elég tapadás kell: erre idén is a “jól bevált” stresszlabdát használtuk (erre majd még kitérek)
- megfelelő kanyaríven forduljon: kormányműre megkötés
- legyen fancy, mert “azzal lehet közönségdíjat nyerni”
Tervezésre megintcsak AutoCAD-ben fogtam neki. Ebben tavaly már a kapott (StradaXT) alkatrészeket modelleztem és nekilálltam a hajtóműnek, majd a kormánymechanikának. Itt kezdtek kiütközni a program és a programhibákkal szembeni tűrőképességem határai, de inkább az utóbbi. Régóta ismerős volt a Fusion 360, de csak CNC megmunkálásra és kisebb munkákra vállalkoztam vele, most viszont volt idő, motiváció és egy példafeladat, hogy megtanuljam a program használatát. Utólag azt kell mondjam, hogy ha valaki egy alkatrésznél többet szeretne modellezni, az tanulja ki a Fusion 360-at, minden másra ott az MS Paint.
Motor, és szénkefés variánsok patológiás elváltozásai
A legyen gyors része a célnak adott volt, azonban a motorcserét illetően nem kommunikáltak egyértelműen a szervezők. Tavaly előtt megengedett volt a gyári 144W-os motort egy 200W-os Brushless motorra cserélni (mondván a keféseket úgy is túlhajtják, nem mintha a Brushless motorokat nem lehetne még durvábban túlhajtani. 😀 ), idén már csak kefés motorok indulhattak, azonban megkötés csupán a méretre volt “540-es”. Nyilván gyári motorra közepesen nyugodt szívvel kapcsolgatunk kW-os teljesítményeket, és a leégett motorok cseréje is lassan a rutin szürkeségébe süllyed. Meg hát ott van az is, hogy a robonaut standard gumikesztyű (beszerezhetó itt), de még a spéci stresszlabdánk sem tolerálja a gyári motor által elérhető nyomatékot, vagyis simán elpörög, ha közben a motorvezérlő meg nem adja magát. Igazából amit nyerhettünk volna egy másik motorral, hogy túlméretezzük és akkor nem a verseny előtti nap ég le mindkettő, illetve Brushless motorral nem szakad le a szénkefe.
A motor meghajtására, mint mindenre a tavalyi nyomtatott áramkörünket használtuk, ami egy esettől eltekintve sosem melegedett szobahőmérséklet felé, de amikor mégis akkor a motor majdnem megolvasztotta a kasztnit felette 2 centivel. Akit a motvez érdekel olvassa el a tavalyi cikkünket is, ha még nem tette volna 🙂
Nyilván idén sem telhetett el év motorcsere nélkül. Ezek a motorok 7.2V-os Ni-MH akkumulátorokhoz lettek tervezve, ezért sokszor nem tolerálják a többszörös túlhajtást (azokat a kW-okat lökésszerűen) és a kefénél jelentkező kisülések hajlamosak megolvasztani és elégetni a szénkeféket jobb napokon. Máskor meg csak egyszerűen letörnek. Nekünk is természetesen a versenyt megelőző két napban égett le mindkét autó motorja, a verseny napján pedig Bruce szénkeféje szakadt le a cseremotorban. Erre persze számítottunk, többek között ezért is lett újratervezve Bruce, hogy ilyen esetekben könnyen lehessen motort cserélni. Szolgáljon itt pár kép elrettentő például minden csapatnak, illetve jó érvként a kefenélküli motorok használata és engedélyezése mellett.
Tömegeloszlás és kamera
Egyenesben mindenki tud gyorsan menni… Igazából van az a sebesség ahol ez sem igaz, de erre lejjebb térünk majd ki. Viszont amit addig is megtehetünk, hogy mind egyenesben, mind kanyarban stabilan gördüljön a járművünk. Ennek érdekében az autó súlypontja minél lejjebb kell kerüljön. Persze értelmes határok között: erre negatív példa a Faketelen Taxi tavalyi tavalyi konstrukciója, ahol a leszívás érdekében annyira alacsonyra kerül a jármű hasa, hogy az emelkedő (ugrató?) végén / lejtő elején karcolta a járólapot. Mint láthatjuk az legutóbbi két rekordidő tartó csapat (Taxi és U&S) autói alacsony konstrukciók voltak: egy merevített alváz és rajta minden alkatrész.
Másik fontos szempont az autó tömegének eltalálása. A motor szempontjából ugyan minimalizálni érdemes a tömeget: azonos gyorsító teljesítménnyel jobban gyorsulunk, alacsonyabb köridők lehetségesek, viszont egy könnyű konstrukciót sokkal negatívabban tud befolyásolni a kamera viszonylag magasan elhelyezett tömege. Nem mintha ezen véglet gyakori volna.
Végül ami megdöntheti az egész tervezést (és autót), avagy miért szeretné mindenki összetörni a kamerát? A kamera a maga 400g tömegével és a tanszék által biztosított kameratartóval elég magasan kap helyet, így nem elhanyagolható. Hiába az alacsony súlypont, főleg könnyű konstrukció esetén, (előre) gyorsulás esetén a kameratartó erőkarja megemeli az autó orrát. Kritikus esetben teljesen elemelkedhet a talajtól, amivel irányíthatatlanná válik az autó. Esetleg konstans gyorsulás esetén elemelkedés után gyakorlatilag a hátsó kerekeken egyensúlyozva, a kerék rugalmassága miatt pattogva teszi le az orrát, addig pedig gyakorlatilag irányíthatatlan az autó. Továbbá hasonlóan a kameratartó csak ront a helyzeten mikor megérkezünk az emelkedő tetejére. Egyszerűen mondva az autó orra és irányított kerekei nem érnek időben földet az emelkedő végén, ezzel gyakran elveszítve a vonalat. Kicsit precízebben fogalmazva pedig a magas elhelyezés és nagy tömeg miatt a hátsó tengelyre vonatkoztatott tehetetlenségi nyomatékunk jelentősen megnő. Egy ilyen mutatványt láthattatok tőlünk is idén. Ezen sajnos az sem segít ha háttal gyorsulunk, mint az Unemployed & Single csapattól láthattuk, mert akkor a fékezéskor emeli fel az autó orrát (hátulját), bár ha a gyorsulási és fékezési erők nem egyenlőek érdemes lehet mérlegelni merre is nézzen a kamera. Sajnos az emelkedő és lejtő tetején lévő ugratást érdemben nem befolyásolja, hogy elől vagy hátul van-e a kameratartó csak a sebesség.
Ezekből a megfontolásokból idén is alul középen kapott helyet a legnehezebb alkatrészünk: az 4S Li-Po akkumulátor. Itt szétvált a két konstrukció: Bruce megintcsak ABS lapból készült CNC-s megmunkálással. Idén kicsit bátrabb voltam és egy nagyobb hajlított elemmel biztosítottam a hosszirányú merevségét a váznak. Ebben sokat segített a Fusion 360 sheet metal (fémlemez) funkciója, amivel könnyen síkba lehetett teríteni az ilyen alkatrészeket. Tesla pedig a két éve készült alumínium vázból lett újraépítve. Ott is alapvetően alvázra épült szerkezettel. Bruce modellben a kameratartó hátsó tömegét a motor és a nehezebb szervó orrban való elhelyezésével próbáltuk kompenzálni, de sajnos úgy tűnt ezzel sem sikerült elérni az áhított eredményt.
Ideális kormányszerkezet (írta: Hava & Beni)
Az idei év talán legnagyobb tanulsága, hogy egy komoly körrekord megfutásához nincs szükség leszívásra, a négykerék kormányzás cserébe elengedhetetlen. Ugyan a versenyen nem sikerült demonstrálnunk, de értelmes pályaállapot mellett mindkét kocsink képes volt megfutni a tavalyig érvényes körrekordot. Amit az Unemployed & Single idén felállított, arra mi sem voltunk felkészülve, ezúttal is gratulálunk hozzá!
Felmerül a kérdés, hogy miért nyúlunk valamihez, ami eddig működött? Az idei vázba nem fért volna el a tavalyi kormánymű, vagy csak annak az árán, hogy valamelyik lemezt kilyukasztva helyezzük el az alkatrészeket (mint tavaly is). Tavaly éltünk azzal a kompromisszummal, hogy a hátsó kerék kivezérelhetősége kisebb volt mint az elsőké, ami elvben okozhatott volna gondot a kormányszabályozónak.
Az is kérdés lehet, hogy hogyan is kell négykerék kormányzást tervezni, de kiváltképp a miért ajánlott. A négykerék kormányzást az indokolja, hogy a pályán túl éles pályaívek találhatóak a kocsi méretéhez és sebességéhez képest és csak elsőkerék kormányzással közel lehetetlen bevenni ezeket a kanyarokat.
Ha nem másolhatjuk a tavalyit, akkor mégis mi alapján bólinthatunk rá a szerkezet paramétereire vagy validálhatjuk azt? Erre a naiv válasz az volt, hogy egy ideális kormánnyal.
De milyen egy ideális kormányzás? Röviden: minden kerék mindig a kanyaríven gördül. Erre az általános ökölszabály, hogy legyen Ackermann kormányzás, és az jó lesz. Ezzel csak két gond van, az Ackermann kormány csak közelíti az ideálist és a másik, hogy a Bruce modellben ez sem fért volna el, illetve nem vállaltam a vele járó kompromisszumokat. A Tesla modellben ezzel ellentétben egy szimmetrikus Ackermann kapott helyet. Bár nem tökéletes, de ezzel sem volt probléma, aminek okát lejjebb részletezem.
Előtte azonban lássuk, hogy hogyan tudjuk jellemezni és összehasonlítani egy tervezett és az ideális kormányzást, ami alapján elfogadunk egy szerkezetet. A kormányzást szimmetrikusra választottuk, vagyis a hátsó kerékszögek az elsőknek tükörképei, így biztosítható hogy az autó a középpontja körül forogjon. A kivezérlés is szimmetrikus kell legyen, tehát a szervó szimmetrikus kivezérlése esetén a kerekeknek is szimmetrikusan kell forogniuk. Ez csak annyit tesz (lásd: Ideális kanyarív ábra), hogy a szervót bal végállásba helyezve a bal kerék álljon 45°-os szögben, ugyanennyire jobbra kivezérelve a szervót pedig a jobb kerék álljon 45°-os szögben (az előjelekkel most nem kell foglalkozni). Ezzel együtt láthatjuk, hogy az ellenoldali kerék ilyenkor nagyjából 20°-os szögben kell álljon ideális esetben (T és L adott, lásd: Ideális kanyarív ábra). A szimmetrikus eset miatt kanyarívnek az autó középpontja által befutott ívet neveztem. Ennek az ívnek az inverz sugarát elneveztem S-nek (a steering után). Ez igazából jobban megfogja a lényeget és könnyebb vele számolni: a kanyarív sugara csak a 0 valamekkora szimmetrikus tartományában nem értelmezett, mi viszont jobban kedveljük a véges tartományokban maradni. Viszont onnan nézve, hogy S = 0 eset egyenesmenetet jelent, S = 4 [1/m] (vagyis 0.25m közepes kanyarodási sugár) pedig például a maximális kanyarodásunk, sokkal intuitívabb a dolog. Ebben a rendszerben ábrázolva az ideális kormány karakterisztikáját a következőket láthatjuk (a tavalyi esetet is feltüntetve).
Itt azt láthatjuk, hogy a tavalyi konstrukció külső íven gördülő kereke az ideálisnál kisebb kanyaríven fordul (nagyobb abszolút kerékszög), vagy máshogy fogalmazva a belső kerekek nagyobb íven szeretnének gurulni. Ez az ellentmondás azt jelenti, hogy egy nagy kanyarban, sebességtől függően a külső kerekek jobban tapadnak, és tolnák sugárirányban a kanyarba a járművünket, a belső kerekek viszont kicsit gyengébben de kifelé próbálják tolni a járművet. Ezzel az eltéréssel azt eredményezzük, hogy csökken a maximális tapadásunk a kanyarokban (és ezzel a sebességünk is), attól függően, hogy éppen mennyire térünk el az ideálistól. Ökölszabályként azt mondhatjuk, hogy jobb ha a belső kerekek befelé húzzák az autót (tehát a görbénk kevésbé meredek) így az autó nem csúszhat kifele. Ebből is következik, hogy a fentebb ábrázolt 4-kerekes Ackermann kormányzás esetén a belső kerék kisebb (pontosabban beljebb tolt) íven próbál fordulni, így ez elfogadható kompromisszum lehet, amíg a gumik rugalmassága tolerálja (lásd: slip szög).
Most hogy tisztáztuk, hogy egy rossz kormánymű miatt tapadási tartalékból veszítünk a kanyarokban, röviden kitérek, hogy hogyan lett ebből egy fizikai terv: Mivel a túl sok lehetséges paraméter (adott konstrukcióhoz) volt, ezért inkább egy Excel táblával próbáltam optimalizálni a paramétereket implementálható határok között maradva. Két konstrukcióval kezdtem: az elsőben állított szervótengellyel számoltam, ami lényegében a két évvel korábbi konstrukció finomítása lett volna. Ezt azonban fizikai megkötések miatt nem lehetett volna kivitelezni, úgy hogy közben a karakterisztika megfelelően közelítse az ideálist. A probléma az volt, hogy a motor és a nagy fogaskerék helyzete miatt nem fért volna el a szükséges szervókar.
Második konstrukció alapjául a tavalyi autó kormányműve szolgált, pár megkötéssel (szervókar hossza, tolórúd szélessége és a gyári csapágyház paraméterei). Itt is sikerült addig iterálni míg egy elfogadható megoldás született. Ezt utána implementáltam Fusion 360-ban. A konstrukció vázlatán a jelölések megegyeznek, csak a fancy grafika maradt el 🙁
Tesla konstrukciójában a kerekek között fix tolórudazatot használtunk. Mint ahogy az ábrán is látszik a kerékagy és a tolórudazat forgástengelyének egy fix egyenes mentén kell elhelyezkednie.
Ezen forgáspont ugyan közel ideális íven való fordulást tesz lehetővé, de itt emelném ki, hogy nagy sebességnél éles fordulóknál fontossá válik, hogy a kocsi súlypontja középre essen. A kamera által farnehézzé tett jármű éles kanyar esetén „vetődik”, bedobja a hátulját a kanyarba. Ez könnyen lesodródáshoz vezethet (lásd a 2. gyorskörünk)
Kerékagy (csapágyház) kialakítása
Kellően nagy sebességek esetén olyan problémába ütköztünk, hogy az egyenes szakaszon az autó fix időállandóval oszcillált, ami fékezéskor felerősödött. Ezt nem tudtuk mire vélni: a kormányhangolás jó volt, az autó a vonalon középen ment, kormányszögek jók voltak. Érdekes módon ez kis sebességeknél (értsd 17 mp-es köridő) nem jelentkezett. Szakemberrel való beszélgetés után arra jutottunk, hogy ez sem új dolog és létezik rá “kész” megoldás. Röviden: a kerék forgástengelyét a megfelelő irányba megdöntve ez kiküszöbölhető.
A kerék forgástengelyét hívjuk csapnak. Ezt megdöntve a menetdinamikáját lehet befolyásolni a járművünknek. A kerekeket döntve (nem a csapot) vagy forgatva megintcsak változik a dinamika.
- csapterpesztés: a csapok teteje a hosszanti tengely felé, befele (pozitív szög) dől vagyis terpeszt (elölnézetben)
- csaphátradőlés: a csap teteje hátrafele (pozitív szög, oldalnézetben) dől, 4-kerék kormányzás esetén a hátsó kerekek csapja értelemszerűen előre dől
- kerékdőlés: a kerekek teteje befele, a hosszanti tengely irányába dől (negatív kerékdőlés, elölnézetben)
- kerék össze és széttartás: az első/hátsó kerékpár nem párhuzamos (felülnézet)
De hogy mit is befolyásolnak ezek a paraméterek?
A csapterpesztés miatt kanyarodáskor a kerekek nem a függőleges tengely körül forognak, ezért a kerekek kicsit megemelik a járművet. Ez egy visszatérítő erőt hoz létre, ami a kerekeket egyenes állás fele mozgatja kanyarban. Ezért forog vissza a kormány az autókban, ha egy kanyar után elengednétek (ami mint tudjuk szabálytalan gyakorlat). A csaphátradőlés erre a hatásra erősít rá, de ami fontosabb, hogy a kerek tetejét a kanyarív középpontja felé dönti, ezzel növelve a menetstabilitást. Az fix kerékdőlés (tehát a csaphátradőlés miatt kanyarokban jelentkező kerékdőlésen túl) értelmes határokon belül (max. 5°) képes sokat javítani a kanyarokban a tapadáson. Túl sok kerékdőlés viszont meggátolja az értelmes egyenesmenetben a tapadást.
Mi a pontos mechanikai jellemzőit az észszerű határok figyelembevételével, továbbá a tesztelés során megfigyelt viselkedés alapján alakítottuk ki. Így jutottunk arra, hogy 4° csaphátradőlés, 8° csapterpesztés megfelel a célnak. A Tesla esetében ehhez jött még 2° kerékdőlés is.
Az utolsó fontos kormánymechanikai kérdés a kerekek szét vagy összetartásának szükségessége, szerepe. 4 kerék hajtás esetén arra a következtetésre jutottunk, hogy a hátsó tengelyen lévő kerekeknél indokolt a párhuzamos, az első tengelyen a kis mértékű széttartás beállítása. Mindez menet közben stabilizálja a kormánymű holtjátékát (amennyiben hagytatok bene. 😊 )
Ami még fontos lehet, hogy a csap tengelyének és a földnek a döféspontja hol található a gumihoz képest. Látható, hogy nekünk nagyjából a belső harmadban található. Az ideális volna ha külső oldalra kerülne, de más igények indokolhatnak másik döféspontot is. Sajnos a kerék ennyi szabadságot engedett ennek a paraméternek a hangolására. A témáról bővebben itt olvashattok: itt, itt és itt!
4 kerék kormányzás hangolása (írta: Hava)
A versenyen látható, hogy több csapat próbálkozott négykerék kormányzással, azonban ezek beállításai nem sikerültek feltétlenül fényesen. A probléma az, hogy nem a vonalon mennek az autók, hanem azon ferdén vagy mellette egy pár centivel. Ha a hátsó kerék nem kormányozható a ferdén haladást nehéz kiküszöbölni (mechanikai hibára utal), négykerék kormányzás esetén viszont ezt a szervók középponthibái (rossz ofszet) okozzák. A hátsó kerék helytelen ofszethibája okozza a vonalhoz képest ferde haladást, az első kerék ofszethibája pedig párhuzamos eltolódást eredményez. Ez akkor válik láthatóvá, ha a menet közben a hátsó szervót középállásban rögzítjük. Nagy sebességeknél érdemes középállásban rögzíteni a hátsó szervót, mert bekapcsolásával ugyan kis sebességgel stabilizálódna a vonaltartása, nagy sebességen viszont oszcillációt okoz. Pontos beállítása reménytelen 😀
Kidolgoztunk egy gyors algoritmust, aminek a segítségével egyszerűen elvégezhető ez a szervók ofszetjeinek finomhangolása. Bemeneti követelmény egy elülső vonalszenzor és egy azon futó PD szabályozó. (Ez egyébként hátsó vonalszenzor meglétével teljesen automatizálható lett volna) Az iterációs lépések a következők:
- a hátsó szervót letiltjuk (majd 0-ba állítjuk), a kocsit egyenes vonalra tesszük majd egyensúlyi állapotig (egyenletes gázadással) futtatjuk az első szervóval a vonalkövetést
- menet közben addig hangoljuk a hátsó szervó középállását míg a kocsi nem halad párhuzamosan a vonallal
- ha a kocsi párhuzamosan halad a vonallal az első szervó középpontját addig hangoljuk míg a kocsi nem kerül a vonal közepére
- ezt követően visszakapcsoljuk a hátsó szervót és a kocsit a vonalra merőlegesen mozgatva ellenőrizzük a két szervó egyenletes kivezérlését (amennyiben ez nem stimmel akkor indokolt a beadott értékek arányos leosztása a túlforduló szervó esetén)
A hangolási elv azon alapul, hogy a kocsi haladási irányszögét a hátsó kerekek állása határozza meg.
Kasztni
Idén végre volt kasztnink 🙂 A design még tavalyról jön, amit akkor nem sikerült ilyen minőségben realizálni. Akkor CNC-zni és vákuumformázni szerettük volna. Most se CNC-hez nem fértünk hozzá a kollégiumi lezárások miatt, vákuumformázó gépet sem tudtunk összerakni idő híján, így a választás, hogy mégse maradjon el a kasztni, a nyomtatásra esett.
Anno még a kasztnit 3ds Max-ban terveztem spline cage technikával, amit sajnos a Fusion 360 nem támogat. Cserébe kapunk T-spline megoldást amit pl még a Rhino támogat (de az nem Autodesk), és sokkal modernebb megoldás mint egy spline cage. Igaz ez azt jelentette, hogy a régi alapján újra kellett tervezni az egészet, de onnantól kezdve sokkal barátságosabb megoldás volt.
Az igaz, hogy itt is szembe találkoztam magam pár programhibával (feature?). A nyomtatáshoz sajnos Magyarországon nem találtam olyan céget, aki ekkorában nyomtatott volna (nyilván egy darabban), és nem FDM technológiával (ez a fogkrém kinyomós nyomtatás). A választás korábbi tapasztalat miatt az SLA technológiára és a FacFox-ra esett.
És a valóságban:
Akkumulátor felügyeleti PCB (írta: Hava)
Ebben az évben ugyan jórészt a mechanikára helyeztük a hangsúlyt, azonban láttunk némi elektronikai fejlesztési lehetőséget. Tavaly gondot jelentett, hogy az akkumulátorok bedugáskor szikrázhatnak (nem gondoskodtunk a kondenzátorok előtöltési áramának korlátozásáról) ezáltal a csatlakozók megsérülhettek, továbbá a kocsi áramtalanítása kritikus esetben nem tudott gyorsan megtörténni. Ihletként a tavalyi XT60 csatlakozónk szolgált.
További célul tűztük ki az alábbi funkcionalitásokat:
- nagyáramú megszakítás készítése billenőkapcsolóval (100A-es kapcsoló nincs értelmes méretben)
- párhuzamos akkumulátor töltési és labortápos tesztelési interfész kialakítása
- integrált Li-po akkumulátor felügyeleti egység, esztétikai céllal rendszámtáblának álcázva
- több különálló cella csatlakoztatásához és egyesítéséhez szükséges interfész kialakítása (erre a súlyelosztás miatt volt szükségünk)
A fenti követelményeket figyelembe véve megalkottuk az alábbi kapcsolást.
Az áramkör működése és felépítése igen egyszerű. A bemeneti akkumulátorpakkokat (VIN 1 és VIN 2) egyesítettük, majd szeparációként készítettünk egy eltávolítható loopback kábelt. A fizikai szétválasztást követően lehetőségünk nyílt alternatív feszültségforrásról tesztelnünk a kitéglázott kocsinkat. A nagyáramú kapcsolást egy az inverterben is használt 200A terhelhetőségű FET felhasználásával biztosítottuk. Az akkumulátor balanszer csatlakozójára felkerült egy kapcsolható Li-Po-őr áramkör. Ez az áramkör természetesen nem rendelkezik előtöltő funkcióval, a kellően gyors és erős kapcsoló használatával ez szükségtelenné vált.
Miért van aktívan bekötött (és bekapcsolt) Li-Po-őrre szükség (by Beni): A Li-Po cellák nem rajonganak az ötletért, hogy fagyban biciklin utazzanak. Ezen bölcsesség megszerzéséhez sajnos úgy jutottam, hogy egyik reggelre virradóan meghalt két cella az akkupakkban (~10mV maradt benne). Ezt nem jelezte az akkuőr, valószínűleg túl gyorsan történt vagy csak túl jó alvó vagyok és nem hallottam az utolsó kívánságát (temessetek szelektív hulladékgyűjtőbe). Szerencsére még maradt pont két cella. Az akkupakkot 2mm vastag polisztirol hablemezzel burkoltam mechanikai védelem és kihűlés ellen.
Lámpa
Első tervnek 3 szegmens lett volna egy integrált ledmeghajtóval (van a nyákon hely neki) és hátsó megvilágítással. Maga a lámpa elképzeléseim szerint plexiből készült (volna), viszont az elég törékeny, nem szereti a hajtogatást, sem az ütközéseket. A Tesla modell lámpája pont ezért PETG-ból lett nyomtatva, amit könnyebb hajtogatni és kevésbé törékeny. A megvilágítás esetén pedig inkább áttértünk 21-21 címezhető ledre. Ezzel nem volt a LED-ek színérel megkötés és az előtétekkel vagy árammeghajtókkal sem kellett vesződni.
A megvilágítás végül felülről (ami apró lyukakkal szórtunk szét hátrefele, Tesla esetén alulról érkezett, és a fényszóráshoz elég volt a nyomtatás tökéletlensége). A reflexiót pedig kétoldalú ragasztó és alufólia kombinációval biztosítottam.
Tapadás van, de milyen áron?
Immár második alkalommal használtunk stresszlabdát a gumikesztyű helyettesítésére inkább több mint kevesebb sikerrel. Ennek a nagy előnye, hogy ezzel a megoldással az elérhető tapadás jóval meghaladja a standard SPAR-os mosogatókesztyűvel elérhető értékeket. Nyilván pont ezért nem tettük közkinccsé ezt a megoldást. Tehát ez a titka annak, hogy hogyan lehet gyorsan menni a kanyarban. Sajnos azonban ha poros a pálya, azon csak a takarítás segít.
Ennek a megoldásnak viszont van egy átka is. A tapadással együtt jár az elektronok felhalmozódása is, elvégre a tapadás atomi szinten elektromos jelenség, amit a dörzsölés csak elősegít. Ugyanez a jelenség előfordul persze gumikesztyűvel is, de nem olyan szembeötlő. Stresszlabdával sem probléma egy bizonyos sebességhatárig, ahol már nem tudja a levegő és föld elég gyorsan elvezetni a felhalmozódott elektrontöbbletet, és pechünkre gyakran az áramköreink bizonyultak a leggyengébb láncszemnek. De persze az is elég, ha a föld felé távozik egy halk szikrakisülés formájában a felesleges töltés, ez elég egy EMC zavarhoz ami képes újraindítani a mikrokontrollereket vagy egyéb zavarokat okozni. Ezen csak ront az, hogy télen fűtenek és szellőztetnek, így a levegő páratartalma alacsony és ez sem képes elvezetni a felesleges töltéseket (kiszárad a gumi felülete).
Ez a jelenség ugyan mindkét autónkon megfigyelhető volt, de Bruce esetén a váz ABS-ből készült ami nem tudta elvezetni a töltéseket (lévén egész jó szigetelő), míg Tesla igen, és egy kis földelő vezeték elég volt, hogy kiküszöbölje ezt a problémát. Az is megoldás lehetett volna, ha kissé vezetővé tudjuk tenni a gumikat. Sajnos a versenyig ezt a problémát Bruce esetében nem tudtuk kiküszöbölni, ezért nagyjából körönként újraindult a gyorsasági szám tesztjén. Tehát ezért indult a Tesla és nem Bruce.
Egy rövid montázsvideó a készítésről és korai tesztek
Szoftveres változások
Időrablás a fejlesztés során (írta: Hava)
Sajnos idén is sok csapatnál figyeltem meg azt a tendenciát, hogy nem keresnek egyszerű és gyors megoldást időigényes folyamatok egyszerűsítésére. Több évre visszatekintve szeretnék megemlíteni néhány apróságot, ami utólag visszatekintve sok tesztpályán töltött időnket felemésztette.
Járművel való kommunikáció hiánya, szükségessége:
Mit és miért lehet érdemes a kocsival kommunikálni? Erre a kérdésre mi az alábbi választ adtuk.
- szükség van funkciók ki és bekapcsolására, továbbá azok állapotának ellenőrzésére /FLAG SETTINGS/
- minden szenzoradatnak elérhetőnek, lekérdezhetőnek kell lennie /LOGGING/
- szükséges bizonyos belső paraméterek módosítása / PARAMETER SETTINGS /
A robotjaink menürendszere ezen beállítási módokra lett kiélezve. Amennyiben a kommunikációs interfész nem elég fejlett az az STM nagyon sok rendbéli újraégetését vonja maga után.
- A FLAG beállítások elengedhetetlennek bizonyultak a tesztelés során. Többek között egyesével tudtuk tiltani, invertálni szervóinkat, állítani tudtuk a távirányító üzemmódjait, ki bekapcsolhattuk a szabályozási köreinket. Ellenőrizhettük a kód által engedélyezett/ tiltott funkcionalitásokat.
- A LOGGING menüpontokkal egy-egy szenzoradat logolását kapcsolhattuk be. Amennyiben megmagyarázhatatlan hibát észleltünk az adatok utólagos elemzésével megérthettük validálhattuk a kocsink döntési paradigmáit. A szenzoradatok kinyerésére a verseny során felmerült az SD-kártyára való mentés lehetősége. Ezt a megoldást szintén csak ajánlani tudom. Nagyon sok időt vehet el egy tökéletes forráskód elemzése, validálása amennyiben egy bemeneti feltétel hibás.
- A PARAMETER SETTINGS segítségével felügyelhettük, módosíthattuk a szabályozó beállításainkat, beállíthattuk a szervóink kivezérlését, középpontját. Ezen menüpont megalkotásánál nehézséget okozott, hogy az STM fix 3 byte-os DMA UART üzeneteket fogadott az ESP WiFi modulunktól. Felvetődik a kérdés, hogy lehet ezen az interfészen keresztül hibátlanul átvinni egy akár sok tizedes értéket elérő double értéket. Ennek veszélye miatt (esetleges rossz paraméter esetén komoly károkat okozhatott volna többek közt a sebességszabályozó) meg sem kíséreltem. Csupán parancsot adtam egy-egy érték adott inkremenssel való növelésére/csökkentésére.
Ezen menüfelépítést függvénypointer rendszerrel oldottam meg, mely pillanatok alatt bővíthető volt további menüpontokkal. Kliensalkalmazásként Putty-t (RAW telnet mód) továbbá az androidos „Serial Wifi Terminal” nevezetű appot használtuk. Ebben az alkalmazásban könnyen készíthettek fix parancsot kiküldő gombokat. Egyszerű alternatíva lehet egy 5 perc alatt létrejövő alap kommunikációs interfész megalkotására.
TLDR:
Nem érdemes vakon tesztelni. Ezt bizonyára nem fogjátok belátni az első kódok tesztelésekor, ezért elrettentő példával szolgálnék: Több csapat próbálkozott PD szabályozót hangolni paraméter tippelgetéssel. Tökéletesen működő vonalszenzor és kielégítő mechanika esetén (a gyári messze nem ilyen), ezenfelül értelmes szervókkal ez valóban determinisztikus (100 újraégetési ) iterációból sikerülhet. Amennyiben online tudjátok tologatni a PD szabályozótok paramétereit azonnali visszajelzést kaphattok. Egy szabályozó hangolás így nem több 10 percnél…
Ha már kommunikáció, megemlíteném a Rekeszkutató Intézet (csapat) megoldását: ESP és MQTT szerver és PC-s GUI kombó. Ha újra indulnánk, akkor mindenképpen megfontolnánk a használatát.
Giroszkóp és előzés (írta: Doma)
Idén a legkritikusabb feladat amihez szükségünk volt a giroszkópra az előzés volt. Az alap elgondolás nem változott az előző évekhez képest. Amit idén is megpróbáltunk megvalósítani, hogy elhagyjuk a vonalat egy megfelelő szögben, majd ha elég messze értünk visszaállunk párhuzamosan a vonallal és gázt adunk. Miután megtettünk megfelelő távolságot, lassítunk, megfelelő szögben közelítünk a vonalhoz, majd ha elértük a vonalat kijelentjük hogy végeztünk az előzéssel és újra követhetjük a vonalat. Meglepő módon idén sem ment hibátlanul az előzés első próbára, de másodikra sem…
Mivel előzéskor nincs vezetővonal és egyéb külső segítség, így a kocsin lévő szenzorok adatai alapján tudjuk végrehajtani az előzést. A legfontosabb szenzor az encoder. Enélkül nem tudjuk megmondani mennyit mentünk eddig és mikor kéne befejezni az egyes részeit a feladatnak. Ezek alapján nyilvánvalóan ha elpörög/megcsúszik a kerék, nem tudjuk végrehajtani az előzést. Ahhoz hogy ez teljesüljön, tapasztalati úton állítottuk a sebességet/gyorsulást. Nem nagyon akaratunk megcsúszás/kipörgés detektálással foglalkozni, de nyilván úgy szebb lenne a megoldás. Az előzésnél a következő feladat, hogy megfelelő szögekben tudjunk haladni a vonalhoz képest. Ezt meg lehet csinálni fix kormány szögekkel, de nem célszerű. Ez úgy működne, hogy elfordítjuk a kormányt egy fix szögben, megyünk valamennyit, majd változtatunk megint a kormányon megint megteszünk valamekkora távolságot stb… Ezt elég próbálkozással be lehet úgy hangolni, hogy teljesítse a feladatot. Ezzel az a probléma, hogy ha változik a szervó beállítása, akkor mindent újra kell hangolni. Ez akkor állhat elő, ha tönkremegy a régi szervó, vagy csak szét kell szedni a kocsit pl. motorcsere miatt… Tapasztalatok alapján utolsó este kell szétszedni a kocsit és nem nagyon lesz idő a fix kormányszöges manőverek újrahangolására. Szóval ezt semmiképp sem javasoljuk.
A tanszék által kiadott giroszkóp/gyorsulás érzékelő sugallja, hogy ezt kéne használni a feladathoz. Ha tudjuk biztosan a kocsi orientációját, egész egyszerűnek tűnik a feladat. A tavalyi cikkben elég sok mindent leírtunk a giroszkóppal kapcsolatban, de idénre is jutott egy kis meglepetés… A tavalyi kódon finomítgattunk és elég jól ment minden, majd egyszer csak minden szétesett. Elég hamar kisült, hogy az orientáció méréssel van a problémánk. Az történt, hogy egyik napról a másikra a szenzor offset hibája egy nagyságrenddel megnőtt. Ez azért okozott problémát, mert előtte nem foglalkoztunk az offset hibával. Szerencsére nem bonyolult számításba venni. Mikor még áll a kocsi és inicializál minden perifériát, a MEMS is kapott egy kis időt, hogy mérjen n db mérést és számítson egy átlagot, amit szépen elment magának a program és korrigálja a szenzor által küldött adatokat. Megjegyzem a szenzor tartalmaz erre egy külön regisztert ahova ha beírjuk az offset hibát, kiszámítja a korrigált értékeket és az jelenik meg a kimeneti regiszterben. De a programból való kezelés is működik. Az a fontos, hogy minden indulásnál ellenőrizni kell ezt a hibát és vízszintes talajon álló helyzetben történjen a kalibrálás. Többször sikerült, még a levegőben bekapcsolni a kocsit, így a kalibráció során azt mértük, hogy hogy döntjük a kocsit, mikor letesszük a földre. Ez általában akkor jutott eszünkbe, mikor előzésnél falnak vette az irányt… Amivel nem foglalkoztunk, de illett volna, hogy magunk kalibráljuk a szenzort. Ha egy ismert szögsebességgel tudjuk forgatni valószínűleg pontosíthatjuk a mérést és némi nemlinearitást is felfedezhetünk a szenzor adataiban. De egy korrekt offset méréssel sikerült megfelelő pontossággal mérni az orientációt, így nem foglalkoztunk tovább a problémával, sem a szenzor öregedésével vagy hőmérsékletfüggésével.
Miért nem UH? (írta :Hava)
Mint már olvashattátok a TOF szenzorok megbízhatatlansága miatt az előző években a HC-SR04 típusszámú ultrahangos szenzort (és másolatait) használtuk. Ugyan mérete meglehetősen nagy és ormótlan, idén is megkíséreltem a használatát, azonban nem várt hibák jelentkeztek. A szenzor mérési tartománya elméletben meghaladja a 3m-t azonban nekünk 1.4m felé sem sikerült stabilan mérnünk vele. A szenzor echo jelét oszcillografálva egyértelművé vált, hogy nem a központi kontrollerünk kódja rossz, a szenzor valóban ilyen értéket ad vissza számukra. Ennek okát sokáig keresve az alábbi megfigyeléseket tettem. Számít milyen felület elé kerül felhelyezésre a szenzor, továbbá megközelítőlegesen bármilyen kapcsolat a külvilággal befolyásolja a mérési eredményét. Pontosítva a történteket, nem találtam olyan felhelyezési módot amiben megbízhatóan tudtam volna mérni vele. Természetesen a szenzor kínai verzióját használtuk és nem kíséreltem meg másik vezérlő elektronikát készíteni hozzá. Úgy vélem a kínai szenzor hibáját az is okozhatta, hogy kapszuláink hátulja az eredetivel szemben nem fémből készült, így iránykarakterisztikájuk jóval szórtabb lehet (akár a hátsó irányban is lehet sugárzási, érzékelési tartományuk). Időhiányban elvettem a kísérletezést, a következő lépést azonban ezen kapszulák cseréje jelentette volna.
Arra a kérdésre, hogy miért is fontos legalább 2m-es hatótáv a versenyen az utolérés adja meg a választ. Két lehetőség közül választhattok, vagy megfelelően lassan mentek és kis tempóval éritek utol a felvezetőkocsit (ehhez persze pontosan tudni kéne a sebességét), vagy nagy sebességről időben megkezdve a ráfutás elleni fékezést éritek utol. Utóbbi vagányabb és egyszerűbb megvalósítani. 😊
(Megjegyezném oszcilloszkóp nélkül a hardveres hibák megtalálása (mentális) egészségre káros lehet, kérdezze róla kezelőorvosát vagy gyógyszerészét.)
ToF (írta: Doma)
Tavaly használni szerettük volna a tanszék által biztosított ToF (Time of Flight) távolság mérő szenzort, de nem volt rá elég időnk és maradtunk a bevált ultrahangos távolságmérőnél. Idén több szempontot figyelembe véve azt mondtuk, hogy akkor most megfejtjük a ToF (nem)működését. ” Nem létezik, hogy használhatatlan dolgot áruljon az ST! ” felkiáltással nekiestünk hogy kiderítsük mi volt a baj tavaly. Ráadásul nem olcsó mulatság egy ilyen szenzor. A szenzor az ST VL53L1-es szenzor, ami egy VL53L1X-SATEL breakout board-on található. Az ST honlapjáról le lehet tölteni egy API-t ami lehetővé teszi a szenzor “egyszerű” használatát. Van egy egyszerűsített “Ultra Lite Driver” verzió ami kb 3 fájlt tartalmaz. Mi ezt használtuk. Az igazság az, hogy csak az API-val lehet használni a szenzort, mivel az ST nem nagyon akarja leírni a belső működést. Csak egy User Manual-t ad ki az API-hoz. Ez valahol jó, mert nem kell regisztereket böngészni, kitalálni a megfelelő szekvenciákat, hogy tudjunk mérni a szenzorral. Egyszerűen meghívjuk a megfelelő funkciókat és a szenzor visszaadja a kért adatokat. Ez addig jó, amíg minden úgy működik, ahogy elképzeltük. Amint valami nem stimmel elkezd zavarni, hogy nem látjuk, hogy mi történik a feketedobozban… Sajnos az ST nem dokumentál valami fényesen, így egy csomó dolgot csak tippelni tudunk a működésben.
Korábbi évekből több csapattól is hallottuk, hogy sok gond volt a szenzorral, szóval nem csak mi bénáztunk. A szenzor I2C-n kommunikál, amit többen a hiba lehetséges forrásának tartottak. Ha ilyen munkába fog az ember akkor jó, ha először utánajár az I2C kommunikációnak. Az I2C-t elég sok helyen alkalmazzák. Nagy előnye pl az SPI-al szemben, hogy 3 vezetéken (GND, SCL, SDA) sok eszközzel tudunk kommunikálni, míg SPI-on minden egyes újabb eszköz egy újabb CS (chip select) vezetéket jelent. De az élet nem egy habos torta, így semmi sincs ingyen. SPI-on a CS lábbal a master mindenképp le tudja állítani a kommunikációt, majd újat kezdeni. Az I2C-n viszont előfordulhat egy hiba hatására (pl EMC gondok), hogy a slave blokkolja a kommunikációs vonalat. Röviden ez úgy fordulhat elő, hogy a slave 0-át szeretne adni és várja az órajelet. A master viszont valami hiba miatt úgy “gondolja”, hogy befejeződött az adás. Szeretne újra adni, de látja hogy az adatvonal foglalt (SDA 0 állapotban ragadt), így nem tud új kommunikációt indítani. Erre a problémára többféle megoldási javaslatot lehet találni a különböző fórumokon. Egyik az reseteljük az adott eszközt, ami ugye növeli a szükséges vezetékek számát… A lényeg, hogy fel kell készülni az I2C hibákra, szoftveres és hardveres megoldás is van, de legbiztosabb ha mindkettővel rendelkezik az ember.
Pár ilyen fórum és megoldás: itt, itt, itt és itt
(Megjegyzem, hogy pont erre találták ki kritikus helyekre az SMbus kommunikációt, ami lényegében I2C, többek közt azzal a különbséggel, hogy megszabják a minimális kommunikációs sebességet és egy kötelező érvényű időkorlátot is szabnak a kommunikálásra pont az ilyen kritikus fennakadások elkerülése érdekében, de a szenzorunk nem támogatja az SMbus-t)
Vissza a ToF szenzorunkhoz és az API-hoz. Az ST lehetőséget biztosít számunkra, hogy több szenzort is használhassunk egyetlen buszon. Ezt úgy tudjuk megtenni, hogy az API-val be tudjuk állítani minden szenzornak az I2C címét. Gyári beállítás szerint minden szenzor a 0x52-es címmel rendelkezik. Ahhoz, hogy külön-külön be tudjuk állítani a számunkra tetsző I2C címeket, használnunk kell a szenzor XSDN lábát. Ez az adatlap szerint HW standby állapotba állítja a szenzort. Gyakorlatban ez azt jelenti, hogy reseteli a szenzort! (Ezt nagyon sokat kerestem és egy eldugott fórumon írták csak le, hogy ez ténylegesen a reset láb és nem csak egy SW standby.) Az elv, hogy minden szenzort reset állapotból indítunk. Felengedjük az első reset lábat, a 0x52-es címen tudunk vele kommunikálni. Beállítunk neki egy másik címet, majd a következő szenzor reset lábát engedjük fel amivel most már tudunk gond nélkül a gyári címén kommunikálni, mert az előző szenzorunk címét már átírtuk és nem válaszol a 0x52-es címre. Így szépen fel tudjuk inicializálni az összes szenzorunkat. Mi csak egy szenzort használtunk, ami a követéshez volt szükséges. Ennek ellenére egy szenzornak is érdemes átállítani a címét.
Egy fontos részlet még tavaly kiderült az API-val kapcsolatban. A szenzor inicializálása során, miután beírta a megfelelő regisztereket elindít egy mérést és addig vár, amíg nem érkezik be egy mérési eredmény, majd leállítja a mérést és kijelenti, hogy minden rendben ment. Ezzel csak az a gond, hogy nem figyeli a regiszter írás során, hogy ha nem tud kommunikálni a szenzorral. Ha nincs fent a szenzor a helyén (akár fizikailag nincs ott a csatlakozón) az I2C műveletek nyilván hibára futnak, de az API ezt nem kezeli és belép egy “while()” ciklusba aminek a kilépési feltétele a sikeres mérés. Na ez blokkol mindent a kontrolleren… Ezt mondjuk a második lefagyás után hamar kiderítettük anno, de ha ez menet közben játszottuk volna el, akkor biztosan törik a kocsi… Ezen kívül még egy turpisságot találtunk az API-ban (erről majd kicsit később), de alapvetően elég jól használható.
A többi hiba mind hardveresnek tekinthető. Alapvetően az volt a problémánk, hogy asztalon minden jól működött, de amint leraktuk és mentünk a kocsival, random idő elteltével elhalt az I2C kommunikáció. A szenzorkártya két részből áll. Van egy szintillesztő és tápfeszültség előállító áramkör, és maga a szenzor. Eredeti gondolatunk az volt, hogy használjuk a szintillesztőt, hogy biztos ne legyen baja a szenzornak. Tehát tüskesorral csatlakoztunk a kártyához. A random leállások miatt egyből azt gyanítottuk, hogy a kocsi által keltett zavarok miatt omlik össze a kommunikáció. Egyik első gondolatunk volt, hogy csökkentsük az I2C felhúzó ellenállásait (nagyobb felhúzó áram), valamint használjunk árnyékolt kábelt. A kisebb ellenállás nem vezetett célra, menet közben ugyanúgy lehalt a kommunikáció. Az árnyékolt kábelt több csapat is bejátszotta, de tudtommal senkinek sem oldotta meg a problémát. “Mit csinál a villamosmérnök, ha problémába ütközik? Hát mér…” – felkiáltással rámértünk oszcilloszkóppal, hogy mégis mi folyik az I2C vonalakon. Első körben nem tudtuk megmérni, mert amint rákerült a szkópfej elhasalt a kommunikáció.
Ezen a ponton volt elegünk abból, hogy nem tudjuk pontosan mi is történik a kártyán. Szerencsére csak 2 IC volt a kártyán a szenzoron kívül, amiből az egyik egy feszültségstabilizátor (LDO), ami 2.8V-ot állít elő a szenzor számára, a másik pedig a szintillesztő (TXS0108EPWR). Ennek az adatlapja alapján szükségtelen a külső felhúzó ellenállás, mivel az IC-ben van beépített. Ugyanakkor nem bíztunk a szintillesztőben, mert nem tudtuk mennyire zavarérzékeny a működése. Mivel a motor miatt elég nagy áramtüskék jelennek meg a rendszerben, ezért számíthatunk bőven a zavarokra is. Végül is az adatlapok böngészése után arra jutottunk, hogy kihagyjuk a buliból az illesztő áramkört. A szenzor adatlapja szerint 3.5V-ot visel el legfeljebb, így nincs sok tartalék a rendszerben, de 3.3V-ról tudjuk működtetni a 2.8V-os szenzort. A kártya lehetőséget ad, hogy csak a szenzort használjuk. Sőt, letörhető kivitelben készült a “Mini PCB”. Ilyenkor az SMD pad-ekre kell csatlakozni a megfelelő vezetékekkel. Ebben az esetben kritikusabb a felhúzó ellenállás, mivel az illesztőt nem használjuk. Miután ezt szépen megcsináltuk, bekapcsoltuk… és meg se szólalt a szenzor… Nyilván.
Itt derült fény az utolsó meglepetésre amit az API tartogatott számunkra (ez nem azt jelenti, hogy minden más tökéletes benne, csak mi nem találtunk egyebet). A szoftver (VL53L1X_api.c fájl 109 és 110 sora) alapértelmezetten a normál 1.8V-os logikai szinteket állít be. A kártyán viszont 2.8V-os feszstab található, így kb a véletlen műve, hogy működött a kommunikáció a szintillesztővel. Valószínűleg az illesztő áramkör még éppen tudta érzékelni az 1.8V-os szintet logikai 1-nek. Miután kibabráltunk az illesztővel az STM ugyanilyen feltételekkel már nem tudta a szenzor válaszát fogadni. Szerencsére elég hamar megtaláltuk a hibát, de elég meglepő volt. Ha nem akarjuk bántani a kártyát, akkor át lehet jumperelni és még felhúzó ellenállást is lehet forrasztani a kis panelre, így bármikor visszaalakítható az eredeti állapotára. Ugyanakkor kevésbé gányolás az a megoldás, ha ténylegesen letörjük az erre kialakított részt.
Ezzel az átalakítással, elég jó eredményt tudtunk elérni. Szkópon nagyon szépen mentek a jelek, és kocsin is elég jól működött. Egészen addig amíg le nem mentünk az aulába tesztelni… Ez úgy kell érteni, hogy a fenti tesztpályán nagyon sokszor szépen megcsinálta a követési és előzési feladatokat a kocsi, de amint levittük az aulába újra előjöttek a megoldottnak hitt problémák. Azt tapasztaltuk hogy az ESD sokkal nagyobb gondot okozott az aulában mint fent a tesztpályán. Ezen felül valószínűleg az emelkedő miatt nagyobb áram folyt a motorban, ami nagyobb zavart eredményezett. Sajnos ilyenkor már nem volt időnk rendesen körbejárni a hiba valódi okát, így maradt a tippelgetés, és muszáj volt megoldani a feladatot, így nem feltétlen elegáns, de működő megoldást sikerült összehoznunk.
Mivel hardveresen már csak az árnyékolás maradt ki, és többeknek ez sem oldotta meg a problémát, ezért úgy döntöttünk szoftveresen fogjuk kezelni a problémát. Az is egy külön logikát képezett a kódban, hogy kezeljük azt az esetet amikor a kocsi elnéz a safety car mellett és ki tudja milyen értéket ad vissza a szenzor, de ha feltételezzük, hogy bármelyik pillanatban lehalhat a szenzor, még egy lapáttal ráteszünk a bonyolultságára. Alapvetően kétféle végzetes hibára futhat a szenzor:
- a fentebb leírt módon beakad az I2C
- ha az XSDN lábon kap egy zavarimpulzust a szenzor, reset állapotba megy (csak sokára sikerült tisztázni, hogy valójában mi történik)
Ahhoz, hogy tudjunk hibát kezelni először detektálni kell azt. Minden adatkérés előtt le kellett futtatni a hibakeresést. A reset okozta hibát szerencsére könnyű detektálni, ha a szenzornak beállítunk valami címet (más mint a gyári) és minden mérés előtt megpingeljük, hogy ott van-e még. Ha a beállított címről senki nem válaszolt, de az eredeti 0x52-es címről válaszol akkor elég nagy magabiztossággal állíthatjuk, hogy újraindult a szenzor. Ennek kezelése egyszerű, hiszen csak újra le kell futtatnunk az inicializáló rutinunkat. Az az egy megkötés, hogy nem foglalhat egyszerre túl sok processzoridőt, hiszen a kocsi épp “száguld” a pályán, ha valahol beragad a program akkor az falat jelent. Az I2C összeomlását, blokkolását úgy detektáltuk, hogy figyeltük, hogy az egymást követő lekérdezések hányszor futnak olyan hibára, hogy foglalt az I2C (HAL_BUSY fleget kerestünk). Ha ilyet érzékelünk először reseteljük az I2C-t majd reseteljük a szenzort is, mondván, hogy ki tudja milyen parancsokat vett be a szenzor és jobb tiszta lappal indulni. Ugyanakkor a hibakezelésnél arra is figyelni kell, hogy ne kerülhessen reset loop-ba a program. Ez tipikusan akkor jött elő nekünk, ha nem nulláztuk a megfelelő számlálókat, amik a hibás próbálkozásokat számlálták. Valamint, ha valóban végzetes hiba történik, pl megszakad a kábel (hibakezelés tesztelésére lehúztuk a szenzort). Ilyenkor az lenne a biztos megoldás, ha néhány reset után az mondaná, hogy nem fog megjavulni a szenzor és nem próbálkozna tovább, mert feleslegesen terheli a processzort. Ugyan ez már a hibakezelés hibakezelése, de ha az alkalmazás megkívánja muszáj ilyenre is gondolni.
Összességében a következőket vontuk le a ToF-al kapcsolatban:
Sok hardveres hibát lehet javítani, (felhúzók, layout stb…) és annál jobb, ha minél kevesebb olyan elemet tartalmaz, amit nem ismerünk pontosan. Szoftverrel ugyanez a helyzet: Az a biztos, ha magunk írjuk és tudjuk mi miért szerepel benne és mit csinál. Végül nem tudtuk megoldani, hogy hibátlanul működjön a szenzorunk, így muszáj volt kitalálni egy megfelelő hibakezelést hozzá. Egy másik csapat (Unemployed & Single) máshogy közelített a problémához. Az I2C problémái miatt felraktak egy kiegészítő kártyát a ToF-hoz. A szenzorkártya ezzel kommunikált I2C-n, ez a kártya pedig RS422-vel (soros port) a központi egység felé. Saját bevallásuk szerint nem volt semmi problémájuk a szenzorral.
További tanulság számunkra egy általunk véletlenül észrevett feature. Amennyiben a ToF szenzort 90 fokkal elforgatjátok az iránykarakterisztikája alkalmasabb lesz a versenyen kért követési és utolérési manőver elvégzéséhez (amennyiben a szenzor ROI beállításait gyári értéken hagyjuk). Ellenkező eseteben oldalirányban nagyon sok tereptárgyat észlelhet a szenzor.
ESP kommunikáció, lámpa animációk
A fő “nagy” nyákon kapott helyet egy ESP32 WROOM modul, amit kezdetben csak kommunikációra szántunk. Ennek a szerepkörét idén bővítettük:
- kezelje a lámpákat, animációkat (LED-ek frissítése, animációk kirajzolása)
- minden nem változó adatot (AP csatlakozási adatok, animációk) egy fájlrendszerben tároljon külön a fő kódtól
- egyéb funkciók: STM újraindítás és kikapcsolás (ha például lefagyna a kontroller)
- ne csak telefonról, hanem laptopról is lehessen könnyen kezelni (parancsfordítás)
- nem utolsó sorban lehessen PC-ről frissíteni az STM kontroller firmware-ét
A kommunikációt idén is egy WiFi (Telnet) -> UART megoldással oldottuk meg, annyival bonyolítva, hogy parancs esetén nyilván értelmezze és ne továbbítsa azt. Erről bővebben a tavalyi cikkünkben olvashattok.
A ledek vezérlésére az ESP RMT preifériáját használtuk. Ez egy adott sebességgel küld ki impulzusokat (most 1MHz-en) és az impulzusok szélessége alapján mondja meg, hogy az adott bit 1-es vagy 0-ás értékű. Az animációkra egy külön task készült, ami 100Hz-es képfrissítéssel rajzolta ki az animációkat. Ezeket a gyors fejlesztés érdekében nem direktben lekódoltuk, hanem a belső flash memóriában létrehozott SPIFFS partíción tároltuk és onnan töltöttük be, mint szöveges állományt. Így egy szövegszerkesztővel írhattunk percek alatt új animációkat. Ezeket az utolsó sorral egymás után lehetett továbbfűzni bonyolultabb animációk megvalósításához (pl: rendőrségi villogó).
Biztonsági funkciónak került be egy újraindítás, amivel ha a fő kontroller (STM) valami hibára futna, akkor ne kelljen utána futni és levadászni a folyosón. Szerettük volna a DFU programozást is implementálni, de sajnos több napos próbálkozás után valamilyen kommunikációs hiba miatt ezt nem sikerült. Értsd: a DFU programozás működött, de az ESP UART-ja nem fogadta az ACK byte-ot. Ezzel nem kellett volna minden firmware módosítás esetén rádugni a programozót, hanem a fordítás után automatikusan feltölthette volna a kódot a kocsira.
3D nyomtatás pro és kontra (írta: Hava)
Mint a verseny során is szóba került: ebben az évben két kocsit építettünk. Ezt a kis csapaton belüli versenyt egymás maximális támogatásával, a problémák közös megoldásával valósítottuk meg. A két kocsi elektronikailag ~97%-ban azonos, mechanikailag különböző. Itt jegyezném meg, hogy a mechanika azonban azonos elvek alapján készült. Minden fejlesztést tartalmaz a Tesla amit az idei Bruce, a különbség csupán a platform amin végrehajtottuk az építkezést. A verseny során a Teslát láthattátok a pályán.
Mit érdemes 3D nyomtatni mit CNC-zni? Mint tudjátok a rendelkezésünkre álló SEM-es CNC gép 3 tengelyes, így nagyon sok alkatrész elkészíthető vele, azonban megvannak a korlátai. A mechanikai célok között említett ferde csapszegekhez ferde csapágyház társul. Ezen bonyolult geometria kimarása CNC-felhasználásával szinte lehetetlen. Úgy vélem egy ilyen komplex mechanika megépítéséhez mindkét gép segítségére szükségünk lehet. A nagy elemeket, amelyek geometriája egyszerű érdemes CNC-zni, ez mind időben mind minőségben páratlan eredmény hoz, azonban a finommechanikát érdemes nyomtatni. ABS lemez vágása a CNC-hez hasonlóan lézervágóval is lehetséges, ez kiváló alternatívát jelenthet számotokra.
A főbb vázszerkezeti elemek CNC használatával kerültek kialakításra mindkét kocsi esetén.
A finommechanikát nyomtatással készítettük el. A verseny halasztása lehetőséget nyújtott számomra, hogy megkíséreljek darabonként kinyomtatni egy teljes karosszériát. 😊
A 3D tervezés fontosságát úgy vélem a fentiek olvasatában már meg sem kell említenem. 🙂
Kész a szekér
Bruce
Tesla
Sikeres kvalifikációk után
Verseny
Végül a versenyen, két hét halasztást követően a Tesla kocsi indult. Sajnos az első szervókar a második előzés után / közben meglazult és a kanyar után leesett, ezért a lejtőn a falnak ment. Ezt sajnos pillanatnyi pánikunkban nem fedeztük fel és naivan visszatettük a vonalra. Ezután mint láthatjátok, nem vette a következő kanyart és újabb ötlet híján inkább megelégedtünk a köridővel. A dologhoz hozzátartozik, hogy mint utolsó csapat, a pálya akkorra már elég poros is volt és valószínűleg nem sikerült volna a várt (és tesztelt) köridőket reprodukálni.
Végül szeretnénk köszönetet mondani barátainknak és hozzátartozóinknak, hogy elviselték a megszállott készülődést és támogattak, amiben tudtak. Nem utolsó sorban megtiszteltetés, hogy ennyien szavaztatok ránk a közönség soraiból 🙂
