OSD на ATmega1281
Отвес? 😃
В большой авиации до сравнительно недавнего времени именно по отвесу (маятнику пузырьковому) авиагоризонт корректировали. У больших самолетов он ведь тоже убегает по времени. Правда модель болтает больше чем реальный самолет, простым выключателем коррекции уже наверное не обойтись.
ИМХО по поводу "до сравнительно недавнего времени "… конечно все относительно, но в моем представлении давненько уже это было… 😃 Подобный принцип (только трех-осевой акселерометр) еще худо-бедно годится для индикации, и может даже поможет выбраться пилоту из облака, но никак уж не пойдет для системы управления. Уж очень велика вероятность получить на вираже за счет центробежного ускорения около нулевые показания крена, ну и тп…
А вопрос по датчикам углов остается открытым… Пока для отладки использую пару потов в каналах АЦП, накручивая ими “крен”,“тангаж”. Секретную информацию о том, как использовать трехосевой компас для определения углов, так и не получил. 😦 Но сообщение заставило еще раз задуматься… А что если крутить компас, например вдоль одной оси?.. Тогда конец вектора 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 строк.
Понятно? нет? Доделаю - покажу.
Кстати, а что за прога рисует такие красивые графы? или вручную?
у нас есть еще 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град, что для моей задачи вполне достаточно.