А не сделать ли нам OSD?

Shuricus
Oliver:

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

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

X3_Shim:

Ну к примеру ?

Из любого из здесь засветившихся. Я могу насчитать как минимум три. Есть еще автопилот Олега, есть Сергея, это как минимум.

Drinker:

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

Андрей, ну вот в результате только вы один и делаете. С таким же успехом, вы могли это выложить в дневнике. Зачем тогда ветку создавали, и уже 11 страниц исписали? А результата ноль. Я не вижу, что бы было принято решение по финальной схемотехнике, которое бы все одобрили. Даже обсуждения на эту тему не вижу. Вижу только какие-то голоса начинают бороться за правду в интернете.

Scott_Tiger
alexeykozin:

есть семейство “осд для бедных” оно полностью заполнено предложениями первым была поделка ремзиби “poor man osd” работала она удивительно глючно и вероятно толком работала только у самого ремзиби использовала она атмегу и видеопроцесор max7456 потом было создано миним осд на том же видеопроцессоре, практически без глюков, удивительно что и конфиг тул удивительно похожа на утилиты ремзиби. в принципе с прошивкой экстра - осд вполне летабельное,

Вы, как мне кажется, смешиваете в одну кучу проблемы ПО (прошивки) и оборудования. Варианты “для бедных”, типа того же MinimOSD, имеют вполне стабильный (и, кстати, полностью открытый) код, но используют технически слабую элементную базу, как в части видеотракта, так и в вычислительной части, плюс энное количество вычислительного времени тратится на разбор несколько тяжеловатых протоколов типа Mavlink. В результате качество картинки не самое лучшее, объём отображаемой информации может быть маловат, а оборудование работает не очень надёжно. Варианты “для богатых”, как правило, используют более производительные аппаратные компоненты, столь же адекватное ПО, но всеми силами тянут пользователя на свою “платформу”, а исходный код или закрыт или очень сложен и насыщен не всегда нужными фичами. На мой взгляд, создание еще одного OSD “для богатых” оправдано только в том случае, если к нему будет еще и полётный контроллер “для богатых”, и модемы “для богатых”, ну и, обязательно, расписанные под хохлому гироскопы 😃

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

Drinker
Shuricus:

Андрей, ну вот в результате только вы один и делаете.

Эта ветка меня натолкнула к созданию осд для пиксхавка.

Shuricus:

Зачем тогда ветку создавали, и уже 11 страниц исписали?

Я не создавал, я примкнул к теме.

Shuricus:

Я не вижу, что бы было принято решение по финальной схемотехнике, которое бы все одобрили. Даже обсуждения на эту тему не вижу.

А у меня схемотехники как таковой нету. Моё предложение было лмку к фезу40 присобачить да пару деталек еще.

Scott_Tiger:

иметь что-то более ориентированное на энтузиастов, в т.ч. владеющих паяльником на начальном уровне и базовым C, нет разве?

Выше я описал - куда проще для начинающего паяльщега?

Shuricus

Андрей(Scott Tiger), вот спасибо за конструктивный текст!
Я бы еще уточнил, что у нас происходит деление на для бедных и для богатых потому, что на форуме перемешаны в кучу совершенно разные интересы людей использующих одно и тоже оборудование для коммерческих и хоббийных целей. Если бы этого не было, было бы все проще. Для хобби не оправданы дорогие железки, просто потому что. Можно прекрасно летать по текущему Миним ОСД и получать море удовольствия. Ведь так?

Смысл был сделать ОСД с более широким функционалом и с возможно лучшей графикой, но не в ущерб стоимости. И не для того, что бы на нем обогатится.
Ну точнее - это было мое предложение.

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

Drinker:

Я не создавал, я примкнул к теме.

Андрей, я это обращаюсь ко всем участникам. Потому сейчас выглядит так - все поговорили, и разошлись по домам. 😃

Scott_Tiger
Shuricus:

Для хобби не оправданы дорогие железки, просто потому что. Можно прекрасно летать по текущему Миним ОСД и получать море удовольствия. Ведь так?

Можно, но, как справедливо многократно замечено, хочется, чтобы графика была получше, а надёжность платы - повыше при более-менее сопоставимом ценовом диапазоне. В остальном лично меня МинимОСД устраивает полностью, все данные для собственно отображения я передаю извне (немного модифицированный MultiWii). Причём я лично предпочел бы не последовательный порт, а I2C, но переделать плату MinimOSD квалификации у меня решительно не достаточно.

