czech english

DTC Phase 2

jak zvýšit šance na přežití?

DARPA přišla s novou „výzvou”/soutěží: DARPA Triage Challenge. Triage znamená třídění raněných u hromadných neštěstí, přírodních katastrof nebo na bojišti. V zásadě jde o to, že podle úrovně zranění šance na přežití rychle klesá. Mluvíme o zhruba o prvních 15 minutách. Naděje, že v tomto čase bude dostatek kvalifikovaných doktorů je mizivá. Tak nastupují roboti a AI. Update: 27/7/2025 — DTC Systems 2 - W30 (zbývá 9 týdnů) - grid map, pose, audio


DARPA Triage Challenge má podobný časový rozvrh jako již ukončená SubT Challenge. Soutěž bude trvat 3 roky, jsou tři základní kategorie (Primary System, Primary Virtual a Secondary Data) a účastníci jsou jak DARPA sponzorované týmy, tak self-funded týmy.


Obsah


Blog


13. prosince 2024 — Pravidla - Event 2

Pravidla pro druhý rok DTC jsou konečně oficiální (*):
Asi největší překvapení pro System je, že se DARPA rozhodla už v tomto roce přejít na plnou autonomii! (to skoro stojí za screenshot, jak nevinné přídání slůvka not změní úplně charakter soutěže)
Také „noční jízda” bude asi zábava: It is anticipated in Challenge 2 that there will be a night course.
Aby šokované týmy trošku uklidnili (ono už pootevření „zadních vrátek” že tým bude moci number of times zasáhnout je výrazné zjednodušení oproti první verzi pravidel pro rok 2, kde nebyl zbytek modrého textu), tak se i zvedá hladina odměn:

Workshop 2

  • Event Qualification: 12/5/2024 - 1/5/2025 (konec za 3 týdny!)
  • Event Date: 3/9/2025 - 3/15/2025 (březen!)
(*) — neoficiální alfa verze byla zveřejněna před týdnem na DTC fóru (pro přístup je třeba login)

3. ledna 2025 — NDAA 2025

23. prosince 2024 president Biden podepsal National Defense Authorization Act for Fiscal Year 2025. Přišlo mi „vtipné”, že ani po několika dnech není jasné, jaká jsou tedy omezení na UGV (Unmanned Ground Vehicle) v rámci DARPA Triage Challenge.

… ale už to pomalu chápu! Jen pro představu to má 794 stran
AI to úplně růžově nevidí:
The National Defense Authorization Act for Fiscal Year 2025 (FY25 NDAA) includes several key restrictions and provisions specifically targeting unmanned ground vehicles (UGVs), particularly those manufactured by foreign entities, especially from China. Here are the primary restrictions:

Key Restrictions on UGVs

1. Prohibition on Procurement:
  • The FY25 NDAA mandates a study and report on the Department of Defense's (DoD) use of Chinese-made UGVs. Following this assessment, it prohibits the procurement and operation of covered UGVs from foreign adversaries, particularly those identified as posing cybersecurity risks [1][2][3].
2. Supply Chain Risk Assessment:
  • The Act requires the DoD to disassemble and analyze components of commercially available UGVs from foreign adversaries to identify supply chain risks. This includes a comprehensive evaluation of UGVs to enhance the resiliency of the domestic supply chain [3][4].
3. National Security Risk Review:
  • A provision directs national security agencies to assess drones from companies like DJI and Autel Robotics, potentially leading to their inclusion on the Federal Communications Commission’s (FCC) Covered List if deemed a national security risk. This would prevent these companies from obtaining FCC authorization for new models [1][5].
4. Long-term Sunset Clause:
  • Beginning one year after the enactment of the NDAA, the DoD is prohibited from procuring or operating UGVs manufactured by entities in foreign adversary countries. This aims to phase out reliance on potentially insecure technologies over time [3][4].
5. Increased Oversight and Accountability:
  • The legislation emphasizes enhanced oversight regarding the procurement processes for UGVs and other unmanned systems, ensuring that any acquisitions align with national security interests [1][2].
