Создание собственной системы стабилизации
Мне нравится такая мысль, куку явно не хватает акселерометров. Не очень перспективно, но зато актуально.
Два акселерометра повесятся без проблем, а вот дальше либо отказыватся от подстроичников и чисто программно настраивать гиры, плюс переделка ПО ввод новых переменных, 88 может уже не хватить.
я к чему у людей тоже атмега стоит rcopen.com/files/000000000000000000000000
Два акселерометра повесятся без проблем, а вот дальше либо отказыватся от подстроичников и чисто программно настраивать гиры
С курсом мне кажется вообще ни у кого проблемм нет, так что остается крен и тангаж. ATMEGу при необходимости можно и помощнее взять.
Нужно над этим поразмыслить, попробую, подсунуть два акселерометра…
Хотя есть и цифровые тогда всё проще SPI или I2C и трёхосевой впихнётся, по I2C можно и несколько устройств повесить…
за исходниками в почту rw9uao который живет на yandex ru
исходники ппм энкодера ardupilot-mega.googlecode.com/svn/…/trunk/
для ARM926 (конкретно at91sam9260) для QNX? =)
www.starterkit.ru/html/index.php?name=shop&op=view…
вот на эту штуку гляньте. бюджетнее вы мощный АРМ926 не найдете.
вот еще вариант
pico-SAM9G45
- SAM9G45 pico-ITX compatible SBC (80x100mm)
- ARM9, 400Mhz, ARM926EJ-S, 32/32K
- 256MB DDR2
- 4 USB 2.0 ports 480Mbps, shared
- 1 miniPCI-e with USB only support
- 10/100 Mbps Ethernet
- SD card reader
- SIM card slot
- Bootable microSD
- 5V power via microUSB
- 6-40V support via DC barrel connector
- High endurance ceramic and SP capacitor design
- Expansion header for SPI, I2C, RS232
- Native support 480 x 272 LCD (higher resolution possible)
- WIFI support via miniPCI-e with USB
- Buzzer
- Plastic enclosure with multiple mounting options. (sold separately, available April 2011)
- Ideal for development or OEM use.
- Linux / Android boot options.
www.mini-box.com/pico-SAM9G45-X
arm.mini-box.com/index.php?title=Releases
Вобщем, пока суть да дело и финансовые проблемы буду к КУКу акселерометры прикручивать…
Вобщем, пока суть да дело и финансовые проблемы буду к КУКу акселерометры прикручивать…
Получилось прикрутить?
Получилось прикрутить?
Ага, за 5 часов сделал сопряжение с акселерометрами, написал программное обеспечение и обкатал на нескольких видах коптеров. 😁
Ага, за 5 часов сделал сопряжение с акселерометрами, написал программное обеспечение и обкатал на нескольких видах коптеров. 😁
А можно поподробнее. как это получилось сделать?
А можно поподробнее. как это получилось сделать?
Вы это серьезно? 😃 Я же поставил в конце смеющийся смайлик.
Я пошутил, за такой короткий срок это невозможно. Вы наверное никогда не сталкивались с электроникой на уровне разработки и написания софта. И уж тем более ее обкатки.
С сопряжением на базе даташита еще кое-как можно быстро разобраться. А вот засунуть в чужой код подпрограммы обработки с последующей коррекцией на этапе отладки, это обычно очень длительный процесс.
Недаром за полгода на КК-контроллер вышло несколько десятков подверсий программного обеспечения и продолжают выходить дальше.
Если у Сергея выйдет что-то рабочее меньше чем за месяц, я буду первый орать “браво” и выклянчивать у него софт.
Извините, если ввел в заблуждение, но подумал, что это очевидно.
И так мысли в слух, имеется KKmulticontroller v.5.5 “Blackboard” www.kkmulticopter.com/index.php?option=com_content… собственного исполнения на Atmega 168 и акселерометр LIS35DE, любезно выдернутый из китайской NOKIA N71 знакомыми паяльниками.
Здесь описание и исходники под модуль на этом акселерометре.
имеется две проблемы, но их никак не избежать, наверно, без переделки КУКа
в первом случае если подключатся через I2C то нужно её освободить, а во втором если через порт программатора то нужно освободить порт SS иллюстрацию прилагаю, может в чём не прав поправте…
Блин картинка не ахти получилась
1- перенести подстроечники с выводов 27 28 на 19 22 соответственно ну и конечно переназначить порты
2 - перенести Motor1 с вывода 14 на вывод 2 ну тоже с доработкой программного
хотя если я правильно понял то порт SS используется только для переключения режимов I2C и SPI так для SPI замкнуть вывод СS акселерометра на корпус и всё никакой переделки КУКа?
Ну конечно надо избежать каким то образом генераторы прерываний INT1 и INT2
примерное подключение
Акселерометр – Атмега
13 – 15
12 – 16
14 – 17
Накидал платку акселерометра, естественно под разъём платы привёдённой выше - прошу критиковать:)
Акселерометр получается точно по центру платы
Теперь самое страшное - научить КУК общатся с ним.
Может написать как отдельный модуль для корректировки гироскопов, тогда бы не пришлось всё програмное менять?
Может написать как отдельный модуль для корректировки гироскопов, тогда бы не пришлось всё програмное менять?
При отдельном модуле придется обрабатывать параллельно два потока данных. Проще, наверное, написать отдельную процедуру обработки данных с акселей и корректировки гироскопов. И вызывать ее из основного тела программы до или после каждого цикла обработки данных с гироскопов.
Правда увеличится общее время обработки, и возможно из-за недостаточной скорости контроллера уменьшиться общая скорость опроса. Но в этом случае работа модулей будет последовательной во времени.
Как-то так.
Блин сижу и думаю с какого конца програмное кусать, может всё таки задействовать INT какой нибудь, повесить на свободный вывод атмеги, при изменении на INT - считать данные с акселерометра, или в какой-то определённый момент считывать, одна операция за такт, аналоговые наверно можно было бы прямо в процедуру обработки гироскопов вписать, совет бы желательно по русски, а то один исходник для мигания светодиодами занимающий всё время процессора без нормального описания для меня маловато, а ещё в прошивку это всё вклинить надо не покалечив её, ладно буду дальше репу чесать - делать то надо…
подскажу. сделайте для начала _аппаратный_ выход РРМ. мега у вас мелкая, ног мало, поэтому поставьте еще микросхему счетчика-декодера как на аналоговых приемниках. тем самым сильно разгрузите время процессора. можете этот кусок когда подглядеть в кодере фокус/MSV. в КК формирование сигнала РРМ сделано по идиотски. захват РРМ сигнала у вас итак аппаратный. гироскопы вы опрашиваете по аналоговым входам. в КК опрос идет поллингом. сделайте нормальный обработчик прерывания такого вида:
вход в прерывание АЦП
запись значения текущего канала в переменную
ADMUX = новый_канал | ADC_VREF_TYPE;
запуск замера
выход из прерывания
только на этом вы сэкономите 10 мСек на каждый канал.
идем дальше. акселерометр у вас на I2C? либо делайте аппаратно, либо цепляйте к аналоговым входам. их у вас 8.
в основном цикле только отработка математики. Калман - х.з. а вот ФНЧ надо обязательно. ну и ПИДы само собой.
акселерометр у вас на I2C?
Вообще-то я его планирую по SPI впихнуть дабы не переделывать кук
Примерно так
Ладно нужно срочно откапывать в себе талант программиста и переделывать всё таки софтину
Сразу предупреждаю я не программист, вот исходник с которым я воюю:
не могу понять где происходит определение изменения показаний гироскопов, была мысль читать данные из акселерометра после каждого изменения?
{
asm volatile (“NOP”); asm volatile (“NOP”);
asm volatile (“NOP”); asm volatile (“NOP”);
asm volatile (“NOP”); asm volatile (“NOP”);
asm volatile (“NOP”);
}
это цикл ожидания прервываний я так понимаю ?
Нарыл подобное подключение на Aruino physics.csuchico.edu/…/micrologger.pde.html
www.rlocman.ru/shem/schematics.html?di=70957 здесь само подключение