Expertiză · Sisteme pentru roboți

Software pentru roboți: stratul care decide mișcarea, modulul de vedere și cel de auz. Azi avem verificare offline și simulare — nu avem nimic care comandă un motor real.

Scriem cinematică, verificare de traiectorie și simulare fizică reproductibilă, cu porți care blochează atunci când dovada lipsește. Pentru vedere avem un prototip pe cameră fixă, nu pe robot. Pentru audio pe robot nu avem nimic construit, și pagina spune asta în loc să împrumute dovezi de la telefonie. Nu lucrăm cu ROS.

Discută un proiect

Ofertă, cu condițiiAm rulat azi tot ce se poate rula. Stratul de control există și e serios, dar e offline: un modul propriu de cinematică pentru un braț cu șase axe, care a rezolvat 8.400 din 8.400 de puncte de traseu, și un validator de fizică pe MuJoCo 3.10.0 cu 34 de teste trecute, plus 14 teste pe partea de vizualizare. Amândouă declară în propria sursă că nu au transport către hardware și nu pot comanda un robot real. La vedere avem un prototip propriu — detecție și urmărire de persoane pe cameră IP fixă — cu un singur comit și cu directorul de teste gol. La audio pe robot avem zero: tot ce e pe disc e voce de call-center sau bibliotecă terță de telefonie, iar singura lucrare acustică proprie s-a încheiat cu un rezultat negativ, scris în aplicație. ROS: zero instalat, zero scris. Regula cere minimum două implementări proprii pentru „am făcut”; pe control le am, dar niciuna nu atinge hardware, iar celelalte două straturi ale serviciului sunt sub prag. Deci: ofertă cu condiții, cu granițele desenate.

Software-ul unui robot are trei straturi care se strică diferit: ce vede și aude, ce decide, și ce trimite spre motoare. Pe primele două avem lucrări proprii cu teste care rulează. Pe al treilea — puntea către hardware — nu avem nimic, iar asta e granița serviciului, nu un detaliu de implementare. Două dintre codurile noastre o spun în propriul lor antet, în engleză, exact ca să nu poată fi citite greșit: modulul de cinematică nu are transport către hardware și nu poate comanda un robot real.

Ce există pe partea de mișcare e verificare înainte de mișcare. Un modul propriu calculează cinematica directă, jacobianul și cinematica inversă pentru un braț cu șase axe, cu o rezervă impusă față de limitele fiecărei axe, și a fost folosit ca să verifice un traseu întreg: 8.400 de puncte cerute, 8.400 rezolvate, cu viteza maximă pe axă rămasă sub 8% din limita de catalog. Separat, un validator de fizică rulează pe MuJoCo 3.10.0 pe procesor, cu pas de calcul de o milisecundă, în șase scenarii, fiecare de câte două ori, cu aceeași sămânță — și cele două rulări dau amprente identice. Determinismul nu e o afirmație, e o comparație de sume de control.

Ce există pe partea de vedere e mai puțin, și e cinstit să spunem cât. Un prototip propriu face detecție și urmărire de persoane pe fluxuri de cameră IP, cu un detector mic din familia YOLO, un urmăritor multi-obiect, estimare de postură pentru cinci stări și control de rotire-înclinare-transfocare al camerei. Are un singur comit și directorul de teste gol. Iar diferența dintre asta și vederea unui robot e reală, nu formală: camera de pe un robot se mișcă odată cu el, scena e aproape, expunerea se schimbă la fiecare pas, iar bugetul de întârziere e altul, pentru că imaginea trebuie să ajungă la o decizie de mișcare, nu la un ecran. Nu avem cameră de adâncime, nu avem calibrare de cameră, nu avem odometrie vizuală.

Pe partea de audio pentru roboți nu avem nimic construit, și nu vom împrumuta dovezi din altă parte. Avem lucrări reale de voce pentru telefonie și pentru asistenți conversaționali, dar un microfon pe un robot are alte probleme: zgomotul propriu al mașinii, ventilatoare și servomotoare care pornesc exact când robotul se mișcă, direcția din care vine vocea, ecoul din încăpere și distanța variabilă. Singura lucrare acustică proprie pe care o avem s-a terminat cu un rezultat negativ, scris în aplicație, și îl publicăm ca atare — pentru că un rezultat negativ măsurat e mai util decât o promisiune.

