MultiWii
а че там паять
100 пинов меги на плату паять qtfp 100 это жесть ждать нехочеться duin’у
242->usb уже спаял (выше гдето было) шас плату дуины потом на 1 схему их
Возник вопрос относительно питания кардуины НАНО.
В интернете встречается такая информация:
“Arduino Nano может получать питание через подключение Mini-B USB, или от нерегулируемого 6-20 В (вывод 30), или регулируемого 5 В (вывод 27), внешнего источника питания. Автоматически выбирается источник с самым высоким напряжением.
Микросхема FTDI FT232RL получает питание, только если сама платформа запитана от USB. Таким образом при работе от внешнего источника, будет отсутствовать напряжение 3.3 В, генерируемое микросхемой FTDI, при этом светодиоды RX и TX мигаю только при наличие сигнала высокого уровня на выводах 0 и 1.”
Хотелось бы уточнить:
- если питать кардуину от ВЕС одного из регуляторов (5в) через вывод 30 (vin), то она работать не должна.
Соответственно придется запитывать ее или от ходового АКБ (11.1в) или от дополнительного стабилизатора вольт на 8-9. - если питать кардуину от ВЕС через вывод 27 (+5v), то все будет вроде нормально, но напряжения 3,3v на выводе 17 ни в том ни в другом случае, судя по всему, не будет.
Отсюда вопрос - как запитывать ВМП и нунчак в таком случае?
И вообще, интересно, у кого как организовано питание на борту?
Вот теперь я понял. Подключал ардуину по USB, все датчики работали нормально. Подключаю от ESC, датчики с ума сходят. (пост №506) Завтра буду паять регулятор напряжения.
а в чем проблема запитать так же от USB? я проста кабель нашел лишний, отрезал и пихнул питание с ESC (5V до 2A) на mega через usb дырку (очень надеюсь что там от кз че нить стоит) =)
Ковыряю седня весь день BaronPilot и скорее всего буду юзать эту прошивку - там работа с i2c через стандартную библиотеку, а не самописную штуку, которая через раз работает, т.е. нет никаких проблем с работой датчиков (с multiwii мой нунчак заработал 1 раз нормально, и после резета снова фигня началась)… зато появилась другая проблема - библиотечка для i2c крайне не любит работать с VirtualWire, без которой не работает связь в моём варианте (без аппы), поэтому было решено разориться на еще одну seeeduino и сделать 2х ядерные мозги для коптера… пока опробовал просто соеденить платки (RX<->TX, TX<->RX, GND<->GND и 5v->Vin, чтоб не 2 усб кабеля резать), чтобы туда сюда между ними данные гонять - работает отлично, поэтому буду собирать так: на seeeduino mega прошивка стандартная (+ управление какой нибудь периферией, благо дырок дофига), на другой сидуинке связь и плюшки вроде дальномеров (которые будут тормозить из-за ожидания ответа сигнала) и gps (ради этого в общем то и затевалось всё), чтобы не нарушать работу основной программы =)
PS: если у кого то внезапно перестала заливаться прошивка в Linux… ковыряем файлик .arduino/preferences.txt на предмет строки serial.debug_rate=9600 - сегодня испугался что убил мегу, а оказалось что там другая скорость стояла и ничего не хотело заливаться
Друзья, проблема не в мультивии, а в связке несовместимых между собой wiimotion+ и нунчака… если не пошло сразу гладко, забейте на нунчак, полетайте только с вимоушеном, купите себе нормальный акселерометр. Я не знаю ни одного человека из rcgroups и отсюда, чтобы multiwii не летал вообще (тоесть без нунчака) или с другим акселерометром…
На выходе получаем постоянку, которую можно подавать на любой ОСД, поддерживающий термоголову FMA
Олег, а какие еще ОСД поддерживают твою фичу? ЧТо такое термоголова FMA?
Ну иногда то оно работает идеально, но чаще всего тупит, а хочется чтоб стабильно работало (без перебора кучи нунчаков) =) пока поковыряю 2х ядерный вариант с бароном (где пробем нет с i2c), который потом без проблем под любую прошивку смогу переделать (управление различается только названиями массивов и дипазоном параметров в них) не меняя кода работы с дальномерами/компом/gps(очень надеюсь)/etc, да и третью сидуинку уже заказал, поэтому обратной дороги нет =)
у вас при соединении 2х плат по usart проблем с тактами нет ? … 2 разных кварца без синхронизации как я понял … у меня 2 меги отказываються работать быстрее чем 2400 от разных кварцев
проблем не заметил, общаются на 9600 и на 14400 нормально (blog.sovgvd.info/2011/03/2.html), другие варианты не тестил, так как выше 9600 всеравно не надо будет =) а почему кварцы разные? у меня на платках по 16 оба кварца (328 и 1280 процы)
ЧТо такое термоголова FMA?
Это пирометрический датчик горизонта. Применяется в стабилизаторе полета FMA. Принцип основан на разнице температур неба и земли. В не облачную погоду температура земли на несколько десятков градусов больше чем температура неба.
paparazzi.enac.fr/wiki/Infrared_Sensors
Минусы - невозможны или затруднены полеты в туман, в облачность и меж деревьями,строениями и прочем.
Плюсы - нет дрейфа. Математика - проста.
у меня на платках по 16 оба кварца (328 и 1280 процы)
при таких включениях мк вроди как должны тактоваться синхромно … с ножки xtal2 ведущего на xtal 1 ведомого
- какието танцы с бубном вокруг fuse bits …
связывал atmega1280 + atmega32 пока незделал с одного кварца нивкакую …
хз, может я че не так делаю, но работает нормально - сообщения с одного контроллера на другой адекватно льються, может во время дальнейших экспериментов баги полезут… + я точно так же GPS подсоединял (blog.sovgvd.info/…/arduino-gps-holux-m-1000.html) - там то такты тем более не синхронизированы никак, но всеравно всё работает
Олег, а какие еще ОСД поддерживают твою фичу?
Я проверял на ИглТри и уверен в нем. Про другие выдумывать не буду (а их куча разных еще есть). Но если попадется на глаза ОСД, умеющий работать с горизонтом FMA без Z-сенсора, то с ним этот прикол тоже пройдет.
Обнаружил в Мультивие косяк в режиме автоуровня: если коптер стоит слегка неровно с запущенными винтами какое-то время, то при даче газа он подскакивает со стороны перекоса, как ужаленный. И чем дольше, тем хуже. Может мгновенно перевернуться.
Если активировать движки сразу перед взлетом, такого не происходит. Типа как будто накапливается I-составляющая ПИДа, при невозможности воздействия.
По идее, в режиме IDLE, когда мультивий движками не маневрирует принципиально (минимальный газ), не стоило бы обновлять ПИДы! Как бы до Алекс-париж докричаться? На форуме “там” по странице в час постят, уже плюнул следить.
кстатии для FPV чето инетерсное www.elenafrancesco.org/arduino/baroneosd/ - как я понял напрямую с ардуинки пихать циферки в PAL сигнал, без шилдов даже - еще одна штука, которо можно нагрузить лишнее ядро
А графическую информацию как ардуинка, осилит? Чтобы как у Олега горизонт был.
ну это я так… мечтаю, графику можно осилить (там в коде цифры битовыми масками идут), но гемора много и не факт что еще одно ядро не надо будет впиливать… но хотя бы циферки какие нибудь или как в старых добрых играх:
| _ |
| _ - |
| _ o |
| _ - |
косяк в режиме автоуровня
Вот Алекс жулик! при подаче мин. газа он принудительно дает мин. газ на регули, а ПИДы продолжают работать и неумолимо накручивают “усилие” на моторы, чтобы скомпенсировать перекос. Как бы натягивают тетиву лука.
В итоге, при включении газа из ждущего в рабочий, коптер “выстреливает” одной стороной. А я голову ломаю, чего на видео столько переворотов прямо с места!
Сейчас это можно обойти, взлетая в режиме гир и включая стабилизацию только в полете. Но не для того я чаку покупал111 😁
Буду думать дальше.
Зловредный участок кода привожу:
if ((rcData[THROTTLE]) < MINCHECK)
#ifndef MOTOR_STOP
motor[i] = MINTHROTTLE;
#else
motor[i] = MINCOMMAND;
#endif
Вот Алекс жулик! при подаче мин. газа он принудительно дает мин. газ на регули, а ПИДы продолжают работать и неумолимо накручивают “усилие” на моторы
Это в версии 1.7
при подаче мин. газа он принудительно дает мин. газ на регули, а ПИДы продолжают работать
if ((rcData[THROTTLE]) < MINCHECK)
#ifndef MOTOR_STOP
motor[i] = MINTHROTTLE;
MINCOMMAND = 0; // ??
#else
motor[i] = MINCOMMAND;
#endif
не тут, все гораздо хуже.
MINCOMMAND это дефайн 😃
=== added
Вот, нашел решение, работает отлично :
delta = gyroData[axis] - lastGyro[axis];
DTerm = (delta1[axis]+delta2[axis]+delta+1)*dynD8[axis]/3;
delta2[axis] = delta1[axis];
delta1[axis] = delta;
lastGyro[axis] = gyroData[axis];if ((rcData[THROTTLE]) < MINCHECK) errorAngleI[axis]=0; // prevents side jump during the transition from idle when in autolevel mode
axisPID[axis] = PTerm + ITerm - DTerm;
Переход к выравниванию стал очень плавный.
Может кто подскажет что за мозги?