OSD на ATmega1281
всё равно лучше
Что ж сразу такой пессимизм, попробуйте, а вдруг… Это ж не микромеханика, может что-то соизмеримое получится…
Не ожидал столько благодарностей, вроде ничего нового и не придумал, спасибо…
Была своя мега-идея- сделать вывод видео через 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 в определенное значение…
Не понял… каким образом??
каким образом??
У вас, как я понял, вывод строк идет в теле прерывания INT, а у меня, пока не подключена камера, в прерывании T1CompareA с собственной частотой 15625Гц.
По приходу ССИ от 1881 я устанавливаю TCNT1 на 8 мкс до сброса, а при срабатывании таймера начинаю тупо выводить очередную строку, пропустив программное формирование ССИ. Если ССИ от 1881 не поступало (камера разбилась, промокла, мало ли что), таймерное прерывание будет само формировать ССИ и КСИ, что позволит выдавать OSD даже без входа с камеры.
Т.е. прикрутив намертво плату к передатчику и резервной батарейке, решаем проблему поиска грохнувшегося самоля по GPS координатам.
Кстати, поэтому у меня проц сейчас вообще не усыпляется и все вычисления основного цикла main проходят непрерывно, только отвлекаясь на прерывание таймера. Т.е. сложность вычислений и время вывода на экран не имеет значения. А дрожание порешил, как указал выше.
Если правильно понял, пока у Вас нет внешних асинхронных процессов. Естественно и проблем нет.
По приходу ССИ от 1881 я устанавливаю TCNT1 на 8 мкс до сброса
Я и спрашиваю- каким образом??? Может есть какой-то аппаратный способ установки таймера, мне такое неизвестно… А если программно в обработчике INT, то даже при программной реализации ФАПЧ таймера, будет та-же неопределенность в несколько тактов, только для момента установки/коррекции таймера… Короче, может туплю, но так и не могу понять, куда собираетесь сажать выходы 1881? на прервание или … ?..
---------
Может кому будет интересно, вот диаграмка обработки сигналов моего уже реализованного автопилота:
В диаграмме указаны конфигурационные коэффициенты (задаются с ПС). Но многие детали пропущены. Да и не все показано, например нет логики переключения режимов Manual/Assistent/Autopilot, дополнительных аналоговых и дискретных каналов с функциями failsave.
Все отлаживалось на страшненьком симуляторе:
Это, конечно, не полноценны сим, аэродинамики там нет, просто замедленная реакция на заведомо загрубленные (для проверки I-веток PID регуляторов) команды.
В железе пока только оценена общая работоспособность.
Может есть какой-то аппаратный способ установки
Это лишнее. После формирования строки у нас есть еще 1-2 мкс на различные операции до поступления следующего ССИ (время обратного хода луча). В это время мы выходим из прерывания.
Второе прерывание у нас очень короткое: по INT0 (внешний ССИ) устанавливаем TCNT1 на 12 мкс до срабатывания, устанавливаем флаг наличия внешнего ССИ и выходим. Через 12 мкс (ССИ 4 мкс+СГИ 8 мкс) у нас срабатывает таймер. В таймерном, если был флаг внешнего ССИ, сразу выводим строку. Если не было, сами формируем ССИ и проч. Выходим. Процесс повторить.
Если внешнего ССИ не было в течение 12 мкс, сработает таймер и сформирует нормальную строку со всеми нужными сигналами.
И еще. Если внешний ССИ возник во время отрисовки строки, флаг прерывания сохранится, и оно выполнится сразу после выхода из таймерного. Т.е. в худшем случае синхронизация восстановится за 64/12=~6 строк.
Понятно? нет? Доделаю - покажу.
Кстати, а что за прога рисует такие красивые графы? или вручную?