Ce cuprinde

Lucrarea, pe componente

Verificăm cinematica înainte de a mișca ceva

Cinematică directă, jacobian analitic construit din produse vectoriale, cinematică inversă numerică cu patru poziții de pornire și o rezervă impusă de 10° față de limita fiecărei axe, cu convergență la 0,05 mm pe poziție. Cu ea am verificat un amplasament în 1.331 de poziții de grilă și un traseu complet de 8.400 de puncte, toate rezolvate. Rezultatele: viteză maximă pe axă la 7,86% din limita de catalog și marjă minimă față de limite de 19,9°. Raportul își scrie singur natura: screening discret offline, fără ieșire către hardware.

Rulăm fizica separat de imagine, și reproductibil

Validatorul de fizică e un program separat de partea vizuală, pe MuJoCo 3.10.0, pe procesor, cu pas de o milisecundă și eșantionare la 20 de milisecunde. Șase scenarii, fiecare rulat de două ori cu aceeași sămânță, cu amprente identice între rulări. Toleranțele sunt declarate în cod, nu subînțelese: derivă de energie sub 1% relativ, pătrundere în sol sub 3 cm, încălcare de limită articulară sub 0,03 radiani. Ce se măsoară în cădere liberă e accelerația centrului de masă, comparată cu gravitația configurată — 9,80665, 1,62 și 3,72076 metri pe secundă la pătrat.

Punem o poartă care blochează, nu una care doar etichetează

Registrul de acțiuni cere fiecărei mișcări să-și declare proveniența, iar toate cele 15 acțiuni înregistrate sunt marcate cinematice, zero validate — pentru că niciun controler din ele nu e condus de un simulator de corpuri rigide cu limite de actuator și validare de contact. Peste el, o poartă de eliberare citește fișierul de dovadă și cade dacă o constantă cheie nu e calibrată pe hardware. Azi cade: o singură constantă de oprire articulară, de 5 milisecunde, e declarată în cod drept parametru provizoriu, nu valoare măsurată — și atât e de ajuns ca verificarea completă să iasă cu eroare. E o regulă scrisă de noi împotriva noastră.

Citim descrierea robotului cu parser propriu, și spunem ce lasă afară

Pentru afișarea și inspecția modelelor am scris propriul analizor de format MJCF: corpuri, articulații de tip balama, liberă, glisantă și sferică, geometrii, materiale și încărcarea plaselor, cu cache de geometrie. Lasă intenționat afară geometriile de coliziune, pentru că e un analizor vizual, nu unul de contact — scris în cod, nu descoperit ulterior. Modelele folosite sunt cele oficiale, cu 29 de grade de libertate pentru umanoid și 12 pentru patruped.

Nu confundăm valorile comandate cu cele măsurate

Unghiurile care apar pe ecran sunt cele comandate de controler, publicate într-o singură direcție către interfață. Nu conțin zgomot de encoder, stare măsurată, cuplu, viteză sau temperatură — scris explicit în auditul tehnic al proiectului. Distincția asta pare mică până când cineva ia un grafic frumos drept telemetrie de robot; de aceea o scriem în cod, în audit și aici.

Vedere: detecție și urmărire de persoane, pe cameră fixă

Un prototip propriu care ia fluxuri de cameră IP, detectează persoane cu un model mic din familia YOLO, le urmărește între cadre cu un urmăritor multi-obiect la un prag de încredere de 0,5, estimează postura în cinci stări — necunoscut, șezând, în picioare, mergând, aplecat — și poate roti camera prin protocolul standard de control. Rulează forțat pe procesor, din cauza unei incompatibilități notate în cod. Stadiul lui real: un singur comit și directorul de teste gol. E un prototip, nu un modul de producție, și nu a fost niciodată pe un robot.

Audio pe robot: spunem ce lipsește, în loc să împrumutăm de la telefonie

