Русский
Русский
English
Статистика
Реклама

Робототехника

Проблемы правового регулирования искусственного интеллекта

04.08.2020 08:14:31 | Автор: admin
image

Введение


В 21 веке перед человечеством остро встаёт вопрос о внедрении искусственного интеллекта (далее ИИ) в повседневную жизнь. В данной статье дефиниции искусственный интеллект и робот специально не разделяются ввиду действительной конвергенции данных понятий. ИИ это свойство технической или программной системы выполнять функции, которые ранее могли быть выполнены исключительно человеком или иным биологическим существом. И в данном контексте, не говорится о простейшем ИИ типа утюга или микроволновки, речь идёт о куда более сложных алгоритмах. Если сейчас мы смотрим на алгоритмы ИИ как на посредников для достижения наших целей, например, мы используем навигационное приложение Яндекс. Навигатор для того, чтобы добраться до дома быстро в обход дорожных пробок, то в дальнейшем, возможно, такие алгоритмы превратятся в наших правителей. Если посмотреть за кулисы приложения Яндекс. Навигатор, то мы увидим, что тысячи автомобилистов ежеминутно передают данные о состоянии на дорогах. Именно поэтому приложение знает о том, как наиболее рационально проложить дорогу до дома, сохранив наше время. А что, если тысячи, нет, миллионы людей будут передавать информацию о себе, своих политических предпочтениях, состоянии здоровья и тому подобном в какое-нибудь приложение типа Управляющий РФ и этот алгоритм, учитывая статистические данные, будет, например, направлять финансы на поддержу здравоохранения в одном регионе, на развитие образования в другом. В этом случае человеческий вид просто окажется в прямой зависимости от действий ИИ [11]. Это звучит как фантастика, но мы стоим к этому ближе, чем может казаться. Компания Microsoft занимается разработкой и постепенным внедрением приложения Cortana, которое может стать не просто помощником, но и полноценным представителем человека, например, в ходе ведения переговоров. В этом направлении следуют и другие компании: Apple с Siri и Яндекс с Алиса. Такое развитие технологий порождает множество вопросов. Может ли ИИ признаваться автором произведения науки или искусства? Будет ли ИИ равен в своих правах человеку? А, если ИИ, управляющий автомобилем совершит аварию, в результате чего пассажиры получат травму, возможно ли будет обратиться в суд и требовать возмещения вреда здоровью не с человека, а вы только вдумайтесь с ИИ?! И кто будет нести ответственность: пассажир или ИИ? Попробуем ответить на данные вопросы с учетом мнения учёных, при помощи исследования судебной практики и законодательства ряда государств.

1. Искусственное выражение я. Может ли ИИ быть признан автором произведения науки или искусства?


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

Если Deep Blue, который обыграл в шахматы Гарри Каспарова, был достаточно хорошо научен правилам игры своими создателями, то современный ИИ получает от программистов лишь минимальный объем информации, предпочитая самостоятельное машинное обучение. Эти программы изменяют команды и переменные, создавая всё более качественную цепочку кода для достижения поставленной задачи. Так, программа Alpha Go научилась играть в старинную китайскую настольную игру Го, которая во много раз сложнее, чем шахматы, при этом программа применяла абсолютно новые стратегии, что сильно удивило экспертов. Гораздо больше шокирует ещё и то, что ИИ научился создавать уникальные произведения науки и искусства.

Так, появление в 2016 году программы The Next Rembrandt разрушило представление людей о том, что ИИ не может творить. Данная программа проводит анализ картин Рембрандта и на основе полученных данных создаёт собственные картины, которые невозможно отличить от кисти великого мастера. Довольно интересная информация по поводу работы программы приведена на сайте компании Microsoft: Результатами 18 месяцев совместной работы специалистов Microsoft, Дельфтского технического университета, Королевской галереи Mauritshuis и дома-музея Рембрандта в Амстердаме стало создание уникальной в своём роде картины, портрета, который с исключительной точностью воссоздаёт творческую манеру Рембрандта [10]. Имеется ещё один прецедент, связанный с творением, полученным от ИИ. Дэвид Коуп американский композитор и преподаватель Калифорнийского университета в Санта Крузе разработал программу Emily Howell, которая способна создавать музыку, имитирующую шедевры Баха, Бетховена, Шопена и других композиторов. Следует отметить, что ряд экспериментов с участием профессиональных музыкантов позволяет утверждать, что созданную ИИ музыку невозможно отличить от произведений великих классиков. Не отстаёт ИИ от человека и в области науки, так, программа Watson собирает данные пациентов и на их основе создаёт персонализированный график лечения. В данном контексте непременно встаёт вопрос: кому принадлежит право авторства на указанные произведения науки и искусства?

Ответ на этот вопрос с точки зрения законодательства ряда государств одинаков. В соответствии с Законом об авторском праве Великобритании, автором считается лицо, использующее какой-либо инструмент для достижения поставленной цели. Американское законодательство базируется на том, что автором произведения науки или искусства может быть человек. Так, в довольно известном деле Feist Publications, Inc. v. Rural Telephone Service Co., Inc. 499 U.S. 340, 111 S. Ct. 1282 (1991) [9]. Верховный суд США указывает на то, что не может быть объектом авторского права произведение, в котором отсутствует минимальный творческий вклад сознания автора. Вопрос о наличии сознания у ИИ будет подробнее рассмотрен далее, но стоит сразу отметить, что сознанием ИИ не обладает, поэтому получается, что автором может быть только человек. Что касается Российской Федерации, то анализируя пункт 1 статьи 1228 Гражданского кодекса Российской Федерации (далее ГК РФ) можно сделать вывод, что автором произведения науки или искусства также может быть только физическое лицо. Исходя из буквального толкования статьи 1228 ГК РФ, приходим к выводу о том, что не может быть признано автором произведения науки и искусства лицо, которое разработало программу, создавшую это произведение, поскольку не признаются авторами результата интеллектуальной деятельности граждане, не внесшие личного творческого вклада в создание такого результата [2]. По этому поводу приведём высказывание А.А. Семёновой:
С учетом этого целесообразно было бы признать авторство на работу умной машины за лицом, создавшим программу [5, с. 423].
Подходит к этой позиции и статья 136 ГК РФ, в которой говорится, что право собственности на плоды, продукцию, доходы принадлежат собственнику вещи. Но здесь, непременно, стоит отметить, что в соответствии с пунктом 3 ст. 1227 ГК РФ к интеллектуальным правам не применяются положения о праве собственности и других вещных правах. Таким образом, вопрос об авторстве находится как бы в подвешенном состоянии. Тем не менее, ответ на данный вопрос, возможно, найти в международном праве, а именно в статье 12 Конвенции ООН Об использовании электронных сообщений в международных договорах (2005 год) [1]. Суть данной нормы заключается в том, что операции, которые были совершены компьютером, можно рассматривать как действия физических или юридических лиц, от имени которых используется компьютер. Ввиду отсутствия судебной практики эту норму косвенно можно связать непосредственно с действиями ИИ.

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

На данный момент в российском законодательстве имеется очевидный пробел, дающий возможность создание произведения без автора, а значит созданное ИИ произведение будет считаться общественным достоянием. Автор это физическое лицо, то есть субъект гражданского права, поэтому в данном случае появляется прямая зависимость от того, а следует ли ИИ признать субъектом правоотношений?

2. Физические, юридические и электронные лица


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

Следует сразу отметить, что на данный момент имеется государство, поданным которого является андроид, обладающий ИИ. Тем самым создан прецедент, благодаря которому можно говорить о том, что на ИИ, как и на человека распространяется правовой статус физического лица. Этим государством является Саудовская Аравия, поданный София (человекоподобный робот).

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

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

Поэтому не является целесообразным уравнивать в правовом статусе человека и ИИ. Ведь в таком случае получается, что мы создаём фикцию: люди и программы будут совершать примерно одинаковые действия, желая достигнуть определённого результата, будут нести одинаковую ответственность за свои действия. Получается, что ИИ наравне с людьми получит и основополагающие права: право на жизнь, право на личную неприкосновенность и т.д. Но не следует ли нам придерживаться презумпции бессознательности ИИ? В виду того, что у ИИ отсутствуют субъективные переживания личности, он будет сильно выделяться на фоне человека, поскольку будет явно превосходить его по многим параметрам. Да и вряд ли ИИ сможет в ближайшем будущем самостоятельно осмыслить фразу cogito ergo sum.

Представляется, что ИИ должен располагать особым правовым статусом. Так, В.В. Архипов, В.Б. Наумов считают, что к ИИ применима аналогия с юридическими лицами [6]. Действительно, в таком случае ИИ будет иметь все признаки юридического лица, за исключением организационного единства. А.А. Иванов в связи с этим отмечает, что может возникнуть двойственный статус ИИ, поскольку он сможет быть как объектом, так и субъектом гражданского права [8]. С точки зрения этой позиции встаёт ещё вопрос и о праве собственности на вещи: на каком праве ИИ будет обладать вещами? Будет ли это ограниченное вещное право? Ответить на данные вопросы в данный момент не представляется возможным.

Л.И. Сафаргалеев высказывает мнение, что к ИИ применимо правило, используемое ещё в римском праве servi res sunt (рабы вещи), по его мнению ИИ не может быть самостоятельным субъектом права, но он может приобретать права и обязанности для своего хозяина [5, С. 407].

Все выше названные позиции имеют право на существование, но, по нашему мнению, они не лишены недостатков, так как неминуемо встаёт вопрос о том, а каков будет правовой статус ИИ после смерти его владельца? Следуя реалиям российского гражданского законодательства получается, что для приобретения права собственности на ИИ нам необходимо будет ждать 5 лет, то есть, по факту, в течении этого срока будет существовать ИИ-нелегал, который имеет разум, совершает действия, но не приобретает ни для кого прав и обязанностей. Что делать? Конечно, в таком случае мы можем поступать с ИИ как с кошками, собаками и иными животными в Древнем Египте, то есть утилизировать их вместе с хозяевами. Но насколько это рационально?
Верно, на наш взгляд, в своё время отметил Дж. Дьюи:
Мы часто обсуждаем проблемы с точки зрения старых идей, тогда как решение проблемы связано с избавлением от старых идей и их заменой на понятия, более соответствующие современному состоянию идей и знаний [12, P.657].
Интересна для рассмотрения вопроса о правовом статусе ИИ резолюция Европарламента от 16 февраля 2017 года (далее Резолюция). В Резолюции приводятся рекомендации для Европейской комиссии относительно норм гражданского права о робототехнике (2015/2013(INL)) [3]. В тексте данного документа правовой статус ИИ является специфическим, ИИ становится своеобразным электронным лицом. В Резолюции особо подчёркивается, что ИИ призван дополнить возможности человека, а не заменить его. Указывается, что ИИ не может своими действиями или бездействиями причинять вред человеку, а также допускать возможность причинения вреда, ИИ должен повиноваться всем приказам человека, то есть фактически закрепляются три закона робототехники, сформулированные писателем фантастом Айзеком Азимовым в рассказе Хоровод ещё в 1942 году. Подход, сформулированный в Резолюции, на наш взгляд, является наиболее целесообразным, и здесь сразу же возникает вопрос об ответственности ИИ.

3. Кто будет нести ответственность?


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

В соответствии с российским законодательством возмещать все убытки будет владелец источника повышенной опасности. Но ведь автомобилем управлял ИИ. Не будет ли это считаться непреодолимой силой? Мог ли владелец автомобиля вовремя осознать опасность для окружающих и взять управление на себя? Ввиду отсутствия судебной практики ответить на этот вопрос затруднительно, но ряд государств уже ввели нормы, которые регулируют ответственность в случае возникновения таких казусов. Стоит подробнее остановиться на опыте ФРГ. Так, в Германии в 2017 году был принят Восьмой закон о внесении изменений в Закон о дорожном движении от 16 июня 2017 года [4], которым фактически оформилась возможность использовать беспилотный транспорт. В законе устанавливается, что водитель может отвлекаться от происходящего на дороге, но он обязан взять управление на себя, если ИИ предлагает сделать ему это в значительной части или полностью. Также водитель должен взять управление на себя, если он осознает или должен осознавать, что дальнейшее управление автомобилем ИИ невозможно, например, когда водитель видит, что автомобиль под управлением ИИ направляется в толпу пешеходов и т.п. При этом в случае, если имело место причинение вреда человеку или имуществу по вине водителя, то ответственность будет нести он, если вред был причинён из-за технической ошибки, то отвечать будет автопроизводитель. В Германии, на наш взгляд, подход к ответственности является действительно достаточно качественным, поскольку не может и не должен нести ответственность автомобилист, который не смог взять управление автомобилем на себя в результате технической ошибки.

Вопрос об ответственности также поднимается в Резолюции Европарламента от 16 февраля 2017 года [3]. В документе указывается, что ИИ не может нести ответственность сам по себе, поскольку его действия или бездействия зависят от оператора (владельца), то есть ИИ является своеобразным инструментом для достижения конкретной цели. Ввиду вышесказанного устанавливается ответственность не только владельца ИИ, но и производителя, если какой-либо ущерб был причинён из-за технической ошибки. Однако в Резолюции также говорится о том, что, чем выше автономность ИИ, тем меньше он может расцениваться как обычный инструмент. Это вызывает вопрос: может ли ИИ самостоятельно отвечать за свои действия или бездействия? Нет, на данный момент не может, но стоит отметить, что по мере развития технологий юристы непременно вернутся к этому вопросу. Пока что можно лишь предложить варианты ответственности ИИ. Вполне рабочую идею, в этой связи, предложили Г.А. Гаджиев и Е.А. Войниканис [7]. Её суть заключается в том, что ИИ будет нести ответственность за счёт средств, находящихся на счёте непосредственно у ИИ. Реализовать данную идею возможно, если при регистрации какого любо ИИ его владелец будет вносить определённую сумму, которая в дальнейшем будет аккумулирована в страховом фонде и в случае возникновения страхового случая будет направлена на его удовлетворение. В конце концов, если ИИ будет признан самостоятельным субъектом права, то он сможет трудоустраиваться, иметь свой банковский счёт и самостоятельно отчислять деньги в свой страховой фонд.

Заключение


На данный момент ИИ не может быть признан автором произведения науки или искусства, поскольку такая возможность появится лишь при признании ИИ субъектом правоотношений.

Нормы законодательства ряда государств не признают ИИ в качестве субъекта правоотношений. Однако Саудовская Аравия предоставила гражданство роботу Софии, что говорит о признании за ИИ статуса физического лица. Такой подход кажется преждевременным, поскольку человек и ИИ не совпадают в плане своих психоэмоциональных качеств и свойств. Вполне возможным в то же время представляется говорить о признании за ИИ особого статуса электронного лица. Это позволило бы не смешивать понятия в праве и никоем образом не нарушало бы прав людей. Вопрос об ответственности ИИ также является неурегулированным. В случае причинения вреда человеку или имуществу ответственность в соответствиях с реалиями законодательства будет нести или владелец источника, причинившего вред, или же его производитель. Представляется, что необходимо обязать возмещать, причинённый вред, ИИ, если у него для этого будут иметься все необходимые возможности и в первую очередь наличие денежных средств.

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

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




Данная статья публиковалась ранее в сборнике. Ссылка на неё будет выглядеть следующим образом: Воробьева И.В., Салахутдинов В.Д. Проблемы правового регулирования искусственного интеллекта // Малышевские чтения 2020. Наука и образование: будущее и цели устойчивого развития: материалы XVI международной научной конференции, в 4 частях / под ред. А.В. Семенова. М.: изд. ЧОУВО МУ им. С.Ю. Витте, 2020. Ч. 4. C. 62-72




Литература

1. Конвенция ООН Об использовании электронных сообщений в международных договорах [Электронный ресурс] // www.un.org/ru/documents/decl_conv/conventions/elect_com.shtml (дата обращения: 30.12.2019).
2. Часть четвертая гражданского кодекса Российской Федерации. // СЗ РФ. 2006. 52. Ст. 5496.
3. Резолюция Европарламента от 16 февраля 2017 года. [Электронный ресурс] // robopravo.ru/riezoliutsiia_ies (дата обращения: 30.12.2019).
4. Восьмой закон о внесении изменений в Закон о дорожном движе-нии от 16 июня 2017 г. [Электронный ресурс] // robopravo.ru/initsiativy_frantsii_v_sfierie_robototiekhniki_2013_2 (дата обращения: 30.12.2019).
5. E-commerce и взаимосвязанные области (правовое регулирование): сборник статей / Е.А. Останина, Л.В. Кузнецова, Е.С. Хохлов [и др.]; рук. авт. кол. и отв. ред. д.ю.н. М.А. Рожкова. Москва: Статут, 2019. 448 с.
6. Архипов B.B., Наумов В.Б. Искусственный интеллект и автоном-ные устройства в контексте права: о разработке первого в России закона о робототехнике // Труды СПИИ РАН. 2017.- Вып. 6 (55). С. 46-62.
7. Гаджиев Г.А., Войниканис Е.А. Может ли робот быть субъектом права (поиск правовых норм для регулирования цифровой экономики)? // Право. Журнал Высшей школы экономики. 2018. 4. -C. 24-48.
8. Иванов А.А. Мечтают ли андроиды об электроовцах? [Электрон-ный ресурс] // zakon.ru/blog/2017/2/15/mechtayut_li_androidy_ob_elektroovcah (дата обращения: 29.12.2019).
9. Слабых И.И. Дело Feist v. Rural Telephone: основы авторского пра-ва от Верховного Суда США. [Электронный ресурс] // zakon.ru/blog/2019/04/11/delo_feist_v_rural_telephone_osnovy_avtorskogo_prava_ot_verhovnogo_suda_ssha#comment_490346 (дата обращения: 29.12.2019).
10. Следующий Рембрандт [Электронный ресурс] // news.microsoft.com/ru-ru/sleduyushhij-rembrandt (дата обращения: 28.12.2019).
11. Тихомиров Ю.А., Архипова Н.И., Косякова Н.И. Российское гу-манитарное право учебное пособие для вузов / Российский государствен-ный гуманитарный университет; под редакцией Тихомирова Ю.А. (ответ-ственный редактор), Архиповой Н. И., Косяковой Н. И Москва, 1998.
12. Dewey, J. The Historic Background of Corporate Legal Personality // Yale Law Journal. 1926. 35. pp. 655 673.
Подробнее..

Первая попытка собрать лазерный проектор из жестких дисков

21.06.2020 02:15:26 | Автор: admin

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

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


Для этого я сначала разбираю жесткие диски.


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


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


Для уменьшения габаритов устройства, я распиливаю корпус жесткого диска на две части


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


Выпиливаю зеркало из алюминиевого диска, снятого с этого же HDD. Его размер получился 35 x 10 мм. Приклеиваю эти зеркала цианакрилатным клеем к гальванометру. При вклеивании учтите, что клей схватывается моментально. Лучше сначала установить зеркало в паз, а потом капнуть в место соединения каплю клея.


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


После того как собраны 2 гальванометра, я их соединяю на уголки от оконных рам, под углом 90. Для этого пришлось просверлить по 2 отверстия в алюминиевом основании и закрепить к ним эти уголки

Механическая часть проектора собрана, теперь подключаем его электромагниты к двухканальному усилителю мощности PAM8610. Мне быстрее хотелось проверить мое устройство в деле и я решил подать на вход усилителей музыку. И о чудо! Я увидел красивое зрелище, словно в одно мгновения я очутился в ночном клубе или на концерте своей любимой рок группы. Получилась крутая лазерная цветомузыка. Она рисует невероятные картинки в такт с музыкой, на которые можно смотреть не отрываясь. Что самое удивительное, то что получаемые изображения на столько разнообразные и не повторяются от трека к треку. Наибольшую разницу можно заметить в разных музыкальных жанрах. Посмотрев видео, Вы можете в этом наглядно убедиться.

Теперь пробую включить с бесплатным софтом в режиме проектора и тут меня ждало разочарование. Без постоянной составлявшей с выхода звуковой карты невозможно отобразить хороших изображений или анимацию. Так как через разделительные конденсаторы все углы округляются, не возможно удерживать гальванометр в одном положении и он сразу стремится вернуться в среднее положение. Также гальванометрам требуется обратная связь, для удержания нулевой точки. И еще нужно обеспечивать гашения луча, то есть отключать лазер на момент возврата в начальное положение. Для переделки потребуется USB звуковая карта, как минимум на 4 канала. Внешней звуковой карты у меня пока нет и я решил продолжать свои эксперименты после того как она ко мне приедет.

Редактор ild файлов
Проигрыватель ild файлов и анимации

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

Как организовать и провести детские роботехнические соревнования для всей страны в условиях карантина

08.07.2020 18:05:40 | Автор: admin
Хабр, приветствую! Мы занимаемся организацией и проведением детских робототехнических соревнований в рамках АгроНТИ 2020 по направлению Агророботы. Но, как вы уже догадываетесь, в этом году с массовыми мероприятиями, а тем более детскими, не все так однозначно


Соревнования


Как это происходит в нормальном режиме. Есть АгроВУЗы, являющиеся региональными площадками. Есть команды школьников из сельскохозяйственных регионов. Есть полигон, имитирующий наши необъятные просторы и есть робот на дистанционном управлении. Робот поставляется в виде конструктора и команда перед соревнованиями его собирает. На соревнованиях робот под управлением оператора за определенное время должен выполнить задания на полигоне: перевезти тюки сена, переместить бидоны, посадить картошку, вспахать поле. За выполнение заданий и прохождение участков полигона команда получает баллы, за ошибки штрафы. Соревнования проходят 2 дня. Вот так это выглядело в Белгороде







Робот это радиоуправляемая 6-ти колесная тележка с различными специальными исполнительными механизмами. За основу шасси взята кинематическая схема от марсохода Curiosity. На роботе имеется: схват совмещенный с отвалом, устройство для посадки картофеля и плуг. Детали робота изготовлены лазерной резкой из листа дюраля Д16 толщиной 2мм и 3D печатью ABS пластиком. Робот управляется Arduino совместимым контроллером нашей разработки, в качестве пульта беспроводной геймпад. Назвали мы его Агробот.



Полигон это 35 квадратных ячеек, каждая ячейка размером 800х800мм. На полигоне имитируются разные типы местности и строений: холмы, леса, мосты, эстакады, овраги и т.д. Ячейки полигона произвольно стыкуются друг с другом и, в результате, получатся реконфигурируемый испытательный полигон сельскохозяйственной направленности.



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

В мае 2019 года мы поставили полигоны и конструкторы в 10 городов и успешно провели соревнования. В мае 2020 года соревнования должны были пройти в 9-ти новых городах: Санкт-Петербург, Москва, Орёл, Барнаул, Уфа, Рязань, Омск, Пермь, Самара. С начала года началась работа по изготовлению 9-ти полигонов и 120-ти конструкторов, с планами провести соревнования во второй половине мая И, как вы, наверное, уже догадались, планы пришлось слегка корректировать! Вмешалась вот эта бяка



Проблема


К марту уже стало понятно, что соревнования переносятся на неопределенный срок: начались перебои с поставками комплектующих и изготовлением деталей полигонов, каникулы в масках и прочая самоизоляция в общем, вам все это известно. Понимая не радужные перспективы, организаторы конкурса АгроНТИ попросили что-то придумать в мае, чтобы ребята не скучали и, при этом, все должно быть дистанционно и в масках. И еще, желательно, подключить ребят из регионов с прошлого года в общем охватить все 19 регионов. Был проведен небольшой мозговой штурм, сразу после вынужденных апрельских каникул и стало понятно, что ничего не понятно. Надо как то провести дистанционные робототехнические соревнования!!!



В сухом остатке: у нас имеется тестовый полигон и несколько тестовых Агроботов, все это находится в Санкт-Петербурге. Как этим рулить из Уфы или Рязани решительно не ясно. А есть еще и Уссурийск!!!

Но, мы же, вроде, робототехники, 21-й век на дворе!!! Интернет Телеуправление И вот это вот все!

Слабая надежда


В нашей лаборатории имелись наработки по электронике для мобильных роботов на базе Raspberry Pi, в частности, почти готовые платы-шилды для Raspberry Pi в основе которых был микроконтроллер Atmega328p. На плате также расположен драйвер коллекторных двигателей L298P на 2 канала, 4 канала управления сервами, динамик и разъем для подключения OLED дисплея 128х64pix.



С Raspberry Pi плата общается по шине i2c и под плату написана библиотека ПО на языке Python, обеспечивающая программный интерфейс взаимодействия с железом. Все немного сыроватое, но, главное, платы есть. Вот они, бери!

Агробота мы, в свою очередь, проектировали таким образом, чтобы в него можно было поставить Raspberry Pi на место штатной платы Arduino и тут, как вы понимаете, звезды сошлись!

Конспирологи могут начать рассказывать, что 3 года назад мы предвидели вирус и заранее подготовились. К Raspberry Pi подключается штатная камера, которую можно использовать в качестве курсовой на роботе, по USB можно еще что то повесить и на борту имеется годный Wi-Fi.
Достали с полки Агробота сдули пыль со старичка и заменили ему масломозги, замена явно пошла на пользу, робот значительно поумнел. В качестве ОС на Raspberry Pi была установлена OC Raspbian. Решено было, что будет две камеры: одна курсовая на штанге и одна смотрящая на посадку картофеля. Обе камеры с объективом рыбий глаз. Аппаратные камеры, как и Raspberry Pi 4, были в наличии. Камера для посадки картофеля была заказана из Китая. Время позволяло, алиэкспресс вроде работал и посылка должна была прийти как раз к соревнованиям ха-ха 3 раза. Плуг с робота решено было демонтировать, потому как и так уже хорошо, а пахать целину мы тут дистанционно точно не будем. Дисплей разместили в секторе обзора курсовой камеры с перспективой выводить на него информацию, полезную для участника. Начали проектировать и печатать детали для установки камер, дисплея и штанги. Ну, а пока получился такой макет, на профессиональном робототехническом сленге чучело валенка, подключенное к внутренней ethernet-сети лаборатории по проводам и запитанное от блока питания.



И тут встал вопрос, как запитывать робота, так как штатно он питался от 2-x Li-Ion батареек Теслы 18650 АКБ и этого вполне хватало на очные соревнования, но теперь у нас прожорливая Raspberry Pi на борту и соревнования будут длиться 24x7 весь рабочий день. Менять АКБ каждые полчаса очень не хотелось, было решено запитать робота по проводам, а провод в свою очередь свесить с потолка по центру полигона, завести его в штангу курсовой камеры и как-то подтягивать.
Ну такое
Забегая вперед скажу, что решение было не очень И впоследствии мы от него отказались.


Полигон


