Привет, Хабр! Меня зовут Александр Крестинин, я разработчик встроенного ПО в компании Whoosh. Мы в embedded-команде не только переливаем биты из одного регистра в другой, но и решаем разные бизнес-задачи. Иногда попадаются головоломки. 

Однажды мы подумали, что было бы здорово выводить на экраны самокатов анимации и изображения — показывать инструкции, как пользоваться сервисом, как начать и закончить поездку, и чтобы запускать DOOM.

Зачем?

1) Сделать комфортнее. Удобно видеть инструкции на большом и ярком экране перед глазами, а не нырять за ними в приложение на смартфоне. 

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

3) Почти у всех привычных устройств уже есть экраны, которые выводят пользователям видео и картинки, а почему бы не сделать то же самое на самокате?

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

Расскажу, как мы нашли решение этой задачи. Прошу под кат.

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

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

Когда имеешь дело с микроконтроллерами, а микроконтроллер — основа нашего IoT-модуля, постоянно приходится собирать и отлаживать прошивку. Пишешь код, компилируешь его, заливаешь на микроконтроллер. Потом надо убедиться, что всё работает как надо: подключить отладчик, подебажить.

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

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

Будет make, Python, vscode, ansible, gdb, orangepi и немного чёрной магии.

За несколько лет Whoosh в несколько раз вырос по числу самокатов, пользователей и локаций, а данных по ним накопилось на 30 терабайт. Прежней архитектуры уже не хватало для работы. К тому же платить за I/O (input/output)-операции на Aurora (PostgreSQL) выходило дорого (тогда еще не было I/O‑optimized версии, однако с ее появлением, актуальность не исчезла). Другое дело — Redshift: расходы постоянны (n$/час), а работает он быстрее, благодаря колоночному формату хранения данных. В этом году мы переехали с одного хранилища на базе PostgreSQL — того, где вся отчётность для бизнеса и модели dbt — на рельсы Data Lake в AWS.

Меня зовут Никита Зеленский, я главный по данным в Whoosh. Эту статью я написал вместе с другими участниками переезда — Пашей Сивохиным, ГИС-аналитиком, и Костей Малыхиным, руководителем группы анализа данных. Надеюсь, наш опыт будет полезен всем, кому предстоит миграция данных, особенно если вы работаете с геоаналитикой.

Всем привет! В первой части статьи мы рассказали о том, как на наших IoT модулях реализована схема управления пьезоэлектрическим излучателем (баззером) с регулировкой частоты и амплитуды; как эта схема управляется микроконтроллером программно, воспроизводя простые звуки и мелодии. Такая реализация показала себя надежной в эксплуатации, нетребовательной к ресурсам и на начальном этапе решала задачу базовой озвучки самоката. Шло время, появлялись новые сценарии взаимодействия с пользователями и нам самим хотелось чего-то большего — например, хорошо было бы сделать звучание самоката более “фирменным”, узнаваемым и приятным на слух. Так мы и задумались о “звуковом рефакторинге” — об этом и расскажем вам в этой статье.

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

И сегодня мы поговорим об ИНС, а точнее об одном из необходимых элементов подобных систем — магнитометре, а еще точнее о том, как его калибровать.

В Софт, хард и два колеса: как мы строили IT-инфраструктуру в Whoosh упоминалось, что первые версии IoT мы ставили под непрозрачную крышку, замещая стандартный модуль управления от самоката Xiaomi M365. То есть, после установки и проклеивания крышки, связь с модулем была только через облако. В идеальном мире этого было бы достаточно, но реальность диктовала условия, в которых нужна была индикация процессов — как в режиме обслуживания, так и в городе, у пользователей. Прием управляющих команд, отправка телеметрии, подключение к сети и выход устройств в онлайн — разные этапы нужно было различать сервисной команде для быстрой диагностики, а пользователя — предупреждать об изменениях в базовых сценариях использования — командах, ошибках, ограничениях и т.д.

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

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

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

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

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

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

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

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

Здесь мы расскажем, как мы реализовывали модель прогнозирования спроса на самокаты, с чем сталкивались при прототипировании, какие модели были протестированы, чем наш случай отличается от прогнозирования спроса в каршеринге, спроса для пополнения запасов в дарксторе и т. п. (Самокат, самокаты Whoosh передают привет!)

История получилась про наши подходы и грабли, которые мы в итоге собрали. Чуть‑чуть про технику, чуть‑чуть про бизнес — нескучно и с ветерком (как на самокате).

Whoosh!

Всем привет, на связи Фарук, инженер-разработчик электроники и встроенного ПО в Whoosh (читается как ВУШ, ощущается как вжууух). Работаю я в embedded отделе (хардкорные программисты, что пишут прошивку на C для различных железок и проектируют эти самые железки), но в основном занимаюсь анализом различных данных от нашего IoT модуля и разработкой алгоритмов для работы с этими данными.

Наша компания — сервис аренды электросамокатов (а местами еще и электровелосипедов) или, иными словами, кикшеринг. О том, как мы к этому пришли и что из себя представляем можно почитать здесь.

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

Во-первых, так нельзя. А во-вторых, добро пожаловать под кат.

Привет, Хабр!

На связи команда Whoosh — лидера в разработке и интеграции технологий микромобильности в стране. Если вы живете в России или СНГ (мы уже присутствуем в некоторых городах Казахстана и Беларуси), то наверняка видели наши электросамокаты или пользовались ими. Вероятность этого большая: за 9 месяцев 2022 года года уже совершено 46 млн поездок, парк вырос до 82 тысяч устройств и размещены они в 40+ городах трех стран.

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

Меня зовут Сергей Шилин, я руководитель отдела разработки электроники и встроенного ПО. Вместе с CIO и со-основателем Whoosh Егором Баяндиным мы вспомним, как все начиналось несколько лет назад, как все устроено сейчас с точки зрения IT и какие у нас планы на будущее.