Nu avem detector de cuvânt de activare, nu avem detector de voce rulat local, nu avem formare de fascicul, nu avem estimare de direcție și nu avem cod de anulare a ecoului scris de noi. Ce avem în zona vocii e pentru apeluri telefonice și pentru asistenți conversaționali: întreruperea vorbitorului se face fie prin detectorul din serviciul furnizorului, fie prin apăsarea unei taste în meniul telefonic, iar anularea ecoului vine din bibliotecile browserului sau dintr-o stivă terță de telefonie. Sunt lucruri reale, dar rezolvă altă problemă decât un microfon montat pe o mașină care se mișcă și își face singură zgomot.

ROS: nu avem, și nu ne prefacem

Nu e instalat pe nicio mașină a noastră și nu am scris niciodată un nod, un fișier de lansare sau un pachet propriu. Singurul pachet cu sistem de construcție specific ROS de pe disc e descrierea publică a unui robot industrial, descărcată ca fișier de model și folosită exact așa, nu compilată. Dacă proiectul tău presupune ROS 2 ca dat, e o informație pe care trebuie să o ai înainte de prima ședință, nu după.

Ce am accepta și ce nu

Am accepta: verificare cinematică și de traiectorie înainte de o achiziție, simulare cu toleranțe declarate, un modul de percepție măsurat pe datele tale, și o punte către hardware făcută împreună cu integratorul care răspunde de siguranță. Nu am accepta: să scriem singuri stratul care oprește un robot în caz de urgență, să promitem un modul de audio pe robot fără o măsurare prealabilă a zgomotului propriu al mașinii tale, și nici să spunem că experiența noastră de voce la telefon acoperă auzul unui robot.

Cum arată

Traseul, pas cu pas.

Definim sarcina și limitele fizice, apoi verificăm dacă încap

Ce trebuie să atingă robotul, în ce volum, cu ce viteză și ce sarcină. Apoi verificarea: acoperirea volumului, marja față de limitele fiecărei axe, viteza și accelerația pe traseu, coliziunile pe geometrie reală ca screening. Livrăm raportul cu limitările lui scrise. Etapa asta are un raport bun între cost și pagubă evitată, pentru că se face înainte de o achiziție.

Simulăm cu toleranțe declarate și cu determinism verificat

Scenarii, sămânță fixă, rulări repetate, comparare de amprente, toleranțe scrise în cod. Livrăm și lista de lucruri pe care simularea NU le demonstrează — la noi, de exemplu, un validator care confirmă căderea liberă și menținerea poziției pe un plan de test nu confirmă mersul, contactul complex sau dinamica actuatorului, și scrie asta singur.

Construim percepția pe datele tale, nu pe un set public

Un detector care merge pe imagini de pe internet nu spune nimic despre hala ta. Etapa înseamnă captură din mediul real, un set de evaluare propriu, o măsurătoare de referință și abia apoi alegerea modelului și a locului unde rulează. Livrăm cifrele de referință și metoda cu care le poți reproduce, inclusiv când sunt slabe.

Puntea către hardware — etapa pe care nu am făcut-o niciodată

O scriem ultima și o scriem cu condiții, pentru că e singura din listă în care nu avem experiență proprie. Se face împreună cu integratorul sau cu producătorul robotului, iar funcțiile de oprire de urgență, de limitare și de siguranță rămân în responsabilitatea celui care răspunde de mașină. Ce putem duce noi până acolo e stratul de decizie, verificat, cu interfața lui documentată.

Lanțul unui robot, de la stânga la dreapta, cu starea reală a fiecărei verigi. Vedere: prototip pe cameră fixă, un singur comit, fără teste. Auz: gol — nimic construit pentru un microfon pe o mașină care se mișcă. Decizie și cinematică: verificat, cu 8.400 de puncte rezolvate și cu o poartă care blochează atunci când o constantă nu e calibrată. Ultima săgeată, cea către motoare, e întreruptă: niciun cod al nostru nu are transport către hardware. Desenul e făcut ca să se vadă unde se oprește serviciul, nu ca să pară complet.

Datele

Ce atingem, unde stau și cât rămân

Întrebările pe care le pune oricine are un responsabil cu protecția datelor — puse aici înainte să le pună el.