schs
Drinker:

Мавлинк и и2ц сделаю. Через 3 недели - после ОТПУСКА!

Здорово! Будет рабочая вещь, при открытом коде можно и под себя допиливать.

alexeykozin

в самом деле мои слова переиначили.
я говорю о том что если сам не пишешь прошивок и особо труда не вкладываешь
но просишь когото постороннего написать , пусть для блага общего
это примерно тоже самое что попросить “эй чувак донеси мне чемодан” или “вскопай мне огород”
я бы понял если бы тему начал ктото из программистов с предложением “мужики а давайте я вам все сделаю”.
зы прошу понять и не обижаться

а дринкер конечно супер.

Wasja

Я думаю, что автор сам должен определять что закрывать а что продавать. Часто код открывают поскольку самому не осилить. Большинство западных проектов продавали железки, тем и живут до сих пор. Если нужен OSD лучше чем minim надо доплачивать, хотя за компоненты более дорогие. И мне бы лично хотелось доплачивать автору, если такая возможность есть. В любом случае это все проект, что-то сильно сомневаюсь что сейчас китайцы это начнут клонировать завтра.

Oliver
Shuricus:

у тех кто не путает понятия готового решения, готового изделия и просто проекта

Мне казалось я сделаю доброе дело хотя бы дав вам повод еще раз вернуться к своим утверждениям, и, возможно, обдумав, их изменить. НЕ имел целью что-то доказывать и переубеждать. Как правило, это бесполезно. Вдвойне обидно, что мои слова были восприняты в таком ключе.
Кстати, в к-ве очень интересного симбиоза могу привести пример ОТКРЫТОГО ПРОЕКТА, в результате развития которого появились как бесплатные ГОТОВЫЕ РЕШЕНИЯ так и платные ИЗДЕЛИЯ, причем было бы интересно понаблюдать над попытками назвать этот проект российским/зарубежным, т.к. по факту он международный. 😃 Это проект голосового модуля для Турниги9х - MegaSound.
По поводу якобы навязчивого желания нашими коллегами везде срубить бабла - тоже натянутое утверждение. Есть такие и тут и там. И авторов, предпочитающих безвозмездно распространять свои достижения - предостаточно. Так же, как и авторов, бесплатно распространяющих свои РЕШЕНИЯ, но продающих ГОТОВЫЙ ПРОДУКТ.
В данной ветке предложения получить/заплатить денег появились только тогда, когда появилось обсуждение появления в ходе проекта ГОТОВОГО ИЗДЕЛИЯ. Не решения (схем, рисунков плат, кода), а изделия - запаяной, прошитой платки. Да, такое тоже востребовано. И… почему бы нет? Зачем так категорично осуждать тех, кто готов заплатить за чужой труд и тех, кто имеет возможность этот труд предлагать?

Drinker

В соседних ветках очень любят обсуждать названия еще не существующих поделок. Я не стану отступать от моды, гы, назову свою поделку CoCOSD, кокос - потому что под управлением ртос CoOs, а код песал в среде CooCox.

Drinker
Alexey_1811:

Может DrOSD? Drinker OSD.

ДроСд. Жжошь! И по-олбански получилось. Как Дринкер и любит.

На заставке дросд будет нарисован. В ответ арлу пиндосовскому в иглтри.

Scott_Tiger
Drinker:

На заставке дросд будет нарисован. В ответ арлу пиндосовскому в иглтри.

Вот так и рождаются брэнды 😃

smalltim
Drinker:

Не совсем в этом идея. Идея в том, чтобы сделать девайс, управляемый командами по и2ц, выводящий инфу поверх (или без оного) видео на ТВ. Ну как всякие жк дисплеи с управлением по и2с для ардуин. Это чистый ОСД. Пользователю не нужно будет морочиться по части видеооверлея. Его задача рассчитывать что куда выводить. С этим и автопелот на ардуинке справится.

А буквы - цифры вообще ниче не надо рассчитывать, ткнул координаты и что вывести и привет.

ОСД ничего не считает - она только организует оверлей. Считать должен основной контроллер.

