1. Общая структура
Gazebo Sim состоит из двух основных процессов: серверного (backend) и клиентского (frontend), которые запускаются при старте симуляции. Сервер отвечает за физику, обработку команд и другие вычисления, а клиент за отображение и взаимодействие с пользователем через GUI.

2. Архитектура на основе плагинов
Вся функциональность симулятора реализована в виде плагинов, которые могут подключаться и отключаться во время выполнения. Есть плагины сервера (например, для физики или сенсоров), а есть плагины GUI (например, для визуализации и управления). Пользователь может добавлять, удалять или разрабатывать свои плагины.

3. Серверный процесс
На сервере используется архитектура entity-component-system (ECS), где entity - это любой объект сцены, а component - его характеристики (позиция, геометрия и т.д.). Серверные плагины взаимодействуют с этими сущностями: например, система физики реагирует на заданные силы. Работа построена вокруг основного симуляционного цикла с последовательными шагами обновления состояния объектов.

4. Клиентский процесс
Клиентская часть (GUI) также состоит из плагинов для отображения 3D-сцены, окон управления и других интерактивных элементов. Эти плагины получают сжатые данные о состоянии сцены от сервера и реагируют на них, не изменяя непосредственно состояние симуляции. Общение между плагинами GUI организовано через события (events).

5. Взаимодействие сервера и клиента
Клиент и сервер обмениваются информацией через систему сообщений Gazebo Transport и Messages. Сервер с помощью специального плагина Scene Broadcaster периодически отправляет клиенту сжатое состояние сцены, которое визуализируется, а клиент может посылать команды (например, на создание или удаление объектов) обратно через свой интерфейс.

6. Модульность
Все компоненты (базовые библиотеки, плагины, GUI) модульны и могут использоваться и обновляться независимо друг от друга. Это упрощает расширение и настройку симулятора под любые задачи — от интеграции новых физических движков до экспериментов с пользовательским интерфейсом.

7. Внешние процессы
Отдельные серверные и клиентские плагины способны взаимодействовать с внешними процессами — например, ROS (Robot Operating System) или другими сторонними сервисами и приложениями. Некоторые плагины (например, для сенсоров или управления движением) отправляют и получают сообщения не только между сервером и клиентом Gazebo, но и напрямую во внешние среды. Благодаря такой возможности, Gazebo интегрируется в распределённые системы управления, поддерживает обмен данными с ROS-узлами, а также расширяет сценарии взаимодействия за пределы собственной симуляционной среды.

В итоге, фреймворк позволяет описать множество сценариев симуляции: от настройки мира с произвольными моделями, сенсорами и физическими условиями до динамического подключения новых физических движков, визуализации, систем сбора данных и обмена сообщениями с внешними процессами, включая ROS. Все компоненты могут настраиваться и расширяться с помощью плагинов. Пользователь не ограничен некоей стандартной функциональностью, а может создавать свои уникальные сценарии, масштабируя и изменяя симуляцию под любые задачи.

#knowledge #gazebo #Robotics

🐌 Исследование по оценке влияния ИИ ассистентов на реальную производительность разработки кода

В новостной ленте наткнулся на исследование, в котором авторы попытались оценить как использование ИИ-ассистента влияет на производительность опытного разработчика.

Мотивировка очень правильная: "... Хотя бенчмарки доказали свою полезность для понимания возможностей ИИ, они, как правило, жертвуют реализмом ради масштаба и эффективности — задачи являются самостоятельными, не требуют предварительного контекста для понимания и используют алгоритмическую оценку, которая не охватывает многие важные аспекты (безопасность кода, например). Это может приводить к переоценке возможностей ИИ. С другой стороны, поскольку тесты проводятся без взаимодействия с человеком, модели могут не выполнить задачи, несмотря на существенный прогресс, из-за небольших узких мест, которые человек исправил бы в ходе реального использования. Это может привести к недооценке их возможностей модели. ..."

Поэтому, чтобы получить реалистичную оценку в "обычных" сценариях разработки, исследователи договорились с 16 опытными разработчиками open-source, которые должны были решить суммарно 246 задач, распределенные случайно на две группы - с использованием ИИ (Cursor Pro with Claude 3.5/3.7 Sonnet) или без. Задачи обозначены как типовые: рафакторинг, исправление багов, добавление функционала. Разработчики трудились за $150/час.

