ArduCopter Mega: порт на обычную Arduino (тестим)
Проблема медленного доплывания горизонта решена! Вес акселя в этом процессе был зажат.
Видимо в этом и было дело. Ща вот вспомнил, что пробовал на днях в DCM мультивии уменьшать вес акселя и получал тотже эффект доплывания, НО судя по всему это сделано в АС не просто так. Из личных наблюдений, аксель более чувствителен к вибрациям (нунчак по аналогу или bma020 в сравнении с гирой 3205). И видимо если уменьшить его вес в DCM, то углы будут высчитываться в основном на показаниях гиры, которая менее чувствительна к вибрациям.
В мультивии стабмоде так и не полетел в итоге (сегодня тестил на bma020), т.к. только дашь газку аксель сходит с ума и никакими предварительными калибровками не равняется, хотя в ГУИ при выключенных моторах красота!
Надо будет существенно увеличить GYR_CMPF_FACTOR и попробовать подлетнуть…
/* Set the Gyro Weight for Gyro/Acc complementary filter */
/* Increasing this value would reduce and delay Acc influence on the output of the filter*/
/* Default WMC value: 300*/
#define GYR_CMPF_FACTOR 310.0f
аксель более чувствителен к вибрациям
Да, он гораздо более шумный.
углы будут высчитываться в основном на показаниях гиры, которая менее чувствительна к вибрациям.
- Ровный полет: вес акселя =1
- полет с перегрузками (или вибрация): вес акселя -> 0 accel_weight = constrain(1 - 3 * fabs(1 - accel_magnitude), 0, 1);
Испытывал на оригинальной прошивке. Горизонт доплывает очень медленно (минуты) после кувыркания, если плата вибрирует.
Попробую вечером сохранить большой вес акселя, но жестко фильтровать его (accel_filtered). Еще в IMU надо покопать, там тоже какие-то ограничения есть.
kp_roll_pitch(0.05967) ki_roll_pitch(0.00001278) и error_roll_pitch тоже можно потестировать.
никто OSD от МегаПиратоСамолета не ковыряет щас? а то занятся, а друг уже есть =)
Глеб, а в чем заключается суть портирования? Изменения портов ввода вывода, или все гораздо сложней?
Потестил сегодня режим авто… эх нравится мне 40 портированная прошивка (тест8), РТЛ работает, полет по точкам работает, высоту держит! Вот ее бы портировать на самули а? Есть умельцы в русских селеньях 😃?
Кто нибудь пробовал использовать habrahabr.ru/blogs/DIY/125214/ (не реклама) заместо APC220? Сделал по инструкции к APC220 (поменял скорость) все подключилось но в планере показывает что плата повернута влево градусов на 190, хотя через юсб кабель нормально показывает. Прошивка родная (black vortex).
Подскажите что нужно изменить в MegaPirateNG_2.0.40_Test8 чтобы работал на black vortex?
Спасибо!
Посмотрите надцать страниц ранее. Или спросите Хатуля
Глеб, а в чем заключается суть портирования?
портирование OSD? или самого ArduCopter?
в OSD надо тупо поменять значения режимов (и для моей камерки с 420 линиями еще и сдвиги для блока с тестом и графикой, а то за пределы всё уходит), в ардукоптере сложнее: code.google.com/p/megapirateng/wiki/portmanual (кто-то пополет по мере пиления?)
Кто нибудь пробовал использовать habrahabr.ru/blogs/DIY/125214/ (не реклама) заместо APC220?
Я использовал, тока не помню, что бы у меня была разница с USB.
Это было бы отлично! По гире видно, что очень быстрые наклоны она не отрабатывает, кратковременные скачки не успевают захватиться и интегрироваться.
Вчера думал, куда же прикрутить INT Gyro… так и не придумал, т.к. походу все выводы, на которые можно повесить прерывание - заняты.
Еще можно задействовать INT Baro (как в оригинальном AC), для этого можно задйствовать любой цифровой вывод (которых полно свободных).
И еще, если тут есть специалисты в микроконтроллерах. Допустим мы подключим INT Gyro к одному из выводов и повесим на него прерывание. Как лучше организовать чтение значений гиры? Прямо в коде прерывания наверное нельзя… Видимо надо выставлять какой то флаг готовности и в основном цикле программы, вызывать чтение гиры как можно быстрее…? Но во втором случае, есть вероятность пропустить одну из итераций, т.к. у нас есть “медленный” код, который работает на частоте 50Hz…
UPD: Походу придумал - можно TX Sonar перенести на обычные цифровые выходы, а его пин задействовать для INT Gyro… сегодня попробую вечером 😃
Вчера думал, куда же прикрутить INT Gyro… так и не придумал, т.к. походу все выводы, на которые можно повесить прерывание - заняты.
Я думал сделать супер_быстрый цикл 1 кГц, в нем проверять флаг готовности. Gyro INT подать на d**. Если d** = 1, то считаем с гиры.
Нужно узнать время на считывания гиры и интегрирование, от этого задавать время сверх_быстрого цикла.
Как потом отдавать интегрированное значение в DCM ?
------------
Или в супер_быстром цикле 1 кГц проверять флаг готовности. Gyro INT подать на d**. Если d** = 1, то считаем с гиры, значение акселя берем старое, все это подаем в DCM.fast_update();
можно TX Sonar перенести на обычные цифровые выходы, а его пин задействовать для INT Gyro
А что вызывать в коде прерывания? readAHRS() ? Или считывать гиро и копить, потом отдавать в IMU ?
Или в супер_быстром цикле 1 кГц проверять флаг готовности. Gyro INT подать на d**. Если d** = 1, то считаем с гиры, значение акселя берем старое, все это подаем в DCM.fast_update()
DCM.fast_update можно не вызывать. Надо просто суммировать показания гиры, до следующего считывания DCM’ом (а он обновляется в fast_loop). Т.е. идея такая - в супер быстром цикле, проверяем флаг гиры, если установлен - считываем показания и суммируем с предыдущим (при этом запоминаем количество считываний). Далее, раз в 4ms (250Hz) идет fast_loop который в свою очередь обновляет IMU - а тот уже читает значения гиры. Отдаем просуммированные показания и Dt (количество циклов гиры (считанных) * период одного цикла) (сейчас Dt = 4000мкс).
Т.е. идея такая - в супер быстром цикле, проверяем флаг гиры, если установлен - считываем показания
Можно не трогать сонар, а просто повесить gyro_INT на цифровой вход. Только определиться с частотой super_fast_loop, чтобы гира гарантировано успела дать INT=1 и хватило времени проинтегрировать.
Можно не трогать сонар, а просто повесить gyro_INT на цифровой вход
Ну это смотря как его использовать. Если просто как флаг готовности, то да - этого достаточно, а если как прерывание, то его можно повестить только вместо сонара.
если как прерывание, то его можно повестить только вместо сонара.
жалко сонар трогать, придется потом не забывать править его код при портировании новой версии.
Кстати, гира якобы работает на 400кГц, она часто будет вызывать прерывания.
Кстати, гира якобы работает на 400кГц
Не, частота задается. В текущий момент там 250Hz стоит.
Всем привет. Тестил опять лойтер, не хочет он нормально работать и всё тут. Коптер беспорядочно летает в круге диаметром метров 50, не меньше. А хотелось бы чтобы было метров 5-10 хотя бы, видел что тут у многих именно так. На rcgroups у joebarteam вообще с последней версией держит в радиусе 1 метра. Пробовал крутить лойтер ПИДы, как-то особой разницы не заметно. Может у кого есть какие идеи, куда смотреть, где что крутить?
Есть мысли что это может быть из-за моего gps, который на i2c шине висит, там получилась немного меньшая частота отдачи данный. Кто-нибудь тестировал лойтер с gps модулем работающим через i2c?
Коптер беспорядочно летает в круге диаметром метров 50, не меньше.
имхо чето с GPS, например спутников мало или еще чего (код i2c вроде как всё еще тестовый) - в планере то нормально показывает положение?
Т.е. идея такая - в супер быстром цикле, проверяем флаг гиры, если установлен - считываем показания и суммируем с предыдущим (при этом запоминаем количество считываний).
V takom sluchae “bistrie” uskoreniya giri budut usrednyatsya i nichego novogo mi ne poluchim po idee, t.e. adekvatnogo povedeniya sistemi na bistrie izmenenia uglovih skorostey - boltanku t.e…
- dlya vseh etih eksperemntov v pervuyu ochered nado podnyat hardwarniy filter dlya giri, s 20Hz hotyabi do 256Hz…
V takom sluchae “bistrie” uskoreniya giri budut usrednyatsya i nichego novogo mi ne poluchim po idee, t.e. adekvatnogo povedeniya sistemi na bistrie izmenenia uglovih skorostey - boltanku t.e…
Если гира работает с меньшей частотой (250Hz), то мы просто не “увидим” то что гира повернулась на (например) 90гр. Т.к. у нее произойдет переполнение. Что бы этого не было, надо увеличить частоту гиры (Например 500Hz или 1KHz), тогда она станет чаще отдавать информацию и мы увидим поворот два раза по 45гр (или 22.5 для 1KHz). Суммирование нам даст 90гр при той же частоте fast_loop’a (250Hz).
итак, OSD, который писал Олег, но так и не добавил в коптерную версию прошивки
Спасибо SovGVD что взялись за адаптацию Олеговского OSD.
Давно уже лежит E-OSD прошитая прошивкой Олега.
Всё не как не мог дождаться, когда Олег освободит время и для нас.
Ну теперь благодаря Вам будем пробовать😁
Кто нить подскажите, чет запутался😵
Пока пробовал прошивки как работают в Планере, просмотрел а как у нас теперь включаются моторы?
имхо чето с GPS, например спутников мало или еще чего (код i2c вроде как всё еще тестовый) - в планере то нормально показывает положение?
Я то же думаю, что проблема в GPS. Алексей, у тебя есть какая нибудь телеметрия? Ну через APC/Xbee/Bluetooth? Тогда бы можно было в планере посмотреть, что творилось с координатами. Либо можно прикрутить SD карточку и писать лог на нее…
Давно уже лежит E-OSD прошитая прошивкой Олега.
мне бы только разобраться как компилить без avrstudio, используя только avg-gcc =))
V takom sluchae “bistrie” uskoreniya giri budut usrednyatsya i nichego novogo mi ne poluchim po idee, t.e. adekvatnogo povedeniya sistemi na bistrie izmenenia uglovih skorostey - boltanku t.e
Точно! +5 градусов -5 +5 -4 +6 -4 (super_fast_loop) = 0 (отдали в fast_loop)
Нужно в самом super_fast_loop вычислять матрицу DCM и отдавать команды моторам, по времени затратная процедура.
С другой стороны, просто суммируя в super_fast_loop, мы точнее получим итоговый угол наклона. Т.е. ошибка интегрирования будет меньше, потому что отчеты чаще.
в коде i2c itg3200:
i2c_write(0x4); // 7: 1000Hz/(4+1) = 250Hz .
1000Гц/5 = 200 Гц хм
Если поставить фильтр 256Гц, то Finternal = 8кГц вместо 1кГц. Попробую сейчас в быстром цикле опрашивать гиру и суммировать.