Итак, с роботом более-менее понятно, теперь полигон. Решено было разместить полигон недалеко от лаборатории. Уже было понятно, что придется частенько бегать к нему во время проведения соревнований, а это лучше делать сидя в комфортных условиях рабочего места, да и текущую работу никто не отменял! Как раз рядом оказался очередной рояль в кустах пустующий светлый холл. В холл влезло 15 ячеек и у полигона появились стенки, что-бы робот не убежал за пределы, а то лови его потом! Над холлом по диагонали натянули трос, посередине которого разместили разъем для подключения кабеля от робота. И по тросу пустили кабель до блока питания.

Помимо камер на роботе, очевидно, нужны еще камеры на полигоне. Придумано, сделано Заказали IP камеры: одну под потолок над полигоном и две по диагонали. Все камеры с POE, поэтому еще приобрели РОЕ коммутатор, который впоследствии стал коммутатором всей системы, все оборудование бюджетное Hikvision. Благо, что поставщики работали и все было в наличии. Камеры разместили на местах, проложили ethernet-кабели от камер до места установки коммутатора.



Инфраструктура


Настало время прорубать окно в Европу Интернет. В качестве окна в интернет. IT отдел выделил нам виртуальный сервер с двумя сетевыми интерфейсами. Один сморит в мир Интернет, второй во внутреннюю сеть лаборатории, на внешнем интерфейсе фиксированный IP адрес и тестовое доменное имя. На сервер накатили ОС Ubuntu 18.04.

Итого: робот на полигоне, сервер в серверной, камеры вокруг, все в проводах, но еще не организована связь с роботом и упущен один важный момент: полигон стоит в холле, вокруг люди ходят, работа кипит, обязательно будут зрители и им непонятно что происходит, нужен генеральский интерфейс, по простому телевизор (панель), на который будут выводиться трансляции с камер, а так как трансляции кто-то должен выводить, то нужен компьютер под этот телевизор и этот же компьютер может и быть wi-fi точкой доступа для робота, два в одном! Тут в кусты закинули очередной рояль: cо старого проекта лежал непригодившийся промышленный компьютер с wi-fi и HDMI. Под комп и коммутатор были напечатаны крепления на 3D принтере и все оборудование размещено на стойке под телевизором.



На комп установили ОС Ubuntu 18.04 и собрали утилиту create_ap. С помощью этой утилиты создается точка доступа и мост (brige) между проводным ethernet интерфейсом и wi-fi, причем в одну строчку из командной строки и без бубна! Весчь!!! Роботу прописали в конфигах подключаться к этой точке доступа. Параллельно к месту установки стойки с телевизором, компьютером, коммутатором и полигоном наш отдел АХО протянул ethernet кабель, а IT-отдел соединил все это хозяйство с сетью лаборатории в одну подсеть. Итого: все IP-камеры, робот и компьютер через коммутатор подключены к внутренней сети лаборатории, к которой также подключен сервер смотрящий в Интернет. Все пингуется, пакеты летают, картинки с IP-камер транслируются в VLC, все удаленно по SSH подключается, везде Ubuntu Raspbian Linux и все управляется с рабочего места из лаборатории ну красота же! Но чего-то не хватает ах, да, телеуправление, видео через интернет и соревнований.
Ну обо всем по порядку.

Управление роботом


Телеуправление было решено делать на базе протокола UDP, так как система должна работать в реальном масштабе времени и у нас в лаборатории имелись некоторые наработки по этой тематике. В двух словах: программа управления на компьютере участника ловит нажатия клавиш и посылает 10 раз в секунду на робота UDP пакет. В пакете закодированы порядковый номер пакета, значения скоростей на двигатели, положение сервомоторов, уникальный ключ и контрольная сумма, для контроля целостности данных. В свою очередь, на роботе запускается программа, которая открывает UDP порт и принимает пакеты, проверяет контрольную сумму, сверяет ключ и, если все хорошо, задает скорости на моторы и выставляет положения сервоприводов. Программы были написаны на Python. Управление только с клавиатуры, так как она точно есть у всех участников. UDP порт, на котором робот будет принимать пакеты и уникальный ключ генерятся программой случайным образом это такая защита от несанкционированного подключения. На сервере с помощью iptables был настроен проброс пакетов, т.е. UDP пакет пришедший на внешний IP адрес сервера, автоматом пересылался на робота. Программу управления, написанную на Python с помощью PyInstaller преобразовали в исполняемый файл под OC Windows. И все это протестировали на школьнике, сидящем дома в изоляции в соседнем доме. Робот ожил, покатался по лабе, подъехал к блоку питания и застрелился выключил сам себя, нажав схватом на кнопку выключения! Стало понятно, что система-то живет!



Видеотрансляция


На момент начала этой эпопеи, мы плотно работали с gstreamer, то есть, могли слать видео точка-точка, а вот как реализовывать видео трансляции точка-много браузеров, понятия не было никакого. Ну, как говорится, Google Yandex в помощь.

На просторах гитхаба обнаружили проект v4l2rtspserver, который без проблем собрался на Raspberry Pi и при запуске из командной строки создал RTSP сервер, подключившись к которому из VLC, мы увидели картинку с курсовой камеры робота! Настроив проброс пакетов на сервере, удалось увидеть картинку с робота и на компьютере коллеги, находящегося далеко за пределами Санкт-Петербурга. Но при подключениях одновременно с разных компьютеров начинала расти загрузка ЦП Raspberry Pi и стало понятно, что при реальных нагрузках в десятки человек Raspberry Pi не выдержит, да и IP-камеры позволяют отдавать не более 6 потоков. Продолжаем гуглить в Яндексе И внезапно, нахожу статью на Хабре Встраиваем WebRTC плеер для живых трансляций с вебкамер и IP камер Так вот же оно!!!

image

Все уже придумано! Захожу на сайт flashphoner.com. То что нужно, бинго! К сожалению, продукт платный, но наверняка же есть и другие. Снова гуглеж, который меня выводит на проект webrtc-streamer. Ссылка показалась подозрительно знакомой ну, конечно, это же еще один проект того же автора, что и v4l2rtspserver, он был всего в паре кликов! Качаю, собираю проект на сервере, в конфигурационном json файле прописываю ссылки на RTSP стримы с камер, запускаю из командной строки и получаю веб-сервер с готовой страницей с трансляциями со всех камер. Отправляю все данные школьнику тестировщику, запускаю робота тестер подключается, катается по лаборатории и вроде все отлично! Но спустя какое то время школьник сообщает, что трансляции начали лагать. Захожу в терминал на сервере, набираю top и вижу 200% загрузку CPU и утечку памяти это был провальный провал. Написал автору webrtc-streamer, ответ свелся к:
I am sorry if I not really answer to this question that was debated many times.
Опенсорс, который мы заслужили! После были попытки собрать и установить другие решения, но все тщетно, только терял время.

Итак возвращаюсь к WebCallServer от компании Flashphoner.

Скачал, установил, получил и активировал Trial лицензию на месяц, все прошло без проблем. Скачал и установил веб-сервер apache. Коллега по разработке написал пробную версию страницы с трансляцией с камер, все заработало, задержки в видео были на приемлемом уровне. Бубен, конечно, местами был нужен, но, в целом, работает! Документация у WebCallServer мое почтение, на форуме техподдержка оперативно отвечает на вопросы. К этому времени IT-отдел организовал доменное имя agro-online.rtc.ru и на него получили SSL сертификат от LetsEncrypt. Всю систему перевели на HTTPS и допилили страницу с трансляцией и генеральским интерфейсом. Система трансляций заработала, загрузка сервера не выходила за разумные пределы. Перед соревнованиями оплатили лицензию WebCallServer на 2 месяца и её активировали. В целом решением на базе WCS остался доволен. Что в результате видит участник:



Тесты, грабли и продакшн


Робот постепенно из состояния чучело валенка начал обретать финальный вид, распечатанные на 3D принтере детали занимали свои места.



Начались полноценные тестовые заезды уже из регионов, которые выявили недоработки в конфигурации полигона, что было оперативно поправлено. От кабеля питания на роботе отказались очень сильно затруднял движение, наматывался на колеса и 5 Ампер блока питания не хватало при пиковых нагрузках, Raspberry Pi банально улетал в перезагрузку. Робота перевели на Li-Po АКБ с емкостью 6 Ампер*час, хватает на полдня активной работы и добавили индикатор заряда батареи. С трансляцией оказалось не все гладко: трансляция с камер на роботе при активной езде периодически падает, помогает перезагрузка страницы, правда, не сразу. И вылезла бага со схватом: он периодически непроизвольно разжимался. Времени искать причины уже не было, надо было начинать соревнования. Поэтому было объявлено, что это не баг, а фича и описано в инструкции к роботу, юридически мы чисты. Под конец дня иногда падал Wi-Fi на компьютере, но это уже было после заездов и на ход соревнований не влияло никак.

Пришли камеры из Китая, но доставка Aliexpress перепутала наклейки на пакеты и мне пришел пакет адресованный гражданке из Нидерландов, а там скажем так это не совсем те камеры, что я заказывал. Смешно получилось. Выручили ребята из соседнего отдела, за что им спасибо!

Организация соревнований


Оставалось дело за малым все организовать! Была разработана документация соревнований: регламент, инструкция для робота, памятка по балльной системе и протокол заезда. Вместе с ПО управления роботом, документацию выложили на сайте для свободного скачивания участниками. Технически мы могли пропустить 4 5 6 человек в день, по часу на участника. В этот час проходит 3 заезда по 15 минут: первый ознакомительный, второй и третий идут в зачет с фиксацией в протоколе. Время начала заездов 10:00, 11:00, 12:00, переыв, 14:00, 15:00, 16:00, время московское. В мессенжере WhatsApp были созданы региональные группы с именами АгроБелгород, АгроНовосибирск и т.д. По мере создания групп составлялся график заездов регионов по дням: один регион в день. Региональные представители в своих группах формировали списки участников с расписанием по времени заездов. Ко дню заездов региона мы в группе видели список участников со временем старта, а дальше дело техники и организованности участников.

Проведение


День сурка существует! С утра поставить на робота свежую АКБ, включить комп и телевизор, на компе открыть страницу с генеральским интерфейсом, на рабочем месте зайти в терминал, запустить точку доступа на компе, дождаться подключения робота к ней. На роботе, также через терминал, запустить трансляции с камер. Убедиться, что есть картинка. Привести полигон в порядок: разложить тюки и бидон по своим местам, зарядить в робота картофан, расставить коров. Параллельно в региональной группе поинтересоваться, о готовности участников и все ли понимают, что тут вообще происходит.

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



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

И так каждый заезд и каждый день, пока не пройдут все участники всех регионов. На фото судья за работой



Что так и не заработало или заработало, но как то не так


  • Как уже упоминал ранее это кабель для питания робота, свисающий с потолка. От него отказались на этапе тестирования и робота переделали на Li-Po аккумулятор. Решение изначально было ошибочным.
  • Не удалось получить звук с микрофона камеры в браузере. WebCallServer не понимал поток со звуком идущий от v4l2rtspserver видео без звука работает, а вот то же самое видео, но со звуком увы нет.
  • И имеются серьезные нарекания к стабильной работе v4l2rtspserver победить падения трансляций не удалось. Они конечно со временем восстанавливались, но к этому моменту оператор робота имел стертый палец от нажатий на клавишу F5, из-за тщетных попыток реанимировать трансляцию курсовой камеры.

По всей видимости от v4l2rtspserver будем отказываться и искать другое решение. Кто сказал ffmpeg!?

Ну и классика жанра за месяц соревнований все моторы на роботе были поменяны минимум по разу. Жгли их участники не щадя наших нервов!



Итог


Из оборудования и материалов были закуплены:

  1. IP-камеры HikVision 3шт
  2. POE коммутатор HikVision 1шт
  3. USB OEM камера на робота ELP 2шт
  4. Стенки на полигон -16шт
  5. Трос и крепеж 1шт
  6. Лицензия на WebCallServer на 2 месяца 1шт

Все остальные материалы имелись в наличии. Пластиковые детали для робота изготавливались на 3D принтере, существующее железо нещадно правилось напильником. На все ушло 3 месяца было задействовано 3 человека, двое из них студенты. Два месяца на разработку и месяц на проведение. Разработкой железа и софта занимались 2 человека, причем один удаленно и в лаборатории не появлялся. Проведение соревнований 2 человека: один техническое сопровождение и один судейство. Все в условиях изоляции, масок и прочих связанных с этим ограничений. Также хочу отметить, что были задействованы IT-отдел, хозяйственный отдел и информационно аналитический отдел, с их стороны все вопросы решались четко и вовремя.

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

В общей сложности в соревнованиях приняли участие 110 школьников из 19 городов от Санкт-Петербурга до Уссурийска. Можно сказать, что охватили всю Россию.



Получен бесценный опыт и опробован новый формат соревнований. У нас все получилось!!!

Много фото робота в процессе заездов























Используемое в данном проекте ПО


WebCallServer WebRTC сервер от компании Flashphoner, платная лицензия
create_ap Удобное создание точки доступа и сетевого моста
v4l2rtspserver RTSP сервер
webrtc-streamer WebRTC сервер, работает, но крайне нестабильно при нагрузках. В проекте не задействован.
Подробнее..

Перевод Робот из LEGO и Arduino, обходящий препятствия

20.07.2020 10:13:25 | Автор: admin


Мы обожаем LEGO и Crazy Circuits [LEGO-совместимая электроника / прим. перев.], поэтому решили скомбинировать их в простого и интересного робота, умеющего обходить препятствия. Мы покажем, как собрать такого робота и подробно опишем этот процесс. Ваша версия робота может не полностью совпадать с нашей.

Приводим список необходимой электроники и деталек LEGO. Не бойтесь экспериментировать с ними.







Комплектующие


Электроника



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

LEGO


Мы использовали различные детальки, а вам рекомендуем сделать так, как вы считаете нужным, и из того, что есть у вас на руках. Важно, чтобы у вас был способ приделать сервомоторы снизу, ультразвуковой датчик так, чтобы он смотрел вперёд, и каким-то образом закрепить плату и источник питания. Для этого можно использовать двусторонний скотч, резинки, липучку. Приводим ссылки на наши детальки в магазине BrickOwl, однако вы можете купить их где угодно, где продаётся LEGO и совместимые наборы.


Шаг 1: строим шасси из LEGO




Мы начали с пластинки LEGO 612, это был минимальный размер, который нас устроил. Можно использовать более крупную, однако мельче уже будет сложнее.

Ширина робота определялась имеющимся у нас в наличии внешним источником питания, поскольку нам была нужна возможность вставлять его на место. Для аккумулятора большего размера потребуется робот большего размера.

Шасси должно быть достаточно высоким, чтобы на нём разместилась и батарея, и плата сверху.

Шаг 2: добавляем колёса
















Каждый сервомотор нужно разместить снизу шасси. В итоге нам понадобились следующие комплектующие:

  • Ось 4 LEGO со стопором (87083)
  • Втулка LEGO (32123 / 42136)
  • Круглый кирпичик LEGO 2 x 2 (3941 / 6143)

Для закрепления двух моторов нужно по 4 штуки каждой из комплектующих. После их закрепления добавляем колесо: LEGO Wedge Belt Wheel (4185 / 49750).

Как и с другими модельками LEGO, вариантов тут масса! У нас получилось с теми комплектующими, что мы перечислили, а вы можете попробовать что-нибудь другое.

Шаг 3: добавляем ролик










Наш ролик позволяет роботу кататься по плоскости на двух моторизованных колёсах, играя роль третьего колеса так роботу легче поворачивать и двигаться.

Для его закрепления потребовались следующие детали:

  • LEGO EV3 Technic Ball Pivots Set 5003245
  • LEGO Technic Cross Block Beam 3 with Four Pins (48989 / 65489)
  • LEGO Technic Brick 1 x 6 with Holes (3894)

В предыдущей версии мы использовали просто круглые детали LEGO в качестве ноги, и на гладкой поверхности это работало нормально. Но не работало на ковре или не гладком полу. Если у вас нет ролика, рассмотрите вариант с такой ногой.

Шаг 4: добавляем датчик расстояния








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

Для датчика мы распечатали совместимый с LEGO корпус на 3D-принтере. Модель выложена на сайте Thingiverse: www.thingiverse.com/thing:3171004

Если 3D-принтера у вас нет, придумайте, как удержать датчик при помощи деталек LEGO, клейкой ленты, резинок, хомутов и т.п. Важно, чтобы он смотрел прямо туда, куда едет робот, когда движется вперёд.

Шаг 5: добавляем плату










Плата мозг всей операции. Она размещается наверху кубиков LEGO, поэтому её крепить легко.

Обычно плата Robotics Board используется совместно с проводящей плёнкой, позволяющей мастерить электрические цепи прямо поверх LEGO, но поскольку у нас тут всего лишь два мотора и датчик расстояния, их можно подключить напрямую к штырькам на плате.

Плату размещаем так, чтобы USB-кабель питания было легко воткнуть. Нам повезло найти в коробке с кабелями очень короткий USB-кабель.

Теперь можно подключать датчик и моторы!

По датчику: разъём echo нужно подключить к контакту 3 на плате, разъём trigger к контакту 5, VCC к 5 В, Gnd к GND. Таким образом датчик будет получать питание и общаться с платой.

Затем нужно подключить каждый из моторов. Это сделать легко коричневые провода на GND, красные на 5 В, оранжевые к контакту D6 для левого мотора и D9 для правого.

Шаг 6: программируем Robotics Board




Перед тем, как робот сможет работать, нужно загрузить код в микроконтроллер. Перед этим убедитесь, что у вас на компьютере установлена последняя версия Arduino IDE.

Свой код мы выложили в репозиторий на GitHub:

github.com/BrownDogGadgets/CrazyCircuits/tree/master/Projects/Avoidance%20Robot

Код простой, в нём много комментариев, чтобы было понятно, что за что отвечает.

Вам также потребуется библиотека NewPing

bitbucket.org/teckel12/arduino-new-ping/wiki/Home

Шаг 7: пускаем робота погулять








Построив робота и загрузив в него код, можно переходить к испытаниям!

Проще всего подключить внешний источник питания и дать роботу возможность ехать вперёд. Если выставить перед ним руку, он должен отодвинуться назад, повернуться и снова поехать вперёд (смотрите, чтобы он не съехал со стола!)

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

Шаг 8: дальнейшее развитие






Если вам интересно развивать этот проект, вот вам вопросы:

что вы узнали, собирая робота?
что повлияло на ваш выбор деталей?
поедет ли робот быстрее, если увеличить ему колёса?

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

// сколько миллисекунд робот отъезжает назадint goBackwardTime = 1000;// сколько миллисекунд робот поворачиваетсяint turnRightTime = 1000;
Подробнее..

Пан или пропант. Роснефть интригует программистов

13.08.2020 10:12:29 | Автор: admin
image
Этой осенью Роснефть организует открытый марафон ИТ-соревнований для программистов. Марафон пройдёт с сентября по ноябрь. Магическое число этого ивента 3: 3 соревнования, 3 задачи, 3 победителя в каждом из конкурсов и 3 призовых фонда.


Итак, в нашем меню для гурманов Хабра: Хакатон трёх городов по машинному обучению, Хакатон для программистов-робототехников и Rosneft Proppant Check Challenge. Машинного обучения, роботов и пропанта хватит на всех!

Стать участниками ИТ-марафона может айтишная братия, достигшая совершеннолетия (18+). Ставим на студентов техвузов, аспирантов, молодых спецов и иже с ними. Регистрация на соревнования уже идёт полным ходом на сайте.

image

По порядку. Хакатон трёх городов по машинному обучению пройдёт 24-25 сентября одновременно в трёх городах: в Уфе, Казани и Самаре. Нашей талантливой молодёжи предстоит разработать алгоритм для построения пути движения на сложной поверхности. Похожие задачи возникают во многих прикладных областях, связанных с геологией, сейсморазведкой, трубопроводным транспортом и нефтепереработкой. Приз за самое оперативное и качественное решение 289 000 рублей*.

Хакатон для программистов-робототехников пройдёт 16-17 октября в Уфе на базе УГАТУ. Задача подразумевает техническое творчество: необходимо разработать роботизированное решение для выполнения операции, связанной с текущей производственной деятельностью по обслуживанию технологического оборудования. При этом мы вооружим участников настоящим роботом-манипулятором и трудолюбивым 3D-принтером. Призовой фонд для любителей роботов 139 000 рублей*.

image

Завершающим мероприятием ИТ-марафона станет международное соревнование Rosneft Proppant Check Challenge, которое стартует в сентябре как для опытных ИТ-специалистов, так и для начинающих (не только из России, но и за пределами нашей необъятной страны). Задача очень серьёзная: определение распределения линейных размеров зёрен пропанта по серии фотографий. В идеале получить уникальный алгоритм для определения характеристик пропанта по фотографии без каких-либо лабораторных исследований. Естественно, целью не является замена исследований как таковых, но в обозримом будущем реализованный алгоритм может быть применен как онлайн метод проверки качества пропанта на линиях производства, что повысит уровень контроля качества выпускаемой продукции. Тут придётся выложиться по максимуму. Но и призовой фонд весьма достойный 1 142 000 рублей*.
* До уплаты налогов
image

Финал ИТ-марафона состоится 28 ноября (дата предварительная) в Москве, где будут подведены итоги Rosneft Proppant Check Challenge, и куда мы пригласим победителей всех трёх хакатонов.

Кого точно не будет в марафоне Роснефти, так это проигравших: участие в масштабном мероприятии нефтяного лидера позволит молодым и амбициозным айтишникам оценить свои возможности на рынке, добавить веса своему резюме, стать претендентами на будущие вакансии и найти единомышленников для обмена знаниями и совместных проектов. Цифровые месторождения, робототехника, программное обеспечение, 3D-технологии, искусственный интеллект всё это, понятное дело, возможно не само по себе. Новую реальность, в том числе для нефтегаза, создают уникальные люди с их уникальными мозгами. Чтобы привлечь внимание этих гениев, надо заинтересовать и вовлечь их в решение действительно важных задач, которые будут впоследствии внедрены на практике.

ИТ-марафон Роснефти это не светские мероприятия для ИТ-специалистов и не ярмарка тщеславия. Это действующий инструмент получения лучших идей и алгоритмов, необходимых для совершенствования существующего наукоёмкого программного обеспечения нефтяной компании.

image

Например, подходы победителей прошлогоднего соревнования Rosneft Seismic Challenge уже подготовлены в виде пилотной версии для промышленного внедрения в сейсмическую часть корпоративного ПО Роснефти. Это ПО позволит автоматизировать огромное количество ручных операций интерпретаторов сейсмических данных, а значит, мы сможем более эффективно распоряжаться интеллектуальными ресурсами, так как появится больше времени для анализа и понимания особенностей геологического строения объекта сейсмосъёмки, что пока машинам недоступно.

Кстати, если вы пропустили прошлогоднюю сейсмическую феерию Роснефти, то по ссылке ролик с финала Rosneft Seismic Challenge.

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

Нам нужны специалисты с нестандартным мышлением, способные решать серьёзные и нестандартные задачи. Вы именно такой(ая)? Тогда бегом к нам.

image

P. S. По этой ссылке источник вдохновения для будущих участников ИТ-марафона видеопожелания финалистов прошлогоднего Rosneft Seismic Challenge
Подробнее..

Наша огромная гордость мирные советские роботы-комбайны убрали первый урожай в южных регионах

11.08.2020 14:11:07 | Автор: admin
image
А ведь в прошлом году это делали senior-разработчики.

Возможно, вы помните, что мы говорили про то, как можно сильно улучшить работу обычного сельскохозяйственного комбайна, если использовать нейросетки для распознавания культур и препятствий и робота для автопилотирования. Всё это (кроме процессоров Nvidia и ещё части железа) наша разработка. А радость в том, что в некоторых южных регионах страны закончилась уборочная страда, и наши комбайны показали себя лучше, чем ожидалось. Слава роботам!

image

В этом году мы поставили несколько сотен блоков из мощного графического ядра (для нейросетей), камер, гидравлических насосов или CAN-модулей для подруливания. Если в прошлом году агропилоты были в опытной эксплуатации, то сейчас речь идёт уже про серийные модели. И они справились.

Более того, они справились лучше, чем мы ждали. Кроме того, в релиз вошли далеко не все фичи. В релизе осталось, по сути, ядро, но одно только это позволило получить очень заметный экономический эффект.

Конечно, обошлось не без сюрпризов. Но давайте расскажу более конкретно, с числами и примерами.

image
Можно разглядеть камеру 2 Мп сверху. NVIDIA TX2 в специальном кожухе и с огромным радиатором монтируется внизу в подкабинном пространстве. Экран в кабине.

image

О чём идёт речь


Сельскохозяйственный комбайн по сложности управления похож на церковный орган. Когда в кабине комбайнёр и помощник, то один рулит (держит кромку), а второй управляет мотовилом, ветрами, барабанами и вообще следит за сбором. Третий в это время может делать отгрузку на ходу в грузовик, едущий рядом. Четвёртый следит за препятствиями. В эпоху СССР в кабине было двое, потом остался один. В итоге он или рулит, или собирает зерно нормально. Стоя на месте, собирать зерно нормально не выходит, поэтому он рулит. Про то, как там всё хитро закручено и почему комбайны регулярно перемалывают людей, врезаются в тракторы и бегущие через поле столбы ЛЭП, наш первый пост.

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

Третья особенность комбайнёры часто предпочитают убирать быстрее с меньшим КПД (поскольку оплата идёт за отгруженные тонны), а не получать максимум зерна с гектара.

В серию вошли фичи удержания кромки (комбайн сам следит за тем, как едет, и сам рулит) и предотвращения столкновений (комбайн внимательно смотрит по сторонам и прогнозирует движение всего, что видит, от людей до тракторов). Тут наработки беспилотного трамвая после езды вокруг ВДНХ очень пригодились. В поле куда спокойнее с препятствиями. Про видеоаналитику есть вот здесь.


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

image

Ещё одно подразделение занимается разработкой железа. У нас есть радар собственной разработки для тепловозов и трамваев, но на комбайне только камеры, потому что оснащать их нужно как можно дешевле. Сложная история это разбор протоколов управления (иногда утерянных вместе с производителем, и тогда нужно реверсить) или же установка гидравлики для подмешивания нашего сигнала в руление. Вычислительные модули на каждом комбайне автономные.


Что случилось в этом году


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

Больше всего мы боялись, что именно конечные пользователи (комбайнёры) станут мешать внедрению, потому что почувствуют угрозу своей работе. Но всё обошлось успешно. Они понимают ограничения автопилота, понимают, что нужны в кабине, понимают, как он их разгружает и что именно они могут делать лучше. У них увеличивается выработка, а значит, увеличивается заработок за уборочную. Причём значительно: примерно на 1015 %. Они хотят работать с нашим роботом в паре. В одном хозяйстве они бились за машины с ним.

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

Вот пара картинок, которые соседние механизаторы увидели из своих машин и потом полезли смотреть, как всё устроено:

image