Забываю, что есть ардупилот. Ну, если его немножко пригрузить расстановкой графики по экрану, то взлетит вполне, здравая мысль. Не экономьте на АЦП входах, сделайте побольше, 3-5, и способ отдавать данные на АП, лишним никогда не будет.

Уже прикинули бюджет букв-линий в кадре, в секунде? Через и2ц пролезет?

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

Drinker

Тим спасибо за советы. Но я если честно не очень радиолюбитель. По-этому собрал максимально просто, лишь бы работало. С кодом я еще могу покреативеть. Я попрошу помощи у того кто сможет грамотно железяку сделать. Попозже.

Руки чешуццо крутилку пристроить. На разрешение экрана например. Иначе это полу-дринкерстайл.

smalltim
Shuricus:

А в России, мало того, что берут за основу то, что уже сделано бесплатно другими, так все равно сразу пытаются втюхивать за бабки. Это или из за бедности, или из-за жадности. А видимо, из-за того и другого. Причем это именно русский менталитет. Даже живущие за границей русские и нормально зарабатывающие, все равно этому подвержены. Просто тошнит от этого. Долбанное крохоборство.

Как это Вы всех скопом под одну гребенку. Из тех автопилотостроителей, что знаю, насчет одного есть подозрения, но он, вроде бы, еще далек от “за бабки”. Я и сам взял готовое решение для ориентации - у меня для ориентации используется конкретно перепиленный под себя МАРГ. Но я и не скрывал этого никогда.
Код Ардупилота, увидев однажды года два-три назад и ужаснувшись, обхожу стороной за три версты. Очень нравится подход GentleNav, но там странные полуакадемики, которых ломает купить нормальный проц и не ломает писать какие-то целочисленные извраты. Тоже стало отвратно. Я с этим на Меге наелся, в жестком ассемблере, хватит.

Shuricus:

Цель этого проекта была собрать общие усилия и уже готовые решения, которые тут у многих присутствуют и сделать для сообщества моделистов хорошую, дешевую ОСД.

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

“Симпатичненько” оно выглядит на Зеленом потому, что я, заиспользовав 12-летний опыт работы с комп графикой сам с нуля очень быстро написал векторную графику, 1 слой абстракции, битовые и векторные шрифты -мои буковки могут поворачиваться и масштабироваться на экране! - и выглядят эти повороты и масштабирования не отвратно, а прекрасно, потому что алгоритм рисования линий я писал тоже сам - не Брезенхем банальный, что у всех, а нормальный полноценный алгоритм с субпикселами - с нецелыми координатами пикселов.
Разрешение ОСД у меня 720х576, т.е. полный PAL кадр. С тенями и двойной буферизацией. Я реально очень жестко заморочился для того, чтобы получить квадратные пикселы, отсутствие дрожания фаз, эти долбаные приоритеты долбаных прерываний, и т.д. После всего, что между нами было, уже должен жениться на осциллографе. Схема тактования шин и SPI у меня - отдельная песня. Процы на Зеленом бомбят друг друга данными по UART со скоростью 16 Мбит, меньше меня не устраивает, есть миллисекундные задержки, которых пользователь и не увидит, потому что привык ко всяким минимосдшкам, а вот меня - не устраивает, я максималист. Звуковая библиотека - я запилил, мать его, сжатие звука и пакетный обработчик звуковых библиотек, потому что PCM 8 бит 8 кГц по качеству меня не устраивает, мне надо 22 кГц как минимум… Но это вам не актуально, вы звук не делаете.
Ну, уж не говорю о том, что у меня свой собственный шрифт с оптимально подобранными под особенности передачи в аналоге форматов PAL/NTSC наклонами глифов и начертанием букв (избегайте углов наклона глифов 70/110 градусов к горизонту, избегайте мелких угловых элементов в буквах, избегайте однопиксельных линий, избегайте мелкие “шахматоподобные” паттерны и т.д., иначе на земле на ТВ/в очках будет не то, что Вы думали увидеть, нарисовав это на компе), и что, разумеется, написан свой редактор шрифтов, иконок и любых символов.
Ну, о размещении элементов на экране - ни разу не слышал о том, чтобы просили на Зеленом что-то передвинуть туда-то. Размещайте информацию на экране соответственно важности, читайте статьи дизайнеров пользовательских интерфейсов, поговорите с пилотами реальной авиации, поставьте и поиграйтесь в авиасимуляторы/космосимуляторы, поглядите на их интерфейс, скачайте 2-3 пака пиксельных иконок для ПК, посмотрите, как надо делать и как не надо и т.д.

