OSD на ATmega1281
во время полёта скорость вдруг стала меньше минимальной, т.е. падение, тогда координаты увеличиться автоматически. А вот время полёта, мелкие цифры.
Тут ведь ситуации разные бывают. Был у нас такой случай. На определенной дальности отвалилось управление и автопилот, как ему и было сказано, развернул самолет домой и начал занимать целевую высоту 100 метров. Но из-за особенностей нашего рельефа (сопки) когда самолет самолет снизился до 125 метров потерялась прямая видимость. Как следствие управление так и не вернулось, а видео пропало. В итоге самолет так и не вернулся на базу. На пути возврата оказалась сопка выше 100 метров. Это я про то, что все равно всех ситуаций при планировании маршрута полета не предусмотреть. Самолет был найден благодаря известным координатам, скорости и изменению высоты. Ошиблись с предполагаемым местом падения всего на примерно 40 метров.
Считаю, что постоянно крупные цифры были бы очень кстати.
У меня была та же ситуация, на пути возврата оказалась гора. Самолёт нашли. Пришлось поездить на внедорожнике вдоль реки, с ноутбуком и повороткой с видео антенной, сигнал поймали, и еле еле удалось различить цифры координат.
Я думаю, не проблема, в КП сделать выбор крупные координаты всегда или увеличивать автоматически. Кто как хочет.
И еще один вопрос, только не пинайте сильно.
Нет ли в планах разделить экран на зоны? Центральная с “радаром”, линией горизонта ну и т.д. Верхняя часть, нижняя часть. Ну и индикацию скорости и высоты раздвинуть в стороны. Если это невозможно, хотелось бы понять почему.
Спасибо.
Ты радуйся что тебе бесплатно дали прошивки и схему, и платы. Довольствуйся тем что есть! То что есть вполне, больше и не нужно.
Остальное это хотелки, нужные только Вам.
Меня вполне все устраивает. Мало того, меня всегда поражали люди, способные сотворить ТАКОЕ практически в одиночку от начала и до конца.
Дело в том, что автор темы говорил, что готов выслушивать предложения.
Никого не хотел обидеть.
P.S. Вы уж меня извените, но я обращался к разработчику.
P.S. Я обращался к разработчику.
Я его зам.
Мы сегодня летали.
Он сейчас отдыхает, после полётов.
А я не летал, я крылья забыл от Ская… Вот так…
я крылья забыл от Ская… Вот так…
Бывает.
Немного офф топа. Тоже с товарищем на рыбалку морскую собрались. Упаковали все в машину, доехали, накачали лодку повесили мотор. Хлопнули за рыбалку по три. И тут выяснилось, что забыли удочки и документы на судно.
Ну и индикацию скорости и высоты раздвинуть в стороны. Если это невозможно, хотелось бы понять почему.
Не даст разрешение пиксельного экрана. Виртуально экран, на котором можно выводить графику, меньше полного размера экрана. Шкалы высоты и скорости, как раз на границах этого экрана. Что бы сделать разрешение больше, нужно много чего переделать. Фактически это новая разработка.
Понятно, спасибо.
Сергей, скажите, а почему сигнал канала руля направления не проходит через автопилот?.. С функцией удержания курса АП справлялся бы еще лучше. Да и стабилизация по курсу не лишняя.
Управление и стабилизация по курсу мне показалось проще, безопаснее и универсальнее сделать через крен, который легко и однозначно реализуется через подсистему стабилизации ориентации. Если есть желание использовать РН, можно зацепить его серву в параллель элеронным сервам и механически подобрать соотношения расходов элеронов/РН.
И вопрос по размеру цифр текущих координат. … Может есть смысл увеличить шрифт?
Да, согласен. Единственно, что в течении полета эти цифры обычно вообще не нужны и только будут загромождать экран.
Надо только подумать (с вашей помощью) по каким критериям автоматом менять шрифты этих полей. С ходу могу предложить по нулевой скорости GPS в момент остановки полетного таймера. Этого будет достаточно?
Нет ли в планах разделить экран на зоны? Центральная с “радаром”, линией горизонта ну и т.д. Верхняя часть, нижняя часть. Ну и индикацию скорости и высоты раздвинуть в стороны.
К сожалению это очень непросто сделать. Пока генерируется OSD проц ничем другим заниматься не может (всего три такта на пиксель). Но В конце строки ему все равно нужно успеть: выполнять обмен с IMU, читать данные LRS по UART,читать данные с LRS по UART или принимать SUM_PPM. И делать хотя бы минимальную предварительную обработку полученного (хотя бы записать в буфер и сделать инкремент счетчика байт). Если раздвигать телеметрию по горизонтали, можно чего-то не успеть. Примерно тоже самое по вертикали… Обработка всех данных, основные расчеты автопилота и самое машиноемкое - отрисовка видеобуфера делается после последней выведенной строки и надо уложиться до первой. Может и возможно какие-то функции вынести на обработку между некими горизонтальными зонами, но все это потребует долгой кропотливой отладки, и потом будет очень непросто делать какие-то изменения.
Есть вопрос по OSD/АП.
Немогу запустить SUM_PPM.
Приёмник FrSky D8R-II plus перепрошитый на FrSky D8R-ХР(3 и 4 канал замкнул).
Прошивка OSD/АП та что в 712 посту с подержкой IMU.
Летаю с этим АП и ОСД на таком же приемнике. Если правильно расположить стоковые антены то 3км летаю без бибиков. При разворотах попискивает телеметрия о слабеньком сигнале. До ФС удалением не доводил - только передатчик выключал в полете принудительно - самолет благополучно вернулся на базу. Прошивал по инструкции прошивка по первой ссылке (не от D8R-ХР). Никаких проблем!
Что показывает осцилл на ноге приемника с предполагаемым CPPM? Сколько каналов ППМ вы настроили в ОСД? Должно совпадать то что настроили и то что генерит ваш передатчик. Куда подключаете сигнал CPPM? Формирователь на транзисторе собирали?
CPPM с приёмника уходит.
Формирователь на транзисторе собраный , на входе
На ноге меги
К сожалению осцилографа неимею и делал эти осцилограммы через микрофонный вход зк.
Количество каналов выставил.
Вопрос снят.
Dollop большое спасибо , перешился на простую прошивку и оно заработало.
Хоть все решилось, на всякий случай:
Cистема ожидает пакет PPM с параметрами:
- Количество каналов должно соответствовать конфигурации;
- Длина синхро-импульса должна быть меньше 17ms и больше 2.5ms;
- Длины всех стробов должны быть меньше 0.6ms и больше 0.2ms;
- Длины канальных импульсов+ длина строба должны быть меньше 2.2ms и больше 0.8ms.
После этого должна хотя-бы крутиться палка RC на OSD…
Информация о состоянии IMU была интересна и полезна на период отладки. Теперь хотелось бы сделать что-то попроще, попонятнее… Например уровень вибрации. Но что-то не соображу как это реализовать… Если просто поставить ФВЧ с частотой среза скажем 5Гц на длину вектора акселя, то будут честно измерены вибрации от 5 до 25Гц (частота опроса акселя всего 50Гц). Реальные вибрации от двигателя до ~170Гц. Поднимать частоту опроса акселей до 400Гц только для оценки вибрации не слишком хочется (если вообще пройду по быстродействию). Может есть какие идеи?
Если хочется странного - то может, полезнее будет фурье? - по нему можно определять частоту раскачки ероплана и пытаться автоматически ПИД настраивать? Частоты пониже - герцы и доли герца, и вроде как полезнее - система теоретически становится самонастраивающейся. А двигатель чтобы не вибрировал - пропеллер надо балансировать 😃
Если хочется странного…
Задача скромная - выдать на OSD полезную и наглядную информацию о состоянии IMU. Может из OSD вообще все по IMU выкинуть, только загружает пилота? В принципе о качестве работы IMU можно и просто по линии горизонта судить?
…и пытаться автоматически ПИД настраивать?
Если и успею на меге БПФ посчитать, и даже из спектра убрать шумы, то дальше построить ПХ модели имхо непросто… Пытался почитать про самонастраивающиеся регуляторы, там либо трехэтажная математика с потерей для меня всякого физического смысла и предупреждениями о куче ограничений, или общие идеи типа: 1. снять ПХ-объекта, 2. построить регулятор с обратной функцией (напоминает детскую загадку о бегемоте и холодильнике).
А двигатель чтобы не вибрировал - пропеллер надо балансировать
Всю прошлую неделю по вечерам пробовал на своем вжике радикально убрать вибрацию для получение четкой картинки с курсовой камеры.
- Пробовал разные винты (конечно проверял или делал статическую балансировку). Одна простая зависимость: больше шаг - больше вибрация.
- Пробовал разные мягкие подвесы ВМГ. Однозначный результат один: сама ВМГ начинает вибрировать гораздо сильнее. Корпус вибрирует немного меньше только в определенном диапазоне оборотов.
- Пробовал делать отдельную платформу на мягком подвесе ( втулки от CD-ROM) на которую крепил только акк и камеру… Радикально проблему тоже не решило.
Вообщем пока плюнул на это дело…
Одна простая зависимость: больше шаг - больше вибрация
Вот от винта она и идёт.
Я читал на форуме где то, что эту проблему решает 3-х лопастный винт.
Заинтересовался тоже этим проектом, здорово получается! Попробую собрать.
Для контроля вибраций в полетном прямолинейном полете думаю хватит сканирования акселей с частотой среза 10-15Гц (меняя произвольно частоту сканирования). Если будут какие то нелогичные всплески - сигнализировать на экран. На мой взгляд было бы полезно сделать отдельную подпрограмму автоматической пошаговой настройки (калибровки) всех основных параметров. Скажем лимиты серв по контролю тока (добавить в схему), обороты-вибрации путем замера вибраций на нескольких частотах вращения ОР, заложить сразу описание основных стандартных моделей планеров, лимиты каналов как всегда двигая стиками и т.п. В результате положительного обсчета получать конфиг для прошивки.
Скажем лимиты серв по контролю тока (добавить в схему), обороты-вибрации путем замера вибраций на нескольких частотах вращения ОР, заложить сразу описание основных стандартных моделей планеров, лимиты каналов как всегда двигая стиками и т.п.
Сергей этого делать не хочет. Я ему об этом говорил.
Я бы ещё хотел полёт по точкам…
Вообще проект, для самодельщиков. Кто его сделает самостоятельно, то ему не нужны те функции, которые описаны выше.
Делайте, не пожалеете.