Перейти до основного вмісту
megapromotingПоговорімо

Експертиза · Системи для роботів

Програмне забезпечення для роботів: шар, що вирішує рух, модуль зору і модуль слуху. Сьогодні у нас є офлайн-перевірка і симуляція — нічого, що керує реальним мотором, немає.

Ми пишемо кінематику, перевірку траєкторії та відтворювану фізичну симуляцію, із шлюзами, що блокують, коли доказу бракує. Для зору маємо прототип на фіксованій камері, не на роботі. Для аудіо на роботі в нас немає нічого побудованого, і сторінка говорить це замість того, щоб позичати докази з телефонії. Ми не працюємо з ROS.

Пропозиція, з умовамиAm 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.

Програмне забезпечення робота має три шари, які ламаються по-різному: що бачить і чує, що вирішує, і що відправляє до моторів. На перших двох у нас є власні роботи з тестами, які виконуються. На третьому — місток до hardware — у нас нічого немає, і це межа послуги, а не деталь реалізації. Два наші коди говорять це у власному заголовку, англійською, саме так, щоб їх не можна було прочитати неправильно: модуль кінематики не має транспорту до hardware і не може керувати реальним роботом.

Те, що існує на частині руху, — це перевірка перед рухом. Власний модуль обчислює пряму кінематику, якобіан і обернену кінематику для руки з шістьма осями, із закладеним запасом щодо меж кожної осі, і був використаний, щоб перевірити цілу траєкторію: 8.400 запитаних точок, 8.400 розв’язаних, із максимальною швидкістю по осі, що залишилася нижче 8% від каталожної межі. Окремо валідатор фізики працює на MuJoCo 3.10.0 на процесорі, з кроком обчислення в одну мілісекунду, у шести сценаріях, кожен по двічі, з однаковим зерном — і дві прогонки дають ідентичні відбитки. Детермінізм — це не твердження, а порівняння контрольних сум.

Тут, на стороні зору, менше, і чесно сказати, скільки саме. Власний прототип виконує детекцію та відстеження людей на потоках з IP-камер, із малим детектором із сімейства YOLO, багатoоб’єктним трекером, оцінкою пози для п’яти станів і керуванням поворотом-нахилом-зумом камери. Є лише один коміт і порожній каталог тестів. І різниця між цим і зором робота реальна, а не формальна: камера на роботі рухається разом із ним, сцена близька, експозиція змінюється на кожному кроці, а бюджет затримки інший, бо зображення має дійти до рішення про рух, а не до екрана. У нас немає камери глибини, немає калібрування камери, немає візуальної одометрії.

На стороні аудіо для роботів ми нічого не побудували, і не будемо позичати докази звідкись іще. У нас є реальні роботи з голосом для телефонії та для розмовних асистентів, але мікрофон на роботі має інші проблеми: власний шум машини, вентилятори й сервоприводи, що запускаються саме тоді, коли робот рухається, напрямок, звідки йде голос, луна в приміщенні та змінна відстань. Єдина власна акустична робота, яка в нас є, завершилася негативним результатом, записаним у заявці, і ми публікуємо її як є — бо виміряний негативний результат корисніший за обіцянку.

Що входить

Робота, за складовими

Перевіряємо кінематику перед тим, як щось рухати

Пряма кінематика, аналітичний Якобіан, побудований із векторних добутків, числова обернена кінематика з чотирма стартовими положеннями та резервом 10° від межі кожної осі, зі збіжністю до 0,05 мм за позицією. На її основі ми перевірили розміщення в 1.331 позиції сітки та повний маршрут з 8.400 точок, усі розв’язані. Результати: максимальна швидкість по осі на 7,86% від каталожної межі та мінімальний запас до меж 19,9°. Звіт сам називає свою природу: дискретний офлайн-скринінг без виходу до апаратури.

Розділяємо фізику та зображення, і робимо це відтворювано

