OSD на ATmega1281
а в соответвии с солнцем ?
если придумаете, чтобы развертка в телевизоре меняла направление в зависимости от солнца, будет вам “реалистичней” 😁
Вообще, это для того, чтобы на белом фоне буквы видеть, а не красота…Называется ВЧ-фильтрация, или, как Сергей выразился, дифференциатор. Делается внешним конденсатором. Развертка идет всегда слева направо, поэтому тени сменить не получится. Только убрать.
Ничего, что я ответил? 😃
Развертка идет всегда слева направо, поэтому тени сменить не получится. Только убрать.
Ничего, что я ответил? 😃
Вот смотрю ща кино по телеку, а там направление теней соответвует источнику света 😃, хотя развертка тож слева направо и сверху вниз.
Просто не вглядывался в превьюшки, не посмотрел, как тени реализованы. А чтоб читалось лучше независимо от картинки - фон может иметь смысл вобще черным делать там где надписи, или у букв черную окантовку делать. На белом фоне белые буквы с тенями конечно читаются лучше, чем без теней,но тоже нифина не комфортно.
Сергей, а не пробовал картинку реалистичнее делать? В плане чтоб “освещение” не слева направо было, а в соответвии с солнцем ? 😃
Реалистичнее это совсем убрать 😃. На реальных самолётах OSD выводится с помощью ЭЛТ зеркально и отражается от лобового стекла.
посмотрите на моей страничке проект с использованием такого датчика
Я тоже это читал. Классный проект!
Отвес? Поделитесь конечно…
Нет, не отвес. Примерно так:
Трубка из диэлектрика, две токопроводящие пробки, к одной из них приклеивается токопроводящим клеем пьезокристалл(найти можно в зажигалке, поджигающей газ высоковольтной искрой), с другой тороны к нему приклеивается грузик из металла, к которому припаивается тоненькая проволочка, которая припаивается к другой пробке. Грузик(да и сам пьезокристалл) обладает инерцией. При смещении всей конструкции вдоль оси он будет этому противодействовать, сжимая или растягивая пьезокристалл. На его концах появится напряжение пропорциональное силе сжатия/растяжения.
Это в теории… Надо бы поэкспериментировать ради интереса 😃.
Но
изделия от аналоговых девиц… 😃
всё равно лучше 😃.
всё равно лучше
Что ж сразу такой пессимизм, попробуйте, а вдруг… Это ж не микромеханика, может что-то соизмеримое получится…
Не ожидал столько благодарностей, вроде ничего нового и не придумал, спасибо…
Была своя мега-идея- сделать вывод видео через USART в режиме SPI с тактированием от внешнего генератора, который аппаратно синхронизируется по фазе с началом строки. Все смоделировал в протеусе и отлично работало. Печатка так и разведена под эту идею. В железе ничего не заработало и только через пару дней покуривая даташит на мегу “вдруг” обнаружил, что в SPI режиме мега работает только мастером… Забавно что протеус оказался “круче” железа, обычно наоброт…
к которому припаивается тоненькая проволочка
Следует заменить эту соплю на пружину сжатия и сделать резбовую заглушку. Собственная частота датчика в таком случае будет зависить от типа ПЭ, массы груза и упругости пружинки.
Нет, не отвес. Примерно так:
Трубка из диэлектрика, две токопроводящие пробки, к одной из них приклеивается токопроводящим клеем пьезокристалл
Неудачная идея, т.к. не будет выдавать постоянную составляющую
Неудачная идея, т.к. не будет выдавать постоянную составляющую
Что имеется ввиду под “постоянная составляющая”? То что напряжение в покое(относительном) будет находится в 0, а напряжение будет изменятся как в плюс, так и в минус? Так там в любом случае нужно будет ОУ ставить для корректировки диапазона выдаваемых значений, который бы АЦП МК смог бы преобразовывать… А противоположном входе(инвертирующем/не инвертирующем в зависимости от подключения основного сигнала) можно организовать постоянную составляющую.
store.diydrones.com/ProductDetails.asp?ProductCode… и еще кое что там найдете.
надеюсь поможет
я заказывал - доставляют исправно, инвойс автоматом занижают…
Интересный сайт. Но цены не радуют, увы… Действительно получается пока дешевле сразу FMA-голову купить. Правда там нет вертикальной пары(?).
Ладно, пока декодером займусь, а там видно будет…
Nintendo сделали Wii MotionPlus для игровой конзоли Wii. У него 3-осевой гироскоп. Управление I2C. Также естъ Nunchuck Controller for Wii у которого 3-осевой акселерометер. Управление тоже I2C.
Китайские клонинги www.dealextreme.com/details.dx/sku.26391 и www.dealextreme.com/details.dx/sku.14236.
Дешевле акселерометр и жироскоп вряд ли найдем, но что внутри клонингов и подходят ли для ваших целей???
Что имеется ввиду под “постоянная составляющая”? То что напряжение в покое(относительном) будет находится в 0, а напряжение будет изменятся как в плюс, так и в минус?
Я имею в виду постоянную составляющую ускорения, а не сигнала. Поставьте Ваш датчик вертикально - будет он показывать постоянное ускорение свободного падения? Нет, не будет - очень скоро напряжение на пьезокристалле станет нулевым. А нормальные акселерометры, например, www.freescale.com/webapp/sps/…/prod_summary.jsp?co… работают с постоянной составляющей. Это позволяет, к примеру, довольно точно измерять наклоны (конечно, если датчик в покое).
Добавил в свой OSD декодер группового PPM. Делаю управление. Диаграмку обработки выложу чуть позже.
Пока разбираюсь с каналом крена, сделал полноценный PID.
В проекте папарацев, как я понял, используют значения канала газа для учета изменения управляемости по крену для разных скоростей. Пока этим не стал заморачиваться, будем летать в ограниченном диапазоне скоростей.
Для D-ветки простейшее дифференцирование первого порядка ( D=Kd*(e[n]-e[n-1]) )показалось мало эффективно, сервы не будут успевать отрабатывать, добавил задержку дифф импульса - восстановление по квадратичному закону за задаваемым временем.
I-ветка примитивный метод прямоугольников с ограничением. Задается время интегрирования и диапазон ограничения. Что-то не могу сообразить что ждать от этой ветки. Если сделать время интегрирование большим, может есть шанс получить эффект автотриммирования. Если малым- компенсацию избыточной устойчивости скажем высокоплана для ненулевого крена. Кстати, для последнего может есть смысл добавить еще ветку - пропорциональную заданному значению крена (не ошибки). Собственно это все вопросы…
Отвес? 😃
В большой авиации до сравнительно недавнего времени именно по отвесу (маятнику пузырьковому) авиагоризонт корректировали. У больших самолетов он ведь тоже убегает по времени. Правда модель болтает больше чем реальный самолет, простым выключателем коррекции уже наверное не обойтись.
ИМХО по поводу "до сравнительно недавнего времени "… конечно все относительно, но в моем представлении давненько уже это было… 😃 Подобный принцип (только трех-осевой акселерометр) еще худо-бедно годится для индикации, и может даже поможет выбраться пилоту из облака, но никак уж не пойдет для системы управления. Уж очень велика вероятность получить на вираже за счет центробежного ускорения около нулевые показания крена, ну и тп…
А вопрос по датчикам углов остается открытым… Пока для отладки использую пару потов в каналах АЦП, накручивая ими “крен”,“тангаж”. Секретную информацию о том, как использовать трехосевой компас для определения углов, так и не получил. 😦 Но сообщение заставило еще раз задуматься… А что если крутить компас, например вдоль одной оси?.. Тогда конец вектора S-N будет определять окружность лежащую в нужной плоскости. Но крутить как угодно систему координат можно и математически… И опять вспоминаю аксиому- по двум точкам нельзя определить плоскость… Парадокс, млин…
ИМХО по поводу "до сравнительно недавнего времени "… конечно все относительно, но в моем представлении давненько уже это было… 😃 Подобный принцип (только трех-осевой акселерометр) еще худо-бедно годится для индикации, и может даже поможет выбраться пилоту из облака, но никак уж не пойдет для системы управления. Уж очень велика вероятность получить на вираже за счет центробежного ускорения около нулевые показания крена, ну и тп…
Гировертикали, корректируемые пузырьковым отвесом, стоят на самолетах, находящихся в эксплуатации до сих пор. Ну например на Ту-154. И вполне справляются со своими обязанностями. И не только для индикации но и в качестве датчика для автопилота. Есть конечно проблемы с применением такого принципа в моделях, но тут наверное опираться надо на изучение существующих систем а не на свои представления о них.
Не судите строго, с авиацией дел никогда не имел и в моделизме новичок. (Да и с математикой на уровне средней школы…) Свои предствления в этой теме формирую на основании сообщений форума и вики. Именно там написано- “Авиагоризо́нт — бортовой гироскопический прибор, используемый в авиации для определения…”. О применении в авиации “пузырьков” ничего не упоминается. Зато попадалось:
“Кренометр - прибор для измерения угла крена судна. Кренометр устанавливается в ходовой рубке. Простейший кренометр представляет собой отвес, перемещающийся по сектору, разбитому на градусы. Жидкостные кренометры (клинометры), основаны на использовании пузырьковых уровней.”
Известные мне существующие системы в авиамоделизме практически все выполнены на ИК-термодатчиках.
Секретную информацию о том, как использовать трехосевой компас для определения углов, так и не получил.
Повторю еще раз, получить крен и тангаж только из трехосевого датчика магнитного поля невозможно. За исключением случая полета в районе магнитного полюса, где силовые линии магнитного поля Земли вертикальны. В наших широтах наклон линий к горизонту - около 70 градусов.
Ну вот, вывод графики типо работает… 192х160
Пока без камеры, формирую синхро сам. Бенчмарк с другого изделия, шрифт 8х12 + 10 движущихся элементов, FPS довольно неплох 😃
На экране появляются артефакты, т.к. AT90CAN128 разогнана с 16 до 20 МГц. Других под рукой не было. Надо переползать на что-то побыстрее.
msv, прошу прощения, “обоснование” раздобыть не удалось, потому и не отписал 😦
Кстати, у вас на изображении шум на вертикальных элементах присутствует? Типа край дрожит…
Мну это поборол.
От разгона по идее не должно быть никаких артефактов. Проц или заведется или уж нет. Это только ИМХО, своей практики не так много.
Дрожание вертикальных полос есть маленько. Кварцы камеры и меги гуляют и самое заметное, когда они близко по частоте становятся. Тогда видны конкретные биения. Период тактового генератора меги всего в 4 раза меньше ширины пикселя, вот на эту четвертушку и бьет… Совсем побороть это можно только синхронизировав по фазе генераторы. Решение этой задачки считаю неоправданно сложным для столь простой схемки.
Период тактового генератора меги всего в 4 раза меньше ширины пикселя, вот на эту четвертушку и бьет
Неправда ваша 😃
Дело все в том, что переход по прерыванию от 1881 происходит только по завершении текущей инструкции. А они могут быть 1-тактные (nop, ldi*, sbi…), 2-тактные( rjmp, lds, breq…), 3-тактные (ld *Z+…) и 4-тактные ( jmp). Это дает ощутимую задержку в зависимости от того, что выполняется в момент прихода прерывания.
Ниже привожу компенсатор, который я поставил в самое начало прерывания. Правда, у меня прерывание работает от таймера TCNT1. При синхронизации от INT0 1881 планирую устанавливать TCNT1 в определенное значение и действовать по-прежнему от таймера.
#asm
push tmp
push tmp1
lds tmp,TCNT1L
lds tmp1,TCNT1H
cpi tmp,0x19
brlo rovn1
cpi tmp,0x21
brsh rovn1
ldiz rovn //
subi tmp,0x19
clr tmp1
add zl,tmp
adc zh,tmp1
ijmp
rovn: nop
nop
nop
nop
nop
nop
nop
nop
rovn1:
pop tmp1
pop tmp
#endasm
Неопределенность по времени входа в прерывания у меня решена как и во всех подобных системах, перед выводом "рабочих"строк (на которые накладывается картинка), проц “засыпляется”- asm(“sleep”). Вся работа фоновых функций разрешена только в межкадровый интервал. Если этого не делать, картинка просто безобразная…
А с остановкой проца остается только неопределенность на длину периода тактового генератора.
При синхронизации от INT0 1881 планирую устанавливать TCNT1 в определенное значение…
Не понял… каким образом??