These restrictions reflect a broader strategy to mitigate risks associated with foreign technologies in defense operations, particularly amid growing concerns over cybersecurity and supply chain vulnerabilities.
Citations:

19. března 2025 — Virtuál zrušen

Koukám, že už je ta informace oficiální: After much consideration, we have made the difficult decision to discontinue the DARPA Triage Challenge Virtual Competition for Year 2. This decision was not made lightly, and we understand the impact it will have on teams and the community.
… nejspíše to není poslední krok jak „ušetřit”, ale to uvidíme později …

29. června 2025 — DTC Systems 2 - Robotika

OK, asi je pomalu čas oprášit (nebo naopak zadupat do země) původní myšlenku, se kterou vznikla Matty série. Před čtvrtečním callem s DARPA jsem si narychlo nastudoval ICD Systems, aneb komunikační protokol, jak reportovat nalezené oběti. Stejně tak jsem si stáhl testovací server a přiohnul reportování z SubT:
(osgar) md@md-ThinkPad-P50:~/git/osgar-apps/dtc-systems$ python report_dtc.py Gas 0 0 0
Reporting: Gas
Get Status
b'{"clock":6.889369,"run":"Run2","team":"Test Team","user":"testuser"}'

Report {'casualty_id': 1, 'team': 'Robotika', 'system': 'Matty M01', 'location': 
  {'latitude': 10, 'longitude': 20, 'time_ago': 1}}
b'{"run":"Run2","team":"Test Team","user":"testuser","system":"Matty M01","clock":8.900963,
"report_id":"e2ca8f47-da17-4f9b-b258da52389ec7dd","report_timestamp":"2025-06-26T13:33:44.083908",
"report_status":"accepted","casualty_id":1}'
Traceback (most recent call last):
  File "report_dtc.py", line 128, in 
    print(score(artf_type, args.x, args.y, args.z))
  File "report_dtc.py", line 104, in score
    report_artf(artf_type, x, y, z)
  File "report_dtc.py", line 63, in report_artf
    assert response.status_code == 201, response.status_code
AssertionError: 200
… no asi by z toho úplně 2x nadšený nebyli, ale za mne je důležité "report_status":"accepted". Ono tedy během callu z nich vylezlo, že bude ještě další meeting, kde budu mít demonstrovat pomocí screensharing automatický report a Control Center pro mediky, ale … TODO.
Včera se zárověň otevřelo „registrační okno” na Systems Challenge 2, která začíná za 3 měsíce, a součástí přihlášky jsou i demonstrační videa jak robotů, tak právě tohoto reportingu.
Co mne na callu ale překvapilo (ono, moc jsem DTC posledních X měsíců nesledoval, virtuál padnul, data jsme pustili k vodě sami a system je "trošku" úlet), že celý soutěžní prostor bude zasíťovaný Wi-Fi (5GHz) a bude určena pro soutěžící! Prostě pravý opak toho, co jsme zažili v podzemí na SubT. To najednou dává možnost přímo streamovat ze všech robotů aktuální video … no nice to have. Stále bych se držel LoRA (Long Range Radio) malých paketů jako základ pro reporting (pokud vůbec bude co reportovat).
A příprava? Myslím si, že Matty platforma prošla dostatečnou zatěžkávací zkouškou:
Co dál? Asi hlavně respektovat získané zkušenosti ze SubT, co ze na RoboOrienteeringu „připomněly”, aneb symetrie je krásná vlastnost a pokud se za vámi nezhroutí strop (oblíbený prvek z finále), tak je možné z každé situace vycouvat. Toto by se rozhodně hodilo v první jízdě.
Dále bych chtěl doplnit geofence (to už asi také mělo být na RO25) a kompas (to už raději … nic neříkam). Pak by robot měl alespoň tušit, zda geofence opouští nebo jede po její hranici …

8. července 2025 — DTC Systems 2 - W27 (zbývá 12 týdnů) - skryté předpoklady