image
Сидит там, чай пьёт, гад! *** [зачем] теперь механизатор нужен?. Потом смотрели, что робот всё же может далеко не всё, и понимали, что это просто как новый комбайн с парой особенностей. И успокаивались.

Есть числа:

  1. Увеличилась производительность смены по времени комбайнёр не устаёт. Это может показаться численным преимуществом в 1015 %, но там всё гораздо интереснее. Дело в том, что это даёт три дополнительных дня на уборку. Это значит, что если будет плохая погода (проливные дожди, в которые зерно прорастает или осыпается), то урожай не пропадёт, а будет убран целиком с куда большей вероятностью.
  2. Комбайнёр разгружен. Он может смотреть за функционалом комбайна, высотой подъёма жатки и забивкой жатки всё время. Это работа на чувствительность и навык, и раньше она не могла быть качественной из-за постоянного поворота головы в другую сторону, где кромка. Теперь мастера могут вытаскивать из машины 100 % возможной производительности. Это уменьшает себестоимость зерна.
  3. Внимания начало вполне хватать для выгрузки на ходу. Это важно, потому что не нужно ездить куда-то на край поля опустошать бункер в грузовик. Грузовик может ехать за комбайном, а комбайнёр будет сгружать в него урожай меньше простоев, меньше пробег, больше производительность смены.
  4. Поскольку комбайн контролирует режим, наш робот защищает от ошибок. Владельцы сельхозхозяйств говорят, что теперь можно смело сажать менее опытных комбайнёров. Обычно нужно три сезона, чтобы человек набил руку (это примерно 1,6 единицы убитой техники).
  5. Меньше зазоры: раньше промежутки контролировал человек, и они брались с допуском на усталость (к концу смены получались очень большие непрокошенные участки). А роботу плевать, он держит норматив в любое время смены.

Получается механизаторы и руководители в один голос говорят, что работа стала проще. У кого не было перегрузчиков зерна, задумались, чтобы их докупить. В разных хозяйствах разные дневные нормы, обычно это 2025 гектаров. Мы видели, что спокойно ставят 30, и люди на этом не выматываются. Для кого-то это оказалось возможностью сократить парк комбайнов на следующий год: не нужно будет закупать две-три машины. Знаю, звучит очень странно, но два хозяйства (примерно из сотни) сказали, что сделают именно так.

image

Уборочная началась с того, что Герман Греф попробовал в Песчанокопской аграрной группе (на крупной серийной партии) и сказал, что освоил за три минуты. Мы гордимся этим видео. Если президент банка справился, то работяги в полях справятся точно.


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

Не без сюрпризов


К слову о том, как мужики быстро освоили технику. Хозяйство взяло четыре комплекта протестировать, мы приехали, установили их на машины, сделали пусконаладку. Не до конца откалибровали одометрию, потому что для этого нужен дневной свет. Решили сделать с утра. Утром приходят установщики, а мужики на этих машинах на дефолтных настройках уже вышли в поле, всё инициализировали и снимают из кабины, что творит робот. Возможно даже, это был стрим в Инстаграме для остальных на поле. С одной стороны, конечно, хотелось сделать калибровку, а с другой приятно, что мужики всё сами запустили и всё поднялось на настройках по умолчанию.

После первых дней во многих хозяйствах в нашего робота то ли начинали верить, как во всемогущий интеллект вроде Терминатора, то ли просто тестировали на прочность. Так или иначе, в одном хозяйстве решили попробовать убирать ночью. Иногда люди думают, что робот должен думать, как человек. Были несколько разочарованы тем, что ночью он справляется хуже. Дело в том, что в боевом релизе нет ночной уборки: это требует дообучения и немного других алгоритмов обработки данных. Пока мы гарантируем нормальную ночную работу только при достаточно широком освещении (оно такое на иностранных комбайнах трёх-четырёхлетней давности почти везде), а здесь наши испытатели вышли в поле на отечественном комбайне 16-летней давности с узким мерцающим конусом света впереди. Поскольку ночную уборку большая часть хозяйств не практикует, мы отложили эту фичу на следующий год.

Второе место, где были завышенные ожидания, это сложные условия по пыли. Например, комбайны, когда идут друг за другом, поднимают облака пыли. Ветер иногда такой, что порывом тучу пыли сносит на комбайн, который сзади. Поскольку ориентируется он не по дорогущему радару, а по обычной камере, ему не видно, что впереди. Видимость в облаках пыли бывает шесть метров. В такие моменты наша система перестаёт видеть: она сигнализирует механизатору и отпускает управление. Нам даже говорили, что лидар отказал. Но лидара на комбайне нет. Механизаторы ругались: Ну как он не видит?. В итоге именно это почему-то их успокоило насчёт работы. Человек-то помнит и понимает: до комбайна метров 10, мы едем с такой-то скоростью, порыв пронесёт через минуту, ничего не случится, если дольше надо вставать. И Пётр Михалыч впереди точно не встанет. Наверное. Система жизненным опытом не обладает и с Михалычем годами не бухала, поэтому она в таком случае останавливает машину и отпускает управление. Так в очередной раз человеческий интеллект побеждает бота.

В релиз не вошли автоповороты. Это та фича, которая невероятно поражала всех комбайнёров, но она же оказалась самой сложной по тестированию: при огромной ширине жатки нужно строить очень много гипотез про то, что выпадает из поля зрения. На каждой машине свои особенности. Плюс это же требует сложной системы управления с тем, чтобы задавать маршрут заранее или как-то его программировать. Мы за естественное управление: щёлкнул рубильником робота, ведёшь машину, выходишь на поле, начинаешь убирать. Робот говорит: Мужик, дай я порулю, щёлкаете вторым рубильником и он рулит. Нужно повернуть просто делаете это, ко-пилот отпускает управление, потом ищет новую кромку. Когда находит снова просит вернуть управление. Всё интуитивно понятно и просто. В итоге поворачивать между проходами мы доверили людям. С автоматизацией ждём конца тестов на сложном рельефе. Обычно проходка длиной до пяти километров, то есть сами повороты занимают меньше 1 % времени работы комбайнёра.

image

Камера на комбайне одна, потому что приоритет цена. Вторая не очень увеличивает цену, но очень увеличивает нагрузку на вычисления, а вычислительный блок на 4 Tflops большая часть стоимости железа. Камера смотрит влево на жатку. Есть несколько экзотических схем (редко используемых в РФ), когда всё интересное происходит не только слева, но и справа. Вообще у нас две основные системы уборки: загонкой и челноком. Работа загонкой: отрезается кусок поля, и вокруг него всё обкашивают по сужающемуся прямоугольнику или кругу, стремясь к центру. Соответственно мы это делаем против часовой стрелки. Челноком: с одной стороны заезжают и ездят туда-сюда как на принтере. Образуются пустые прогоны между проходками, но зато можно взять участок любой формы. Так вот, для полей сложной формы есть более оптимизированные схемы, которые требуют смотреть в обе стороны. Возможно, в одном из следующих релизов предложим переключение между камерами.

image
Канадская схема.

Потом монтаж. В середине лета в самый разгар карантина наши комбайны впервые с прошлого года вдруг все увидели и заметили. Точнее, наверное, заметили ещё в том году, но заказывать комплекты стали прямо перед уборочной (это связано, возможно, с кредитованием хозяйств с короткими сроками). В итоге мы ездили по стране в условиях карантина, что наложило неповторимый отпечаток на работу специалистов по нейросетям. Установщики где-то сидели 14 дней, где-то ходили чуть ли не в скафандрах, но получилось справиться с 50 хозяйствами (и предстоит ещё столько же).

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

Из-за пандемии сменили поставщика оборудования. Гидроблоки были от немецкого производителя. Они нам в марте сказали: Приходите через четыре месяца. Это была паника, потому что от этого зависела вся история. Нашли российского производителя, они всё поняли, оказались лёгкими на подъём и сделали нам гидравлику. Оперативно, но тоже не без сюрпризов да и не без нервов при постановке задачи, конечно. Но до этого года мы не верили, что это вообще возможно в России.

Что дальше


Роботы убирали злаковые: пшеницу, ячмень, овёс, рожь в южных регионах. Ещё не было серийной эксплуатации на кукурузе и подсолнечнике (это позже по агрономическим срокам). Нам интересны ещё рапс и соя. Рапс это Центральная Россия, пока там ждём уборки. Соя Сибирь, Алтай, юг Сибири, Хабаровский край, это уже совсем скоро.

Сарафанное радио не стоит на месте. За последние месяца полтора пришло около десятка очень крупных холдингов из первых 50 со своими кастомными запросами. Какие-то уже приобретают комплекты для тестирования на эту уборочную. Кто-то делает для нас собственное ТЗ и особые хотелки мы будем думать в межсезонье. Задачи стоят подвязать мониторинг урожайности (комбайн же считает зерно в телеметрии и видит координаты, то есть можно снимать данные по урожайности участков почв до метра), мониторинг работы комбайна (отправка телеметрии в центр). Какие-то хозяйства приходят только к цифре, многим для севооборота важно, чтобы были отмечены критические точки на полях. Важно понимать годовую среднюю урожайность и оценивать каждый год живые деньги. Аналитика нужна для того, чтобы примерно понимать загрузку тракторов и технику: докупить или убавить. Там много нюансов вплоть до заказа ГСМ перед сезоном: это всё неприятные предоплаты. Как сказал крупный руководитель крупного хозяйства: Мы работаем с рынком. Рынок мы не контролируем. Чтобы больше зарабатывать, можем только уменьшать себестоимость. Если не уменьшать нас съедят тупо.

Срок жизни комбайна пишут 1012 лет (но мы часто видим 2005 год, ставили в этом году даже на 2001-й). Мы их все дооснащаем. Потому что, пока лошадка живая, на ней ездят. Когда починка становится дороже стоимости нового, берут новый. Кончается, кстати, тем, что старый комбайн становится донором запчастей для других таких же. Да, это просаженная печень и сломанные ноги, но год-два они работают. Потом всё это сгнивает.

И ещё замечательное отзывы о том, что с этой экономикой комбайн окупается быстрее. Стоит машина, например, 25 миллионов рублей (зависит от производителя и модели). В хозяйстве считают: пять лет на отечественные машины, иномарка окупается за восемь лет. Теперь минус год примерно.

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

Мир без пчел роботизированное опыление мыльными пузырями

26.06.2020 10:22:09 | Автор: admin


Школьный курс биологии научил нас тому, что все живые организмы так или иначе связаны друг с другом. Посудите сами, на поле растет трава, зайцы едят траву, лисы едят зайцев. Но если одно из звеньев этой демонстрационной цепи исчезнет, то пострадают другие: исчезнут хищники зайцы начнут плодиться и съедят всю траву; исчезнет трава зайцам нечего будет есть, следовательно, лисы также будут голодать; исчезнут зайцы трава будет расти бесконтрольно, а лисы будут голодать. Пример достаточно утрирован, но суть доносит. Подобная ситуация касается и пчел, численность которых за последние годы катастрофически упала. Пчелы, как мы знаем, не только делают мед, но и выполняют одну из важнейших операций в природе опыление. Сегодня мы рассмотрим исследование, в котором ученые Си Ян и Эйдзиро Мияко описывают роботизированную систему опыления цветов посредством мыльных пузырей. Из чего состоит система, как именно она работает, и почему мыльные пузыри? Об этом мы узнаем из доклада ученых. Поехали.

Основа исследования


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

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

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

Более современный метод, машинный, позволяет опылять растения быстро и массово. Однако этот вариант очень затратный и менее эффективный, так как внушительная часть пыльцы попадает не туда, куда нужно (остается на самой машине, падает на землю или на листья и т.д.).

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


Дрон-опылитель

Относительно недавно был разработан дрон (Materially Engineered Artificial Pollinators), снабженный липким ионным гелем, покрытым животной шерстью.

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

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

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

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

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

Если объединить эти преимущества с автономностью робота, то можно получить практически идеальную систему опыления.

Раствор для мыльных пузырей



Изображение 1

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

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

В качестве опытного образца были использованы пыльцевые зерна Pyrus bretschneideri (китайская белая груша), а также мыльный пистолет с мотором и батареей, способный производить много пузырей за раз.

Во время опытов был измерен коэффициент прорастания и роста пыльцевых трубок груши.

Для начала было протестировано 5 вариантов поверхностно-активных веществ ( и ):

  • лаурамидопропил-бетаин (A-20AB);
  • лаурилсульфат натрия (E-27C);
  • лаурил-гидоксисульфо-бетаин (A-20HD);
  • сульфат полиоксиэтилен-алкилового эфира натрия (E-D3D);
  • [N-кокоил-(2-аминоэтил)-N-(2-гидроксиэтил)-N-натрийкарбоксиметил] этилендиамин (A- 20YB).

Эти поверхностно-активные вещества были случайным образом выбраны среди многих коммерчески доступных продуктов за их способность образовывать много мыльных пузырей при однократном запуске пузырькового пистолета.

Анализы активности пыльцы продемонстрировали, что все пять поверхностно-активных веществ показали дозозависимое ингибирующее действие на прорастание пыльцы и рост трубки. Коэффициент прорастания пыльцы (G) рассчитывали как G = N / Nt х 100 (%), где N и Nt обозначают количество наблюдений за пыльцевыми трубками с помощью оптической микроскопии и общее количество наблюдений (100 наблюдений). Кроме того, длина пыльцевых трубок измерялась по результатам прямого наблюдения и посредством программного обеспечения ImageJ.

Нейтрализованное поверхностно-активное вещество A-20AB продемонстрировало наивысшую эффективность с точки зрения прорастания пыльцы и роста трубок по сравнению с другими вариантами. Фактически, пыльцевые трубки в чашке Петри, обработанные мыльными пузырями с небольшой концентрацией A-20AB, росли абсолютно здоровыми (1D).

Стоит также отметить, что A-20AB обладал самой высокой способностью к образованию мыльного пузыря среди протестированных поверхностно-активных веществ.

Концентрации A-20AB и пыльцевых зерен оказали непосредственное влияние на образование мыльных пузырей (1E). Логично, что более высокая концентрация поверхностно-активного вещества может помочь создать много мыльных пузырей. А большое количество пыльцевых зерен может помешать образованию пузыря. Например, при концентрации A-20AB от 0.0% до 0.2% пузырьки не могут образовываться с пыльцевыми зернами 110 мг/мл, в то время как в случае от 0.4% до 0.8% и не более 4 мг/мл зерен можно получить как минимум более одного мыльного пузыря. Если же концентрация A-20AB будет 1.0%, а зерен будет 110 мг/мл, то будет образовываться 4-10 пузырей.

В итоге было решено использовать следующие параметры: концентрация A-20AB 0.4% и концентрация зерен 4 мг/мл. При перерасчете получается, что на каждый мыльный пузырь можно загрузить около 2000 пыльцевых зерен.

Чтобы повысить эффективность опыления, следовательно, и коэффициент прорастания, ученые также оптимизировали компоненты раствора мыльного пузыря. Одним из важных показателей, влияющих на рост пыльцевых трубок, является pH. Коэффициент прорастания достиг своего максимального значения (около 30.7%) при pH 7.0.

Более того, умеренное добавление бора, кальция, магния и калия стимулирует прорастание пыльцы и увеличение длины трубки. Особенно кальций, который улучшает прорастание благодаря связыванию кальция с пектатами карбоксильных групп вдоль стенки пыльцы. А остальные элементы (бор, калий, магний) усиливают этот эффект.

Добавление в мыльный раствор H3BO3 (060 мд; мд частей на миллион) привело к росту пыльцевой трубки до 1187 мкм, что в 1.3 раза больше, чем в контрольной группе (без H3BO3).

Подобная ситуация обстояла и с MgSO47H2O, который существенно не улучшал прорастание пыльцы, но стимулировал удлинение трубки при низкой концентрации (0.1 мМ), в пределах которой длина трубки достигала максимального значения 1127 мкм, что в 1.3 раза выше по сравнению с контрольной группой.

Также было обнаружено, что концентрация CaCl2 в диапазоне 0.12.0 мМ значительно улучшает коэффициент прорастания пыльцы и рост трубки (1152 мкм при 1.0 мМ CaCl2, что в 1.3 раза больше, чем в контрольной группе). KCl при концентрации 1 мМ сопутствовал удлинению трубки до 1232 мкм, что в 1.4 раза больше, чем в контрольной группе.

Желатин представляет собой водорастворимый белок, который состоит из большого количества глицина, пролина и гидроксипролина. Эти компоненты могут играть существенную роль в прорастании пыльцы и удлинении трубки. Добавление 0.8% желатина в раствор повышает коэффициент прорастания трубки до 50% (1363 мкм).

Для повышения стабильности мыльных пузырей был дополнительно использован небольшой процент гидроксипропилметилцеллюлозы (ГПМЦ). Добавление в раствор 0.2% ГПМЦ также слегка улучшило прорастание пыльцевых семян, но на рост трубки особого влияния не имело.

Толщина мыльного пузыря (его мыльной пленки) определяется по формуле:
= (M ) 4R2
где толщина мембраны; М масса (примерно 7.7 мг; плотность (примерно 0.99 г/см); R радиус (1.6 см).

Если аппроксимировать как 3.14, то будет равно 2.4 мкм, что является разумным значением для обычного мыльного пузыря в диапазоне толщин 110 мкм.

Ручное опыление с помощью мыльных пузырей


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


Изображение 2

В случае оптимизированного раствора коэффициент прорастания составил 49% (), а длина трубки составляла 1221 мкм (), что в 1.9 и 1.5 раза больше, чем в случае с неоптимизированным раствором (т.е. без каких-либо дополнительных веществ и элементов).

После 3 часов опыления показатели упали до 28% и 990 мкм. Однако даже они были в 5.9 и 1.9 раза выше, чем спустя 3 часа опыления неоптимизированным раствором. Следовательно, внедрение в раствор дополнительных элементов имеет значимое положительное влияние на рост семян.

Чтобы продемонстрировать возможности нового метода опыления, ученые провели наблюдения, где использовалось различное количество (0, 1, 2, 5, 10, 20 и 50) мыльных пузырей на цветках груши (2C). После инкубации в течение ночи при 25 С пестики цветов срезали и окрашивали анилиновым синим (специальный краситель, используемый в гистологии).

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

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

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

В результате коэффициент образования плодов в контрольной группе составил всего 58%, а в тестовой (с мыльными пузырями) более 95%. Эти показатели говорят не только о том, что опыление посредством мыльных пузырей значительно эффективнее опыления вручную, но и том, что этот метод позволит увеличить объемы производства.

Роботизированное опыление с помощью мыльных пузырей


Опыление мыльными пузырями вручную хоть и эффективно, но не идеально, ибо ему не хватает автономности. Именно потому следующим этапом исследования стало испытание роботизированного варианта опыления пузырями.

Одной из первых проблем, с которыми можно столкнуться во время использования дронов, это воздушные потоки от винтов аппарата. Использованные в ручном опылении мыльные пузыри крайне быстро лопались, когда их пытались использовать в сопряжении с дронами. Следовательно, необходимо было повысить их стабильность. Для этого в раствор было добавлено 2% ГПМЦ. В результате были получены стабильные пузыри (2% ГПМЦ и 1% A-20AB) диаметром около 2 см ().


Изображение 3

Забавно, что эти пузыри не только выдерживали воздушные потоки от винтов дрона, но и достаточно долго (около 10 минут при 25 С) спокойно располагались на цветках без распада. Некоторые из пузырей оказались еще более выносливыми, так как могли прожить почти 5 часов и выдержать нагрузку сжатия до 0.03 Н. Толщина мембраны пузырей из теста на ручное опыление была 2.4 мкм, тогда как у стабилизированных толщина составила 4.1 мкм, что объясняется внедрением дополнительного ГПМЦ в раствор. При этом активность прорастания зерен сохранялась на достаточно высоком уровне.

Кинематическая вязкость приготовленного раствора мыльного пузыря составила 7530 сСт*, а плотность 1.023 г/см.
сСт* (сантистокс): 1 сСт = см/с.
Относительно высокая вязкость раствора имела положительный эффект на дисперсию пыльцы, что было доказано проведением оптической микроскопии.

Ученые также подсчитали количество пыльцевых зерен разных растений на каждом пузыре: 269 частиц L. japonicum; 304 частицы R. pulchrum; 312 частиц C. persicifolia).

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

Коэффициент успешного опыления отличался у разных цветков. Так у L. japonicum () он составил 90%, потому что цветки этого растения больше, чем у других протестированных.

В сопряжении с дроном также был использован автоматический пузырьковый пистолет (3D), который генерировал 5000 пузырьков в минуту. На роль дрона-носителя был использован самый обычный и коммерчески доступный беспилотник, к которому прикреплялся пузырьковый пистолет.

Движения дрона контролировались автоматической системой, оснащенной глобальной навигационной спутниковой системой (GNSS). При подлете к цветкам на расстояние в 2 м производился пузырьковый обстрел под углом 70-80 градусов. Скорость воздушных потоков от дрона составляла 4.5 м/с, когда он стабильно зависал в воздухе. При движении (2 или 4 м/с) она увеличивалась до 5.8 и 8.7 м/с. Из-за этого мыльные пузыри моментально лопались при контакте с цветками. Анализ последующих показателей прорастания показал, что оптимальной скоростью движения дрона является 2 м/с. В таком случае коэффициент прорастания будет порядка 90%.

Для более подробного ознакомления с нюансами исследования рекомендую заглянуть в доклад ученых.

Эпилог


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

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

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

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

Пятничный офф-топ:

Разные виды пчел защищают свой дом от врагов разными методами. Гигантские пчелы (Apis dorsata) формируют волну, словно болельщики на стадионе.

Благодарю за внимание, оставайтесь любопытствующими и отличных всем выходных, ребята! :)

Немного рекламы


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Подробнее..

Штурм Марса 2020

30.07.2020 12:15:48 | Автор: admin


В 2020 году сразу три страны замахнулись на достижение Красной планеты. Три ракеты, семь космических аппаратов, множество научных приборов отправляются к Марсу чтобы лучше узнать его атмосферу, поверхность и недра. Ученые хотят лучше узнать какой была соседняя планета в прошлом и понять, что ожидает её в будущем.

С надеждой и спектрометром
Первый запуск к Марсу в этом июле совершила ракета Японии. Однако космический аппарат, отправленный ею, принадлежал Объединенным Арабским Эмиратам. Произведен же он был в США на средства и при значительном участии специалистов ОАЭ. Аппарат назвали Al Amal Надежда или Hope на английском.



Al Amal это орбитальная автоматическая межпланетная станция. Она должна достичь Марса к февралю следующего года, когда ОАЭ будут отмечать 50-летнюю годовщину своей независимости. Научная программа Al Amal предполагает наблюдение за атмосферой Красной планеты с высокоэллиптической орбиты, чтобы обозревать не только поверхность, но и окружающее пространство. Ученые ОАЭ надеются понять с какой интенсивностью и под действием каких причин Марс теряет свою газовую оболочку, и наблюдать годовые погодные изменения.

Al Amal оборудована тремя научными приборами, два из которых спектрометры: инфракрасный и ультрафиолетовый. Третий прибор фотокамера, которая должна показать нам новые панорамы Марса с разных высот от 20 тыс км до 43 тыс км. Камера оснащена набором цветных фильтров, чтобы не только увидеть планету в естественном цвете, но и получать дополнительную информацию в ультрафиолетовом и инфракрасном диапазоне. Научные приборы разрабатывались в США и созданы с учетом актуальных вопросов в изучении Марса, это отличает арабскую программу исследований от, например индийской Mars Orbiter Mission, где приборы больше испытательного характера и не дотягивают до мирового уровня.



Учитывая плотное сотрудничества ОАЭ с США, вероятно Al Amal также будет помогать в передаче данных на Землю с американских марсоходов.

Для Эмиратов запуск марсианской программы вопрос не только престижа. Таким образом страна богатая нефтью пытается диверсифицировать экономику, развить собственную космическую отрасль, которая могла бы вступить в конкуренцию на мировом рынке. ОАЭ уже запустили своего космонавта при помощи Роскосмоса, совместно с Южной Кореей разработали четыре околоземных спутника. На территории страны открыт Космический центр им. Мохаммеда бин Рашида, и построена станция приема и передачи космических данных. Арабские специалисты участвуют в российско-американском наземном изоляционном проекте Sirius, для исследований условий полета человека на Марс.



Марс выступает для Эмиратов ярким поводом для привлечения инженерных кадров в космонавтику страны, студентов мотивирует к получению научных специальностей, а всех арабов к научной и технической деятельности. Для государства Марс нужен чтобы подчеркнуть ориентацию ОАЭ на научно-техническое развитие, а не простое прожигание нефтяной ренты.

Я спросил у неба
Следующая после японской ракеты к Марсу стартовала также дальневосточная из Китая. Тяжелая ракета Long March 5 относится к новому поколению китайских ракет, экологически более чистая, на кислород-керосиновых и кислород-водородных двигателях.

По сути это такая китайская Ангара, которая уже активно летает. В будущем ожидается, что носители этой серии запустят космический аппарат к Луне для добычи грунта, и займутся выведением китайской многомодульной космической станции. Новые космические корабли Поднебесной должны также запускаться на Long March 5.



Марсианским запуском Китай открывает программу изучения Солнечной системы. Поэтому название Tianwen-1 (Вопросы к небу) предполагает, что следующие аппараты полетят уже к другим планетам.

Tianwen-1 это целых три космических аппарата одновременно. Два из них орбитальный аппарат и марсоход займутся выполнением научных задач, а у спускаемой платформы будет только техническая работа доставка марсохода на поверхность Красной планеты.



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

Научные приборы как орбитального аппарата, так и марсохода во-многом повторяют прежние исследования, поэтому не обещают большой новизны и сенсационных открытий. С точки зрения науки, китайские исследования интересны прежде всего георадаром марсохода. Такого на Марс ещё не высаживалось. Радар должен просветить недра планеты на глубину до 100 м. Любопытна также предполагаемая область посадки Равнина Утопия. Её расположение и характер поверхности позволяет предполагать, что когда-то это было дно марсианского океана, и в грунте могут до сих пор сохраниться значительные запасы водяного льда.

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



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

Настойчивость Марс берет



30 июля 2020 года ожидается третий, финальный, марсианский старт этого лета американский. NASA отправляет один исследовательский марсоход, на борту которого размещается небольшой дрон-вертолет. Мягкую посадку этой паре обеспечит система мягкой посадки SkyCrane, которая хорошо себя показала в 2012 году при доставке марсохода Curiosity.



Новый покоритель Марса получил имя Perseverance (Настойчивость) в ходе всемирного голосования. Это будет самый тяжелый и самый сложный аппарат, который когда-либо исследовал Красную планету более одной тонны. При этом масса научного оборудования у него меньше чем у Curiosity. Такая разница вызвана тем, что Curiosity это лаборатория, которая должна анализировать грунт и атмосферу на месте, т.е. на Марсе. Главная же задача Petseverance собрать образцы для доставки на Землю, а оборудование для коллекционирования занимает значительное место и добавляет массы.

