Вкладываясь в точки, а не линии

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

image

Признаюсь, я немного старомоден в сфере Европейских венчурных проектов. Я стал работать аналитиком венчурного фонда в Атласе почти десять лет назад. Моими наставниками стали Фред Дестин и Сонали де Рикер, которые сейчас являются партнёрами в Accel Partners. Во многом они повторяли советы Марка: надо вкладывать в процесс, в идеальном варианте, способствуя росту бизнеса, там, где вы разбираетесь в подспудных движущих силах бизнеса, понимаете динамику работы команды и экономику данной сферы.

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

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

В Sunstone, где средний размер привлекаемых инвестиций-120 миллионов долларов, мы вкладываем деньги и на посевном раунде, и раундах серии А (от 100 000 до 5 миллионов долларов); комбинация этих рыночных сил и понимание того, что именно инвестиции на очень ранних стадиях развития и позволяют нам оставаться в группе ведущих организаций Европы (на бумаге!), и мы сейчас не боимся инвестировать тогда, когда ещё не видно никакого прогресса и развития. Примерно в трети случаев, мы инвестируем в точку, а не в линию.

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

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

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

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

В следующе статье я расскажу о том, как справляться с неизбежным выбором между «посевным инвестированием как опцией» и «социальными контактами с предпринимателем» Спойлер: предприниматель и есть клиент, глупцы!

А пока, смело обращайтесь ко мне, если вам нужно каких-то 100 000 долларов. Может я влюблюсь в вашу точку.

Всего хорошего.

image
Любовь с первого взгляда. Это верно и для венчурных фондов.

P.S.: Я большой поклонник Марка. Наша совместная портфельная компания Seriously-разработчик игр Best Friends сейчас на высоте. Не представляю, как Марк одновременно управляет медиа-компанией и занимается венчурным фондом, но да прибудет с ним и его «Snapstorms» сила. В конце концов, инвестирование в компанию «Seriously» тоже было вложением средств в «точку» 🙂

Оригинал: Invest in Lines, Not Dots
ссылка на оригинал статьи https://habrahabr.ru/post/316568/

Новое поколение продуктов Cambium Networks: ePMP Elevate

image
Сегодня компания Cambium Networks презентовала новый продукт линейки ePMP под названием ePMP Elevate. Продукт координально отличается от всех предшественников.

На эот раз, продукт полностью програмный, и позволяет устаналивать прошивку ePMP Elevate на “железо” других вендоров, таких как Ubiquiti и Mikrotik. ePMP Elevate будет поддерживать все протоколы беспроводной передачи данных присущие линейке продуктов ePMP1000/2000.

В первую очередь ePMP Elevate поддерживает протокол TDD (Time Division Duplex), что позвляет использовать все основные приемущества TDMA:
— GPS синхронизация;
— Переиспользование частот;
— Air Fairness (Весь сектор не ощутит наличия, одной станции с низким сигналом);

ePMP Elevate – являются исключительно абонентскими станциями и не могут быть преключены в режим базовой станции.

Также после установки ePMP Elevate все устройства получат такие приемщущества, хорошо знакомые пользователям продуктов ePMP1000/2000:
— Емкость сектора (до 120 абонентских станций);
— Отличные показатели качества в условиях зашумленности;
— Поддержка бимформинга;
— Большое кол-во сетевых и менеджмент настроек;
— Использование единной системы управления и мониторинга в сети – cnMaestro;

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

Для работы c ePMP Elevate, необходимо докупать специальную лицензию, которая устанавливается на базовую станцию.

Информация по лицензии:
1 юнит – Product Number C050900S501A1
10 юнитов – Product Number C050900S510A1
ссылка на оригинал статьи https://habrahabr.ru/post/316564/

Китай превращает большие данные в «Большого брата»


Фрагмент популярного реалити-шоу

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

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

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

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

Конечно, потерять «социальный» рейтинг можно не только из-за попыток обмануть систему пропуска в метрополитене. Это касается всего — асоциального поведения, попыток обмануть налогового инспектора, нарушения правил планирования семьи.

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

«Сможем ли мы реализовать этот проект или нет — пока неясно, мы находимся в состоянии неопределенности. В любом случае, это лучше, чем то, что работало все предыдущие годы, когда у нас не было данных [о гражданах — прим. ред], и полиция судила о людях, исходя из сведений, полученных от других людей», — заявил Менг Тингуанг, политолог из университета Циньхуа.


Принцип работы описываемой в материале системы. По плану, все должно работать примерно так

Администрация Шанхая опубликовала на своей веб-странице несколько подробностей о системе мониторинга граждан по своему региону. В частности, подтверждается информация о том, что нарушения законов будут влиять на рейтинг благонадежности. Среди проступков — срыв сроков оплаты штрафов и нарушение правил дорожного движения. Получение «очков неблагонадежности» приведет к увеличению количества условий для получения кредита в банке или и вовсе отказ в банковском кредитовании. В некоторых случаях речь идет о невозможности получить скидку на услуги каких-либо компаний.

