OSD на ATmega1281
Похвастаюсь…
Сделал QRP тест своей LRS. Мощность зажал до ~20мВт ( на приборе первое деление 100мВт, показывал мнооого меньше). Антенны и на приемнике и на передатчике- штыри. На передатчике честный штырь с тремя противовесами под 45 град, пол метра над крышей авто, КСВ чуть больше 1. На расстоянии 2км, высоте 150м уровни -70dbm, ни одного дропа… Причина возврата- выполнил полетное задание.
Вчера облетал свой IMU. Железо: мега8 (вообще первоначально думал сделать на нем только интерфейс для опроса сенсоров и сброса на хост, на котором отладил бы математику, и уж потом… выбрать под потребности необходимый проц…)+сенсоры. Алгоритм - классический DCM (изменения косметические). Пока математика без компаса (че-то не понравилось как у авторов сделано,да и флэша в меге может не хватить), с постоянной заданной линейной скоростью для расчета центробежных ускорений. Работает… ну уж точно не хуже пиросенсоров… Проблемы предсказуемые, основная- после долгих вращений из-за неточной коррекции центробежки не сразу точно встает в 0 по крену. Но для полетов вполне удолетворительно, в режиме стабилизации уронить не просто, авто-режимы отрабатывают нормально. Если нужны исходники адаптированные именно под эти сенсоры, выложу…
Добавлю пару фоток:
а как с OSD?
Причина возврата- выполнил полетное задание.
ооо… звучит многообещающе.
На передатчике честный штырь с тремя противовесами под 45 град
буду банален, но при наличии такой крыши… никакой ground-play не нужен.
ИМХО 5/8 то что доктор прописал.
На расстоянии 2км, высоте 150м уровни -70dbm
судя по цифрам запас по расстоянию раз 10 и если еще 5/8 совсем гуд будет.
Сергей, а что вы скажете насчет вот такой www.ebay.com/itm/271031471551 IMU? Заказал себе недавно, жду теперь. Думал сначала взять как у вас, но решил попробовать что всё-таки за зверь этот Digital motion processor.
Я не буду слишком нахальным, спросив нет ли у вас исходников для расчёта DCM?
Ну эти сенсоры уж точно не хуже моих…
Теория DCM легко находится гуглом: “direction cosine matrix imu”.
Исходники по: “ArduIMU_1.9”
Если хотите, могу выложить свой адапт+отладочный софт на BCB6, но там мин. комментариев.
На данный момент понял, что много лучше для расчета центробежки использовать скорость GPS, а не заданную константой. Ведь при полете по ветру и против она может отличаться в разы.
И пока засада… на хосте все нормально, на МК тот же код вызывает при больших скоростях заметную не устраняемую ошибку между ориентацией по акселю и гиры.
спс за наводку, DCM пошукаю по тырьнету.
заметную не устраняемую ошибку
я так понимаю это в купе ошибка интегрирования + дрейфы сенсоров…именно поэтому я решил взять invensense и покурить их DMP, заодно попробовать пропусть это через калмана, если таки до меня дойдет его логика работы😵 только вот мучать сразу решил кортекс-м4.
Решил, проблему… Мой косячок… На столе работает замечательно…
калман, кортекс… Это все здорово… Но имхо важнее четко понимать физический смысл каждой строки алгоритма и четко представлять все его ограничения… В этом смысле DCM не превзойден своей гениальной простотой и очевидностью. А уж что влез в мегу8, сам не ожидал…
Вообще по плану инерциалку думал слепить только к следующему сезону, долго и нудно отлаживаясь долгими зимними вечерами. На удивление за недельку работы по вечерам склепал платку и адаптировал математику. Неожиданно сложно (целых два дня ушло) оказалась реализовать софтовый интерфейс с OSD (SPI, TWI, UART там уже недоступны).
а как с OSD?
Могу выложить прошивку последней версии с вертикальной парой пиросенсоров (наверное больше не буду ее поддерживать).
буду банален, но при наличии такой крыши… никакой ground-play не нужен.
Ну не play, конечно, а plane… 😃 Первоначально был штырек-четвертушка прямо в разъем. Тоже посчитал, что земли хватит… Но стало интересно померить КСВ. Попробовал коаксиальную слепить, на удивление не смог согласовать… А вот “классика”, сделаная в размер, сразу идеально согласовалась. Более того, по сравнению со штырьком в разъеме (видимо тоже не слишком был согласован…) показала почти +6dbm. Так что пока вполне доволен, только хранить и перевозить эту раскоряку конечно не очень удобно…
Могу выложить прошивку последней версии с вертикальной парой пиросенсоров (наверное больше не буду ее поддерживать).
А ну сбросьте на майл. А что значит не поддерживать, те OSD как понимаю (творческая неудача ) и почил?
Антенки: либо блямба магнит либо отверстие в крыше ( я так понимаю не желательно ) предпочтительно 5/8. 1/4 из стальной проволоки в центре крыши с хорошим контактом ( теоретически 36 Ом плюс потерь на 14 Ом ), плюс блямбочка (емкость удлинняющая ) на кончике, тоже должно быть гуд.
делаю генерацию видео на меге32 (в 16ой памяти мало)
сделал текст 40х28 с графическим полем 88х72 которое можно размещать в произвольном месте (командой)
у графического окна есть пока 2 режима
общее разрешение 88х72 может выводиться в разрешении 320х224 (в разрешении текста)
и в разрешении 160х224 (по горизонтали в 2 раза крупнее)
все вертикальные линии получились ровные - уделил этому специальное внимание
ссылки на файлы в большом разрешении
vg.ucoz.ru/_fr/0/0708507.jpg
vg.ucoz.ru/_fr/0/5946348.jpg
может быть использовать как модуль наложения изображения в OSD ?
в качестве контроллера атмега 328
для общения с внешним миром - планирую uart или i2c (spi занят на дисплей)
в графическом окне можно рисовать авиагоризонт, и выводить какую то другую графическую инфу…
а в текстовой выводить все остальное…
в принципе сейчас делаю другие графические режимы (текстовый 20х28 и графический (полностью графика) 160х92 )
делаю генерацию видео на меге32 (в 16ой памяти мало)
Вот опенсурсный проект Mobidrone OSD на меге 328:
code.google.com/p/mobidrone/
Вот так сейчас выглядит:
Молодцы, мужики! Интересные проекты.
Видео- прям OSD с марсохода… 😃
Виталий, как прямо по ходу строки умудряешься успевать сообразить, когда пора графику выводить, а когда опять псевдо?
Возможность полного заполнения экрана по вертикали это здорово, но надо ж ещё когда-то успеть как мин. перерисовать видеобуфер…?
но надо ж ещё когда-то успеть как мин. перерисовать видеобуфер…?
Я уже как-то говорил, что с MSP все делается элементарно - например, для того, чтобы получить такую картинку, понадобилось меньше 3К ОЗУ на все-про все - видеобуфера (целых 4 штуки! - по 45 байт каждый 😃 плюс отдельный буферок под горизонт - но не рабочий, а для предварительного формирования линий), переменные, стеки, строки и т.д. и т.п. Причем рисуются и белые, и черные точки:
Что поважнее- обведено черным, декорации - только белые, и нехай себе пропадают 😃
Если делать маленькую белую точку, а за ней черную - цветной факел на белом гарантирован, посему шрифты толстые.
При желании можно что-нибудь серое нарисовать, включая одновременно белый и черный пиксель.
Виталий, как прямо по ходу строки умудряешься успевать сообразить, когда пора графику выводить, а когда опять псевдо?
у меня генерация видео на асме… полностью…
перед каждой строкой текста (44 байта) идет байт который указывает с какой текстовой позиции выводить графику и байт адреса этой самой графической строки в графическом буфере…
правда все равно поля где то в полтора символа слева и справа есть для графического поля - я адрес вычислял на ходу… буду переписывать сделаю заранее - тогда наверное поля уменьшатся втрое
Возможность полного заполнения экрана по вертикали это здорово, но надо ж ещё когда-то успеть как мин. перерисовать видеобуфер…?
я даже во время генерации кадровой последовательности успеваю основную программу исполнять…
плюс до и после вывода 224 строк изображения у меня суммарно более 60 строк “ничего не делания” - так что по моим прикидкам на остальные задачи процентов 8-9 процессорного времени остается…
где то был тест со скролингом экрана, так там если задержки убрать вообще мелькание символов снизу вверх… хотя скролл полностью программный
у меня генерация видео на асме… полностью…
Это само собой разумеется… 😃 Да и действительно стыковать графическое окно с текстом пиксель в пиксель нет смысла… Сколько тактов на пиксель в режиме текста и графики получилось?
Ни и конечно, не подумал…, что для текстового режима нет необходимости отрисовывать в видеобуфере каждый пиксель буковки… Поэтому конечно много быстрее получится экран обновить…
Если делать маленькую белую точку, а за ней черную - цветной факел на белом гарантирован
Эх… больная тема… В теории вроде так… Но ведь у rvosd и прочих уважаемых изделиях все чистенько… Подсмотреть бы у них схемку модулятора…
у меня генерация видео на асме… полностью…
Это само собой разумеется…
А меня на С++ … полностью… 😃 само собой разумеется 😃
Ни одной ассемблерной вставки 😃
Но это так увлекательно из слабого на сегодняшний день проца выжимать все на что он способен, и даже чуть больше… 😃 Прямо спортивный азарт… 😃 Вообщем хобби такое…
Ни коем случае не хочу обидеть (безусловно оценил и грамотность выбора проца, и грамотное использование его аппаратных возможностей), но то что вам удается обходиться без асм-а, как бы не совсем ваша заслуга… 😃
Хотя, если у меня дело дойдет до следующего релиза (пока нет в планах), вполне возможно он будет на чем-то типа MSP430 или даже STM32…
как бы не совсем ваша заслуга…
Вы меня не так поняли. Это как бы реклама 😃 Фирмы - производителя сего процессора.
Подсмотреть бы у них схемку модулятора…
Дык скиньте жеж последнюю прошивку я сам как нить промодулирую.
Это само собой разумеется… 😃 Да и действительно стыковать графическое окно с текстом пиксель в пиксель нет смысла… Сколько тактов на пиксель в режиме текста и графики получилось?
2 такта
Ни и конечно, не подумал…, что для текстового режима нет необходимости отрисовывать в видеобуфере каждый пиксель буковки… Поэтому конечно много быстрее получится экран обновить…
угу, правда для этого я знакогенератор храню по линейно (сначала 256 первых линий всех символов, потом 256 вторых линий, и т.д.)
Давненько не выкладывал видеоотчеты. А ведь этот сезон начал на новом носителе (вжик), с новой камерой, с новой системой РУ. Ну а в последнее время все не нарадуюсь на ИМУ…
О параметрах в верхнем левом углу:
- РУ. Крутится палочка по получении данных от приемника с валидной КС. Лампочка, если что-то плохо. Уровень сигнала в dbm. Количество дропов за последние 2,56сек.
- GPS. Количество спутников. PDOP.
- IMU. 1я цифра: Отклонение длины вектора акселей от 1G. 100%-> ==1G; 0%-> <0.5G || >1.5G;
2я цифра: длина нормализованного вектра ошибки между осью Z матрицы и акселерометром. 0-> совпадают.
Ниже цифры: крен/тангаж.
Коментарии по видео:
Ветер слабый но порывами.
0-12сек; проверка на вертикальные ускорения.
12-2:55; скучный отлет на пару км в режиме FBW и возврат в режиме RTH.
2:55 до конца; проверка ИМУ на устойчивость к центробежным ускорениям.
Коментарии по видео:
Красиво. А где тянучка или flame на видео.