Minulý týden se to celkem pěkně rozjelo. V úterý jsme s Jakubem dmontovali postříkovač z M02 a připravili tak zeleného Mattyho na další soutěž. MartinL se pustil do tisku růžového M04 a s Frantou jsme si vyjasnili nástroje co používal ve Virtuálu. Také jsem udělal první „noční jízdy” abych si potvrdil, že na FRE kamera opravdu vypadávala kvůli slabému zdroji. Dostal jsem z ní právě jeden snímek:
Zombie s lidarovým vzorem
Zombie s lidarovým vzorem
Zbytek videa je už jen černo. Lidar jsem vypnul a nechal pouze IR přisvit a to vypadlo celkem dobře (viz mini-video). Zavěr tam slavný není, ale ono nasvícená bílá zeď moc triangulačních bodů nedává. Nárazníky to jistí! Jinak oak.color stream je zase nepoužitelný a je třeba pro detekce použit šedotónové obrázky z levé nebo pravé kamery. OAK ale asi nedává všechny 3 streamy najednou, takže je třeba tu barevnou kameru trošku ošidit (viz Jakubův PR #1020 na balení obrázku až na PC).
Zvuk v OSGARovi dosud nemáme, tak jsem se chtěl inspirovat ROSem, ale v zásadě tam mají AudioData (pole bajtů) a AudioInfo (popis kódování, vzorkovací frekvence a pod). V zásadě „proč ne?”
No a pomalu se dostávám k těm skrytým předpokladům, aneb jsem nepoučitelný a mám to i tady v historii … hmm, tak nemám. No prostě začátkem března byl workshop, kde by člověk vše viděl z první ruky, a je to velmi užitečná zkušenost — viz SubT - Colorado. Leč tělo úplně nesouhlasilo a nastoupil „oblíbený” dávivý kašel při každé myšlence na DTC. Teď to zatím kašel není, ale antibiotika na 14 dní ano.

13. července 2025 — DTC Systems 2 - W28 (zbývá 11 týdnů) - Helena, Audio, grid_map, …

Pokud jste přílišný optimista, jděte testovat. Ono vás to přejde.
Aneb teď jsem byl chvíli testovat M02+M03 a nějak mne ten optimismus přešel. Ale snad si ještě vzpomenu na okamžiky, kdy to vypadalo pozitivně …
Týden začal antibiotikama. Út a St jsem kompletně prospal. I teď bych si skoro šel lehnout, a měl bych jít, … prostě špatně se bojuje na mnoha frontách. Na středečním callu jsme se bavili, že bych to měl pojmout, stejně jako RoboOrienteering, jako společenskou událost a že by to pak nebyl takový stress a možná bych si to i trošku užil. A když nejsou lidi, tak až zapojím AI, studenti na FRE to také dělali, a třeba se mi uleví. Tenkrát jsme nového člena týmu pojmenovali Elena (ChatGPT), tak ja bych to jen o H prodloužil na Helena (Gemini 2.5Pro).
Možná to bylo ještě tu středu, kdy jedna z úloh na seznamu je rozchodit audio v OSGARu. V práci nás stejně neustále tlačí do používání AI, tak jsem to zkusil. Jirka používá PyAudio, tak jednoduchá úloha byla, „napiš mi program v Pythonu, který pomocí PyAudio nahraje zvuk” (toto není přesný prompt, přeci jenom jsem to psal v EN). Podle očekávání i Gemini 2.5 Flash (?) to dala bez zadrhnutí. No a pak tak ze srandy jsem připsal „a teď na to udělej driver do OSGARa”. Jako Flash dost halucinoval (např. v OSGARu konfigurace v TOML opravdu není), ale když jsem přepl do Gemini 2.5 Pro, tak to vystřelila tak, že bych to snad lépe nenapsal! A okamžité pocity hodně smíšené. OSGAR je open source, tj. vše je k dispozici, ale dokumentace je mizerná, takže je třeba jít do kódu. To Helena dala. Ale návrhy proměnných, název třídy, návrh konfigurace … jak kdybych si to psal sám. … jediná drobnost byla, že to nefungovalo. Opravdu mne nebavilo se s ní přít: I've double-checked the OSGAR architecture, and I can confirm that osgar.node.Node does not inherit from threading.Thread., když já vidím:
from threading import Thread

class Node(Thread):
ale nechť má svoji pravdu. Připsal jsem tam svůj jednořádkový fix a bylo (viz PR #1024). Jako fakticky testováno je to pouze na Win11, na ODroidu zatím pouze instalace a pokus, že to nespadne. Budu muset sehnat vhodný mikrofón se stereo (díky PavleS) jackem 3.5mm.
No a když jsem byl tak rozjetý, tak jsem si říkal, že zkusím úlohu, do které se nikomu nechce, ale mne by se to fakt moc hodilo — Python verzi grid_map od ANYmal. Je v C++, podporuje různé vrstvy a mapě, ale pro mne základ by byla elevation map, kde bych integroval jednotlivé 3D hloubková data z Mattyho OAK-D kamery. Myslel jsem si, že mne Helena pošle do háje, ale neposlala. Prý je to medium challenge a tak jsme střední dobu zápasili. Nakonec z toho něco vypadlo (grid_map_py-0.0.1-cp310-cp310-linux_x86_64.whl), ale do gitu jsem to pořádně ještě neposkládal. Vlastně vůbec netuším jestli to co vzniklo je k něcemu použitelné. Toto tvrzení lehce naznačuje můj stupeň pochopení. Rozhodl jsem se to dat do odděleného repositáře, který jsem před chvílí vytvořil zde, ale zatím je to prázdné!
Jo ještě jednu úlohu jsem hodil na Helenu a to dala od A do Z, zapracovala připomínky a je to zamergeovaný (PR #11, DTC Causality Report generation Ver0). Sice jsem si později přečetl, ze DARPA chtěla něco trošku jiného: Teams must demonstrate a working user interface. This should include features such as marking objects on a map and the capability to convey casualty features such as Severe Hemorrhage status. … no možná ještě Helenu poprosím, ať to trošku přepracuje. Teď to jede z JSON reportů, které stejně musíme poslat, pokud chceme bodovat a obrázek situace, který je ale pouze někdy k dispozici. Ver0 vypadá takto.
No a to se obloukem pomalu dostávám k dnešnímu večernímu testování. Říkal jsem si, že bych přeci jenom měl nahrát videa Mobility - For ground systems, the movement must be over uneven terrain to include dirt, gravel, and grass. The course should include at least two 90-degree turns.
Mám dva roboty, tak bych měl testovat s oběma najednou, ať pak těch pět není takový šok, není-liž pravda? První pozorování — dva roboty najednou v ruce neunesu. Tak jsem je postupně dostal na louku a M02 se nepřipojil k AP (na mobilu). Sigh. No tak pojedu jen z M03. No a pak byly asi 3-4 pokusy jet 17m rovně zatočit o 90 stupňů vpravo, dalších 10m, zatočit o 90 stupňů vlevo a ujet ještě 8 metrů. Louka je ale neposekaná, jen jsem vytrhal pruh na auto (a na roboty), takže se skoro vždy někde zasekl. Peklo.
Demo2 - přejezd hromady štěrku byla brnkačka.
No a pak jsem si říkal, že zkusim denní jízdu v prostředí, kde bych později zkusil i noční jízdu. No to byla katastrofa. Ona M02 si to v mezičase rozmyslela a také se připojila, tak jsem je oba „na divoko” pustil do „lesa”. Jako bude tam třeba seriózní koordinace všech členů! Vlastně i na SubT jsme roboty vypouštěli postupně, ale tam o čas až tak nešlo. Tady je za 15min po všem.
Pokud stažená videa z momentálně vybitého telefonu nebo logy z robotů budou nějak použitelné, tak ještě doplnim … ale teď je čas opravdu jít do postele.
p.s. stahuji logy a evidentně jsem updateoval config jenom u jednoho z robotů (aby se používalo H.265 kódování videa:
m03-dtc-day-250713_170143.log
    140,168,400 100%    5.90MB/s    0:00:22 (xfr#1, to-chk=16/26)
m03-matty-followpath-250713_163357.log
         20,199 100%   31.87kB/s    0:00:00 (xfr#2, to-chk=11/26)
m03-matty-followpath-250713_163547.log
    808,649,552 100%    5.69MB/s    0:02:15 (xfr#3, to-chk=10/26)
m03-matty-followpath-250713_163908.log
  1,285,921,633 100%    5.94MB/s    0:03:26 (xfr#4, to-chk=9/26)
m03-matty-followpath-250713_164134.log
p.s.2 videa:

20. července 2025 — DTC Systems 2 - W29 (zbývá 10 týdnů) - nedotažené konce

Uplynulý týden bych označil jako nedotažené konce, aneb jak by můj dědeček řekl: „Je to hotové, jen to dodělat”.

DTC User Interface

GUI je součastí registrace a už minule jsem zmiňoval, že si představují mapu obětí se zvýrazněním případů s vážným krvácením. Toto psala zase Helena (viz PR #12). Je to zase mezi-verze, protože podkladová mapa je z OpenStreetMap a to samo offline fungovat nebude. Pro aktuální demo viz video (ne náhodou je unlisted)- Helena má přípravenou ještě verzi s PNG se souřadnicemi, kteoru pomocí GDAL převede na mapové dlaždice … jako bylo by to pěkné, ale snad později.

Audio

Na této frontě je nový mikrofón (nejlevnější s odpovídajícím 3.5mm jackem) a test na Odroidu. Selhal. Zvuk se sice krásně komprimoval, ale ano, byly to samé nuly. PavelS mi poslal výřez PDFka, jake je audio zapojené:
tj. nahoře je jack na repráčky, uprostřed je mikrofón a dole nějaka optická vychytávka … píše: „S/PDIF (Sony/Philips Digital Interface) je digitální rozhraní pro přenos audia. Jako medium se používá koaxialní nebo optický kabel.” https://en.wikipedia.org/wiki/S/PDIF
No a teď proč to sakra nefunguje?! Levný mikrofón je sice mizerný, ale nějaký výstup dává (testováno ještě při callu ve středu). Drivery jsou, ale při spuštění OSGAR narávání to hrozně nadává:
ALSA lib confmisc.c:855:(parse_card) cannot find card '0'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_card_inum returned error: No such file or directory
ALSA lib confmisc.c:422:(snd_func_concat) error evaluating strings
Na doporučení jsem se na OSGAR vykašlal a zkoušel přímo nástroje systému arecord -larecord: device_list:274: no soundcards found... . A to jsem si myslel, že kabelovým mikrofónem se problemům s drivery a pod vyhnu. Chyba lávky.
Druhý den jsem trošku z nedostatku nápadů zkusil zvuk přehrát (aplay) a zase nic?! Jako jsem hodně sklerotický, ale toto mi už na Odroidu snad sakra fungovalo?! A ano … fungovalo … ale když jsem byl přihlášen, používal monitor a kliknul na nějaký WAV nebo si pustil YouTube video! Aneb zde je ten zakopaný pes. Pokud pustím příkaz přehrání tak dokonce čeká, dokud se v jiném terminálu nepřihlásím. Sigh.
Jirka pak psal, že Během boje s bluetooth jsem pulseaudio nahradil za pipewire + pipewire-pulse + wireplumber. Klíčový pojem muže být "system-wide pulseaudio". Tak toto jsem také nedotáhl. Jedna z možnosti je v BIOSu změnit automatické přihlašování na startu, ale … tam se zase nedostanu z bezdrátovou klávesnicí. TODO

Pose Estimation

Jeden ze vstupů pro analýzu zdravotního stavu je pose estimation, aneb kde je hlava, ruce atd. YOLO modely mají v sobě i variantu pose, jen ty modely jsou v PyTorch. A já bych do OAK-D Pro potřeboval blob formát. Existuje Luxonis BlobConverter (sice deprecated, ale stále funguje), ale co použít za vstup? Tady zase díky Jirkovi - ONNX je správný meziformát: https://docs.ultralytics.com/integrations/onnx/. Hmm, teď čtu ten mail znova celý a jsou tam samozřejmě i další kroky a to jaké extra parametry případně použít a kde se na ONNX podívat … jj, ještě věci dotahovat a maily číst do konce … tj. TODO je podívat se na ONNX velikosti vstupů a výstupů.

Noční vidění

Jeden z úkolů je demonstrovat autonomní navigaci v noci. A s tím je i spojená detekce zraněných v noci bez extra světla (IR přísvit je povolen). Propojení detektoru na levou monochromatickou kameru je snad pořešeno (viz PR #1026), ale při testu se mi podařilo zlomit už třetí nárazník! (až toto bude MartinL číst, tak se na mne naštve a zastaví výrobu M04 a M05 :-( https://youtu.be/C0kljPdg5js
Ani nevím, zda zmiňovat důvod, proč to tam napral do té žídle? Sigh. No to jsou ty mé copy and paste, aneb stále tam byl kus kódu, že „když nemůžeš tak přidej víc” … ne to si s něčím pletu … myslím tím, pokud není cesta jeď rovně (aneb v poli si ji udělej, v reálném světě to ale občas bolí).
timeout … tj. ani tento zápis pořádně nedodělám. Chybí Terminátor, poděkování za tip Jirkovi roboty prostě nastartovat v klidu doma, ale kód spouštět až na uvolnění STOP tlačítka (a notebook a telefon ani s sebou nebrat, stejně jako na Robotem Rovně 2025), vtip proč mi včera v noci tak hloupě robot ujížděl do keřů (hint, bylo to severo-západním směrem), páteční call s DARPA … někdy příště.
p.s. alespoň jedna z delších nočních jízd — https://youtu.be/oqklhJHKlBg

27. července 2025 — DTC Systems 2 - W30 (zbývá 9 týdnů) - grid map, pose, audio

Dnes to bude stručné, aneb ani na report už teď nemam moc sil. Asi první zpráva je, že jsem odeslal Robotika - Systems přihlášku na CE2 (Challenge Event 2). Žádná sláva, ale tento víkend jsem byl pryč a uzávěrka je do konce července a to už nic lepšího nedoplním. Podle dřívější zkušenosti se sami ozvou, co jim přijde nedostatečné a pak budeme mít 10 dní na to to nějak napravit.
Druhá zpráva je, že jsem si koupil naslepo nějaké hračky — chtěl jsem k tomu sepsat malý příspěvek a nazvat ho Zajíc v AlzaBoxu, ale ono to dopadlo relativně OK, tj. žádné drama. Potřeboval jsem koupit SSD disky do dalších dvou robotů M04 a M05 a tak jsem do košíku přihodil i „co by se mohlo hodit”. Jednak to byla numerická klávesnice na USB, která ma tlačítko Del. A funguje, resp. pomocí této klávesnice se už do BIOSu Odroidu (řídící počítač pro všechny Matty roboty) dostanu. (asi kontext, že s bezdrátovou klavesnicí, co jsem pořízoval na Elrob loni nikoliv)
Druhý zajíc byl C-TECH SPK-08R (klíčová slova byla reproduktor a jack 3.5mm). Je rozmně malinký 6x6x6cm, ano trošku ďábelský, ale když jsem ho rozbalil, tak na jack zdířce byla ikonka sluchátek?! A ano, bez kabelu … který jsem tedy koupil v druhé vlně. Ale funguje to, jen je po startu třeba 2x stisknout MODE (Bluetooth, Radio, AUX). A možná i ten Bluetooth bude použitelný? S notebookem i s Odroidem (v GUI) se to spárovalo a pak to přehrávalo zvuky. A co více je tam i malý mikrofón! Uvidíme, časem, možná. (A ano, koupil jsem další mikrofón s jack 3.5mm, ale ten jsem vlastně ještě ani nevyzkoušel)
Úprava navigace robota, že když to nikam nejde, tak místo „jeď rovně” se pořádně rozhlédni, pomohla v tom smyslu, že už Matty není tak sebe-destruktivní, ale … ve vysoké trávě nikam nedojede.
Také jsem upravil offline reporting se staženými mapovými dlaždicemi (viz PR #13), takže teď se vlastně může každý robot chovat jako webový server a poskytovat info, na jaké pozici koho detekoval, včetně obrázků detekcí, ale nejprve musí někam dojet …
Pro další posun mi už přijde nutná nějaká ta mapa, tak se trošku posunula i grid_map fronta. Jako není to nic světoborného a k videu PavlaS z Výpustku to má ještě hooodně daleko, ale zase snad malý krůček vpřed. Pro začátek jsem si postavil malý Stonehenge.
Simuluj zeď v depth kameře ve 2m vzdálenosti a opakuj v 360deg kruhu
No reálným obrázkům zatím vůbec nerozumim:
Jako už jsem si otočil souřadnice, kdy world má X dopředu, Y vlevo a Z nahoru vs. kamera X vpravo, Y dolů a Z dopředu, ale ještě tam bude zakopaný nějaký ten pes, možna dva a více. Minimálně jsem si vědom, že update grid_mapy je asi natvrdo přířazení poslední hodnoty, takže když jich je tam více s různou výškou, tak vyhraje „libovoný” (no jede se po řádcích, takže ten úplně dole s malou hodnotou). ATD.
Ještě jsem sliboval tu pose — no Jirka měl pravdu, že AI na toto téma ví všechno (perplexity):
I am trying to use yolo v11n pose model and it returns array 1 x 56 x 8400 - what is it?
The 1 x 56 x 8400 array returned by a YOLOv11n pose model represents the model's raw output for pose estimation.
Here's a breakdown of what each dimension signifies:
  • 1 (Batch Size): This indicates that the model processed a single image at a time. If you were processing multiple images simultaneously, this number would change to reflect the number of images in your batch .
  • 56 (Features per Detection): This dimension contains the information for each detected object, specifically designed for pose estimation . It's typically broken down as follows:
  • First 5 values: These represent the bounding box coordinates and confidence score for a detected object (e.g., a person). This usually includes x, y, width, height, and confidence .
  • Remaining 51 values (17 keypoints x 3 values per keypoint): These are the keypoints for pose estimation. YOLO models trained on datasets like COCO typically detect 17 keypoints (e.g., nose, eyes, shoulders, elbows, wrists, hips, knees, ankles) . Each keypoint is represented by three values: its x coordinate, y coordinate, and a visibility score or confidence . So, 17 keypoints * 3 values/keypoint = 51 values.
  • 8400 (Number of Potential Detections/Anchors): This is the total number of anchor boxes or potential detections the model considers across the input image. Each of these 8400 entries contains the 56 features described above .
Post-processing is crucial to interpret this raw output . The 8400 potential detections need to be filtered and processed to extract meaningful results. This typically involves:
  • Non-Maximum Suppression (NMS): To eliminate redundant bounding box detections that overlap significantly.
  • Confidence Thresholding: To filter out detections with low confidence scores.
  • Converting Coordinates: The raw keypoint coordinates might be normalized or relative to the bounding box, and often need to be converted to actual image coordinates for visualization or further use .
In essence, the 1 x 56 x 8400 array is the comprehensive set of predictions from the YOLOv11n pose model, which requires specific post-processing steps to yield the final detected objects with their poses.
… no ale zatím jsem s tím nic neudělal. :-(
A vlastně ještě jedna drobnost — OSGAR Matty driver teď publikuje joint_angle (PR #1027), což by se hodilo minimálně u toho „rozhlížení se na místě”.