Телеметрия (часть 1)
Мда… Придется сидеть на 433 и 1.2.
Мда… Придется сидеть на 433 и 1.2.
если это не фантом, то да 433 и 1.2 это лучшее сочетание для полётов от 3 км
Недавно заинтересовался сей темой, быстренько собрал для экспериментов необходимое железо (Rasp-PI В+ +camera (tx), Orange-PI PC (rx), wifi TP-link-wn722n), дальность пока не интересует, а по поводу задержки хочу поделиться своими наблюдениями:
- wi-fi канал, сам по себе, с задачей вполне справляется, зря его некоторые “ругают”, я б сказал “за глаза”, разницы при 1080р и 720р - никакой…(естественно при H264 и аппаратной код/декод на обоих концах)
- а вот от программной организации потока всё и зависит - тут нужно детально разбираться с передающей и принимающей сторонами… дьявол в деталях…
сдается мне (пока), что всё упрется в наш любимый линукс с его шеледуллером (извин., планировщиком задач… )) а тут уже дело тёмное, для “особо приближенных”…
эксперименты продолжаются…
И подозрения, похоже, оправдались… Время от времени, “играя” с размерами буферов (tx и rx) удается добиться почти идеального результата…, но стоит произойти малейшему сбою в связи и картинки “разбегаются” на несколько десятков кадров…
К тому же чудо-raspivid (собака) не хочет кодировать временные метки в поток H264, и как следствие - принимающему плееру не за что вообще зацепиться… Так что надо собственный аппаратный драйвер писАть ()))
Ровно год назад игрался с малинкой. На ней написал код, который запускает raspivid с параметрами от хоста, принимает видео поток, разбивает на кадры и каждый кадр отправляет UDP-дейтограммой. Кроме видеоданных, в каждом пакете передаю структуру с распарсенными данными от GPS-модуля. (Ну там можно еще что угодно передать…).
На приеме на ноуте под Win, сваял код, который строит граф в DirectShow и воспроизводит поток. Тут самым хитрым оказалось, что если отключить синхронизацию (те отправлять на рендер сразу по приему), картинка заметно подергивается. Пришлось сделать буфер под несколько кадров, и генерировать свои временные метки, которыми регулировать скорость воспроизведения с учетом текущего заполнения буфера. В принципе задержка удовлетворительная, цифры не помню. Подключил по бытовому WiFi, погулял по квартире с ноутом. Через две кап. стены практически без дропов (есть счетчик). Надо сказать что обычный аналог на 1080мГц в этих условиях работает несравнимо хуже, куча мест где даже синхра рвется (интерференция…).
Хотел наложить OSD на приеме с данными GPS, неожиданно сложно оказалось, так и не сделал…
На ней написал код,
Нельзя ли поподробней? (питон? си?) хотя бы в общих чертах, куда копать…
В принципе задержка удовлетворительная,
меньше секунды ? или как ? и при каком разрешении… (тут некоторым и 200 мс -“многовато”))
Мне хочется сделать двусторонний линк : туда управление - назад видео, и вообще понять насколько это возможно и какими средствами …
Увы, кроме Си, ничем не владею…
меньше секунды ?
Да вы что… Кажется в районе 50-100мс… Как-нибудь проверю, уточню. От разрешения практически не зависит, проверял правда до 720p, дальше старенький ноут не справлялся. Вывод был- конечно не для активного пилотажа, но вполне…
туда управление - назад видео, и вообще понять насколько это возможно и какими средствами
Никаких проблем, вопрос только в дальности WiFi соединения… И тут уже давно намечено пока одно приемлимое решение- ubiquiti.
И тут уже давно намечено пока одно приемлимое решение
А что с broadcast?
Это другой уровень, туда не лез (только до стека IP)… Кстати, еще объективных оценок по его преимуществу относительно обычного WiFi-коннекта в реале не видел. (видимо оно есть, но сколько в граммах?..)
Это другой уровень, туда не лез
В идеале надо в ядро линукса драйвер ставить… Но к сожалению даже для “народной” игрушки типа raspberry доступ к видеоядру засекречен…
Квадрокоптер c Pixhawk на борту. На планшете установлена QGroundcontrol с поддержкой Gstreamer. Передаю по wi-fi как видео, так и телеметрию. Gstreamer прост в настройке и отлично справляется со своей задачей – картинка в разрешении HD идёт с минимальным лагом.
Экспериментировал с FullHD – лаг на том же уровне, но существенно уменьшается дальность уверенного приёма сигнала: появляются артефакты и т.д. Антенны – клеверы с алиэкспресс.
Перепробовал весь модельный ряд малины – остановился на 2B+ и точках Ubiquiti Bullet M5. Единственное, вытащил пулю из корпуса и перепаял разъём для антенны с N-type на SMA, чтобы уменьшить вес модуля. Крепёж распечатал на 3d принтере, получилось вполне эстетично. Дальность уверенной передачи HD-видео с китайскими клеверами – порядка 500-600 м при отсутствии препятствий.
О достоинствах и недостатках: видеть качественную картинку непосредственно в QGroundcontrol – несомненный плюс для любителей pixhawk/apm. Переключение с карт на видео происходит одним касанием. Команды отправляются без проблем. Настройка происходит без танцев с бубном, несмотря на присутствие Linux. Процесс настройки соединения Raspberry и Pixhawk по разъёму телеметрии подробно и с картинками описан в нете. Недостатки для себя отметил следующие: вес малины, точки доступа, модуля камеры, шлейфа, антенны и крепежа – около 200 грамм. Не самоё бюджетное, но вполне надёжное решение для полётов по камере на небольшие расстояния.
Может стоило бы эту башенку под брюхом центральной чести коптера разместить? Профиль конструкции бы уменьшился, что положительно бы сказалось на аэродинамическом сопротивлении и прибавило бы время полета.
Дальность уверенной передачи HD-видео с китайскими клеверами – порядка 500-600 м при отсутствии препятствий.
При переходе на WIFI Broadcast получите вдвое большее расстояние не той же мощности.
точки доступа,
Точка доступа зачем ? (она отдельная что ль?), ведь на малине ее можно легко организовать …
Точка доступа зачем ? (она отдельная что ль?), ведь на малине ее можно легко организовать …
Мост построен на двух Ubiquiti Bullet M5. Одна пуля (точка доступа) - на земле, вторая (клиент) – на коптере. Пуля, установленная на коптере соединена витой парой с Raspberry Pi. К наземной точке по wi-fi подключён планшет с установленной QGroundcontrol.
У меня есть система, построенная на свистке, но мне она не очень нравится. У малины весьма ограничен набор предустановленных дров под свистки на 5 ГГц. Приходится собирать дрова самостоятельно или искать на гитхабе готовые решения. Во-вторых, запуск точки доступа на малине дополнительно нагружает систему. При передаче изображения в разрешении HD, передаче телеметрии по Mavlink и работе малины в режиме точке доступа я боролся с лагом видео. Хотя, может я что-то криво настроил…
Точка доступа зачем ? (она отдельная что ль?), ведь на малине ее можно легко организовать …
Raspberry Pi Zero v1.3 со свистком asus usb-ac51. Тоже рабочая схема, будет стоять на f450
У меня пока результаты опытов “так себе”…
Задержку видео можно сделать минимальную без особых заморочек (либо связка raspivid->socat->udp, либо вместо socat-a свой примитивный сервер на СИ с сокетами), правда это испытано только на столе, хотя помехи и сбои всеравно периодически дают непредсказуемый лаг картинки…
А вот при двунаправленной связи, которую и хотелось в принципе, тормоза уже неприемлимые (опасные для ЛА)…
Соответственно делаю вывод: “нахаляву” этот номер не пройдет, либо надо лезть в дебри линукса, что скорей всего закончится полным отказом от него… как такового , либо управлять “луноходом” и не париться… (тоже круто, кстати)
У меня пока результаты опытов “так себе”…
Задержку видео можно сделать минимальную без особых заморочек (либо связка raspivid->socat->udp, либо вместо socat-a свой примитивный сервер на СИ с сокетами), правда это испытано только на столе, хотя помехи и сбои всеравно периодически дают непредсказуемый лаг картинки…
А вот при двунаправленной связи, которую и хотелось в принципе, тормоза уже неприемлимые (опасные для ЛА)…
Соответственно делаю вывод: “нахаляву” этот номер не пройдет, либо надо лезть в дебри линукса, что скорей всего закончится полным отказом от него… как такового , либо управлять “луноходом” и не париться… (тоже круто, кстати)
Олег, мне кажется, сравнение с луноходом несколько преувеличенно 😃 Задержка при двусторонней связи не превышает 150-200мс. Визуально это сопоставимо с лайтбриджем на фантомах, а они как то летают… Я согласен, что для полёта на гоночном дроне между деревьев это неприемлемо, но для спокойных FPV полётов на аппаратах 450 размера и более - вполне терпимо. Мой вариант с точками Ubiquiti сводится к установке Gstreamer’а на Raspberry Pi и настройке моста между двумя пулями. Причём двусторонняя связь позволяет отправлять команды и настройки с планшета на дрон прямо в полёте
последняя реализации у dji та что на мавике работает пошустрее чем 150-200мс
сравнение с луноходом несколько преувеличенно
Тогда сразу вопрос: у Вас не выскакивают периодически (непредсказуемо) “провалы” в связи ?
Тут вопрос даже не в самом сбое , а в том как быстро система из них способна восстановиться, или не-восстановиться… короче говоря в надёжности.
сопоставимо с лайтбриджем на фантомах
Ну там наверно не так примитивно сделано, наверно люди поработали, возможно пожертвовали задержкой в угоду надежности… (ИМХО)
Тогда сразу вопрос: у Вас не выскакивают периодически (непредсказуемо) “провалы” в связи ?
Тут вопрос даже не в самом сбое , а в том как быстро система из них способна восстановиться, или не-восстановиться… короче говоря в надёжности.
Ну там наверно не так примитивно сделано, наверно люди поработали, возможно пожертвовали задержкой в угоду надежности… (ИМХО)
Олег, непредсказуемых провалов пока не было. Были лаги и артефакты, вызванные конкретными причинами: наводки на шлейф камеры и 100% загрузка процессора Raspberry Pi. Причины были вылечены. Сейчас наиболее вероятен сбой, связанный с потерей wi-fi соединения (препятствие/дальность), но в этом случае точки Ubiquiti быстро друг друга находят
Именно для предсказуемости результата, я разбивал поток на кадры сразу в малине и передавал их пронумерованными в отдельных пакетах. Не приходит один кадр- появляются небольшие артефакты до следующего ключевого кадра. Частоту передачи ключевых кадров можно задавать в raspivid, и для динамической картинки ее можно делать довольно частой, без серьезного увеличения трафика (размеры дельта-кадров соизмеримы с ключевыми). Кроме того, с таким потоком легче и надежнее работать на приеме: более-менее равномерно приходящие пакеты надежнее принимаются в потоке Win (в принципе без потерь даже на слабой машине при надежном линке, а сколько вопросов по этому поводу задают…), ну и Source Filter заметно упрощается.
я разбивал поток на кадры сразу в малине
Чет пока не получается у меня из raspivid-a найти “кадровые метки”, ерунда какая то лезет… Вроде ищу последовательность байт 0х00 0х00 0х00 0х01 типа начало заголовка NALU… , а результат какой то странный (явно не правильный).
Где то в потоке что то не то, что пишут, хотя есть программа SecialVH264.exe, она вроде всё находит как надо и заголовки и блоки… короче разбираться надо… читать матбазу на H.264
я разбивал поток на кадры сразу в малине
Разобрался я с H.264… легче не стало…
Делаю так: читаю в буфер два кадра (что б начало и конец полюбому попадало в него) это ~200 Кб, нахожу начало и конец, считаю количество байт, отправляю по воздуху 1 найденный кадр, результат - суммарная задержка ~ 0.3-0.4 секунды…
Не знаю как у Вас получается быстрее (?)… вроде всё до безобразия оптимально и написано на Си… и на приеме тормозить не может, там еще всё проще - кадр из приемного буфера сразу в mpvplayer с аппаратным ускорением (у меня)…
Что я делаю не так ?
fpv.blue обещают в конце января свой хд линк выпустить. 900-1.2частота задержка 50мс дальность 7км очень заманчиво.
fpv.blue обещают в конце января свой хд линк выпустить. 900-1.2частота задержка 50мс дальность 7км очень заманчиво.
Они с мая прошлого года обещают. Обещанного три года ждут как говорится 😁
Ну вот, из пустого в порожнее. Я же тоже не отменял GPS. Я его отменил для задач измерения высоты и скорости.
Ну вот, из пустого в порожнее. Я же тоже не отменял GPS. Я его отменил для задач измерения высоты и скорости.
Ну, так уж сразу и “в порожнее” ? - В результате наших “переливаний” Вы, например, уже слегка “урезали осетра” - с 5км диапазона и 1м точности до несколько неопределенных слов про “минимально возможную погрешность”… В процессе выяснилось, что “минимально возможная” от gps нас не устраивает; - теперь следует понять, годится ли эта самая минимально возможная от барометра… 😃
Пожалуйста, не обижайтесь, но это традиционная ошибка заказчика (я сейчас не имею в виду какие-то коммерческие отношения между обитателями этого форума, а просто смотрю на подход к задаче “у целом”), когда сначала заявляются какие-то запредельные (с технической точки зрения) требования, а потом - когда разработчик предлагает под это совершенно непомерное по цене решение - выясняется, что цифры были взяты, в общем, с потолка, а на самом деле годится и на порядок или два хуже.
Вообще, это совершенно традиционный вариант переговоров:
З: Неужели методом X нельзя получить точность YYY ? А каким тогда можно ?
Р: Ну, вообще это делается ZZ, но это очень сложно и дорого, поэтому можно попробовать Z. Это будет стоить NN.
З: Нет, NN - это тоже слишком дорого ! А что можно получить, если все-таки поставить X ?
Р: Ну, YYY точно не получится. Обычно оно дает Y, но если исхитриться, то можно сделать 2Y.
З: 2Y, говорите ? Нда, это звучит не так красиво. Ну, ладно, пусть тогда будет просто Y…
Р: А зачем же вы просили YYY ?
З: Ну, у буржуев всего 4Y, а мы хотели чтобы было лучше. И вообще, двенадцатиразрядный индикатор так красиво вписывался в нашу приборную панель !
😁
Ладно, ладно, я все понимаю. Заказчик обычно не очень сильно понимает чего хочет. Он где-то слышал, где-то видел и начинает фантазировать свои запросы. В данной теме я выступаю в роли виртуального заказчика и я “не сильно в теме” возможностей и тех решений. Отсюда и цифры.
Давайте попробуем сделать по другому.
Я опишу чего бы я хотел на словах, без цифр. А все желающие пускай напишут как это можно реализовать в каких цифрах, погрешностях и размерностях
Для пилотирования ДПЛА мне необходимо знать; Высоту относительно точки старта, скорость воздушную,скорость относительно земли, иметь вектор направления на базу, удаление от базы напряжение силовых батарей, напряжение батарей телеметрии, полетное время.
Ваши предложения?
Кстати, по-моему, барометрический датчик можно-таки вполне успешно “уточнять” GPSом, получая плюсы и того, и другого методов и без их минусов. То есть, хорошую точность при высокой скорости обновления.
Дарю идею, которая лежит на поверхности: на протяжении всего полета, или последней минуты-двух-трех, каждую секунду кладем в копилку (в циклический массив) высоту от GPS и высоту от барометра. Каждую секунду усредняем. Средняя высота от GPS точнее, поскольку усреднена на длинном интервале времени, на нее и опираемся. Вычитаем одно среднее из другого и прибавляем к показаниям барометра, который точнее на коротких интервалах времени.
На экране 50 раз в секунду показываем скорректированные показания барометра.
Вот.
Сам не пробовал, и не хочу пока - не хочу пока связываться с GPS 😃
Я опишу чего бы я хотел на словах, без цифр. А все желающие пускай напишут как это можно реализовать в каких цифрах, погрешностях и размерностях
Для пилотирования ДПЛА мне необходимо знать; Высоту относительно точки старта, скорость воздушную,скорость относительно земли, иметь вектор направления на базу, удаление от базы напряжение силовых батарей, напряжение батарей телеметрии, полетное время.
Ваши предложения?
По моим (грубым) оценкам, барометрическая высота на небольшом (скажем, до 30 минут) интервале времени может быть получена с точностью метра в 3-5. Потом (через эти самые полчаса) - перекалибровка на земле.
Воздушную скорость навскидку не оценю (эту цифру, наверное точнее назовет smalltim), но думаю, что 1-2м/с получить вполне можно, а лучше - точно не нужно. Скорость относительно земли - это уже с GPS’а; - будет 0.5-1м/c.
Азимут и дальность - в зависимости от того, насколько в угоду производительности будет упрощена математика - думаю, от 5-10 градусов и 10-20 метров - вполне реально. (На самом деле, угол будет тем точнее, чем больше дистанция. В радиусе же 2КВО он, очевидно, начнет метаться, как потерянный.)
Напряжения и токи - в принципе, сколь угодно точно, но по факту лучше чем 100мВ и 100мА для этих задач явно не нужно. Время - вплоть до 20мс.
Устраивает ? 😃
Дарю идею, которая лежит на поверхности: на протяжении всего полета, или последней минуты-двух-трех, каждую секунду кладем в копилку (в циклический массив) высоту от GPS и высоту от барометра. Каждую секунду усредняем. Средняя высота от GPS точнее, поскольку усреднена на длинном интервале времени, на нее и опираемся. Вычитаем одно среднее из другого и прибавляем к показаниям барометра, который точнее на коротких интервалах времени.
“Нипалучицца !” 😛
“Средняя высота” летящего самолета - примерно столь же ценная информация, как и средняя температура по больнице, и поскольку в процессе полета она изменяется в пределах, значительно (вернее, “как минимум, на порядок”) больших, нежели та ошибка, которую мы хотим скорректировать, то использовать это самое “среднее значение” (неважно за какой интервал) для повышения точности - достаточно бессмысленно.
На экране 50 раз в секунду показываем скорректированные показания барометра.
А это - еще более бессмысленно. 😉
Цифровую информацию, обновляемую с тактом быстрее 300-500мс, человек вообще воспринять не в состоянии, а ведь нужно на нее еще и как-то отреагировать…
Чаще, чем раз в секунду, обновлять на экране не следует ничего.
(Я, конечно, нарушал этот принцип, обновляя, например, на каждом кадре время, но делалось это исключительно в целях постанализа по записи: у меня был индикатор помех, и я хотел увидель, как долго они могут длиться…)
По моим (грубым) оценкам, барометрическая высота на небольшом (скажем, до 30 минут) интервале времени может быть получена с точностью метра в 3-5. Потом (через эти самые полчаса) - перекалибровка на земле.
Воздушную скорость навскидку не оценю (эту цифру, наверное точнее назовет smalltim), но думаю, что 1-2м/с получить вполне можно, а лучше - точно не нужно. Скорость относительно земли - это уже с GPS’а; - будет 0.5-1м/c.
Азимут и дальность - в зависимости от того, насколько в угоду производительности будет упрощена математика - думаю, от 5-10 градусов и 10-20 метров - вполне реально. (На самом деле, угол будет тем точнее, чем больше дистанция. В радиусе же 2КВО он, очевидно, начнет метаться, как потерянный.)
Напряжения и токи - в принципе, сколь угодно точно, но по факту лучше чем 100мВ и 100мА для этих задач явно не нужно. Время - вплоть до 20мс.Устраивает ? 😃
Мне кажется, тут должна последовать фраза из анекдота: “Дорогой, а с кем это ты сейчас говорил?”😃
Тем более, не полетавши на ДПЛА выдвигать какие-то ТТХ- занятие довольно бессмысленное, примерно- как бокс по переписке…
А азимут с точностью 10 градусов- это не курс, а направление:)
Прикиньте, где окажется аэроплан , летящий с удаления 5км с точностью 10грд.? Правильно- нэ в нашэм районе.
Вот, наткнулся о GPSах , надеюсь кому нти это будет тоже интересным. www.navigatorgps.ru/content/view/125/7/
Вот, наткнулся о GPSах , надеюсь кому нти это будет тоже интересным. www.navigatorgps.ru/content/view/125/7/
Дело в том, что приемник GPS и GPS модуль- две очень разные вещи: приемник- это законченное устройство, с набором определенных потребительских функций и ограничений: например, точность определения места в приемнике- в несколько раз хуже, чем в модуле- это определяется законодательными моментами (не точнее30 метров)
Сами модули- также различаются, уже на стадии изготовителя- гражданские (обычно ограничена скорость обновления информации , максимальная высота и скорость движения) и военные- с частотой “обновления” до 30 гц. Поэтому реклама продавца бытовых GPS в данном форуме- абсолютно неинтересна, просто- не та тематика.
“Нипалучицца !”
Средняя высота" летящего самолета - примерно столь же ценная информация, как и средняя температура по больнице, и поскольку в процессе полета она изменяется в пределах, значительно (вернее, “как минимум, на порядок”) больших, нежели та ошибка, которую мы хотим скорректировать, то использовать это самое “среднее значение” (неважно за какой интервал) для повышения точности - достаточно бессмысленно.
А Вы подумайте хорошенько 😃
Есть такие слова, как матожидание и дисперсия. Давайте их применим к нашим летающим баранам.
У показаний с ГПС матожидание будет где-нибудь в районе средней высоты полета за последние три минуты. Дисперсия - большая, но на матожидание она принципиально не влияет.
У барометрического датчика матожидание будет то же где-нибудь рядом с матожиданием высоты от ГПСа, но не в точности такое, ибо уползает из-за изменения атм. давления. Дисперсия показаний у барометра на маленьких интервалах времени невелика.
Представьте себе две кривые на графике: одна - показания от ГПС, шумная, рваная, но при усредении большого количества отсчетов достаточно точно описывающая высоту. Вторая кривая - показания от барометрического датчика. Точно такая же по форме, но, во-первых, без шумов, а во-вторых, уползающая вниз-вверх при изменении атм. давления.
Ну так и кто мешает сдвигать показания барометрического датчика _постоянно_, основываясь на показания ГПС, несмотря на то, что средняя высота за последние три минуты не имеет смысла?
Мне кажется, тут должна последовать фраза из анекдота: “Дорогой, а с кем это ты сейчас говорил?”😃
Тем более, не полетавши на ДПЛА выдвигать какие-то ТТХ- занятие довольно бессмысленное, примерно- как бокс по переписке…
Я готов согласиться, что у меня - “не настоящий ДПЛА”. - Не буду спорить о терминологии. 😉
Но меня полеты на своем пепелаце вполне устраивают, равно как и моя реализация телеметрии. Не говоря уже о том, что оценку точности той или иной технолигии можно давать, вообще ни на чем не летая, - достаточно знать предметную область.
Не нравятся мои оценки - приведите свои. Желательно вместе с конкретными технологиями, и ценами на их реализацию. Можно даже с примерами из жизни… В противном же случе, - если продолжать “боксерские” аналогии, - Вы будете продолжать вести бои с собственной тенью 😁.
А азимут с точностью 10 градусов- это не курс, а направление:)
Прикиньте, где окажется аэроплан , летящий с удаления 5км с точностью 10грд.? Правильно- нэ в нашэм районе.
Ошибка в определении угла в прямоугольном треугольнике определения точностью задания его катетов и точностью вычисления арктангенса. Первое для одночастотного gps-приемника заведомо известно - это порядка 15м КВО, а второе выбирается, исходя из вычислительных ресурсов и решаемой задачи. Если Вы еще не забыли, то обсуждается не самолет-разведчик, отправляемый на территорию сопредельного государства, а чисто хоббийная примочка - just for fun, и исходя из этой задачи я и озвучил ошибку в 10 градусов, которая возможная на удалении порядка сотни-другой метров (ближе самолет уже точно видно глазом, равно как с него видна и ВПП). И тут вполне пригодно даже “направление”.
Если же вдруг предположить, что мы вдруг действительно улетели на 5 километров, и у нас при этом не пропал ни ап- ни даунлинк с моделью, то несложно прикинуть, что на таких удалениях угловая ошибка будет порядка четверти градуса, - то есть, значительно меньше того, что вообще имеет смысл отображать на экране…
А Вы подумайте хорошенько 😃
В данном случае - не буду спорить.
Если Вам удастся (например, на простейшей мат. модели, состоящей из трех графиков: а) некая “истинная” высота, б) “накладываемая” на нее ошибка gps-приемника и в) монотонно “уплывающая” ошибка барометрического высотомера) продемонстрировать работающий алгоритм, делающий из а+б и а+в “чистое” а (с точностью, лучшей, чем каждая из этих ошибок) - я с удовольствием признаю собственную неправоту в этом вопросе и возьму Ваш метод на вооружение…
Представьте себе две кривые на графике: одна - показания от ГПС, шумная, рваная, но при усредении большого количества отсчетов достаточно точно описывающая высоту.
Для “усреднения на большом количестве отсчетов” нужно, чтобы характерная постоянная времени изменения истинной высоты была много больше периода “плаваний” показания приемника из-за всяко-разных ионосферных, тропосферных, и прочих задержек. А она, к сожалению, или сравнима с последним, или даже меньше его…
В данном случае - не буду спорить.
Если Вам удастся (например, на простейшей мат. модели, состоящей из трех графиков: а) некая “истинная” высота, б) “накладываемая” на нее ошибка gps-приемника и в) монотонно “уплывающая” ошибка барометрического высотомера) продемонстрировать работающий алгоритм, делающий из а+б и а+в “чистое” а (с точностью, лучшей, чем каждая из этих ошибок) - я с удовольствием признаю собственную неправоту в этом вопросе и возьму Ваш метод на вооружение…
Вот через неделю закончу одну хреньку по работе, тоже, кстати, связанную с обработкой и отображением сигналов, и попробую сделать модель. Думаю, Екселя хватит 😃
Проблемы видятся только в том случае, если истинная высота самолета сильно (сильнее уровня шумов) меняется с частотой выше, чем половина частоты опроса GPS. Ну, это понятно, происки Найквиста-Котельникова. Если самолет не шарахается вверх-вниз чаще чем раз в 2 секунды, всё должно быть хорошо 😃
Ну вот, народ начинает вспоминать теорию автомачического регулирования. Время реакции по рассматриваемой оси = Т, соответственно инфу о этой оси нужно получать не реже чем Т/2 (по Найквисту)
Для начала вам, товарищи спорщики нужно знать истинную высоту полета чтоб делать какие-то выводы. 😃
Иначе это будет спор чем один “фуфлометр” лучше другого…
барометр в спокойную погоду за час обычно уплывает на 5-12м. перед дождем- бывает и 20-30м, но редко.
Далее. ну посмотрите же наконец, на картинки, котрые я выкладывал. 😃
право же, не из пальца содержание, расположение и размер цифр высосаны.
Мне еще далеко до такого уровня просветления. Да и не нужно.
Прочитал всю ветку…
Хочу высказать глубокое уважение к активистам данного вопроса!
Потихоньку изучаю этот вопрос. С pic дружу, тем паче есть хорошие помощники на работе.
Как продвигаются дела у
Artie
Куда деньги нести - признаться, не знаю. Свою версию как нечто коммерческое я не рассматриваю, бо делается оно крайне немудряще; - там не за что брать деньги. Выкладывать свои сорсы в public domain я пока не буду, бо за код стыдно (это, в общем, была поделка уровня “проект выходного дня”), но со временем - по мере причесывания и доведения до ума - вероятно, выложу.
Что посоветуете ‘на попробовать’ для начала?
Прочитал всю ветку…
Хочу высказать глубокое уважение к активистам данного вопроса!
Потихоньку изучаю этот вопрос. С pic дружу, тем паче есть хорошие помощники на работе.
Как продвигаются дела у
Artie
Что посоветуете ‘на попробовать’ для начала?
Я в скором времени всё выложу. Схему, ASM-код, прошивку, печатную плату в 2 вариантах. Только у меня не PIC, а Mega8. Artie дал добро на выкладывание своего собственного кода отрисовки в состеве моего безобразия, а всёго остального, что у меня понаписано, мне не жалко. Да и нет там каких-то уж особенных откровений.
Здорово! Буду ждать с нетерпением! А пока пенорезку буду заканчивать!
Ура!
Сегодня собрал схемку на печатной плате в варианте для SMD, всё заработало, ошибок в разводке не обнаружилось 😃
На плате стоит MPX4115 вместо MPX5010D, завтра надо переписать в коде коэффициенты пересчета давления в высоту.
А начиналось всё очень интересно: только собрал плату, запустил, программирую, так обнаруживаю детеныша, увлеченно водящего жалом тестера по ногам меги8. А мега маленькая, SMDшная, тут ноги и коротнулись. Взгрустнул.
Отправил детеныша спать, впаял новую мегу, прошил - не пашет. Прошиваю заново - вообще не видится. Смотрю fuse-биты - мммааать… Биты поставлены на синхронизацию от внешнего генератора. Взгрустнул пуще прежнего, мега-то последняя, где в час ночи новую достанешь? Подумал. Достал старый вариант телеметрии, быстренько вшил в него простенькую программку, чтоб на видеовыход отсылался меандр, подключил к новой платке - ура, мега определилась. Вшил правильные fuse-биты, прошил - не работает. Прошил меандровую программу - вполне себе меандрит в видео. Сижу, думаю, разглядываю плату. Ага, в цепи ресета LM1881 вместо 680кОм на землю стоит 680Ом. Достал линейку резисторов, проданных в Чипе-Дипе - правда, 680 Ом. Однако!
Поковырялся в заначке, выпаял с какой-то платы 470кОм, впаял - заработала!
Все остальное завтра, а сейчас - отдыхаю 😃
Ура!
Сегодня собрал схемку на печатной плате в варианте для SMD, всё заработало, ошибок в разводке не обнаружилось 😃
На плате стоит MPX4115 вместо MPX5010D, завтра надо переписать в коде коэффициенты пересчета давления в высоту.А начиналось всё очень интересно: только собрал плату, запустил, программирую, так обнаруживаю детеныша, увлеченно водящего жалом тестера по ногам меги8. А мега маленькая, SMDшная, тут ноги и коротнулись. Взгрустнул.
Отправил детеныша спать, впаял новую мегу, прошил - не пашет. Прошиваю заново - вообще не видится. Смотрю fuse-биты - мммааать… Биты поставлены на синхронизацию от внешнего генератора. Взгрустнул пуще прежнего, мега-то последняя, где в час ночи новую достанешь? Подумал. Достал старый вариант телеметрии, быстренько вшил в него простенькую программку, чтоб на видеовыход отсылался меандр, подключил к новой платке - ура, мега определилась. Вшил правильные fuse-биты, прошил - не работает. Прошил меандровую программу - вполне себе меандрит в видео. Сижу, думаю, разглядываю плату. Ага, в цепи ресета LM1881 вместо 680кОм на землю стоит 680Ом. Достал линейку резисторов, проданных в Чипе-Дипе - правда, 680 Ом. Однако!
Поковырялся в заначке, выпаял с какой-то платы 470кОм, впаял - заработала!Все остальное завтра, а сейчас - отдыхаю 😃
Ночью- надо спать!
А по поводу SMD процессоров Минздрав предупреждал: при отработке программы они крайне неудобны! Ну а в общем- поздравляю.
Только от детеныша паяльник прячь- хорошо, что он водил жалом (300 градусов!) не по своим или твоим ногам, а по “мегиным” 😃
А то у моего знакомого всей пятерней хватанул- тут уж стало не до пайки 😦
Итак, на высоте 9-го этажа платка выдала ровно 24 метра. Потом в течение 5 минут MPX4115 медленно плыл, нагреваясь, и высота “подросла” до 26 метров. Учитывая разницу в 15-20 градусов между уличной температурой и температурой в квартире - неплохо. В полете такой разницы, конечно, не будет.
При неизменной температуре, т.е., в комнате, за 5 минут гуляние показаний датчика с моей обработкой оказалось 0.8 метра, т.е., меньше чем шаг альтиметра. В сэмплах это уплывание оказалось суммарно 6 сэмплов при усреднении 16 накоплений по 64 измерения родным 10-битным атмеговским ЦАПом.
Касание датчика пальцами, дышание на него и прочие пляски с бубном дают ± 2 сэмпла.
В общем, всё прекрасно, я даже удивлен 😃
Осталось только вставить отрезание отрицательных высот и обработку отрицательных температур от термодатчика - сейчас он фигню при минусе показывает - и всё, выкладываю всё на обозрение.
Так, начинаем раздачу.
Видео старта телеметрии: первые 15 секунд - “разогрев датчиков”: инициализация нуля высоты и скорости в момент времени 5, 10 и 15 секунд.
ASM-код и прошивка телеметрии:
Схема и разводка печатной платы в Eagle:
Eagle доступен в бесплатной версии, проблем быть не должно
Фото вариантов печатных плат:
Фото телеметрии в сборе. Серый шлейф идет к разъему программирования, он будет отпаян. Плата после промывки перестанет пугать внешним видом:
ASM - код кое-где имеет комментарии, “чтоб сам не забыл”, так что проблем с пониманием как что работает, быть не должно.
Железка питается от 3S LiPo (соответственно, код заточен на показ трех напряжений), на плате стоит линейный стабилизатор 5В 0.5А, питающий атмегу и всё остальное. Есть диодная защита от переполюсовки по питанию.
Меряет:
Температура: -40…+85 градусов с шагом 1 градус
Высота: 0…999м с шагом 1 м
Скорость 0…350кмч с шагом 1 кмч
Напряжение: 3х 0…9.99В с шагом 0.01В. Из напряжений на банках 2 и 3 вычитаются напряжения банок 1 и 2, чтоб получить индивидуальные побаночные напряжения. Соответственно, независимо три напряжения не померять без изменения кода.
Что еще?
Синхронизация времени ведется по кадровым синхроимпульсам видеосигнала, так что при мощных помехах в видеосигнале или отключении камеры время останавливается 😃
Да, самое главное:
Спасибо Artie, Foxfly, Serj за советы и поддержку 😃
Вах … спасибо. 😃
Эх, придется делать 😃 😃 Спасибо !!!