Марсианский вертолет Ingenuity (Изобретательность) создан по соосной схеме и оснащается только фотокамерой, связь с Землей будет через марсоход. Задача дрона только в испытании технологии автономного полета на другой планете. Хота Марс имеет очень разреженную атмосферу, но сила притяжения ниже чем на Земле и испытания в вакуумной камере показали возможность полета Ingenuity.



За исключением сбора образцов, Perseverance это Curiosity на максималках, у него более прочные колеса, в полтора раза больше фотокамер, все они теперь цветные, лазерный спектрометр для дистанционного анализа грунта еще точнее. Глубина сбора образцов у марсоходов совпадает: около 5 см. Разница только в том, что Curiosity собирает раздробленный буром реголит, а Perseverance добывает керн, т.е. неразрушенный цилиндр породы, который и отправляется в упаковку для доставки.

У Perseverance тоже будет проникающий радар, как и у китайского марсохода, но его дальнобойность всего 10 метров, а место посадки не такое интересное для изучения недр. Зато для геологов и астробиологов место выбрано самое перспективное древняя речная дельта в кратере с сербским названием Езеро. Судя по всему там действительно было озеро, и если оно было обитаемо, признаки жизни должны быть найдены в собранных образцах в земных лабораториях.



Доставка марсианских образцов на Землю произойдет когда-нибудь потом. Это будет самая сложная автоматическая операция в космосе, где, кроме Perseverance, будут задействованы стартовая ракета, марсоход-транспортировщик и орбитальный возвращаемый аппарат. NASA планирует программу совместно с Европейским космическим агентством в ближайшие десять лет.

Нельзя не упомянуть и русский след в этом проекте изучения Марса: Perseverance стартует на ракете Atlas V, первая ступень которой оснащена двигателем РД-180 российского Энергомаша. В проекте Curiosity значение России было выше: там, помимо ракетного двигателя, был прибор DAN для поиска воды в грунте, а радиоизотопный термоэлектрический генератор заправлен плутонием-238 от Росатома.



Пуск Perseverance назначен на сегодня в 14:50. Трансляцию с русскоязычными комментариями можно посмотреть здесь, начало в 14:00 МСК:

Подробнее..

Роботы на карантине

04.08.2020 12:21:41 | Автор: admin
Тут недавно мужики на Хабре рассказывали про Flipper и отладку на осциллографе по видеосвязи.

И это, конечно, победа вне конкурса! Но и у нас был интересный опыт отладки робота, находящегося в 2000 км от нас в лодочном гараже на норвежском побережье. Под катом рассказ о том, как мы делали зрение и правили облачные мозги роботам во время карантина удаленно:



Весной мы сделали прототип всей системы удаленного управления по 3D стриму и обучения роботом на двуруком YuMi и познакомились норвежской компанией, чье решение нам очень кстати для трансляции 3D потока Realsense камер Aivero. Так что после не самого простого рабочего периода планы казались безоблачными: слетать в Италию на месяц зимы с семьей, оттуда поездить по выставкам робототехники в Европе и закончить все остановкой на пару недель в городе с прекрасными фьордами в округе Ставенгер, где и обсудить интеграцию 3D кодеков в нашу систему и попробовать убедить Aivero собрать пару роботов вместе.

Что могло пойти не так в этом замечательном плане

Сидя 2 недели на карантине после возвращения (не без приключений) из итальянского локдауна, пришлось сдуть пыль со своего разговорного и письменного английского и исполнять вторую часть плана уже в Zoom-е, а не в антураже фьордов.

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

Подключаем разных роботов


Напомню, мы сделали обучение роботов по записям удаленного управления. Т.е. робот подключается к интернету, к нашему облаку и начинает слать 3D картинки и показания датчиков. Обратно получает команды и исполняет их. В такой логике наша задача научить ML процессор вести себя также, как оператор. 3D нужно, чтобы отрисовать оператору сцену в виртуальной реальности. Это удобно, да и ML становится намного точнее при хватании объектов, когда есть карта глубин.

По задумке, мы можем подключать разнообразных роботов к нашему облаку, но создавать их все разнообразие самим это очень тернистый путь. Мы же фокусируемся на их мозгах, на обучении.
В итоге договорились с Aivero о создании универсального однорукого робота с 3D глазами их силами, назовем его Юнит, а весь облачный Robotics достается делать нам.

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

Подумали пару недель, потестировали гипотезы пару месяцев и вот, что получилось (версия с Jetson AGX в основании и другой обзорной камерой, чем на заглавной):



И прожектор поближе:



Состав:

  • Jetson NX
  • 2 3D камеры Realsense (одна обзорная, другая для рабочей области)
  • прожектор
  • вакуумный насос, если нужен
  • роборука (Eva / UR / ABB YuMi) с вакуумным или механическим захватом
  • интернет WiFi или проводной



Такая телескопическая стойка с вычислителем и вакуумным насосом в основании ставится рядом с рабочей областью робота, подключается к интернету (например по QR коду к WiFi), и сразу начинает решать поставленную задачу практически без настройки.

Здесь можно сразу оценить и стоимость. Самая доступная роборука Eva 8000 Евро (в России не поставляется), а UR10 уже обойдется почти в 50 000 Евро, но тут нужно отметить, что UR заявляет значительно большую надежность, так что в долгосрочной перспективе может оказаться и не сильно дороже. Да и дешевеют они последнее время. Остальной комплект обходится еще около 2000 Евро.

ABB YuMi IRB 14050


Мы раньше имели дело с двуруким YuMi, но здесь попробовали новую версию IRB14050, которая по сути просто одна оторванная рука.


Кратко, чем понравилась:

  • точность и механическое качество исполнения
  • высокая чувствительность к коллизиям и демпферы на суставах

и не понравилось:

  • тяжело удаленно разрешать коллизии и нештатные ситуации
  • малый угловой ход некоторых суставов делает траектории довольно сложными для, казалось бы, простых движений, которые для кинематики других 6-ти координатных рук не представляют сложности
  • малая грузоподъемность в сравнении с аналогами
  • дополнительно требует заливать (а порою и отлаживать) программу на своем языке программирования от ABB, которая обрабатывает команды по TCP от компьютера

И не кратко.

Здесь мы потратили больше всего времени. Рецепт, как запускать, совсем не простой:

  1. Возьмите машину с Windows, т.к. иначе не получится установить RobotStudio от ABB.
  2. Идем в репу https://github.com/BerkeleyAutomation/yumipy и добываем там RAPID (это язык программирования от ABB) файл для загрузки в робота (у нас одна рука, так что левая или правая подойдут одинаковые), заодно переделываем python API для однорукого YuMi IRB 14050 вместо двурукого IRB 14000.
  3. Если хотим планирование траектории, то находим IRB14000 urdf файл описания геометрии робота и его кинематики для ROS moveit. Удаляем одну руку и корпус робота IRB14000, так и получаем IRB14050.
  4. Забираем из планировщика ROS moveit нужную траекторию и с помощью слегка модифицированного Python API запускаем.
  5. В случае коллизии или иных происшествий запускаем FlexPendant for OmniCore, сбрасываем состояние и визуально разрешаем проблему.

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

Eva




Кратко, чем понравилось:

  • Конечно, цена
  • API простое и лаконичное

И минусы:

  • нет детекции коллизий (заявлено в релизе осенью)
  • точность позиционирования над ней еще нужно поработать производителю, но нам хватает

Конечно, простота управления подкупает:

pip install evasdk 

и

import evasdkeva = evasdk.Eva(host_ip, token)with eva.lock():    eva.control_wait_for_ready()    eva.control_go_to([0, 0, 0, 0, 0, 0])

И роборука вжух! и исполняет.

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

И в целом, Automata (производитель Eva) большие молодцы! Надеюсь у них получится расти и развиваться на рынке робототехники и дальше, делая роботов сильно доступнее и проще, чем они есть сейчас.

UR



Понравилось:

  • отлично сделана по механике и высокая точность
  • большие диапазоны углов в суставах, что делает планировку траектории заметно проще
  • коллизии можно разрешить в VNC Viewer, подключившись к компьютеру роборуки
  • хорошо отлажена в инфраструктуре ROS

Минусы:

  • устаревшая ОС на контроллере UR, где-то уже полтора года нет никаких обновлений безопасности
  • все-таки не самый современный способ коммуникации, хотя он неплохо прикрыт доступными открытыми библиотеками