Система, которая отрабатывается в Шанхае, пока что находится в ранней стадии своего развития. У местных жителей есть возможность просматривать свои данные, это можно сделать на специальном ресурсе. Пока что, по словам журналистов The Wall Street Journal, на этом ресурсе нет никакой информации, которая относилась бы не к финансовым аспектам жизни граждан. То есть о социальных проступках и нарушениях каких-то правил узнать пока нельзя.

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

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

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

Положительные моменты

В городе Янцин (Yangjing) есть собственная система оценки граждан. Здесь она основана на мнении соседей и местных коммунальных комитетов о человеке.

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

В то время, как в самом населенном пункте проживает около 170 000 человек (по меркам Китая, это глухая деревня), в список благонадежных граждан пока попало всего 120 человек. Администрация населенного пункта жалуется на то, что чиновникам мешает оценивать людей ограничения в предоставлении доступа к личным данным жителей.

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

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

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


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

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

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

И бизнес тоже

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

«В особенности все это важно для молодых людей, чье поведение в сети, в том числе, оказывает влияние на кредитный профиль. Мы хотим, чтобы молоды люди понимали, что вести себя нужно лучше», — говорит Джо Тсай, один из руководителей Alibaba.

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

В ноябре представители государственных организаций жаловались официальным СМИ Китая на то, что большое количество информации граждан находится на «островах,» то есть некоторые базы данных изолированы, и получить такую информацию для использования ее в центральной системе мониторинга может быть крайне сложно. Сейчас уже собраны данные о кредитной истории 640 миллионов китайских граждан из 37 регионов. Еще больше данных чиновники надеются собрать из баз данных клиентов телекоммуникационных компаний Китая. Информация с телефонов, умных часов и других устройств пользователей может оказаться в этом деле крайне полезной. В целом, все это похоже на северокорейский "Сонбун", только модернизированный, в цифровом виде.

Тестовая работа системы позволила выявить неблагонадежных людей, преступников, которым запретили покупать билеты на самолеты и скоростные поезда. В «черный список» попало 4,9 миллиона человек.

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

Но в целом, направление развития этой системы задано Председателем Китайской Народной Республики Си Цзиньпином, который неоднократно говорил о необходимости установления системы социального контроля и повышения общего уровня нравственности граждан.
ссылка на оригинал статьи https://geektimes.ru/post/283208/

Как я Дота-лигу открывал (ч.1)

Шел 2006й год. Это были хорошие студенческие годы, время расцвета и становления игры DotA Allstars. В те времена все играли в доту через официальный сервер от Blizzard — Battle.net. Индустрия была очень скудная — не было нормальных трансляций, интернет у многих был еще на adsl, а из событий — мало освещаемые турниры с призами до $5000. Тогда инициативные игроки собирались в группы и организовывались в кланы. Именно тогда мне позвонил мой товарищ и предложил организовать первую Дота-лигу в СНГ. Это был настоящий вызов для меня, и он был принят…

StealthBot

В те времена я активно возился с чат-ботами, которые могли сидеть на канале в Battle.net, притворяясь обычным игроком в Warcraft. Тогда самый распространённый и функциональный бот был — StealthBot. У него были встроенные функции вроде автокика ненужных людей с канала(safelist) и он мог говорить сколько сейчас время и изображать из себя «умного бота», отвечая на заранее зашитые ответы на команды.

Но в нём была отличная штучка — автор этого бота предоставил возможность расширять этого бота через обычный текстовый файл script.txt, в котором можно было писать собственные скрипты на языке Visual Basic Script. Со школьных годов я любил заниматься программированием, а сама игра Warcraft 3 — была моей страстью. Я знал эту игру практически наизусть, я знал все звуки всех юнитов, знал все ресурсы, текстурки и модели этой игры, клепал карты в World Editor’е и гордо называл себя мапмейкером.

Кстати о мапмейкерах и доте

Когда вышла первая полноценная Dota Allstars 5.84c, то общество мапмейкеров очень негативно восприняло эту игру и заклеймили негодной. Все более-менее нормальные картоделы так критиковали эту «карту»: она очень долго грузится, в ней куча героев с «обычными» способностями, очень плоский сценарий, нет никакого сюжета, башни слишком сильные, декорации расставлены как-попало итд…

Чего греха таить, я и сам так считал и критиковал эту карту, смотреть на неё не мог.
Но всё изменилось в 2005м. Тогда вышла версия 6.01, которая была очень здорово оптимизирована и переделана. Эта карта загружалась даже быстрее, чем любая другая карта(даже более простая). Это был настоящий прорыв! К сожалению, до многих мапмейкеров так и не дошло, почему дота стала популярной, и это вовсе не из-за отсутствия сюжета. Эта карта была сбалансированной — в ней можно было играть любым героем и побеждать!