Результат оказался неожиданным: при использовании ИИ задачи решались на 19% дольше, чем без него 😳 При этом по всем прогнозам, ИИ должен был дать буст в скорости до 25%.

Авторы также постарались выделить возможные причины такого замедления:
- ИИ хуже справляется с большими и сложными проектами (что неудивительно 😁),
- ИИ часто не учитывает контекст и не следует общепринятым правилам для конкретного проекта,
- Много времени / внимания уходило на проверку и исправление сгенерированного кода.

Однозначно, исследование очень интересное и доказывает то, что изолированные бенчмарки - это, конечно, хорошо, но использование в реальности - совсем другое дело. При внедрении ИИ нужна экспертиза того как лучше развернуть новые процессы с его участием именно на своей инфраструктуре, с учетом особенностей своей базы кода и знаний.

Размышляя над этим исследованием, я бы добавил, что для опытного эксперта ассистент ИИ в классическом применении (типа расширения для IDE) выглядит как костыль для здорового человека: быстрее и проще все сделать самостоятельно, чем проверять и переделывать. Тут можно только пофантазировать, что для реально больших и сложных проектов могли бы подойти fine-tuned модели, которые заточены под них и "живут" внутри репозитория.

Но это профи, а что касается ребят попроще (к которым я отношу и себя 😁), то здесь буст скорости есть 100%. Но только при правильно выстроенном пайплайне: архитектура, декомпозиция, тестирование все равно остаются за разработчиком. И, надо признаться, результат будет не промышленного стандарта. Но для прототипирования, разработки макетов и других вещей, чтобы поиграться - вполне.

#research #benchmark

🎙 "Живое" общение с ИИ

Давно ищу приложение, которое дало бы возможность просто говорить с ИИ: ничего не писать, не нажимать постоянно кнопку микрофона. Просто включить режим разговора и общаться - ничего лишнего. Сегодня обнаружил первый интересный вариант - режим Stream в AI Studio от Google.

Я уже как-то писал об Qwen-2.5-Omni, но там все еще было по шагам: записал, отправил по кнопке, получил ответ. Здесь же все работает в режиме полноценного стрима. При этом модель понимает голос, видео с камеры и видео с экрана.

Первые впечатления - офигенно 🤩. Большой шаг вперед к полноценному виртуальному преподавателю по любому предмету, с которым можно просто общаться, как это бывает в обычной жизни. Подтянуть ин.яз., научиться играть на инструменте, делать упражнения или танцевать скоро можно будет легко и непринужденно.

#gemini #education

🔋Робот, умеющий сам менять себе батарею

Китайская компания UBTech представила Walker S2 — гуманоидного робота нового поколения, способного автономно извлекать и заменять собственную батарею.


@ai_machinelearning_big_data

#ai #ml #robots

🧩 Gazebo Tutorial - как использовать несколько файлов SDF для описания мира симуляции

Решил опробовать формат коротких роликов. Разбираюсь с Gazebo и попутно выкладываю полезные советы 😁. Первый пример - оптимизация sdf-файлов в проекте. Надеюсь, в таком режиме получится выпускать ролики чаще 🤞.

#gazebo #simulation #tutorial

🧩 Gazebo Tutorial - разбираемся с экспортом моделей из Blender

Новое видео о том, как составить описание робота по его модели в Blender с помощью плагина Phobos и экспортировать SDF для симуляции в Gazebo.

#gazebo #simulation #tutorial #blender

🧩 Gazebo Tutorial - измерение момента на оси с помощью сенсора

Продолжаем знакомиться с Gazebo Sim - на этот раз для чего-то полезного )) Измеряем статический момент на оси подвижного звена, необходимый для удержания нагрузки.

#gazebo #simulation #tutorial #sensor

🔌 Gazebo Tutorial - управляем роботом в Gazebo из ROS2

Новое видео о том, как соединить ROS2 и Gazebo уже на канале. Наблюдаем за работой ПИД-регуляторов при установке звеньев.

#gazebo #simulation #ros2 #ros_gz_bridge

🏆 Китай становится мировым центром робототехники

弟弟 серьёзно продвинулся в плане роботов. Достаточно посмотреть на два недавних примера.

