Search in topic

Телеметрия (часть 1)

Нада скидываться на WMR и заказывать двадцатку. Я с удовольствием руку приложу к программке

Для разработки приложения отображения параметров телеметрии на ПК (Windows XP) начали обсуждать протокол передачи.

Цель - использование единого ПО отображения для различных вариантов телеметрии.

ПК подключается к приемному устройству телеметрии через RS232 или через USB (RS232/USB конвертор).

Для различных приложений (вертолетных, планерных, самолетных и т.д), где передаются различные параметры, предлагается использовать или идентификатор протокола или идентификаторы параметров.

Предварительное обсуждение пока началось на Форуме у LeshaK здесь forum.leshak.ru/viewforum.php?f=4 , для входа в форум надо зарегистрироваться.

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

Привет Всем.
С Новим Годом.
Вопрос по ОСД плате:
Обясните зачем со стороны земли проведион Землианой проводник от акумулиатора?
Он всиоравно соединиаетсиа с землиой на “Крене”

>Обясните зачем со стороны земли проведион Землианой проводник от акумулиатора?

Чтобы земля для платы бралась с той точки, где стоят конденсаторы-помеходавы,
чтобы была меньше вероятность образования токовых петель.

smalltim, существуют ли сейчас варианты получения КИТа для сборки телеметрии?

>Предварительное обсуждение пока началось на Форуме у LeshaK здесь

Пока там обсуждения-то и нет особого.
Пару мыслей пока выложу тут.

1. На USB гораздо удобнее оперировать с паектами фиксированного размера.
2. Глянул скриншоты с графиками. Убожество. Я 2 года назад на flash за месяц написал просмотровщик данных (графиков) с , походу, невиданным для иглтриии функционалом. В мой вариант телеметрии перейдет 1 в 1, тока 3D добавится.
3. ИМХО, лучше делать систему максимально открытой: сделать ядро (логика там, работа с файлами и т.д.) и выставить наружу кончики API - позволить людям самостоятельно писать функции парсинга данных, отрисовки этих данных на экране, и т.д.

smalltim, существуют ли сейчас варианты получения КИТа для сборки телеметрии?

Отписал в личку.

>Я 2 года назад на flash за месяц написал просмотровщик данных
Вот картинка. Не показательная, но первая что нашел. Данные (до 32 графиков) берутся с жесткого диска или urlRequestами с любого http адреса или из баз данных. Структура меню, внешний вид и функционал настраиваются в XML файлах, само ядро на flash. Заточено всё под работу на строне сервера и отображение в браузере пользователя, но может работать и находясь локально на диске пользователя.

то smalltim. мне пожалуйста тоже ответьте по кит-у. я писал Вам в личку.

Отодвинув выпифку и салаты в сторону, потихоньку обрастаем мясом:

>Предварительное обсуждение пока началось на Форуме у LeshaK здесь

Пока там обсуждения-то и нет особого.
Пару мыслей пока выложу тут.

1. На USB гораздо удобнее оперировать с паектами фиксированного размера.
2. Глянул скриншоты с графиками. Убожество. Я 2 года назад на flash за месяц написал просмотровщик данных (графиков) с , походу, невиданным для иглтриии функционалом. В мой вариант телеметрии перейдет 1 в 1, тока 3D добавится.
3. ИМХО, лучше делать систему максимально открытой: сделать ядро (логика там, работа с файлами и т.д.) и выставить наружу кончики API - позволить людям самостоятельно писать функции парсинга данных, отрисовки этих данных на экране, и т.д.

Выскажу свою позицию по вопросу телеметрии, сугубо IMHO:

• вариант передачи телеметрии через видео изображение - удачное бюджетное решение для простой задачи полета в пределах 1,5 км.

  • Плюсы:

    • простота
    • дешевизна.

  • Минусы:

    • ограниченный радиус действия
    • невозможность записи в log параметров
    • невозможность анализа параметров полета
    • невозможность использования внешних приложений, использующих полетные параметры

• вариант передачи телеметрии в звуковом канале видео передатчика.

  • Плюсы по отношению к первому варианту:

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

  • Минусы по отношению к первому варианту:

    • более сложное решение, требующее установки и на борту и на земле дополнительных блоков, обеспечивающих безошибочную передачу данных в радиоканале.

• вариант передачи телеметрии отдельным радиоканалом.

  • Плюсы по отношению ко второму варианту:

    • существенное увеличение радиуса действия получения телеметрических данных за счет использования узкополосных сигналов, безошибочной передачи и использования ретрансляторов
    • гарантированное получение телеметрических данных при существенно меньшей потребляемой мощности передатчика (соответственно меньше габариты и вес)
    • получение телеметрии не зависимо от видео картинки
    • наложение телеметрии на видео картинку в наземном блоке

  • Минусы по отношению ко второму варианту:

    • более сложный
    • более дорогой
    • требуется дополнительный передатчик телеметрии