Валідатор фізики — це окрема від візуальної частини програма на MuJoCo 3.10.0, на процесорі, з кроком у одну мілісекунду та вибіркою кожні 20 мілісекунд. Шість сценаріїв, кожен запущений двічі з тим самим зерном, з ідентичними відбитками між запусками. Допуски оголошені в коді, а не припускаються: дрейф енергії менше 1% відносно, проникнення в ґрунт менше 3 см, порушення межі суглоба менше 0,03 радіана. Те, що вимірюється у вільному падінні, — це прискорення центра мас, порівняне з налаштованою гравітацією — 9,80665, 1,62 і 3,72076 метра на секунду в квадраті.

Ставимо шлюз, який блокує, а не лише позначає

Журнал дій вимагає, щоб кожен рух заявляв про своє походження, і всі 15 записаних дій позначені як кінематичні, перевірено нуль — бо жоден із цих контролерів не керується симулятором твердих тіл з обмеженнями виконавчого механізму та перевіркою контакту. Понад ним шлюз випуску читає файл доказу й падає, якщо ключова константа не відкалібрована на апаратурі. Сьогодні він падає: одна єдина константа зупинки суглоба, 5 мілісекунд, у коді оголошена як тимчасовий параметр, а не виміряне значення — і цього достатньо, щоб повна перевірка завершилася помилкою. Це правило, написане нами проти нас самих.

Читаємо опис робота власним парсером і кажемо, що він лишає поза межами

Для відображення та інспекції моделей ми написали власний аналізатор формату MJCF: тіла, шарнірні, вільні, ковзні та сферичні суглоби, геометрії, матеріали та завантаження сіток, із кешем геометрії. Він навмисно залишає поза межами геометрії зіткнення, бо це візуальний аналізатор, а не контактний — написано в коді, а не виявлено пізніше. Використані моделі — офіційні, з 29 ступенями вільності для гуманоїда і 12 для чотириногого робота.

Не плутаємо задані значення з виміряними

Кути, що з’являються на екрані, — це задані контролером значення, опубліковані в одному напрямку до інтерфейсу. Вони не містять шуму енкодера, виміряного стану, моменту, швидкості чи температури — це прямо записано в технічному аудиті проєкту. Ця різниця здається малою, доки хтось не візьме гарний графік за телеметрію робота; тому ми пишемо про це в коді, в аудиті й тут.

Зір: детекція та відстеження людей на фіксованій камері

Власний прототип, який бере потоки з IP-камер, виявляє людей за допомогою малої моделі з сімейства YOLO, відстежує їх між кадрами за допомогою багатoоб’єктного трекера з порогом упевненості 0,5, оцінює позу у п’яти станах — невідомо, сидить, стоїть, іде, нахилився — і може обертати камеру через стандартний протокол керування. Працює примусово на процесорі через несумісність, позначену в коді. Його реальний стан: один коміт і порожній каталог тестів. Це прототип, а не виробничий модуль, і він ніколи не був на роботі.

Аудіо на роботі: кажемо, чого бракує, замість позичати з телефонії

У нас немає детектора слова активації, немає локально запущеного детектора голосу, немає формування променя, немає оцінки напряму і немає написаного нами коду придушення луни. Те, що маємо в зоні голосу, — для телефонних дзвінків і для розмовних асистентів: переривання мовця відбувається або через детектор у сервісі постачальника, або через натискання клавіші в телефонному меню, а придушення луни йде з бібліотек браузера або з третьої телефонної стеки. Це реальні речі, але вони розв’язують іншу проблему, ніж мікрофон, змонтований на машині, що рухається і сама створює шум.

ROS: у нас немає, і ми не вдаємо, що є

Не встановлено ні на одній нашій машині, і ми ніколи не писали ані вузол, ані файл запуску, ані власний пакет. Єдиний пакет зі специфічною для ROS системою збирання на диску — це публічний опис промислового робота, завантажений як файл моделі й використаний саме так, без компіляції. Якщо ваш проєкт виходить із того, що ROS 2 є даністю, це інформація, яку ви маєте знати до першої зустрічі, а не після.

Що ми б прийняли і чого ні