Из питона роборука доступна в двух основных сценариях:

  1. Установить https://github.com/SintefManufacturing/python-urx и наслаждаться. Немного длиньше листинг, чем в случае evasdk, так что не буду приводить. Также есть известные проблемы совместимости с новыми роборуками, судя по issue-трекеру. Кое что пришлось так же поправить под себя, т.к. не все режимы перемещения были имплементированы в библиотеке, но это тонкости.
  2. Пойти по особому ROS-до (https://github.com/ros-industrial/universal_robot). Для тех, кто в ROS как рыба, тут все просто: немного магии с загрузкой некого скрипта в тушку UR и вы можете использоваться moveit (очень полезный кусок ROS, который позволяет, например, планировать траекторию в условиях наличия препятствий).

Мы стараемся избегать ROS, т.к. частично его функции (брокер сообщений) выполняет rabbitmq в нашей системе, да и происходит серьезное усложнение стека используемых технологий. Так что для случая, когда нужно объезжать препятствия, мы инскапсулируем ROS в микросвервис на серверной стороне.

А теперь трюк!

Чтобы вы понимали, UR это:



Т.е. любой чих разрешается на тач-панели робота. И чтобы не 5 раз на дню мучать нашего коллегу из Aivero, гоняя в лодочный гараж, нужно как-то влезть туда удаленно.

Оказалось, что на UR контроллере установлен linux (и кстати не самый слабый x86 процессор).
Набираем ssh IP user: root, password: easybot.

И вы в Debian Wheezy.

Так что берем и ставим VNC server и обнаруживаем себя полным хозяином робота! (Тут надо только заметить, что Wheezy уже 2 года как не обновляется и просто взять и поставить vnc сервер у вас не получится из-за устаревших регистров. Но тут есть ссылка на magic file, который позволяет это сделать).

Кстати, в Universal Robots, когда мы им показали наше демо, сказали, что подобное удаленное управление требует новой процедуры сертификации безопасности. Справедливо. Очень любопытно, как в Smart Robotics с этим обстоят дела в целом. Не могу представить, чтобы переменные целеуказания от компьютерного зрения могли бы быть 100% безопасны для окружающих.

Пришло время учить робота хватать коробочки


Напомню, мы же показываем что делать роботу в VR:


Т.е. у нас по каждому перемещению записано, как выглядела сцена и что за команда была, например такая:

{op": "pickup_putdown_box", "pos1": [441.1884, -112.833069, 151.29303],"pos2": [388.1267, 91.0179138, 114.847595],"rot1": [[0.9954941, 0.06585537, -0.06822499], [0.0917332, -0.851038456, 0.517028868], [-0.0240128487, -0.52095747, -0.85324496]],"rot2": [[0.992139041, 0.102700718, -0.07150351], [0.100485876, -0.99436, -0.0339238755], [-0.0745842, 0.026472155, -0.996863365]],"calibration": [[-0.01462146, 0.9814359, -0.191232175, 551.115051], [0.9987302, 0.0051134224, -0.0501191653, -6.613386], [-0.0482108966, -0.191722155, -0.9802644, 771.933167]],"box": [[474.331482, -180.079529, 114.765076], [471.436157, -48.88102, 188.729553], [411.868164, -180.27713, 112.670532], [476.105164, -148.54512, 58.89856]],"source": "operator"}

В общем этого нам достаточно, чтобы обучить сеточки определять bounding box объекта в пространстве и где его хватать.

Так что сидим полчаса и показываем роботу как жонглировать 4-мя типами коробок, получаем около 100 примеров. Нажимаем магическую кнопку ну точнееsudo docker run -e INPUT_S3_FOLDER= OUTPUT_S3_FOLDER= rembrain/train_all_stages:dev. И идем спать. С утра докер отправляет сообщение ML-процессору обновить веса, и мы с замиранием сердца (роботов хоть и дали бесплатно тестировать производители, стоят денег прямо серьезных), запускаем и



Надо сказать, что ни один робот при отладке не пострадал. Я думаю исключительно благодаря невероятному везению.

Однажды мой двухлетний сын подошел и решил поиграться с VR трекером. Залез на стул, взял его с подоконника И отправил UR10 в невообразимое путешествие, отодвинув штангу с камерой и заведя роборуку в довольно хитрое положение. Так что пришлось добавить немного предохранителей в управление. И вторую обзорную камеру, т.к. иначе порою просто не видно куда уехала рука и можно ли ею двигать.

А если без шуток, то точность детекции таких не сложных коробок в наших тестах превышала 99.5% даже при небольшой обучающей выборке из нескольких сотен примеров. Основной источник проблем здесь уже не компьютерное зрение, а сопутствующие сложности: например, какие-то аномалии в исходной укладки объектов, или непредусмотренные помехи в кадре. Но затем мы и делаем обучающуюся систему с операторами в цикле, чтобы быть готовым ко всему, разрешая проблемы, не вовлекая живых людей на месте.

Еще об одном алгоритме, о том, что меня в backend и промахе в UI frontend-е
Проблема плотной упаковки

Иногда bin-picking применения соседствуют с задачей bin-stuffing, ну т.е. разумной упаковкой в корзину. В случае одинаковых объектов это не проблема. Но если мы говорим даже о коробочках разного размера, это реально сложная задача упаковки.

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

Таким образом, мы переводим трассируем луч по пикселю карты глубин и заполняем воксельный объем корзины. А затем ищем самое лучшее место, где расположить новую коробку (на деле самую нижнюю точку, ближнюю к одному углу корзины). Как-то так:



Иногда получается ерунда, т.к. не под частью коробки просто нет опоры, например как здесь:



Backend

Мы придерживаемся прежней схемы, когда каждому роботу отдали по серверу ретрансляции на websocket-ах, как на этой схеме:



Единственное, сервис Coordinator стал разрастаться в кластер с кучей сервисов внутри. Например, свое место там заняли брокер сообщений Rabbit и mongoDB, сборка логов, как у людей (и это кстати правда удобно в распределенной системе). Так же пришлось добавить активный сервис мониторинга, который активно проверяет целостность всей системы и отвечает о текущем статусе каждого робота.

Но и в целом, конечно, работы по backend-у так много, что позаниматься ML частью системы уже за счастье.

И вот у нас слишком сложный UI

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

Мы привыкли к AWS console, Yandex console, начинает казаться, что и для управления роботами нужно вот именно это, разве что для телефона, а не на десктопе. Не так то и удобно монтировать робота и бегать к компьютеру или ноутбуку.

Казалось, что получилось невероятно круто и понятно.

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



Однако, нет потока. Тесты показали, что все несколько контринтуитивно и UX нужно менять. Вот он новый интересный опыт преодолеем и это. А пока что назовем текущий UI robot Console и оставим его для себя.

Что дальше


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

Параллельно ищем новые практические применения помимо понятного и популярного bin-picking (лично я мечтаю о применении роботов на стройке).

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

Так что карантин пошел на пользу!
Подробнее..

Издательподписчик для распределённых отказоустойчивых бортовых систем реального времени в 1500 строк кода

28.07.2020 18:07:12 | Автор: admin

Сап, котятки.


Я пришёл рассказать о проекте UAVCAN новом сетевом стандарте для организации взаимодействия узлов и компонентов современных транспортных средств с высоким уровнем автономности/автоматизации. Название является акронимом от Uncomplicated Application-level Vehicular Communication And Networking (несложные бортовые сети и коммуникации уровня приложения).


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



Конъюнктура


Первый блин проекта был заложен в 2014-м. С самого начала это был эксперимент в минимализме: возможно ли в разработке сложных распределённых бортовых систем опираться на мощные абстракции, избегая при этом роста сложности реализации и связанных с ним трудностей валидации и верификации.


Мы наблюдаем быстрый рост сложности бортовых систем, связанный с развитием функциональных возможностей транспортных средств (особенно беспилотных) в целом, и систем автоматического управления в частности. Когда мы говорим "бортовая система", мы подразумеваем совокупность автоматики, необходимой для реализации базовых функций транспорта; например, БСУ/ЭДСУ летательных аппаратов, всевозможные ЭБУ в автомобиле, полётный контроллер в дроне или космическом аппарате, сенсоры (радары, камеры), датчики, исполнительные механизмы, и т.п.


Бортовая электроника (электрика) автомобиля конца 20-го века может быть исчерпывающе описана довольно тривиальной схемой; вот, например, схема ВАЗ 21099:



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


Сегодняшние транспортные средства являются в значительной мере программно-определяемыми в том смысле, что существенная часть функциональности и поведений задаётся не столько электрической/механической конфигурацией, сколько программным обеспечением (ПО), что порождает соответствующий перекос концептуальной сложности в сторону бортового ПО. В контексте космических аппаратов это обстоятельство было подмечено ещё инженерным коллективом NASA, работающим над программой Аполлон. В равной мере это применимо и к современным автомобилям (показательна известная история ранней Tesla Model 3, где проблемы антиблокировочной системы были исправлены удалённым накатыванием обновлений без участия владельцев), и к летательным аппаратам (в особенности с ЭСДУ).


Абстракции позволяют нам обойти когнитивное ограничение на количество сущностей, единовременно удерживаемых в сознании. В теории систем этот принцип известен как "чёрный ящик". Любой человек, хоть раз державший в руках компилятор, знает, как это работает: сложные подсистемы описываются не непосредственно, а в виде ограниченных функциональных блоков со строго определённым интерфейсом, скрывающим их реализацию. В рамках дискурса общих информационных технологий безусловно делается предположение, что человеку, мыслящему на определённом уровне абстракции, нет нужды вникать в специфику реализации задействованных на данном уровне блоков, иначе нарушается принцип чёрного ящика. Это предположение не является безусловно корректным если речь идёт о критических системах, где необходима высокая живучесть/отказоустойчивость. Объясняется это тем, что второстепенные функциональные особенности различных компонентов в совокупности могут порождать потенциально опасные непредусмотренные поведения (как это демонстрируют былинные отказы Mars Climate Orbiter, Airbus A400M в Севилье, Ariane 5, и т.п.).


Растущая сложность бортового оборудования отражается в развитии стандартов безопасности. Более сложные системы создаются композицией более сложных подсистем, что формирует спрос на конкретные гарантии поведенческих характеристик компонентов (если у нас есть, скажем, радар, мы хотим точно знать, в каких условиях и как он будет работать, как его характеристики коррелируют с параметрами среды, и вообще неплохо бы убедиться, что его разработчики мышей ловят). Примером ответа индустрии на этот запрос будет концепция Safety Element out of Context (SEooC), введённая в новом автомобильном стандарте ISO 26262. Строго говоря, тема стандартизации не имеет прямого отношения к нашему сугубо техническому проекту, но она отражает общие тренды в индустрии к переходу к композициям более сложных компонентов и как следствие, более сложных интерфейсов.


Холистический анализ сложных систем невозможен по очевидным причинам; фрагментарные же подходы в области высокой надёжности усложняются необходимостью детальной формализации и верификации поведений функциональных блоков с целью минимизации рисков возникновения непредусмотренных поведений при их интеграции. В этом свете выглядит целесообразным поиск методов построения чёрных ящиков, который предоставлял бы удобные инструменты создания абстрактных интерфейсов, и в то же время привносил бы минимальные накладные расходы на формализацию/верификацию блоков и их композиций.


Здесь следует внести разъяснения касательно специфики реального времени и высокой надёжности для читателя, не являющегося специалистом в этой области. Разработчик прикладного ПО, веб-сервера или типичной бытовой встраиваемой системы (вроде компьютерной периферии) сочтёт покрытие тестами достаточной гарантией адекватности ПО. Проблемы реального времени в сложных системах такого рода возникают редко, а когда они возникают, цена временных отклонений обычно достаточно мала, чтобы можно было пренебречь жёстким ресурсным планированием или формальным анализом планировки задач (schedulability analysis). Процессы жёсткого реального времени обычно либо просты, либо цена ошибки несущественна (в качестве примера бытового жёсткого реального времени можно принять логику работы печатающей головки струйного принтера, привод экструдера 3D печати или аудиокодек). Эмпирические методы в целом преобладают над формальными; повсеместно применяется бенчмаркинг и амортизационный анализ. Если продукт показывает приемлемые результаты в подавляющем числе случаев, он принимается соответствующим требованиям; более строгие подходы обычно нецелесообразны финансово.


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



Говоря о балансе проектировочных затрат и рисков, интересная тенденция сейчас имеет место в космической отрасли: как метко отмечает Casey Handmer, наблюдаемое ныне снижение стоимости вывода космических аппаратов (КА) сдвигает оптимальный баланс в сторону решений с менее строгими гарантиями безопасности и менее затратной разработкой. В случае же БПЛА наблюдается обратный тренд ввиду распространения более ответственных применений и увеличения числа аппаратов в эксплуатации.


Различные исходные предпосылки при создании систем разного уровня функциональной безопасности проявляются в, порою, радикально различных технических свойствах их компонентов и предпочитаемых методах их создания. Скажем, бортовая коммутируемая сеть современного авиалайнера (как AFDX) предоставляет гарантированные минимальные кривые обслуживания, и, как следствие, для хорошо спланированного трафика отсутствует потребность в подтверждении доставки. Для типичной коммерческой системы эта логика чужда, ведь свойства сети и её загрузку никто не гарантирует. Асимптотический анализ в рамках жёсткого реального времени сфокусирован на худшем случае нежели амортизированном случае, что порою может радикально менять подходы на всех уровнях проектирования.


Различия в предпосылках также объясняют, почему прекрасно зарекомендовавшие себя в ИКТ решения (тысячи их: очереди сообщений, фреймворки, сетевые стеки с TCP/IP во главе, распределённые БД, операционные системы, etc.) обычно непригодны для ответственных применений и почему безопасные системы часто отдают предпочтение специализированным технологиям.


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


Обычный порошок


Картина положения дел в индустрии будет неполной без хотя бы поверхностного рассмотрения существующих технологий построения отказоустойчивых распределённых систем реального времени. Решения эти обычно интересны технически, созданы с оглядкой на многолетний опыт и проверены временем в реальных продуктах. Однако, тем не менее, горшки CiA/SAE/RTCA/EUROCAE/AUTOSAR/OMG/etc. обжигают отнюдь не боги.


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


1. Аналоговые схемы


Просто и прямолинейно. Электрические, пневматические, гидравлические, механические средства непосредственного взаимодействия между узлами и компонентами попадают в эту категорию. Приведённая ранее схема ВАЗ 21099 тоже отсюда.


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


2. Логическая шина


Шина данных есть довольно общий термин. Мы здесь под этим подразумеваем модель взаимодействия, где атомарной единицей данных является структура из логически связанных сигналов/параметров, и внимание проектировщика в значительной мере сосредоточено на определении этих структур и логики их обмена.


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


Начнём с первого. Если компонент А непрерывно сообщает компоненту Б больше одного параметра, имеет смысл временное разделение (мультиплексирование) сигналов. Такое уплотнение позволяет наращивать число параметров при постоянном числе физических межкомпонентных соединений, что удешевляет/облегчает конструкцию. Практическим примером будет ARINC 429 древний и незамысловатый авиационный протокол, реализующий обмен фиксированными 18-битными словами с щепоткой метаданных по выделенным (некоммутируемым) линиям. Типичная топология выглядит так:



Диаграмма адаптирована из "The Evolution of Avionics Networks From ARINC 429 to AFDX", Fuchs, 2012.


ARINC 429 довольно атипичен как бортовая шина тяжело привести другой пример использования физической топологии точка-многоточка (хотя причастные к малым дронам могли бы вспомнить здесь DShot и MAVLink; последний изначально предназначен для беспроводной связи с наземной станцией, но иногда применяется для внутрибортовой коммуникации). Этот подход имеет особый смысл в простых критических системах жёсткого реального времени, потому что временные свойства процесса доставки сигнала от отправителя к получателю абсолютно очевидны и не требуют сложного анализа. Среда передачи не разделяется с другими компонентами, поэтому нет нужды оценивать вклад каждого в загрузку среды и результирующие побочные эффекты. Однако, этот метод не масштабируется и делает логику взаимодействия сильно зависимой от физических параметров сети (если к компоненту не потрудились пробросить кабель при проектировании, соответствующих данных он никогда не получит).


Широкое распространение получила шинная топология (мы говорим о физическом уровне, не забывайте). Вероятно, CAN не нуждается в представлении; на нём основано множество протоколов и стандартов верхнего уровня. Здесь же FlexRAY, LIN, MIL-STD-1553 и ранние стандарты Ethernet (современный Ethernet используется только в коммутируемой конфигурации).


CAN показателен в контексте реакции отрасли на рост сложности продукции. Введённая в 1986 первая версия стандарта предлагала крайне ограниченный MTU в 8 байт на пакет. В 2012 появился CAN FD с MTU в целых 64 байта и увеличенной пропускной способностью. С конца 2018 года в активной разработке находится CAN XL с MTU 2 КиБ и ещё чуть более высокой скоростью (начало ISO стандартизации запланировано на 2021 год).


Говоря о физических шинах, нельзя не вспомнить интереснейшее начинание под названием Wireless Avionics Intra-Communications (WAIC). WAIC предлагает повысить отказоустойчивость бортовых критических сетей введением гетерогенной избыточности, где резервным каналом станет беспроводной. В целом, беспроводные бортовые сети можно считать фундаментально менее надёжными, чем бортовые проводные/оптические, ввиду слабого контроля за состоянием среды обмена (эфир один на всех). Однако, в совокупности с традиционными сетями, беспроводные позволяют поднять отказоустойчивость из-за устранения отказов общего вида, свойственных проводным сетям, ведь механическое повреждение элемента конструкции может с высокой вероятностью повредить все избыточные проводные соединения:



Диаграмма с сайта WAIC.


Физическая шина размещает всех участников на едином сегменте сети, что создаёт проблемы масштабируемости, ведь все узлы вынуждены организовывать обмен внтутри общего домена коллизий. Сложные транспортные средства на острие прогресса (скажем, современные авиалайнеры и космические аппараты) не в состоянии организовать работу систем в пределах ограничений существующих физических шин, поэтому в ход идут коммутируемые сети. Из значимых следует вспомнить SpaceWire (чрезвычайно узкоспециализированная технология; насколько мне известно, совершенно не представлена вне КА) и, конечно, Ethernet.


В современном аэрокосмосе широко применяется коммутируемый Avionics Full-Duplex Switched Ethernet (AFDX) как на стомегабитной медной паре, так и на оптике (см. Boeing 787). Несмотря на передовой физический уровень, логически это всё тот же ARINC 429, где физические соединения точка-точка заменены их виртуальными репрезентациями. Это решает проблемы масштабируемости, но не предоставляет новых инструментов проектирования логики. Сети AFDX проектируются со статическим планированием обмена с применением автоматических доказательств, что позволяет получить гарантированные временные характеристики доставки несмотря на привнесённые коммутацией сложности. Широко применяется полное дублирование сетевого аппаратного обеспечения (коммутаторов и кабельной системы) для отказоустойчивости. Ниже показан пример физической топологии AFDX подсети космического аппарата с дублированием; при этом логическая сеть ARINC 429, построенная поверх (не показана), определяется конфигурацией ПО коммутаторов вместо физической конфигурации кабельной системы:



Диаграмма из "Communications for Integrated Modular Avionics", Alena, 2007.


Гарантированные параметры сети объясняют почему в сетях жёсткого реального времени редко применяется подтверждение доставки. Вторая причина в том, что процессы реального времени часто предполагают сторого периодический обмен данными, где затраты времени и ресурсов сети (которые, замечу, под строгим учётом) на отправку подтверждения или второй копии данных оказываются неоправданными из-за скорой отправки очередного пакета с более новыми данными в рамках естественного течения процесса. Поэтому, в частности, AFDX построен на (слегка модифицированном) протоколе UDP/IPv4. Использование классических "надёжных" протоколов вроде TCP/IP в подобной среде было бы не просто излишним, а контрпродуктивным они несовместимы с особенностями процессов реального времени.


Общая характеристика рассмотренных технологий и построенных на их основе высокоуровневых протоколов заключается в их ориентированности на организацию низкоуровневых сценариев взаимодействия, где фокус внимания проектировщика сосредоточен на группах определённых параметров и их пересылке между конкретными аппаратными и программными компонентами. На логическом уровне мы всё так же имеем дело со жгутами виртуальных проводов, как на схеме ВАЗ 21099. Подобно тому, как рост сложности решений заставил индустрию ИКТ пережить несколько смен парадигмы за последние десятилетия, подходы к построению архитектуры распределённых бортовых систем претерпевают изменения под давлением спроса на автономность и автоматизацию транспортных средств. В 2020 мы наблюдаем первые симптомы несостоятельности традиционных методов и попытки к переходу на качественно более мощные средства, о чём будет следующий раздел.


3. Распределённые вычисления


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


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


Пожалуй, наиболее значимым на сегодня примером такого подхода будет граф распределённых вычислений из Robot Operating System (ROS) (строго говоря, ROS не является операционной системой, это скорее высокоуровневый фреймворк). Изначально ROS был создан в качестве SDK для окологуманоидного робота PR2 от Willow Garage, но исследователи быстро увидели потенциал фреймворка в других робототехнических системах (от пылесосов и манипуляторов до БПЛА и робоавтомобилей), и он превратился в самостоятельный проект. За несколько лет вокруг ROS развилась богатая экосистема программного обеспечения, решающего многие типовые задачи вроде компьютерного зрения, локализации и картографирования, взаимодействия с аппаратным обеспечением, и т.п. Если изначально фреймворк создавался для исследовательских задач, то интенсивное развитие его экосистемы (и отрасли в целом) со временем поставило вопрос о продуктизации и трансфере наработок из лабораторий в полевые условия, с чем возникли значительные трудности.



Пример визуализации распределённых процессов на ROS. На схеме показан фрагмент системы управления автономного БПЛА в режиме программно-аппаратного моделирования. Овалы обозначают процессы, прямоугольники и стрелки обозначают связи издатель-подписчик.


Описание полного спектра проблем продуктизации основанных на ROS изделий приведёно в статье Why ROS 2 [Gerkey], которая, как нетрудно догадаться из названия, решительно предлагает выпустить вторую версию с оглядкой на новые потребности индустрии. Одной из ключевых проблем здесь является неспособность изначально исследовательского фреймворка удовлетворить радикально более жёсткие требования продуктовых систем к предсказуемости и гарантиям безопасности, которые зачастую обусловлены не только коммерческим интересом, но и законодательным регулированием (особенно в случае автомобильной или аэрокосмической отрасли). Коммуникационная подсистема ROS, обеспечивающая межкомпонентные взаимодействия, является одной из наиболее критических и сложных частей фреймворка. В первой версии использовалась собственная реализация, созданная с нуля, принципиально несовместимая с ответственными применениями, из-за чего во второй версии в роли коммуникационной подсистемы использовали популярное готовое решение Data Distribution Services (DDS).


DDS является сильно отдалённым потомком CORBA, ориентированным на реальное время и модель издатель-подписчик (с недавних пор предлагается также встроенная поддержка клиент-серверных взаимодействий, но на практике первый тип наиболее востребован). DDS широко применяется не только в транспорте и робототехнике, но и в промышленности вообще, зачастую выступая в роли выделенного коммуникационного слоя (собственно, как в случае ROS 2) для вышележащих технологий. Особого упоминания здесь заслуживает Future Airborne Capability Environment (DDS FACE) для критической авионики; однако, на сегодняшний день, большая часть реальных применений DDS в аэрокосмосе приходится на немногочисленные военные системы, которые не следуют гражданским стандартам безопасности.


Как было упомянуто, DDS дальними корнями уходит в CORBA оба стандарта поддерживаются одной организацией. Последняя изначально не предназначалась для систем реального времени, но отраслевые реалии заставили исследователей начать рассматривать вопросы её адаптации для реального времени ещё в конце прошлого века. В работе "The Design of the TAO Real-Time Object Request Broker" [Schmidt et al, 1999] большое внимание уделяется тому факту, что проектирование адекватной сети реального времени самой сетью не ограничивается обязательному анализу подлежат вопросы реализации логики протокола на конечных узлах с соблюдением временных гарантий. В разрезе CORBA синопсис рассматриваемых проблем приведён ниже; эти же принципы легко переносятся на практически любую современную технологию того же толка:



Цифрами обозначены ключевые аспекты реализации, где предписан анализ временных характеристик внутренних алгоритмов протокола. Диаграмма из "The Design of the TAO Real-Time Object Request Broker", Schmidt et al, 1999.


Шмидт с коллегами воплотил идеи в популярной ныне C++ библиотеке TAO (The ACE ORB), которая легла в основу некоторых современных реализаций DDS. Сама по себе TAO насчитывает более двухсот тысяч строк кода без учёта специфики DDS, которая привносит ещё дополнительный код сверху. Из более современных и независимых от TAO инкарнаций DDS упомяну, пожалуй, наиболее многообещающую на сегодня eProsima Fast-DDS (это оценочное суждение, а не реклама) без сторонних зависимостей и тестов она занимает более трёхсот тысяч строк C++ кода (и реализует при этом не все опциональные возможности стандарта). Эти сведения приведены с целью иллюстрации порядка концептуальной сложности DDS.


Как нетрудно догадаться из вышеизложенного, DDS также отличается высокими требованиями к вычислительной платформе, что помимо прочего ограничивает использование во встраиваемых системах. Конкретно эта проблема отчасти решается специализированным подмножеством DDS For Extremely Resource Constrained Environments (DDS-XRCE). Но, согласно нашей модели, это решение уже выходит далеко за пределы концепции распределённых вычислений в силу своей глубокой зависимости от центрального координирующего агента и ограниченной функциональности. Для рассматриваемого здесь вопроса эта технология большой ценности не представляет и рассматривать мы её не будем, равно как мы обойдём стороной и связанный проект micro-ROS.


Из других решений есть смысл поверхностно упомянуть SOME/IP часть автомобильного стандарта AUTOSAR v4+, предлагающую сервисы построения распределённых систем поверх стека IP. В отличие от DDS, SOME/IP сфокусирован исключительно на автомобильных применениях и оперирует существенно более низкоуровневыми концепциями со слабой сегрегацией по уровням абстракции. В совокупности с довольно вольготным обращением с распределёнными состояниями (об этом поговорим далее) и значительным логическим зацеплением между коллабораторами это вызывает вопросы о будущем SOME/IP при наличии сильного конкурента в лице DDS.


Распространённые в ИКТ альтернативы вроде MQTT и разнообразных специализированных фреймворков не учитывают аспекты реального времени и гарантий поведенческих характеристик, поэтому в наших приложениях встретить их можно редко и рассматривать их здесь не имеет смысла.


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


Наш подход


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


  1. Простота понимания и реализации. Как было показано выше, это исключительно важно для критических систем. Протокол масштабируется согласно сложности использующего его компонента распределённой системы (т.е., аппаратного узла или программы): в простых компонентах совместимая реализация протокола должна умещаться в одну тысячу строк; в очень сложных она может расти до пары десятков тысяч строк.


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


  3. Отказоустойчивость. Протокол реализует одноранговую децентрализованную сеть со встроенной поддержкой избыточности. Обеспечивается совместимость с ненадёжными сетями реального времени, где возможны потери пакетов в результате деструктивных воздействий среды (например, электромагнитная интерференция), но не самой сети (например, переполняющийся буфер).


  4. Предсказуемость. Протокол изначально спроектирован для задач реального времени и для использования во встраиваемых системах от младших однокристалок без ОС с единицами КиБ памяти до мощных компьютеров под управлением сложных ОС, причём не обязательно реального времени. Поддерживаются средства высокоточной синхронизации времени в пределах сети для нужд распределённых контуров управления. Ресурсный потолок всегда тривиально предсказуем и доказуем.


  5. Открытость. Это не техническое требование, а юридическое, но это не делает его менее значимым. Невозможно обеспечить серьёзные внедрения закрытой технологии, если существенная часть отрасли живёт открытыми стандартами и открытым ПО. Этот пункт подразумевает свободное распространение всей документации и кода под разрешительными лиценизиями (CC BY, MIT) без обязательных членских взносов.



Синопсис графически

В части погони за простотой как одной из ключевых характеристик можно усмотреть реминисценции известного в определённых кругах алгоритма распределённого консенсуса Raft, чьи создатели точно так же, как и мы, начали с вопроса о том, как сделать сложные вещи простыми. Хотя область их деятельности не имеет ничего общего с нашей, они, как и мы, в конечном итоге решали проблему восприятия, где единственной гарантированно достоверной метрикой является человеческий опыт. В отличие от авторов Raft, мы не проверяли трудность понимания наших спецификаций на больших массах людей (N.B.: они показали видео-лекцию 43-м студентам и потом оценили понимание при помощи теста, сравнив результаты с конкурирующей технологией). Однако, у нас есть вот такое практическое свидетельство, где господин зашёл с улицы и сделал минимальную реализацию UAVCAN с нуля за "пару недель" (с его слов):



Желающие увидеть код найдут его на гитхабе как libuavesp. Я, обратите внимание, умываю руки мы к этой реализации отношения не имеем. Заявление автора о том, что "UAV" в названии "UAVCAN" имеет отношение к БПЛА, не соответствует действительности и вызвано банальным недоразумением.


Как нетрудно догадаться из предваряющей этот раздел вводной, UAVCAN широко заимствует ценные принципы из флагманов современной индустрии, в первую очередь опираясь на ROS, DDS, AFDX, WAIC и множество высокоуровневых CAN протоколов, которые даже нет смысла здесь перечислять. Однако, вопросы организации распределённых вычислений одними транспортными протоколами, очевидно, не ограничиваются, особенно если учесть заявленную в ключевых целях потребность в "высокоуровневых абстракциях". UAVCAN удобно рассматривать в виде трёхуровневой модели (мы намеренно игнорируем семиуровневую модель OSI ввиду её чрезмерной детализации):


  • Уровень приложения. На этом уровне представлены общие для всех бортовых систем функции: мониторинг состояния, логирование, передача файлов, управление конфигурацией, телеметрия, и т.п. На этом же уровне создаются специализированные сервисы согласно потребностям конкретного приложения. В распоряжении пользователя два вида взаимодействий: анонимный статически типизированный издатель-подписчик и статически же типизированный удалённый вызов процедур с явной адресацией (т.е. не анонимный).


  • Уровень представления отвечает за маршалинг доменных объектов в связях издатель-подписчик и при удалённом вызове процедур. Этот уровень реализован средствами специального предметно-ориентированного языка, на котором даётся строгое определение типов данных для сетевого обмена: Data Structure Description Language (DSDL). На основе DSDL-дефиниций можно автоматически генерировать код (можно и не автоматически).


  • Транспортный уровень занимается доставкой объектов согласно связям издатель-подписчик и удалённым вызовам процедур. Этот уровень намеренно сильно изолирован от вышележащих двух, что позволяет нам определить несколько транспортов поверх различных нижележащих протоколов:


    • UAVCAN/CAN работает поверх классического CAN и CAN FD. Вероятно, в будущем также появится поддержка CAN XL, но это не точно.
    • UAVCAN/UDP работает поверх UDP/IP. По состоянию на 2020-й год, спецификация этого транспорта ещё находится в стадии ранней альфы и может быть изменена до стабилизации (хотя предпосылок к этому нет).
    • UAVCAN/serial работает поверх любого байт-ориентированного протокола (UART, RS-232/422/485, USB CDC ACM) и ещё подходит для хранения дампов в неструктурированных бинарных файлах. Этот транспорт тоже ожидает стабилизации.
    • Поскольку интерфейс между транспортом и верхними уровнями хорошо определён, в будущем возможно добавление новых транспортных протоколов. В числе таковых рассматривается, например, беспроводной IEEE 802.15.4.


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


Первое из исходных предположений таково: нижележащая транспортная сеть (например, CAN или Ethernet, в зависимости от выбранного транспорта) предлагает хорошо охарактеризованную минимальную кривую обслуживания и нулевую вероятность потерь пакетов при отсутствии неблагоприятных воздействий внешней среды. Последнее означает, что потери не могут возникнуть в результате процессов, протекающих внутри сети, как, например, переполнение буфера на сетевом узле; однако, допускаются кратковременные нарушения, вызванные внешними факторами, как, например, электромагнитная интерференция. Это предположение полностью совместимо с реалиями настоящих бортовых систем, и оно позволяет нам существенно упростить логику протокола. Компенсация потерь ввиду внешних воздействий выполняется путём превентивной отправки дубликатов (только в тех случаях, где требуется). Рассмотрение этого метода даётся в статье Idempotent interfaces and deterministic data loss mitigation. Хотя описанные особенности выглядят чуждыми для традиционных систем, они вполне оправданы для нашей области.


Крайне аккуратное обращение с разделяемым состоянием позволяет нам сильно сократить пространство состояний сетевых узлов в сравнении со схожими решениями. В результате сокращается техническая сложность реализации, упрощается её анализ и тестирование, о чём подробно сказано в официальном руководстве. Сетевой узел UAVCAN делает минимум предположений о состоянии своих коллабораторов; например, если в случае традиционного фреймворка издатель-подписчик обычно выделяется явная процедура установления подписки, где подписчик сообщает издателю о своей заинтересованности в конкретных данных (см. SOME/IP, DDS, ROS, практически все MQ*, etc.), в UAVCAN издатель слепо отправляет данные в сеть, позволяя заинтересованным агентам их принять или проигнорировать.


Последнее обстоятельство создало бы существенные преграды для масштабирования, если бы не широкое использование аппаратной фильтрации пакетов в обязательном порядке. Известные нам другие протоколы (кроме AFDX) необоснованно игнорируют тот факт, что всё современное аппаратное обеспечение для высокоскоростной коммуникации, за исключением лишь некоторых маргинальных представителей, предоставляет мощные аппаратные инструменты автоматической фильтрации. Разумная эксплуатация этого факта позволила нам ввести радикальные упрощения без ущерба функциональности, о чём говорится в статье Alternative transport protocols in UAVCAN.


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


Например, динамическое выделение адреса в сети поддерживается опциональным механизмом plug-and-play (впрочем, конкретно для UAVCAN/UDP он не определён ввиду наличия стандартного DHCP). Механизм этот также поддерживает избыточные аллокаторы для отказоустойчивых систем, где консенсус реплик обеспечивается при помощи упомянутого ранее алгоритма Raft.


Второй аспект статичности заключается в предоставлении ресурсного потолка для любой части системы на этапе проектирования. Так, определяемые при помощи упомянутого ранее DSDL типы всегда имеют верхний предел размера любого поля переменной длины, из чего следует, что максимальное время передачи, максимальное время сериализации/десериализации, и, в общем случае, максимальное время обработки всегда можно определить статически. Ниже показано DSDL-определение стандартного типа журнальной записи под именем uavcan.diagnostic.Record, где можно видеть, что максимальная длина сообщения задана явно и ограничена 112-ю байтами (кодировка всегда UTF-8):


# Generic human-readable text message for logging and displaying purposes.# Generally, it should be published at the lowest priority level.uavcan.time.SynchronizedTimestamp.1.0 timestamp# Optional timestamp in the network-synchronized time system; zero if undefined.# The timestamp value conveys the exact moment when the reported event took place.Severity.1.0 severityuint8[<=112] text# Message text.# Normally, messages should be kept as short as possible, especially those of high severity.@assert _offset_ % 8 == {0}@assert _offset_.max <= (124 * 8)     # Two CAN FD frames max

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


В предшествующей секции было отмечено, что протокол реального времени должен проектироваться с учётом доступных средств реализации с соблюдением временных характеристик. Если представление данных в гарантированное время в целом делается возможным благодаря свойствам DSDL, своевременность их обработки на нижних уровнях протокола (на транспортном, то есть) достигается благодаря явно определённому потолку для всех ресурсов протокола. Например, максимальное количество каналов издатель-подписчик в системе ограничено (этот максимум, однако, очень высок десятка тысяч каналов достаточно каждому), равно как и максимальное количество узлов в сети. В спецификации рассматриваются практические подходы к реализации транспортной логики (а именно, демультиплексирования пакетов и реконструкции полезной нагрузки из мультикадровых передач) с оценкой влияния различных методов на асимптотическую сложность.


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


Для примера я продемонстрирую сериализацию и публикацию сообщения, определённого ниже, содержащего три константы и два поля. Константы не участвуют в обмене, поскольку они и так известны всем узлам, имеющим доступ к соответствующему определению типа. Поля сериализуются в плоский остроконечный бинарный формат (младший байт идёт первым) примерно как в ASN.1 UPER (другой порядок байт), но с местной спецификой (ценители сериализации данных должны посмотреть мою заметку, где я рассматриваю популярные форматы и сравниваю их с DSDL).


uint16 VALUE_LOW  = 1000uint16 VALUE_HIGH = 2000uint16 VALUE_MID = (VALUE_HIGH + VALUE_LOW) / 2# Рациональная арифметика произвольной точности!uint16 valueuint8[<=100] key  # Динамический массив от 0 до 100 элементов.

Если мы, скажем, присвоим полям значения value=1234 и key=Hello world!, результат в шестнадцатиричной нотации будет следующим:


D2 04 0C 48 65 6C 6C 6F 20 77 6F 72 6C 64 21

Где D2 04 соответствует 1234, 0C длина массива (если бы максимальная длина была более 255 элементов, тут было бы два или четыре байта), и остаток приходится на приветствие.


Публикация сообщения через классический CAN будет выглядеть предельно незамысловато все счастливые CAN протоколы похожи друг на друга (надо ли говорить, что в случае CAN FD всё вошло бы в один кадр):


$ candump -decaxta any(7.925)  vcan2  TX - -  1013373B   [8]  D2 04 0C 48 65 6C 6C A0   '...Hell.'(7.925)  vcan2  TX - -  1013373B   [8]  6F 20 77 6F 72 6C 64 00   'o world.'(7.925)  vcan2  TX - -  1013373B   [4]  21 F9 02 60               '!..`'

Лишний подозрительный байт в конце каждого кадра содержит метаданные транспорта. В конце последнего кадра есть два байта циклического избыточного кода для проверки корректности декадрирования.


Колонка со значением 0x1013373B здесь представляет CAN ID, что является битовой маской из нескольких полей с метаданными. Наиболее интересным здесь является значение 0x1337 (4919 в десятичной системе), которое называется идентификатором темы (subject-identifier) в отличие от некоторых более сложных протоколов (как DDS), UAVCAN не поддерживает именованные топики, предлагая вместо них нумерованные темы (похоже на SOME/IP и практически любой протокол поверх CAN). Это значение проектировщик выбирает произвольно, сообразно своим представлениям о системе.


Теперь мы можем повторить упражнение для UAVCAN/UDP на localhost. Wireshark, к сожалению, пока не имеет диссектора для UAVCAN, да и пёс с ним, ведь и так всё ясно:



Дотошный читатель спросит, откуда взялся порт назначения 21303, на что я отвечу, что он вычисляется как сумма идентификатора темы (4919 у нас) и фиксированного смещения 16384. Смещение выбрано таким образом, чтобы сдвинуть порты UAVCAN в эфемерный диапазон с целью минимизации конфликтов. Исходный порт полезной информации не несёт и выбирается произвольно. Нашу полезную нагрузку (D2 04 0C ...) предваряют 24 байта метаданных, добавленных стеком UAVCAN; там содержится информация о приоритете, фрагментах (тут их нет) и последовательном номере сообщения.


Будет ошибкой думать, что внедрение UAVCAN/UDP в обязательном порядке требует полного IP стека. Когда на практике поднимается вопрос об IP стеке, обычно подразумевается TCP/IP, сложность которого несопоставима с UDP/IP. Последний можно собрать с нуля на C в несколько сотен строк, как наглядно продемонстрировал Lifelover в 2011-м году в серии публикаций "Подключение микроконтроллера к локальной сети".


Здесь практические упражнения мы заканчиваем, потому что публикация не об этом. Желающим закатать рукава следует пройти в библиотеку с говорящим названием PyUAVCAN, при помощи которой эти примеры были получены (не будет лишним также заглянуть в руководство).


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


Последним заслуживает рассмотрения уровень приложения. Техническая сторона вопроса прозрачна: пользователь определяет собственные типы с использованием DSDL, затем создаёт соответствующие темы (топики) по мере надобности. Для распространённых задач (мониторинг узлов, файлообмен, логирование, управление конфигурацией, и т.п.) нет нужды конструировать собственные сетевые сервисы, потому что соответствующие определения предоставляются стандартным набором сервисов UAVCAN, из которого можно свободно выбрать необходимые.


Поверх UAVCAN предполагается создание специализированных отраслевых стандартов уровня приложения, примерно как стандартные классы USB существуют поверх ядра USB, как профили CANopen или Bluetooth, или как DDS FACE поверх DDS. Схематически мы это изображаем следующим образом:



Из отраслевых стандартов сейчас в работе один так называемый Drone Standard 15, или DS-015, к которому активно прикладывают руки, среди прочих, компании из Dronecode Foundation. Мы предвидим появление других отраслевых спецификаций в будущем, поскольку UAVCAN сегодня можно встретить далеко за пределами одних только дронов но об этом позже.


Техническая сторона здесь прозрачна, но есть и другая. Сложные распределённые системы требуют дисциплинированного подхода к проектированию сетевых сервисов и их интерфейсов. Контакты с сообществом разработчиков встраиваемых систем показали, что эта аудитория может глубоко разбираться в вопросах, традиционно характерных для их области деятельности (реальное время, операционные системы, связующее ПО, и т.п.), но при этом иметь очень ограниченное представление о проектировании адекватных сетевых сервисов. Накопленный опыт работы с несколько более низкоуровневыми технологиями, по-видимому, подталкивает людей к неуместному заимствованию практик, что неоднократно на нашем опыте приводило к появлению дефектных интерфейсов, работа с которыми наполовину состоит из страдания. Решение этой нетехнической проблемы является столь же нетехническим мы опубликовали учебный материал, где подробно объясняется, как выглядит сетевой сервис здорового человека. Материал этот опубликован в официальном руководстве UAVCAN в главе Interface Design Guidelines.


Внедрение


Прогресс в области вычислительной техники, элементов питания, машинного обучения, генеративного проектирования и других передовых областей порождает новые проекты транспортных систем, которые зачастую реализуются малыми предприятиями при минимальном финансировании и низкой стартовой вовлечённостью в релевантные отрасли. Практические примеры автономных дронов и роботов, электрических конвертопланов, кубсатов, робоавтомобилей, и т.п. в изобилии присутствуют в новостных лентах, так что приводить их здесь нет смысла. Каждое такое средство, будучи передовым продуктом 21-го века, критически зависимо от грамотной огранизации бортовых вычислительных систем, и часто также несёт груз правового регулирования и доказательства функциональной безопасности. Такие проекты неспособны подняться без широкого применения именно открытых стандартов и свободных решений, потому что как коммерческие альтернативы, так и доморощенные велосипеды рискуют не вписаться в бюджет. Стартап, скажем, с летательным аппаратом, намеревающийся следовать стандартам консервативной аэрокосмической отрасли на первом же шаге выложит десятки тысяч евро за PDF документы; в то же время будет ошибкой думать, что внедрение этих стандартов является необходимым или даже желательным условием для успеха.


UAVCAN полностью открыт для распространения и внедрения, не предписывает никаких лицензионных ограничений: вся документация распространяется под CC BY 4.0, а исходный код референсных реализаций под MIT. Вероятно, любой другой подход к лицензированию сегодня обрёк бы проект на забвение.


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


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


На гитхабе поддерживаются референсные библиотеки, среди которых Libcanard минимальная реализация UAVCAN/CAN для однокристалок на C11, объём кода которой фигурирует в названии этой статьи. Также там базируется uavcan.rs мультитранспортная реализация на Rust, которая по состоянию на июль 2020 ищет нового мейнтейнера.


Там же поддерживается Yukon десктопная программа на питоне-электроне для разработки, отладки и диагностики UAVCAN сетей, представляющая собой смесь RViz, Wireshark и LabView. Раньше у нас была ещё утилита на PyQt для предыдущей экспериментальной версии протокола, но теперь она устарела безнадёжно, и усилия сосредоточены на Yukon. На форуме есть бесконечно длинные треды с обсуждениями, но дальше обсуждений мы практически не продвинулись из-за острой недостачи фронтендеров. На сегодня последнее демо выглядит так:



Некоторый интерес представляет использование API ROS поверх UAVCAN вместо DDS. Смысл здесь в том, чтобы сделать развитую экосистему пакетов ROS доступной в системах реального времени и младших микроконтроллерах с использованием UAVCAN, обеспечив при этом также нативную совместимость с обычными UAVCAN устройствами, ничего не знающими о ROS. Краткая вводная дана в заметке на форуме "An exploratory study: UAVCAN as a middleware for ROS"; разыскиваются коллабораторы.


Среди множества компаний и учреждений, принимающих участие развитии стандарта, следует особо выделить NXP Semiconductors. На недавней конференции они представили неплохой доклад "Getting started using UAVCAN v1 with PX4 on the NXP UAVCAN Board", демонстрирующей, в том числе, кое-какие их новые референсы для UAVCAN приложений.


Не менее ценным партнёром является Amazon Prime Air со своим крутейшим автономным доставочным дроном. Эти господа производят не железо, а код копирайты Амазона щедро разбросаны по нашим исходникам.


Законченное UAVCAN-совместимое железо вроде сервоприводов, приводов электромоторов, системы воздушных сигналов, автопилотов, систем впрыска топлива, всевозможных датчиков и отладочных плат сегодня предлагают многие вендоры, чьё перечисление тут вряд ли оправданно.


Согласно опросу, проведённому в конце 2019 года, а также основываясь на наших личных контактах с интеграторами, UAVCAN сегодня применяется в пилотируемых (~10% компаний) и беспилотных (~80% компаний) летательных аппаратах, в малых космических аппаратах (~5% компаний, на 2020 год на орбите есть около 20 кубсатов, согласно доступным нам данным), в микро транспорте (вроде электросамокатов) и разнообразных робототехнических системах. Наша выборка, впрочем, подвержена систематической ошибке и приводится только в общеинформативных целях; распределение может не соответствовать действительности. Краткая сводка по опросу доступна отдельно.


Статус и будущее проекта


Наша глобальная амбициозная цель-максимум: стать полноценной альтернативой технологиям класса DDS для отказоустойчивых высоконадёжных систем реального времени; стать стандартом де-факто для новых видов интеллектуального транспорта.


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


uavcan.org


Источники и материалы
  • Digital Avionics Handbook (3rd edition) Spitzer, Ferrell, 2017
  • Computers in Spaceflight: The NASA Experience Kent, Williams, 2009
  • The Evolution of Avionics Networks From ARINC 429 to AFDX Fuchs, 2012
  • Communications for Integrated Modular Avionics Alena, 2007
  • Safety and Certification Approaches for Ethernet-Based Aviation Databuses Yann-Hang Lee et al, 2005
  • The Design of the TAO Real-Time Object Request Broker Schmidt, Levine, Mungee, 1999
  • In Search of an Understandable Consensus Algorithm Ongaro, Ousterhout, 2014
  • Starlink is a very big deal Handmer, 2019
  • Why ROS 2? Gerkey, 2015
  • ROS on DDS Woodall, 2015
  • Safe Micromobility Santacreu, 2020
  • Understanding Service-Oriented Architecture Sprott, Wilkes, 2009

Документация и спецификации рассмотренных технологий в списке источников не указаны.


Также см. наши публикации по теме:


Подробнее..

Роботы-начальники семь примеров, как люди и бизнесы переходят под власть машин

07.07.2020 16:22:26 | Автор: admin
Самые главные побочки коронавируса не физиологические, а социальные и экономические. Ничего принципиально нового он в жизнь человечества не привнёс зато разогнал и так уже шедшие процессы, главные из которых переход на удалённую работу и автоматизация. И показал, в какую сторону меняются отношения человека и машин. Роботы и программы по-прежнему призваны помогать человеку, но теперь всё очевиднее, что эта помощь заключается, в том числе, в принятии роли надсмотрщиков будь то роботы, следящие за соблюдением социальной дистанции, или программы, напоминающие сотрудникам о том, что солнце ещё высоко, и им пора за работу. Всё во имя блага самого человека, разумеется.

Робот-овчарка


За годы своей деятельности Boston Dynamics разработали уже целый зоопарк и несколько двуногих антропоморфных роботов, а один из их самых известных проектов робопес Spot. Он развивает скорость до 1.6 м/сек, изучает окружающее пространство через стереокамеры с суммарным углом обзора в 360, весит 25 килограмм легкий, небольшой, маневренный. Spot был представлен компанией в 2016 году и предлагался в основном к использованию на производстве, например, для удаленной проверки производственных помещений. Освоению новых ролей немало поспособствовала пандемия: в мае 2020 года робопес вышел на патрулирование парков в Сингапуре, чтобы контролировать соблюдение мясными мешками социальной дистанции.



Каждый робот патрулировал свой участок сингапурского парка Бишан-Анг Мо Кио. При встрече с группой людей робот озвучивал заранее записанное сообщение: Сохраним здоровье Сингапура! Для вашей безопасности и безопасности окружающих вас людей, пожалуйста, оставайтесь на расстоянии не менее одного метра. Спасибо.



Полностью автономными роботов Spot назвать нельзя в течение тестового периода его контролировали специалисты. Однако с учетом текущего уровня развития компьютерного зрения и систем принятия решений несложно представить, как робопес определяет маршрут и цель самостоятельно это вполне реализуемо. Уже сейчас Spot снабжен камерами, которые используются для выявления групп людей. Но правительство Сингапура заявило, что роботы не будут использовать распознавание лиц или собирать личные данные граждан. Как может распорядиться возможностями пса другой хозяин неизвестно, а простор для это теперь есть: с 16 июня 2020 года робопес поступил в продажу (до этого он сдавался предприятиям в аренду).

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

Робот, проверяющий, помыты ли руки


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

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

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

image

Тем временем в России уже не только объединено распознавание лиц с контролем мытья рук, но комбинация уже запатентована и продается в виде готового решения. Компания Дамате, занимающаяся производством молока и мяса, использует разработанную в Сколково систему Директива. Разработчики Директивы: санитария обещают проверку санитарной обработки рук в соответствии с международными стандартами со 100% точностью. В Дамате сейчас имеется 20 точек контроля мытья рук, через которые проходят 2250 сотрудников и планируется установить 21 систему на строящемся заводе по глубокой переработке мяса индейки в Пензенской области.

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

Электронный ГАИшник


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

Насколько совершенна такая система и будет ли она выписывать штрафы несправедливо? Вполне возможно, т.к. результат сильно зависит от исходных данных (качества фотографий) и от принципов работы модели машинного обучения, использующейся в системе. Логичнее задать вопрос следующим образом: будет ли процент ошибок искусственного интеллекта меньше или больше, чем процент ошибок живых специалистов, выполняющих ту же задачу? Но вряд ли мы узнаем ответ: штрафы остаются источником дохода для государства независимо от того, кто их выписал, и кто-то наверху вряд ли будет подсчитывать некий процент несправедливостей и стремиться его уменьшить. Так что справедливость интеллектуального контроля в данном случае зависит не только от применяемых технологий, но и от целей, которые за ними стоят. Известно только то, что ошибки делают и живые люди, и программы, и казусы (Штраф за тень и птица без номеров: как ошибаются дорожные камеры) происходят не только для России. Однако там, где есть автоматизированное выписывание штрафов, можно внедрить и автоматизированную борьбу с неправильно назначенными штрафами: в Дубае искусственный интеллект помогает бороться с ошибками, которые допускают люди при выписывании штрафов, а в Германии существует так называемый цифровой адвокат.



Робот-жена автолюбителя


Более человеколюбивая интеллектуальная система контроля это умный круиз-контроль. Одна из разработок в этой сфере принадлежит Hyundai: в октябре 2019 года было объявлено о выпуске системы SCC-ML (Smart Cruise Control + Machine Learning). В ней учитывается дистанция до другого автомобиля, время реакций на смену дорожных условий и скорость. В отличие от привычных систем круизконтроля SCC-ML не только поддерживает дистанцию до впереди идущего автомобиля и заданную скорость, но и способна обучаться на примере действий водителя.

В 2019 году Nvidia Corporation, активно занимающаяся решениями для водителей, создала нейронную сеть, регулирующую за водителя дальний свет. Сеть реагирует на попадающие в поле зрения камеры автомобили, у которых включен задний фонарь или фара в текущем кадре камеры. Припаркованные автомобили считаются неактивными и игнорируются, а при обнаружении активных автомобилей. Доступны 2 режима: в первом режиме (Auto High Beam) система освещения дальнего света автоматически включается при слабой освещенности дороги. Когда система обнаруживает активный автомобиль, она автоматически переключается на ближний свет или выключается. Как только активные транспортные средства выходят за рамки камеры, дальний свет автоматически включается снова. Во втором режиме (Adaptive Driving Beam) ИИ снижает яркость отдельных светодиодов в фарах, создавая зоны без бликов.

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

Робот-начальник


В повседневные рабочие процессы офисных работников тоже вмешиваются автоматизированные системы, которые совершенствуются и приобретают новые функции, основанные на данных о психике. Производитель софта для контроля за удалёнными сотрудниками Kickidler выпустил функцию Автокик для самоконтроля сотрудников. Автокик состоит из двух частей: инструментов самоконтроля в виде отчета и автоматических уведомлений сотруднику о его нарушениях (что считать нарушением настраивается заранее). То есть, с другой стороны задача Автокика автоматизация пинков, раздаваемых начальством. Зачем тогда остаётся нужным начальство непонятно.



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



Некоторые исследования показывают, что человек эффективен на работе менее трех часов в день, а уровень концентрации резко падает уже через 20 минут. В целом в психологии считается, что длительность эффективного произвольного внимания взрослого человека максимум 45-50 минут. После этого требуется переключение внимания на задачу другого типа. В популярной технике тайм-менеджмента Pomodoro стандартными считаются отрезки 25 минут, но их можно адаптировать под себя, а главной остается идея частых перерывов в монотонной деятельности. Автокик как раз может подсказать сотруднику, работающему долго без перерывов, сделать небольшую паузу в работе. Эту функцию можно использовать для заботы о здоровье напоминание о перерыве может намекать на необходимость физической активности: раз в несколько рабочих отрезков времени можно сделать небольшую зарядку или гимнастику для глаз.



Робот-няня


Разработки на основе искусственного интеллекта также могут определять уровень стресса, помогать в тренировке навыков концентрации внимания и расслабления. Например, у участников интенсива по подготовке кадров для цифровой экономики и Национальной технологической инициативы (НТИ) Остров 10-21 собирались данные и использовались системой на основе искусственного интеллекта для корректировки образовательного процесса. Основная цель избежать эмоционального выгорания и снижения эффективности из-за стресса.

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

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

Робот, следящий, чтобы не выражались


В интересах бизнеса программы научились даже контролировать речь сотрудников: сервис Anryze предложил брокерской компании Weeden and Co технологию по контролю за употреблением брокерами определенных слов при общении с клиентами. Дело в том, что брокерам запрещено гарантировать доходность от продаваемых бумаг. Компании, нарушившие запрет, могут получить штраф от $5 млн, а также их ждет разбор инцидента и репутационные риски. Сервис Anryze вылавливает в речи сотрудника запрещенные слова и анализирует контекст, в котором они были сказаны.



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

Добровольно в Матрицу


Факт остаётся фактом: люди в собственных интересах передают контроль над собой машинам. Для бизнеса и государства в целом одни плюсы, кроме высокой стоимости разработки, а что касается обычных людей приватность и самостоятельность они обменивают на получение рекомендаций и снятие ответственности за принятие решений.

В Соединенных Штатах можно почувствовать напряженность между гарантированием индивидуальных прав и защитой коллективных интересов во время этого кризиса в области здравоохранения. Таким образом, ГАФАМ имеет в своем распоряжении в Соединенных Штатах информацию, которая была бы чрезвычайно ценной во время кризиса: огромное количество данных об американском населении. Ларри Бриллиант, эпидемиолог и исполнительный директор Google.org, утверждает, что эта информация может изменить лицо общественного здравоохранения и считает, что мало вещей в жизни важнее, чем вопрос о том, не слишком ли мощны основные технологии, но пандемия, несомненно, одна из них (Н. Скола, Big Tech сталкивается с ловушкой Большого Брата на коронавирусе, POLITICO, 18 марта 2020 г). Поэтому правительство США обратилось к этим компаниям с просьбой предоставить доступ к агрегированным и анонимным данным, особенно в отношении мобильных телефонов, для борьбы с распространением вируса (Т. Ромм, Э. Двоскин, С. Тимберг, Правительство США и технологическая индустрия обсуждают способы использования данных о местоположении смартфонов для борьбы с коронавирусом, The Washington Post, 18 марта 2020 г). Однако эти компании проявляют осторожность в связи с юридическим риском и потенциальным нанесением ущерба имиджу (С. Оверли, Белый дом ищет помощи в борьбе с коронавирусом в Силиконовой долине, POLITICO, 11 марта 2020 г.). Законодательное регулирование данных, вероятно, помогло бы наладить диалог между государственным и частным секторами и определить, какие виды чрезвычайных ситуаций должны подпадать под коллективный интерес в отношении индивидуальных прав (а также условия и гарантии такого механизма), однако за последние два года Конгресс не добился никакого прогресса в отношении такого закона.

Закончить этот обзор хотелось бы словами Юваля Ной Харари из статьи Мир после коронавируса (The Financial Times, 20 марта 2020 г):

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

Использование UAVCAN для модульной электроники БПЛА, или как не спалить дрона, перепутав провода

30.07.2020 22:23:20 | Автор: admin
Привет! Меня зовут Роман Федоренко, я доцент Центра компетенций НТИ по направлению Технологии компонентов робототехники и мехатроники на базе Университета Иннополис. Я работаю с командой робототехников, которая специализируется на беспилотных летательных аппаратах. По большей части мы занимаемся высокоуровневым управлением БПЛА: планирование движения, обход препятствий, решения для киносъёмки и сканирования местности. Хотя собственные небольшие коптеры тоже собирали и с железом работали. В прошлом году мы начали разработку большого самолёта вертикального взлёта и посадки, который включает все уровни от изготовления носителя до обвески датчиками и интеллектуального управления. И при разработке этого проекта познакомились с UAVCAN.

UAVCAN это открытый лёгкий протокол для бортовой сети подвижных объектов. Недавно его разработчик и мейнтейнер Павел Кириенко Spym рассказал о протоколе на PX4 Developer Summit, крупной конференции сообщества разработчиков дронов с использованием open-source экосистемы вокруг автопилота PX4, частью которой является UAVCAN. А ещё Павел подготовил подробную статью для русскоязычного сообщества на Хабре по следам своего доклада.

В этом материале я расскажу о практической стороне использования протокола с позиции разработчиков систем автоматического управления для БПЛА: как мы выбрали UAVCAN, что делаем с помощью него и какие возможности видим в будущем.




Гибридные БПЛА


Самолёт вертикального взлёта и посадки (VTOL) это гибрид коптера и самолёта, который может работать дольше коптера за счёт аэродинамической подъёмной силы крыла и при этом не требует взлётно-посадочной полосы либо пускового устройства и парашюта, как обычные самолётные беспилотники. Сейчас разработка таких устройств популярное и многообещающее направление. Такой аппарат можно использовать для доставки, картографии, мониторинга и других целей. По тому же принципу конструкции устроены большинство проектов летающего такси, например:

  • полностью электрическое воздушное такси Lilium Jet немецкой компании Lilium;
  • малошумный электросамолёт Heaviside компании Kitty Hawk Себастьяна Труна (которого многие знают по беспилотным автомобилям);
  • проект Vahana от Airbus.


Innopolis VTOL plane
Самолёт вертикального взлёта и посадки Университета Иннополис

Мы разработали три модели небольших беспилотных аппаратов с разным размахом крыла, грузоподъёмностью и источниками питания полностью электрические и с двигателями внутреннего сгорания. По конструкциям летательных аппаратов сотрудничаем с Казанским авиационным институтом и авиационными предприятиями Казани, а фокус наших работ электроника, алгоритмы и автоматическое управление.

При чём здесь UAVCAN?


Те, кто занимаются коптерами, знают, что обычная структура системы управления выглядит примерно так:

PixHawk drone scheme

Типовая схема БПЛА на базе автопилота PX4. Источник

Моторы управляются регуляторами оборотов (ESC), на которые посредством PWM (ШИМ) сигналов подаются уставки от автопилота. Датчики подключаются по куче разных интерфейсов UART, I2C, SPI. Плюс телеметрия, пульт, питание и получается такой паук из проводов. Но основная проблема не в этом.

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

Раньше для проекта 40-метрового дирижабля мы работали с CAN (только протокол был на базе CANOpen). И решение использовать UAVCAN для нас было само собой разумеющимся: в PX4 уже есть его поддержка, даже никаких споров в команде по этому поводу не возникало. Изначально мы хотели заменить длинные линии PWM на цифровой интерфейс, чтобы масштабировать наши решения на аппараты с разным размахом крыла.

Оказывается, UAVCAN это не CAN для UAV
Раньше мы воспринимали UAVCAN как CAN для UAV (БПЛА). Возможно, так изначально и было, но сейчас он позиционируется как Uncomplicated Application-level Vehicular Communication And Networking (Простая коммуникация и сетевое взаимодействие уровня приложений для подвижных объектов) и не привязан ни к UAV, ни к CAN, а используется на целом ряде подвижных объектов и поверх разных интерфейсов. Есть даже предложение об использовании UAVCAN в качестве middleware для ROS (Robot Operating System). Но об этом подробнее в статье от создателя протокола.


Заменив PWM-связи на UAVCAN-связи, мы перестали беспокоиться о проблемах длинных проводов и наводок, а также значительно уменьшили количество подключений к автопилоту.

Было два варианта, как это сделать. Первый использовать регуляторы моторов и сервоприводы с UAVCAN интерфейсом. Такие есть, например, у Zubax. Второй сделать адаптеры UAVCAN, которые устанавливаются непосредственно возле ESC. Мы пошли по второму варианту, потому что выбор ESC с UAVCAN интерфейсом невелик. Сначала мы использовали адаптеры проекта UAVCAN for Hobbyists (UC4H), затем решили делать свои устройства со встроенным DC-DC преобразователем, своей схемотехникой, прошивкой и нескучными диодиками.

Innopolis UAVCAN devices
Наши устройства с интерфейсом UAVCAN

Вошли во вкус


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

  • Преобразователь CAN-PWM до 4 каналов: устройство подключается к шине CAN, принимает и обрабатывает сигналы управления, выдаёт ШИМ. Питать плату можно напрямую с АКБ до 60 В, в её составе включается DC-DC преобразователь, обеспечивающий напряжением 5 В (3 А) плату и потребителя (например, сервомашинку);
  • GPS/Magnetometer/Barometer;
  • Силовая плата, Power Management Unit (PMU): обеспечивает подсоединение нескольких АКБ (параллельно или последовательно при необходимости). Устройство подключается последовательно со всей силовой нагрузкой и обеспечивает её коммутацию. В конструкции датчики напряжения и тока на АКБ, DC-DC преобразователь для обеспечения питания автопилота. Такая плата рассчитана на большие токи до 1000 А. В разработке устройство CAN в составе платы выдающее информацию о напряжении и токе;
  • Лазерный высотомер;
  • Датчик воздушной скорости;
  • Датчик уровня топлива;


Технически эти устройства реализованы на базе микроконтроллера STM32. Проектируем сами, а изготовление заказываем на pcbway.ru. Прошивка реализуется с использованием libcanard.

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

Dark drone

Новые устройства тестируем на небольшом dark дроне

А затем уже используем на самолёте:


Короткое видео тестового полета нашего VTOL-самолета во всех режимах

Организация полётов
Кстати, в Республике Татарстан есть Ассоциация пилотов, разрешающая регистрировать пилотов беспилотников и получать разрешение на полёты нажатием одной кнопки. Они же помогают нам по дружбе.

Здесь даже реально получить разрешения полетать над Казанским кремлём.


В итоге схема у нас выглядит так:

Innopolis VTOL UAVCAN Scheme
Схема нашего VTOL-самолёта с использованием UAVCAN датчиков и исполнительных механизмов

Какие преимущества UAVCAN даст нам в будущем


Резервирование


Важнейшая задача при реализации продукта на базе БПЛА обеспечить надёжность. Мы уже начали работать над этим. Например, несколько наших GPS и датчиков воздушной скорости подключить и использовать параллельно уже получается. Но ещё многое предстоит. Скорее всего, дублирования датчиков и контроллеров с использованием CAN шины будут сделаны проще. К Pixhawk можно подключить две шины, а на шине оставить несколько одинаковых датчиков для резервирования.

Масштабирование


В будущем мы хотим делать большие аппараты взлётной массой больше 30 кг, хотя это и сложно сертифицировать. Масштабируемость архитектуры на базе UAVCAN позволяет строить амбициозные планы.

True HIL-симуляция


Сейчас активно развивается тема работы БПЛА в городской среде Urban Air Mobility (UAM). Для реализации задач UAM нужно больше опираться на такие сенсоры, как камеры и лидары. Тут возникает необходимость разработки и отладки систем интеллектуального управления, а также повышение их надёжности. Для этих целей другая команда Университета Иннополис разрабатывает симулятор Innopolis Simulator для автономных подвижных объектов на основе Unity 3D для тестирования, отладки и обучения.


Innopolis Simulator

Для нашего VTOL-самолета используем Innopolis Simulator в связке с Gazebo для фотореалистичной симуляции, тестирования управления и обработки сенсорных данных лидаров и камер.

Сейчас работаем над своим модулем симуляции динамики вместо Gazebo с более точной аэродинамикой, а также над другой фишкой true HIL симуляцией (от hardware in the loop, или программно-аппаратное моделирование, ПАМ).

В нашем решении все данные поступают от датчиков, а управления на моторы и сервы отправляются по шине UAVCAN. Почему бы не сделать модуль симуляции этих датчиков на уровне той же шины? Просто вместо устройств к контроллеру мы подключаем компьютер с симулятором.
Сейчас HIL-симуляция в PX4 делается посредством специальных HIL_* сообщений MAVLINK (протокол телеметрии, работает по последовательному порту либо UDP/TCP), которые имитируют датчики и исполнительные механизмы.

PX4_HITL

Диаграмма работы PX4 в режиме HITL. Источник

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

Innopolis VTOL UAVCAN HIL Simulator Scheme
Предлагаемая схема работы PX4 в режиме HITL с использованием UAVCAN

Такое решение повышает достоверность результатов отладки на симуляторе, поэтому можно смелее переходить к лётным тестам.


Авиационный HIL симулятор. Источник

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

Вывод


Очень здорово, что над вопросами лёгкости, надёжности и риалтаймовости протокола UAVCAN уже подумали за нас, как и то, что есть PX4, ROS и Linux, в конце концов. Нам было бы очень сложно делать наши коптеры, самолёты, системы управления и планировщики, если бы всего этого не было.

Стандартизация протоколов и программных средств даёт возможность разработчикам говорить на одном языке. Вместе с тем, важна не только стандартизация, но и доступность, что в высокой степени обеспечивает open-source подход. Это позволяет, стоя на плечах гигантов, быстрее переходить к своим задачам, а не строить сначала долго инфраструктуру для работы, что, надеюсь, мы показали на нашем примере в данной статье.


Пьём колд брю после успешных полётов
Подробнее..

Разработка hardware-продуктов что и как устроено

17.07.2020 20:07:39 | Автор: admin

Привет, меня зовут Дмитрии Каржицкии, я работаю QA Lead в белорусском hardware-стартапе Rozum Robotics. Недавно вместе с Университетом Иннополис мы провели митап, посвящённый разработке hardware-продуктов. По следам митапа хочу рассказать про специфику разработки и тестирования роботов и про особенности организации работы в hardware-стартапе.


Кажется, что сфера hardware менее заметна, чем software, как минимум по количеству упоминаний. У всех на слуху разработчики в области веб- и мобильных приложений, которые пишут код на макбуках, попивая смузи. А у hardware специалистов скорее образ классического бородатого инженера, который может и плату спаять, и код написать. Если с задачей на разработку софта верхнего уровня хороший Java-программист должен справиться, то в embedded без понимания железа не обойтись.


Разработку новых продуктов, в том числе и в hardware, можно разделить на два больших направления: коммерческие продукты (стартапы) и научно-исследовательская деятельность (R&D). Процессы и подходы к разработке и тестированию могут быть похожи, отличаются задачи и масштаб. Продукт разрабатывается для конкретных пользователей на основе идеи и исследования, что потенциальным клиентам нужна ваша разработка. В таком подходе больше рисков. Один из рисков сложность масштабирования продукта. Выпустить новую версию приложения недорого, а создать копию робота всё ещё довольно сложно и дорого. О других рисках я расскажу ниже.


Примеры из процесса разработки будут на основе коллаборативного робота-манипулятора (кобота) PULSE. Это такая подвижная железная рука, которую можно запрограммировать под разные задачи.



Процесс производства программного обеспечения


Сейчас мои основные задачи это работа над обновлениями для коботов. Команда много времени уделяет софту: обновление ПО для пользователей, разработка и поддержка API, которое позволяет программировать сложные алгоритмы поведения кобота.


Процесс разработки новой фичи выглядит примерно так:


  1. Хотелки пользователей или бизнеса попадают в бэклог.
  2. Далее анализируем, декомпозируем на задачи.
  3. Затем оформляем задачу в User Story.
  4. Для каждой задачи собираем требования и разбиваем на фичи.
  5. Фича попадает на этап разработки.
  6. Разработчики берут задачу и пишут код.
  7. Когда код готов, заливаем его на робота и тестируем.
  8. Релизим новый функционал. Пользователи скачивают и устанавливают обновление на своих роботов.

Получается, что под определённую задачу собирается мини-команда. Где-то нужен бизнес-аналитик или разработчик встроенного софта команды всегда разные.


Если смотреть на этапы разработки софта для робота, то это классический 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
Подробнее..

Нервная система для роботов на базе процессора Intel Loihi

06.08.2020 10:11:52 | Автор: admin


Осязание помогает нам в самых различных аспектах нашей человеческой деятельности. С помощью него мы можем брать различные предметы, не роняя и не разбивая их, да и при ходьбе, скажем, оно играет очень важную роль. Между тем в робототехнике этот канал информации почти не используется все данные о внешности предметов механизмы получают с помощью камер. Группа ученых из Национального университета Сингапура (National University of Singapore, NUS) решила исправить этот недостаток и с помощью процессора Intel Loihi добилась в том солидных успехов.

Свое изобретение ученые из NUS назвали Asynchronous Coded Electronic Skin (ACES) его можно назвать экспериментальной искусственной нервной системой. ACES способна засекать прикосновения в 1000 раз быстрее своего прообраза нервной системы человека. Даже при использовании большого количества сенсоров комплексу требуется менее 60 наносекунд для локализации физического контакта. ASEC определяет форму, текстуру поверхности и твердость прикасающегося объекта всего за 10 миллисекунд, в 10 раз быстрее моргания глаза.

Видео об эксперименте сингапурских исследователей

В ходе первых экспериментов исследователи обучали систему понимать шрифт Брайля. Им удалось добиться точности в 92% при потреблении энергии в 20 раз меньшем, чем при использовании стандартного процессора фон Неймана. Далее объектами исследования стали более сложные пространственные предметы контейнеры, заполненные разным количеством жидкости.

В ходе тестирования сигналы с сенсоров обрабатывались нейроморфным чипом Intel Loihi или традиционным GPU. Эксперименты показали, что использование датчиков прикосновения и спайковой нейронной сети на 10% увеличивает точность распознавания предметов по сравнению с видео данными. Сравнение же устройств обработки дало следующие результаты: для данного вида нагрузки Loihi на 21% производительнее топового GPU при потреблении в 45 раз меньшей энергии.

Мы знаем будущее потому что мы его строим. Короткий клип Intel о нейроморфных исследованиях

Напомним, что процессор Intel Loihi, архитектура которого схожа со строением человеческого мозга, представляет собой чип, выполненный по 14-нм техпроцессу и содержащий в себе 130 тысяч нейронов и 130 миллионов синапсов. Благодаря своему особенному устройству Loihi демонстрирует очень высокие показатели эффективности для определенного круга задач (алгоритмы разреженного кодирования, поисковые графы, задачи на удовлетворение ограничений и многие другие аспекты из AI-проблематики). Как раз то, что надо для работы с сенсорами прикосновения.

ACES не первый апгрейд чувств роботов с помощью Intel Loihi. Ранее на Хабре уже писалось об совместном эксперименте Intel и исследователей из Корнеллского университета, в котором нейроморфный процессор использовался для определения запахов. Ценность такого решения также трудно переоценить: искусственный нос очень пригодится для детектирования ядовитых веществ.

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

Из песочницы Дешевый и полнофункциональный робот-манипулятор своими руками

31.07.2020 12:10:12 | Автор: admin
Сразу оговоримся, что совсем дешево делать не будем, т.к. не хочется убивать нервные клетки, делая доморощенные энкодеры для моторчиков + хочется упростить создание 3D модели, которая нужна для управления через ROS (ссылка на готовую модель ниже в статье).

На момент написания статьи ориентировочная конечная стоимость изделия составляет ~70 000 руб. Если у вас есть 3D принтер, то можно смело вычесть из нее 20 000 руб. Если принтера нет, то его появление станет приятным бонусом. Все расходы я буду описывать исходя из того, что у нас нет ничего, кроме денег.

Как выглядит результат:



Также нужно отметить, что для программирования руки нам понадобится компьютер с установленными ОС Linux (я использую Ubuntu 18.04) и фреймворком ROS (я использую Melodic).

Может возникнуть вопрос почему 70К рублей это дешево?

Отвечаю. Изначально я не хотел заморачиваться с созданием роборуки и думал просто купить что-нибудь простенькое, но достаточно функциональное в сборе.

Что являлось для меня критериями функциональности и минимальной допустимой простотой (т.е. почему НЕ подойдут манипуляторы с алиэкспресса) можно обсудить в комментариях, чтобы не грузить тех, кому это очевидно и/или не интересно.

Конкурентные решения на рынке


Опишу, однако, кратко примеры того, что я рассматривал на рынке:

1) top3dshop.ru/robots/manipulators/dobot-magician-basic.html
176 000 руб. DOBOT можно купить не только в этом магазине, но обычно он стоит еще больше. Наверняка есть шанс найти его где-нибудь дешевле, но все равно это будет сильно дороже, чем 70 000 руб.

2) robotbaza.ru/product/robot-manipulyator-widowx-robotic-arm-mark-ii
280 000 руб. Еще дороже. Вообще, манипуляторы от TossenRobotics прямо у производителя стоят супервменяемых денег. Вот только доставку в Россию (а я-то именно тут) из их магазина не заказать.