Жизнь в Battle.Net’е

Чат в Battle.net был довольно убогий:

  • В нём нельзя было открыть отдельный приватный чат, в нём нельзя сохранять переписку
  • При переходе на другой канал, у тебя стирается весь предыдущий
  • Чтобы зайти в Battle.Net нужен был официальный CD-KEY — ключ от игры. Если у тебя пиратский Warcraft — ты не можешь зайти в Battle.net.
  • История чата была лишь на последнюю сотню строк, а более поздние стирались
  • На одном канале могло сидеть не более 40 пользователей
  • А еще в нём нельзя было копировать или выделять текст!
  • Про ссылки или смайлы я вообще молчу

Чтобы хоть как-то разнообразить жизнь в Battle.Net’е я писал ботов. Первые мои боты могли запоминать, когда в последний раз такой-то член клана был в онлайне (посещал канал). Затем через бота можно было оставлять сообщения человеку, который сейчас оффлайн (своего рода почта).

В то время единственной более-менее нормальной дота-лигой был европейский канал «Clan DCE», где стоял простенький бот, который кикал всех, кого нет в белом списке. Попасть туда было довольно не просто, хотя и не трудно. Но это всё было не то. Там не было учёта «плохих» игроков — кто сильно ругался, или самое неприятное — выходил из игры до её завершения (ливер). Со временем, в DCE уровень игры стал падать, ливеры попадались в каждой игре, и их просто не успевали банить на канале.

В итоге всё это наталкивало на мысль, что надо взять ситуацию в свои руки, и открыть крутую дота-лигу, которая бы всех устраивала и решала эти проблемы! Моих познаний в ботостроении тогда хватало, чтобы записывать данные в текстовые файлы и читать с них, и общаться с людьми в Battle.Net. Вся мозаика потребностей и возможностей сложилась в голове, и я сказал себе: «Всё что надо есть, я смогу!» и понеслась…

Воздушные замки в голове

Перед созданием лиги, нужно было решить первую очень важную проблему: хостить игры в Battle.net’е могли лишь те игроки, у которых открыты порты или имеются белые ip-адреса. Такие игроки были редкостью, и чтобы вдруг не возникало ситуаций, когда собирался народ поиграть, а ни у кого из них нет белого ip-адреса, было принято решение, что начинать набор игроков на игру могли только игроки, которые имеют возможность хостить игры. Им админы и модераторы должны будут выдавать особый уровень доступа «Hoster»(Хостер).

Следующей проблемой было то, что когда игроки заходят к кому-то в игру, то бот никак не может узнать, в какую команду они зашли — за 1.Sentinel или за 2.Scourge.

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

И тут я решил: пусть Хостер начинает набор игры, сообщая боту о своём намерении. Бот в это время всем в чат начинает каждые 20 секунд сообщать, что сейчас происходит набор игры, с именем игры:
«Происходит набор в игру QDL012. Осталось мест: Sentinel: 4, Scourge: 5»
Имя игры — это своего рода адрес IP, куда подключаться. Вводя название игры в Battle.net’е, игрок попадал в эту игру к Хостеру.
Игрок мог зайти за любую свободную сторону, и когда он определялся с выбором, он должен был сообщить об этом боту(с очень коротким ником QDL и QD.) через отправку личного сообщения короткой командой:
/w qdl .j1 — значит он зашел за первую команду
либо
/w qdl .j2 — за вторую
Как факт подтверждения регистрации, бот отвечал: Sucess!QDL012;team1

Одна команда из 9 символов запоминалась довольно быстро, более того, игроки подсказывали друг другу, что надо сделать. Когда все слоты забиты, и все игроки зашли, Хостер должен был проверить список игроков, которые «зарегистрировались» в боте, и проверить, все ли игроки соответствуют своим командам. Для этого он отправлял боту команду:
/w qdl .check
и ему в ответ прилетало длинное сообщение, со список игроков по командам:
QDL012 {Sentinels: [1]Quad.Tims [2]Quad.5min [3]AlfaCriostat [4]y6uBaIIIe4ka [5]remi} {Scourges: [6]Piragok [7]zagalex [8]Fade.Killer [9]Ums.Acc [10]upska}

Хостер должен был свериться со списком, и если всё впорядке, то сообщить боту о старте:
/w qdl .start
Игра начиналась, люди играли. В конце игры, люди возвращались на канал и сообщали о результате, кто победил:
.result 1 — победила первая команда The Sentinel
.result 2 — победила вторая команда The Scourge
.result 0 — ничья. Она могла произойти по разным причинам, обычно из-за ливера.

Когда 51%+ игроков проголосовали за какое-то решение, бот производил раздачу очков — отнимал у проигравших, давал победившим, и записывал в статистику к игрокам +1 победу победившим и +1 поражение проигравшим, чтобы вести статистику.

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