Ми б прийняли: перевірку кінематики та траєкторії перед закупівлею, симуляцію із заявленими допусками, модуль сприйняття, виміряний на ваших даних, і місток до апаратного забезпечення, зроблений разом з інтегратором, який відповідає за безпеку. Ми б не прийняли: писати самостійно шар, що зупиняє робота в разі аварії, обіцяти аудіомодуль на роботі без попереднього вимірювання власного шуму вашої машини, і казати, що наш досвід голосу телефоном покриває слух робота.

Як це виглядає

Шлях, крок за кроком.

01

Визначаємо завдання і фізичні межі, потім перевіряємо, чи вміщується

Що робот має досягати, в якому обсязі, з якою швидкістю і яке навантаження. Потім перевірка: покриття обсягу, запас відносно меж кожної осі, швидкість і прискорення на маршруті, зіткнення по реальній геометрії як скринінг. Ми передаємо звіт із записаними в ньому обмеженнями. Цей етап має добрий баланс між вартістю і уникненою шкодою, бо його роблять до закупівлі.

02

Симулюємо із заявленими допусками та перевіреною детермінованістю

Сценарії, фіксована зернина, повторні запуски, порівняння відбитків, допуски, записані в коді. Ми також передаємо список того, чого симуляція НЕ доводить — у нас, наприклад, валідатор, який підтверджує вільне падіння і утримання позиції на тестовій площині, не підтверджує ходьбу, складний контакт або динаміку актуатора, і це він пише сам.

03

Будуємо сприйняття на ваших даних, а не на публічному наборі

Детектор, який працює на зображеннях з інтернету, нічого не каже про ваш цех. Етап означає збирання в реальному середовищі, власний набір для оцінювання, еталонне вимірювання і лише потім вибір моделі та місця, де вона працює. Ми передаємо еталонні цифри і метод, за яким ви можете їх відтворити, зокрема тоді, коли вони слабкі.

04

Місток до апаратного забезпечення — етап, який ми ніколи не робили

Ми пишемо його останнім і пишемо з умовами, бо це єдиний пункт у списку, де у нас немає власного досвіду. Це робиться разом з інтегратором або виробником робота, а функції аварійної зупинки, обмеження та безпеки залишаються у відповідальності того, хто відповідає за машину. Те, що ми можемо довести до цього етапу, — це шар ухвалення рішень, перевірений, з документованим інтерфейсом.

IntrareVerificareDeciziePublicareNimic nu trece mai departe neverificat.ORDINEA E ARGUMENTUL
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.

Дані

Чого торкаємося, де воно лежить і скільки лишається

Запитання, які ставить кожен, у кого є відповідальний за захист даних, — поставлені тут раніше, ніж їх поставить він.

Камера робота знімає людей, і це все змінює
Модуль зору, який виявляє і відстежує людей, створює персональні дані в прямому значенні слова, навіть якщо нікого не ідентифіковано на ім’я. Питання ставляться до першого рядка коду: чи зберігається зображення, чи лише результат, де обробляється, хто має доступ до записів, як довго вони зберігаються, що показується тим, кого знімають. Наш прототип був побудований як технічний експеримент, а не як введена в експлуатацію система, і ми не пропонуємо його як такий.
На пристрої чи на сервері — рішення про затримку, а не про перевагу
Якщо зображення має дійти до рішення про рух, шлях до сервера і назад прямо входить у бюджет реакції. Якщо результат лише показується або записується, сервер прийнятний. Рішення ухвалюють на основі виміряного для вашого випадку бюджету затримки і записують його. Наш прототип примусово працює на процесорі, що є реальною швидкісною обмеженістю, зазначеною в коді.
Симуляції зберігаються із зерниною та відбитком
Результат симуляції без seed генератора та без контрольної суми вхідних даних — це не доказ, а оповідь. Наші звіти з фізики містять seed, кількість прогонів на сценарій, версію двигуна і стан детермінізму; звіти з кінематики містять відбиток вхідних файлів. Так можна перевірити через місяці, чи цитована цифра ще чинна.
Аудіо означає записувати кімнату
Мікрофон на роботі чує все, що відбувається навколо, а не лише команду, яку йому дають. Правило, яке ми б застосували, таке: безперервний запис не має існувати за замовчуванням, а лише вікно, потрібне для рішення, а те, що зберігається для покращення, має бути явним вибором із терміном. У нас ще немає побудованої такої системи, тож це заявлена позиція, а не доведена практика.
Моделі та описи роботів мають свої ліцензії
Моделі роботів, які ми використовуємо в симуляції, походять із публічних колекцій, під дозвільними ліцензіями, а описи промислових роботів — це публічні файли виробників. Вони не наші, і ми на них не претендуємо; у вашому проєкті ліцензію кожного зовнішнього джерела перевіряють до того, як воно потрапить у результат.