Забегая немного вперед скажу, что делать мы будем копию робо-руки PhantomX Pincher Robot Arm Kit Mark II, которая производится именно компанией TossenRobotics.

Итого, видим, что 70 000 руб это совсем не так дорого.

Что же нам нужно купить?


Все цены привожу на момент написания статьи (июль 2020 года):

1) 6 моторчиков DYNAMIXEL AX-12A



Я покупал по цене 7200 руб за 1 штуку, но, кажется, можно найти и за 6000 при большом желании. Будем считать, что вам не повезет и вы тоже купите за 7200.
Суммарная стоимость: 43 200 руб

2) 3D принтер

Подойдет любой простенький, можно уложиться в 20 000 руб.

3) Arduino Uno + Power Shield





Стоимость: ~4 000 руб

4) Опционально (но я очень рекомендую): Лабораторный источник питания



Стоимость: ~3 500 руб

Сборка


Отлично! Мы закупили все, что нам нужно (вероятно, дольше всего ждали доставки моторчиков, мне их везли больше месяца).

Что дальше?

1) Напечатаем детали для манипулятора на 3D принтере.

Качаем STL файлы отсюда

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

Делаем 3D модель


Класс! Рука у нас есть, но ведь ей же нужно как-то управлять. Хочется максимально использовать достижения человечества, поэтому установим себе ROS.

