[Разработка робототехники, Робототехника, Управление продуктом] Разработка hardware-продуктов — что и как устроено
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Привет, меня зовут Дмитрий Каржицкий, я работаю QA Lead в белорусском hardware-стартапе Rozum Robotics. Недавно вместе с Университетом Иннополис мы провели митап, посвящённый разработке hardware-продуктов. По следам митапа хочу рассказать про специфику разработки и тестирования роботов и про особенности организации работы в hardware-стартапе.
Кажется, что сфера hardware менее заметна, чем software, как минимум по количеству упоминаний. У всех на слуху разработчики в области веб- и мобильных приложений, которые пишут код на макбуках, попивая смузи. А у hardware специалистов скорее образ классического бородатого инженера, который может и плату спаять, и код написать. Если с задачей на разработку софта верхнего уровня хороший Java-программист должен справиться, то в embedded без понимания железа не обойтись.
Разработку новых продуктов, в том числе и в hardware, можно разделить на два больших направления: коммерческие продукты (стартапы) и научно-исследовательская деятельность (R&D). Процессы и подходы к разработке и тестированию могут быть похожи, отличаются задачи и масштаб. Продукт разрабатывается для конкретных пользователей на основе идеи и исследования, что потенциальным клиентам нужна ваша разработка. В таком подходе больше рисков. Один из рисков — сложность масштабирования продукта. Выпустить новую версию приложения недорого, а создать копию робота всё ещё довольно сложно и дорого. О других рисках я расскажу ниже.
Примеры из процесса разработки будут на основе коллаборативного робота-манипулятора (кобота) PULSE. Это такая подвижная железная рука, которую можно запрограммировать под разные задачи.
Процесс производства программного обеспечения
Сейчас мои основные задачи — это работа над обновлениями для коботов. Команда много времени уделяет софту: обновление ПО для пользователей, разработка и поддержка API, которое позволяет программировать сложные алгоритмы поведения кобота.
Процесс разработки новой фичи выглядит примерно так:
- Хотелки пользователей или бизнеса попадают в бэклог.
- Далее анализируем, декомпозируем на задачи.
- Затем оформляем задачу в User Story.
- Для каждой задачи собираем требования и разбиваем на фичи.
- Фича попадает на этап разработки.
- Разработчики берут задачу и пишут код.
- Когда код готов, заливаем его на робота и тестируем.
- Релизим новый функционал. Пользователи скачивают и устанавливают обновление на своих роботов.
Получается, что под определённую задачу собирается мини-команда. Где-то нужен бизнес-аналитик или разработчик встроенного софта — команды всегда разные.
Если смотреть на этапы разработки софта для робота, то это классический pipeline: планирование, кодинг, тестирование, публикация софта для скачивания, эксплуатация.
Когда фича готова и для неё требуется разработка железа — нового мотора, например, начинается производственный этап, и подключается Отдел технического контроля (ОТК). ОТК проходит всё, что поступает на склад для сборки робота, включая материалы и оборудование. После этого робот собирается и попадает обратно в отдел ОТК, где проверяется качество сборки. После всех проверок на робота заливается новая версия софта.
С обновлением ПО всё понятно, новую версию софта заливаем на веб-сервис. Когда робот в сети, он скачивает обновление и после подтверждения пользователя разворачивает релиз — примерно как новая прошивка для телефона.
С обновлением железа сложнее. Робот модульный, можно заменить любой мотор или всю руку целиком, оставив контролбокс, или заменить контролбокс, оставив руку. Операция не особо сложная, но выполнять её могут только специалисты, знакомые с устройством кобота.
Сложности ириски
Один из рисков в hardware-разработке — длительный процесс производства. Непонятно, будет ли продукт востребован на рынке к моменту запуска. Разработка новой версии софта это одни сроки, новая версия мотора или робота целиком совсем другие. Быстро получить обратную связь не получится, нужно потратить много времени и денег.
Чтобы как-то минимизировать риски, активно используем прототипирование для проверки гипотез. После тестирования прототипа принимаем решение — запускать мелкосерийное производство или выпустить один экземпляр, чтобы проверить жизнеспособность продукта с минимальными вложениями, а слабые места выявлять в процессе эксплуатации.
Так как мы стартап существует bus factor, когда на одном человеке завязаны многие процессы и нет дублирования ролей. Набирать новых людей на одну позицию не самый рациональный вариант, поэтому мы стараемся создавать френдли коллектив, из которого не хочется уходить просто так.
Разработка и специалисты
В hardware есть глобальное разделение на софт верхнего и нижнего уровня. Код для верхнего пишут на Java и Python. Для нижнего (embedded) — на C, C++, инженерам приходится активно работать с математикой. В embedded-разработке важно разбираться в железе, уметь пользоваться мультиметром, осциллографом и измерять физические параметры. Таких специалистов на рынке мало. Обычно это люди с профильным образованием по робототехнике.
Задача под Java подразумевает, что хороший программист с ней справится даже без знания железа. Тем более если железо и софт максимально разделены на уровне интерфейсов и микросервисов, чтобы не было зависимости между верхним и нижним уровнем. Тогда можно легко менять софт верхнего уровня вне зависимости от железа, на котором он работает, и не нужно учитывать 10 000 версий разных окружений, если есть конкретный список версий.
С задачами тестирования могут справиться специалисты без опыта работы с железом. С другой стороны — классно, когда специалист по тестированию может проверить железную часть, произвести измерения, локализовать проблемы. На рынке таких специалистов найти сложно и дорого. Проще взять начинающего и обучить под задачи продукта.
Разработка, особенно верхнеуровневая, похожа на software. Разработчик так же пишет код, запускает его на компьютере или эмуляторе. Из приятных бонусов — код запускается на роботе и работает в физическом мире. Это не программа в браузере, а устройство, которое двигается и выполняет действия. Тестировать такое бывает очень весело.
Кобот кормит меня зефирками
Как мы тестируем коботов
На некотором уровне абстракции нет принципиальной разницы, что тестировать. Если известны параметры на входе и ожидаемый результат, то как именно чёрный ящик выполняет свою работу не так важно.
Работа в физическом мире накладывает свои проверки, но многие процессы построены по классической схеме разработки софта. Мы не стали изобретать велосипед, взяли за основу проверенный временем стандарт ISO 9283. Такой подход позволяют оценить работу робота-манипулятора не по придуманным критериям, а в рамках стандарта, где прописаны характеристики по параметрам: точность и повторяемость прихода в заданную точку, точность и повторяемость прохождения заданной траектории, скоростных, временных характеристик, прохождение поворотов.
Тестирование применяется на всех этапах производства. Многое взято от тестирования микросервисов, отдельно модульное тестирование, интеграционное, есть автотесты для интеграции софта на уровне API, приёмочные тесты покрывают всю систему, канареечные релизы позволяют проверить работу софта на проде у лояльных пользователей. После релиза у нас нет возможности следить за роботами онлайн, поэтому с каждым пользователем есть чат для мониторинга эксплуатации оборудования, постоянно собираем обратную связь.
Бо́льшая часть нашего тестирования это классическое тестирование API и веб-интерфейсов с некоторыми особенностями. Нужно учитывать, что устройство перемещается с приличной скоростью. Если допустить ошибку в логике защитных функций — это серьёзная угроза для безопасности пользователей.
Тесты на безопасность проходят в несколько этапов. В первую очередь проверяем, что робот безопасен для людей и не повредит оборудование и себя, потом проверка функциональных особенностей. Сначала проверяют наши специалисты, потом пользователи, которые готовы к непредвиденным ситуациям, после этого новые функции попадают в общий доступ.
Ещё проводим обязательные тесты на работу в физическом мире: температурный режим, грузоподъёмность, влияние стороннего оборудования, влажность, например, в зависимости от страны — это всё влияет на структуру материала, который используется для производства.
Что сейчас происходит в сфере hardware-автоматизации
Ситуация с ковидом катализировала процессы атоматизации в сферах, которые традиционно не рассматривали такую возможность. Ещё до пандемии был интерес к роботизации процессов в сфере развлечений и услуг — от крупного ритейла, заканчивая барами, магазинами и ресторанами. Владельцы прогрессивных заведений понимают, что многие рутинные операции можно доверить роботу, наливать напитки, например. В этом есть потенциальная экономическая выгода, но сейчас это больше развлечение для посетителей. Роботов-барменов можно встретить на круизных лайнерах или в баре в центре Милана.
Когда начался кризис, привычный способ потребления услуг начал меняться. Заказ кофе с собой вызывает лёгкий дискомфорт, поэтому интерес к непромышленной роботизации растёт. Мы видим это по количеству запросов от потенциальных клиентов и инвесторских сделок в мире. Сейчас тема автоматизации с помощью безопасных коботов на хайпе, но это логично объясняется экономическими и социальными факторами.
Промышленные предприятия, наоборот, заморозили средства, которые планировали направить на автоматизацию производства. С учётом разрыва логистических цепочек и падением рынка реализация многих сделок замедлилась, отменилась или перенеслась.
Надеемся, что помогли лучше понять современную разработку hardware-продуктов. Мы планируем ещё одну статью по этой теме с точки зрения R&D задач Центра компетенций НТИ по направлению «Технологии робототехники и мехатроники» на базе Университета Иннополис. Пишите в комментариях, про какие аспекты hardware в научно-исследовательской деятельности хотите узнать.
Все выступления с митапа It is hard
SPL
===========
Источник:
habr.com
===========
Похожие новости:
- [Дизайн, Дизайн игр, Управление продуктом] Геймификация в бизнесе. Основы
- [Искусственный интеллект, Разработка под AR и VR, Разработка робототехники, Робототехника] Модель МТИ помогает роботам осознавать окружение подобно людям
- [Локализация продуктов, Управление продуктом, Управление проектами, Управление разработкой] Советы по эффективной локализации продукта
- [Карьера в IT-индустрии, Управление продуктом] Генеральный конструктор vs Скрам-мастер
- [Help Desk Software, IT-компании, Service Desk, Управление продуктом, Управление проектами] Как тратить меньше времени на обучение стажеров-аналитиков и повысить его качество
- [Разработка робототехники, Робототехника] МТИ представил робозахват, который может распутывать тонкие кабели
- [Развитие стартапа, Разработка веб-сайтов, Управление продуктом] Как выбрать компанию для реализации своего IT-стартапа?
- [Развитие стартапа, Разработка робототехники, Транспорт] Стартап показал «автомобиль без колес» с дистанционным управлением реальной машиной
- [Будущее здесь, Робототехника] В Перми человекоподобный робот помогает получать госуслуги в МФЦ
- [Управление продуктом] «Все пошло не по плану»: как поменять курс развития продукта и не остаться в проигрыше
Теги для поиска: #_razrabotka_robototehniki (Разработка робототехники), #_robototehnika (Робототехника), #_upravlenie_produktom (Управление продуктом), #_robototehnika (робототехника), #_roboty (роботы), #_hardware, #_hardwareprodukt (hardware-продукт), #_blog_kompanii_gorod_innopolis (
Блог компании Город Иннополис
), #_razrabotka_robototehniki (
Разработка робототехники
), #_robototehnika (
Робототехника
), #_upravlenie_produktom (
Управление продуктом
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:01
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Привет, меня зовут Дмитрий Каржицкий, я работаю QA Lead в белорусском hardware-стартапе Rozum Robotics. Недавно вместе с Университетом Иннополис мы провели митап, посвящённый разработке hardware-продуктов. По следам митапа хочу рассказать про специфику разработки и тестирования роботов и про особенности организации работы в hardware-стартапе. Кажется, что сфера hardware менее заметна, чем software, как минимум по количеству упоминаний. У всех на слуху разработчики в области веб- и мобильных приложений, которые пишут код на макбуках, попивая смузи. А у hardware специалистов скорее образ классического бородатого инженера, который может и плату спаять, и код написать. Если с задачей на разработку софта верхнего уровня хороший Java-программист должен справиться, то в embedded без понимания железа не обойтись. Разработку новых продуктов, в том числе и в hardware, можно разделить на два больших направления: коммерческие продукты (стартапы) и научно-исследовательская деятельность (R&D). Процессы и подходы к разработке и тестированию могут быть похожи, отличаются задачи и масштаб. Продукт разрабатывается для конкретных пользователей на основе идеи и исследования, что потенциальным клиентам нужна ваша разработка. В таком подходе больше рисков. Один из рисков — сложность масштабирования продукта. Выпустить новую версию приложения недорого, а создать копию робота всё ещё довольно сложно и дорого. О других рисках я расскажу ниже. Примеры из процесса разработки будут на основе коллаборативного робота-манипулятора (кобота) PULSE. Это такая подвижная железная рука, которую можно запрограммировать под разные задачи.  Процесс производства программного обеспечения Сейчас мои основные задачи — это работа над обновлениями для коботов. Команда много времени уделяет софту: обновление ПО для пользователей, разработка и поддержка API, которое позволяет программировать сложные алгоритмы поведения кобота. Процесс разработки новой фичи выглядит примерно так:
Получается, что под определённую задачу собирается мини-команда. Где-то нужен бизнес-аналитик или разработчик встроенного софта — команды всегда разные. Если смотреть на этапы разработки софта для робота, то это классический pipeline: планирование, кодинг, тестирование, публикация софта для скачивания, эксплуатация. Когда фича готова и для неё требуется разработка железа — нового мотора, например, начинается производственный этап, и подключается Отдел технического контроля (ОТК). ОТК проходит всё, что поступает на склад для сборки робота, включая материалы и оборудование. После этого робот собирается и попадает обратно в отдел ОТК, где проверяется качество сборки. После всех проверок на робота заливается новая версия софта. С обновлением ПО всё понятно, новую версию софта заливаем на веб-сервис. Когда робот в сети, он скачивает обновление и после подтверждения пользователя разворачивает релиз — примерно как новая прошивка для телефона. С обновлением железа сложнее. Робот модульный, можно заменить любой мотор или всю руку целиком, оставив контролбокс, или заменить контролбокс, оставив руку. Операция не особо сложная, но выполнять её могут только специалисты, знакомые с устройством кобота. Сложности ириски Один из рисков в hardware-разработке — длительный процесс производства. Непонятно, будет ли продукт востребован на рынке к моменту запуска. Разработка новой версии софта это одни сроки, новая версия мотора или робота целиком совсем другие. Быстро получить обратную связь не получится, нужно потратить много времени и денег. Чтобы как-то минимизировать риски, активно используем прототипирование для проверки гипотез. После тестирования прототипа принимаем решение — запускать мелкосерийное производство или выпустить один экземпляр, чтобы проверить жизнеспособность продукта с минимальными вложениями, а слабые места выявлять в процессе эксплуатации. Так как мы стартап существует bus factor, когда на одном человеке завязаны многие процессы и нет дублирования ролей. Набирать новых людей на одну позицию не самый рациональный вариант, поэтому мы стараемся создавать френдли коллектив, из которого не хочется уходить просто так. Разработка и специалисты В hardware есть глобальное разделение на софт верхнего и нижнего уровня. Код для верхнего пишут на Java и Python. Для нижнего (embedded) — на C, C++, инженерам приходится активно работать с математикой. В embedded-разработке важно разбираться в железе, уметь пользоваться мультиметром, осциллографом и измерять физические параметры. Таких специалистов на рынке мало. Обычно это люди с профильным образованием по робототехнике. Задача под Java подразумевает, что хороший программист с ней справится даже без знания железа. Тем более если железо и софт максимально разделены на уровне интерфейсов и микросервисов, чтобы не было зависимости между верхним и нижним уровнем. Тогда можно легко менять софт верхнего уровня вне зависимости от железа, на котором он работает, и не нужно учитывать 10 000 версий разных окружений, если есть конкретный список версий. С задачами тестирования могут справиться специалисты без опыта работы с железом. С другой стороны — классно, когда специалист по тестированию может проверить железную часть, произвести измерения, локализовать проблемы. На рынке таких специалистов найти сложно и дорого. Проще взять начинающего и обучить под задачи продукта. Разработка, особенно верхнеуровневая, похожа на software. Разработчик так же пишет код, запускает его на компьютере или эмуляторе. Из приятных бонусов — код запускается на роботе и работает в физическом мире. Это не программа в браузере, а устройство, которое двигается и выполняет действия. Тестировать такое бывает очень весело.  Кобот кормит меня зефирками Как мы тестируем коботов На некотором уровне абстракции нет принципиальной разницы, что тестировать. Если известны параметры на входе и ожидаемый результат, то как именно чёрный ящик выполняет свою работу не так важно. Работа в физическом мире накладывает свои проверки, но многие процессы построены по классической схеме разработки софта. Мы не стали изобретать велосипед, взяли за основу проверенный временем стандарт ISO 9283. Такой подход позволяют оценить работу робота-манипулятора не по придуманным критериям, а в рамках стандарта, где прописаны характеристики по параметрам: точность и повторяемость прихода в заданную точку, точность и повторяемость прохождения заданной траектории, скоростных, временных характеристик, прохождение поворотов. Тестирование применяется на всех этапах производства. Многое взято от тестирования микросервисов, отдельно модульное тестирование, интеграционное, есть автотесты для интеграции софта на уровне API, приёмочные тесты покрывают всю систему, канареечные релизы позволяют проверить работу софта на проде у лояльных пользователей. После релиза у нас нет возможности следить за роботами онлайн, поэтому с каждым пользователем есть чат для мониторинга эксплуатации оборудования, постоянно собираем обратную связь. Бо́льшая часть нашего тестирования это классическое тестирование API и веб-интерфейсов с некоторыми особенностями. Нужно учитывать, что устройство перемещается с приличной скоростью. Если допустить ошибку в логике защитных функций — это серьёзная угроза для безопасности пользователей. Тесты на безопасность проходят в несколько этапов. В первую очередь проверяем, что робот безопасен для людей и не повредит оборудование и себя, потом проверка функциональных особенностей. Сначала проверяют наши специалисты, потом пользователи, которые готовы к непредвиденным ситуациям, после этого новые функции попадают в общий доступ. Ещё проводим обязательные тесты на работу в физическом мире: температурный режим, грузоподъёмность, влияние стороннего оборудования, влажность, например, в зависимости от страны — это всё влияет на структуру материала, который используется для производства. Что сейчас происходит в сфере hardware-автоматизации Ситуация с ковидом катализировала процессы атоматизации в сферах, которые традиционно не рассматривали такую возможность. Ещё до пандемии был интерес к роботизации процессов в сфере развлечений и услуг — от крупного ритейла, заканчивая барами, магазинами и ресторанами. Владельцы прогрессивных заведений понимают, что многие рутинные операции можно доверить роботу, наливать напитки, например. В этом есть потенциальная экономическая выгода, но сейчас это больше развлечение для посетителей. Роботов-барменов можно встретить на круизных лайнерах или в баре в центре Милана. Когда начался кризис, привычный способ потребления услуг начал меняться. Заказ кофе с собой вызывает лёгкий дискомфорт, поэтому интерес к непромышленной роботизации растёт. Мы видим это по количеству запросов от потенциальных клиентов и инвесторских сделок в мире. Сейчас тема автоматизации с помощью безопасных коботов на хайпе, но это логично объясняется экономическими и социальными факторами. Промышленные предприятия, наоборот, заморозили средства, которые планировали направить на автоматизацию производства. С учётом разрыва логистических цепочек и падением рынка реализация многих сделок замедлилась, отменилась или перенеслась. Надеемся, что помогли лучше понять современную разработку hardware-продуктов. Мы планируем ещё одну статью по этой теме с точки зрения R&D задач Центра компетенций НТИ по направлению «Технологии робототехники и мехатроники» на базе Университета Иннополис. Пишите в комментариях, про какие аспекты hardware в научно-исследовательской деятельности хотите узнать. Все выступления с митапа It is hardSPL=========== Источник: habr.com =========== Похожие новости:
Блог компании Город Иннополис ), #_razrabotka_robototehniki ( Разработка робототехники ), #_robototehnika ( Робототехника ), #_upravlenie_produktom ( Управление продуктом ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:01
Часовой пояс: UTC + 5