А не сделать ли нам OSD?
В соседних ветках очень любят обсуждать названия еще не существующих поделок. Я не стану отступать от моды, гы, назову свою поделку CoCOSD, кокос - потому что под управлением ртос CoOs, а код песал в среде CooCox.
Может DrOSD? 😃 Drinker OSD.
Может DrOSD? Drinker OSD.
ДроСд. Жжошь! И по-олбански получилось. Как Дринкер и любит.
На заставке дросд будет нарисован. В ответ арлу пиндосовскому в иглтри.
На заставке дросд будет нарисован. В ответ арлу пиндосовскому в иглтри.
Вот так и рождаются брэнды 😃
ДроСд
Зачетное название.
Не совсем в этом идея. Идея в том, чтобы сделать девайс, управляемый командами по и2ц, выводящий инфу поверх (или без оного) видео на ТВ. Ну как всякие жк дисплеи с управлением по и2с для ардуин. Это чистый ОСД. Пользователю не нужно будет морочиться по части видеооверлея. Его задача рассчитывать что куда выводить. С этим и автопелот на ардуинке справится.
А буквы - цифры вообще ниче не надо рассчитывать, ткнул координаты и что вывести и привет.
ОСД ничего не считает - она только организует оверлей. Считать должен основной контроллер.
Забываю, что есть ардупилот. Ну, если его немножко пригрузить расстановкой графики по экрану, то взлетит вполне, здравая мысль. Не экономьте на АЦП входах, сделайте побольше, 3-5, и способ отдавать данные на АП, лишним никогда не будет.
Уже прикинули бюджет букв-линий в кадре, в секунде? Через и2ц пролезет?
Ну и это вот. Не поленитесь пару максов4090 поставить на вход-выход, некошерно постоянкой тянуть видеосигнал вверх-вниз по проводам, лучше его тянуть в пределах платы.
Но это удорожание небольшое, смотрите сами.
Тим спасибо за советы. Но я если честно не очень радиолюбитель. По-этому собрал максимально просто, лишь бы работало. С кодом я еще могу покреативеть. Я попрошу помощи у того кто сможет грамотно железяку сделать. Попозже.
Руки чешуццо крутилку пристроить. На разрешение экрана например. Иначе это полу-дринкерстайл.
А в России, мало того, что берут за основу то, что уже сделано бесплатно другими, так все равно сразу пытаются втюхивать за бабки. Это или из за бедности, или из-за жадности. А видимо, из-за того и другого. Причем это именно русский менталитет. Даже живущие за границей русские и нормально зарабатывающие, все равно этому подвержены. Просто тошнит от этого. Долбанное крохоборство.
Как это Вы всех скопом под одну гребенку. Из тех автопилотостроителей, что знаю, насчет одного есть подозрения, но он, вроде бы, еще далек от “за бабки”. Я и сам взял готовое решение для ориентации - у меня для ориентации используется конкретно перепиленный под себя МАРГ. Но я и не скрывал этого никогда.
Код Ардупилота, увидев однажды года два-три назад и ужаснувшись, обхожу стороной за три версты. Очень нравится подход GentleNav, но там странные полуакадемики, которых ломает купить нормальный проц и не ломает писать какие-то целочисленные извраты. Тоже стало отвратно. Я с этим на Меге наелся, в жестком ассемблере, хватит.
Цель этого проекта была собрать общие усилия и уже готовые решения, которые тут у многих присутствуют и сделать для сообщества моделистов хорошую, дешевую ОСД.
Я по аналоговой части видео точно советую брать максы, уж поверьте опыту и налету всех моих ОСД, начиная с Мини - работают просто железобетонно.
По выводу графики советовать, уж извините, не буду.
Не стоит брать мою ОСД за основу, придется заморачиваться конкретно.
“Симпатичненько” оно выглядит на Зеленом потому, что я, заиспользовав 12-летний опыт работы с комп графикой сам с нуля очень быстро написал векторную графику, 1 слой абстракции, битовые и векторные шрифты -мои буковки могут поворачиваться и масштабироваться на экране! - и выглядят эти повороты и масштабирования не отвратно, а прекрасно, потому что алгоритм рисования линий я писал тоже сам - не Брезенхем банальный, что у всех, а нормальный полноценный алгоритм с субпикселами - с нецелыми координатами пикселов.
Разрешение ОСД у меня 720х576, т.е. полный PAL кадр. С тенями и двойной буферизацией. Я реально очень жестко заморочился для того, чтобы получить квадратные пикселы, отсутствие дрожания фаз, эти долбаные приоритеты долбаных прерываний, и т.д. После всего, что между нами было, уже должен жениться на осциллографе. Схема тактования шин и SPI у меня - отдельная песня. Процы на Зеленом бомбят друг друга данными по UART со скоростью 16 Мбит, меньше меня не устраивает, есть миллисекундные задержки, которых пользователь и не увидит, потому что привык ко всяким минимосдшкам, а вот меня - не устраивает, я максималист. Звуковая библиотека - я запилил, мать его, сжатие звука и пакетный обработчик звуковых библиотек, потому что PCM 8 бит 8 кГц по качеству меня не устраивает, мне надо 22 кГц как минимум… Но это вам не актуально, вы звук не делаете.
Ну, уж не говорю о том, что у меня свой собственный шрифт с оптимально подобранными под особенности передачи в аналоге форматов PAL/NTSC наклонами глифов и начертанием букв (избегайте углов наклона глифов 70/110 градусов к горизонту, избегайте мелких угловых элементов в буквах, избегайте однопиксельных линий, избегайте мелкие “шахматоподобные” паттерны и т.д., иначе на земле на ТВ/в очках будет не то, что Вы думали увидеть, нарисовав это на компе), и что, разумеется, написан свой редактор шрифтов, иконок и любых символов.
Ну, о размещении элементов на экране - ни разу не слышал о том, чтобы просили на Зеленом что-то передвинуть туда-то. Размещайте информацию на экране соответственно важности, читайте статьи дизайнеров пользовательских интерфейсов, поговорите с пилотами реальной авиации, поставьте и поиграйтесь в авиасимуляторы/космосимуляторы, поглядите на их интерфейс, скачайте 2-3 пака пиксельных иконок для ПК, посмотрите, как надо делать и как не надо и т.д.
Отсюда, в общем, вся плавность и “красивенько” и прочее. И отсюда, извините, моя скрытность: это моё, собственное, почему я должен с кем-то делиться, если я просто жадный гад и не хочу?
Тем не менее, я всегда помогу с тем, чтобы показать, откуда начать плясать. Мне так с принципом вывода OSD на STM в свое время очень, очень помог Syberian, за что лишний раз, пользуясь случаем - огромное человеческое спасибо. Разобравшись, помучавшись, я сделал осдшку, которая превзошла предшественника и по качеству графики убила всё остальное, что было до нее.
Всё свое не расскажу, но не сделать то, что мне кажется ошибкой - помогу.
С кодом я еще могу покреативеть.
Очень удобно хранить битовые шрифты по 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, но делает это, подсчитывая число кадров в секунду, т.е. ему надо до секунды, чтобы понять, что его обманули.
Я попрошу помощи у того кто сможет грамотно железяку сделать. Попозже.
Схему старой ОСД я выдам, там по видеочасти всё понятно. В Зеленом точно то же, только подмешивание другое - у меня есть программная регулировка яркости и силы затенения, вам это не надо и опять же пара лишних микросхем, удорожает.
Не экономьте на стабилизаторах питания. В том плане, что пусть они будут и дешевые и линейные, но отдельные на видеочасть, на аналоговые датчики, если таковые будут, и на проц. Я на пробных платах Зеленого обжегся, пришлось переделывать.
Ну а питать видеочасть от 3.3В, даже если и работает и “а ну и пусть” - это вообще странно, когда по спекам ЛМ и МАКСов им 3.3В просто не подходит. Логические уровни ЛМа и проца нормально сочетаются без всяких плясок, когда ЛМ на 5В, а проц на 3.3В. Ну, на всякий случай, посмотрите по спеке проца, иммунны ли ноги, на которые заводите синхроимпульсы от ЛМ, к 5В.
Наконец, обязательно выведите на отдельные пины SWD интерфейс проца. Обновлять прошивку через UART или USB - это по пацански, по хардкору, но возможность обновляться и полноценно дебажить через SWD - это просто рай на земле.
- с нецелыми координатами пикселов. Разрешение ОСД у меня 720х576, т.е. полный PAL кадр.
можно уточнить?
т.е. в векторах вы считаете, переводите в матрицу удвоенном разрешении по горизонтали и вертикали а зетем 4 пикселя сворачиваете по сумме яркости в один пиксель разрешения 720х576?
или как понимать “нормальный полноценный алгоритм с субпикселами - с нецелыми координатами пикселов”
т.е. в векторах вы считаете, переводите в матрицу удвоенном разрешении по горизонтали и вертикали а зетем 4 пикселя сворачиваете по сумме яркости в один пиксель разрешения 720х576?
Координаты пикселов - числа с фиксированной точкой, 16 бит целых и 16 бит дробных, меньше не хватает точности.
Сворачивания яркости нет, ОСД не умеет(*) выводить кучу оттенков серого сразу.
(*) аппаратно умеет, но оказалось, что можно с этим вообще не париться, а чуток подтюнив шрифты и аккуратно делая векторную графику, с моим разрешением ОСД можно вполне рассчитывать на цепи шумоподавления в современных ТВ и программные шумодавы в плейерах ПК, которые прекрасно выглаживают ступенечки из точечек в красивые буковки и линии.
Координаты пикселов - числа с фиксированной точкой, 16 бит целых и 16 бит дробных
то что можно посчитать картинку с точностью до 16 знака это понятно, непонятно как обратно экстраполировать красивую векторную картинку в однобитную матрицу (поскольку речь идет о чб, без оттенков серого)
я предположил что в зависимости от удаления векторной точки от нужного пикселя к пикселю считается его “гардация серого” - грубо говоря если косая линия перекрывает пиксель на половину то в 256 градациях его цвет 127, если к примеру только задевает уголок, то гденить около 200 (где 0 это черный а 255 это белый) само собой делать 8 битный сдвиговый регистр и ставить цап это через чур, разве что какие хитрости с увеличением реального разрешения в котором работает микропроцессор в несколько раз с тем чтобы пиксель прорисовывался на долю реальной паловской точки, что в последствии корректируется аналоговой rc цепочкой в аналоговый уровень - те.е по принципу цифровых усилителей (аналоговый_сигнал - шим - lc фильтр - обратная связь) (ну или без обратной связи в конкретном решении ибо быстродействующий и точный ацп далеко не в каждом проце есть)
обязательно сделайте двойную буферизацию
Это я сразу сделал. В теневом можно по времени рисовать хоть до упаду. А потом хлоп и переключил. Это да.
Забудьте про рисование окружностей.
При 512х384 на обычном (не широком) телеке отличные круги. А на широком ессно овал.
когда ЛМ на 5В
А я лмку вообще от 5в бековских запитал. От них-же фез40 (там свой стаб на 3.3 есть).
В результате графическая осд за 25 бакинских.
Кстати, люди. Тут давно тема проскакивала. Человек вот такую схему предложил.
Я к чему. Видеотрахт заявлен как с аппаратными тенями. Если это так, то я с удовольствием отказался от ручного рисования теней.
Кто че думает?
smalltim что скажете про эту схему?
Я к чему. Видеотрахт заявлен как с аппаратными тенями. Если это так, то я с удовольствием отказался от ручного рисования теней.
Кто че думает?
тени тут будут только по горизонтали, вертикальным то тут откуда взяться?
Кстати, люди. Тут давно тема проскакивала. Человек вот такую схему предложил.
osd.jpg
Я к чему. Видеотрахт заявлен как с аппаратными тенями. Если это так, то я с удовольствием отказался от ручного рисования теней.
Кто че думает?
Тени будут только по горизонтали.
smalltim что скажете про эту схему?
Нечем Игловские файлы смотреть, но если это Алексснега схема, то нормал.
Ну, если его немножко пригрузить расстановкой графики по экрану, то взлетит вполне, здравая мысль.
А патч на APM текущей версии куда шить? Или кто-то здесь готов свою ветку APM поддерживать? Кстати устройства такие уже есть, все их знают, и производитель подтверждает, что при изменении кода APM (причем не закорючки какой, а всего протокола MAVLINK, то есть отказа от модемов, следилок и прочего на этом протоколе работающих) возможна интеграция с APM.
ДрОСД. Гы.
Dr.OsD
типа доктор (в смысле гуру осд)
может распятие дрозда, как двуглавый орел на старом Российском гербе?
Вот же тролли. Хотя, да, двуглавый дрозд, в одной лапе передатчик, а в другой моделька - правильная тема 😁
Вот же тролли
так ониж первые начали, сначала ardupilot.com написал на всех своих сайтах крупным красным шрифтом об участии в имбарго во все страны кроме канады,
потом пошли слухи о том что микрософт с ораклом решили оставиь без нас техподдержки.
как жеж в такой ситуации казаки не напишут ответ турецкому султану 😃)
Ой, ну только политики тут не надо.
Кто возьмется делать платы и продавать как продукт - прикладывайте в комплекте шапочки из фольги 😃
При 512х384 на обычном (не широком) телеке отличные круги. А на широком ессно овал.
512х384 - это размер буфера кадра, как я понимаю. Вы же не используете нецелое количество пикселов по вертикали на одну ТВ строку: делаете или пиксел на 1 строку, или на 2.
Реально будет или 512х288 для видимой части кадра, если не квадратные пикселы, или 360х288, если квадратные. А если так, то зачем большой буфер кадра? Память не бывает лишней.