Отсюда, в общем, вся плавность и “красивенько” и прочее. И отсюда, извините, моя скрытность: это моё, собственное, почему я должен с кем-то делиться, если я просто жадный гад и не хочу?

Тем не менее, я всегда помогу с тем, чтобы показать, откуда начать плясать. Мне так с принципом вывода OSD на STM в свое время очень, очень помог Syberian, за что лишний раз, пользуясь случаем - огромное человеческое спасибо. Разобравшись, помучавшись, я сделал осдшку, которая превзошла предшественника и по качеству графики убила всё остальное, что было до нее.
Всё свое не расскажу, но не сделать то, что мне кажется ошибкой - помогу.

Drinker:

С кодом я еще могу покреативеть.

Очень удобно хранить битовые шрифты по 1 или по 2 или даже по 4 (если маленькие или не хотите высокое разрешение) в 32-битном слове. Растровые мои шрифты имеют переменную шириной букв, но до размера 16*20, т.е. Х*20. Горизонтальный срез 2 таких букв хорошо ложится в слово, они быстро читается и небольшой кучкой команд битовых сдвигов шустро ложатся на экран.

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

Забудьте про рисование окружностей. Шансов, что на экране будет не окружность, а овал - 90%, потому что у всех разные очки, телевизоры, у половины широкоформатники, у второй - 4:3, и т.д. Насмотревшись на эти разнообразные яйца в разных ОСД, я забил на всякие режимы “радара” и прочую ересь. Если на радаре нет правильных пропорций ширина/высота, то это не информация для пилота, а дезинформация.

Продумайте уже сейчас, что из показаний ардупилота можно интерполировать на ОСД, а что нельзя. С такой частотой обновления данных, как на ардупилоте, будет не плавность, а пляски. Интерполировать показания, приходящие с частотой 5 Гц, можно хоть до 25 Гц. Чаще не надо - не стоит обновлять информацию на экране чаще, чем раз в 2 полукадра, т.е. 25 гц, иначе деинтерлейсинг на всех современных устройствах отображения превратит картинку в помойку. А людей на кинескопных мониторах, получающих профит от 50 Гц, я в поле пока не видел, и не думаю, что увижу.
25 Гц - прекрасно для плавности и выше крыши для полного счастья.
При интерполяциях избегайте пропуска / “выпадающих” кадров из анимации и резких рывков, например, вращающейся линии/стрелочки/горизонта. На глаз это не сильно заметно, но подсознательно вызывает отторжение, когда линияв каждом кадре поворачивается на 5 градусов, потом замирает на кадр, потом прыгает на 10 градусов. Бррр, мерзость.

Не забудьте, что есть люди с NTSC системами. Их можно ловить по числу строк в кадре. Тайминг синхроимпульсов NTSC строки чуть-чуть другой, поэтому поиграйтесь с задержками перед началом вывода данных в строке, чтоб и PALовцы радовались, и NTSCшники. По длительности вывода в строке разницы между PAL и NTSC нет. Зеленый на лету перепрыгивает между NTSC и PAL, но делает это, подсчитывая число кадров в секунду, т.е. ему надо до секунды, чтобы понять, что его обманули.

Drinker:

Я попрошу помощи у того кто сможет грамотно железяку сделать. Попозже.

Схему старой ОСД я выдам, там по видеочасти всё понятно. В Зеленом точно то же, только подмешивание другое - у меня есть программная регулировка яркости и силы затенения, вам это не надо и опять же пара лишних микросхем, удорожает.

Не экономьте на стабилизаторах питания. В том плане, что пусть они будут и дешевые и линейные, но отдельные на видеочасть, на аналоговые датчики, если таковые будут, и на проц. Я на пробных платах Зеленого обжегся, пришлось переделывать.
Ну а питать видеочасть от 3.3В, даже если и работает и “а ну и пусть” - это вообще странно, когда по спекам ЛМ и МАКСов им 3.3В просто не подходит. Логические уровни ЛМа и проца нормально сочетаются без всяких плясок, когда ЛМ на 5В, а проц на 3.3В. Ну, на всякий случай, посмотрите по спеке проца, иммунны ли ноги, на которые заводите синхроимпульсы от ЛМ, к 5В.