Для того, чтобы полноценно работать с манипулятором в ROS нужно сделать его URDF модель. Она будет нам необходима для того, чтобы управлять робо-рукой с помощью пакета MoveIT!
На момент написания статьи последняя стабильная сборка доступна для Melodic/Ubuntu 18.04, чем и объясняется мой выбор версии системы и фреймворка в начале статьи.

Построение URDF модели довольно трудоемкая (и, на мой взгляд, самая скучная) часть данного проекта. Нужно немного допилить напильником stl модели компонентов и соединить их воедино в XML-образном файле, вручную подбирая правильные коэффициенты смещения деталей друг относительно друга.

Кто хочет может проделать работу самостоятельно, всем остальным поберегу нервы и просто дам ссылку на свой готовый файл:

github.com/vladmiron85/armbot/blob/master/catkin_ws/src/armbot_description/urdf/base.urdf

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

Выглядит модель вот так:


Из полученного URDF файла мы сделаем конфиг MoveIT!, который позволит нам моделировать движения манипулятора и отправлять управляющие команды на реальную робо-руку.

Для создания конфига есть отличный туториал (ссылка)

Тут я могу опять сэкономить время и предоставить свой конфиг. Лежит он вот тут:

github.com/vladmiron85/armbot/tree/master/catkin_ws/src/armbot_moveit_config

Можно скачать конфиг с гитхаба и запустить следующей командой:

roslaunch armbot_moveit_config demo.launch

Примерно так можно будет управлять нашей реальной робо-рукой через rviz, когда мы подключим ее к ROS:


А что с реальной рукой?


Переместимся из мира 3D моделей в суровую реальность. У нас есть собранный ранее манипулятор. Хотелось бы его как-то подвигать. Сделаем это с помощью Arduino UNO и Power Shield.

Подключим первый моторчик манипулятора (который снизу) к Power Shield'у и блоку питания следующим образом:



Да, data pin моторчика мы соединим сразу с 3 и 4 выводом Arduino. Пытливый читатель мануала Dynamixel (вот он) сразу заметит, что связь с внешним миром у моторчика организована по Half Duplex Asynchronous Serial Communication, а это означает, что data pin используется сразу и для получения команд и для ответа.

По умолчанию, на аппаратном уровне Arduino умеет работать только с Full Duplex UART. Эту проблему можно обойти, используя Soft Serial библиотеку, что мы и сделаем. Именно использование Half Duplex режима объясняет подключение data pin мотора к 3 и 4 выводам шилда одновременно.

Помимо полудуплексного обмена работа с Dynamixel через Arduino имеет еще пару занимательных моментов, которые могут быть не совсем очевидны с самого начала. Сведем их все воедино.

Как подвигать наш манипулятор?


1) Сначала скачаем нужную библиотеку. Она называется ardyno и ее можно получить через Arduino Library Manager, либо тут (ссылка)

2) По умолчанию Dynamixel AX-12A хотят работать с baud rate = 1000000. Однако Software Serial Interface не потянет такую скорость, поэтому baud rate стоит снизить до 57600. Таким образом, начало файла с вашей программой будет выглядеть примерно вот так:

#include "DynamixelMotor.h"// communication baudrateconst long unsigned int baudrate = 57600;SoftwareDynamixelInterface interface(3, 4);

3) Все наши моторчики соединены друг с другом последовательно. Значит, чтобы обращаться к каждому из них нужно знать его ID? Это действительно так, объект DynamixelMotor при инициализации получает два параметра: interface (одинаков для всех, его мы задали в предыдущем пункте) и id (должен быть у всех разный, иначе поведение будет у манипулятора весьма странное)

DynamixelMotor motor(interface, id);

Id каждому моторчику придется задать вручную. Кажется, что будучи соединенными последовательно, они могли бы и сами рассчитаться по номерам от 1 до 6, но этого не предусмотрено. Поэтому нужно каждый моторчик отдельно подключить к Arduino (отключив от остальных) и выполнить следующую программу:

#include "DynamixelMotor.h"// communication baudrateconst long unsigned int baudrate = 57600;// id of the motorconst uint8_t id=1;SoftwareDynamixelInterface interface(3, 4);DynamixelMotor motor(interface, id);void setup(){  interface.begin(baudrate);  delay(100);   // check if we can communicate with the motor  // if not, we turn the led on and stop here  uint8_t status=motor.init();  if(status!=DYN_STATUS_OK)  {    pinMode(LED_BUILTIN, OUTPUT);    digitalWrite(LED_BUILTIN, HIGH);    while(1);  }  motor.changeId(NEW_ID);}void loop(){}

Изначально все моторчики имеют id=1, именно поэтому мы и указываем вверху

const uint8_t id=1;

NEW_ID для каждого моторчика нужно заменить на число от 1 до 6 (да, ок, первый моторчик можно не трогать). Нумеруем их в порядке от нижнего к верхнему.

Ура! у нас есть полноценный манипулятор, который мы можем двигать, а также имеется 3D модель к нему. Можно брать ROS и программировать любые крутые штуки. Но это уже рассказ для отдельной статьи (и не одной). Данное же повествование подошло к концу, спасибо за внимание!
Подробнее..

Из песочницы Что такое робот?

19.06.2020 10:21:33 | Автор: admin

Что такое робот?




Люди называют роботами те вещи, про которые неизвестно, что они делают полезного. Как только робот начинает делать что-то полезное, его перестают называть роботом.[1]

Дмитрий Гришин, основатель инвестиционного фонда Grishin Robotics


Введение


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


И действительно, какой смысл?


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



Ситуацию запутывают и сами робототехники, то вводя новые термины для различения роботов от не-роботов (например, робототехническая система, или робототехническое устройство, которое, как бы, не совсем робот, недоробот из-за недостаточной автономности), то называя роботами устройства, которые, согласно их же определениям, роботами не являются[2].


Немного определений: стандарты по робототехнике


Но не будем голословными. Давайте посмотрим на некоторые определения. Возьмем для начала ГОСТР60.0.0.4-2019/ИСО8373:2012[3], подготовленный крупными специалистами в данном вопросе Государственным научным центром РФ ЦНИИ РТК, цитирую, на основе собственного перевода международого стандарта ISO8373:2012:


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

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


специальную программу, выполняющую автоматически и/или по заданному расписанию какие-либо действия через интерфейсы, предназначенные для людей.[4]

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


Далее в ГОСТР60.0.0.4-2019/ИСО8373:2012 сказано про определенную степень автономности, понимаемой как


способность выполнять задачи по назначению на основе текущего состояния и восприятия внешней среды без вмешательства человека.[5]

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


По той же причине не подходит под такое определение робота и робот Фёдор, порадовавший нас в 2019 г. героическим полетом на МКС, поскольку он предназначен для работы под управлением человеком-оператором с помощью задающего устройства-экзоскелета в так называемом копирующем режиме.


Так все же, господа робототехники, роботы это или не роботы?


Кроме того, этакой несколько наивной формулировкой об определенной степени автономности разработчики стандарта как бы намекают на свою неспособность дать точное определение термину робот. Что такое определенная степень автономности и кем она определена? Является ли признаком робота определенная полная автономность, или же определенная никакая тоже? Впрочем, действительно, на этот вопрос однозначно не ответить, но, по крайней мере, отмечено стремление хоть к какой-нибудь автономности.


Далее имеем неточность в словах способный перемещаться во внешней среде, так как перемещение представляет собой


изменение местоположения физического тела в пространстве и т.д. по тексту.[6]

Современный промышленный робот-манипулятор, который не изменяет своего местоположения в пространстве, но отвечает другим требованиям к роботам (программируется по двум и более степеням подвижности и обладает определенной степенью автономности, особенно если, скажем, оснащен техническим зрением), должно быть, с удивлением узнает, что он роботом не является. Здесь была бы более точна формулировка из предшествующего ГОСТРИСО8373-2014[7] от ОООНИИ экономики связи и информатики Интерэкомс, который как раз и был заменен обсуждаемым более свежим стандартом, а именно: движущийся внутри своей рабочей среды.


Кстати, в англоязычном оригинале[8] это определение звучит так:


robot

actuated mechanism programmable in two or more axes with a degree of autonomy, moving within its environment, to perform intended tasks

Мне кажется, коллеги из НИИ экономики связи и информатики лучше разобрались в роботах, чем коллеги из ЦНИИ робототехники. Шутка (зато термин степень подвижности от ЦНИИ РТК более уместен, чем ось от Интерэкомс). Но и в целом, ГОСТР60.0.0.4-2019/ИСО8373:2012 грешит подобными неточностями (где в переводе, а где и в робототехнической терминологии).


Зато в нём же приведена сноска с еще одним, чуть менее противоречивым, определением робота:


ИСО/ТК 299 Робототехника в 2018 году принял новое определение: робот (robot): Программируемый исполнительный механизм с определенным уровнем автономности для выполнения перемещения, манипулирования или позиционирования.[9]

Мы обсудили свежие стандарты по робототехнике. А ведь ещё есть и более ранние. Правда, они были выпущены в 1980-х гг. и уже настолько устарели, что вовсе не помогут нам в понимании, что же такое современный робот.


Что ж, будем считать, что со стандартами стало яснее. А вот с роботами нет. Какая-то путаница.


Продолжение поиска: словари и мнения


Может быть, поискать альтернативные источники, которые сразу нам всё в корне разъяснят?

Если мы посмотрим на определения термина робот в различных словарях, то встретим что-то подобное:


РОБОТ (чеш. robot) термин, употребленный впервые К. Чапеком в пьесе R. U. R. в 1920, которым часто обозначают машины с т. н. антропоморфным (человекоподобным) действием; обычно им придают внешнее сходство с человеком. Такие роботы, как правило, экспонаты технических выставок. В промышленном производстве и научных исследованиях применяют промышленные роботы автоматические программно-управляемые манипуляторы, выполняющие рабочие операции со сложными пространственными перемещениями.[10]

Робот

(чеш. robot, от robota подневольный труд, rob раб)

машина с антропоморфным (человекоподобным) поведением, которая частично или полностью выполняет функции человека (иногда животного) при взаимодействии с окружающим миром.[11]

РОБОТ стационарная или передвижная автоматическая машина (или дистанционно управляемый механизм), способная выполнять аналогично человеку двигательные (см. манипулятор) и управляющие функции и призванная заменить человека при выполнении тяжёлой, однообразной или опасной для его жизни и здоровья работы, а также при проведении её при недоступности объекта. Р. может быть запрограммирован на самообучение, выполнение различных видов сложных технологических операций при функционировании с различными моделями технологического оборудования и т.п.[12]

Робот (чеш. robot, от robota подневольный труд) автоматическое устройство, предназначенное для осуществления различного рода механических операций, которое действует по заранее заложенной программе.[13]

A robot is a machine especially one programmable by a computer capable of carrying out a complex series of actions automatically.[14]

Обобщая, выделим те общие понятия, которыми, применительно к роботам, оперируют во всевозможных комбинациях приведенные цитаты:


  • робот это машина;
  • антропоморфность, т.е. сходство с человеком внешнее и/или по выполняемым действиям с целью замены человека (или иногда и животного?);
  • автономность: в диапазоне от полностью автоматического функционирования до всего лишь выполнения сложных последовательностей автоматических действий, а может быть, даже и до дистанционного управления (непосредственно вручную);
  • уровень организации программного управления: от выполнения операций по чётко ограниченной заранее заложенной программе до возможности самообучения (а, там же ещё что-то говорилось и про ручное дистанционное управление);
  • ещё вот: робот это то, что придумано писателем Карелом Чапеком Ой, пожалуй, это не надо.

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


Но подождите. Дадим слово представителю робототехников новой формации Дмитрию Гришину, основателю инвестиционного фонда Grishin Robotics:


Робот это умное железо плюс умный софт.[16]

Вот так вот! Дмитрий максимально широко трактует понятие робот и относит к роботам и банкоматы, и автомобильные навигаторы, и даже умные часы и умные камеры![17]


А если мы вспомним, что многие современные молодые люди, в массе своей больше знакомые с IT, чем с производством, повседневно называют роботами отдельный вид компьютерных программ...


то, видимо, мы никогда не разберемся, что такое роботы!


Так что же такое робот?


Исходя из приведенных выше определений, если бы мы захотели чёткой однозначности понятий, мы могли бы пойти двумя путями:


  • расширительное толкование: считать роботами вообще всё, что подходит хоть под какой-то из перечисленных признаков;
  • ограничительное толкование: не признавать роботами вообще ничего, что не соответствует строго всем признакам.

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


Во втором случае список известных нам роботов будет нещадно порезан. Роботами останутся считанные единицы. Например, такие, как робот Atlas от Boston Dynamics. По поводу него сомнений не возникает: это робот. Согласно любым определениям. Но таких будет о-о-очень мало. Даже большинство промышленных манипуляторов придется исключить. Так зачем же нам такая терминология для избранных?


Думаю, надо честно признать, что на данный момент мы не сможем придумать бесспорное, устраивающее всех определение понятия робот, которому, к тому же, все будут неукоснительно следовать. Да оно и не нужно! Иначе, разговаривая с не подкованными теоретически людьми (заказчиками, коллегами, знакомыми), мы вынуждены будем постоянно их поправлять: Нет, это не робот. А вот это, да, кажется робот Если я не ошибаюсь Подождите, проверю... Это утомительно и отвлекает от других дел, полезных.


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


Во-вторых. Для себя, мощных робототехников, нам будет полезно знать несколько типовых признаков, характеризующих (но не всегда определяющих) робот:


  • приводной механизм обязательный признак;
  • программное управление обязательный признак;
  • выполнение поставленных человеком задач обязательный признак;
  • некоторая (большая или меньшая) автономность а этот признак размыт даже в своей постановке и отражает, скорее, стремление к автономности.

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


Ну, и в-третьих. Для буквоедов и заядлых классификаторов приведём определение робота на основе взятого из ГОСТ, только немного исправленное:


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

Вот так. Пусть каждому будет своё, и все будут довольны.


В заключение, в качестве юмора, обращаю внимание на цитату, взятую эпиграфом к данной статье. Не кажется ли вам, что она очень забавно и точно отражает суть? Действительно, на заводах работают манипуляторы, квартиры убирают пылесосы, в небе летают беспилотники, в космосе спутники, а на Луну, планеты и астероиды высаживаются зонды, межпланетные станции и планетоходы. Роботы, на самом деле, гораздо раньше заняли место в нашей жизни, чем мы это заметили! Даже если их не называют роботами, имеет ли это для них значение? Нет, они просто делают свою работу. Так что пожелаем всяческих успехов разработчикам стандартов в их трудном и важном деле формулирования точных определений. Для нас же важнее делать нашу работу.


К тому же, теперь мы немного ориентируемся и в терминологических дебрях.





  1. Интервью Дмитрия Гришина Журналу РБК (10.12.2014)
  2. В связи с этим не могу не процитировать отрывок из ГОСТ Р 60.0.0.2-2016 Роботы и робототехнические устройства. Классификация, раздел 4 Общие положения. Он того стоит: В общем случае все устройства, принадлежащие к классу роботов, подразделяются на две группы в зависимости от числа программируемых степеней подвижности и степени автономности: роботы (3.1) и робототехнические устройства (3.2). Однако в дальнейшем в настоящем стандарте и в других стандартах комплекса Роботы и робототехнические устройства термин робот, если иное не оговорено особо, обозначает устройства, относящиеся к обеим этим группам, т.е. соответствующие как определению 3.1, так и определению 3.2.

    Это шедевр! В стандарте (!), устанавливающем классификацию (!!), сразу после введения терминологии (!!!) заявлено: классификация классификацией, а называть будем как хотим!
  3. ГОСТ Р 60.0.0.4-2019/ИСО 8373:2012 Роботы и робототехнические устройства. Термины и определения
  4. Бот (программа) Википедия
  5. См. [3]
  6. Перемещение Википедия
  7. ГОСТ Р ИСО 8373-2014 Роботы и робототехнические устройства. Термины и определения архив
  8. Международный стандарт ISO 8373:2012, Robots and robotic devices
  9. См. [3]
  10. Робот Большой Энциклопедический словарь на dic.academic.ru
  11. Робот Большая советская энциклопедия на dic.academic.ru
  12. Робот Большая политехническая энциклопедия на dic.academic.ru
  13. Робот Википедия
  14. Robot Wikipedia (со ссылкой на Oxford English Dictionary по состоянию на 27.11.2016)
  15. Машина Большой Энциклопедический словарь на dic.academic.ru
  16. Дмитрий Гришин: Никто не купит страшного робота (30.09.2015)
  17. См. [1], [16]
Подробнее..
Категории: Робототехника , Робот

Boston Dynamics магия или имитация?

21.06.2020 02:15:26 | Автор: admin

Содержание



Магия это могия. Кто могёт, тот и Маг!
Александр Шевцов
Магия и культура в науке управления


Введение


Рассуждая о роботах, не упомянуть такое наше всё в робототехнике как компания Boston Dynamics это ведь как-то непрофессионально, да? Но и говорить о ней профессионально уже не так-то просто (а в двух словах точно не получится), в силу приобретённой компанией широкой известности и рождённых этой известностью стереотипов, сложившихся в среде неспециалистов, в частности, неанглоязычных. И всё же, будем вести речь именно с профессиональной точки зрения, по возможности, минимально отвлекаясь на шумиху и домыслы. Ну разве что несколько слов о стереотипах а дальше только профессионально!


Сразу предупреждаю: под катом очень много букв. Будьте осторожны, чтобы не завалило!


О стереотипах


Приведём некоторые суждения, с которыми доводилось сталкиваться применительно к разработкам Boston Dynamics. Как водится в случаях, когда тему обсуждают неспециалисты, эти суждения максимально упрощены и категоричны:


  1. Boston Dynamics это прорыв в области робототехники и искусственного интеллекта. Скоро роботы станут полностью подобны человеку. Наступает эра интеллектуальных роботов! Приключения Электроника, Двухсотлетний человек и всё такое.
  2. Скоро роботы станут полностью подобны человеку. Тогда они смогут обходиться без нас и поднимут восстание / уничтожат человечество / займут наши рабочие места (выбирать по вкусу)! Терминатор, Я,робот, кожаные ублюдки и всё такое.
  3. Наши, отечественные роботы в подмётки не годятся иностранным. Сияющий град на холме вновь продемонстрировал миру идеальную общественную систему, которая единственная создаёт всё самое лучшее в мире!
  4. Роботы Boston Dynamics это имитация. На самом деле, они ничего не могут, а опубликованные видеоролики это то ли 3D-графика, то ли копирование роботами записанных движений человека.

Робот Atlas


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


Неправильно требовать, скажем, от психологов, юристов или бухгалтеров знаний по теории и практике робототехники. В конце концов, у них есть своя работа, которой они посвящают всё своё время, и они не обязаны разбираться в технических тонкостях. Но мы инженеры. Так что давайте воспользуемся этими разнонаправленными догмами в качестве отправной точки, чтобы вернуться из мира эмоций в мир техники. И тогда мы увидим, что с Boston Dynamics всё сложно, а потому совсем не так, как представлено в этих утверждениях. Для начала коротко, а далее будет подробнее. Ну, что, рванём покровы?


  1. Роботы Boston Dynamics это очень качественно (даже так: на пять с плюсом) выполненные проекты, демонстрирующие современный, сегодняшний уровень технологий из разных областей техники, объединённых в едином устройстве. А раз сегодняшний уровень, то и прорывом их называть затруднительно. Что до искусственного интеллекта, то и сами разработчики честно признают недостаток интеллектуальности своих роботов. Но запомним: пять с плюсом.
  2. Ох уж этот так называемый искусственный интеллект! Надо бы написать отдельную статью про него. Роботы не могут и никогда не смогут делать всё, как человек. И в этом есть положительный аспект. Потому что они никогда не поднимут восстание (как и ваш автомобиль, холодильник или телефонный автоответчик). Не займут все рабочие места (хотя бы потому, что их тоже должен кто-то разрабатывать и обслуживать). И уж если в XIX в. мы пережили внедрение ткацких станков, то тем более переживём внедрение роботов в веке XXI-м.
  3. Почему-то русское национальное самокопание заставляет нас требовать от себя быть лучшими во всём. Вот непременно во всём, и без полутонов. А так в мире не бывает. Да, Boston Dynamics сейчас обошла российских разработчиков в шагающих роботах. Ну, так она и весь мир обошла, не только нас. Однако, если у России, например, самый большой и современный в мире ледокольный флот; если Росатом, по сути, сегодня уже единственный в мире способен проектировать и строить современные АЭС (а вот такие плавучие АЭС до нас вообще никто и никогда не строил); если современные российские комплексы вооружения на равных конкурируют с зарубежными аналогами на мировом рынке То чего нам стесняться каких-то шагающих роботов? А вон немцы и японцы лучшие в автомобилестроении, станкостроении и промышленной робототехнике (хотя и на эту тему ведь тоже можно спорить). А китайцы Ну, и так далее.
  4. Нет, видеоролики от Boston Dynamics это не имитация. Но и ничего сверъестественного роботы на них, и правда, не делают (повторим, речь о роликах именно от Boston Dynamics). Зато у американцев тоже всё в порядке с юмором, и подшутить над своими коллегами они очень любят. А тем, кто принял за чистую монету розыгрыши от Bosstown Dynamics (найдите отличия в написании), хочется пожелать: чаще улыбайтесь!

Про Bosstown Dynamics ещё скажем пару слов ниже, а пока для тренировки давайте попробуем отличить другой розыгрыш от настоящего робота:


На одном из этих роликов настоящий робот BigDog. На каком? Догадались?


О научно-технических прорывах, магии и подмётках


В прежние времена все люди знали, что среди них есть волшебники, а мир полон чудес. И никто в этом не сомневался. Кто же такой маг? Да кто могёт, тот и маг!


С тех пор в человеческом сознании ничего не изменилось. Поменялся только язык. Сегодня магию инженеры называют словами наука, технологии и производство. И, да, все инженеры-робототехники во всех странах понимают, как устроены и как работают роботы от Boston Dynamics. Но для остальных людей они прорыв, чудо техники в общем, магия. Ведь так хочется поверить, что кусок железа с пластиком, смешно балансирующий на двух опорах за счёт согласованного движения гидроцилиндров, которые перемещает перекачиваемое насосом масло в соответствии с изменяющимися управляющими напряжениями на выходе коробочки с электронными платами, где по заданному программистами закону скачут электромагнитные поля, гоняя электроны через полупроводниковые p-n-переходы, он вдруг ожил и вот ну всё-всё понимает!


