Előző versenyünk után ismét megpróbálkoztunk az éves RobonAUT versenyen. A cél, a tavalyi köridő rekord megdöntése volt, az ügyességi feladat teljesítése mellett.
Sajnos a rekordot nem sikerült megdöntenünk, sem a Teslára jellemző esztétikai igényességet, habár az ügyességi részt hibátlanul teljesítettük. Sokkal inkább a “monster” és az utolsó percek pánikja szülöttjének meglepően életképes valamije sikerült, de ennyire ne szaladjunk előre!
Idei célok, a pontozás és a verseny menete:
Úgy gondoltuk tudunk újat mutatni, az eddigi eredményeinket felhasználni és persze első helyezést elérni. Ezen felül, ironikus módon szerettük volna a sebességrekordot is megdönteni, ami egy banális hibán csúszott el végül.
A verseny pontozása szolgált útmutatásul, hogy mit kell teljesíteni vagy elérni a verseny és felkészülés folyamán. Maga a verseny két részes: az első rész az ügyességi versenyszám, ahol a kocsi “okosságát” kell demonstrálni, hogy képes komplex döntések meghozására és feladatok elvégzésére. A második versenyszám pedig a gyorsasági futam, ahol a legkisebb köridő elérése és némi mutatvány (előzés, követés) produkálása a cél. Ezek mellett pedig célszerű a közönség szívét is elnyerni egy szép formatervvel, vagy egy egyedi mutatvánnyal, akármivel amivel ki tudunk tűnni a mezőnyből. Utólagos pontszámítások alapján még ha sikerül is (idén, és összességében is) a leggyorsabbnak lenni, egy ponttal így is lecsúsztunk volna a dobogóról a közönségszavazatok hiánya miatt. Persze már maga egy rekordidő is megdobogtatta volna a törzsvendégek szívét.
Honnan a név:
Bruce Banner a névadója a szörnyszülöttünknek, innen is a zöld szín, meg persze a Monster energiaitalról is ez köszön vissza. A model R, mint Tesla kódnév már csak az igazi rajongóknak mond valamit. Az egész utalást, vagy csak elszólást még Musk bökte ki a model Y bemutatója elején, utalva, hogy bővül a SEXY termékpaletta, és “SEXY-eR” lesz a Tesla: itt a videó, hogy aki nem hiszi ne kelljen utánajárnia.
Mi kell a rekordidőhöz? Fizika!
Fizikai szempontból nem kifejezetten bonyolult egy gyors köridő elérése. Menj amilyen gyorsan csak tudsz. A kérdést inkább fordítva érdemes feltenni: hol és milyen gyorsan tudsz menni? Ez nyilván a gyorsasági pálya és a jármű képességeinek függvénye, amiből csak az utóbbit tudjuk befolyásolni. Tehát első dolgom, mint a csapat fizikás tagjának, az volt, hogy utánaszámoljak ezeknek.
A pálya rajza szerepelt a versenyszabályzatban. Szerencsére referenciának (nem csak nekünk, hanem azoknak is akik ragasztják a pályát) ott voltak a csempék vonalai is. Innen egy kis AutoCAD rajz és méretezés után megkaptuk a pálya felülnézetét. A lépcsőfokokat figyelembe véve az emelkedő (lejtő) meredeksége is adott volt. Innen kis ügyeskedéssel egy pontsorozatot tudtam generálni, nagyjából egyenletes közökkel, ami a pálya pontjainak koordinátáit megadta nekünk mm-ben. Maga a pálya hossza nagyjából 55m, amit csak 314 ponttal ábrázoltam (véletlen egybeesés a pi-vel). Ami fontosabb, hogy ebből már adott állandó sebesség mellett tudtam számolni gyorsulásokat. Igazából nem volt szükség végül ezekre a pontokra. Annyi előnye lehetett volna, hogy tetszőleges pályára csak a pontokat kellett volna cserélni. Ezt át kellett volna gondolni előre.
Magát a számolást nem gondoltam túlbonyolítani szimulációval, mivel úgyis a valós próbáé az utolsó szó. Egy sima excel (LibreOffice Calc) táblázatban számoltam, ami egyben az ábrázolásban is segített. A pálya után a képzeletbeli autó paramétereit (tömeg, tapadási együttható) bevittem a táblázatba, amivel megkaptam az autóra ható erőket, és a hozzá tartozó köridőket is.
Ezek után a könnyebb kezelhetőség érdekében a pályát kanyarokra (1m sugárral) és egyenes szakaszokra osztottam, figyelembe véve az emelkedőket és a lapos szakaszokat. A kulcs a kanyarbeli sebesség maximális értéke, amit a tapadásuk korlátoz. Ahogy mondják: egyenesen mindenki tud gyorsan menni. A hagyományos képlettel, a tapadási súrlódás arányos a felületre merőleges nyomóerővel, az arányossági tényezőt pedig egy, ebben az esetben a kerekekre (gumikesztyűre) és a felületre (járólap) jellemző együttható. Ezt a tavalyi köridőnk és a csúszás alapján olyan 0.42-re számoltuk, ami nem túl kitűnő.
Az ideális megoldás nyilván az volna, ha a kerekere és a kocsira is mindig állandó erő hat. Tehát kanyarban csak centrifugális (igen, tudom, olyan nincs) erő, egyenes szakaszon pedig csak tangenciális erő hat. Sajnos ez nem lehetséges, mivel a kormányszabályozás miatt eltérünk az ideális kanyarodási sugártól (átléphetjük a minimális kanyarodási sugarat), az autó tehetetlenségi nyomatékát szintén elhanyagoltuk (amiből később volt probléma), a tapadás nem feltétlen homogén az egész pályán, és persze a hidegburkoló sem szintezett minden járólapot. Meg egyébként is, szép dolog az elmélet, de az a sok “miért nem megy” és “ez érdekes” végszava csak. Maradjunk inkább a valóság és a Q épület talaján!
A tapadásunk növelése érdekében átvettük tavalyról az impelleres megoldást. Az impeller (Electronic Ducted Fan) pedig annyiban különbözik a ventilátortól, hogy a hatásfok növelése érdekében a propellerek egy csőben vannak elhelyezve, amivel a hatásfok nagyban megnő, mivel a lapátok széle nem tud turbulens áramlást létrehozni. Ennek egyetlen “hátránya”, hogy a propeller igyekszik mindig vízszintbe állni, ezért nem használható többpropelleres légi járműveken (quadkopter), mivel azok manőverezése és végsebessége nagyban a jármű vízszinteshez képest megdöntésén alapul. Ebben az esetben ez nekünk csak előny.
A tapadás növelése légdinamikával egyáltalán nem új dolog. Sok versenyautón nem csak esztétikai elem a légterelő, hanem a leszorító erő növelésével ér el tapadási többletet (ground effect). A jó formatervvel, és áramvonalas kialakítással hasonló leszorítóerő többletet lehet produkálni. Utánaszámolás alapján, még optimista becslésekkel (optimális szárnyszög, nagy felület, max 60kmph) sem értünk volna el az 1N leszorítóerő többletet, mivel az ilyen hatások subszonikus sebességek esetén a sebesség négyzetével arányosak, így nem lett volna elég sebességünk ezek kihasználására, ezért az áramvonalasság és légterelők nem játszottak további szerepet megfontolásainkban. Ellenben az impellerek, típustól függően 1-2kg (10-20N) leszorítóerő többletet is jelenthetnek impellerenként, persze a megfelelő teljesítmény rendelkezésre állása esetén.
Számolások alapján a képletből kiesik az autó tömege impelleres rásegítés nélkül, tehát lényegtelen az autó tömege a tapadás szempontjából (legalábbis elméletben), mivel a nagyobb tömeg arányosan több leszorítóerőt is jelent. A valóságban a tapadás nem lineáris, egységnyi leszorítóerővel többet alkalmazva egységnyinél kevesebb tapadási járulékunk lesz. Azonban ahogy képbe lép egy többleterő, ami nem jár arányos tömeg többlettel (kisebb cetrifugális erő a kanyarban), az összefüggés tulajdonképpen a leszorítóerő / autó tömege hányadosra csökken. A másik nyilvánvaló paraméter pedig a tapadási együttható. Harmadik kritikus pont pedig a maximális végsebesség, amit el kell tudnia érnie a motornak az egyenes szakaszokon. Ez nekünk olyan 50kmph lett volna amit 1.1sec alatt ért volna el az autó, aminek a gyorsulása megegyezik egy 2.3 másodperces 0-100-ra gyorsítással. Az alábbi táblázat tartalmazza a maximális köridőket a tapadási együttható és a F/m (impeller általi extra leszorítóerő / autó tömege).
Impellerre a választásunk egy kellően nagy tolóerejű (>10N), 3-4 Li-po celláról hajtható (~800W x2), lehetőleg soklapátos verzióra esett. Szempont volt, hogy ne kínából érkezzen, nem volt egy hónapunk a csomag megérkezésére, mivel a gyártó nem adott hozzá mechanikai terveket. Ezt nekem kellett lemérni. 20N extra erő, egy 3 kg-os kocsi esetén (tavaly volt 2.8kg) max. 11.21-es köridőt jelentene elméletben. Nekünk elég volt valahol 14-15 sec körül is, a többi jó biztonsági tartaléknak. Másik paraméter ebben az autó tömege, amit az F/m arány növelése érdekében érdemes minimalizálni.
A választásunk végül: egy ChangeSun 64mm EDF 12 lapát (nyilván kínai másolata)
Motorvezérlőnek pedig egy 80A repülő ESC: SkyWing 80A (ez is valami kínai megoldás)
Mechanikai tervek
A tervezési szempontok a következők voltak:
- legyen lehetőleg könnyű (a tavalyi alu váz szükségtelenül merev/nehéz volt)
- hátsókerék kormányzás a könnyű manőverezéshez
- impellerek nagyjából középen
- alacsony súlypont, szintén a manőverezés érdekében
- elnyelje a rezgéseket, legyen rugalmas, ne törjön
- elég merev az exta nyomóerő elviselésére és oldalirányú erőkre kanyarban
Alkatrészek részletes rajzai, részben a kapott Strada XT, és egyéb kapott/vásárolt alkatrészek
A váz tervei AutoCAD-ben készültek, mivel ebben vagyok járatosabb (ismerem a bill. kombinációkat és a programhibákat). Első pár nap a megtartandó alkatrészek bevitelével telt, amit egy sima tolómérővel végeztem. Ezen adatokkal felvértezve a kellően pontos vázszerkezet elméletben adott volt, az alapanyaga ellenben kétséges. Eredeti naiv elképzelésünk szénszálas lemez lett volna, ami könnyű, rugalmas és kellően nagy a szakítószilárdsága és a töréshatára. Sajnos ilyet magyarországon szinte lehetetlen beszerezni kellően nagy (30x45cm) táblában, nem beszélve az áráról. Kicsivel olcsóbban, és rosszabb paraméterekkel (nagyobb sűrűség, törékenyebb) felmerült az üvegszövet + epoxy gyanta (amit általában FR4-nek hívunk). Ezt már könnyebb lett volna beszerezni, ha hajlandóak vagyunk sokat költeni. Megjegyezném, hogy a keresésben sokat segített a makeitfrom oldata, ahol részletes adatok vannak a különböző anyagok fizikai tulajdonságairól. Innen egy viszonylag gyakori anyag az ABS műanyag merült fel, mivel nem kifejezetten törékeny és sűrűség / szakítószilárdság aránya megfelelt nekünk. Azzal nem számoltunk, hogy kis országunkban nem olyan egyszerű ilyen dolgokat (sem) beszerezni. Eredeti tervekben még 2mm-es lemezekkel számoltunk, viszont az anyag puhasága miatt inkább 3mm-es lemezeket vettünk végül.
Azzal érdemes számolni, hogy a lemez által elvezetett feszültségek hogyan, milyen helyeken koncentrálódnak a lapban. Lesznek olyan pontok a vázban, amik érdemben nincsenek terhelve, ezért csak holt terhet jelentenek. Ezen pontok meghatározásához, a váz kikönnyítéséhez a lemezek körvonalai kellettek az előzetes tervekből. A terhelésteszteket szerencsére mára elég könnyű elvégezni számítógépes szimulációval, mivel sok eszköz áll a témában képzetlenebbek részére is. A választásom a már CNC-s munkánból ismert Fusion360-ra esett, amivel akár generatív tervezést is végezhettem volna, bár ebben a konkrét esetben túl sok volt a premfeltétel, egyszerűbb volt csak a tesztelést itt végezni. A terhelőerőket beállítva (az érték jelen esetben nem fontos) a program megmutatta a váz anyagában fellépő feszültségek nagyságát (piros a nagyobb feszültség). Ahol a terhelés hatására nem keletkezik feszültség akár el is hagyhatók, mivel nem képviselnek jelentős tartást (adott irányú terhelés esetén). A többféle terhelést külön modelleztem, majd később ezeket egymásra helyezve (feltételezve az anyag linearitását) megkaptam a valós helyzetben jelentkező terheléseket (nyilván ami lényeges számomra).
Az alul látható viszonylag nagy kivágás a T alakban elhelyezett akkunak, hogy így könnyen cserélhető legyen alulról. Ezzel ugyan meggyengül a váz, amit a nagyobb akku-fedőlemezzel kompenzáltam. Adva a stressz eloszlást, a kikönnyítést el tudtam végezni, és ebből a program már tudott számolni térfogatot, amiből anyagválasztás után adódik a tömege a vázszerkezetnek. A két lemezt 7 borda kötötte össze, ami tartotta az akkut, a szervókat és biztosította a váz merevségét.
Sajnos 8mm-es műanyag, amiből a bordák lettek volna nem igazán volt nekünk. Ami volt, az egy névlegesen 8mm-es (7.5mm) polikarbonát (PC) lemez, amiből készült a prototípus. Ez azonban nagyon törékeny és nehezen fúrható volt. Egyik darabba koknrétan beleolvadt majd tört egy fúrószár, a kiműtésébe pedig a borda tört bele. A végleges megoldás 3 réteg ABS lemez volt (9mm lett végül). Itt inkább külön kivágtuk a három réteget, mivel a benne lévő lépcsős csapágyházat így egyszerűbb volt kialakítani. A három réteget végül pillanatragasztóval ragasztottuk össze, ami meglepően stabilra sikerült.
A vonalszenzort megtartottuk a korábbi évekből, ez kellően “okos” (erről később lesz szó) volt a céljainkhoz. A kormányművet megint csapágyaztuk, és viszonylag gyors szervókat terveztünk bele. Tavalyról maradt még egy SRT CH6012-es coreless szervónk, 50ms/60° sebességgel. Hátulra, mivel volt még tanszéki keretünk egy BH9022 BLDC szervó került, szintén 50ms/60° sebeséggel. A tavalyi szervó sajnos (érthető módon, sokat nyúztuk) januárban megadta magát, a kefe elkopott benne, aminek következtében a benne lévő félhídmeghajtó felsőoldali FET-jei zárlatba égtek. Érthető módon tavaly is ezzel gyakoroltunk, elhasználtuk. Dávid csapattársamnak ugyan sikerült megjavítania: egy másik szervóban talált azonos “szén”kefét hozzá, és a gyárihoz hasonló dual-FET-et is sikerült beszerezni, amivel újra működőképessé varázsolta a motort, de a szervó a bizalmunkat már elvesztette. Ezért még a javítás előtt beneveztünk mégegy BLDC szervóra, és mivel volt idő, viszont tanszéki keret nem, így Szlovákiából rendeltünk (olcsóbb) egy BH8015 szervót.
Az ütközőhöz a tanszékről kaptunk PU (poliuretán) habot, amit a műhelyben kivágtunk két méretben a CNC-vel. Ezt a más helyen is használt szénszálas rúd távtartókkal rögzítettük, átmenő csavarokkal. A rúd belsejében (3mm) futottak az átmenő M3-as csavarok. A végén távtartókkal, amire a vonalszenzort rögzítettük. Omptimistán először a kisebb ütközőt szereltük fel, majd az első ütközést (törést) követően jobb belátásra tértünk, így nem lett több törésünk.
Kormányműnek egy ackermann-féle kormányművet szerettünk volna szimmetrikusan. Tehát a kocsi eleje hátulja szimmetrikusan lett volna vezérelhető, ez nem teljesen ideális ugyan, hátsó kerékre nézve, de kellően puha gumival a slip szög ezt tudja korrigálni. Hátsó kerék kormányzással a minimális fordulókörünk sugara nagyjából 0.3m lett, ami elég gyors kormányzást/korrekciót tett lehetővé. Az alacsony súlypont érdekében a szervók a két lemez közé kerültek, úgy, hogy az akksi a szervóra fel tudjon feküdni. A kormánymű alkatrészeit 1.6mm-es nyáklemezből martuk ki CNC-n egy 2mm-es kontúrmaróval. Sajnos a megoldásunk (bronz betétek) miatt egy kis (~0.5mm) holtjáték került a rendszerbe, de az nem jelentett problémát az egyébként jó kivitelezés és csapágyazás miatt. Az akkutartót pedig egy satu, egy lapos falemez és egy hőlégfúvó segítségével hajlítottam a megfelelő alakra. A vázat pedig elég magasra kellett tegyük, hogy az emelkedő elején és végén se érjen le a kocsi, hasa és a vonalszenzor. Az eredmény beszéljen magáért!
És persze robbantott ábrák is kellettek:
Amit későn vettünk számításba, hogy az akku T alakja, a motor hátsó elhelyezése, a nagyobb szervó és a kamera elhelyezése miatt a kocsinak a súlypontja nagyban a hátsó kerékre tolódott el, ezért sok esetben hátsókerekes autóként viselkedett. Ezt lehet látni a lenti tesztvideóban is, ahol a kanyarban sokszor kifarolt, ami egyrészt a hátsókerék terhelése miatt adódott. A másik nyilvánvaló oka, hogy nem tapadt a kocsi eléggé. Végül, amit nem implementáltunk, hogy a hátsó kerekeknek sebességfüggő (távolságfüggő) fáziselőnye van az első kerekekhez képest, ezért kanyarban nagyobb forgatónyomaték hat a kocsira (mint szükséges volna), ami miatt az első kerekek, majd a hátsók is megcsúsznak és a felhalmozott impulzusmomentum miatt tovább pörög a kocsi a tömegközéppontja körül. Néha akár teljesen meg is fordult. Ezt ki lehetett volna küszöbölni, ha figyelek a tömegeloszlásra, és egy megfelelő késleltetéssel vagy egy szoftveres, giroszkópra alapuló forgatónyomaték minimalizálással. Az utóbbit nyilván nehezebb lett volna, cserébe jobb lett volna a vonaltartásunk.
Végül egy rövid videómontázs a készítésről és hogy miért volt szükség nagyobb ütközőre:
Központi elektronika és vezérlő szoftver (írta: Havasi Dávid)
Központi vezérlőegység tervezése
A tervezés első lépéseként úgy vélem minden esetben meg kell fogalmaznunk elvárásokat, követelményeket, melyek végigkísérhetik, segítik a tervezés és a kész termék validációjának folyamatát. Ezen követelmények lehetnek kötöttségek, melyek meghatározzák döntéseink főbb pontjait, de lehetnek olyan elvárások is melyek kiterjesztik lehetőségeik határát. Elsőként szeretném számba venni azon követelményeket, melyek megadták ezen jármű központi moduljának alapját.
- Révén nem első alkalommal versenyeztünk, elsődleges szempont volt számomra a régi autónkkal való kompatibilitás. Ennek megfelelően a központi vezérlőegységet STM32F446RE megtartottam és konfigurációs állományát igyekeztem a lehető legkisebb mértékben megváltoztatni. Ezen törekvés a tervezés első fázisaiban sikeresnek bizonyult, később viszont a funkciók nagyszámú bővítése okot adott a mélyebb konfigurációváltoztatásra. A két éven át írt szoftverünk kis módosítások árán portolható volt az új eszközre
- A régi autónk “Tesla 1” elektronikai felépítésével nagyon jó tapasztalatunk volt, azonban egykori tapasztalatlanságunkból fakadóan nem sikerült az áramkört elektronikai szempontból optimalizálni és minimalizálni.
- a nagy számú aluldokumentált PCB lemez és kábelrengeteg nehézkessé tette a javításokat és megnehezített a hibakeresést
- A Bluetooth-os kommunikáció megbízhatatlannak bizonyult, mind sebessége mind a csatlakoztatási problémái miatt
Az új egységgel szemben támasztott főbb elvárások:
- átgondolt egyszerű felépítés
- 15-20V-ig terjedő bemeneti feszültség (3-4C LiPo battery)
- 3 fázisú 200A-es motorvezérlési lehetőség 😀
- megbízható WiFi lapú nagysebességű kommunikáció
- integrált MEMS
- dedikált, egységes felépítésű konfigurálható kijáratok a szenzorok számára
- 50x100mm.es nagyság, 4 rétegű stackup
A központi vezérlő főbb részei
- Tápegységek
A tanszék által javasolt áramköri felépítést újfent átalakított formában az áramkörünk idén is 1db 3-4S LiPo akkumulátorról üzemelt. Ezen akkumulátor látja el feszültséggel mind a motorvezérlő rész félhídinvertereit, mind azon DC/DC konvertereket, melyek biztosítják a szenzorok és a központi vezérlő egység számára a szükséges tápellátást. DC/DC konverterek terén a választásom ebben az évben is az ST ST1S10-e konvertereire esett. Ugyan ezek kimeneti áramterhelhetősége csupán 3A, mely a szervók számára kevésnek bizonyulhat, azonban rendelkeznek két fontos előnnyel. Ezek közül az első és egyben legfontosabb, hogy nem robban fel amennyiben a kimenetét túlterheljük, továbbá rendelkezik beépített előtöltési funkcióval. Ezek alapján a kimenet indokolatlannak tűnő bufferelésével egyszerűen fedezhető a nagyáramú szervók hirtelen gyors mozgásához szükséges áramimpulzusai.
A tápegységek megválasztása és méretezése minden esetben kritikus folyamat. Ne feledjük, a nagy kimeneti kapacitív terhelés hatására több tápegység nem képes beindulni. Amennyiben jól választunk ezen terhelést természetesen kompenzálhatjuk a kompenzációs bemenet diszkrét elemeinek megfelelő méretezésével, esetenként a kapcsolási frekvencia módosításával. Természetesen minden döntésnek ára van. A nagy frekvencia zavarhatja áramkörünket, noha a felhasznált elemek méretét jelentősen csökkenti (nagy áramok esetén praktikus lehet). A nagy áramú tápegységek (esetleg külső FET félhidas megoldások) zajosak lehetnek. Természetesen ez is kompenzálható… Az optimum megtalálása minden tervezési folyamat alapja.
A nyákon tehát 3db egyenként 3A-es tápegység foglal helyet (3V3, 5V , 7,2V) melyek kimenetére egy visszajelző LED-et tettem. Apróságnak tűnik, de a vizuális visszajelzés a szervónk átégésekor megmentett az áramkörünket. Az “egy LED-re mindig szükség van!” elvet természetes a kontroller esetén sem felejtettem el. 🙂
Gondoljuk át ezen tápellátás előnyeit. A bemeneti feszültség legrosszabb eseteben 3S esetben 9.6V-ra süllyed. A LiPo akkumulátorok ekkor már nem érzik jól magukat (3.2V-os cellánkénti feszültség, megközelítőleg 10%-os kapacitás ) azonnali eltávolításuk és töltésük indokolt! Alámerülés esetén a cellák felrobbannak, az akkumulátor tönkremegy. (A cellák feszültségét egy külső egységgel is figyeltük “LiPo-őr” mely sípolni kezdett, ha bármelyik cella a beállított küszöbérték alá süllyedt.) Ebből láthatjuk, hogy a DC/DC konvertereinknek minden esetben elegendő bemeneti feszültség áll a rendelkezésére a megfelelő kimeneti feszültségek stabil előállításához. Amennyiben az akkumulátort megfelelően válasszuk meg, a motor által felvett áram nem képes a kimeneti feszültségét jelentős mértékben megrántani, tehát nem kell tartanunk a kontrollerünk újraindulásától. (Természetesen az esetleges pillanatszerű feszültségkimaradásokat az áramkörben található bufferkapacitások segíthetnek “áthidalni”)
- Beépített és külső perifériák
A vezeték nélküli kommunikációt egy ESP32 wroom modullal oldottuk meg. Konfigurációja szerinte az STM32-es központi vezérlő egy UART portját továbbította minden rá csatlakozó eszköz számára, továbbá minden csatlakoztatott eszköz felől lévő forgalmat visszamásolt az STM32 felé. A kommunikációt rajta keresztül TCP-n TELNET segítségével valósítottuk meg. Ezáltal soros terminálból vezérelhettük a központi egységet (hasonlóan a tavalyi megoldásunkhoz) de ezúttal továbbfejlesztettük a vezérlést egy könnyen bővíthető és konfigurálható menürendszert létrehozva.
Az odometria alapját egy ST-LSM6DS3 MEMS szolgáltatta számunkra, erről bővebben esik szó az pályaalkotás taglalásakor.
A távolságmérésről ezúton is SC-SR04-es szenzorok gondoskodtak, idén két darab került a kocsi orrára, melyeket ezúttal nem forgattunk. A szenzorokból jövő adatokat a vonalszenzor által mért “hibaszög” alapján súlyoztuk, így tehát minden eseteben a kanyar belső íve felé láttunk jobban (a felvezetőkocsi ebben az irányban lehetett látható számunkra)
A vezérlőkártya kompatibilis mind a standard nagyfelbontású (fordulatonként 256-4096 inc),mind a 3 fázisú motor által kiadott 3 csatornás (fordulatonként 6 impulzus) enkóderrel
A motor fázisfeszültsége, az akkumulátorok aktuális feszültsége kompenzált ADC -en keresztül került visszamérésre. Ezen felül természetesen megtalálhatóak voltak a standard Servo ki és bemenetek, védett SPI és I2C perifériák is a csatakozók között.
A PCB talán legmókásabb része a 3 fázisú 200A-es inverter volt. Célom volt, hogy mindez nagyon kis helyen férjen el, semmi esetre se emelkedjen 30 fok felé (hűtés nélkül), továbbá, hogy 20V-os bemeneti feszültség mellett is üzemelhessen. Az árammérő betervezése esetén a PCB design jelentősen kevesebb áramot lett volna képes elvezetni, ezért a végső designba nem került bele. Az árammérés ezzel párhuzamosan tehát a nyomatékszabályozás ebben az évben nem valósult meg. Szükség esetén természetesen ezen hiányosság egy külső áramkör megtervezésével orvosolható lett volna, de ezúttal a külső, egyhurkos fordulatszám szabályozás mellett döntöttem. Mindez hasonlóképp mint a tápegységnél egy véget nem érő optimalizálási feladat volt. A tesztek igazolták mind a layoutdesign mind a kapcsolás helyességét.
Történt egyszer, hogy egy vezérlési hiba folytán a motoron 10cm távolságból már hússütésre alkalmasnak bizonyult, a motorhoz menő kábelek felizzottak és a nagyáramú csatlakozók kellően felmlegedtek…. A motorvezérlő mindeközben melegedés nélkül szemlélte az eseményeket… 🙂
A motorvezérlő ellenőrzőmérései (2F és 3F motorok esetén)
A túllövések kizárólag a labortápról való járatásból erednek, akkumulátor használata során megszűntek.
Sebességszabályozó algoritmus
A sebességszabályozónkat az AUT tanszék szabályozástechnikai szemináriuma alapján készítettük el. Az ajánlott szabályozó felépítése és szabályozási algoritmusa az a következő ábrákon látható.
Mit is látunk pontosan? Melyek azon zavaró hatások, melyeket egy saját motorvezérlő tervezésekor elhanyagolhatunk? Mik a jó paraméterek a szabályozás beállításához?
Kezdjük az elején… Az ábrán egy FOXBORO struktúrájú PI szabályozót láthatunk. A bemeneti alapjelet ‘e’ Kc körerősítéssel szorozzuk, egy pozitív visszacsatolótagon keresztül összegezzük az előző kimenettel, majd limitáljuk a kapott jelet, így kapjuk meg az ‘u’ beavatkozójelet. Eddig egyszerűnek tűnik, de hogyan válasszuk meg a paramétereket? (levezetés lást AUT szabályozástechnika szeminárium jegyzet)
Jelen esetben az alábbi képlet érvényes, ahol “Ts” jelöli a diszkrét szabályozó futási periódusidejét, ‘T’ pedig a PI szabályozó által kiejtendő időállandót. Utóbbit méréssel határozhatjuk meg. A rendszerem időállandóját egy közepes sebességű egységugrás (feszültség) alapjelre adott fordulatszámváltozás alapján mértem meg.
Az alábbi mérést a kocsi 10ms-os lépésközzel küldte el számunkra. A kék grafikonon látszik a kiadott alapjel, a sárgán az erre adott fordulatszámváltozás válaszjel. Megfigyelhető, hogy mind a fel mind a lefutási periódus időállandója közel azonos, 1s. A rendszer egytárolós jelleget mutat, így valóban helyes a feltételezés, miszerint PI szabályozóval szabályozható. A sebességszabályzó tehát ez alapján már könnyen beállítható lenne. Mit felejtettünk el?..
Egy dolog maradt hátra, a beavatkozójelet és a sebességalapjelet azonos dimenzióra kell skáláznunk. Amennyiben ezt a skálázást nem sikerül pontosan megcsinálnunk a kiadott sebességalapjel nem fog pontosan beállni, azonban kizárólag minimális arányos hibája lesz ami jelen alkalmazásban nem számít. Ezek alapján érdemes lehet a szabályozót (esetemben a 0-500-as) kiadható PWM jeltartományban “járatni” és a bemeneti sebességjelet, ezzel egyetemben a hibajelet ebben a dimenzióban előállítani. A visszamért sebességet átskálázva beavatkozójellé könnyen ellenőrizhetjük a szabályozó működését.
Az alábbi odometria mérés a valós versenypályán készült a versenyt megelőző estén. Mit is látunk pontosan? A szabályozó által kiadott beavatkozójel a sárga görbe, a jármű skálázott sebessége a kék, a beavatkozó jel dimenziójú hibajel a szürke görbén jelenik meg. Képzeljük magunk elé a versenypályát oly mód, hogy az autónk a fenti gyorsasági szakaszról indult. Az első és a harmadik szakaszban tehát sík terepen ment, míg a 2.-on lejtőn és a 4.-en emelkedőn. Az odometria igazolja a szabályozó helyes működését, hiszen míg a kék sebességjel minden gyors és lassú szakaszon azonos értékekre áll be, addig a kiadott alapjellel (sárga) a kocsi láthatóan kompenzálja az emelkedő és a lejtő által beintegrált zavaró tényezőt. Továbbá megfigyelhető a pólusáthelyezés és a körerősítés jótékony hatása is a kimeneti sebesség időállandójának csökkenésében. 🙂
Mit hanyagoltam el? Saját tervezésű jól méretezett motorvezérlés esetén nem szükséges számolnunk az esetleges nemlinearitással, hiszen pontosan tudjuk milyen feszültség kerül ki az inverterünk kimenetére. A holtsáv természetesen ebben az esetben sem elhanyagolható, azonban ha nem kompenzáljuk megszüntethetjük a szabályozás állóhelyzetben történő remegését, mely csendesebbé teheti a fejlesztés nyugodt pillanatait.
További fontos dolgok, javaslatok
- ha ezt a megoldást választjuk nincs nyomatékszabályozásra lehetőségünk (egyszerűségéért ezzel fizetünk). Ebben az esetben érdemes lehet a sebességalapjelet rámpázni ezzel csökkentve a megcsúszás kockázatát
- Részben a holtemberkapcsoló, részben a kocsi dinamikus mozgatásának elősegítése miatt érdemes implementálni a lökésmentes indítást. Ellenkező esetben egy újraindítás könnyen a szénkefék, motor esetleg egy gyengébb motorvezérlő életébe kerülhet.
- Az enkódermágnes pozicionálása és a szenzortól való távolsága kritikus! Amennyiben nem kerül középre nemlinearitást visz az elmozdulás és a ezáltal a sebességmérésbe, mely instabillá teheti a szabályozási kört
Szoftveres megoldások, telefonos kezelőfelület
Két teljesített verseny után első gondolatként úgy véltem, nem lesz sok dolgom a központi vezérlő szoftverével. Természetesen nem lett igazam, így a félév során 70%-ban újraírtam a kódot. (mint tudjuk sosincs kész projekt, csak túl közeli határidő!) A szoftver felépítéséről az előző cikkünkben már beszámoltam, így most kizárólag azon lényegi változásokról szeretnék beszélni, melyek hatalmas segítséget jelentettek számunkra a felkészülés során. Ez pedig azon kezelőfelület melyen a kocsival kommunikáltunk.
Az előző évhez hasonlóan ebben az évben sem volt célunk grafikus megjelenítést alkalmazni, hiszen ez túl nagy kötöttséget jelentett volna számunkra az interfészek megírásakor. A kommunikációt ezúttal 3 részre bontottam és funkcióit minden perifériavezérlő szoftveregységbe implementáltam. Ezen 3 funkció a flag beállítás, a stream adatkérés engedélyezése, továbbá a paraméterállítás lettek. Ezen beállításokat soros terminál segítségével egy menürendszeren keresztül kezelhettük. A felépítés előnye, hogy a kocsi aktuális működésének teljes átalakításához nem szükséges újabb programkódot felégetünk, minden funkció valósidőben testreszabható és minden perifériavezérlő 40ms- ként valós időben logolható. A kimeneti adatokat egyszerűen áthelyezhettük excel tábláblázatba, melyben grafikusan ellenőrizhettük a kocsi belső működését, a nyers adatokból validálhattuk számításainak helyességét.
A versenyen sajnos ez okozta a vesztünket, az egyik flag alapértéke rossz állapotban maradt, ezért a kocsi elfogadva azt a tényt, hogy a sebességalapjelet a távirányító szolgáltatja így nem állította be automatikusan a sebességét a látott vonaltípusoknak megfelelően…
——– End of Hava Sessions ——-
Vonalszenzor V1.2
A vonal látása a verseny szempontjából kulcsfontosságú, úgyhogy nekiálltam kiterjeszteni a jelenlegi hardver szoftveres korlátait. Tavalyi megoldásunk lényegében nem tért el egy standard vonalszenzortól. Röviden a vonalszenzor beolvassa az infradiódákon beállt feszültséget, és ha a küszöbérték felett vannak az adott diódáktól kiolvasott értékek, akkor abból súlyozott átlaggal egy pozíciót határoz meg. Az egész korlátja, hogy a hardvertervezési segédlet szerint 140us kell a diódákon a feszültség beállásához. Nyilván jobban kitérnek a témában erre, viszont tévesen (vagy nem egyértelműen jelölve), nem az infraledeknek kell idő (töltés), hanem a visszaverődést érzékelő fototranzisztoroknak.
Az ötlet abból adódott, hogy túl nagy padó-szenzor távolság esetén a beolvasott kép (vonal) dinamikus tartománya sokszor a zajszint alá csökken, a fugát és a vonalat nem lehet egyszerűen megkülönböztetni (ezért falnak megy a járművünk például). Milyen jó volna, ha többet látna a szenzor, nem csak az általában adott 12bites ADC értékeket vehetnénk számításba, hanem ezt a dinamikus tartományt valahogy bővíteni tudnánk. Itt dinamikus tartomány alatt a fotózásban megszokott módszert kívántam alkalmazni, vagyis, hogy több képből építem fel a végső képet, közben pedig változtatom az expozíciós értéket. Ehhez először is észre kellett venni, hogy a fototranzisztorok kapacitív elemként viselkednek. A ledeknél ez nem jelentkezik, ott 25ns-alatt beáll az áram (saját mérés alapján). Ellenben a fényérzékelő elem áramtól függően 5-200us idő alatt áll be konstans feszültségre, amit megmérünk. A hagyományos módszerrel csak az a probléma, hogy egyetlen méréssel kidobjuk a sok információkat amit a szenzor nyújthatna számunkra. Másik jó megoldás lehetett volna a ledek áramának vezérelhetősége. Ezt ugyan korlátozottan megvalósítottam, a ledvezérlők referencia áramának módosításával (FET-en keresztül sönt áramot kapcsolok ki-be). Bár ez elég korlátozott, mégis több mint a semmi.
Másik dolog, hogy a szomszédos ledek áthallást okoznak, így elmosódottabb vonalakat kapunk. Ezt a megfelelő, a következő és az azután felvillanó led lehető legtávolabbi megválasztásával lehet minimalizálni. Ez konkrétan 8-as led-csoportokkal a 1-5-2-6-3-7-4-8 sorozatot jelentette.
Az optimális megoldás az lett volna, ha a fototranzisztor időállandóját tudtam volna meghatározni, ami azonban valószínűleg lassú lett volna, mivel a felhasznált STM32-ben nem volt hardveres lebegőpontos szorzó. Másik heurisztikus megoldás, hogy a jelalakot numerikusan integrálva kapok egy számot, ami szigorúan monoton függ az időállandótól. Tehát nagyobb időállandóra mindig nagyobb értéket ad majd az integrál, kisebb időállandóra pedig mindig kisebbet. Szerencsére az STM ADC (Analóg-Digitális konverter) mintavételi ideje 1us, tehát lényegében a jelalak változatlan a mintavételi időben, de legalább is elhanyagolható az 5-200us intervallumban, ha integrálunk mindenképpen.
A mérés 5us időközönként zajlik, 15 alkalommal (vagy 30, beállítás kérdése), összesen 75us (150us) ideig. Ez idő alatt integrálja az egyes diódák feszültségét. Majd ugyanezt megismétli nagyobb fényerőn is, remélve hogy a nagyobb fényerőn az érzékelt adat nem lineárisan változik, hanem mondjuk bizonyos pontokban beég a kép (telítődés), máshol pedig a sötétebb részletek kirajzolódnak. A végleges verzióban ugyan nem is használtunk, csak egyetlen fényerő beállítást, mivel ez is kellően robosztusnak bizonyult.
A másik lényeges újítás a képfeldolgozásban rejlik. A fix küszöbérték helyett érdemesebb dinamikatartomány (max érték – min érték) szerint változtatni a küszöbértékeket. Nagyobb magasságban a dinamikatartomány leesik, kis magasságban nagy lesz, de ez nem lenne szabad befolyásolja az érzékelés pontosságát. Ez az elgondolást ott problémás, hogy a dinamikatartomány egy zsákutca vagy vonalvesztés esetén is alacsony lesz, ilyen esetben sajnos vissza kell térjük valamennyire egy fix küszöbértékhez, minden más esetben sokkal megbízhatóbbnak tapasztaltuk a szenzor adatait. A méréseket terepen végeztem, a kocsit végigtoltam/vezettem a vonal felett, a nyers beolvasott adatokat pedig egy táblázatkezelőben értékeltem ki az algoritmus és a küszöbértékek meghatározásához.
Két fontos érték adódott egy mérésből. Az első a dinamikatartomány, a második az átlag. Ebből a két adatból tudtuk megkülönböztetni a semmit sem látunk eseményt (vonalvesztés), a mindent látunktól (zsákutca). Mindkét esetben a dinamikatartomány leesik, de 10000 alá csak a fenti két esetben. Ha nem esik le, akkor látunk valami vonalat, ha leesik akkor pedig az átlagból meg tudjuk mondani: ha nagy az átlag, akkor zsákutca, ha kicsi akkor pedig nem látunk vonalat. Ezeket a küszöbértékeket még az utolsó esete is utánahangoltuk, hogy pontosabban érzékeljen. Még egy biztonsági megoldás azért került bele, ugyanis lehetséges, hogy ferdén ráhajtva a zsákutcára csak egy szeletet láttunk belőle, viszont ez a szelet is szélesebb mint egy átlagos vonal, vagy ha merőlegesen hajtunk rá, akkor is a különböző kalibrálatlanság (nem lehet tökéletesen kalibrálni) miatt nem egyszerre lépik át a küszöbértéket, sok vékony vonalat bejelezve. Erre a megoldás, hogy ha túl széles a vonal, vagy túl sok fototranzisztor érzékel valamit egyszerre, akkor zsákutcát jelzünk ebben az esetben is.
Az eredmény, hogy a szenzor napfényben is 1-5cm magasságban kielégítően észlelte a vonalakat, ami szerintem kielégítő eredmény. Habár ha megint indulnék, inkább gépi látással dolgoznám fel a vonalakat, ami megbízhatóbb vonalészlelést és pozícióadatokat biztosítana, nem beszélve a rugós felfüggesztés megtartásáról, amit csak a vonalszenzor miatt kellett elvetnünk (és a többi csapatnak is). Azt hiszem megérte az a nagyjából 30MB mérési adat, és >30 excel tábla, ami erre elment.
Ügyességi pálya: Labirintus, megint
Tavaly egy majdnem ugyanilyen feladat volt. Akkor nem sikerült az algoritmus, mint írtam is, megbukott a lokáción az algoritmus. Most kicsit bonyolultabb lett a csomópontok felépítése, és volt zsákutca is (kettő is a kvalifikáción). Ezt leszámítva nem sok elvi változás történt. Mivel tavaly nem számíthattam helyadatokra, ezért azt a megoldást, vagyis a vonalszakasz mérést, orinetációt (iránytű) és kapuszámot szerettem volna felhasználni a csomópontok azonosítására. Pár oldal füzetoldal és nap próbálkozás után rájöttem, hogy a feladatot túlságosan is megnehezíti a rengeteg információ szűrése. Nagyjából minden adatunk egyezése lehetséges, kivéve a csomópontok elhelyezkedése nem eshet egybe. Lehet azonos elágazással, azonos orientációval és azonos megelőző vonalhosszal is csomópont, és akkor a korábbi csomópontokat is figyelembe kellene venni, de ott is lehet egyezés, bár nem valószínű. Ekkor jön a képbe a meglévő adatok integrációja, mikor tudom azt mondani, hogy a két csomópont azonos, és körbeértünk a pályán. Ez mind megbonyolította volna az algoritmust, ezért úgy tűnt, hogy még az odometria kikalapálása is egyszerűbb feladat volna. Ezért megbeszéltük, hogy ez mindenképpen kelleni fog, és mindkét oldalon (odometria és navigáció) segítjük a másik algoritmust. A navigáció reseteli a pozíciót, az odometria pedig visszahúzza az egyeneseket, ezzel kiküszöbölve a transzlációs (eltolásos) és a rotációs (elforgatásos) hibákat.
Az algoritmus két részre tagolódott. Az első a tavalyi vonalszakasz felismerőnek az erősen módosított és személyreszabott változata volt. Ennek feladata a csomópontokba érkezés és elhagyás detektálása volt. Csomópontnak kényelmesen az számított ahol a több vonal volt, és távolságuk kisebb volt egy küszöbértéknél. Ez névlegesen a csomópontokban 3.8cm, de ennyi nyilván nem lehetett, mivel a vonalszenzor is lehet kicsit tévedhet, ha ferdén hajtunk a csomópontba (becsatlakozás), akkor is távolabbra esnek (a mi perspektívánkból) és ha kicsit ugrál a vonaltávolság, mondjuk a küszöbérték körül akkor véletlenül többször is érzékelhetjük a csomópontot. Túl nagy sem lehet a távolság, mivel akkor túl hamar érzékelnénk a becsatlakozást és túl későn a leágazást, és mivel ekkor döntjük el, hogy melyik irányba haladunk tovább, így a kormány ebben a pontban hirtelen vált, ezért megcsúszhat. Egyéb feladata a vonalfelismerőnek, hogy regisztálja a beérkezéskor a pozíciót, orientációt (90° többszörösét: 0-3, 0°-270°) a csomópont hosszát mm-ben, a be- és kimeneti leágazások számát, hogy melyik vonalon mentünk be, melyiken vagyunk éppen a csomópont közben és végül, hogy milyen vonalszenzor értéket (vonalat) kell követnie a kormányszabályozónak. Egyéb funkciók is helyet kellett benne kapjank: például egy esemény tiltás arra az esetre mikor visszatolatunk, vagy ha vonalat akarunk váltani.
A csomópontok két oldalra voltak osztva orientáció szerint. A csomópontok felvételekor eltároltunk egy referencia orientációt, amivel összehasonlítva a jelenlegi orientációt kiválaszthattuk azt az oldalt, ahol beérkeztünk, és azt is amelyiken kifelé haladunk majd. Minden csomópontot próbáltunk azonosítani mikor éppen elhagytuk azt, és vagy új csomópontot felvenni vagy az előzőt a jelenlegi és a megelőző csomópont összekapcsolásával frissíteni. Végül a transzlációs hibák kiküszöbölése érdekében visszaállítjuk az először mentett pozíciót. Ezután terveztünk egy útvonalat és vonalat váltunk ennek megfelelően. Az mostani csomópont adatait pedig eltároltuk a következő csomópontig. Az azonosítás távolság alapján kiválasztotta a legközelebbi csomópontot és egy küszöbértéken belüli vagy elfogadta a találatot vagy új csomópontot jelzett.
Az útvonaltervezés egy kissé módosított dijkstra algoritmus volt (nem távolság alapján), ami megadta mindig a következő leágazásokban a megfelelő kimeneti kapukat (így neveztem a leágazásokat). Itt minden csomópont kétszer szerepelt (referencia orientáció szerinti és ellentétes kimeneti oldallal). A generált fa gyökerét az aktuális csomópont és a kimeneti oldal adta. Innen az algoritmus elkezdte felépíteni az ágait, a már ismert összeköttetések alapján. Nem volt cél a teljes ismert fát felderíteni, ha nem szükséges (lehetséges), ezért a felderítés végetért ha talált egy ismeretlen kimeneti kaput, amit még nem derített fel. Ha ilyet nem talált, akkor ez azt jelentette, hogy mindent ismerünk, ezért a korábban eltárolt kimeneti csomópontot, orientációt és kaput figyelembe véve megkerestük a fában azt a csomópontot, amelyiken kimenve kiállhatunk menetirányban a pályáról. Az útvonalkereső tulajdonképpen egy egyirányban láncolt listát készített, aminek a gyökerét jelezve egy algoritmus kapuk sorozatát állította elő, amit a tervezett útvonalunknak neveztünk. Kiállás esetén az utolsó leágazásnál engedélyezte az algoritmusnak, hogy a kocsi kiálljon, ezzel megakadályozva, hogy ha éppen megfordulási céllal haladnánk át a kilépési ponton, akkor túl korán kiálljunk.
Egy olyan kiegészítés is készült hozzá, hogy ismert útszakasz esetén jelezte a motornak, hogy ismert a távolság a következő szakaszig, így haladhat gyorsabban is, és a csomópont előtt lassítson. Ezért külldött egy jelzést mikor gyorsítson fel menetsebességre és mikor fékezzen le, hogy a csomópontot biztonságosan tudja azonosítani, és megcsúszás nélkül tudjon vonalat váltani. Ezt a funkciót sajnos nem volt időnk tesztelni, mivel más fontosabb dolgok nem mindig működtek megbízhatóan. Mivel a távolságokkal is tisztában voltunk, kis munkával és kicsivel több számítás árán egy tisztességes dijkstra algoritmust is lehetett volna implementálni, amivel lehet kicsivel gyorsabban jártuk volna be a pályát…
Mivel az implementáció meglehetősen komplexre sikerült, ezért az utolsó pillanatig kételkedtünk annak működőképességében. De hát ez így van, míg csak elméletben létezik, addig bízunk benne, aztán valami hiba csúszik a kódba, és hozzászokunk, hogy nem működik, majd utána sosem bízunk meg benne, hiába javítottuk a hibát. Mi a legjobb módja a kód tesztelésének, mint hogy versenyre menjünk vele tesztelés nélkül? Kétségkívül elegánsabb mint egy random algoritmus.
Tolatás:
Hátsó vonalszenzor hiányában nem támaszkodhattunk csak az érzékelt vonaladatra. Az első ötletünk az volt, hogy vegyük fel az orientációt a megtett út függvényében (encoder adatok) és arra szabályozzuk a kormányszöget hátrafelé. Ez első ötletnek remekül is sikerült, tényleg visszament, de további tesztelés során előjöttek a megoldás hibái is. Lement a vonalról. Nekünk a vonalon kellett volna visszamenni, így egy másik kis korrekciót alkalmazva, vagyis hogy a vonalszenzor adjon a kerékszögekhez egy korrekciós tagot, sikerült elégséges (ez egy szép szó az egyetemen) eredményeket produkálni, amiben már hajlandóak voltunk megbízni. A megoldás látható problémája, hogy a fáziskésés miatt az egyenes szakaszon hátrafelé enyhén oszcillált a kocsi, de le nem ment róla! Az eredményünket az alábbi videón dokumentáltuk:
Odometria, helymeghatározás (írta: Domonkos Albrecht)
A tavalyi és idei RobonAUT során is az ügyességi verseny egy labirintus feltérképezéséből állt. Ehhez alapvetően ismerni kell a kocsi aktuális pozícióját valamilyen pontossággal. Az alap ötlet az volt, hogy ha ismert az orientáció és az elmozdulás, akkor meg lehet mondani, hogy hova jutott el a kocsi, az előző méréshez képest. Tavaly a következő megoldással próbálkoztunk: elmozdulást a motor tengelyén elhelyezett enkóderrel, orientációt pedig a szervezők által kiadott giroszkóp (ST-LSM6DS3) segítségével mértünk. Tavaly sajnos nem működött rendesen az orientációszámítás és nem jöttünk rá, hogy miért. Persze nem segített, hogy idő szűkében voltunk akkor is. Nagyjából működött, de kisebb-nagyobb hibával mérte az elfordulásokat, ami hosszú távon elég nagy hibát okozott a pozíciószámításban, ezért úgy döntöttünk idén megpróbálunk egy iránytűt megvalósítani, amivel mindig biztosan meg tudjuk mondani az orientációnkat.
Az idei versenyre az egész elektronika egy 50 x 100 mm-es NYÁK-ra lett tervezve (Hava jóvoltából). Ezen a panelen kapott helyet egy ST-LSM9DS1-es szenzor, ami tartalmaz egy gyorsulás érzékelőt, egy giroszkópot és egy magnetométert is. Különböző irodalmak leírják, hogy a szenzorok fúziójából, hogyan lehet meghatározni egy jármű (kocsi, drón, stb…) orientációját három tengely mentén (madgwick filter). A szenzor adatlapja több helyen okozott komoly fejtörést, így ezeket most leírom ide, hátha másnak megkönnyítem a dolgát.
A szenzornál már az gyanús lehetett, hogy a három szenzor két külön eszköz egybe tokozásából épült fel. Az interface-eiket belül összehuzalozták és ebből állt az IMU. Ez nyilván nem könnyítette meg az eszköz egységes kezelését.
Első érdekesség, hogy a hivatalos honlapról letölthető adatlapban (innen) a DEN lábról nincs semmi leírás. Erről azt sikerült hosszas kutatás után kideríteni, hogy mezei felhasználónak nem kell sehova kötnie. Valami olyasmit sikerült kibogarászni a fórumokon, hogy ha időbélyegezni akarunk, ahhoz lehet valamilyen módon használni, de még most is elég homályos a tényleges funkciója.
Második komoly hiba az adatlapban, hogy a CTRL_REG3_M regiszter leírása rossz. A SIM bit ugyanis a 3 vezetékes SPI működést engedélyezi. Ez valahol a dokumentumban szerepel, csak a regiszter leírásnál nem sikerült jól leírnia az ST-nek…
A tréfás adatlap után térjünk rá a tényleges működésre. Féltünk tőle, hogy a kisméretű NYÁK-on a motor árama zavarhatja a magnetométert, de mit volt mit tenni, megpróbáltuk. Mielőtt nagyon belemerültünk volna a szenzorfúzióba, egy egyszerű teszttel ellenőriztük, hogy mennyire zavarják a mérést a nyákon folyó áramok. Teszt a következő volt: Levegőben forgattuk a kocsit a Z tengelye körül (Z-tengely merőleges a talajra). Először (I) a szervókat és motort leállítottuk, majd (II) szervókat mozgattuk és motor állt, harmadjára (III) a motor ment és szervók álltak, végül (IV) a motor is ment és szervók is mozogtak.
Az ábrán a magnetométer egy tengelyének nyers adatai látszanak, függőleges tengely a mágneses térerősséggel arányos a vízszintes az eltelt idővel. A tényleges értékek annyira nem is érdekesek, inkább csak a jel változása. A jelalakból azt a következtetést vontuk le, hogy ami zavarja a mérést az a szervó. A jelelakból érdekes módon mindig pozitív tüskék állnak ki, aminek az alsó burkológörbéje még követi a tényleges jelalakot, de így már az átlaga elcsúszik. A motor, noha nagy áramot vesz fel, alig zavaró, ugyanis a tüskék jóval kisebbek mint a szervó esetében és átlagolással kiesik. Itt jött a felismerés, hogy egy tervezési hiba miatt nem GND réteg került közvetlen a szenzor alá, hanem pont a szervó tápfeszültségének elvezetése, amin szintén elég nagy áram folyik, amikor éppen mozog a szervó. A négyrétegű NYÁK-on a szenzor alatt az elképzelt rétegek sorrendje: TOP-GND-VCC-BOT. De ehelyett: TOP-VCC-GND-BOT sorrend valósult meg. Mindezek ellenére ki lehetett volna hozni valamit a mérésből (alsó burkológörbe), de sajnos egy sokkal nagyobb probléma is szembejött a folyosón…
Ez konkrétan az volt, hogy a folyosón végigsétálva teljesen megbolondult a mérés. Ezzel nem nagyon tudtunk mit kezdeni, de az elmélet az, hogy a falakban található betonvas, kábelek (kábelezési aknák ferromágneses ajtókkal), egyéb ajtók mind zavarják a mérést. Lehet, hogy ki lehetett volna hozni valamit ebből is, de ennél a pontnál mi elengedtük az iránytű ötletet és visszatértünk a giróhoz, amúgy is azért adták azt a szervezők, hogy ezzel oldjuk meg a feladatot (az adott IMU-ban nem volt magnetométer).
A mérésnek papíron egyszerűnek kéne lennie. Feltételezzük, hogy csak Z tengely körül forog a kocsi (síkban haladunk), a két mérés között megtett távolságból (enkóderes távolságmérés) és a kocsi orientációjából meg tudjuk mondani az elmozdulást. Ez elég egyszerűen hangzik, de nem annyira triviális. Nézzük, min csúszhat el a dolog!
Első körben az elmozdulást kell pontosan mérni. Ezt az eddigi tapasztalatok alapján az enkóder elég jól mérte, csak arra kell figyelni, hogy ne csússzon meg a kocsi és ne pörögjön el a kerék. Ezt nem nehéz elérni, ha nem akarunk nagy sebességgel menni, illetve valami tapadás növelő csodaszert (pl. az évek óta nagy sikerű gumikesztyűt) alkalmazunk. Az orientációmérés sem sokkal bonyolultabb, de több helyen lehet hibát vinni a rendszerbe.
Aki tudja, mi az a giroszkóp, az tudja, hogy a szenzor nem tud orientációt mérni, csak szögsebességet. Ahhoz, hogy orientációt kapjunk, nincs más dolgunk, mint integrálni a giroszkóp adatait. Ez jelen esetben nem más, mint egy egyszerű szummázás szerencsére. A szenzorból érkező mérési adatok 16biten 2-es komplemenses számábrázolásban érkeznek. Ebből, hogy szögsebességet tudjunk számolni, meg kell szorozni a felbontással (LSB), amit a beállított mérési tartomány határoz meg. Tehát egy végtelenül egyszerű képletet kapunk: (REG a regiszterből kiolvasott érték)
Tesztelés során kimentettük a kocsi által rögzített nyers adatokat, hogy abból kiderítsük, ha hiba csúszik valahol a rendszerbe. A félév során a Q épület második emeleti folyosóján volt egy „kutyacsont” alakú pálya felragasztva, főleg ezt használtuk a mérések validálására. (Aki nem járt arra mostanában, elég annyit tudni róla, hogy viszonylag hosszú önmagába záródó pálya.) A fent leírt módszerrel a következő eredményre jutottunk.
Látható, hogy nem sikerült elsőre a feladat, szóval vegyük végig, hogy hol csúszhat hiba a számításainkba. Az első dolog, ami eszébe jut az embernek, hogy a mérés különböző hibákkal terhelt. Talán a legegyszerűbben emészthető, hogy feltételezhetünk egy ofszet hibát, illetve azt, hogy ez nem mindig egyforma nagyságú (pl. ha kicsit melegebb van, vagy ha a csillagok rosszul állnak elmászik az ofszet). Ezeket biztosra vehetjük, hogy léteznek, csak az nem mindegy, hogy mennyire befolyásolja a mérést. Jelen mérésnél az ofszet úgy jelentkezik, hogy az egyenes vonalak helyett is görbe vonalakat kapunk, mivel az egyik irányba kis sebességgel folyamatosan „fordul” a kocsi. Ez az előző ábrán nem nagyon látszik, de ha hozzáadunk egy nagyobb (pozitív) ofszetet, akkor a következőt látnánk.
Összességében közelebb kerültünk a kiinduláshoz, de nyilván valóban nem így kellene ezt elérni. Továbbá látszik, hogy a nyers mérés viszonylag kis ofszettel terhelt. A következő gondolat az volt, hogy a szenzornak biztos van valamekkora nemlinearitásból adódó hibája. Eredetileg azt gondoltam, hogy ha megadják a teljes mérési tartományt (Full Scale) és ismert, hogy 15 biten (15+előjel) ábrázolják, akkor igaz, hogy FS/2^15=LSB. Ez pedig nem igaz. Pont a nemlinearitások miatt és a FS bizonytalansága miatt, az adatlap megad egy tipikus LSB-t. Az általam számolt LSB: 0,00744 °/s míg az adatlapban szereplő 0,00875 °/s. Mindenhol azt tanítják, hogy worst-case (legosszabb eshetőség) esetre méretezzünk, tervezzünk. De itt nincs worst-case, szóval úgy járunk a legjobban, ha hiszünk az adatlapnak és elfogadjuk a tipikus értéket. Persze ha tudnánk saját magunk kalibrálni a teljes tartományban, akkor biztos tudnánk valamit pontosítani.
Ez így már kezdett használhatónak tűnni. Az ábrán azt látjuk, hogy a kocsi a kanyar után kis lengéssel állt be a vonalra, és valószínű a lengés utolsó félperiódusa kimaradt a mérési adatokból a mintavételezés miatt. Növeltem a mintavételi frekvenciát és elkezdtem ötletelni, hogy a kis ingások ne vigyék el a mérést. A lementett adatokból kis exceles bűvészkedéssel a következőkre jutottam.
A rögzített mérési adatokból elég jól látszik, hogy mikor kanyarodott a kocsi. Ha nem kanyarodik, akkor nem is változhat az orientációja. Valamint azt is tudtuk, hogy a szabályoknak megfelelően az ügyességi pályán elhelyezett csomópontok orientációja 90° egész számú többszörösei, így ezek az irányok kitüntetett szerepet kaptak. Ez azt jelentette, ha nem kanyarodik a kocsi, és pl. 93° lenne a számolt orientáció, akkor kerekítettem 90°-ra. Persze ezt ki kellett tesztelni, hogy milyen eltérés esetén fogadja még el ezt a kerekítést. Papíron ez elég jól működött.
Természetesen az elmélet szép meg jó, de a valóság mindig elmarad valamivel. Ezeket az elgondolásokat, leprogramozva a következőket kaptuk.
Ugyan nem ment végig a kocsi a teljes pályán (vagy valahol elveszett egy csomó adat), de látszik, hogy valami félresiklott a kocsi számításaiban.
A kocsin 0…360 fok közé esik az összes érték, hogy átláthatóbb legyen. Jól látszik, hogy a kocsin számolt orientáció gyorsabban változik, mint ahogy azt az excel alapján várnánk. Végül arra jutottam, hogy ütemezési problémába futottam. Azt feltételeztem, hogy 10ms-ként lefutnak a pozíció/orientációszámításhoz szükséges függvények, ezt vettem időalapnak a szögszámításhoz. A mérés alapján ez 10%-ban is eltérhetett, ami természetesen tönkre is teszi a mérést. Ennek megoldása az lett, hogy kritikus tasknak tituláltuk a pozíciómérést és a hozzá tartozó függvényeket, és interruptból futtattuk, vagyis jó közelítéssel tényleg 10ms-ként. Ez után a javítás után már csak a kanyarok detektálásához kellett beállítani a megfelelő küszöbértékeket.
Mikor elértem ezt az állapotot, hogy tulajdonképpen megegyeznek az elvárt és a ténylegesen számolt pozíció adatok, úgy ítéltem meg, hogy megfelelő lesz a labirintus feltérképezését végző algoritmusnak. És valóban ezzel már működött a feltérképezés.
Még egyszer összefoglalva, hogy min mehet félre a pozíciószámítás. Az elmozdulás mérése egy motor tengelyére szerelt encoderrel történt. Ha elég pontos az encoder, elég arra figyelni, hogy ne csússzon meg a kerék. Az orientációmérés mindig hibával terhelt, viszont nem mindegy mennyire. Első gondolat, hogy beállítjuk a felbontást és annak megfelelően számolunk, valamint az ofszetet kompenzáljuk. Ha tudjuk, hogy egyenes szakaszon vagyunk, minden ilyen szakaszon tudnánk mérni egy szögsebesség ofszet értéket, ezzel folyamatosan kalibrálva, kiküszöbölve az ofszet eltolódást. Figyelni kell, hogy az időalap megfelelő legyen, és ne legyen benne nagy bizonytalanság. Ha ez még mindig kevés lenne, akkor kell trükközni egy kicsit. Az, hogy nem engedjük, hogy változzon az orientáció, csak ha kanyarban van a kocsi, egy viszonylag egyszerű feltevés, csak jó helyen kell meghúzni a küszöbértékeket. Ha megfelelően sikerül eltalálni, akkor nagyon szép eredményt lehet így elérni. Az is biztos, hogy ugyan nem tűnik professzionális megoldásnak, hogy excelben/más hasonló programban, kézzel végezzük el a számításokat, de mindenképp sokkal hatékonyabb, mint minden pici változtatás után újabb és újabb mérést végezni.
Amivel a jövő generációinak meg lehetne keseríteni az életét, ha az egyenes szakaszok orientációja nem lenne 90° többszöröse. Ez ugyan most is csak a csomópontokra volt kimondva. Valószínüleg lehetne még finomítani az algoritmuson, de ezzel már el tudtuk érni a kívánt eredményt. A kívánt eredmény pedig a próbálkozások folyamán a “tökéletestől” az “elég jó”-n át a “feladom” szintig képes süllyedni.
——– End of Doma Sessions ——-
Murphy megmondta: ami elromolhat…
-A szervó keféje a lassan két verseny felkészülés alatt annyira elkopott, hogy a fémlemez “szén” kefe hátramenetben begyűrődött a másik kefe alá, és ezzel rövidre zárta a motor kivezetéseit. Ennek következtében a motorvezérlő félhídban az egyik dual-FET rövidzárba égett.
-Az impeller vezérlője nem éppen egy csúcskategória volt. A “védelmi” ferriteket naívan eltávolítottuk. Egyik feature az volt, hogy teljes gázon annyi zajt generált a saját bemenetén, hogy nem akart leállni a motor. Máskor egy driver hiba miatt (default PWM érték elírás), impeller letiltás esetén az impellerek úgy gondolták, most rajtuk a világ szeme és mindent beleadtak. Ezt volt szerencsém párszor megtapasztalni, de nem tudtam mire vélni. Általában pánikolva megpróbáltam ujjaimat biztonságban tudva széthúzni a tápcsatlakozót és utána remegő lábakkal pihenni egy negyed órát. Azután Havának is volt szerencséje, mikor a szoftver lefagyott tesztelés során. Utána rohanva felkapta a kis aranyost, és resetet nyomott. Ekkor ismét beütött a pánik, az imepellerek ismét magukon érezték a világ szemét és… ami a csövön kifért. Nem segített az sem, hogy a kiáramló légmennyiség miatt a reset gombot nem lehetett benyomni, csak ha éppen a kezünk nem volt az impellerek felett. Azóta javítottuk a kódot, de mindig bátorságpróbát jelent, hogy ki dugja össze az impellerek tápcsatlakozóit.
-A kocsi néha véletlenszerűen lefagyott, és látszólag semmi konkrét nem okozta a jelenséget. Emiatt például nem tudtunk kvalifikálni időben, mert 10cm megtétele után a kocsi úgy gondolta, hogy: “get outta tha way bitches” és letolta volna a safety car-t a pályáról.
Mint kiderült, vagy nem, de a stack és heap méretének megkétszerezésével a probléma megoldódottnak tűnt.
-Versenyt megelőző csütörtök este, a szokásos programozás közben az eszköz egyszer csak… Nem, egyszer csak nem. Indult. Be. Az “érdekes”, hogy a programozás továbbra is lehetséges volt. Lehet valamilyen kofigurációs bájt sérült meg, meg lehet nem. A pánikhangulat és kevés idő miatt nem akartunk ezen agyalni. Egyszerűbb volt egy csere nucleo-board-ról leforrasztani egy IC-t és felforrasztani a vezérlőnkre, mint keresni a hiba okát. Ennek is a versenyt megelőző 48 órában kell jelentkezni, nyilván. Unalmas volna ilyenek nélkül a felkészülés. Ja nem.
-Majdnem egy héttel a verseny előtt a háromfázisú BLDC motorunk kis híján leégett, mikor álló helyzetből nem volt képes elindulni a kis nyomatéka miatt, és mivel az új gumik túlságosan is tapadtak egy mosás után. A kis nyomaték valószínűleg vezérlési probléma volt, mivel a motor előfázis szöge nem volt sebességfüggő vagy a 6 fázisú encoder nem volt elég pontos kis sebességek esetén. Olyan szempontból mindegy, hogy a motorcsere miatt a névleges teljesítményt 214W-ra korlátozták, a miénk 200W-ot tudott névlegesen. Halkabb volt, elvileg szebben lehetett volna nyomatékot adni rá, meg egyéb kellemes lehetőségeket adott volna. De a kezünk meg volt kötve, és a gyári motor elbírt akár 1kW teljesítményt is rövid ideig. Ezzel a BLDC-nk nem tudott versenyezni. Inkább visszatértünk a kefés motorhoz…
-Korai probléma, mint említettem hogy a kefés gyári motor sokat elvisel, de hosszabb távon nem szereti a túlfeszültséget. Sosem hajtottuk ki a 16V-os feszültségre (meghalna, max 2-3V-ot kapott). Viszont távirányítóval nem nehéz kövér gázokat adni, utána meg motorféket. Egy ilyen alkalommal vettük észre, hogy mintha megválasztották volna a pápát. És valóban, füstölt a motor és égett szaga volt. Ennek ellenére azóta is működik.
-A távolságmérét idén a tanszékről kapott ToF (Time of Flight) lézeres távolságmérő szenzorral szerettük volna megoldani. Ezzel minden csapatnak meggyűlt a baja. Először is a három kapott szenzor nem tudott egy I2C vonalon egyszerre létezni. Másodszor valami szintillesztő, vélhetően védelmi funkció miatt a jelalakot szabotálta a szintillesztő 5V-os tápfeszültségen. Néha csak egyszerűen kimaradt egy órajel ciklus, amit a szintillesztő praktikusan egy dirac deltával próbált jelzni. Menjünk tovább, az IC valamilyen oknál fogva néha egy nem dokumentált hiba státuszkóddal lezárta a mérést. Ezt a problémát az Override ötletesen egy periodikus tápfeszültség megszakításával hidalta át. Mi pedig három nappal a verseny előtt elégeltük meg a szenzor megbízhatatlanságát, és vissaztértünk az ultrahangos (ultracsöndes?) távolságméréshez.
-Az iránytűhöz, gyorsulásmérőhöz és giroszkóphoz elkészült a madgwick implementáció, azonban a kiadott pozíció és orientáció valóságtartalma egy párhuzamos univerzum létezését vetítette elő, ahol az általunk ismert fizika törvényei nem érvényesek többé. Ezt mint említettem két hibának köszönhette. Először is a magnetométer (iránytű) alatt futott tervezési hiba miatt a szervó tápárama, ami nem tette lehetővé a kormányzást és az északi irány egyidejű megfigyelését, legalább is ha valós adatokat szerettünk volna. A motor ugyan kicsit zavaró volt, de a motor zaját könnyedén ki tudtuk volna átlagolni. Másik zavaró egybeesés, hogy a Q épület vasbeton szerkezetén belül eléggé torzul lokálisan a föld mágneses tere, főleg egy folyosón, ahol acéllemez ajtók mögött mosdók és kábelaknákban ökölnyi vastag vezetékek rejtőznek. Valahogy így képzelheti el egy absztrakt művész, hogy mi az az elektromágnes. Ez számszerűen olyan 70-80° szöghibát produkált, attól függően, hogy a férfi vagy női mosó előtt haladunk el, vagy egy kapcsolószekrény előtt, és persze attól is függ, hogy hívott-e valaki liftet, vagy éppen hogy áll a jupiter meg a csillagok.
-Korai banális hiba volt, a motorvezérlő bekötésénél, hogy a félhidak közös pontjai (ahol a felső oldali FET source-a és az alsó oldali FET drain-je össze van huzalozva) nem voltak közös potenciálon a félhídmeghajtó megfelelő kivezetésével, így a bootstrap kondenzátor nem tudott elég feszültséget (kb semmit) szolgáltatni, sem a felső oldali FET-et teljesen kinyitni. Remek demonstrációs eszköz, hogy mi történik ha kapcsolóüzemben 5kW-ot kapcsol valami, és miért nem jó játék ugyanezt megpróbálni lineáris üzemben. Lehet nem tud disszipálni ennyit szegény 5x6mm-es lapka és hálából füst kíséretében elválnak útjai az FR4-es lemeztől.
-Volt egy olyan hiba, hogy konzisztensen mindig a rossz oldalon szeretett volna kiállni a kocsi a labirintusból, legalább is fáradtan úgy tűnt, mintha mindegy honnan érkezett, mindig a falnak akart volna hajtani. Ez igazából csak egy betű elírást jelentett a kódban, de pont ezért volt nehéz megtalálni. A probléma az volt, hogy nem a csomópont közben követett vonal alapján határozta meg, hogy melyik oldalon álljon ki, hanem az utána levő egyetlen vonal alapján kísérelte meg ezt a mutatványt, általában kevesebb sikerrel, mivel a próbák alkalmával még a felderítés is hagyott kívánnivalót maga után. Egy “.g[0]” -> “.e” után elméletben nem lehetett ezzel gond, csak a rögtönzött javításokat kellett visszajavítani a kód versenyt kezelő állapotgépében. Még egy másik javítást is eszközöltem, remélve, hogy a kívánt hatást érem el vele, és a verseny előtt még egy biztonsági időzítő is bekerült, hogy ha mégis eltévedne a labirintusba legalább ki tudjon állni bizonyos idő letelte után. Mivel a gombok használata és nyomkodása buzis volt, ezért hogy melyik versenyszámot szeretnénk indítani a kocsi 20cm hátrahúzásával ill. előretolásával jeleztük. A gyors “utolsó” programozás után (10:12-kor, verseny előtt) még egyszer csak tesztelésképpen hátrahúztuk a kocsit az ügyességin, és első dolga volt kiállni a gyorsaságira. Ott megfagyott a vér az ereinkben, mivel biztosan a pálya elején lesz a kiálló rész is, amivel praktikusan kinullázzuk az ügyességi pontjainkat az utolsó pillanatban hozzáadott biztonsági időzítős dolog miatt. Ezért míg a többiek szépen sorbaálltak, én felrohantam egy laptopért és prgramozóért. Majd lent remegő kézzel a földön: Kommenteld ki azt a két sort és jó lesz! Programozd fel! Rohaj ki vele és tedd ki a helyére, ahol már 45 perce állnia kellene! És akkor jöhet a bevonulás. Pompás reggel, valami ilyesmire számítottam.
-Ami sajnos későn derült ki, hogy a kocsi a verseny reggelén, mikor összeraktuk még reggel 6kor a különböző kódokat, utána nem akart felgyorsulni. Azt hittük, hogy az új vonalfelismerő és a tavalyi (két külön rendszer, a gyorsaságin még a tavalyit használtuk kényelemből) összeakad valahogy, és nem ismeri fel a vonalakat. A valóságban: volt benne egy biztonsági funkció, mely a távirányító aktiválása esetén letiltotta az automatikus sebességállítást. Ezt a kis kapcsolót nem vettük ki a versenykódból, nem is tudtuk, hogy mi az oka, de ha tudtuk volna, akkor egy komment vagy pár gombnyomás lett volna telefonon. Bár ezzel lehettünk volna a leggyorsabb csapat, de a sebességrekord megdöntéséhez az impellerek is kellettek volna. Ennyi múlik egy nyomorult kapcsolón, 15 másodperc…
-Kicsit könnyebb téma. A vonalszenzor szimmetrikus. Tényleg. Többször is sikerült felcsavarozni, és csak utána eszméltem rá, hogy a szenzorok felfelé néznek. Első alkalommal azonban percekig nem értettem, hogy mi lehet a hiba, vagy miért nem látja a vonalat. Aztán Hava felhívta a figyelmemet, hogy ne legyek ennyire retardált 🙂
-Nem volt előtöltős tápcsatlakozónk. Az akkupakk csatlakoztatásakor elég nagy áramok képesek pillanatszerűen megindulni, ami a sok bemeneten lévő tápsimító kondenzátor feltöltéséhez kellene. Az előtöltős csatlakozó ilyenkor biztosítja, hogy ez az áram bizonyos értéket ne léphessen túl amíg a feszültség el nem éri az akku kimeneti feszültségét. Csatlakoztatás esetén ha nincs elég szoros kapcsolat, akkor ívet képes húzni a két “elektróda” amit jelen esetben a két XT60-as csatlakozó banándugói alkottak. Az ívkisülésről tudni érdemes, hogy egyenáram esetén alakul ki, a kisülés ionizálja a gázt (levegőt) és utána az ívkisülés fenntartásához már nem szükséges különösen nagy feszültség (a plazma elég jó vezető), és nagy áramokat tud vezetni, mellette pedig elég forró tud lenni. Ha ez szándékos, akkor használhatjuk mint plazmavágót is. Az azonban nem segít ha a plazmacsatornát elkezdjük meghosszabbítani. Gyakorlatban ez úgy nézett ki, hogy össze szerettem volna “óvatosan” dugni a csatlakozókat, és mikor lassan közelítettem akkor szikrázott egyet, húzott egy kis ívet. Itt én megijedtem és reflexszerűen szét akartam húzni a csatlakozót, amivel csak az ívet húztam szét, mikozben töltödtek a kondenzátorok az immár zárt áramkörben. Sajnos mire sikerült egy plazmacsatornán keresztül feltölteni a pufferkondenzátorokat az XT60-as csatlakozóból nem túl sok maradt hátra, ami használható lett volna. Néha az óvatos, nem azt jelenti hogy lassan, hanem hogy gyorsan 😀
Formaterv
A formaterv megint a Rodstertől indult, aztán a Cybertruck bemutatása után a ledszalagos fényszórókat is valahogy be akartam illeszteni a tervbe, mivel jó ötletnek tartottam kiemelni ezt az újítást. Hamar be kellett látni, hogy a nagy “monster truck” kerekek miatt nem lehet csak úgy ráhúzni egy roadster kasztnit, kiegészíteni ledcsíkkal elől és hátul, legalább is nem lesz esztétikus. Ezért inkább az adottságokból építettem egy alapot, és erre próbáltam meg ráhúzni a Roadster vonalvezetését, amit nyomokban fel lehet ismerni. A hagyományos szélvédő ötletét is elvetettem, mivel nem kell úgy tenni, mintha ez egy hagyományos személygépjármű volna, vagy akár csak sportkocsi is, sokkal inkább egy önvezető jármű, pilóta nélkül, bár a felismerhetőség határán belül. A lapos hátsó pedig egy Porsche hátsóra hajaz. Az impellereket pedig két él körbeöleli, kiemelve az újítást Felmerült, hogy lehetne kabrió is, de nem lett volna egyszerű esztétikusan kivitelezni. Mindenképpen kellett lyuk a tetőre, az impellerek miatt.
A kasztni tervei 3ds max modellező programmal készültek. Ugyan megpróbáltam ugyanezt AutoCAD-ben is, de sajnos az 3d modellezés korlátozottan interaktív, nem lehet csak úgy változtatni az íveket és az éleket tologatni. Ezért maradtam a max-nál. Az adott vázat és kerekeket importáltam dwg-ből, és köré szerkesztettem meg spline cage modellezési technikával a felületet. Az itteni modellezés lényege, hogy ha nem is teljesen de procedurálisan lehet szerkeszteni a modellt, így ha valamelyik ív kicsi, semmiből sem tart elmozdítani vagy módosítani egy bezier súlyt. A spline cage lényege, hogy 3 és négyoldalú görbékkel határolt felületeket hozzunk létre, amiből egy módosító eszköz tetszőlegesen részletes felületet generál. Az lett volna az optimális ha ezt a matematikai felületet (a NURBS felületek egyik alkategóriája) tudom exportálni, mint STEP file, vagy hasonló, nem poligon modell. Korlátozottan ugyan lehetséges volt, de más programok (Autodesk termékek, ami éppen nem Max) nem kezelték megfelelően ezt. Az is elég lett volna, ha a spline cage rácsot tudom exportálni mint bezier görbéket, viszont az AutoCAD nem ugyanúgy kezeli a bezier görbéket mint a Max. Opcióként még rendelkezésre álltak a Fusion 360-ban is implementált T-spline felületmodellezési eszközök, de ezt megtanulni nem volt időm a szűkös időben.
A vákumformát még Max-ban terveztem, mivel a CNC marófájlok generálásához zárt test szükséges, nem tud egyetlen felület alapján dolgozni. Ezért egy egyszerű talpat is csináltam neki és ezt importáltam Fusion 360-ba. Itt a formát végül két félre osztottam, a technikai megkötések miatt. Egyik megkötés, hogy a gép 5cm-t tud jól megmunkálni, magasabb munkadarab esetén beütközhet a Z tengelyen a végálláskapcsolóba. Másik megkötés a rendelkezésre álló 1/8″-os marófej éléből adódik. A terv az volt, hogy majd tömör habból (XPS hőszigetelés) kimarom, amit visz mint a vajat a marófej. A fejnek viszont csak kb 8mm hosszan van éle, így ennél magasabb réteget nem érdemes kimarni vele, mivel ahol nincs él csak tépi az anyagot, közben pedig dörzsöli és melegíti. Ilyenkor megolvadhat hűtés és kenőanyag nélkül a műanyag, ami ráolvadva a marófejre teljesen tönkreteheti a munkadarabot (szétolvasztja ahol hozzáér, növelve a műanyag csomó méretét, csinál egy nyalókát magából). Harmadik probléma, hogy a marófej hossza volt majdnem 5cm. Ez a lapos felületek miatt nem volt probléma, csak a meredek éleknél a munkadarab szélein, ahol rendszeresen le kellett vágni a merőleges falakat, hogy a befogó fej ne érjen hozzá.
Vákumformázással volt tervben megvalósítani a kasztnit. A kasztni felső fele már korábban elkészült, így csak az egyszerűbb alsó felét kellett kimarni. Mindezt persze verseny előtt hajnali egytől kellett, mert akkor volt rá idő. Igazából akkor sem volt, ahogy másra sem igazán. A terv szerint glettel, vagy egyéb gipsz szerű anyaggal (szobrász agyag?) vontuk volna be a habot, amit simára lehet csiszolni, és egyben hőálló is. Erre megintcsak nem volt idő. Gyors megoldásnak adódott valami egyéb gyorsan felvihető bevonat. Végül a maszkolószalagnál lyukadtam ki, mint “hőálló” bevonat. Természetesen előtte más bevonatokkal is végeztem próbaformázásokat, ahogy az elvárásairásaim és az eredményeim konvergáltak egy “close enough” megoldás felé.
Magát a kasztnit egy 0.5mm-es PETG lemezből akartuk (akarjuk) megoldani, de nyilvánvalóan nem volt vákumformázónk, ami enyhe korlátot (értsd: kihívást) jelentett. A megoldás végül, hogy hőlégfúvó és vizes rongy kombinációval addig simogatjuk a lágy műanyaglemezt amíg rá nem simul a formára. A hőlégfúvó viszonylag gyorsan megmelegít egy kis felületet, de az egészet egyben nem képes meglágyítani, ezért egyszerre csak egy kis részen lehet dolgozni. A vizes rongy pedig azért kell, mivel elég forró a lágy műanyag, nem érdemes kézzel simogatni. A víz pedig egyben hűti és síkosítja is a felületet. Végül addig simogattam míg rá nem állt a formára. Ezután egy fél kasztnira elegendő festéket szétkentem a kasztnin és kész is volt a low-budget, néhol lyukas, de messziről meggyőző valami.
Ez ugyan nem került fel az utolsó percekben az autóra, mivel az impeller nyílásokat nem tudtuk kivágni, sem a kameratartónak szánt nyításokat, és így nem lehetett rögzíteni. Az impeller bekapcsolása esetén pedig egy légcsatorna kialakítása is szükséges lett volna, hogy a majdnem 2kg tolóerő ne végződjön egy rögtönzött striptease show-ban, ahol egy hirtelen kanyarban a szörnyünk úgy dönt, hogy neki nincs szüksége többé kasztnira. Persze a tervet nem fogjuk ennyiben hagyni, ahogy a lassúsági rekordunkat sem. Hamarosan elkészül egy tisztes kasztni is, addig pedig itt van ami elkészült.
Pánik, rohanás: kvalifikáció és verseny
A képekért köszönet a SPOT fotókörnek! Itt van az eseményről készült albumuk: (itt)
A többi, ide nem szorosan kapcsolódó képért keresd fel Facebook oldalunkat: (itt)
Vagy a verseny hivatalos Facebook oldalát: (itt)
Versenyközvetítés, a Budavári Schönherz Stúdió (BSS) jóvoltából: (itt)
A tavalyi versenyünk beszámolója itt olvasható.