Camera unui robot filmează oameni, și asta schimbă tot: Un modul de vedere care detectează și urmărește persoane produce date personale în sensul propriu al cuvântului, chiar dacă nimeni nu e identificat pe nume. Întrebările se pun înainte de prima linie de cod: se păstrează imaginea sau doar rezultatul, unde se procesează, cine are acces la înregistrări, cât timp se țin, ce se afișează celor filmați. Prototipul nostru a fost construit ca experiment tehnic, nu ca sistem pus în funcțiune, și nu îl propunem ca atare.
Pe dispozitiv sau pe server — o decizie de întârziere, nu de preferință: Dacă imaginea trebuie să ajungă la o decizie de mișcare, drumul până la un server și înapoi intră direct în bugetul de reacție. Dacă rezultatul e doar afișat sau înregistrat, serverul e acceptabil. Decizia se ia din bugetul de întârziere măsurat pe cazul tău, și se scrie. Prototipul nostru rulează forțat pe procesor, ceea ce e o limitare reală de viteză, notată în cod.
Simulările se păstrează cu sămânță și cu amprentă: Un rezultat de simulare fără sămânța generatorului și fără suma de control a intrărilor nu e o dovadă, e o poveste. Rapoartele noastre de fizică poartă sămânța, numărul de rulări per scenariu, versiunea motorului și starea de determinism; rapoartele de cinematică poartă amprenta fișierelor de intrare. Așa se poate verifica, luni mai târziu, dacă o cifră citată mai e valabilă.
Audio înseamnă a înregistra o încăpere: Un microfon pe un robot aude tot ce se întâmplă în jur, nu doar comanda care i se dă. Regula pe care am aplica-o e ca înregistrarea continuă să nu existe implicit, ci doar fereastra necesară deciziei, iar ce se păstrează pentru îmbunătățire să fie o alegere explicită, cu termen. Nu avem încă un astfel de sistem construit, deci e o poziție declarată, nu o practică demonstrată.
Modelele și descrierile de robot au licențele lor: Modelele de robot pe care le folosim în simulare provin din colecții publice, sub licențe permisive, iar descrierile de roboți industriali sunt fișiere publice ale producătorilor. Nu sunt ale noastre și nu le revendicăm; într-un proiect al tău, licența fiecărei surse externe se verifică înainte de a intra în livrabil.

Un caz

O măsurătoare acustică proprie care s-a încheiat cu „nu”, și de ce o publicăm

Situația

Într-o aplicație proprie de macOS am vrut să aflăm dacă difuzorul și microfonul unui dispozitiv de consum pot fi folosite ca sonar simplu — un semnal emis, ecoul lui măsurat, o distanță dedusă. Întrebarea e exact cea care apare și la un robot: cât poți afla despre spațiul din jur folosind hardware audio pe care îl ai deja, fără senzori suplimentari.

Ce am construit

Am construit lanțul complet, nu o schiță: un semnal baleiat de 12 milisecunde care urcă de la 2 la 8 kilohertzi, ferestruit, emis la amplitudine mică; corelație încrucișată între semnalul emis și cel înregistrat; detecția sosirii directe cu o fereastră de gardă de 1,5 milisecunde, ca lobii laterali ai autocorelației să nu fie luați drept ecou; căutarea ecoului într-o fereastră de până la 60 de milisecunde, cu praguri separate de corelație și de câștig relativ; viteza sunetului corectată cu temperatura aerului. Aproape 800 de linii de Swift, cu detectarea traseului audio — dacă emițătorul și receptorul sunt pe dispozitive diferite, geometria e bistatică și un singur timp de întârziere definește o elipsă, nu un punct.

Ce a ieșit

Concluzia e scrisă în aplicație, în ecranul care spune ce poate și ce nu poate măsura: pe difuzorul și microfonul aceluiași calculator se pot detecta schimbări grosiere ale reflexiilor după calibrare, pentru că latența e relativ stabilă. Prin căști fără fir însă, reducerea activă a zgomotului, formarea de fascicul, codecul și latența variabilă distrug măsurarea metrică precisă — deci pot fi folosite pentru orientarea capului, nu ca sonar precis. Am scris asta în produs, nu într-o notă internă.