Еще немного механики бота

Чтобы людям было удобнее набирать имя бота, я их зарегистрировал с очень короткими никами:
QDL и QD.

Какие «фишечки» были в боте:
Бывали ситуации, когда, игрок зашел в игру и зарегистрировался у бота, а хостер его кикнул из игры, то игрок автоматически попадал на канал. Когда игрок заходил на канал, бот проверял — не зарегистрирован ли этот игрок в какой-либо игре, и если это так, то автоматически снимал с него регистрацию, и слот в счётчике игроков освобождался.

Хостер, отправляя команду CHECK и получая список из игроков, должен был сверяться — все ли зарегистрировались правильно. Бывало так, что кого-то кикнули, а регистрация не снялась. И чтобы хостеру не вводить длинные и сложные ники вроде y6uBaIIIe4ka, хостер мог ввести лишь порядковый номер «лишнего» игрока, и бот снимал регистрацию.
QDL: QDL012 {Sentinels: [1]Quad.Tims [2]Quad.5min [3]AlfaCriostat [4]y6uBaIIIe4ka [5]remi} {Scourges: [6]Piragok [7]zagalex [8]Fade.Killer [9]Ums.Acc [10]upska}
Hoster: /w qdl .kick 4

Бот вёл таймер для каждой игры, и у хостера было 5минут, чтобы начать игру, иначе игра отменялась, хостер получал штраф, а другой хостер мог объявить новый набор игры. Но это время можно было продлить, отвечая боту на предупреждения командой .continue.

Пробуждение силы

Код был написан примерно за 2 месяца. Это был настоящий разрыв мозга и трансформация мышления, я еще никогда не писал столько кода! Еще никогда не делал полноценный проект! Стыдно это признавать (но теперь уже не стыдно): весь код был написан с использованием обычных текстовых файлов! Никаких БД, никаких запросов! Только хардкор)
Запускаться решили через 2 недели: в ноябре 2016года. За 2 недели разместили информацию на всех Dota-форумах, где смогли, а мои товарищи соклановцы подготовили правила игры и начисления очков.

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

Запуск

И вот мы запустились! В первый день ноября у нас было проведено около 10 игр. Народ вяло-текуще разыгрывался и тянул своих знакомых. Мы всех с радостью добавляли в белые списки и разрешали им играть. Чтобы увеличить поток игроков, мы выдавали сразу целые белые списки на имя Клана, например «FADE» — если на канал заходил игрок, и он состоял в этом клане, то он автоматически попадал в белый список.
А чтобы усилить конкуренцию, мы помимо списка лучших игроков вели список лучших кланов, в котором учитывались очки всех участнико в клане.
Через неделю у нас на канале уже стабильно 20 человек, с которыми можно начать игру.
Так как в Battle.Net было ограничение — максимум 40 человек на канале, то бот со временем научился кикать с канала неактивных пользователей, когда канал заполнялся на 90% чтобы другие могли без труда зайти.
Через 2 недели, можно было в любое время зайти на лигу и в течение 5 минут найти нормальных игроков, которые не ливали.

Эффект очков

Знаете, чего мы не ожидали? А того, что люди, никогда раньше не видавшие виртуальный счётчик очков (points), побед и поражений, что они начали выкладываться в играх на 100%! Они понимали, что если они будут плохо играть, то проиграют. А значит потеряют winrate, очки и снизятся в рейтинге игроков. Эти простые циферки, которые бот говорит в чате — значили для игроков очень многое! Быть топ-50 игроком из 1000 человек — это что-то да значило!

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

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

Перспективы и монетизация

Сейчас довольно забавно это вспоминать, но проект вообще не предусматривал никакой монетизации или коммерции! Тогда мы как пионеры работали просто ради славы в интернете :). Ни я, ни администраторы-соклановцы, ни набранные модераторы не получали ни копейки. Да и времена были такие, что из виртуальных денег были только WebMoney, которыми пользоваться умели немногие.

Со временем, мы подружились с ребятами, которые вперёд нас создали лигу, и начали дружить. Оказалось, что организаторы лично знают всех самых лучших Дотеров, и они рассчитывали создать закрытую лигу, чисто для самых топовых игроков, а нам они обещали скидывать всех остальных, кто им не подходил. Нам — дополнительная реклама, им — возможность вежливо «отказать» неподходящим игрокам.
Договорились, а на деле вышло совсем не так, как задумывалось: так как у них было довольно мало игроков, то чтобы собраться поиграть, игрокам приходилось ждать подолгу, пока соберется 10 топовых дотеров. Такое работало только в самые часы пик — с 18 до 22ч, а в другие часы ждать приходилось минут по 20-30, и чтобы не ждать, они просто шли к нам. Как итог — все играют у нас — и лучшие дотеры, и «не лучшие». Иногда это приводило к скандалам, интригам и расследованием, например они за одно лето(самый неактивный сезон) переманили к себе почти всех наших админов и модераторов. Работать стало некому, приходилось заново набирать команду.

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