★ В пекинском E‑Town открылся первый в мире «4S»‑магазин гуманоидных роботов - Robot Mall. По аналогии с автоиндустрией здесь объединены продажи, сервис, запчасти и обратная связь - не выставка на пару дней, а постоянная площадка, где можно прийти, потрогать, протестировать и купить готовые решения для дома и бизнеса. Запуск приурочен к старту World Robot Conference 2025 и показывает новый тренд: Китай строит не только R&D‑витрины, но и ритейл‑инфраструктуру для массового рынка, где производители учатся быстрее «доводить» продукты, а пользователи — быстрее внедрять их в практику. Тут же можно вспомнить и площадку обучения разнородных гуманоидных роботов: Humanoid Robot Kylin Training Ground в Шанхае; сейчас она вмещает свыше 100 роботов и нацелена на одновременную подготовку до 1000 к 2027 году.

★ Unitree Robotics выпустила новую модель своего робопса A2. Благодаря продвинутым сенсорам (фронтальный и тыловой 3D-лидары) и системе управления движением, A2 способен автономно проходить до 20 км без нагрузки, перемещаться со скоростью до 5 м/с и нести до 30 кг на себе (статическая грузоподъёмность — до 100 кг), при этом масса самой платформы около 37 кг. Такой набор характеристик делает модель одной из наиболее универсальных на рынке: A2 подходит как для инспекций промышленных объектов и выполнения логистических задач, так и для использования в аварийных или строительных сценариях

Оба кейса складываются в цельную картину: Китай одновременно наращивает потребительскую инфраструктуру (шоурумы, сервис, обслуживание) и активно выводит на рынок передовые модели роботов разных типов. Это ускоряет переход от прототипов к массовому применению, когда роботы не только впечатляют на сцене (привет, Илон Маск), но и стабильно работают на складе, в городе и на производстве.

#marketing #china #robots

🔦 Mountain Analogy for Gradient Descent in Deep Learning

🗻 The Mountain = Loss Surface
Imagine the loss function as a mountain landscape. The altitude at each point is the loss for a given set of weights and biases.

🛤 Weights & Biases (w, b) = Directions on the Mountain
Your position on the mountain depends on your current values of weights and biases as coordinates in the model parameters' space.

📈 The Gradient = Slope at Your Feet
At your location, the gradient tells you how steep the mountain is in every direction.
For each parameter (w, b), the gradient answers:
“Which way makes the loss increase or decrease most quickly if I nudge this parameter?”

👣 Gradient Descent = Walking Downhill
The raw gradient points you uphill (increasing loss).
To minimize loss, you step opposite the gradient—downhill.
The learning rate (lr) controls how big a step you take with each move.

🧑‍🔬 Summary Table

Mountain = Loss surface
Your location = Current weights & biases (w, b, ...)
Slope at your feet = Gradient (∂L/∂w, ∂L/∂b ...)
Walking downhill = Updating params (w = w - lr * grad)
Step size = Learning rate (lr)

➡️ Goal: Step by step, you use the gradient to guide your parameters (w, b) downhill to the lowest loss—the valley where the model is most accurate!

#pytorch #deep_learning

Appendix: What is the Model Parameter Space?

When we say “the mountain” in the analogy, we’re really talking about the parameter space of the model. That means, for every weight and bias in your network, you have one dimension in this space. If your model has two weights, then you can imagine this as a 2D space, but if you have hundreds or thousands of parameters, you’re in a space with that many dimensions. Every point in this space represents a specific set of values for all the model’s parameters.

When you update the model during training, you’re moving through this parameter space, trying to find the spot where the loss (the “height” of your mountain) is as low as possible.

More parameters do not mean “better resolution” the way it might in an image, but it does mean your model becomes much more flexible. It can represent much more complex patterns and functions. However, having too many parameters can be risky—you might fit the training data perfectly but fail to generalize to new, unseen data (this is called overfitting). The goal is to have enough parameters to model your data’s genuine patterns, but not so many that your model memorizes every tiny detail or noise.

In summary, the optimization process in deep learning is really a search through this multi-dimensional parameter space, adjusting all the weights and biases at once to minimize loss and build a good model.

#pytorch #deep_learning