Ce nu spune cazul

Rezultatul e despre hardware de consum peste o legătură fără fir, nu despre un robot cu microfoane montate și cablate. Ce se transferă nu e concluzia, ci metoda: se măsoară canalul înainte de a promite funcția. Pentru un robot, aceeași investigație ar începe de la zgomotul propriu al mașinii în mișcare — și abia rezultatul acelei măsurători ar spune ce e posibil.

Întrebări

Ce ne întreabă oamenii înainte să sune

Ați pus vreodată software-ul vostru pe un robot fizic?

Nu. Niciun cod al nostru nu a comandat vreodată un motor real, și două dintre codebase-urile noastre o declară chiar în antetul fișierului, ca să nu poată fi citite greșit. Ce am rulat e simulare și verificare offline. Dacă asta e o problemă pentru proiectul tău, e mai bine să o știi de la prima frază decât să o descoperi la a treia ședință.

Atunci ce anume aveți, concret?

Trei lucruri, toate rulabile în fața ta. Un modul de cinematică pentru un braț cu șase axe, care a verificat un traseu de 8.400 de puncte fără niciun eșec, cu marjă minimă de 19,9° față de limitele axelor. Un validator de fizică pe MuJoCo 3.10.0, cu 34 de teste care trec și cu determinism dovedit prin amprente identice pe rulări repetate. Și un demonstrator în browser cu 14 teste, a cărui poartă de calificare cade astăzi în mod deliberat. Plus un prototip de vedere, despre care spunem deschis că are un singur comit și niciun test.

Lucrați cu ROS?

Nu. Nu e instalat la noi, nu am scris niciun nod, niciun fișier de lansare și niciun pachet. Singurul pachet de tip ROS de pe discurile noastre e descrierea publică a unui robot industrial, descărcată ca fișier de model pentru calculele de cinematică — folosită ca date, nu construită. Dacă echipa ta lucrează deja în ROS 2 și asta e o cerință, noi pornim de la zero acolo, și trebuie pus la socoteală.

Puteți face modulul de vedere pentru robotul nostru?

Cu o etapă de măsurare înainte, nu pe baza prototipului pe care îl avem. Ce se transferă din el e felul de a lucra — detector, urmăritor între cadre, prag de încredere, unde rulează calculul. Ce nu se transferă e situația: camera de pe un robot se mișcă, subiectul e aproape, lumina se schimbă la fiecare pas, iar rezultatul trebuie să ajungă la o decizie de mișcare, nu la un ecran. În plus, nu avem cameră de adâncime, calibrare de cameră sau odometrie vizuală în niciun proiect propriu. Prima etapă ar fi captură din mediul tău și o măsurătoare de referință.

Aveți agenți vocali. Nu e același lucru cu auzul unui robot?

Nu, și nu vrem să pară că e. La telefon, canalul e cunoscut și îngust, vorbitorul e lipit de microfon, iar întreruperea vorbitorului o rezolvă fie serviciul furnizorului, fie o tastă apăsată. Pe un robot, microfonul stă pe o mașină care își face singură zgomot exact când se mișcă, vocea vine dintr-o direcție care se schimbă, încăperea produce ecou și distanța variază. Sunt probleme de acustică, nu de conversație. Am putea începe de la o măsurare a zgomotului propriu al robotului tău — dar ar fi o lucrare nouă, nu o extindere a celei de telefonie.

De ce publicați o poartă de calificare care cade?

Pentru că alternativa e ca ea să treacă fără să însemne ceva. Poarta noastră citește un fișier de dovadă și verifică dacă o constantă critică — timpul de oprire la capătul de cursă al articulației — a fost calibrată pe hardware. Nu a fost: e o valoare provizorie de 5 milisecunde, pusă ca să existe o simulare stabilă. Cât timp e provizorie, verificarea completă iese cu eroare, iar toate acțiunile rămân marcate cinematice. Ziua în care va trece o să însemne ceva exact pentru că azi nu trece.

Ce nu demonstrează simulările voastre?