Снова проблемы

Прошел 1 год:
Battle.Net лагал. Игры, которые хостились через Battle.net, вызывали задержки как минимум в 80мс, в то время как по LAN’у задержка была 40мс (это стандартная задержка игры, если игра хостится через официальный клиент Warcraft. Гораздо позже вышел хост-бот: GhostBot, который радикально уменьшил пинг)
Были читеры. Увы, на каждый новый патч от Blizzard, выходила новая версия MapHacka (видеть всю карту и персонажей вне поля зрения), или KickHack’а(хостер мог выкинуть любого игрока (который ему не нравился, или очень сильно раскачал героя) прямо по среди игры, и тому дали бы бан за ливерство).
Метод набора в игру был несовершеннен. Очень часто происходили абузы со стороны Хостеров — они набирали в свою команду хороших игроков, а в противниках оставляли самых убогих. Получалось, что если ты хостер, то ты можешь с вероятностью 90% одерживать победы. Волна негодования возрастала.
Чат был убогим, не позволял ботам слишком много писать личные сообщения или в чат. Тут пришлось запустить 2 бота, и часть сообщений отправлять через второго. Напомню, что боты работали через обычные текстовые файлы — по одному на каждого игрока, и на каждую сыгранную игру.
HDD тормозил — тогда я даже не знал, что HDD работает медленно, когда ему надо определить лучшего игрока из 1000 игроков, открыть 1000 файлов и выдернуть 3 лучших. Надо было решать эту проблему…

Судьба

Вы верите в судьбу? А я верю. Точнее уверился в ней. Вот вам мой пример:
Помните, я выше писал про лигу DCE? Которая была довольно простой? Так вот. Меня тогда всё же добавил в белый список мой друг-немец, с которым я познакомился в одной из игр. Так вот, он узнал, что я пишу ботов, и попросил им сделать апгрейд бота. Этот парень знал PHP и MySQL, но вот ботов писать не умел(и не хотел). Он попросил, чтобы бот умел работать с базой данных через ODBC-клиент MySQL, и даже показал примеры-кодов. Мы провели с ним месяц, он научил меня SQL, объяснил что такое базы данных, и как в них лежат данные. Так-же он показал мне волшебный unixtime, с которым очень просто прибавлять к датам дни, минуты и секунды, особенно, когда нужно было давать бан на время. Я сделал ему бота, которого он хотел, который имел прямую связь с БД от сайта, и он смог у себя реализовать онлайн-списки игроков.

Распрощавшись, и вооружившись новой технологией, я за пару недель переписал с нуля своего бота на «новую технологию» — MySQL. Это был настоящий прорыв для меня. Можно было в одну секунду получить лучшего игрока, посчитать очки у всего клана, или вывести статистику по всей игре! Бот начал летать, а игроки получили нового бота с новой механикой набора игр, автобалансировкой команд по очкам.

Так что там на счёт судьбы? Сейчас я понимаю, что я тогда забрёл в тупик, и не знал, куда дальше развиваться. И если бы не этот немец (и не то случайное знакомство с ним во время игры), то он бы не научил меня MySQL, а сам я вряд ли бы вдруг загуглил «как работать с mysql».

Я не могу назвать это обычным совпадением, которое привело к знакомству 2 года назад, и привели к толчку в сторону познания баз данных и понимания, что даже из этого хиленького StealthBot можно цепляться к большим и крутым базам данных!

Развитие

Я нашёл интересный язык AutoIt, с которым написал свою первую программу-клиента для лиги. Встроил в него детектор самых распространённых читов, и сказал, что игроки, которые будут играть с ним, будут получать на 50% больше очков. Желающие нашлись, и это был первый интересный опыт клиент-серверного программирования.

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

Среди первых испытуемых был Hamachi. Увы, с ним не сложилось — слишком сложно настраивать, требуются админские права (устанавливается виртуальная сетевая карта), но качество связи было хорошее, пинг был ниже, чем в Battle.Net.

Следующим испытуемым была программа Battle Lan — небольшая программа, которая транслировала широковещательные udp-пакеты разведчики на введённые адреса, и таким образом, если кто-то с белым IP создавал игру прямо в локальной сети, то его могли увидеть другие игрок за NAT’ом. Я встроил и автоматизировал её в своём клиенте, и некоторые игроки могли поиграть друг с другом. Увы, решение оказалось нестабильным — часть игроков видела хостера, а другая часть нет.


