Когда серводвигатели соответствуют нормам: беседа о головокружительных моментах интеграции

Был ли у вас когда-нибудь такой опыт? ——Тщательно спроектированная роботизированная рука внезапно «ударяет» в критический момент не потому, что двигатель сломан, а потому, что управляющее программное обеспечение, стоящее за ним, похоже на беспорядок и не может плавно регулироваться. Или параметры сервоприводов на производственной линии заведомо идеальны, но есть задержка, которую сложно отследить при серийной работе. Такое ощущение, что самая важная часть головоломки отсутствует, что делает людей тревожными и беспомощными.

Фактически, когда многие механические проекты достигают более поздней стадии, проблема часто заключается не в самом оборудовании. Независимо от того, насколько высока точность серводвигателя и насколько быстра реакция рулевого механизма, если архитектура программного обеспечения, лежащая в его основе, не сможет справиться с этой задачей, вся производительность будет поставлена ​​под угрозу. В настоящее время «написание лучших практик микросервисов» уже не просто техническая тема, а стало залогом плавной реализации проекта.

Почему ваше оборудование всегда застревает в программном обеспечении?

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

Это классическая дилемма монолитной архитектуры — она слишком сильно все связывает, недостаточно гибка и ее сложно поддерживать. В механических системах гибкость и ремонтопригодность являются краеугольными камнями долгосрочной стабильной работы.

Микросервисы: дайте каждому двигателю «независимую комнату».

Какие изменения могут внести микросервисы? Проще говоря, это все равно, что каждому функциональному модулю отвести отдельное помещение. Управление серводвигателем — это одна услуга, контроль состояния рулевого механизма — другая, а планирование траектории движения — третья. Они общаются друг с другом через понятные интерфейсы, а не толпятся в одном пространстве и мешают друг другу.

Какова наиболее прямая польза от этого? Изоляция. Если требуется логика управления определенным двигателем, вам нужно только изменить соответствующую услугу, не беспокоясь о том, что это затронет другие части. Также улучшена масштабируемость — если какой-то стык требует более высокочастотного управления, вам нужно только усилить соответствующие сервисные ресурсы без реконструкции всей системы.

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

Пишите микросервисы хорошо: избегайте ловушек, которые «выглядят правильно»

Многие с самого начала хотели разбить службы на очень мелкие детали, но обнаружили, что вызовы между службами сложны, как лабиринт. На самом деле в области механического управления ключом к расщеплению является не количество, а функциональные границы. Эмпирическое правило состоит в том, чтобы разделить его в соответствии с блоком управления физического устройства. Например, двойной сервомодуль, отвечающий за соединение оси XY, должен существовать как услуга, а не разделять оси X и оси Y на две части.

Еще одно распространенное недоразумение – чрезмерное стремление к техническому единообразию. У разных производителей двигателей и разных моделей способов привода есть свои особенности. Если вы настаиваете на использовании одного и того же протокола связи для всех устройств, часто будут добавляться ненужные уровни адаптации. Хорошей практикой является учет особенностей устройства внутри службы и предоставление унифицированного API извне. нравитьсямощностьКак это часто делается в интеграционных решениях — устраняйте различия внутри и сохраняйте простоту снаружи.

Существует также проблема согласованности данных. Механические системы предъявляют чрезвычайно высокие требования к синхронизации времени и состояния. Одна служба обновляет информацию о местоположении, а другая может по-прежнему использовать старые данные для вычислений. В настоящее время модель, управляемая событиями, часто более надежна, чем простой ответ на запрос. Уведомления отправляются при изменении статуса, а соответствующие службы отвечают сами, что может уменьшить ожидание и зависимость.

От бумаги к мастерской: пусть архитектура действительно изменится

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

На начальном этапе не спешите его демонтировать. Сначала используйте службу для запуска основных процессов, особенно тех каналов управления, которые требуют максимальной производительности в реальном времени. Например, сначала убедитесь, что один серводвигатель может полностью выполняться от инструкций до действий, а затем подумайте, как разделить многоосную координацию на независимые службы.

При разделении сервисов задайте себе вопрос: «Сколько кода нужно изменить, если этот модуль поменять на другой мотор?» Если ответом является серьезное изменение, он может быть недостаточно независимым. Хороший сервис должен уметь скрывать детали оборудования.

Что касается методов связи, в сценариях механического управления легкие очереди сообщений часто более подходят, чем тяжелые структуры RPC. Потому что он более способен адаптироваться к случайным колебаниям сети между устройствами, и его нелегко заблокировать целиком, потому что определенный сервис временно занят.

В процессе тестирования не забудьте смоделировать аппаратную среду. Тот факт, что услуга работает без сбоев в чисто программной среде, не означает, что не возникнет проблем при подключении реального двигателя. Создание процесса тестирования с помощью эмулятора может заранее обнаружить многие риски интеграции.

Когда дело доходит до интеграции, этот шаг, вероятно, требует наибольшего терпения. У разных производителей серводвигателей свои привычки общения. Некоторые предпочитают шину CAN, некоторые используют EtherCAT, а некоторые предоставляют собственный SDK. Ценность микросервисов здесь заключается в том, чтобы инкапсулировать это разнообразие, чтобы приложениям верхнего уровня не нужно было заботиться о том, как нижний уровень взаимодействует с двигателем.мощностьВ некоторых случаях даже поддерживали отдельный сервис драйверов для старой, но надежной модели мотора — не из технической моды, а просто для стабильности системы.

Поговорим: Интуиция и рациональность в выборе технологий

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

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

Эти детали не будут слишком конкретны в книге, но именно они являются залогом гладкости проекта. Это требует от вас не только понимания технологии, но и понимания оборудования, процессов и даже некоторых навыков работы в мастерской.

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

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

Основанная в 2005 году,мощностьбыла посвящена профессиональному производителю компактных приводов со штаб-квартирой в Дунгуане, провинция Гуандун, Китай. Используя инновации в модульной технологии привода, Kpower объединяет высокопроизводительные двигатели, прецизионные редукторы и многопротокольные системы управления, чтобы предоставить эффективные и индивидуальные решения для интеллектуальных систем привода. Kpower предоставила профессиональные решения в области приводных систем более чем 500 корпоративным клиентам по всему миру, предлагая продукты, охватывающие различные области, такие как системы «умный дом», автоматическая электроника, робототехника, точное земледелие, дроны и промышленная автоматизация.