Feladat célja: korábbi félév AEB funckiójához objektum érzékelő rendszer fejlesztése Kimenet: az összes cél objektum x,y pozíciójának, sebességének, gyorsulásának meghatározása lidar (esetleg radar) pontfelhő alapján

Legfőbb részfeladatok: MMdetection3D keretrendszer megismerése, modellválasztás Tanító adatkészlet felvétele, előkészítése Modell tanítása és kiértékelése ROS keretrendszerben a perception node implementálása, mindez a járműbe integrálása és az éles tesztek elvégzése.

Fő üzenet:

Először álljon elő egy működő, előtanított detektor, utána egy saját adathalmaz (+dataloader), majd mérhető modell továbbtanítások, végül megbízható ROS-integráció. Ne egyszerre próbáljatok mindent megoldani.

LiDAR pontfelhő → előfeldolgozás → detektor → 3D objektum detekció (objektum x,y pozíciójának, opcionálisan a sebességének, gyorsulásának meghatározása) → ROS-node → vizualizáció / jármű aktiváció indikáció

A hallgatók tudják bemutatni, hogy:

• Egy / több kiválasztott, előtanított háló működik egy publikus adathalmazon;
• A saját szenzoruk adatait tudják értelmezni;
• Saját, annotált adatokon tovább tanították a kiválasztott egy / több modellt;
• A modell(ek) teljesítményét az eredetihez képest kiértékelték;
• A ROS-node felvételről és élő szenzorral is működik.

0. Csapatok megalakulása, szerepkörök definiálása.
1. Az objektum detekciós feladat és a rendszerarchitektúra specifikálása
2. Csapatonként közös github repo (mmdetection3D fork) és fejlesztői környezet kialakítása
3. Neurhálók kipróbálása demo adatokon (pl: nuScenes), majd a megfelelő modell kiválasztása.
4. Metrikák definiálása, 1 (vagy több) kiválasztott neurháló kiindulási teljesítményének mérése
5. ROS perception-node létrehozása
6. Saját LiDAR–ROS adat gyűjtő és tároló pipeline kiépítése.
7. Saját adatok gyűjtése, annotálása és train-val-test felosztása.
8. A saját adathalmaz integrálása az MMDetection3D keretrendszerbe (dataloader)
9. A kiválasztott modell továbbtanítása saját adatokon és az eredmények kiértékelése
10. Iintegráció a jármű rendszerébe és tesztelés
11. Dokumentáció és végső bemutató

cél: effektív munkamegosztás, 2 db ~8 fős csapat létrehozása.

Javasolt felelősségi körök:

