Привет, Хабр! Меня зовут Лёша Лещанкин, я руковожу проектом Humanoids в Яндексе. В начале 2025 года мы запустили это направление при поддержке фонда технологических инициатив компании — Yet Another Tech Fund, созданного специально для реализации новаторских идей сотрудников. Наша цель — создать гуманоидных роботов, которые смогут уверенно и безопасно работать рядом с людьми в самых разных условиях: от логистики и промышленности до сферы обслуживания.
В рамках нашего проекта мы тестируем разные RL‑модели. И сегодня расскажу об одном из методов, который позволил нам перейти от «робот дёргается и падает» к «робот ходит плавно 500 шагов подряд» — Lipschitz‑Constrained reinforcement learning.
Зачем вообще RL в управлении гуманоидом
Классические подходы к управлению двуногими роботами требуют ручной настройки сотен параметров. Мы учим робота методом проб и ошибок в симуляции, но с важным отличием — используем математические ограничения для безопасности.
В итоге RL даёт адаптивность, а значит, быстрее выводит фичи (доставка, сопровождение, инспекция) в прод.
В чём состоят ключевые преимущества RL‑подхода:
робот сам находит оптимальную походку под свою механику;
он адаптируется к разным поверхностям без перепрограммирования;
обеспечивается устойчивость к возмущениям и непредвиденным ситуациям;
есть возможность переноса навыков между разными моделями роботов.
Однако когда ты запускаешь симулированную RL‑политику на настоящем гуманоиде — ты почти всегда видишь это: робот начинает «дёргаться», рывками размахивает ногами и в лучшем случае просто падает. Всё было идеально в симуляции, но моторы не выдержали реальности.
Это классическая проблема «симуляция → реальный мир». Несмотря на обширную доменную рандомизацию (вариации масс, трения, задержек и добавление сенсорного шума), оптимизатор всё равно вырабатывает «жёсткую» bang‑bang‑политику: она трактует даже крошечный сенсорный шум как принципиально новое состояние и тут же перестраивает цикл шага. На реальном роботе это приводит к резким, нестабильным переходам, а пиковые моменты, которые казались оптимальными в симуляции, упираются в реальные ограничения приводов. Главное узкое место переноса sim → real не в самом шуме, а в чрезмерной чувствительности политики к нему и в игнорировании аппаратных лимитов. Результат — непереносимость, нестабильность и физическая невозможность выполнения движений.
В недавней статье Learning Smooth Humanoid Locomotion through Lipschitz‑Constrained Policies (ICRA 2025) авторы предложили элегантное решение: наказывать нейросеть за «резкие» действия, измеряя, насколько она чувствительна к входу. Метод прост, дифференцируем и прекрасно переносится на реальных роботов.
От симуляции к железу
Представьте: вы обучили идеальную политику управления роботом в симуляторе. В Isaac Sim ваш гуманоид грациозно ходит, бегает, даже танцует. Переносите на реальное железо и... робот дёргается и падает через 10 секунд.
Почему так происходит?
В реальности сенсоры шумят. IMU дребезжит на ±2%, энкодеры дают погрешность, Wi‑Fi вносит задержки. И вот маленький шум в 0,1° наклона превращается в команду мотору «ДЁРНИ НА 50 Нм!» — и робот падает.
Решение: учим нейросеть быть нечувствительной к шуму. Классический подход — применить фильтры Калмана и сглаживание. Работает, но требует много параметров и настройки под каждого робота. Мы же пошли другим путём: учим нейросеть с самого начала плавно реагировать на входы.
Условие Липшица для политики робота:
Простыми словами, если состояние робота изменилось чуть‑чуть, то и действия должны измениться чуть‑чуть. Никаких резких скачков! То есть если шум IMU — 2°, то изменение команды мотору составит максимум 1° (а не 50°!), что даст в результате плавные, предсказуемые движения.
Для простоты понимания представьте два сценария:
Без ограничения (обычная нейросеть): Шум сенсора 1% → Команда мотору меняется на 50% → Робот дёргается
С Lipschitz constraint: Шум сенсора 1% → Команда мотору меняется максимум на 0,5% → Плавное движение
Это гарантирует, что малые изменения в сенсорах приводят к малым изменениям в командах моторам — критично для переноса на реальное железо.
Как это работает: градиент от градиента
Ключевая идея — добавить к обычной функции потерь RL специальный штраф за «резкость» политики:
# Псевдокод: основная логика метода
def lipschitz_constraint(policy, states, actions, lambda_gp):
# Включаем отслеживание градиентов для входов
states = states.requires_grad_(True)
# Прогоняем через политику
log_probs = policy.log_prob(actions, states)
# Ключевой момент: считаем градиент выхода по входу
input_gradients = compute_gradient(log_probs, states, keep_graph=True)
# Штраф = насколько резко меняется выход
penalty = lambda_gp * norm(input_gradients)
return penalty
# В training loop
rl_loss = compute_ppo_loss(...) # или любой другой RL-алгоритм
smooth_penalty = lipschitz_constraint(...)
total_loss = rl_loss + smooth_penaltyПочему это градиент от градиента? Ответ прост:
Первый градиент:
— насколько действия чувствительны к входам.Второй градиент: при backprop мы считаем, как изменить веса сети, чтобы эта чувствительность уменьшилась.
Сначала мы считаем 
, а потом его градиент по всем весам сети, чтобы уменьшить чувствительность политики.
Мы буквально учим сеть быть менее «дёрганой». Условно, ты говоришь нейросети: «Я накажу тебя, если ты ведёшь себя слишком чувствительно к входам. Что нужно изменить в твоих весах, чтобы ты стала менее чувствительной?».
Что «под капотом»: классическая модель обучения с подкреплением
Мы используем базовый RL‑алгоритм — Proximal Policy Optimization (PPO). Это один из самых популярных алгоритмов RL благодаря его стабильности и хорошему балансу между исследованием и эксплуатацией.
Политика
Представлена нейросетью, параметризованной с помощью MLP (multilayer perceptron).
-
Вход: вектор наблюдений
, который включает:фазу походки (синус и косинус);
команду на скорость
;состояния робота
(позы, скорости суставов);предыдущие действия
;привилегированную информацию (масса, центр масс и т. д. — используется только на этапе тренировки).
Это позволяет обучать политику в симуляции с полным знанием динамики, а затем использовать её без дообучения на железе.
Выход политики
Предсказывает таргетные значения суставных углов (target joint positions).
Эти углы конвертируются в торки через стандартный PD‑контроллер (с фиксированными коэффициентами).
PPO-обучение
Оптимизация идёт по стандартной PPO‑цели:
К ней добавляют Lipschitz gradient penalty:
![Ltotal = LPPO + λgp⋅E[∥∇slogπ(a∣s)∥2]](https://habrastorage.org/getpro/habr/upload_files/3d4/557/5e9/3d45575e98ed9a2ff956771f9687d72f.svg)
Обучение
В симуляции Isaac Gym, massive‑parallel, на тысячах копий среды (в нашем случае num_envs= 4096).
Sim2Real без fine‑tuning: политика одна и та же — сразу на железо.
Sim2Real Transfer
Используется ROA (Regularized Online Adaptation) — это дополнительная техника, основанная на teacher‑student и latent embedding. Но она не требуется для самого метода Lipschitz penalty, а, скорее, поддерживает robustness.
Практическая польза
Использование PPO даёт нам много преимуществ. Что касается робота, то он получает:
Устойчивость к шуму (Robustness ≈ Stability). Мелкие помехи в сенсорах не вызывают резких движений.
Безопасность. Нет внезапных рывков, которые могут сломать механику.
Энергоэффективность. Плавные движения потребляют меньше энергии.
Sim2Real Transfer. Поведение в симуляции близко к реальности. Липшиц‑штраф (grad penalty) сглаживает политику; в реальном мире она не завалит моторы пиками тока.
А относительно всего проекта — такие плюсы:
Платформа ходьбы стабильна. Можно подключать высший уровень задач ‑ перенос груза, лестницы, протягивание руки.
Перенос на железо. Первые стенд‑тесты показывают, что падений нет.
Экономия на тюнинге. Вместо недель ручных коэффициентов мы меняем одну строку с λ и перезапускаем ран.
Наши результаты
После 18 часов обучения на кластере мы получили такие результаты по ключевым метрикам:
Episode length выросла с 10 до 499 шагов — робот не падает почти 50 секунд!
Grad penalty loss: 11,83 — агрессивная регуляризация для safety.
Mean reward: 42,54 — нашли баланс между всеми целями.
Также в процессе обучения мы отслеживаем две ключевые метрики адаптации:
Adaptation/priv_reg_loss — показывает, насколько политика робота зависит от «привилегированной информации» (точные параметры симуляции, которые недоступны на реальном железе). Резкое падение на 2–4k шагах означает, что модель научилась полагаться только на реальные сенсоры.
Adaptation/hist_latent_loss — отражает качество предсказания скрытых состояний робота (скорости, ускорения) из истории наблюдений. Когда эта метрика падает, робот начинает точно оценивать свою динамику без прямых измерений.
Оба графика показывают классический паттерн: хаотичное начало → резкий прорыв → стабилизация. Это момент, когда нейросеть «понимает» задачу и переходит от случайных движений к осмысленной походке.
Видите резкое падение всех функций потерь? Это момент, когда робот научился ходить. А Lipschitz constraint обеспечил, чтобы походка сразу стала плавной.
Почему это работает zero-shot?
В отличие от политик, которые переобучаются под шумную симуляцию, LCP обучается быть устойчивой к флуктуациям входа с самого начала. Это означает, что нейросеть не «подстраивается» под точные значения наблюдений, а учится реагировать на диапазон состояний одинаково плавно. Это и делает возможным перенос на новое железо без fine‑tuning.
А что в итоге?
Мы проверили метод на двух реальных роботах: Fourier GR1 и Unitree H1. Сравнение с классическими методами (награды за плавность, low‑pass фильтры) показало, что LCP:
работает сразу на железе, без fine‑tuning;
даёт сопоставимую плавность движений;
избавляет от ручной настройки весов штрафов;
прост в реализации и добавляется в любую RL‑схему.
Заключение
Знаете, что самое крутое в работе с гуманоидами? Каждый день — это микс из математики, инженерии и чистой магии. Утром ты доказываешь «сходимость алгоритма», днём калибруешь сенсоры, а вечером смотришь, как железяка весом 50 кг делает первые шаги — и это твой код заставляет её двигаться.
Lipschitz‑Constrained Policies — это способ учить нейросети быть устойчивыми к реальному миру на уровне функции потерь, а не костылями после обучения. К слову, если вы работаете с роботами или любым Sim2Real Transfer, — попробуйте добавить этот constraint. Overhead небольшой, а выигрыш в стабильности огромный.
Мы сейчас на пороге запуска field tests на реальном железе. Страшно? Безумно. Но когда видишь, как робот, обученный в симуляции, делает первый шаг в реальном мире и не падает — это стоит всех ночей дебага.
Полезные ссылки
Комментарии (26)
johnfound
25.06.2025 10:15Так и не понял что за RL? Learning, ясен пень, но какой?
Indemsys
25.06.2025 10:15Представлена нейросетью, параметризованной с помощью MLP (multilayer perceptron).
Это самая простая из сетей, которую тут можно было применить.
Но не позволяет подключать камеры и не помнит предыдущую историю прохождения , не учитывает задержки сенсоров.
Т.е. скорее всего расчет на слабые микроконтроллеры или процессоры.
Словом, зря они от Калмана отказались.
Alozarian Автор
25.06.2025 10:15Согласен, «голый» MLP не помнит историю и не знает о задержках. Но у нас он используется строго как policy на коротком горизонте (20–30 мс), и работает в 400 Гц. Все задержки и шумы сенсоров будут обрабатываться upstream — через EKF по IMU и визуальной одометрии. Policy получает уже фильтрованное состояние.
Почему не рекуррентная сетка? Пока не внедряли — в текущих задачах хватает нормализованного вектора с history stacking (N последних шагов в obs). Это проще, легче дебажить и быстрее адаптировать под real-time constraints.
Калман в строю — просто живёт выше по стеку: в perception и state estimation. А policy пусть будет простой, но быстрой и безопасной.
Filex
25.06.2025 10:15А для чего нужны гуманоидные роботы похожие на человека?
Alozarian Автор
25.06.2025 10:15Колёсные тележки и «манипуляторы на стойке» отлично справляются с задачами в структурированном пространстве — именно поэтому на заводах стоят конвейеры, а в складских зонах курсируют AGV. Но как только мы выходим в «человеческую» инфраструктуру (лестницы, узкие дверные проёмы, ручки, выключатели, бытовые инструменты), окупается биоморфная кинематика: существующие помещения, средства труда и процессы не нужно перестраивать под робота, — достаточно обучить робота работать так же, как человек. На практике это уже решает прикладные задачи: Digit раскладывает коробки у Amazon, Optimus сортирует детали на Gigafactory, а гуманоиды Sanctuary AI закрывают «unfilled shifts» на складах. То есть ценность формы — в минимизации CAPEX на переделку инфраструктуры и в возможности массового тиражирования решения там, где ручной труд до сих пор не автоматизирован.
Вторая причина — многоцелевое переобучение. Робот, который уже умеет ходить, держать равновесие и манипулировать бытовыми предметами, меняет «прошивку» — и из курьера превращается в охранника, промоутера или техника‑наладчика. Это не «игрушка для публики», а платформа, способная закрывать дефицит рабочей силы и давать предсказуемый ROI: одна и та же железная база, обновляемая как софт. В конечном счёте именно универсальность и совместимость с человеческой средой делает гуманоиды стратегически более выгодными, чем парк узкоспециализированных, но взаимно несовместимых роботов на колёсах.
santjagocorkez
25.06.2025 10:15лестницы
Сколько стоит пандус-накладка на лестницу с откидным шарниром? А R&D “типа человек”? Вот то-то же. Тем более, молодой маме в подъезде уродливой накладки для спуска и подъема коляски с младенцем достаточно, а капризной железке, видите ли, нет.
узкие дверные проёмы
Платформа не обязана быть широкой, в основание можно встроить маховик для защиты от опрокидывания
ручки
Образец, с которого копируется форма, способен оперировать ими даже при ампутации обеих ног
выключатели
Аналогично
бытовые инструменты
Аналогично
Эрго: трудности с иллюстрацией на примерах довольно просто вскрывают и задачу, которая решается: троллейбус из буханки хлеба.
johnfound
25.06.2025 10:15Это не только лестницы. А поребрики, а камни в парке, а дыры в асфальте и в тротуарах. Ваш пандус накладку кто будет спускать-поднимать? Робот? Вместо того, чтобы дело делать? Антропоморфность это и руки, не только ноги и не только хождение. А управление рук и ног имеет разные цели, но алгоритмы по сути одинаковые. Вот возьмите моноколесо или гироскутер и попробуйте весь день только на нем ездить, вместо того, чтобы ходить. Если выживете – напишите статью на хабр.
santjagocorkez
25.06.2025 10:15поребрики, а камни в парке, а дыры в асфальте и в тротуарах
Со всем этим у гусеничной платформы проблем никаких.
Ваш пандус накладку кто будет спускать-поднимать? Робот? Вместо того, чтобы дело делать?
Да вообще не вопрос. Минус шарнир, так ещё дешевле. Особенно, если плевать на то, как там будут кожаные ходить. Пусть дело делает.
это и руки
К манипуляторам вообще никаких вопросов. Тем более, они могут быть сменными и разными, заточенными под задачу.
алгоритмы по сути одинаковые
Да вот уж нет. Манипулятор может немного ошибиться, и скорректировать его положение можно с небольшим опозданием, а корректировать усилия на опорно-двигательных тентаклях нужно всегда и даже с упреждением, иначе вся пепяка завалится.
Встань прямо, прислушайся к ощущениям. Ты почувствуешь, как мышцы икр и голеностопа (и в меньшей степени бёдер) постоянно, ежесекундно корректируют положение тела, чтобы вся эта плохо пригодная к вертикальному положению конструкция, которую ты безумно любишь, не свалилась. Теперь прислушайся к рукам. Вообще ноль, висят и висят, усилие нужно только тогда, когда хочешь ими подвигать.
Так вот гироскопом очень много проблем заваливания решается: это и уменьшение высоты центра масс, и собственно эффект маховика. Но в тентакли его не встроишь, а в платформу — запросто.
gres_84
25.06.2025 10:15А где именно вы собираетесь выходить в «человеческую» инфраструктуру? Есть запрос от рынка? Не разовые модели поиграться, а десятки и сотни роботов.
Вы перечисляете текущее применение, но это все склады. Зачем там именно гуманоидная архитектура (ноги прежде всего), непонятно, ведь инфраструктуру в абсолютном большинстве случаев поменять дешевле, чем стоимость одного робота. Текущее применение больше походит на рекламный трюк - смотрите, насколько мы технологичны.
Я понимаю, что разработчикам это нравится, задача же очень интересная. Но не могу придумать, где такое решение могло бы заменить кожаных мешков, и ему обязательно были нужны ноги.
Hayoca
25.06.2025 10:15Яшные робототехники открыли для себя вторую производную и решили ознаменовать это потрясающее открытие искрометной статьёй с ошеломительной историей успешного успеха.
Высшую математику робототехникам на курсах молниеносного онбординга и личностного роста не преподавали, поэтому робототехники назвали производную градиентом, а вторую производную — градиентом градиента.
Ну а что, если есть пра-прабабушка, логически рассудили они, то почему бы не быть градентному градиенту?
Так и написали. И получилось у них все очень-очень хорошо. И всем очень-очень понравилось.
ChePeter
25.06.2025 10:15если у них все на шарнирах, то наверное все эти траектории это квадратные уравнения.
там достаточно ограничивать силу и вторая производная будет как нужно ограничена. Т.е. задача решается и без знания второй производной. Школьной физикой
Но замечание - зачёт !
Alozarian Автор
25.06.2025 10:15Спасибо за комментарий.
Да, при планировании траекторий сила действительно может быть ограничена напрямую — и это рабочий подход в системах с аналитическим контролем.
Но здесь другая архитектура: робот управляется обученной политикой, которая не рассчитывает траекторию, а сразу выдаёт управляющее воздействие по текущему состоянию. В такой схеме полезно контролировать не только само значение управления, но и насколько резко оно может меняться при малом изменении входа.
Этот механизм помогает сделать поведение стабильным при сенсорном шуме, особенно при переносе с симуляции на реальную механику, где идеализированные предпосылки не выполняются.
Так что да, физика остаётся — но в data-driven контуре её приходится усиливать регуляризаторами.
Alozarian Автор
25.06.2025 10:15Спасибо за комментарий.
Формулировка про «градиент градиента» в статье — это просто инженерная метафора, чтобы объяснить суть приёма на пальцах.Мы используем gradient penalty — довольно стандартный подход в ML, но применяем его в другом контексте. Штрафуем ∥∇sπ(a∣s)∥, чтобы политика не дёргалась от мелкого сенсорного шума. При backprop это автоматически даёт градиент по параметрам от градиента по входу — отсюда и родилось название.
Новизна не в математике (она действительно уровня бакалавриата), а в том, что в задаче sim2real-переноса для гуманоидов это даёт ощутимый прирост. Это важно при переносе с симуляции на железо, где шум, зазоры и задержки проявляются жёстко. Не откровение — но в нашем случае оказалось полезным.
lazil
25.06.2025 10:15Это называется "рывок" ("jerk").
И да, я тоже читал и не мог понять: почему для ограничения рывка нужны НС, RL и всё это. Карго-культ какой-то.
Дикари с ИИ в руках.Alozarian Автор
25.06.2025 10:15Вы правы — резкие скачки в управляющем воздействии называются «рывками» (jerk), и в классических контроллерах они ограничиваются через jerk-limited траектории, сглаживающие ускорения.
Но в нашем случае задача другая: мы не генерируем траектории, а учим policy напрямую маппить наблюдение → действие. При этом поведение среды сложно, контакты нелинейные, и робот действует в частично наблюдаемом пространстве. В таких условиях ограничить jerk аналитически — уже не так тривиально.
Именно поэтому вводим регуляризацию, чтобы обучаемая политика вела себя похоже на jerk-limited контроллер, но в end-to-end стиле. Это не замена классике, а адаптация знакомых принципов под data-driven стек. Работает — значит, используем. Карго тут нет.
mfclabber
25.06.2025 10:15Пытались валидировать политику RL с помощью Whole-Body Control?
Alozarian Автор
25.06.2025 10:15Пока — нет, напрямую с Whole-Body Control (WBC) не сравнивали.
Основной фокус был на обучении end-to-end policy, отдающей торки, с максимальным переносом из симуляции. Но идея использовать WBC как валидационную референс‑модель (или даже baseline для policy distillation) звучит разумно — особенно для оценки joint consistency, effort balance и при работе с контактами.
Если есть конкретные рекомендации по setup’у или библиотекам — буду рад взглянуть.
apcs660
25.06.2025 10:15напомнили - у меня на экзамене по математике был доп вопрос: "что вы можете сказать о функции по ее второй производной?". Уже плохо соображал и подвис и ответил перепутав имя преподавателя с отчеством, на что получил ответ:
"Если вам трудно запомнить как меня зовут, зовите меня просто Вовочка, я не обижусь".
Владимир Борисович, надеюсь жив и здоров еще.
Теорию управления подзабыл, но краем сознания вспоминаю что там гистерезис помогает много где в приводах, и на устойчивость надо посмотреть, не возникают ли автоколебания из за задержки обрабоки сигналов...
Alozarian Автор
25.06.2025 10:15Спасибо, отличный комментарий — и сильное воспоминание, надеемся, Владимир Борисович по-прежнему в строю!
Что касается сути: да, устойчивость системы при наличии задержек — критичный аспект, особенно в приводах с гистерезисом или при длительном pipeline обработки (в нашем случае — perception → LLM → HLC → action). Мы именно поэтому и используем RL-политику как быстрый стабилизирующий слой: она работает в высокочастотном цикле и помогает «поглощать» эффекты задержки и сенсорного шума.
Автоколебания — вполне реальный риск, особенно если в системе есть накопленный лаг + обратная связь. Мы дополнительно будем ограничивать скорость изменений действий, чтобы не было переусиления. И да — идея о гистерезисе как полезной нелинейности для стабилизации в приводах вполне применима. Благодарим за подсказку — в наших условиях точно стоит протестировать!
sned
25.06.2025 10:15Обилие сокращений и англозаменителей , например: (в нашем случае — perception → LLM → HLC → action)- это только мне непонятно о чём речь?)
Alozarian Автор
25.06.2025 10:15Хорошее замечание — действительно, в статье много сокращений и англоязычных терминов. Это, увы, побочный эффект среды: когда работаешь на стыке ML, робототехники и симуляции, стек технологий почти весь англоязычный, и многие термины просто не имеют хороших русских аналогов.
Тем не менее, Вы правы — нужно делать текст более доступным. В будущих материалах добавлю расшифровку ключевых сокращений (в духе: LLM — большая языковая модель, HLC — контроллер высокого уровня и т.д.), а возможно и глоссарий в конце.
Спасибо, что обратили внимание — это важно! Хорошего дня!
nektopme
25.06.2025 10:15Привет!
Вы достигли хорошего прогресса, но попали в ловушку "почти работает, осталось чуть-чуть".
Могу недорого продать направление, которое приведёт Вас к созданию не падающего робота.
Arastas
В теории адаптивного управления есть метод скоростного градиента - когда подстройка параметров/управления осуществляется не по градиенту целевого показателя, а по градиенту скорости его изменения. Вроде, есть что-то близкое?
Alozarian Автор
Станислав, отличное наблюдение! Не претендую на академическую точность, но кажется, что да, есть определенная концептуальная связь между методом скоростного градиента из адаптивного управления и нашим подходом с Lipschitz constraints.
В методе скоростного градиента мы минимизируем скорость изменения функции Ляпунова:
dV/dt = ∇V · ẋ, подстраивая параметры в направлении-∇_θ(dV/dt). То есть не просто стремимся уменьшить ошибку, а делаем это максимально плавно во времени.В нашем случае с Lipschitz penalty мы тоже работаем с "производной", но в другом смысле:
Мы штрафуем за большую норму градиента
∂π / ∂s— насколько резко политика меняется при изменении состояния (штрафуем за слишком резкую реакцию на входные возмущения.)При оптимизации считаем градиент этого градиента:
∇_θ||∂π/∂s||(на практике это не буквально градиент нормы якобиана, а регуляризация loss-функции с соответствующим penalty)Ключевое отличие:
Скоростной градиент: минимизируем скорость изменения во времени
Lipschitz: минимизируем чувствительность к входам
Но идея общая: мы не просто оптимизируем reward, а контролируем "поведение функции", делаем её более предсказуемой и устойчивой.
Интересно, что в робототехнике эти подходы могли бы дополнять друг друга: Lipschitz constraint для устойчивости к шуму сенсоров + СГ для плавной адаптации к изменяющимся условиям. Спасибо за параллель, есть о чем подумать для следующих экспериментов!
Arastas
Надеюсь, пригодится! :) Если дальше копать, то можно найти параллели с sensitivity shaping, который должен был бы применяться при построении традиционных регуляторов. То есть у вас нечто идейно схожее, но для model-free/data-driven управления.