Наконец, обязательно выведите на отдельные пины SWD интерфейс проца. Обновлять прошивку через UART или USB - это по пацански, по хардкору, но возможность обновляться и полноценно дебажить через SWD - это просто рай на земле.

alexeykozin
smalltim:
  • с нецелыми координатами пикселов. Разрешение ОСД у меня 720х576, т.е. полный PAL кадр.

можно уточнить?
т.е. в векторах вы считаете, переводите в матрицу удвоенном разрешении по горизонтали и вертикали а зетем 4 пикселя сворачиваете по сумме яркости в один пиксель разрешения 720х576?
или как понимать “нормальный полноценный алгоритм с субпикселами - с нецелыми координатами пикселов”

smalltim
alexeykozin:

т.е. в векторах вы считаете, переводите в матрицу удвоенном разрешении по горизонтали и вертикали а зетем 4 пикселя сворачиваете по сумме яркости в один пиксель разрешения 720х576?

Координаты пикселов - числа с фиксированной точкой, 16 бит целых и 16 бит дробных, меньше не хватает точности.
Сворачивания яркости нет, ОСД не умеет(*) выводить кучу оттенков серого сразу.

(*) аппаратно умеет, но оказалось, что можно с этим вообще не париться, а чуток подтюнив шрифты и аккуратно делая векторную графику, с моим разрешением ОСД можно вполне рассчитывать на цепи шумоподавления в современных ТВ и программные шумодавы в плейерах ПК, которые прекрасно выглаживают ступенечки из точечек в красивые буковки и линии.

alexeykozin
smalltim:

Координаты пикселов - числа с фиксированной точкой, 16 бит целых и 16 бит дробных

то что можно посчитать картинку с точностью до 16 знака это понятно, непонятно как обратно экстраполировать красивую векторную картинку в однобитную матрицу (поскольку речь идет о чб, без оттенков серого)
я предположил что в зависимости от удаления векторной точки от нужного пикселя к пикселю считается его “гардация серого” - грубо говоря если косая линия перекрывает пиксель на половину то в 256 градациях его цвет 127, если к примеру только задевает уголок, то гденить около 200 (где 0 это черный а 255 это белый) само собой делать 8 битный сдвиговый регистр и ставить цап это через чур, разве что какие хитрости с увеличением реального разрешения в котором работает микропроцессор в несколько раз с тем чтобы пиксель прорисовывался на долю реальной паловской точки, что в последствии корректируется аналоговой rc цепочкой в аналоговый уровень - те.е по принципу цифровых усилителей (аналоговый_сигнал - шим - lc фильтр - обратная связь) (ну или без обратной связи в конкретном решении ибо быстродействующий и точный ацп далеко не в каждом проце есть)

Drinker
smalltim:

обязательно сделайте двойную буферизацию

Это я сразу сделал. В теневом можно по времени рисовать хоть до упаду. А потом хлоп и переключил. Это да.

smalltim:

Забудьте про рисование окружностей.

При 512х384 на обычном (не широком) телеке отличные круги. А на широком ессно овал.

smalltim:

когда ЛМ на 5В

А я лмку вообще от 5в бековских запитал. От них-же фез40 (там свой стаб на 3.3 есть).

В результате графическая осд за 25 бакинских.

Кстати, люди. Тут давно тема проскакивала. Человек вот такую схему предложил.

Я к чему. Видеотрахт заявлен как с аппаратными тенями. Если это так, то я с удовольствием отказался от ручного рисования теней.
Кто че думает?

alexeykozin
Drinker:

Я к чему. Видеотрахт заявлен как с аппаратными тенями. Если это так, то я с удовольствием отказался от ручного рисования теней.
Кто че думает?

тени тут будут только по горизонтали, вертикальным то тут откуда взяться?

smalltim
Drinker:

Кстати, люди. Тут давно тема проскакивала. Человек вот такую схему предложил.
osd.jpg
Я к чему. Видеотрахт заявлен как с аппаратными тенями. Если это так, то я с удовольствием отказался от ручного рисования теней.
Кто че думает?

Тени будут только по горизонтали.

Alexey_1811:

smalltim что скажете про эту схему?

Нечем Игловские файлы смотреть, но если это Алексснега схема, то нормал.

Wasja
smalltim:

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

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