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

Возьмём обычную задачу: включить фару на устройстве.

На практике наша железка должна загрузиться, зарегистрироваться в LTE-сети, поднять TLS-соединение с MQTT-брокером, синхронизировать состояние и пройти ещё кучу слоёв бизнес-логики. С другой стороны — мобильное приложение и бэкенд для управления этой лампочкой (уже целая система собралась!). Там не меньше логики: от авторизации до “да кто блин так дизайн спроектировал?”. Пока дотапаешься до кнопки, пройдёт вечность.

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

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

И стало ясно: нам не хватает shell-интерфейса. Или CLI. Или терминала — называйте как угодно (разницу можно глянуть здесь). Но не просто не хватает — его придётся писать самим. Меня зовут Сергей Шилин, я руковожу разработкой электроники и встроенного ПО в Whoosh. Почему не взяли готовое и чем наш велосипед лучше — расскажу под катом!

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

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

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

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

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

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

Меня зовут Игорь Волынский, я backend-разработчик в команде WCMA Whoosh. И сегодня я расскажу, как мы решили эту проблему: построили централизованную и гибкую систему управления статусами, добавили условные переводы с хендлерами для проверки бизнес-правил и реализовали динамические сценарии для гибкого формирования UI. Спойлер: теперь наши механики и менеджеры видят только те действия, которые им реально доступны, а бэкенд гарантирует целостность данных на уровне системы.

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

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

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

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

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

Привет, Хабр! Меня зовут Александр Крестинин, я разработчик встроенного ПО в компании 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 и какие у нас планы на будущее.