Mai mult decât demonstrează, și e scris în rapoarte. Validatorul de fizică confirmă căderea liberă și menținerea poziției pe un plan de test — nu mersul, nu contactul complex, nu dinamica actuatorului, nu senzorii sintetici. Screeningul de traiectorie confirmă cinematica și geometria — nu materialul, nu furtunurile flexibile, nu întârzierile de proces, nu rampele de pornire-oprire ale controlerului. Iar mișcarea din browser e o previzualizare, nu un rezultat de simulare.

Ne trebuie certificare de siguranță. O faceți?

Nu. Arhitectura de siguranță o putem proiecta — circuit separat de controlul mișcării, controler de siguranță independent, oprire sigură a cuplului, frâne cu feedback, stări de defect care cad în siguranță; asta am și făcut într-un proiect propriu de mașină. Dar evaluarea de conformitate și responsabilitatea pentru mașina pusă pe piață rămân la producător sau la integrator. Nu ne asumăm rolul acela și nu semnăm în locul nimănui.

De ce scrie „ofertă” pe pagina asta?

Pentru că serviciul are trei straturi și niciunul nu trece complet pragul pe care ni l-am pus. Pe control avem două lucrări proprii cu teste care trec, dar niciuna nu atinge hardware. Pe vedere avem un prototip cu un comit și fără teste. Pe audio pentru roboți avem zero. Am fi putut scrie o pagină care sună a experiență, folosind cuvinte ca „percepție” și „control” fără cifre. Ar fi rezistat până la prima întrebare a unui inginer.

Pe ce se sprijină fiecare afirmație de mai sus (17 surse)