Среди последних в поле зрения попал некий Good Game Client (GGC, в будущем — Garena). В нём можно было очень легко поиграть как по LAN’у в такие игры как Counter Strike 1.6, или Warcraft 3(гораздо позднее была добавлена DotA). Пинг очень радовал! Коронная фишка была в возможности устанавливать прямые udp-туннели между игроками, находящимися за NAT, чтобы они могли играть друг с другом, даже не имея белого ip, более того, они были ярыми поклонниками обычного Warcraft 3 и у них был встроеный обновляющийся античит. Чтобы играть здесь не требовался официальный ключ от Warcraft III. В целом всё круто, но под него не было написано никаких ботов. Что-ж, я мог быть первым!

Используя свои познания в AutoIt, я смог получать Handle от окна чата, и обычным чтением получать текущий текст. Точно также, я получал handle поля ввода сообщения, мог вводить текст, и отправлять виртуальный клик по кнопке «Send». Осталось только получать список пользователей на канале, и это тоже получилось. Технически, я был готов запустить там бота. Но в этой платформе не было игроков. Никто не играл там, все привыкли к Battle.Net.
Это был 2008й год, вроде не так много времени прошло, но тогда у многих был платный траффик за каждый мегабайт! И это было неприятно — играя через обычный Battle.Net сеанс игры съедал около 1мбайта, а играя через GGC — игра уже стоила 2мбайта (из-за инкапсуляции данных, ходящие в виртуальном туннеле связи), что для некоторых игроков было критично — играть в доту стало дороже!

Я видел перспективы в этой платформе, адаптировал под неё бота, запустил его там, назначил нескольких местных игроков админами, чтобы следили, и объявил переходный период в 1 месяц. Народ тянулся неохотно, и вплоть до последнего дня играл в Battle.net’е. После отключения бота в battle.net’е, народ объявил демарш, и не стал подтягиваться в GGC, вместо этого народ стал играть на той соседней «закрытой лиге» от наших соотечественников.
Я верил в успех, и в течение месяца мы снова стали активно проводить игры на новой платформе. Уже через год в Battle.Net никого небыло, GGC теперь называлась Garena, а игроков у нас стало в 2 раза больше, чем раньше в Battle.Net.

Продолжение следует…
ссылка на оригинал статьи https://habrahabr.ru/post/316540/

Как мы приготовились к UAV Challenge 2016

Квадро-самолет Мурена во время тестовых полетов

UAV Challenge – это ежегодное мероприятие, направленное на расширение возможностей БЛА и, по совместительству, одно из самых масштабных роботехнических соревнований в мире. Влияние события на отрасль довольно велико: в 2014 году, например, в UAV Challenge участвовали постоянные контрибьюторы таких популярных проектов, как Ardupilot, PX4 и Paparazzi, так что многие из существующих сегодня фич этих контроллеров полета были сформированы именно под влиянием требований этих соревнований. Каждые два года соревнование открыто для команд со всего мира, и при этом тематикой становится миссия по спасению человека. В этом году нам тоже удалось попасть в список из десяти команд, прошедших три предварительных этапа UAV Challenge, и поехать на мероприятия финальной части, которые проходили с 27 по 29 сентября в Далби, Австралия. Чэллендж закончилось два месяца назад – с тех пор наши впечатления успокоились, мы проанализировали опыт и теперь готовы описать те два летательных аппарата, с которыми мы приехали на меропритие.

Мы – MelAvio Avionics Club, объединение студентов из Варшавского Политехнического Университета (Warsaw University of Technology). Мы занимаемся вопросами программирования, электроники и механики в рамках их применения к беспилотникам, и почти вся наша работа проходит в приготовлениях к различным соревнованиям, главным из которых в последнее время являлся UAV Challenge. На самом деле, в этом году MelAvio принимало участие в чэллендже уже во второй раз: до этого наша команда ездила на финал в Австралию два года назад. Тогда удалось хорошо показать себя с оригинальной механической конструкцией и самодельным контроллером полета, заняв десятое место в общем зачете и получив награду за лётное мастерство, хотя и не выполнив полностью миссии соревнований.

Барракуда, беспилотный самолет MelAvio, на UAV Challenge Outback Rescue 2014

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

Задание чэлленджа

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

Карта с обозначенными местом отправления, местом назначения и позволенной областью полета

Главный летательный аппарат

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

Конструкция

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

Тестовый летательный аппарат

С самого начала разработки было ясно, что коптерные винты и двигатели будут создавать дополнительные сопротивление и дисбаланс в самолетном режиме, поэтому мы решили постараться сделать конструкцию самого самолета как можно менее “тормозящей” и как можно более устойчивой. Кроме того, нашим исходным требованием было сохранить максимум пространства в корпусе самолета, так чтобы там поместилось оборудование системы компьютерного зрения и литий-полимерные батареи с емкостью достаточной для выполнения целой миссии (летательный аппарат – полностью электрический). Исходя из этих соображений в качестве схемы самолета мы выбрали высокоплан с трапециевидным крылом среднего удлинения и Т-образным оперением; угол поперечного V крыла был выбран равным полутора градусам.