Випадок

Власне акустичне вимірювання, яке завершилося «ні», і чому ми його публікуємо

Ситуація

У власному застосунку для macOS ми хотіли з’ясувати, чи можна використовувати динамік і мікрофон побутового пристрою як простий сонар — випромінений сигнал, виміряний його ехо, виведена відстань. Питання саме таке, яке виникає і в робота: скільки можна дізнатися про простір навколо, використовуючи аудіообладнання, яке вже є, без додаткових сенсорів.

Що ми збудували

Ми побудували весь ланцюг, а не ескіз: сигнaл зі свіпом 12 мілісекунд, що піднімається від 2 до 8 кілогерц, з віконуванням, випромінений на малій амплітуді; перехресна кореляція між випроміненим і записаним сигналом; виявлення прямого приходу з захисним вікном 1,5 мілісекунди, щоб бічні пелюстки автокореляції не були сплутані з ехо; пошук ехо у вікні до 60 мілісекунд із окремими порогами кореляції та відносного підсилення; швидкість звуку, скоригована за температурою повітря. Майже 800 рядків Swift, із виявленням аудіотраси — якщо передавач і приймач на різних пристроях, геометрія бістатична, і один час затримки визначає еліпс, а не точку.

Що вийшло

Висновок написано в застосунку, на екрані, який каже, що він може і що не може вимірювати: на динаміку й мікрофоні того самого комп’ютера після калібрування можна виявляти грубі зміни відбиттів, бо затримка відносно стабільна. А от через бездротові навушники активне шумозаглушення, формування променя, кодек і змінна затримка руйнують точне метричне вимірювання — отже, їх можна використовувати для орієнтації голови, але не як точний сонар. Ми написали це в продукті, а не у внутрішній нотатці.

Чого цей випадок не каже

Результат стосується побутового обладнання через бездротове з’єднання, а не робота з установленими й підключеними мікрофонами. Переноситься не висновок, а метод: вимірюють канал перед тим, як обіцяти функцію. Для робота таке саме дослідження почалося б із власного шуму машини під час руху — і лише результат цього вимірювання сказав би, що можливо.

Питання

Про що нас питають, перш ніж зателефонувати

Ви ставили ваше програмне забезпечення на фізичного робота?

Ні. Жоден наш код ніколи не керував реальним мотором, і дві наші codebase прямо вказують це в заголовку файлу, щоб їх не можна було прочитати неправильно. Ми запускали симуляцію та офлайн-перевірку. Якщо це проблема для вашого проєкту, краще дізнатися це з першого речення, ніж виявити на третьому засіданні.

Тоді що саме у вас є, конкретно?

Три речі, усі придатні до запуску перед вами. Модуль кінематики для шестикоординатної руки, який перевірив маршрут із 8.400 точок без жодного збою, з мінімальним запасом 19,9° до меж осей. Валідатор фізики на MuJoCo 3.10.0, з 34 тестами, що проходять, і з детермінізмом, доведеним ідентичними відбитками на повторних прогонах. І демо у браузері з 14 тестами, чия кваліфікаційна межа сьогодні навмисно падає. Плюс прототип зору, про який ми відкрито кажемо, що він має один commit і жодного тесту.

Ви працюєте з ROS?

Ні. У нас його не встановлено, ми не написали жодного вузла, жодного launch-файлу й жодного пакета. Єдиний ROS-тип пакета на наших дисках — це публічний опис промислового робота, завантажений як файл моделі для кінематичних розрахунків — використаний як дані, а не зібраний. Якщо ваша команда вже працює в ROS 2 і це вимога, ми починаємо там з нуля, і це треба врахувати.

