Как сделать телеметрию своими руками
Записки Механика
Механика, электроника, авиамоделизм и другие интересности
Самодельная система телеметрии FrSky. Часть первая
Когда я покупал радиомодули FrSky, то помимо хорошей дальности и надежности, меня очень интересовала возможность использования UART канала для передачи какой-нибудь информации с самолета на землю. Но только сейчас я смог более-менее нормально реализовать передачу телеметрии с летящего самолета.
Попутно провел очередную модернизацию своего пульта, добавив в него светодиодный семисегментный дисплей, на который выводится телеметрия FrSky.
Самодельная система телеметрии FrSky. Часть первая
Оправдания
Данная статья возможно будет интересна тем, у кого есть обычная хобикинговская аппаратура и радиомодули FrSky.
Подготовка
Предыдущая модернизация позволяла пользоваться телеметрией FrSky только на уровне звуковых (достаточно примитивных) сообщений. Теперь же, после своих полетов на высоте без FPV мне очень хотелось знать текущую высоту самолета. Учитывая, что под рукой у меня была плата управления мультикоптерами MultiWii 328 на которой был барометрический датчик высоты, мне оставалось только придумать, каким образом данные о высоте передать на землю. приемник FrSky D8RSP в комплекте с FrSky передатчиком имел «непрозрачный» UART канал передачи любых пользовательских данных. Почему «непрозрачный»? А потому, что на приемной стороне данные придется декодировать, чтобы достать оттуда «чистый» UART сигнал. Ведь канал обратной связи включает в себя помимо пользовательских данных еще и штатную телеметрию FrSky. О структуре протокола передачи данных телеметрии FrSky я уже писал.
Для получения неинвертированного UART сигнала использовал простые инверторы на биполярных транзисторах. Два (те, что в пульт) разведены на маленькой печатной платке. А один навесным монтажом прямо на кабеле соединения с Multiwii 328. В результате для полноценной работы описываемой системы телеметрии FrSky нужны три кабеля: шнур контроля напряжения литий-полимерном аккумуляторе (со встроеным делителем), кабель питания для MultiWii 328 (+5В берутся с приемника) и кабель передачи данных с MultiWii 328 на приемник FrSky (с инвертором).
Простой дисплей телеметрии FRSky. Схема и печатная плата
Для дешифровки и обработки полученных данных телеметрии использован микроконтроллер ATMega48PA.
На схеме не показаны ограничительные резисторы 220 Ом. Прошивка для микроконтроллера вот здесь: FrSky Telemetry Firmware.
Описание возможностей дисплея телеметрии FrSky
Три светодиода, сбоку от дисплея предназначены указания какое значение сейчас показывается.
За некоторую сумбурность и «незавершенность» статьи — очень прошу извинить.
Самодельная система телеметрии FrSky. Часть первая : 4 комментария
А можно фото что к чему паять под аудио шнур для данного девайса? И можно ли потом ее настраивать через т6
А причем здесь аудио шнур? И настраивать этот дисплей через ПК нельзя. Там нечего настраивать. Возможно, я просто не понял вопроса…
есть желание повторить Вашу схему могли бы Вы ее переделать?
vladvitt › Блог › FAQ: Телеметрия для автоспорта
Очень часто пишут в личку с вопросам по поводу телеметрии:
Какими программами я пользуюсь?
Где купить?
Как все это работает?
Как наложить логи на видео и тд.
Поэтому, я решил в этом посте поделится свои опытом.
Как только я начал ездить полноценно в Чемпионате по тайм атак, пришло осознание что нужны тренировки, без этого не будет результата однозначно. По факту тренировки дают вкат и понимание что именно нужно сделать с машиной в техническом плане что бы быть быстрее на треке. Но если вы будете просто накатывать круги по треку то очень быстро поймете что стоите на месте. Собственно в этот момент и приходит осознание необходимости телеметрии для анализа ваших тренировок.
Минимальный набор который нужен вам для тренировок по исправного автомобиля это манометр и пирометр. Эти два прибора нужны для контроля давления и температуры шин, кроме того данные полученные с помощью этих простых девайсов помогут вам понять насколько подходят настройки подвески вашего авто для езды по треку. Я не буду углублять в эту тему сейчас, так как на драйве да и в интернете полно статей с анализом и рекомендациями.
Вернемся к телеметрии, в первую очередь она позволяет на получать данные о времени круга, либо о времени прохождения определенного отрезка трассы в случае с различными спринтами. Конечно существует много различных вариаций с разным функционалом и разной стоимости. Самый бюджетный и простой вариант это приложение Race Chrono для android и ios racechrono.com/.
У данного приложения очень обширный функционал, позволяющий проводить глубокий анализ и создавать видео с наложение логов. Для начала достаточно установить простую версию программы, она бесплатная и уже позволит вам видеть время ваших кругов. Но есть одно но, программа будет использовать для отслеживания вашего перемещения по треку gps датчик вашего телефона. Обычно его частота 1Hz, то есть он передает на спутник ваше местоположение и получает обратный сигнал один раз в секунду. К сожалению этого мало для качественного анализа и будут большие погрешности. Тут нам придет на выручку внешний gps датчик с частотой от 10Hz, есть и более продвинутые модели с частотой работы 16Hz, но нам будет вполне достаточно 10Hz датчика. На самом деле в продаже достаточно много подобных датчиков, но наверное самый распространенный это продукт фирмы qstarz
Я уже третий год пользуюсь таким датчиком, купить его можно на ebay или amazon но иногда попадаются б/у варианты и на avito. В комплекте идет сам датчик, аккумулятор и зарядное устройство в прикуриватель автомобиля. Единственный минус это то что он работает только с andoid устройствами, для его работы с устройствами apple вам понадобится дополнительное Bluetooth устройство. Ну а если вы фанат apple и не представляете свою жизнь без яблочных устройств то и для вас есть вариант внешнего gps приемника, но он будет немного дороже чем продукт фирмы qstarz описанный выше. Это SkyPro XGPS160
В принципе, таким минимальным набором я пользовался два года, и этого вполне достаточно для начального анализа. Вы можете видеть время круга как после проезда так и онлайн по секторам, анализировать ваши траектории на треке, перегрузки и даже сравнивать с лучшим кругом. Для того что бы полностью разобрать в приложении race chrono и использовать весь его функционал рекомендую посмотреть видео MGK-SpB
Кроме телефона с приложением и внешнего gps датчика, можно использовать видео для записи онбордов. В принципе, можно снимать на сам телефон или планшет на котором установлено приложение если вам так удобно, но можно использовать внешнюю камеру, например go pro. Приложение race chrono позволяет подключить gopro по wifi либо вы можете просто снять ваш проезд на камеру и затем наложить на него логи снятые с помощью race chrono. В идеале что бы получить доступ к полному функционалу можно подключить еще obd2 сенсор по bluetooth либо hondata если у вас Honda.
Я лично пред заездом, устанавливаю внешний gps датчик в машину, подключаю hondata и связываю все оба устройства с телефоном по bluetooth на котором установлен race chrono. Так же ставлю gopro и включаю запись перед стартом. Затем сохраняю видео с gopro в телефон и связываю конкретный онборд с конкретным проездом. О том как это правильно сделать так же рассказано в видео выше. В результате кроме кроме анализа самой телеметрии в приложении, мы получаем видео вашего проезда с наложением траектории, времени лучшего круга, оборотов двигателя, скорости, перегрузки, открытии дроссельной заслонки и на более современных авто можно выводить показания температуры масла и охлаждающей жидкости.
Что нам это дает? По мимо того что вы можете похвастаться перед своими друзьями, можно удивить ошибки пилотирования.
Положение авто на треке, проанализировать ваши траектории.
Плюс gopro в том что ее можно устанавливать практически в любом месте на автомобиле и анализировать работу и настройки подвески и тд.
В общем то, это и есть минимальный набор бюджетной телеметрии, который на сегодняшний день выходит примерно в 10тыс рублей. С его помощью вы можете получить бесценную информацию и стать гораздо быстрее на гоночной трассе.
Клиент-серверное решение для телеметрии на пивоварне своими руками
Ниже пойдёт речь про внедрение на пивоварне телеметрии, для чего я сделал хардварное устройство и управляющий хост в облаке с нуля.
Спойлер: первоначальная цель была достигнута в полном объеме, но планы по захвату рынка не удались.
В моей первой статье на vc.ru хочу поделиться историей об очередном стартапе, который ничем, кроме пилота, не стал (да, это отсылка к фильму Тарантино «Криминальное чтиво»).
Так как это мое первое художественное произведение, прошу судить строго, пинать сильно в комментариях, критиковать не стесняясь и по делу, и просто так! Иначе зачем вообще вам все это читать, а мне писать… Тем более ниже текст минут на 15.
Итак, все началось с того, что, придя однажды в гости на пивоварню своего хорошего товарища, я обратил внимание на разбросанные по столу Arduino, реле и прочие дары AliExpress. Было это в самом начале 2018 года.
Так как я периодически сам баловался подобными игрушками, это меня заинтересовало. На вопрос, что он хочет этим делать, товарищ поделился болью: хочет из дома видеть температуру в своих холодильниках и ЦКТ. Потому что отказ какого-нибудь кондиционера среди лета мог запросто угробить пару тонн вкусностей, превратив их в невкусности.
Знающие люди не станут спорить, что в пивоварении сразу после воды и совести пивовара по значимости идет температурный режим. На мой вопрос, почему он не купит готовое промышленное решение, товарищ ответил, что те решения, которые он знает, не решают его задач полностью.
Делать на заказ получится дорого, и в принципе он уже придумал: присоединит датчик температуры к Arduino, Arduino проводом к стационарному компьютеру, а на стационарный компьютер будет заходить через TeamViewer и смотреть в монитор порта, куда Arduino будет выводить температуру.
Я представил себе этот процесс и поморщился. Это же коряво и неудобно. Но, как говорят умные люди: критикуешь — предлагай.
После подробного интервьюирования задача зазвучала так: находясь где угодно, в нужный момент пивовар может иметь возможность видеть температуру с каждого из нескольких датчиков на пивоварне.
Если температура вдруг повышается выше пороговой, должна быть возможность автоматически включить кондиционер или открыть кран в охлаждающий контур (охладить). При этом решение не должно быть дорогим. От себя я добавил, что решение должно быть по-возможности универсальным, потому что такая штука, со слов товарища, интересует многих его коллег.
Сразу скажу, что пивоварни в принципе все одинаковые. Везде есть варочный порядок, есть бродильное отделение, есть холодильники для вызревания и хранения. Но при этом абсолютно все пивоварни разные.
У всех разный набор танков, состав и объем варочного порядка, схемы и способы охлаждения, расположение всего этого в пространстве. И каждый пивовар (со слов моего товарища) решал проблему телеметрии и автоматизации своей пивоварни индивидуально.
Найти умельца или компанию, которая развесит по пивоварне датчики с ЖК-дисплеями и парой кнопок, не вопрос. Но если нужно, чтобы была какая-то общая логика, цена сильно возрастает, потому что решение нужно делать индивидуально под конкретный состав пивоварни. А если еще и с интернет-доступом…
Такое решение обычно состоит из датчиков, запорной аппаратуры и пульта управления. Пульт обычно состоит из монитора, набора кнопок для управления и, конечно, компьютера с мозгом. Цена подобных решений, понятное дело, складывается из стоимости проектирования, программирования, инсталляции и железа. Сделали, получили деньги за разработку и установку, и до свидания, до очередных доработок.
Мне же хотелось получить решение, которое можно было бы переиспользовать в других пивоварнях, коих все еще довольно много по стране. Хотя, как мне кажется, крафтовый бум начинает уже утихать.
Со всей этой информацией я ушел думать.
Решение, которое описано выше (как у всех), было сразу отметено. Хотя с точки зрения заработка, конечно, идеально: понятно, за что брать сразу много денег, можно дорабатывать за денежку (при каждом изменении количества датчиков, например). Но это неинтересно, нужно же приносить счастье и при том недорого. А недорого можно, если тиражировать решение, в которое вложился один раз.
Вспомнил я про имеющийся у меня подобный Arduino микрокомпьютер с десятком портов и, главное, с Wi-Fi на борту. Сама железка небольшая, таких в спичечный коробок пара поместится, стоит копейки на AliExpress, продается без проблем во многих магазинах и проверена временем.
Как получать с нее данные, допустим, понятно. Самое правильное — клиент-серверная архитектура. Где сервер — это сервер, а устройство — это клиент. Как управлять разными реле в зависимости от температуры на разных датчиках, тоже понятно. Но раз я хочу универсальность, то нужно решить, как не перепрограммировать контроллер для разных конфигураций пивоварни.
Решение было найдено. Решено было делать железку всегда только с одним датчиком температуры и одним реле. Реле на железке управляется в зависимости от показаний датчика этой же железки. Вот и универсальность.
На каждом холодильнике будет по отдельной автономной железке, и на каждом ЦКТ тоже. Каждая железка будет самостоятельно подключаться к общему Wi-Fi и самостоятельно приходить на сервер. Сервер будет принимать данные и возвращать команды на железку. И показывать оператору в браузере картинку со всеми имеющимися устройствами.
Таким образом можно оснастить пивоварню любой конфигурации необходимым количеством устройств, каждое из которых не нужно будет программировать отдельно, только настроить. Настройку тоже можно сделать с сервера. Для управления температурным режимом ЦКТ, холодильника, комнаты, автомобиля, погреба такого решения вполне достаточно.
Организовать Wi-Fi в помещении или даже в нескольких, понятное дело, не проблема. Затраты на избыточное (как может показаться) железо при таком раскладе с лихвой окупаются возможностью легкого масштабирования и отказоустойчивостью, а так же отказом от более дорогого железа в проекте. Не нужны отдельные ПК, мониторы, провода. Смартфон есть у каждого в кармане, ПК есть в каждом офисе.
Каждая железка будет жить отдельной жизнью, а главное, если понадобится добавить пару ЦКТ, не нужно будет вообще ничего переделывать. На сервере не будет изменяющейся логики, так как независимо от количества датчиков и реле каждая их пара (отдельный модуль) будет обрабатываться индивидуально.
Оператору не нужно будет обходить каждый объект, чтобы увидеть его температуру, достаточно достать из кармана смартфон.
Саму железку собрал в модульном исполнении, где каждый модуль можно заменить или отключить. Состоит из, собственно, микрокомпьютера, адаптера питания с АС 220 В на DC 5 В, реле и цифрового термодатчика. При желании запросто можно убрать реле или подключить устройство напрямую к питанию 5 В. При этом на самом устройстве нет ни монитора, ни других органов управления. Все только с сервера.
Конечно, в будущем пришлось бы добавить еще модуль с картой памяти и какую-либо сигнализацию, но пока и так нормально. Я же пока делал решение для одного пользователя, хоть и с расчетом на захват всего рынка. Ха-ха.
Мне такое решение показалось изящным.
Дальше были три месяца погружения в новые для меня области знаний, которых ранее приходилось касаться очень поверхностно. В свободное от работы время (вечерами и в выходные) я увлеченно кодил, изучал, гуглил:
За три месяца был готов прототип (назовем его MVPr, это как MVP, только прототип), написанный собственноручно, который работал. Был кривенький, косенький, но работал. То есть железка была собрана на макетной плате, а сервер был просто двумя страницами на РНР и БД. Но так и задумывалось.
Время было потрачено еще и на проверку возможности управления варочным порядком с помощью этой же архитектуры (только конфигурация железки изменялась).
Задумка была в том, чтобы пивовар мог собрать в браузере рецепт (прямо мышкой задать количество пауз, их температуру, длительность, время варки, время закладок хмеля), и устройство схожей конфигурации, также в режиме клиент-сервер, варила бы пиво по рецепту, одновременно показывая в браузере температуру, текущий шаг, сообщала о необходимых действиях.
Опыт показал, что так тоже можно, оно работает. Сам UX/UI такой варки тоже оказался сильно отличающимся от всего того, что было известно мне. Как правило, лучшее, что можно было найти, — возможность загрузить файлом определенного формата закодированный рецепт в Arduino и смотреть на него через крохотный ЖК-дисплей. Я же сумел построить нечто иное. Но для этой конфигурации я не стал делать MVPr, не все сразу.
Пока я все это делал, меня посетили несколько простых мыслей.
Выбранная архитектура позволяет без доработок подключить к серверу сколько угодно пивоварен. А это отсутствие затрат на разработку индивидуального решения и возможность предоставить сервис по подписке.
Порог вхождения новых пользователей при этом снижался практически до стоимости устройства, даже одного, что, конечно, никакими капитальными затратами не могло быть, так как стоимость устройства оценивалась не дороже аналогов без всякой телеметрии. Оплата за сервис при этом была бы ежемесячная, как за интернет.
В каждой пивоварне может быть сколько угодно железок, даже одна. В каждой пивоварне может быть несколько пользователей (операторов). Разные логины, разные идентификаторы железок, и вуаля. Тиражирование — проще простого. Включаешь железку в сеть и все, она уже видна на сайте тому оператору, к чьей пивоварне она привязана.
По нагрузкам тоже все довольно понятно – хочешь, используй на одном сервере, или запусти пять серверов. Да и в случае особой надобности развернуть такой сервер можно и локально. А еще можно прикрутить мобильное приложение и уведомления в браузер. Разработка и развитие такого решения тоже не проблема, так как используемый стек технологий, пожалуй, самый распространенный. Короче, очень гибкая штука получалась.
Плюс, вокруг можно запросто собрать сообщество пивоваров со всеми вытекающими плюшками. Потому что на сервер заходили бы все и постоянно.
Можно было и не ограничиваться пивоварнями. В магазинах, складах тоже есть такие потребности, и их можно удовлетворить тоже без доработок.
Стартапом уже не пахло, он был виден невооруженным взглядом!
На то чтобы сделать админку, авторизацию пользователей, а самое главное — адаптивный резиновый интерфейс, у меня уже знаний не хватало. Чтобы хоть как-то сделать это решение работоспособным в адекватные сроки с моими знаниями, нужно было использовать какой-либо фреймворк.
Но я и так потратил три месяца на простейший прототип, а изучение фреймворка отбросило бы запуск еще на неизвестное время. В таком виде, как сервер написал я, выкатывать его в интернет было нереально. Он не мог назваться даже прототипом.
Я решил ускориться и взялся за то, что мог сделать сам, бесплатно и быстро: сел писать подробнейшее ТЗ на разработку сервера для фрилансера.
Так как писать требования к разработке программных продуктов — это моя работа, а то, что нужно сделать, я только что сделал сам, проблем с написанием не возникло.
Я поверхностно провентилировал тему фреймворков, прикинул их возможности и ограничения, поэтому точно знал, чего хочу. Через пару дней был готов документ на 18 страниц и подробным описанием желаемого. Причем это был не поток сознания, часто выдаваемый за ТЗ (знаю по собственному опыту фриланса, хоть и далекому уже), а именно техническое задание.
Описано было все техническим языком, структурировано, формат преимущественно UC/US, была описана структура БД, с подробным описанием каждой таблицы, макеты всех экранных форм. Не было нерешаемых задач, потому что все так или иначе было мною сделано.
Были описаны все сущности админки с привязкой к таблицам БД, были прорисованы алгоритмы обработчиков, были описаны требования к развертыванию и критерии приемки работ. Даже требования к логированию и защищенности от кибератак были описаны.
Алгоритмы обработчиков при этом были описаны, наоборот, очень поверхностно, так как я сам собирался доработать эту часть в уже готовом решении. Мне нужно было это уметь делать самому, так как эта часть была самой изменяемой частью кода сервера.
Далее я пошел на Fl.ru, где и была найдена пачка исполнителей, готовых взяться за эту работу. Почти неделя ушла на переговоры с фрилансерами, чтение пространных рассуждений о том, что, раз это стартап, то надо платить программисту 100 тысяч рублей и что там работы на два месяца на самом деле. Но я был непреклонен и отсеивал кандидатов.
Я знал, что нужно сделать и в каком объеме, и знал, что если за работу возьмется тот, кто знает фреймворк на уровне «сделал три сайта на нем», то там делов на 16 часов с перекурами.
Потому что все до последней таблицы было описано, все тесткейсы были прописаны прямо в требованиях, никакого дизайна, никакой необходимости вникать, что же там должен делать обработчик.
По сути, работа сводилась к тому, чтобы развернуть и настроить фреймворк на сервере, добавить БД с нужными таблицами, описать три-четыре простейших алгоритма записи в БД и чтения из нее. При этом денег, конечно же, я хотел сильно сэкономить.
Деньги были мои собственные. Мой единственный заказчик — хороший пивовар, но денег у него никогда нет, он инвестировал в проект глубокие знания предметной области. Деньги (кроме своих знаний) я решил инвестировать с расчетом на то, что вложения отобьются, если сервис взлетит хотя бы у трёх пользователей.
В результате выбор остановился на студенте без отзывов, но из моего города и того же вуза, в котором учился я. Благодаря тому, что ТЗ было написано так подробно, а я пообещал ему отзыв на сайте, он согласился.
Деньги были небольшие, очень небольшие, да еще и без предоплаты и без безопасной сделки. Это были мои условия. Справился парень хорошо. По ходу работ уточнял непонятное, работал небыстро, но не терялся. Я относился к нему с заботой, то есть не гнал его, не ковырял мозг и подробно отвечал на все вопросы (по жизни это тоже часть моей работы). Он поэтому до конца не верил, что эта работа лично для меня:).
Работа заняла примерно неделю, если я правильно помню. Когда тестовый сервер стал доступен в интернете для меня, я «включил тестировщика» и за вечер по своим же требованиям сам протестировал сайт. После чего студент исправил замечания и получил деньги.
В ответ я получил архив с сайтом и инструкции по развертыванию, а также согласие развернуть это в прямом эфире на арендованной VDS под моей учеткой, что и было сделано за полчаса. Сервер заработал. Теперь я мог по-честному подключать железки к интернету.
Над интерфейсом не морочился вообще. Оформили в виде табличек для каждого имеющегося устройства. В будущем планировал вместо табличек использовать изображения ЦКТ и холодильника, подкраску цветом в зависимости от температуры и прочие свистелки.