Изучаю потихоньку курс Introduction to Deep Learning with PyTorch (кстати, очень рекомендую DataCamp). Как конструктор со стажем, привык в голове рисовать картинки, поэтому какие-то концепты обсуждаю с ИИ и выкладываю тут заметки. Не хватает опыта в абстрактном мышлении, чтобы запросто рассуждать о многомерных пространствах параметров и их оптимизации - требуется перевести на язык образов 😁

⚡️ What Are Activation Functions For?

Activation functions play a crucial role in neural networks: they add non-linearity to the architecture, unlocking the network’s ability to learn and represent complex patterns found in real-world data.

If you were to stack only linear layers (even many of them), the entire system remains a just single linear function—it would only be able to fit straight lines or flat planes, which isn’t nearly enough for most tasks. Activation functions transform the output of each layer in a non-linear way, which allows networks to fit curves, steps, and intricate boundaries—enabling deep learning models to capture subtle features and relationships in data.

By leveraging activation functions between layers, neural networks can build up multiple levels of abstraction. Each activation function “warps” the output, giving the network the flexibility to learn everything from simple thresholds up to very complex decision surfaces.

Here are a few popular activation functions, including their math:
☆ ReLU (Rectified Linear Unit): f(x) = max(0, x)
☆ Sigmoid: f(x) = 1 / (1 + exp(−x))
☆ Tanh: f(x) = (exp(x) − exp(−x)) / (exp(x) + exp(−x))
☆ Softmax: f(xᵢ) = exp(xᵢ) / sum(exp(xⱼ)), for every class output (used for multi-class classification)

For example, the sigmoid function “squashes” any real value into the (0, 1) range, making it ideal for outputs that represent probabilities.

In summary, activation functions are what make neural networks flexible, and able to learn just about any relationship in your data—not just straight lines.

#pytorch #deep_learning

🤳 Управление роботами с помощью MoveIt

MoveIt — это программная платформа для робототехники, которая упрощает управление манипуляторами.

Обзор архитектуры - concepts
Центральным элементом MoveIt является узел ROS под названием move_group. Он функционирует как интегратор, объединяя все компоненты системы и предоставляя пользователям интерфейс для управления роботом через топики и экшены (action) ROS.

Пользователи могут взаимодействовать с move_group тремя основными способами:
◦ C++: с помощью интерфейса move_group_interface.
◦ Python: через пакет moveit_commander.
◦ GUI: используя плагин для Rviz (визуализатор ROS).

Для своей работы move_group использует три вида конфигурации:
◦ URDF (Unified Robot Description Format): XML-файл, описывающий геометрию и кинематическую схему робота.
◦ SRDF (Semantic Robot Description Format): Файл, дополняющий URDF семантической информацией, например, определением групп суставов ("рука", "захват") или поз робота ("домой").
◦ Конфигурационные файлы MoveIt: YAML-файлы, содержащие настройки для планировщиков, кинематики, сенсоров и другие параметры.

Ключевые компоненты
◦ Planning Scene (Сцена планирования): Это внутреннее представление мира, которое включает в себя робота, известные объекты (препятствия) и прикрепленные к роботу предметы. MoveIt использует эту сцену для проверки столкновений.
◦ Motion Planning (Планирование движений): MoveIt использует плагины для подключения различных алгоритмов планирования (по умолчанию OMPL). Пользователь отправляет запрос на планирование, указывая целевую позу для манипулятора и ограничения (например, не сталкиваться с объектами). В ответ move_group генерирует траекторию движения, которая является безопасной и учитывает кинематические ограничения.
◦ Planning Request Adapters (Адаптеры запросов): Позволяют изменять запросы до планирования и обрабатывать результаты после. Например, они могут сглаживать траекторию или добавлять в нее временные параметры (скорости и ускорения).
◦ Kinematics (Кинематика): Для расчета положений суставов на основе заданной позы конечного звена (инверсная кинематика) MoveIt использует плагины. По умолчанию используется численный решатель, но пользователи могут подключить и аналитические решатели, например, сгенерированные с помощью IKFast.
◦ Collision Checking (Проверка столкновений): Для предотвращения столкновений робота с окружающей средой или с самим собой используется библиотека FCL. Оптимизировать этот процесс помогает Allowed Collision Matrix (ACM) — матрица, которая указывает, какие пары звеньев можно не проверять на столкновения (например, соседние звенья или те, что физически не могут столкнуться).

#ros2 #moveit