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

Меня зовут Алексей, я работаю в Yandex Self-Driving Group: несу ответственность за разработку железа трёх (с половиной) поколений роботов Яндекса. В этой статье я не только коротко расскажу про новое поколение, но и поделюсь историей создания роботов-курьеров. Вы сможете взглянуть их глазами на велосипедиста, узнаете, как собрать прототип из фанеры и трёх гироскутеров, а также почему мы выбрали менее дальнобойные лидары. Всё это я дополню роликами и фотографиями разных этапов разработки. Поехали!

You can’t properly test and debug mobile apps without test devices, which there should be plenty of considering how the same code may behave differently on different models. So how do we keep track of these devices? How do we quickly provide developers and testers with the smartphones they need, configured the way they need, and without much red tape?

I’m Alexey Lavrenuke. Over the years, I’ve worn many hats: one of the authors behind Yandex.Tank, a speaker on load testing, and the guy who calculated energy consumption by mobile phones. Now I’m a Yandex.Rover developer on the self-driving car team.

After the phones and before Yandex.Rover, there was Hypercube.

A few years ago, the head of mobile development popped in to the load testing department and mentioned a problem they were having with test devices: phones had a tendency to inexplicably migrate from one desk to another. Picking the right device and then finding it had become a challenge. We already experienced working with mobile devices from building a digital ammeter to calculate energy consumption, so we decided to help our coworkers out and quickly rig up a handy contraption. We figured the whole thing wouldn’t take more than three months. Oh how wrong we were. Let me tell you what we were really in for.


^{_{''Dallas cube''}}

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

Меня зовут Алексей Лавренюк. Вы можете знать меня как одного из авторов Яндекс.Танка и докладчика на тему нагрузочного тестирования. Потом я измерял энергопотребление мобильных телефонов. Теперь я делаю Яндекс.Ровер в команде беспилотных автомобилей (и иногда подрабатываю Дедом Морозом). А между телефонами и Ровером был Гиперкуб.

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

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

Производители как железа, так и софта, стараются решить эту проблему. Для Яндекса она тоже актуальна, потому что наши сервисы — это то, что должно быть под рукой у человека в любой момент. Мы по-разному над этим работаем и в рамках эксперимента создали устройство для измерения тока, который потребляется телефоном с батарейки. Теперь мы умеем мерить мгновенные значения тока с батарейки телефона (Nexus, iPhone и др.) в миллиамперах 500 раз в секунду, сохранять эту метрику на диск и считать по ней среднее потребление.

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

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