Modulul propriu de cinematică declară în antet că nu are transport către hardware și nu poate comanda un robot real, iar câmpurile de efort și inerție din descrierea publică nu sunt folosite ca valori validaterobotics.py:1-4 (antetul modulului); 62-89 (`fk`, `jacobian`, `margin_deg`, `solve` cu rezervă `margin_deg=10`, patru poziții de pornire, prag 0,00005 m și 0,0001 rad)
8.400 de puncte cerute și 8.400 rezolvate, zero eșecuri; viteză maximă pe axă 7,86% din limita de catalog; marjă minimă 19,9°; fără ieșire către hardwaretrajectory-report.json:`state: OFFLINE_DISCRETE_PATH_SCREEN`, `hardware_output_generated: false`, `samples_solved: 8400`, `failures: []`, `max_velocity_fraction: 0.0785…`, `min_axis_margin_deg: 19.932…`, secțiunea `limitations`
1.331 de poziții de grilă verificate pentru amplasament; verificarea de coliziune e screening discret, nu analiză certificată de volum măturatrobot_collision.py:`state: DISCRETE_KINEMATIC_SCREEN_ONLY`; robot_collision.py:1 (antetul modulului)
Validator de fizică pe MuJoCo 3.10.0, Python 3.12, doar pe procesor; 34 de teste trecutehumanoid-sim:./physics/mujoco/.venv/bin/python -m pytest physics/mujoco/tests -q → „34 passed in 16.56s”; physics/mujoco/reports/wave3-evidence.json (bloc `engine`); physics/mujoco/uv.lock (mujoco 3.10.0)
Determinism dovedit prin amprente: șase scenarii, două rulări fiecare, sămânță 731, stare de determinism „pass”; calificarea de eliberare e „blocked” pentru că oprirea articulară nu e calibratăwave3-evidence.json:`determinism_status: pass`, `scenario_count: 6`, `runs_per_scenario: 2`, `seed: 731`, `joint_stop_calibrated: false`, `release_qualification_status: blocked`
Poarta de eliberare cade dacă oprirea articulară nu e calibrată sau dacă starea de calificare nu e „passed”; constanta de 5 ms e declarată în cod ca parametru provizoriu, nu valoare măsurată pe hardwarerunner.py:43-45:`JOINT_LIMIT_SOLREF_TIMECONST_S = 0.005` cu comentariul care spune că e parametru provizoriu de test, nu valoare de hardware
Pas de calcul de 1 ms, eșantionare la 20 ms, gravitații 9,80665 / 1,62 / 3,72076 m/s²; toleranțe: derivă de energie ≤1% relativ, pătrundere în sol ≤0,03 m, încălcare de limită articulară ≤0,03 radrunner.py:26-30 (gravitații), 59-70 (toleranțe), 79-82 (pas, durată, înălțime de cădere, interval de eșantionare)
Toate cele 15 acțiuni din registru sunt marcate cinematice, zero validate, cu motivul scris în comentariul registruluiactions.ts:23-31 (comentariul de proveniență), 32-48 (registrul)
Analizor MJCF propriu, care lasă intenționat afară geometriile de coliziune; 14 teste trecute pe partea de vizualizare; modele cu 29 și 12 grade de libertaterobots.ts:mjcfLoader.ts:101 (`if (cls === "collision") return;`); robots.ts (29 și 12 grade de libertate); `npx vitest run` → „Test Files 5 passed / Tests 14 passed”
Valorile afișate sunt cele comandate, nu măsurate: fără zgomot de encoder, stare măsurată, cuplu, viteză sau temperaturăjointBus.ts:8:publicare într-o singură direcție către interfață
Prototip propriu de vedere: detector mic din familia YOLO, urmăritor multi-obiect, prag de încredere 0,5, rulare forțată pe procesor; estimare de postură în cinci stări; control de cameră prin protocolul standardoffice-tracker:src/tracker.py:98-107 (model, urmăritor, prag, forțarea procesorului cu motivul scris); src/pose.py:20-26 (cele cinci stări); src/ptz_control.py:1-4, 16 (control de cameră); requirements.txt:4-12
Stadiul prototipului de vedere: un singur comit și director de teste goloffice-tracker:git log --oneline | wc -l → 1; ls tests/ | wc -l → 0
Nicio cameră de adâncime, nicio calibrare de cameră, nicio odometrie vizuală, niciun motor de inferență accelerat în cod propriumacbook_nou (căutare):căutări după pyrealsense2, DepthAI/OAK-D, TensorRT, CoreML Vision, ONNX Runtime, GroundingDINO → apar exclusiv într-un depozit clonat de la un autor extern, cu zero comituri ale noastre
Audio pentru roboți: zero cod propriu de cuvânt de activare, detector de voce local, formare de fascicul, estimare de direcție sau anulare de ecoumacbook_nou (căutare):întreruperea vorbitorului în platforma noastră de voce e delegată detectorului din serviciul furnizorului sau se face prin tastă în meniul telefonic; anularea ecoului vine din constrângerile browserului sau dintr-o stivă terță de telefonie vendorizată; o singură referință la un detector de voce local există într-un fișier de configurare fără nicio implementare în cod
Singura lucrare acustică proprie: semnal baleiat de 12 ms de la 2 la 8 kHz, corelație încrucișată, fereastră de gardă de 1,5 ms pentru sosirea directă, fereastră de ecou până la 60 ms, viteza sunetului corectată cu temperatura; concluzia negativă e scrisă în produsAcousticProbeService.swift:303-312 (generarea semnalului), 315-372 (analiza ecoului, praguri, raza monostatică echivalentă), 251 (viteza sunetului corectată cu temperatura), 628-631 (textul din interfață despre ce poate și ce nu poate măsura); 798 de linii în total
ROS: nimic instalat, nimic scris. Singurul pachet cu sistem de construcție specific ROS de pe disc e descrierea publică a unui robot industrial, folosită ca fișier de modelpackage.xml:22 (`<build_type>ament_cmake</build_type>`); scripts/fetch-robot-reference.py:15 (descărcarea fișierelor de limite și geometrie)
`vision.megapromoting.com` nu e un sistem de vederehttps://vision.megapromoting.com · 2026-09-06

Citările interne arată numele fișierului și linia. Calea completă rămâne în depozitul nostru; o putem parcurge împreună, la cerere.

Cum lucrăm Toate serviciile

Ce ai vrea să funcționeze mai bine?

Povestește-ne despre procesul tău. Împreună stabilim ce merită construit, ce putem conecta și cum verificăm rezultatul.

Hai să discutăm