OSD на ATmega1281
Ну вот, вывод графики типо работает… 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 строк.
Понятно? нет? Доделаю - покажу.
Кстати, а что за прога рисует такие красивые графы? или вручную?
у нас есть еще 1-2 мкс на различные операции до поступления следующего ССИ
До окончания ССИ времени даже побольше. Я (точнее мега) успеваю за это время считать по готовности байт с UART от GPS-модуля и уложить в буфер, и считать значение регистра захвата таймера, устанавливаемого PPM сигналом, и тоже записать в буфер. Ну это отношения к вопросу не имеет… а вот
по INT0 (внешний ССИ) устанавливаем TCNT1 на 12 мкс
меня смущает, что момент установки будет не точным, а, как Вы и писали, плюс-минус 4-такта. А значит и сработает тайметр с такой же неопределенностью… Сделать вывод по таймеру имхо возможно, но действовать надо по хитрее… Ладно, подождем результата, может я что и не понял…
-----------------------
Протестировал на столе автопилот, результат вполне обнадеживает.
Очень неплохо работает декодер PPM, наверное потому как проверка пакета делается на основании предварительно откалиброванных значений (мин, мах длина строба, мин мах значения для каждого канала). При ухудшении приема, сервы начинаю только слегко ерзать и отрабатывать команды с замедлением (почти как PWM).
Пару слов о логике автопилота.
В ручном режиме все работает как обычно, декодированные значения выдаются на соответствующие по конфигурации выходы.
В режиме “помощник” данные по каналам PPM трактуются как целевые углы крена и тангажа. Максимальное отклонение ручек соответствует максимальным углам, задаваемым конфигурацией. Далее алгоритмы управления (ПИД для крена, ПИ для тангажа), на основании текущих и целевых углов поворачивают в нужную сторону на требуемый угол сервы.
По своему небогатому опыту пилотирования, решил что для гарантированного сохранения устойчивости самолета, есть смысл динамически ограничивать максиманый угол тангажа в зависимости от крена. Получается приоритет у крена, те. пока поворачиваем, стараемся лететь ровно по тангажу. Для расчета максимального тангажа используется большее значение из текущего и целевого углов крена, и конфигурационный параметр - значение макс. тангажа при макс. крене. В промежуточных углах крена- линейная интеполяция.
В режиме “автопилот”- все так же, только целевой угол крена считается в зависимости от данных GPS о текущем курсе и направлении на базу. Для исключения неопределенности при расхождении курса близкому к 180град, используется конфигурируемый гистерезис переключения направления поворота. Целевой тангаж расчитывается по текущей высоте, целевой (конфигурируется) высоте и расстоянию до базы.
В режиме “автопилот” управление газом определяется по большему значению (текущий, целевой) тангажа. Конфигурацией задается значения газа для максимального, 0-вого и мин тангажа, а так же (для демпфирования) скорости изменения на увеличение газа и уменьшение. Кроме того контролируется скорость GPS и если она меньше порога, считаем что упали, газ отрубаем. Ну и сделал отчечку по напряжению с конфигурируемой скоростью уменьшения газа (очень полезно будет для двухмоторника).
Надеюсь это будет кому-нибудь интересно…
Наконец пришел от FMA датчик горизонта… Увы, действительно получилось дешевле, чем если бы заказавал отдельно термопары… (Хотя цена этой коробочки с операционником и четырьмя датчиками получилась равна GPS модулю… тоже как-то не по божески… ) Поставщики, у которых термопары копейки стоят, на мои письма не отвечают, вероятно торгуют только вагонами и с моими 6-ю штучками возиться не хотят … Ну а у тех, кто в розницу торгуют- просто бессовестные цены. С FMA датчиком прийдется довольствоваться только двумя осями, ну на первое время потянет… Вот снял тест, вместо теплой земли- теплая клава ноута. Точность не так что бы очень, но объяснима ограниченной площадью клавы и ее нераномерным нагревом. Надеюсь в реале будет точнее, хотя для моих криволетов и “супер” алгоритмов даже так сойдет…
Серёга, ГЕНИАЛЬНО!!!
Если это о том, что можно “полетать” прямо над клавой ноута, то согласен…😃 Поначалу хотел противень в духовке подогревать… 😃
Преследуя “корыстную” цель- не дать утонуть теме, выложу побочный результат “конверсии” по этой разработке. 😃
Столкнулся с проблемой, что для питания ТВ-передатчика и камеры на борту, требуется стабилизированные 12В. Ставить еще один акк. как-то неспортивно… Да и все равно прийдется стабилизатор городить… Борт питается от 3S ( 9-12,6В ), напрашивается SEPIC-преобразователь. К сожалению с ним результат получился не очень… Какой-то неустойчивый режим генерации, греются дроссели… Возможно требуется очень точно подбирать дроссели для нормальной работы. Но решил не усложнять себе жизнь и сделать простой step-up (boost) преобразователь, посчитав что даже на полностью заряженных акка, преобразователь заткнется и на выходе будет макс 12,2В за счет падения на диоде. Что вполне приемлемо для камеры и передатчика. Элементная база была выбрана по принципу мин. бюджета из деталей в местном киоске, поэтому применил MC34063 + IRF7413. Но при таком подходе, есть еще один плюс - расширяемость. Те. при желании можно поставить дроссельки побольше, диодик помощнее, ключики несколько в параллель или помощнее и получить любой разумный максимальный ток. Работа схемы так понравилась, что под впечатлением слепил step-down на 5V. Тут сразу не получилось, тк пытался обойтись в затворе низкоомным делителем. Увы… без ключа на биполярнике фронты оказались недостаточно крутые и соответсвенно низкое кпд.
Вот собственно окончательные схемки:
Ничего особенного, но это провереные рабочие варианта из доступных, относительно дешевых деталюшек.
Дроссели все самомотанные, основной для 5В step-down на колечке от материнской платы. Остальные на гантельках из платы монитора.
Ну и печатка ( не идеал конечно ):
BEC1.rar
Попробую по этой же схемке сделать step-up помощнее 12->19В для питания ноута от автомобильного акка…
Преследуя “корыстную” цель- не дать утонуть теме
Проект классный и достойный уважения, а чтобы он не заглох, возможно стоит сделать его возможным для повторения.
Выложить к примеру схему, плату, сорс или прошивку.
Лишь после того как другие, менее или более продвинутые программисты/электронщики повторят и испытают этот проект, можно будет его развивать дальше.
Тема интересная, не останавливайтесь, все вас поддержат.
Как вычислить направление до какой-то точки? Например до точки старта как в OSD. Т.е. именно направление (или угол), чтобы стрелка правильно показывала.
угол - тригонометрически. получается прямоугольный треугольник. оба катета известны, их отношение - это арктангенс. из него можно получить, как угол, так и гипотенузу. вычислять лучше таблично или CORDIC. перевод гипотенузы из градусов в метры делается с коррекцией широты/долготы. ведь 1 градус в москве и архангельске имеют разную длину =)
Надеюсь, что поможет- фукция расчета расстояния до базы, угла направления на базу и пройденного пути:
void calc_los(void)
{
unsigned long dx, dy;
u_int course;
static u_char div_wp=0;
if(gGPS_mode!=3) return;
if(gGPS_speed<gMainConfig.MinValidSpeed) return;
if(gGPS_lat_start>=gGPS_lat.Val) dy=gGPS_lat_start-gGPS_lat.Val;
else dy=gGPS_lat.Val-gGPS_lat_start;
if(gGPS_lon_start>=gGPS_lon.Val) dx=gGPS_lon_start-gGPS_lon.Val;
else dx=gGPS_lon.Val-gGPS_lon_start;
dy*=GRAD_METER_CONST; dy/=1000;
dx*=gGPS_lon_gm; dx/=1000;
gGPS_los=lsqrt((dx*dx)+(dy*dy));
//course
if(gGPS_los>gMainConfig.MinLos)
{
if(dx>=dy) course=90-(dy*45)/dx;
else course=(dx*45)/dy;
if(gGPS_lat_start<gGPS_lat.Val)
{
if(gGPS_lon_start>=gGPS_lon.Val) course=180-course;
else course=180+course;
}
else if(gGPS_lon_start<gGPS_lon.Val) course=360-course;
gGPS_course_base=course;
}
// wp
if(++div_wp>=5)
{
div_wp=0;
if(gGPS_lat_wp>=gGPS_lat.Val) dy=gGPS_lat_wp-gGPS_lat.Val;
else dy=gGPS_lat.Val-gGPS_lat_wp;
if(gGPS_lon_wp>=gGPS_lon.Val) dx=gGPS_lon_wp-gGPS_lon.Val;
else dx=gGPS_lon.Val-gGPS_lon_wp;
dy*=GRAD_METER_CONST; dy/=1000;
dx*=gGPS_lon_gm; dx/=1000;
gGPS_wp+=lsqrt((dx*dx)+(dy*dy));
gGPS_lat_wp=gGPS_lat.Val;
gGPS_lon_wp=gGPS_lon.Val;
}
}
Как видите для расчета арктангеса используется линейная интерполяция на участках 45град. Погрешность оценивал, точно не помню, но что-то меньше 2град, что для моей задачи вполне достаточно.
Наверное точнее не интерполяция, а линейная аппроксимация…
Отвечу на вопросы в личке здесь: Посчитать константу GRAD_METER_CONST и расчет глобальной переменной gGPS_lon_gm (считается один раз после инициализации GPS ) - “задание на дом”. Остальные переменные вроде бы очевидные, если не понятно спрашивайте…
Проект классный и достойный уважения, а чтобы он не заглох, возможно стоит сделать его возможным для повторения.
Выложить к примеру схему, плату, сорс или прошивку.
Лишь после того как другие, менее или более продвинутые программисты/электронщики повторят и испытают этот проект, можно будет его развивать дальше.
Тема интересная, не останавливайтесь, все вас поддержат.
Полностью согласен !
Люди, покаюсь… В принципе изначально не было в планах доводить проект до законченной конструкции с полным представлением всех исходников итп. Очень рассчитываю на обмен мнениями, идеями, как по железу, так и по алгоритмам. Много ценных замечаний и идей получаю в личке (чего только стоит шедевральный цикл вывода в строке за 3 такта на пиксель от уважаемого abalex), за что всем авторам большое спасибо.
От себя, например, могу доложить, что датчик температуры TMP36 категорически не хочет работать в зоне облучения 1гГц видеопередатчика. Боялся, что будут проблемы с GPS, а тут какой-то г-ный датчик температуры на несколько дней все затормозил…
В приципе сейчас все готово, лайнер снаряжен, осталось дождаться ходовых акков с ХС и хорошей погоды для проведения летных испытаний. Правда вес мой 1,5м ероплан, на котором уже отлетал 1,5 сезона, прибавил значительно, ужо засомневался, а взлетит-ли… 😃 Ну май уже скоро, там и посмотрим…
Я это к тому что поразвивать этот проект в вертолетно-коптерном направлении- там специфики своей много очень, ее по любому прописывать заново, просто если мы все будем одних и тех же барабашек вылавливать, быстрее их не выловим.
По поводу термодатчика: он в металле? кондер на ногах стоит? хотя по меньшей мере странно, гиры в коптере гораздо более чувствительны к полям, и измерения на уровне одного отсчета АЦП, 3,3мв, прямо под платой стоит видеопередатчик с оторваным экраном(перегревается иначе) 0,5вт, а рядом с платой антенна двухстороннего радиолинка 0,5 вт 433мгц на основе rfm12bp, все это летает, не дрыгается.
В рабочих проектах правда давно уж применяем DS18S20. На него весь стек проверенный мной есть. Но в данном случае это врятли будет работоспособно, у него свой реалтайм жесткий
PS/ хотя я сейчас уже на распутье (концептуальном), а стоит ли делать так. Сейчас имею радиолинк с потенциалом 3 км в городе! двухсторонний на основе кода Слона(www.1slon.ru/rc24868.htm). Потенциал линка заведомо превышает все мои возможные полеты на коптере, дом просвечивает, небольшой холмик тоже, имея высоту, горизонт стрелку и LOS, подогнать к себе коптер можно (хотя сложно:) ) ППП, потенциал видео (0,5 вт на 2,4ГГц) заведомо меньше. Поэтому напрашивается osd делать на земле, в том числе и при пропадении синхронизации с камеры, а это уж явно не AVR. либо ASIC, либо ПЛИС.
Первый раз этот датчик использовал в своем пульте с 35Мгц передатчиком. Тоже заработал только после того, как повесил на питание и на выход непосредственно на датчик емкости.
А тут… датчик на маленький платке, питание и выход зашунтированы емкостями SMD, все в глухом экране, на шлейфе ферритовое колечко… На расстоянии ближе ~1м от антенны на выходе вместо постоянки, какие-то прямоугольники… Блин… все законы физики неверны… Купил другой - такая же фигня… Уж не так мне нужен этот датчик, просто было уже интересно… повесил доп. нагрузочный резистор, запитал от отдельного источника, еще что-то мудрил, уже не помню… Прямо не датчик температуры, а сверхвысокочувствительный датчик эл.магнитного поля…
C DS18S20 некогда обмениваться, Вы правы. Во всяком случае неохота городить еще один критичный реал-тайм процесс… Пока сделал на делителе с KTY81. Нелинейность плюс/минус километр, ну как индикатор пока пойдет…