С указанными исходными данными о конструкции и предположением о массе летательного аппарата, мы приступили к разработке. Сперва при помощи приложения Profili 2.0 был выбран подходящий вариант профиля главного крыла самолета, после чего в XFLR5 мы уточнили форму крыла и оперения в объеме. Кроме того, в ANSYS Fluent мы проверили, что расположенные в непосредственной близости от крыла коптерные двигатели и пропеллеры не вносят критического изменения в характер воздушного потока на крыле. По выполнению указанных процедур мы перешли к более детальной проработке всей конструкции в SOLIDWORKS.

Проверка потока на коптерных винтах в ANSYS Fluent

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

Крыло самолета было сделано из трех составных частей: центроплана и правой и левой полуплоскостей. Основой для констукции крыла являлся экструдированный пенополистирол. Части крыла были спроектированы таким образом, чтобы их поверхность была прямолинейной, и благодаря этому для точной резки полиэстирола можно было задействовать проволочный ЧПУ станок. После, заготовки из полиэстирола были подвергнуты дополнительной обработке для того, чтобы повысить их прочность и улучшить аэродинамические характеристики. Так, болванка центроплана была заламинирована при помощи углеволокна и полиэфирной смолы; для того, чтобы заготовка сохранила гладкую и ровную поверхность, на время ламинирования она была обернута плексигласом, помещена в вакуумный мешок и закреплена в пенополистироловом негативе. Для изготовления полуплоскостей крыла не представлялось возможным использовать углеволокно, в том числе по той причине, что в этих деталях необходимо было разместить радиопередающее оборудование (уголь создает интерференцию), поэтому полуплоскости были заламинированы слоем стеклоткани и слоем бальсы. На краях элементов были сделаны крепления для их сборки в цельную конструкцию крыла. Также в крыле было вырезано место для размещения радио-трансивера, приводов для эйлеронов, проводов и иного оборудования; в необходимых местах в вырезы были вклеены распечатанные на 3D принтере крепления для оборудования.

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

Центроплан в процессе изготовления

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

Каркас корпуса беспилотника

Силовая часть

В качестве коптерных моторов для аппарата мы взяли самые большие, которые были для нас в зоне оперативного доступа – T-MOTOR U8 Pro 170KV с рекомендованными для этих моторов деревянными пропеллерами от T-MOTOR диаметром 20 дюймов. Для управления скоростью моторов были выбраны ESC’и T-MOTOR FLAME 80A. С питанием от двух соединенных последовательно шестиячеечных литий-полимерных батарей Tattu 22000mah такая силовая установка позволила нам получить максимальную вертикальную тягу в 20 килограмм.

Для пропульсивной установки мы выбрали мотор Scorpion HKIII 4035 500KV с ESC FOXY XR-120 OPTO питанием от того же аккумулятора, к которому подключены коптерные моторы.
Итоговая взлетная масса летательного аппарата со всем оборудованием на борту вышла равной 14 килограммам. Максимальная скорость аппарата — 40 м/с, крейсерская скорость — 25 м/с, скорость срыва потока — 18 м/с, длительность полета в режиме самолета — более одного часа, дальность полета — до 100 км, что должно было обеспечить нам возможность выполнения миссии даже при неблагоприятных погодных условиях.

Система компьютерного зрения

Важной частью главного летательного аппарата для нас была бортовая система компьютерного зрения, без которой найти Джо и выполнить миссию невозможно. Основными элементами системы были выбраны RGB камера JAI GO 2400 с полнокадровым переносом и разрешением Full HD, и мощный мини-компьютер GIGABYTE BXi7-5775. Камера была закреплена на стабилизирующем подвесе нашей оригинальной механической конструкции под управлением контроллера Alexmos – это позволило нам получать изображения с постоянным уровнем наклона относительно земли, так что силуэт человека на них был отчетливо различим. Компьютер был соединен с контроллером полета для обеспечения возможности получения телеметрийных данных и отправки команд. Кроме того, при помощи 4G модема компьютеру был предоставлен доступ к FTP-серверу, через который осуществлялось сообщение со станцией оператора системы компьютерного зрения. Алгоритм программы, запущенной нами на борту, коротко описан в следующем параграфе.