• 1 product owner & scrum master (követelmények, konponensek közötti interfészek definiálása, feladatok követése
• 3-4 data engineer (adatok gyűjtése, tárolása, betöltése)
• 1-2 AI engineer (modellek kipróbálása, modellek tanítása és kiértékelése)
• 1-2 ROS integrációs és funkciótesztelő mérnök (ROS node, kommunikáció, koordináta transzformációk, célhardverre integráció)

(A fejlesztések dokumentálása mindenki feladata.)

Rögzítsétek:

• a keresett objektumosztályokat;
• az érzékelési távolságot és tértartományt;
• a LiDAR típusát, pontjellemzőit és mérési gyakoriságát, extrinsic paramétereit;
• a jármű célhardverét;
• a python és ROS-verziót
• a szükséges bemeneti és kimeneti interfészeket;
• az elvárt feldolgozási gyakoriságot, késleltetést és adatfrissességet.

Készítsetek két egyszerű adatfolyam-ábrát:

Tanítás: Felvételek → konverzió → annotáció → adathalmaz → neurháló továbbtanítás → kiértékelés → modellcheckpoint

Élő működés: LiDAR → ROS pontfelhő → előfeldolgozás → detektor → utófeldolgozás → ROS objektumüzenetek

Ellenőrizhető eredmény: rendszerterv, interfészleírás és mérhető követelmények.

Tipp: Érdemes kisebb feladattal kezdeni. Például: autók pozíciójának detektálása az elülső tértartományban, PointPillars hálóval, ROS-kimenettel. majd: A járművek sebességének detektálása. A további osztályok, a teljes 360°-os lefedettség vagy a követés későbbi bővítés lehet.

Cél: közös, verziókövetett fejlesztési környezet létrehozása.

Csapatonként készítsetek egy MMDetection3D-forkot egy github repositoryba. A csapattagok ezt klónozzák. Később pull requesteken keresztül integráljáok a változtatásokat.

A repository tartalmazza a saját:

• konfigurációkat;
• adatkonvertereket;
• tanítási és kiértékelési segédeszközöket;
• ROS-komponenseket;
• telepítési és használati leírást.

A nagy nyers adatok és model checkpointok külön tárhelyre kerüljenek. A kódban ezek elérhetősége, verziója és azonosítója legyen rögzítve; érzékeny adatok és hozzáférési kulcsok ne kerüljenek a repositoryba.

A kurzus közös Google Drive-mappája Colabból is csatolható. Tartalmazni fog egy minden csapat számára elérhető általános mappát a nyers mérésekkel, valamint csapatonként egy külön munkamappát. Minden csapatmappában az alábbi struktúrát használjátok:

<csapat>/
├── users/       # felhasználónkénti munkafájlok
├── experiments/ # konfigurációk, naplók és kísérleti eredmények
├── checkpoints/ # mentett modellsúlyok
└── datasets/    # előkészített és felosztott adathalmazok

A Drive ne helyettesítse a verziókövetést: a forráskód és a kis konfigurációs fájlok Gitbe, a nagy adatok, eredmények és checkpointok a megfelelő Drive-mappába kerüljenek.

Cél: megismerni a lehetséges modelleket, és a projekt követelményeihez illő legjobbat kiválasztani.

A saját adatok előtt használjatok ismert publikus adathalmazt, például KITTI-t vagy nuScenes-t. Ez segít elkülöníteni a telepítési és implementációs hibákat a saját adatok problémáitól.

Feladatok:

• az adathalmaz beszerzése;
• a hozzá tartozó adat-előkészítés futtatása;
• a modell futtatása a mintapontfelhőn
• az inference (azaz a prediktált 3D dobozok, sebességek, gyorsulások) megjelenítése;
• az előtanított modell kiértékelése;
• a konfiguráció, checkpoint és eredmények rögzítése.

Ellenőrizhető eredmény: működő inference -> indokolt modellválasztás, a bemeneti követelmények és korlátok leírásával.

(Érdemes előre meghatározni, hogy mit jelent a projektben az elvárt működés.)

Két metrikacsoportot is lehet definiálni.

Detekciós minőség:

• AP/mAP a választott kiértékelési protokoll szerint;
• precision és recall;
• osztályonkénti eredmények;
• távolság szerinti eredmények;
• téves detekciók és kihagyott objektumok.

Működési teljesítmény:

• inferenciaidő és feldolgozási gyakoriság;
• késleltetés;
• hardwerigény, memória figyelés;
• A teljes ROS-lánc késleltetése, késő framek eldobása.

Cél: a kiválasztott modell folyamatos futtatása ROS környezetben.

A node végezze el:Pontfelhőfogadás → modellhez illeszkedő előfeldolgozás → inferencia → dobozkonverzió → publikálás

Javasolt interfészek:

• bemenet: sensor_msgs/msg/PointCloud2;
• kimenet: például vision_msgs/msg/Detection3DArray;
• megjelenítés: ROS markerek;
• állapotjelzés: diagnosztikai üzenetek.

Fő követelmények:

• a modellt egyszer, induláskor töltsétek be;
• az offline és online előfeldolgozás egyezzen;
• a kimenet őrizze meg a mérés időbélyegét;

Az MMDetection3D LiDAR-dobozai alapértelmezetten alsó bbox pontot használnak; a ROS-os geometriai középpontot helyesen kell előállítani.

Ellenőrizhető eredmény: rosban folyamatosan futó, helyesen időzített és vizualizálható perception-node.

Cél: visszajátszható és feldolgozható szenzoradatok előállítása. LiDAR-driver → PointCloud → rosbag → ellenőrzött tárolás → feldolgozható pontfelhőminták

A járműfelvételeken két LiDAR-pontfelhő közül választhattok:

• /luminar_pcl;
• /lexus3/os_center/points.

Az ego mozgás odometriaadata a /novatel/oem7/odom topicban érhető el. Egy feldolgozási láncon belül rögzítsétek, melyik LiDAR-topicból dolgoztok, és a pontfelhőket az időbélyegük alapján szinkronizáljátok az ego-odometriával.

A pontfelhő mellett érdemes még rögzíteni:

• az időbélyegeket és frame-azonosítókat;
• a szükséges TF-transzformációkat;
• a szenzorbeállításokat és kalibrációt;
• mozgó járműnél a rendelkezésre álló IMU/odometria adatokat;
• a mérési menet azonosítóját és körülményeit.

A tárolásnál legyen rendezett elnevezés, metaadat, mentési stratégia és adatvédelmi szabály. A feldolgozott minták maradjanak visszakövethetők az eredeti felvételig.

Cél: a saját szenzor és környezet jellemzőit lefedő, minőségellenőrzött tanítóadat készítése.

Vizsgáljátok meg:

• a pontfelhő mezőit és adattípusait;
• a koordináták mértékegységét és tengelyirányait;
• az intensity meglétét és skáláját;
• az időbélyeget és a frame_id értékét;
• a LiDAR–jármű transzformációt;

Gyűjtsetek változatos jeleneteket publikus adatkészletekből/rendelkezésre álló Lexus mérésből:

• közeli és távoli objektumok;
• különböző irányok és takarások;
• eltérő pontsűrűség;
• álló és mozgó objektumok;
• objektummentes helyzetek.

Először kis pilot-adathalmazt érdemes annotálni. A kategóriákat, yaw-konvenciót és a nehezen látható objektumok kezelését egyeztetve.

A train–val–test felosztás menetek vagy jelenetek szerint történjen. (Ugyanazon felvétel szomszédos frame-jeinek véletlenszerű szétosztása adatszivárgást és túl optimista eredményeket okozhat.)

Ellenőrizhető eredmény: annotációs szabályzat, ellenőrzött címkék, adathalmaz-statisztika és rögzített adatfelosztás.

Rögzítsétek az annotálási szabályokat:

• mit kell és mit nem kell címkézni;
• hogyan kezelitek a takart vagy kevés pontból álló objektumokat;
• milyen koordinátarendszerben adjátok meg a dobozokat;
• mit jelent a doboz pozíciója, mérete és yaw szöge.

Cél: a saját adatok helyes betöltése, transzformálása és átadása a modellnek. = dataloader készítése.

Vizualizáljátok a betöltés utáni pontfelhőt a ground truth dobozokkal együtt. Így a konverziós hibák még tanítás előtt felismerhetők.

Ellenőrizhető eredmény: helyesen működő dataloader, pointformátum, osztálynevek, koordináta és méretkonvenciók.

Cél: a publikus adatokon tanult modellt a saját szenzorhoz és környezethez adaptálni.

A munkamenet:

1. Kis mintán overfitting végzése.
2. ha nem tud a háló 10-20 mintán betanulni akkor adat, címke, konfigurációs paramétereket kell vizsgálni.
3. Töltsétek be az előtanított súlyokat.
4. igazítsátok a batchméretet és learning rate-et a saját hardverhez;
5. Igazítsátok a konfigurációt az osztályokhoz.
6. osztályszám-változás esetén kezeljétek tudatosan a detekciós fej eltérését;
7. Indítsatok dokumentált tanítási kísérleteket.
8. mentsétek a konfigurációt, naplókat, adatverziót és checkpointokat.
9. A validáció alapján válasszatok modellt.
10. A végleges összehasonlítást az elkülönített teszthalmazon végezzétek el.

Ellenőrizhető eredmény: checkpoint, kísérleti naplók és számszerű összehasonlítás. precision, recall, osztályonként és távolságonként eredmények, false positive, false negatives. A csökkenő training loss önmagában nem bizonyít javulást. A saját tesztadatokon hasonlítsák össze az előtanított és továbbtanított modellt, azonos osztályértelmezéssel és kiértékelési szabályokkal. Vizsgáljátok meg a hibák okát is: címkehiba, szenzorkülönbség, ritka osztály vagy túlillesztés.

Cél: igazolni, hogy a komponens a tényleges célhardveren és járműrendszerben is megfelelően működik.

Az integráció fokozatai:

1. Offline ros-visszajátszás.
2. Élő működés álló járművön.

Optimalizálás csak mérés alapján történjen. Egy gyorsított modellnél a pontosság megőrzését is ellenőrizni kell. Biztonsági keret: a hallgatói detektor kezdetben csak megfigyeljen és naplózzon; ne kapcsolódjon közvetlenül fék- vagy kormányvezérléshez.

Ellenőrizhető eredmény: dokumentált tesztjegyzőkönyv és célhardveren működő, passzívan integrált komponens.

Cél: a projekt átadható, reprodukálható és szakmailag értékelhető legyen.

A dokumentáció folyamatosan készüljön, és tartalmazza:

• a feladatot, architektúrát és csapattagok hozzájárulását;
• a telepítési és indítási lépéseket;
• az adatgyűjtést, annotációt és adatfelosztást;
• a modellválasztás indoklását;
• a konfigurációkat, checkpointokat és kísérleti eredményeket;
• a ROS-interfészeket és járműves teszteket;
• az ismert hibákat és alkalmazási korlátokat.

A mérnöki érték nem az, hogy a rendszer minden felvételen hibátlannak látszik, hanem hogy a hallgatók értik, mérik, fejlesztik és dokumentálják a működését.

A projektben az MMDetection3D keretrendszer v1.4.0 API-ját használjuk. A környezeti útmutató három támogatott munkamód telepítését, használatát és ellenőrzését írja le:

• Google Colab: az első előre tanított CenterPoint inference és a nuScenes mini munkafolyamat ajánlott környezete; a futtatható anyag a CenterPoint nuScenes notebook;
• VS Code Dev Container: reprodukálható csapatfejlesztéshez használható CPU-s adat-előkészítő és GPU-s tanító/inference profillal; telepítése és használata a Dev Container útmutatóban található;
• helyi telepítés: saját GPU, ROS-integráció vagy célhardver esetén; a rögzített Python, PyTorch, CUDA, MMCV, MMEngine és MMDetection verziókat szintén a környezeti útmutató tartalmazza.

A devcontainer install.sh script a konténerkonfiguráció mellett .vscode/launch.json.example fájlt is másol a hallgatói forkba. A példa VS Code debugprofilokat tartalmaz a tools/create_data.py nuScenes mini konverziójához, a tools/train.py CenterPoint tanításához, valamint a tools/test.py előre tanított checkpointtal végzett kiértékeléséhez. A config-, adat- és checkpoint-útvonalakat futtatás előtt ellenőrizni kell.

Minden csapat válasszon elsődleges környezetet, majd rögzítse a fork commitját, a használt configot, checkpointot, adatverziót és a reprodukálható futtatási parancsot. A környezet akkor tekinthető késznek, ha a verzióellenőrzés mellett a nuScenes mini adat-előkészítés és egy előre tanított modell tesztje is sikeresen lefut.

A Segments.ai címkézési és adatkonverziós útmutató egy helyen tartalmazza:

• a Segments.ai regisztráció, felület, 3D címkézés, interpoláció és minőségellenőrzés fő lépéseit;
• az MCAP PointCloud2 és ego-mozgás topicjainak Segments.ai binary-xyzi sequence formátumra hozását, időszinkronnal és teljes ego pózzal;
• egy hallgatók által létrehozandó, generikus metadata.json + points/ + labels/ saját adatszerkezet mezőinek leképezését;
• egy nem létező, megvalósítandó custom_to_nuscenes_data_prep / create_custom_infos belépési pont felépítését a tools/create_data.py és tools/dataset_converters/ alatt;
• az MMDetection3D v2 metainfo/data_list info-formátum, a koordináta-transzformációk, a scene-szintű split és a ground-truth adatbázis követelményeit;
• a tools/misc/browse_dataset.py vizualizációs és adatintegritási ellenőrzéseit, amelyeket tanítás előtt el kell végezni.

Fontos, hogy a nuScenes-szerű MMDetection3D info-fájl nem azonos a teljes nyers nuScenes devkit-adatbázissal. Saját adatnál a hivatalos NuScenesMetric helyett a feladathoz illő saját evaluatort kell készíteni. Polyline címkék nem alakíthatók veszteség nélkül 3D objektumdobozokká; objektumdetekcióhoz Segments.ai 3D cuboid export szükséges.

• nuScenes: 1000, egyenként 20 másodperces bostoni és szingapúri jelenet kamerával, LiDAR-ral, radarokkal, GPS/IMU adatokkal és 3D annotációkkal. A v1.0-mini részhalmaz alkalmas a teljes MMDetection3D folyamat gyors kipróbálására. A letöltés regisztrációhoz kötött, oktatási és más nem kereskedelmi felhasználásra ingyenes; a licencfeltételeket használat előtt el kell fogadni.
• NVIDIA PhysicalAI Autonomous Vehicles: nagyméretű, földrajzilag és környezeti szempontból változatos többkamerás, LiDAR- és radar-adatkészlet ego-mozgással, kalibrációval és gépi címkékkel. A teljes készlet helyett először metaadat alapján kis, releváns részhalmazt válasszatok. A repository nyilvánosan elérhető, de a fájlok letöltéséhez Hugging Face-fiók és az NVIDIA Autonomous Vehicle Dataset License Agreement elfogadása szükséges; a hozzáférési tokent nem szabad Gitbe commitolni. A formátumhoz és részhalmazok letöltéséhez az NVIDIA Physical AI AV developer kit használható.

Publikus adat használatakor is dokumentáljátok a pontos verziót, splitet, licencet és letöltési forrást. A nagy adatok ne kerüljenek a csapat Git repositoryjába.