OSD на ATmega1281
это угловые акселерометры, выдающие скорость
Акселерометр не выдаёт скорость, он выдаёт ускорение со знаком. Т.о. для компенсации отклонения от оси необходимо выдать ускорение с противоположным знаком.
З.Ы. Про системы регулирования здесь писать ничего не буду.
Акселерометр не выдаёт скорость, он выдаёт ускорение со знаком. Т.о. для компенсации отклонения от оси необходимо выдать ускорение с противоположным знаком.
Воспользовался термином не подумав. Зато могу подсказать как сделать в домашних условиях простейший акселерометр для баловства 😃.
могу подсказать как сделать в домашних условиях простейший акселерометр для баловства
Предпочитаю изделия от аналоговых девиц… 😃
Лучший гироскоп - это трехмерный компас
Была такая мысль… Даже уже начал заказывать сет HMC1055. Но подумав, понял, что по одному вектору невозможно построить однозначную 3D систему координат, а значит и посчитать углы (тк. просто непонятно от каких осей их считать). Буду рад выслушать опровержение.
Про гироскопы возможно пишу бред, т.к с ними не сталкивался, сильно не ругайте. Но в моем впечатлении просто угловой аксель это еще не гироскоп. А если уж назвался гироскопом то обязан выдавать угол. И не важно на каком принципе этот угол определяется: механический волчок или угловой аксель+какой-то хитрый вычислитель/интегратор.
Зато могу подсказать как сделать в домашних условиях простейший акселерометр для баловства
Отвес? 😃 Поделитесь конечно…
ЗЫ Кто-нибудь заказывал FMA-голову? Поделитесь впечатлениями, в тч. насколько сложно заказать в Россию. Можно в личку…
Трехмерного компаса недостаточно. Например, в ситуации, когда одна ось параллельна линиям магнитного поля Земли, будет полная неоднозначность положения.
Гироскопами тут называют датчики угловой скорости. Они выдают именно угловую скорость, а не ускорение и не угол. Если интересно, посмотрите на моей страничке проект с использованием такого датчика. Акселерометры - это совсем другие устройства и они выдают линейное ускорение.
Буду рад выслушать опровержение.
Не для форума. Завтра отпишу в личку. Это вас убедит 😉
В системе координат 3d компаса вектор S-N будет однозначно определен при любом положении. Но что делать дальше?.. Мне нужны углы с плоскостью параллельной земле. У меня есть вектор в этой плоскости. Но вектор это только две точки, а для определения плоскости в пространстве нужно три… Заинтригован…
2Vad64
За ликбез по гироскопам- спасибо. ( Теперь дошло, что хотел интегрировать Nik_Shl. 😃 ) Посмотрел проект, серьезный подход, спасибо.
А графический OSD это отличная идея! Повторил видеодрайвер. Жалко, что весь порт занимает… У меня влезло в 4 килобайта срама на ATMEGA644. Тем более, что 20 МГц это его штатная частота.
В промежутках по краям экрана можно что-то считать + 224 байта памяти в запасе. Неплохо, учитывая, что видеопамять вся внутри и доступ быстрый донельзя. К тому же, основной процесс в Main протекает и не критичен по времени.
Надо попробовать привинтить к нему какой-нибудь 3D интерфейс, ибо драйвер занимает всего 40 слов, а быстродействия осталось еще 10 MIPS 😃 😁
Также есть идея: использовать внутреннюю генерацию синхро, если пропадает внешняя. Так при отказе камеры, например, в облаке от сырости, можно будет и по приборам лететь 😃
Автору респект!
Сергей, а не пробовал картинку реалистичнее делать? В плане чтоб “освещение” не слева направо было, а в соответвии с солнцем ? 😃
а в соответвии с солнцем ?
если придумаете, чтобы развертка в телевизоре меняла направление в зависимости от солнца, будет вам “реалистичней” 😁
Вообще, это для того, чтобы на белом фоне буквы видеть, а не красота…Называется ВЧ-фильтрация, или, как Сергей выразился, дифференциатор. Делается внешним конденсатором. Развертка идет всегда слева направо, поэтому тени сменить не получится. Только убрать.
Ничего, что я ответил? 😃
Развертка идет всегда слева направо, поэтому тени сменить не получится. Только убрать.
Ничего, что я ответил? 😃
Вот смотрю ща кино по телеку, а там направление теней соответвует источнику света 😃, хотя развертка тож слева направо и сверху вниз.
Просто не вглядывался в превьюшки, не посмотрел, как тени реализованы. А чтоб читалось лучше независимо от картинки - фон может иметь смысл вобще черным делать там где надписи, или у букв черную окантовку делать. На белом фоне белые буквы с тенями конечно читаются лучше, чем без теней,но тоже нифина не комфортно.
Сергей, а не пробовал картинку реалистичнее делать? В плане чтоб “освещение” не слева направо было, а в соответвии с солнцем ? 😃
Реалистичнее это совсем убрать 😃. На реальных самолётах 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-ветка примитивный метод прямоугольников с ограничением. Задается время интегрирования и диапазон ограничения. Что-то не могу сообразить что ждать от этой ветки. Если сделать время интегрирование большим, может есть шанс получить эффект автотриммирования. Если малым- компенсацию избыточной устойчивости скажем высокоплана для ненулевого крена. Кстати, для последнего может есть смысл добавить еще ветку - пропорциональную заданному значению крена (не ошибки). Собственно это все вопросы…