После получения изображения с камеры, к нему немедленно привязывается последний полученный от контроллера полета пакет телеметрийных данных, так что для каждого пикселя на изображении можно примерно вычислить его геокоординаты. После этого происходит поиск областей интереса: для этого строится гистограмма изображения, и в ней выбираются уровни, количество пикселей для которых больше некоторого порогового значения – это уровни “неинтересных” регионов, и соответствующие им пиксели далее не рассматриваются. На оставшихся “интересных” пикселях проводится операция морфологической эрозии, так что остаются только пиксели, объединенные в группы – эти группы сортируются по концентрированности, размеру и цвету, и в итоге мы получаем ранжированную группу областей на изображении, которые хоть как-то могут быть похожи на человека. После этого для каждой из таких областей мы вычисляем HOG-дескриптор и при помощи вектора опорных векторов классифицируем ее, как человека или не-человека. Если область классифицирована, как человек, это не значит, что мы сразу действительно считаем ее таковым – она просто получает значительный плюс в рейтинге. После, изображения всех найденных областей интереса высылаются на FTP-сервер в порядке, соответствующем их рейтингу. В файл каждого такого изображения включена информация о геоположении области и идентификатор полного изображения, с которого взята область.

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

Приложение на станции оператора

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

Классификация регионов интереса на борту беспилотника: красный контур — регион классифицирован, как не-человек; зеленый контур — регион классифицирован, как человек

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

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

Вспомогательный летательный аппарат

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

Силовая часть

Для переноса ретранслирующего оборудования мы использовали летающее крыло, сделанное на основе довольно популярной платформы Skywalker X8. Летающее крыло в данном случае вписывается в ограничения, обусловленные неизвестностью ландшафта стартовой площадки, так как может быть запущено с легкой катапульты или с банджи, и может приземляться автоматически, не требуя для этого значительного открытого пространства. Для того, чтобы самолет мог приземляться без шасси, не получая значительных повреждений, мы заламинировали нижнюю часть корпуса кевларом и стеклотканью. Кроме того, чтобы увеличить прочность конструкции и обеспечить возможность полета на повышенных скоростях, стеклотканью была также заламинирована передняя кромка крыла. X8 было оборудовано двигателем на 710 KV, номинально рассчитанным на работу с литийполимерной батареей из пяти ячеек, и батареей для этого двигателя на 16 амперо-часов из шести ячеек. Из-за того, что мы использовали батарею с напряжением выше номинального напряжения двигателя, пришлось обеспечить в конструкции дополнительный влет воздуха для охлаждения. Для двигателся использовался регулятор скорости на 70 А и складывающийся пропеллер 9.5×8. На элевонах мы поставили высококачественные серва HS-5625MG от Hitec; серва обладают значительным запасом по характеристикам, что должно минимизировать возможность потери управляющих поверхностей, каждая из которых в случае летающего крыла является критически важной. Кроме того, на борту были расположены дополнительные малые батареи для авионики и системы аварийного прекращения полета, а также контроллер полета (Pixhawk). В итоге характеристики аппарата оказались следующими: масса — 3,5 килограмма, максимальная скорость — 35 м/с, крейсерская скорость — 25 м/с, время полета — до 55 минут, покрываемое расстояние — более 80 км.

Вспомогательный летательный аппарат во время тестовых испытаний

Организация связи

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

Схема связи между летательными аппаратами и станцией оператора

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

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

Что касается проблемы определения маршрутизатором, предназначен ли полученный пакет данному устройству – решение не совсем тривиально. Дело в том, что для сообщения с летательными аппаратами мы используем протокол mavlink, который является де-факто стандартом для пользовательских беспилотников. В заголовках mavlink отсутствует информация о получателе пакета, хотя есть идентификатор системы и подситемы отправителя. В нашем случае интерпретацией команд от “Базовой Станции 1” должен заниматься только контроллер полета вспомогательного аппарата, а от “Базовой Станции 2” – только контоллер полета главного аппарата, поэтому мы могли сортировать пакеты имея только идентификатор отправителя. Такое решение работает довольно надежно, но, опять же, маломасштабируемо и нуждается в дальнейшей переработке.

Маршрутизатор, осуществляющий фильтрацию пакетов, приходящих от радио-модема

В качестве радиомодемов мы использовали RFD 868+. Маршрутизаторы были сделаны нами на основе STM32 Nucleo, к которому мы добавили шилд, чтобы упростить подключение питания к плате, расширить возможности коммуникации и индикации.

Заключение

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

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

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

В конце стоит сказать, что ни одной из команд в этом году не удалось целиком выполнить миссию соревнований, что было связано с потерей летательных аппаратов по разным причинам: крушение, возгорание, вылет за пределы отведенного летного пространства и, стандартно, зависание на дереве. Наиболее отметились во время чэлленджа команда из TU Delft (оригинальная механическая конструкция и испытательный образец системы компьютерного зрения от Parrot, видео о беспилотнике тут) и Canberra UAV (доставили пробу крови, но разбили вспомогательный вертолет, видео о беспилотнике тут).

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

Материалы

» Правила UAV Challenge Medical Express 2016.
» Статья от организаторов чэлленджа о статистике и истории соревнований.
» Описание успеха Canberra UAV от Эндрю Триджелла — идейного лидера команды.
ссылка на оригинал статьи https://geektimes.ru/post/283210/