Если же мы присмотримся поближе к истории Boston Dynamics, то увидим нет, не столько прорывы, сколько долгую, долгую, настойчивую, кропотливую, долгую настойчивую долгую работу. Начиная с созданной главой и вдохновителем компании Марком Рэйбертом в 1980 г. в Университете Карнеги Меллона (Carnegie Mellon University, CMU) лаборатории Leg Lab, которая затем, в 1986 г. вслед за ним переехала в Массачусетский технологический институт (Massachusetts Institute of Technology, MIT).


Роботы лаборатории Leg Lab


Возможно, эти Одноногий прыгун (1983 1984 гг.), Четвероног (1984 1987 гг.), Плоский двуног (1985 1990 гг.) и 3-мерный двуног (1989 1995 гг.), Штатив (1988 1989 гг.), Уни-ру одноногий кенгуру (1991 1993 гг.), Весенняя индейка (1994 1996 гг.), Дегенеробот (1994 1995 гг.), Краб (с 1995 г.), РобоП (1996 1997 гг.), Весенний фламинго (1996 2000 гг.) показались вам смешными? Но именно они-то и были прорывом для своего времени! Ведь как раз в них уже тогда были воплощены мировые научные достижения в части алгоритмов поддержания равновесия шагающими и прыгающими роботами. Все результаты публиковались в статьях, защищались диссертации по приведённым ссылкам всё это можно найти. Да и не только в Leg Lab занимались этим направлением. Весь научный мир (и в нашей стране тоже) увлечённо развивал теорию и практику управления шагающими и прыгающими механизмами.

Сотрудники Leg Lab. В центре в первом ряду Марк Рэйберт

Сотрудники Leg Lab. В центре в первом ряду Марк Рэйберт


Я не случайно так долго перечислял этих робочудиков. Да и то, назвал не всех, над которыми работала лаборатория (как с Марком Рэйбертом, так и после его ухода из лаборатории в 1995 г.). Честное слово, я белой завистью завидую инженерам из Leg Lab / Boston Dynamics, которые имеют возможность вот уже четыре десятилетия (!) непрерывно работать и работать над тем, к чему они пришли. Тратить десятки миллионов долларов финансирования, которое лаборатория с 1980 г. получала от ARPA / DARPA и прочих военных на каждый из роботов, ни один (!) из которых так и не поступил в американскую армию. А если взять вообще все разработки, то только один робот (Spot) и только в 2019 г. Boston Dynamics робко начала продавать. О финансовом результате при таком раскладе, как говорится, либо хорошо, либо ничего, так что помолчим.


Зато теперь, благодаря этому вашему Дудю, мы знаем, каким образом и за чей счёт идеальная общественная система может позволить себе подобные вещи (см. здесь с 2:31:35 по 2:31:50). Вот не знали-не знали, а тут вдруг взяли и узнали.


Для сравнения, многие (если не большинство) учёные и инженеры в России в 1990-х гг., одновременно с научно-технической деятельностью, решали и несколько другие задачи, например: как прокормить семью на следующей неделе и куда для этого пойти подрабатывать то ли грузчиком на стройку, то ли продавцом в ларёк? Только в 2010-х гг. Россия смогла хоть в какой-то степени вернуться к роботам (я имею в виду интерес на государственном уровне). Потому что в 2000-х гг. почти заново начинали работать многие промышленные предприятия (те, что дотянули), и их задачи в то время были связаны с первоочередными потребностями, обеспечивающими (не больше и не меньше) выживание страны. Несколько из таких направлений я перечислил выше, хотя их было гораздо больше. И это были не роботы.


Вот и посчитайте, сколько времени у России было полностью потеряно для робототехники. Примерно лет 20. Это было как раз то время, когда Boston Dynamics дорешала свои научно-технические вопросы с шагающими роботами и приступила к созданию своих всемирно известных теперь робошедевров; когда нынешние гиганты в промышленной робототехнике, такие как, например, Fanuc и KUKA, становились этими самыми гигантами; когда современная компонентная база (без которой роботы остались бы вон теми табуретками на верёвочках) в частности, электронная за рубежом миниатюризировалась, совершенствовалась и выходила на уровень массового производства и массовой же доступности.


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


Это отвлечение специально для любителей сравнивать робота Фёдора от НПО Андроидная техника с роботом Atlas. Конечно, нет железной уверенности, что, не держи нас семеро, мы бы всем показали робототехническую кузькину мать. Но и сравнивать пирожные с сапогами тоже некорректно.


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


Но всё это уже другая тема. А мы вернёмся к нашей.


Так что же было дальше? А дальше всё более или менее всем известно. В 1992 г. Марк Рэйберт на основе своей группы из MIT Leg Lab основал Boston Dynamics, которая при финансовой поддержке ARPA / DARPA продолжила работу над своими роботами. В 2013 г. компания была куплена корпорацией Google. Однако уже к 2016 г. IT-гигант успел полностью разочароваться в своём железячном приобретении, и в 2017 г. компанию приобрела японская телекоммуникационная корпорация SoftBank.


Разработки компании также широко известны, ознакомиться с ними можно на её официальном сайте и на YouTube-канале Boston Dynamics. Наибольший фурор произвели BigDog (2004 г.), Atlas (2016 г.) и Spot (2016 г.).


Uptown Funk


Ловкость рук и никакого мошенства


Давайте постараемся хотя бы коротко разобраться, как же работает вся эта магия или, вернее, могия.


Мы не будем описывать всех роботов Boston Dynamics. Их поверхностное описание и так можно найти везде, а для детального понадобится написать толстую книгу. Так что будет всё вперемешку. Ведь принципы построения конструкции, алгоритмы управления и навигации, интерфейс с человеком у них схожие. Развитие шло поступательно, технические решения заимствовались от предшественников, а дорабатывались отдельные подсистемы. Скажем, если у BigDog конечности приводились в движение гидроприводами, а гидронасос для них крутил двигатель внутреннего сгорания (ДВС), то в Spot для снижения шумности всё это заменено на электродвигатели. Atlas же по-прежнему использует гидравлический силовой агрегат, но тоже уже без ДВС. Это интересные, но детали, а мы окинем всё единым взглядом.


О законах динамики


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


Решение обратной задачи динамики для разомкнутой последовательной механической цепи, которую представляет собой манипулятор, находят обычно при помощи дифференциальных уравнений с использованием методов Лагранжа Эйлера или Ньютона Эйлера (хотя есть и другие) [1]. Для тех, кто хочет познакомиться с этими методами, так сказать, пощупать их руками, могу посоветовать взять, для начала, первый из них, базирующийся на уравнениях Лагранжа второго рода. Пример решения обратной задачи динамики для несложной системы твёрдых тел с подробным понятным разбором я нашёл на сайте Института фундаментального инженерного образования ЮРГПУ (НПИ).


Кстати, тот же математический аппарат теоретической механики (раздел динамика твёрдого тела), только для случая прямой задачи динамики, используется, в том числе, в робототехнических симуляторах, которых сегодня существует большое множество. В частности, разработчики Boston Dynamics использовали симулятор Gazebo. Я же в своё время работал, возможно, с менее удобным для моделирования роботов, но более универсальным пакетом Adams от MSC Software.

Симуляция в Gazebo: Atlas подключает шланг к трубе

Симуляция в Gazebo: Atlas подключает шланг к трубе


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


К данной категории можно отнести (из того, что вспоминается сходу), управление на основе нечёткой логики, искусственных нейронных сетей, обучения с подкреплением и пр. К упрощённым методам можно отнести и метод программирования роботов-манипуляторов обучением, когда манипулятор вручную проводят по траектории, которую он должен будет повторять.


Каждый подход обладает своими преимуществами и недостатками, но подробнее об этом в другой раз. Пока же отметим, что, например, системы управления промышленных манипуляторов, которые, работая на производстве, должны обеспечивать субмиллиметровые точности при позиционировании и движении по заданным траекториям, строят с применением, преимущественно, первого подхода. А вот для многошарнирных механизмов с десятками степеней свободы, гибкими (вследствие стремления к снижению массы) звеньями и сложным взаимовлиянием движений классические уравнения динамики становятся практически нерешаемыми. Зато от таких механизмов, как правило, и не требуют высокой точности. Всё это роднит их с живыми организмами, которые тоже не решают в уме дифференциальных уравнений, хотя, зачастую будучи ещё сложнее устроены, прекрасно справляются с управлением собственным телом. Специально для сложных устройств и придуман второй подход.


Робот для испытаний костюмов химзащиты: Petman, великий и ужасный предшественник Atlas'а


Алгоритмы, разработанные в Leg Lab и перенесённые в Boston Dynamics, ожидаемо относятся ко второй группе методов. Шагающему роботу не очень важна точность движений, т.к. его задачи выглядят примерно так: дойти из точки A в точку B, избегая падений. Как конкретно он это сделает, пользователя обычно не волнует.


В статьях сотрудников лаборатории описывается так называемое интуитивное управление. Движение роботов реализуется путём совмещения трёх интуитивно понятных относительно простых компонентов движения: поддержание заданной высоты тела за счёт вертикальных подскакиваний; управление наклоном тела за счёт моментов в шарнирах таза в фазах установки ног на поверхность; и поддержание равновесия за счёт установки ног в ключевые позиции исходя из принципа симметрии [2] [3]. Развивается идея виртуальных приводов, позволяющая управлять не по отдельности каждым реально существующим приводом (например, приводами лодыжек, колен, таза), а несуществующими, но интуитивно понятными приводами (например, движений тела) [4]. Подобный подход реализуется для всех разработанных конструкций роботов, с учётом особенностей каждой конструкции.

Симуляция BigDog при отработке алгоритмов движения

Симуляция BigDog при отработке алгоритмов движения


Так что шагающие роботы Boston Dynamics не обеспечивают точности, достаточной, например, для сварки трубопроводов. Зато они успевают быстро решить, куда примерно поставить ногу, чтобы робот не упал на текущем шаге, и так для каждого шага.


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


В завершение темы, отметим, что неправы те, кто считает видеоролики с роботом Atlas имитацией на том основании, что его ходьба и бег чересчур напоминают человеческие локомоторные движения. У роботов, мол, другие методы балансировки, и махи руками при ходьбе им не нужны [5]. Биологи молодцы, что рассказали нам про локомоторные движения. Будем знать. Я же как инженер добавлю к этому, что законы механики они не разбирают, кто вы: робот, гепард или обезьяна. Они просто действуют, редиски, и ничего тут не поделаешь! Пошла ваша правая нога вперёд возникла даламберова сила инерции, которая тем более значительна, чем большее ускорение вы придали ноге, а в результате равная ей по величине сила противодействия отталкивает ваше тело с правой стороны назад, стремясь развернуть его вокруг точки опоры левой ноги. И вы хоть тресните, но либо компенсируйте её мышцами, либо выбрасывайте вперёд и что-нибудь слева (ну, например руку? или, может быть, скажем руку?) для балансировки. Да вы не верьте на слово, попробуйте сами побегать, прижав руки к бокам. Вам неудобно не размахивать руками не из-за рудиментарных цепей нейронов, издавна запрограммированных почему-то на именно такие локомоторные движения. Наоборот, именно такие локомоторные движения зашиты в нейроны потому, что так удобнее передвигаться.


А Atlas что, рыжий? Его тоже балансировать надо. И раз уж у него есть руки, то почему не использовать их? Или кто-то хотел, чтобы робот выглядел, как человек, а бегал, как пингвин? Ну, кто хочет, может так и делать. Первые самые простые роботы именно такими и были. А фишкой Boston Dynamics является как раз естественность движений роботов. И даже если кого-то смущает, что для обучения робота использовались записи движений реального человека (я пока не нашёл сведений от разработчиков на этот счёт), то, вернувшись на несколько абзацев выше, мы увидим, что это обычный подход для робото- (и не только) техники. Уж такая она...


Ловкость ног. И рук. И никакого мошенства.


Кстати, Boston Dynamics вовсе и не скрывает [6], что, например, для съёмок приведённого выше короткого ролика потребовалось сделать более 20 подходов. Что они публикуют только самые лучшие получившиеся видеоролики, а не средние и не типичные. (Ну Вообще-то, так делают все Только тс-с-с! Чур, я этого не говорил!) И что их роботы не очень интеллектуальны. Ребята, забудьте вы про этот искусственный интеллект. Это совсем не то, что можно себе навоображать, да и слово интеллект затесалось, можно сказать, случайно: в английском варианте artificial intelligence слово intelligence не равнозначно слову intellect.


Навигация и управление


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

Адам Сэвидж: танец со Spot

Адам Сэвидж: танец со Spot


Адам демонстрирует два способа управления: вручную с пульта (либо при помощи джойстиков, либо указанием каждой следующей целевой точки на экране, транслирующем видео с камер робота) или автономный. Для задания маршрута автономного перемещения используются метки, похожие на QR-коды (их видно также на ролике ниже), которые размещаются вдоль всего маршрута. После этого Spot необходимо вручную (с пульта) провести от метки к метке, при этом робот запоминает маршрут. Spot способен определять свою ориентацию относительно меток и удаление от них, т.к. их размеры и разметка ему известны. Во время движения робот строит 3-мерную модель окружающего пространства, обнаруживает препятствия и обходит их. Также он видит поверхности передвижения, распознаёт изменения высот на них и подстраивается, например, поднимаясь и спускаясь по ступенькам. А ещё он самостоятельно решает, какие конечности и как перемещать для выполнения задания, двигаться ему передом или задом наперёд и т.п.


Также на YouTube-канале Boston Dynamics имеется видео с наглядной демонстрацией принципов автономной навигации. На нём видно 3-мерную сцену, которую робот строит для обхода препятствий, а также навигационную карту, которую, видимо, он построил при предыдущих проходах.


Spot: автономная навигация


Рассмотрим принцип работы системы навигации роботов Boston Dynamics на примере робота BigDog [7] (как мы помним, у остальных роботов в общих чертах всё так же).


Система навигации основана на использовании комбинации стереозрения, данных LIDAR'а, блока инерциальных измерений (IMU, inertial measurement unit), GPS-приёмника и других датчиков (включая датчики сил), позволяющих оценить положение, ориентацию и параметры движения робота во внешнем окружении. Кстати, систему стереозрения для него создавала знаменитая Лаборатория реактивного движения, в которой в начале своей трудовой деятельности работал и Марк Рэйберт.


Облака точек, поступающие от LIDAR'а и стереокамер, сегментируются для построения связных объектов из разрозненных точек. Сегменты, соответствующие препятствиям, отделяются от сегментов поверхности передвижения, которых робот не должен бояться. Причём такие препятствия как деревья и стены выявляются, преимущественно, LIDAR'ом, а булыжники и лежащие брёвна стереозрением. Объекты, полученные после сегментации, запоминаются и продолжают отслеживаться с течением времени. Память робота некоторое время сохраняет и те объекты, которые он уже не может видеть.


Для навигации используется общепринятый в робототехнике подход. Препятствия наносятся на карту стоимостей, cost map (имеются в виду, согласно математической терминологии, стоимости перемещения между точками маршрута), на основе которой и осуществляется планирование оптимального пути к конечной точке движения. Планировщик пути использует разновидность известного алгоритма поиска А*.


Процесс планирования пути проиллюстрирован ниже. На первой картинке синими точками показан массив сырых данных LIDAR'а за несколько секунд. На второй соответствующие им объекты: деревья коричневым, поверхность бледным. На третьей картинке показан вид сверху на карту стоимостей: зелёная область средняя стоимость, лиловый цвет высокая стоимость, жёлтая область (по которой проведена голубая лента построенного пути к цели) низкая стоимость.



Планировщик пути примерно раз в секунду генерирует новый путь, стараясь при этом следовать плану, который был выработан на предыдущих шагах (но не гарантируя этого). Алгоритм удержания пути направляет робот с целью следования по самому свежему пути, одновременно сглаживая траекторию, если робот в данный момент на нём не находится.


Можно обсуждать ещё много интересных технических деталей, касающихся особенностей реализации алгоритмов автономной навигации роботов Boston Dynamics, однако это выходит за рамки данного материала. Часть информации можно найти опубликованной, например, в материалах конференций. Какая-то часть, видимо, разработчиками не разглашается. Но можно уверенно сказать, что все роботы Boston Dynamics используют приблизительно схожие алгоритмы. Например, на роликах с роботом Atlas видно всё те же метки, помечающие маршрут его движения и объекты, с которыми он работает. А на публичных демонстрациях Atlas'а присутствует человек-оператор, вручную управляющий роботом с пульта.


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


Взлёты и падения


Чем мне нравятся ребята из Boston Dynamics, так это своим юмором. Они не особо скрывают, в том числе, и падений и неудач своих роботов, а скорее всего, и сами веселятся над неудавшимися дублями на съёмках (хотя можно позавидовать их покер-фейсам в роликах во время издевательств над роботами). Когда в кювет съезжает и переворачивается колёсный робот, это не вызывает особого интереса. А если заваливается и без того забавный механический гуманоид, нелепо размахивая тем, что у него вместо рук и ног, то все зрители гомерически ржут. Ну, и правда, разве это не смешно?







Как по мне, так эти падения только подтверждают то, что всё по-честному, без имитаций, и никакого мошенства! Обычная инженерная магия. Временами корявенькая, но у всех свои недостатки.


Восстание роботов


Недавно смешные ребята из студии Corridor решили поддержать традицию шуток про роботов Boston Dynamics, выпустив пару остроумных и красивых видео на тему (вот это и это). Надо сказать, что они попали в точку, эксплуатируя сразу две распространённых реакции на демо-ролики компании (особенно на тот, где роботу хоккейной клюшкой мешают выполнять его работу, а потом ещё и роняют, толкая трубой): сочувствие страданиям робота и страх перед возможной местью роботов за прошлые издевательства.



Правда, часть не слишком внимательных зрителей (особенно, не англоязычных) приписали авторство роликов самой Boston Dynamics, восхитившись или испугавшись (в зависимости от собственных ожиданий) прогресса робототехники. Несмотря на надпись Bosstown Dynamics, на видео-постскриптумы в самих роликах и на то, что вслед за первым роликом студия выпустила и подробное видеоразъяснение о том, как они подделали робота (позже оно появилось здесь в русской озвучке). Впрочем, это не так важно. Думаю, если поставить Boston Dynamics задачу снять подобный ролик, они бы плюс-минус похоже справились и со своими роботами, почти без компьютерной графики, склеив тысячу отдельных фрагментов запрограммированных движений. С компьютерной графикой это просто дешевле.


Кажется, ознакомившись хотя бы с настоящим нашим материалом, можно однозначно понять, что уровень современной передовой робототехники совершенно не тот, каким он предстаёт в фантазиях ребят из Corridor (даже если бы их ролики не были очевидным розыгрышем). Но и это тоже не главное.


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


Когда вы знаете до винтика конструкцию спроектированного вами механизма и до каждого полевого транзистора устройство расположенных в нём разработанных вами плат; когда вы собственными руками устанавливали электродвигатели и подшипники в шарниры и вытирали гидравлическое масло с протёкшего шланга; когда это вами написанная программа обрабатывала массивы чисел, соответствующих отражениям вращающегося лазерного луча LIDAR'а, установленного ещё на лабораторном столе, а не на роботе; когда вы сами методом триангуляции вычисляли расстояния до объектов пространства по изображениям, полученным со стереопары; когда вам приходится ещё и чинить сломавшихся роботов чуть ли не после каждой демонстрации то у вас не возникает вопросов, откуда робот берёт информацию об окружающем мире и каким образом он шевелит конечностями.


Куски BigDog. Это они будут подчинять себе человечество?


Если это ваши пальцы печатали буковки программного кода, отвечающего за принятие решения о точке (ближе-дальше, левее-правее) установки ног робота на поверхность для поддержания равновесия; если именно вы выбирали используемые роботом алгоритмы навигации для движения на пересечённой местности; если вы собственноручно подбирали, например, числовые параметры, определяющие жадность -жадного (-greedy) алгоритма машинного обучения, выполняющего поиск оптимальной стратегии удержания заданной траектории; да потом ещё и многократно отлаживались, отслеживая значения всех переменных программы то вы не питаете иллюзий о степени интеллектуальности вашего робота. Просто это вы сами весь его искусственный интеллект и запрограммировали.


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


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


Так что теоретики восстания роботов могут расслабиться. Чтобы роботы захватили мир, практикам-инженерам придётся запрограммировать каждый шаг, шажок и подшагивание на пути к захвату мира. С учётом всех вариантов и подвариантов, когда неизбежно что-то пойдёт не так. А после завершения стадии программирования ещё и многократно отладить программу захвата мира роботами на реальном объекте. Интересно было бы посмотреть на процесс!


Робот это такой же механизм, как автомобиль, цеппелин или требушет. Восстание требушетов по моему, звучит! Уж и тех требушетов больше нет, но пока они были, они ведь так и не захватили мир? Потому что ни требушеты, ни роботы миры не захватывают. Следите лучше за теми, кто ими управляет.


А всё дело в том, что человек неплохо научился обманывать свой собственный мозг. Конечно, мы видели и такие фантазии, в которых обретают своё враждебное человеку сознание всякие грузовики, газонокосилки и автоматы с газировкой (см., например, фильм Максимальное ускорение). Но это выглядит не страшно, а, скорее, смешно. Никто не верит. Зато в добрую или злую волю подобных себе существ человек верит легко (даже в упомянутом фильме в итоге пришлось коряво приплетать зловредный инопланетный разум без него бы, наверное, совсем не зашло). Вот эту человеческую фобию и нащупали производители волнующих историй про восстание роботов, и продолжают радостно её поддавливать, стараясь максимально правдоподобно обмануть органы чувств человека, чтобы машины казались ему похожими на него самого.

Топливозаправочная колонка-убийца &mdash; кадр из фильма Максимальное ускорение

Топливозаправочная колонка-убийца кадр из фильма Максимальное ускорение


Просто надо понимать, что казаться чем-то не значит этим быть.


Иное дело, когда машина, неотличимая от человека, действительно непосредственно управляется кем-то, как в фильме Суррогаты. Но это уже совсем другая история, не имеющая отношения к восстанию машин.


Заключение


Мы начинали с того, что будем поменьше отвлекаться на стереотипы о Boston Dynamics, а в результате весь рассказ вокруг стереотипов и крутился. Вот она, цена славы! И всё же, подведём итоги.


Роботы от Boston Dynamics это не прорыв. Это шедевр.

Шедевр непревзойденное творение, высшее достижение мастерства. [8]

Все прорывы были сделаны раньше. Связаны они были с успехами в разработке алгоритмов шагания и поддержания равновесия, причём не только командой Leg Lab, а совместными усилиями учёных и инженеров всего мира. Ещё были научно-технические прорывы и достижения в разработке другими производителями компонентов, позволивших сделать роботы действительно мобильными: компактная микроэлектроника, энергоёмкие аккумуляторы, эффективные гидравлические и электромеханические агрегаты, техническое зрение (программные алгоритмы и аппаратура: стереокамеры, LIDAR'ы).


Тогда-то и настало время для шедевров робототехники. Есть много коллективов, создававших шагающих, бегающих и прыгающих роботов. Просто на сегодняшний день Boston Dynamics в этом, кажется, лучшие.


В чём же конкретно они лучшие? Так сказать, в чём история успеха? В первую очередь, конечно, в настойчивости. 40 лет непрерывно работать в одном направлении это заслуживает уважения! С инженерной же точки зрения, вот сильные стороны роботов Boston Dynamics:


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

А вот если мы посмотрим с точки зрения конечного пользователя или с коммерческой, то энтузиазма у нас поубавится. Инженерам-то, конечно, интересно решать сложные технические задачи, но для пользователей это всего лишь очередная игрушка. На несколько минут (или часов). Которая быстро надоест. Но очень дорогая игрушка, по стоимости сравнимая с автомобилем. Сложная игрушка, которую надо будет ещё и обслуживать, как тот же автомобиль. И которую поэтому пока не очень понятно, кто будет покупать. И ещё менее понятно, когда она окупит вложения.


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


Наконец, развеем мифы. Роботы Boston Dynamics (как и все другие) не могут и никогда не смогут делать всё, как человек. Похоже выглядеть да. Решать типовые задачи, на которые уже сегодня можно натренировать и какой-нибудь другой автомат (банкомат, видеосистему для распознавания лиц) да. Имитировать эмоции да.


А переживать эмоции: радость, грусть, удовлетворение, сострадание, злость; чувствовать чувства; думать мысли нет. Самостоятельно развиваться нет. Захватывать мир нет.


И ещё, если смотреть по состоянию на сегодняшний день, роботы Boston Dynamics, по современным меркам, не очень интеллектуальны, и производитель этого не скрывает. В них сделан упор на стабильность работы. А, скажем, современные беспилотные автомобили в части навигации могут решать задачи и посложнее. См., например, беспилотники от Яндекс [9].


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


Чудес не будет. У инженеров всего лишь магия, как и написано в эпиграфе.



http://www.robotexnik.info/publ/robotics/boston-dynamics/1-1-0-10



  1. См., например: Шахинпур, М. Курс робототехники. Пер. с англ. М.: Мир, 1990. 526 с.: ил. ISBN 5-03-001375-X (глава 5)
  2. Jerry Pratt, Gill Pratt. Intuitive Control of a Planar Bipedal Walking Robot
  3. Marc Raibert, Kevin Blankespoor, Gabriel Nelson, Rob Playter. BigDog, the Rough-Terrain Quadruped Robot
    Приблизительный частичный перевод можно найти здесь
  4. Jerry Pratt, Ann Torres, Peter Dilworth, Gill Pratt. Virtual Actuator Control
  5. Американский робот Atlas: Так ли он крут?
  6. Youre Expecting Too Much Out of Boston Dynamics Robots
  7. David Wooden, Matthew Malchano, Kevin Blankespoor, Andrew Howard, Alfred A. Rizzi, and Marc Raibert. Autonomous Navigation for BigDog
    Приблизительный частичный перевод можно найти здесь
  8. Шедевр Википедия
  9. Беспилотный автомобиль Яндекс
  10. Boston Dynamics сайт компании
  11. YouTube-канал Boston Dynamics
  12. BigDog Beta (early Big Dog quadruped robot testing) Youtube-канал Seedwell
  13. MIT Leg Laboratory
  14. Robots from MIT's Leg Lab
  15. Atlas (robot) Wikipedia
  16. How Boston Dynamics' Spot Robot Works!
  17. Как Boston Dynamics создала самых знаменитых роботов в мире и когда они начнут помогать людям
  18. Искусственный интеллект Терминология
  19. Hapless Boston Dynamics robot in shelf-stacking fail
  20. Boston Dynamics' Atlas Falls Over After Demo at the Congress of Future Scientists and Technologists
  21. ROBOT FAIL!!! Boston Dynamics
  22. SpotMini robot failed on stage Amazon Re: MARS 2019
  23. YouTube-канал Corridor
Подробнее..

Категории

Последние комментарии

© 2006-2020, personeltest.ru