Ви можете зробити модуль зору для нашого робота?

З етапом вимірювання перед цим, не на основі того прототипу, який у нас є. З нього переноситься спосіб роботи — детектор, трекер між кадрами, поріг упевненості, де виконується обчислення. Не переноситься ситуація: камера на роботі рухається, об’єкт близько, освітлення змінюється на кожному кроці, а результат має дійти до рішення про рух, а не до екрана. Крім того, у жодному нашому власному проєкті немає камери глибини, калібрування камери чи візуальної одометрії. Першим етапом буде захоплення з вашого середовища та еталонне вимірювання.

У вас є голосові агенти. Хіба це не те саме, що слухати робота?

Ні, і ми не хочемо, щоб це так виглядало. По телефону канал відомий і вузький, той, хто говорить, притиснутий до мікрофона, а переривання мовця вирішує або сервіс постачальника, або натиснута клавіша. На роботі мікрофон стоїть на машині, яка сама створює шум саме тоді, коли рухається, голос надходить із напряму, що змінюється, приміщення дає луну, а відстань варіюється. Це проблеми акустики, а не розмови. Ми могли б почати з вимірювання власного шуму вашого робота — але це була б нова робота, а не розширення телефонної.

Навіщо ви публікуєте шлюз кваліфікації, який падає?

Тому що альтернативою є те, що він пройде, нічого не означаючи. Наш шлюз читає файл доказу й перевіряє, чи була критична константа — час зупинки в кінцевому положенні суглоба — відкалібрована на обладнанні. Не була: це проміжне значення 5 мілісекунд, поставлене для того, щоб симуляція була стабільною. Поки воно проміжне, повна перевірка завершується з помилкою, а всі дії залишаються позначеними як кінематичні. День, коли він пройде, означатиме щось саме тому, що сьогодні він не проходить.

Чого не доводять ваші симуляції?

Більше, ніж доводять, і це написано в звітах. Валідація фізики підтверджує вільне падіння та утримання позиції на тестовій площині — не ходу, не складний контакт, не динаміку актуатора, не синтетичні сенсори. Скринінг траєкторії підтверджує кінематику та геометрію — не матеріал, не гнучкі шланги, не затримки процесу, не рампи запуску-зупинки контролера. А рух у браузері — це попередній перегляд, а не результат симуляції.

Нам потрібна сертифікація безпеки. Ви її робите?

Ні. Архітектуру безпеки ми можемо спроєктувати — окремий контур від керування рухом, незалежний контролер безпеки, безпечне вимкнення моменту, гальма з feedback, стани несправності, що переходять у безпечний режим; це ми й зробили в окремому проєкті машини. Але оцінка відповідності та відповідальність за машину, випущену на ринок, залишаються за виробником або інтегратором. Ми не беремо на себе цю роль і не підписуємо замість нікого.

Чому на цій сторінці написано «пропозиція»?

Тому що сервіс має три шари, і жоден із них повністю не проходить поріг, який ми для себе поставили. У керуванні маємо дві власні роботи з тестами, що проходять, але жодна не досягає hardware. У візії маємо прототип із комітом і без тестів. В аудіо для роботів — нуль. Ми могли б написати сторінку, що звучить як досвід, використовуючи слова на кшталт «сприйняття» і «керування» без цифр. Вона б витримала до першого запитання інженера.

На чому ґрунтуються твердження вище (17 джерел)
  1. `vision.megapromoting.com` nu e un sistem de vederehttps://vision.megapromoting.com · 2026-09-06

16 з них — це код і файли з наших репозиторіїв. Ми не публікуємо їхні назви чи номери рядків: разом, на одній сторінці, це надто точно описало б, як побудовані системи, які належать не лише нам. Ми проходимо їх разом із вами, у репозиторії, за запитом — перевірка залишається можливою, просто вона відбувається в розмові.

Що вам хотілося б налагодити?

Розкажіть про свій процес. Разом визначимо, що варто збудувати, що можна підключити і як перевіримо результат.

Поговорімо