Итак, если мы хотим иметь

• возможность записи в log параметров
• возможность анализа параметров полета
• возможность использования внешних приложений, использующих полетные параметры

следует использовать второй или третий варианты.

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

Если протокол будет определен - а это первично, то создавать графические оболочки можно будет под различные требования.

Поэтому начать нужно именно с согласования протокола.

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

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

Как уже говорилось, аудиосигнал пропадает намного раньше картинки, т.е. 2 вариант отметаем.
По 3 варианту:
во-первых, получается 2 передатчика на борту - некоторые и с одним передатчиком справится не могут - лезут помехи и уменьшается радиус действия р/у. Во-вторых, зачем мне нужны данные телеметрии на земле и большой радиус действия отдельного передатчика телеметрии, если картинка раньше пропадет? В этом случае намного проще писать лог на борту, а по прибытии на землю подробно рассмотреть его, хоть с помощью “внешних приложений, использующих полетные параметры”, проанализировать полет.
От того, что данные будут передаваться на землю - толку мало, если модель улетит - нечего и анализировать будет.
Путь, которым идет smalltim, самый правильный. Телеметрия+автопилот(на случай пропадания сигнала управления).
Если плюсом разработать платку логгера с записью полетных параметров в EEPROM, то это будет самый оптимальный вариант на мой взгляд.

>Если плюсом разработать платку логгера с записью полетных параметров в EEPROM, то это будет самый оптимальный вариант на мой взгляд.

В моем автопилоте с рождения присутствует 2МБ flash памяти для логов всех данных со всех датчиков автопилота и платы телеметрии с заданной пользователем частотой. На фото полуготовой платки это самая 8-ногая микросхемка.
В PC-приложении - полноценный просмоеровщик-анализатор логов.

>Итак, если мы хотим иметь

• возможность записи в log параметров
• возможность анализа параметров полета
• возможность использования внешних приложений, использующих полетные параметры

Всё это, как видите, в полной мере присутствовать будет.

НО.

Главные минусы -

1. отсутствие машинораспознаваемых данных с телеметрии на земле в реальном времени.
2. неоптимальный радиоканал.

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

Как уже говорилось, аудиосигнал пропадает намного раньше картинки, т.е. 2 вариант отметаем.

Иногда лучше молчать, чем говорить … ©

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

По 3 варианту:
во-первых, получается 2 передатчика на борту - некоторые и с одним передатчиком справится не могут - лезут помехи и уменьшается радиус действия р/у.

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

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

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

Путь, которым идет smalltim, самый правильный. Телеметрия+автопилот(на случай пропадания сигнала управления).

Мое предложение не идет в разрез с проектом Smalltim, а дополняет его, так так на плате телеметрии и автопилота есть serial выход на отдельный радиоканал телеметрии.

• возможность использования внешних приложений, использующих полетные параметры

Всё это, как видите, в полной мере присутствовать будет.

Такие интересные приложения, которые требуют реального времени - например сопровождение антенн РУ и телеметрии наземной станции и цифровых ретрансляторов, работать смогут только в вариантах два и три.

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

Поэтому и было приглашение обсудить протокол всем заинтересованным разработчикам и сделать его действительно открытым.

Список деталек на автопилот и платки пирометров:

Добавление: еще AD8552 2 шт и TPS333 6шт, что-то они не проэкспортировались корректно 😦.

Передача телеметрии по каналу звука -наверно наиболее простое и эффективное решение.
А если кем то будет написано приложение ( это называется драйвер ?) ,позволяющие поступающий сигнал на аудиовход ноута ( а не последовательный порт ) обрабатывать да еще транслировать в Гугл Планета -земля будет вообще отлично.
Извиняюсь, если не в тему - не все странички читал.

К проекту подключится не поздно ?
Заказать кит для сборки ?

А можно ли подключить 3 вольтовый GPS модуль к автопилоту, насколько сложная будет доработка?

>А можно ли подключить 3 вольтовый GPS модуль к автопилоту, насколько сложная будет доработка?

Только позаботиться, чтоб была общая земля и чтоб на модуль где-то 3.3В питания обеспечилось.

>К проекту подключится не поздно ?
>Заказать кит для сборки ?

Пока даже рано, ни одного рабочего облетанного экземпляра еще нет, да и софт еще не дописан.

А можно ли подключить 3 вольтовый GPS модуль к автопилоту, насколько сложная будет доработка?

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