Специальные цены   новые товары
Закрытая тема
Страница 1 из 6 1 2 3 ... ПоследняяПоследняя
Показано с 1 по 40 из 236

MultiWii - обсуждаем и отлаживаем Alt Hold

Тема раздела Коптеры. Комплектующие, сборка, настройка. в категории Квадрокоптеры и мультироторы; Решил перенести обсуждение из ветки multiwii (начальное сообщение по этой теме - http://forum.rcdesign.ru/f123/thread...ml#post3125693...

  1. #1

    Регистрация
    23.08.2011
    Адрес
    Краснодар
    Возраст
    39
    Сообщений
    1,017
    Записей в дневнике
    2

    MultiWii - обсуждаем и отлаживаем Alt Hold

    Решил перенести обсуждение из ветки multiwii (начальное сообщение по этой теме - MultiWii

  2.  
  3. #2

    Регистрация
    11.01.2011
    Адрес
    Ярославль
    Возраст
    30
    Сообщений
    1,561
    http://habrahabr.ru/blogs/arduino/137595/ Использование инерциальной навигационной системы (ИНС) с несколькими датчиками на примере задачи стабилизации высоты квадрокоптера

    У вас с включенными моторами акселерометр не глючит (переполнение АЦП)?
    Я BMA180 настроил на 8G, 40Hz ФНЧ.

    Кстати, когда коптер движется ускоренно или по криволинейной траектории, то акселерометр дает больше\меньше, чем 1g ( sqrt(ax*ax+ay*ay+az*az) <> 1g*LSB ). Я пробовал компенсировать "лишний" вектор ускорения за счет скорости по GPS: ax -= omega_z * gps_speed_y; az += omega_x * gps_speed_y; Но тут косяк - предполагается, что ЛА летит осью Y вперед, и никак иначе. Но квадрик может двигаться боком (осью Х). А скорость по GPS не проецируется на конкретную ось.

  4. #3

    Регистрация
    13.03.2011
    Адрес
    Montreal, Canada
    Возраст
    39
    Сообщений
    2,299
    Записей в дневнике
    19
    Цитата Сообщение от alexmos Посмотреть сообщение
    попробую объяснить почему я откзалася от раздельных PI и PD. D в высоте - это производная ошибки, но данные о высоте у нас неточные и D от этих даных будет ещё хуже. Но производная ошибки - это и есть скорость (dErr = d(Hhold - H) = dHhold - dH = -dH), которую наш алгоритм худо-бедно выдает. То есть я просто обозвал P-составляющую скорости D-составляющей высоты, не изменив логики оригинальной версии, только PID высоты теперь стал классическим PID.
    pogodi... esli ishodnie dannie eto visota, to v terminah PID regulyatorov err eto izmenenie visoti, t.e. skorost' za dt cikla...
    err=h_hold-h
    a vot D sostavlyauschaya eto uzhe skorost' izmeneiya oshibki, t.e. uskorenie:
    D = dt(err - prev_err)

    primer: h0=0, h1=5, h2=12
    err1=5-0=5 (skorost' izmeneiya visoti za dt), err2=12-5=7 (skorost' izmeneiya za dt)
    D=(7-5)=2 (uskorenie za dt)

    t.e. eto uzhe ne klassik PID, a mix
    dlya spravki moih rassuzhdeniy http://pidcontrol.narod.ru/

    Цитата Сообщение от alexmos Посмотреть сообщение
    А VelocityPID остался только D - производная скорости, что по сути является ускорением. А так ли нужен этот компонент? Посмотри на график ускорения при любом линейном перемещении - это выброс вверх и равнозначный выброс вниз. Т.е. компенсация а короткий перод времени даст +100 а потом -100 - такое моторы даже не успеют отработать, а есть ещё инерция коптера. Так что смысла от D-скорости ноль.
    esli rassmotret' na primere wii level mode, to tam D eto kak raz uglovoe uskorenie, pravda usrednennoe za poslednie tri iteracii:
    Код:
    delta          = gyroData[axis] - lastGyro[axis];                               //16 bits is ok here, the dif between 2 consecutive gyro reads is limited to 800
        lastGyro[axis] = gyroData[axis];
        deltaSum       = delta1[axis]+delta2[axis]+delta;
        delta2[axis]   = delta1[axis];
        delta1[axis]   = delta;
     
        if (abs(deltaSum)<640) DTerm = (deltaSum*dynD8[axis])>>5;                       //16 bits is needed for calculation 640*50 = 32000           16 bits is ok for result 
                          else DTerm = ((int32_t)deltaSum*dynD8[axis])>>5;              //32 bits is needed for calculation
    I ya tozhe dolgo ne mog ponyat' zachem eto nuzhno esli vspleski simmetrichnie, no potom kazhetsya doper. Oni to simmetrichnie, NO ne po amplitude a po ploschadi, t.e. na razgon mozhet bit' narastayuschiy pologiy grafik, a na tormozheniye krutoy rezkiy pik, libo krutoy na razgon, no pologiy na tormozhenie... i glavnoe chto v level mode eto otlichno reguliruet skorost' raboti sistemi...

  5. #4

    Регистрация
    09.03.2010
    Адрес
    Киев - Мальта
    Возраст
    38
    Сообщений
    7,620
    Записей в дневнике
    5
    Александр, пользуйтесь пожалуйста транслитпереводчиком http://www.translit.ru/ а то мозг сломать можно.

  6.  
  7. #5

    Регистрация
    23.08.2011
    Адрес
    Краснодар
    Возраст
    39
    Сообщений
    1,017
    Записей в дневнике
    2
    Цитата Сообщение от mahowik Посмотреть сообщение
    to v terminah PID regulyatorov err eto izmenenie visoti, t.e. skorost' za dt cikla
    Нет, P - это ПРОПОРЦИОНАЛЬНАЯ составляющая, т.е. это и есть ошибка, без dT. P = err * kP, а D - это ДИФФЕРЕНЦИАЛЬНАЯ, D = derr/dt * kD

    Цитата Сообщение от mahowik Посмотреть сообщение
    esli rassmotret' na primere wii level mode, to tam D eto kak raz uglovoe uskorenie, pravda usrednennoe za poslednie tri iteracii
    Да, потому что в данном случае (в акрорежиме) стабилизируется скорость, а для нее D - это ускорение. Мы же стабилизируем высоту, а для нее D - это скорость.

    Цитата Сообщение от Musgravehill Посмотреть сообщение
    У вас с включенными моторами акселерометр не глючит (переполнение АЦП)? Я BMA180 настроил на 8G, 40Hz ФНЧ
    Нет, не глючит. У меня хорошая виброразвязка, но я тоже включил 8G (его включили в версии 1.9, я просто взял последние изменения). Для моего алгоритма переполнений по оси Z быть не должно, это важно!


    Цитата Сообщение от Musgravehill Посмотреть сообщение
    Я пробовал компенсировать "лишний" вектор ускорения за счет скорости по GPS

    Господи, зачем такие сложности?? Просто спроектируйте его на вектор ориентации (у меня в статье этот момент расписан). У вас останется только вертикальное ускорение при любой ориентации аппарата и любом горизонтальном ускорении. Есть пара тонкостей: я в своих исходниках более точно выставлил 0 гир и уменьшил влияние на них акселеромтера, чтобы ориентация была как можно точнее.

  8. #6

    Регистрация
    13.03.2011
    Адрес
    Montreal, Canada
    Возраст
    39
    Сообщений
    2,299
    Записей в дневнике
    19
    Цитата Сообщение от cylllka Посмотреть сообщение
    Александр, пользуйтесь пожалуйста транслитпереводчиком http://www.translit.ru/ а то мозг сломать можно.
    polzovalsya ranee, no za neimeniem vremeni na rabote i chtobi menshe svetit' raznocvetnim ekranom translit.ru budo postit' tak... potomu sorry ))

    Цитата Сообщение от alexmos Посмотреть сообщение
    Да, потому что в данном случае (в акрорежиме) стабилизируется скорость, а для нее D - это ускорение. Мы же стабилизируем высоту, а для нее D - это скорость.
    ya pisal pro stab/level mode s ego PI-PD regulyatorom, gde konechnaya cel' stabilizaciya ugla, v chem PD regulyator s ishodnoy "uglovaya skorost" kak raz i daet uverennuyu stabilizaciyu... libo visoti v sluchae alt hold...

  9. #7

    Регистрация
    23.08.2011
    Адрес
    Краснодар
    Возраст
    39
    Сообщений
    1,017
    Записей в дневнике
    2
    Хорошо, не буду спорить - возможно, D в скорости действительно нужен. Любая теория может быть опровергнута практикой
    Я специально вынес accZ в глобалные переменные чтобы не считать его "задом наперед" в пид-регуляторе. Умножь на acсZ на kD и проведи тесты

    Кстати, я никогда не сморел как устроен ПИД-регулятор углов. Какого хрена там D часть считается от ускорения, может в level-mode его есть смысл считать как раз от скорости изменения угла??? Получается, мы исполуьзем угол, интеграл угла, и ускорение (притом видно, что оно не очень хорошо себя вело, т.к. используется двойное сглаживание) . Но полностью игнорируем угловую скорость, а ведь она не такая шумная. Надо попробовать, может станет ещё стабильней
    Последний раз редактировалось alexmos; 08.02.2012 в 03:43.

  10.  
  11. #8

    Регистрация
    13.03.2011
    Адрес
    Montreal, Canada
    Возраст
    39
    Сообщений
    2,299
    Записей в дневнике
    19
    Цитата Сообщение от alexmos Посмотреть сообщение
    Нет, P - это ПРОПОРЦИОНАЛЬНАЯ составляющая, т.е. это и есть ошибка, без dT. P = err * kP, а D - это ДИФФЕРЕНЦИАЛЬНАЯ, D = derr/dt * kD
    tak, nado polomat' libo moe predstavlenie o klassik PID, libo tvoe
    esli abstragirovat'sya ot koeficientov regulyatora i rassmatrivat' odnu iteraciyu, to D budet propocionalna dvoynomu differencialu vhodnih dannih, gde:
    - perviy diff eto ERROR
    - vtoroy diff eto (ERROR - prev_ERROR)

    v etom legko ubedit'sya esli na vhod podat' k primeru rasstoyanie (ili ugol), to v GUI uvidish' uskorenie (libo uglovoye uskorenie), t.e. raznopolyarnie vspleski...
    vot prostoy primer iz wikipedii:
    Код:
    previous_error = setpoint - process_feedback
    integral = 0
    start:
      wait(dt)
      error = setpoint - process_feedback
      integral = integral + (error*dt)
      derivative = (error - previous_error)/dt
      output = (Kp*error) + (Ki*integral) + (Kd*derivative)
      previous_error = error
      goto start
    Цитата Сообщение от alexmos Посмотреть сообщение
    Любая теория может быть опровергнута практикой
    vot eto tochno! inogda po grafikam vse nu tak krasivo!

  12. #9

    Регистрация
    13.03.2011
    Адрес
    Montreal, Canada
    Возраст
    39
    Сообщений
    2,299
    Записей в дневнике
    19
    вот блин! короче на работе надо работать, а не в прерывании думу думать... пока ехал домой, все понял
    сорри за путаницу с дифференциалами... все верно Д это скорость, при исходной "высота"... и главное что примерно пол года назад я с этим довольно досконально разобрался :
    MultiWii
    MultiWii
    MultiWii
    MultiWii
    MultiWii

    Цитата Сообщение от alexmos Посмотреть сообщение
    Кстати, я никогда не сморел как устроен ПИД-регулятор углов. Какого хрена там D часть считается от ускорения, может в level-mode его есть смысл считать как раз от скорости изменения угла??? Получается, мы исполуьзем угол, интеграл угла, и ускорение (притом видно, что оно не очень хорошо себя вело, т.к. используется двойное сглаживание) . Но полностью игнорируем угловую скорость, а ведь она не такая шумная. Надо попробовать, может станет ещё стабильней
    так там в PD части, комплексного PI-PD регулятора, скорость и используется для P, а ускорение для D части, которое сложновато понять, но именно оно задает скорость-плавность системы...
    Код:
    if (abs(gyroData[axis])<160) PTerm -=          gyroData[axis]*dynP8[axis]/10/8; //16 bits is needed for calculation   160*200 = 32000         16 bits is ok for result
                                else PTerm -= (int32_t)gyroData[axis]*dynP8[axis]/10/8; //32 bits is needed for calculation   
    
        delta          = gyroData[axis] - lastGyro[axis];                               //16 bits is ok here, the dif between 2 consecutive gyro reads is limited to 800
        lastGyro[axis] = gyroData[axis];
        deltaSum       = delta1[axis]+delta2[axis]+delta;
        delta2[axis]   = delta1[axis];
        delta1[axis]   = delta;
     
        if (abs(deltaSum)<640) DTerm = (deltaSum*dynD8[axis])>>5;                       //16 bits is needed for calculation 640*50 = 32000           16 bits is ok for result 
                          else DTerm = ((int32_t)deltaSum*dynD8[axis])>>5;              //32 bits is needed for calculation
    т.е. там используется и угол, и интеграл угла, и скорость, и ускорение...
    Последний раз редактировалось mahowik; 08.02.2012 в 06:48.

  13. #10

    Регистрация
    23.08.2011
    Адрес
    Краснодар
    Возраст
    39
    Сообщений
    1,017
    Записей в дневнике
    2
    Хорошо что разобрались. Я гляну еще код, может и правда недоглядел. А ускорение в альт холд попробую включить, чисто ради интереса. К субботе вроде у нас погода нормализуется, попробую полетать.

  14. #11

    Регистрация
    23.08.2011
    Адрес
    Краснодар
    Возраст
    39
    Сообщений
    1,017
    Записей в дневнике
    2
    Александр, а когда в режиме Alt Hold из состояния висения начать двигаться вперед, куда уносит коптер - вверх или вниз?

  15. #12

    Регистрация
    13.03.2011
    Адрес
    Montreal, Canada
    Возраст
    39
    Сообщений
    2,299
    Записей в дневнике
    19
    Цитата Сообщение от alexmos Посмотреть сообщение
    а когда в режиме Alt Hold из состояния висения начать двигаться вперед, куда уносит коптер - вверх или вниз?
    сорри... не помню

    кстать попробовал корректировать высоту по высоте из баро в комплиментарном фильтре, т.е. заменил это
    Код:
      // Integrator - altitude, cm  
      alt+= vel * cycleTime * VEL_SCALE;
    
       // Apply ACC->BARO complementary filter
      alt-= err;
    на это
    Код:
      alt += vel * cycleTime/1000000.0f;
      alt = (alt*ACC_BARO_CMPF + sensorAlt)/(ACC_BARO_CMPF+1);
    визуально вроде как стало меньше шумов в alt и vel... в принципе логично т.к. ошибка (alt - sensorAlt) больше шумит, чем просто sensorAlt, т.к. в ошибке шум не только баро, но и акселя...

    Также заметил что при движении с постоянной вертикальной скоростью, показания скорости в гуи угасают, т.к. видимо, пид пытается свести скорость к нулю. Однако в динамике при быстрых изменениях отрабатывает отлично... потому не критично наверное...
    Код:
    vel+= (accZ - err*ACC_BARO_P - vel*ACC_BARO_D) * cycleTime * accScale;
    Смотрел в гуи, что дает ускорение в Д состовляющей (по гирам)... увидел значительное увеличение крутизны пика управляющего воздействия на выходе... т.е. в алт холд пид регуле ускорение по идее точно не будет лишним, тем более что если коптер покое, то оно сидит себе в нуле и не шумит как скорость...

    по поводу улучшайзеров:
    1. было бы неплохо думаю поставить фильтр на сырые значения баро... читал что для баро сенсора медиан лучше всего...
    2. думаю есть смысл поставить велосити деадбенд на выходе из иму, т.к. велосити шумит ~ в диаппазоне +/-10..15


    з.ы. на офф. форуме опять активировались с альт. холдом. Кто первый?!
    http://www.multiwii.com/forum/viewto...start=50#p8508
    http://www.multiwii.com/forum/viewto...t=363&start=80
    чел стенд смастерил
    пишет что можно теперь алгоритмы в реалтайме через матлаб. тестить!

  16. #13

    Регистрация
    23.08.2011
    Адрес
    Краснодар
    Возраст
    39
    Сообщений
    1,017
    Записей в дневнике
    2
    Цитата Сообщение от mahowik Посмотреть сообщение
    кстать попробовал корректировать высоту по высоте из баро в комплиментарном фильтре, т.е. заменил это
    Это я применил небольшую оптимизацию, чтобы не дублировать "тяжелы" умноженя и деления. На самом деле твоя фомула и моя совершенно одинаковы, это в обоих случаях комплементарный фильтр. Я проверил, одна формула сводится к другой раскрытием скобок.

    Цитата Сообщение от mahowik Посмотреть сообщение
    Также заметил что при движении с постоянной вертикальной скоростью, показания скорости в гуи угасают

    Ага, так и должно быть - это работает D-составляющая, она "гасит" скорость. Поэтому я её взял очень небольшую, и осциляции она гасит медленно. Но совсем без нее нелзя, иначе уйдет в раскачку.


    Цитата Сообщение от mahowik Посмотреть сообщение
    Смотрел в гуи, что дает ускорение в Д состовляющей (по гирам)... увидел значительное увеличение крутизны пика управляющего воздействия на выходе... т.е. в алт холд пид регуле ускорение по идее точно не будет лишним, тем более что если коптер покое, то оно сидит себе в нуле и не шумит как скорость...
    Пока трудно представить ситуацию, чтобы ускорение "резко" рвануло при удержании высоты. А при плавных возмущенях, каковые в основном и наод держать - шумом в ускорении все же нельзя пренебрегать, он становится сравним с измеряемой величиной. Поэтому я и против привлечения ускорения в PID-регулятор - только лишние дергания для моторов.

    В удержании угла то же самое - если ставить высокий D на ROLL и PITCH - начинается кобасня на выходах мотров. И хотя это незаметно и они по прежнему стабилизируют хорошо, все же мне кажется что текущее решене неправильное - не нужно учитывать ускорение в PID регуляторе. И по теории не нужно, и логика это подсказывает.

    Цитата Сообщение от mahowik Посмотреть сообщение
    1. было бы неплохо думаю поставить фильтр на сырые значения баро... читал что для баро сенсора медиан лучше всего...

    Попробуй сделать. Вполне допускаю, что комплементарный фильтр не самый лучший для барометра. У меня времени нет сейчас, и не охота пока усложнять алгоритм - уже и так слишком много теории, хочется попрбовать сначала, что текущее решение дает.


    Цитата Сообщение от mahowik Посмотреть сообщение
    думаю есть смысл поставить велосити деадбенд на выходе из иму, т.к. велосити шумит ~ в диаппазоне +/-10..15

    Не, ни в коем случае. Если она шумит вокруг 0, то в сумме и так управляющее воздействие 0. Да и работать она должна именно вокруг 0, т.к. по alt у нас все плавно (если исключить "тестовые" рывки "на камеру" А deadband внесет такую нелинейность что последсвия трудно даже спрогнозировть..

    Стэнд - это круто Ме хватило рук, чтобы висение отладить Я думаю они к таким же резултатм придут: при висении точность определит только барометр. А вот при полетах, вот тут сложнее и инетреснее. И стэнд особо не поможет

    Судя по видео и резким скачкам вверх вниз без видимой прчины, пока не все гладко
    Последний раз редактировалось alexmos; 09.02.2012 в 18:07.

  17. #14

    Регистрация
    23.08.2011
    Адрес
    Краснодар
    Возраст
    39
    Сообщений
    1,017
    Записей в дневнике
    2
    Ещё сделал мелкую доработку: коррекция газа при наклоне аппарата THROTTLE_ANGLE_CORRECTION, чтобы вертикальная составляющая осталась неизменной. Это должно помочь не терять высоту при начале движения. Работает только в stable mode. Возможно придется умножить на понижающий коэффициент, т.к. не уверен в линейной зависимости газа и косинуса угла.
    Код на SVN http://code.google.com/p/multiwii-al...runc/MultiWii/, НЕ ТЕСТИРОВАЛСЯ.

  18. #15

    Регистрация
    11.01.2011
    Адрес
    Ярославль
    Возраст
    30
    Сообщений
    1,561
    Попробовал такой алгоритм:

    Код:
    acc_delta_alt = 9.8 * (az/LSB  -1) * cycleTime * cycleTime;  // 9.8  * az [м\с2] * dT *dT =acc_delta_alt [ м ]
    Altitude = 0.85f * Altitude + 0.15f * alt_baro + acc_delta_alt;
    Фигня получается. Высота скачет как и раньше с баро_только. И приращения acc_delta_alt, похоже, частично теряются, не успевает складывать..
    Последний раз редактировалось Musgravehill; 09.02.2012 в 23:46.

  19. #16

    Регистрация
    23.08.2011
    Адрес
    Краснодар
    Возраст
    39
    Сообщений
    1,017
    Записей в дневнике
    2
    Цитата Сообщение от Musgravehill Посмотреть сообщение
    9.8 * az [м\с2] * dT *dT
    это у вас не двойное интегрироавние, потому и высота не выходит. И так просто как вых написали, проблему не решить

  20. #17

    Регистрация
    13.03.2011
    Адрес
    Montreal, Canada
    Возраст
    39
    Сообщений
    2,299
    Записей в дневнике
    19
    Цитата Сообщение от alexmos Посмотреть сообщение
    Это я применил небольшую оптимизацию, чтобы не дублировать "тяжелы" умноженя и деления. На самом деле твоя фомула и моя совершенно одинаковы, это в обоих случаях комплементарный фильтр. Я проверил, одна формула сводится к другой раскрытием скобок.
    то что и там и там CF это понятно... раскрыл скобки... в оптимизированной версии результат получатся меньше на alt/ACC_BARO_CMPF, который в след-й итерации увеличит ошибку на эту величину по идее
    Код:
    ALT = alt *(1.0f - 1.0f/ACC_BARO_CMPF) - err = 
     alt *(1.0f - 1.0f/ACC_BARO_CMPF) - (alt - sensorAlt)/ACC_BARO_CMPF = 
     alt - alt/ACC_BARO_CMP - alt/ACC_BARO_CMP + sensorAlt/ACC_BARO_CMPF =
     (alt*ACC_BARO_CMP - alt*2 + sensorAlt)/ACC_BARO_CMPF=
     (alt*(ACC_BARO_CMP - 2) + sensorAlt)/ACC_BARO_CMPF
     что равносильно (alt*(ACC_BARO_CMP - 1) + sensorAlt)/(ACC_BARO_CMPF + 1)
    Цитата Сообщение от alexmos Посмотреть сообщение
    Пока трудно представить ситуацию, чтобы ускорение "резко" рвануло при удержании высоты. А при плавных возмущенях, каковые в основном и наод держать - шумом в ускорении все же нельзя пренебрегать, он становится сравним с измеряемой величиной. Поэтому я и против привлечения ускорения в PID-регулятор - только лишние дергания для моторов. В удержании угла то же самое - если ставить высокий D на ROLL и PITCH - начинается кобасня на выходах мотров. И хотя это незаметно и они по прежнему стабилизируют хорошо, все же мне кажется что текущее решене неправильное - не нужно учитывать ускорение в PID регуляторе. И по теории не нужно, и логика это подсказывает.
    я тоже сперва так думал и писал что по логике приведет к осцилляциям... по ссылкам выше размышлизмы один в один MultiWii - обсуждаем и отлаживаем Alt Hold

    за "Д" они принимают дифференциал угловой скорости - т.е. угловое ускорение, как для акро так и для стаб.мода., а должен быть на крайняк дифференциал изменения угла - т.е. угловая скорость... Вывел графики ПИД-ов в ГУИ, занулил "П" и "И", так и есть "Д" у них - это угловое ускорение... В итоге по теории это может привести лишь к лишним осциляциям, т.к. это добавит компенсацию/всплеск не только в нужную полярность, а также и в противоположную...


    соот-но попробовал убирать PD (по скорости) и добавлять D (по углу) к PI в различных вариациях (усредненное 3-х последних скоростей; либо принимая угловую скорость гиры за D и т.д ) MultiWii
    сам тестил + помоШника нашел (хороший пилот)... не полетело в итоге... раскачки, осцилляции, ломанные винты...
    В теории просто ПИД хорош беспорно и главное понятен, а вот на практике не хватает его для устойчивой стабилизации ЛА, потому и используют комплексные ПИД регули думаю...

    Цитата Сообщение от alexmos Посмотреть сообщение
    Попробуй сделать. Вполне допускаю, что комплементарный фильтр не самый лучший для барометра. У меня времени нет сейчас, и не охота пока усложнять алгоритм - уже и так слишком много теории, хочется попрбовать сначала, что текущее решение дает.
    ну я говорил не про замену CF на медиан, а про предварительную фильтрацию данных с барометра медианом или для начала обычный НЧ попробовать поставить...
    Последний раз редактировалось mahowik; 10.02.2012 в 08:29.

  21. #18

    Регистрация
    23.08.2011
    Адрес
    Краснодар
    Возраст
    39
    Сообщений
    1,017
    Записей в дневнике
    2
    Цитата Сообщение от mahowik Посмотреть сообщение
    в оптимизированной версии результат получатся меньше на alt/ACC_BARO_CMPF
    если так, то получается высота просто стремится к 0 всегда, и такой дампиг не оправдан ничем. CMPF её скорректирует конечно но зачем?


    Цитата Сообщение от mahowik Посмотреть сообщение
    сам тестил + помоШника нашел (хороший пилот)... не полетело в итоге... раскачки, осцилляции, ломанные винты...
    Ясно, спасибо за иныу. Интересно самому попробовать, т.к. если это действительно необходимо для углов, то тогда и высоте может помочь.
    В стабилизации высоты все же другие и цели, и исходные данные. Там очень точные показания гиро, высокая скорость "исполнительнго механимза", и задача убрать мелкие раскачивания. А в высоте - постоянный низкочастотный шум +-1м и слабая коррекция на движки, т..е все на-амного медленнее.


    Цитата Сообщение от mahowik Посмотреть сообщение
    ну я говорил не про замену CF на медиан, а про предварительную фильтрацию данных с барометра медианом или для начала обычный НЧ попробовать поставить...
    Обычный НЧ уже есть посредтсвом CMPF. Медианный - думаю ничего не даст кроме усложения вычислений. Мы же ставим дотстаточно высокий k фильтра CMPF и фактически задавливаем все шумы барометра..

    Вот что подкинул ziss_dm: http://www.icee-con.org/papers/2006/pdf/EC2-08.pdf Как я понял, отличия от моего алгоритма в LPF-фильтре 3-его порядка, т.е. повышении крутизны спада АЧХ (если говорить в терминах электроники). Но там слишком много математики, может позже разберусь. И у меня PID-регулятор, а что там не понял.
    Последний раз редактировалось alexmos; 10.02.2012 в 14:13.

  22. #19

    Регистрация
    13.03.2011
    Адрес
    Montreal, Canada
    Возраст
    39
    Сообщений
    2,299
    Записей в дневнике
    19
    Цитата Сообщение от alexmos Посмотреть сообщение
    если так, то получается высота просто стремится к 0 всегда, и такой дампиг не оправдан ничем
    тогда нужно добавить alt/ACC_BARO_CMPF, т.е. alt-=err; поменять на
    alt-= err - alt/ACC_BARO_CMPF;

    Цитата Сообщение от alexmos Посмотреть сообщение
    если это действительно необходимо для углов, то тогда и высоте может помочь. В стабилизации высоты все же другие и цели, и исходные данные. Там очень точные показания гиро, высокая скорость "исполнительнго механимза", и задача убрать мелкие раскачивания. А в высоте - постоянный низкочастотный шум +-1м и слабая коррекция на движки, т..е все на-амного медленнее.
    нужно пробовать вобщем... практика покажет...
    хотя в реализации алт-холд от ziss_dm ето уже проверено и успешно работает по отзывам многих, правда там ускорение из скорости высчитывается, а не берется из оси Z акселя...

    Цитата Сообщение от alexmos Посмотреть сообщение
    Обычный НЧ уже есть посредтсвом CMPF. Медианный - думаю ничего не даст кроме усложения вычислений. Мы же ставим дотстаточно высокий k фильтра CMPF и фактически задавливаем все шумы барометра.
    пробовал вчера добавить НЧ фильтр с высоким фактором (0.3-0.5гц) на сырые данные баро... палка о двух концах... шума стало заметно меньше в альт, но скорость гораздо медленее восстанавливается, а это совсем не плюс для стабилизации в пид регуле...

    Цитата Сообщение от alexmos Посмотреть сообщение
    Вот что подкинул ziss_dm
    осторожно! а то можно и мосК сломать!
    ziss таким образом устраняет конкурентов

    p.s. кстать errI в вычислении accZ плавно но верно корректирует дрейф... спецом пробовал вносить ошибку некорректной калибровкой акселя...
    работает, но не могу до конца понять каким образом... интуитивно вроде как эффект обратной связи получется? можешь нарисовать на палцах? или тут если формулами не расписать то не понять? ну или как ты это понял?
    Последний раз редактировалось mahowik; 11.02.2012 в 04:00.

  23. #20

    Регистрация
    23.08.2011
    Адрес
    Краснодар
    Возраст
    39
    Сообщений
    1,017
    Записей в дневнике
    2
    Удалось полетать сегодня, в целом резултаты нормальные, но есть куда двигаться. Видео надо подрезать и выложу позже. И сегодня же вживую пощупал Parrot ADrone -да, это культурнй шок. ТАКОЙ стабилизации по высоте мне вряд ли добиться

    Цитата Сообщение от mahowik Посмотреть сообщение
    p.s. кстать errI в вычислении accZ плавно но верно корректирует дрейф... спецом пробовал вносить ошибку некорректной калибровкой акселя...
    Ну собственно в этом и смысл алгоритма - найти "нулевую точку" акселя при помощи барометра, и далше показаня брать с акселя. Я уже писал, что таким образом решаются все проблемы с вибрационным дрейфом, температурным и т.д. акселя, и его показания можно уже рассматривать всерьез. В статье я как раз и объяснял как это решается, подробнее уже вряд ли объясню


    Цитата Сообщение от alexmos Посмотреть сообщение
    Ещё сделал мелкую доработку: коррекция газа при наклоне аппарата THROTTLE_ANGLE_CORRECTION, чтобы вертикальная составляющая осталась неизменной. Это должно помочь не терять высоту при начале движения. Работает только в stable mode. Возможно придется умножить на понижающий коэффициент, т.к. не уверен в линейной зависимости газа и косинуса угла.
    Попробовал и это включить, не сработало. COS угла не отражает реланый спад подъемной силы при начале движения, он намного больше. Видимо, происходит сход со струи или какие то более сложные процессы, чем простой наклон вектора тяги. Если кто сталкивался с теоретическими или практическими исследованями в этой области, подскажите. Можно конечно подобрать коэффициент эксперементально, но не с моими возможностями по полетам

  24. #21

    Регистрация
    11.01.2011
    Адрес
    Ярославль
    Возраст
    30
    Сообщений
    1,561
    Такой код дает довольно быструю реакцию на ускорение, по баро сглаживает. Акселерометр дает 2 всплеска противоположного знака при разгоне и торможении. В нештатной ситуации скорость acc_velocity, рассчитанная по изменению итоговой высоты, начинает принимать экстремальные значения, система идет вразнос.

    Код:
                                                 //суммируем скорости на промежутках времени cycleTime для поиска средней скорости
      acc.readAccel(&ax,&ay,&az); 
      acc_velocity +=  9.80665f * cycleTime * (az - calib)/LSB;   
      acc_i ++;
    
                               //неспешно (зачем лишний шум) опрашиваем баро, суммируем для нахождения среднего: симметричные значения уничтожаются.
    baro_loop +=cycleTime;
     if (baro_loop > 0.05) //sec 
    {
         dps.getAltitude(&baro_alt);
         baro_alt_sum += baro_alt;
         baro_i++;
         baro_time =0;
    }           
      
                  //Alt_loop медленный цикл, позволяет усреднить скорость по акселю и найти среднюю высоту по барометру (успеваем накопить данные)
      alt_loop += cycleTime;  
      if (alt_loop > 0.5)  //sec 
    {     
         Altitude = 0.15f * Altitude + 0.85f * baro_alt_sum/baro_i + alt_loop * acc_velocity / acc_i;   
         Serial.println(Altitude, DEC);
         
         baro_alt_sum = 0;
         baro_i   = 0;
         acc_i =0;
         alt_loop =0;
    
                         //начальная скорость для нахождения средней по акселю - рассчитывается по изменению высоты (с учетом баро и акселя)
          acc_velocity =  (Altitude - Altitude_prev) / alt_loop;
          Altitude_prev = Altitude;    
    }

  25. #22

    Регистрация
    31.12.2011
    Адрес
    Днепропетровск, украина
    Возраст
    33
    Сообщений
    804
    Господа, извините что вмешиваюсь, от понимания кода совершенно далек, просто возникла мысль из ряда "а что будет если?".
    Так вот, что если взять два bmp085,или любые другие, и из данных получаемых одновременно выделить "среднее арифметическое",?
    Возможно , как минимум проблему с"мусором" от части получится сгладить.

  26. #23

    Регистрация
    13.03.2011
    Адрес
    Montreal, Canada
    Возраст
    39
    Сообщений
    2,299
    Записей в дневнике
    19
    Цитата Сообщение от alexmos Посмотреть сообщение
    пощупал Parrot ADrone -да, это культурнй шок. ТАКОЙ стабилизации по высоте мне вряд ли добиться
    както читал про него... вроде там open source... или только SDK к нему в открытых кодах... а если и сорсы открыты, то можно почерпнуть...

    Цитата Сообщение от alexmos Посмотреть сообщение
    Ну собственно в этом и смысл алгоритма - найти "нулевую точку" акселя при помощи барометра, и далше показаня брать с акселя. Я уже писал, что таким образом решаются все проблемы с вибрационным дрейфом, температурным и т.д. акселя, и его показания можно уже рассматривать всерьез. В статье я как раз и объяснял как это решается, подробнее уже вряд ли объясню
    статью конечно же читал... и не просто читал, а внимательно вникал...
    интуитивно стало понятно, но математически на пальцах не получается понять каким образом именно интеграл ошибки становится корректирующей величиной проекции вектора ускорения...

    Цитата Сообщение от alexmos Посмотреть сообщение
    COS угла не отражает реланый спад подъемной силы при начале движения, он намного больше.
    я это понимаю так: тут уже скорее всего аэродинамика вход идет... при движении с горизонтальной скоростью, каждый из винтов типа "крыло" со своей подъемной силой, а в начале движения этой подъемной силы нет соот-но... теперь остается это расчитать

    Цитата Сообщение от Dimm168pin Посмотреть сообщение
    что если взять два bmp085,или любые другие, и из данных получаемых одновременно выделить "среднее арифметическое",? Возможно , как минимум проблему с"мусором" от части получится сгладить.
    ради эксперимента можно попробовать, но как по мне так уже лучше сразу взять MS5611-01, тогда и в сонаре надобность отпадет
    http://www.ebay.com/itm/MS5611-01-MS...item3cbe5d6b34
    да и цена 30$... bmp085 брал за 20...
    Последний раз редактировалось mahowik; 12.02.2012 в 07:59.

  27. #24

    Регистрация
    13.03.2011
    Адрес
    Montreal, Canada
    Возраст
    39
    Сообщений
    2,299
    Записей в дневнике
    19
    как я уже писал, мысль-идея-решение витает в воздухе в параллели... http://www.multiwii.com/forum/viewto...3&p=8871#p8840

  28. #25

    Регистрация
    19.01.2012
    Адрес
    Киев, украина
    Возраст
    63
    Сообщений
    253
    Цитата Сообщение от alexmos Посмотреть сообщение
    Удалось полетать сегодня, в целом резултаты нормальные, но есть куда двигаться. Видео надо подрезать и выложу позже. И сегодня же вживую пощупал Parrot ADrone -да, это культурнй шок. ТАКОЙ стабилизации по высоте мне вряд ли добиться

    Попробовал и это включить, не сработало. COS угла не отражает реланый спад подъемной силы при начале движения, он намного больше. Видимо, происходит сход со струи или какие то более сложные процессы, чем простой наклон вектора тяги. Если кто сталкивался с теоретическими или практическими исследованями в этой области, подскажите. Можно конечно подобрать коэффициент эксперементально, но не с моими возможностями по полетам
    Я решил эту проблему при помощи сонара. Добавил в газ производную от высоты по сонару (дифф. составляющая) и проваливаться перестал. В Parrot ADrone стоит сонар, так что не удивительно. Сейчас занимаюсь такой же проблемой, но на другой платформе High end Low cost Quatrocopter . Решение этой проблемы существенно должно упростится при наличии хорошего барометра. Я взял MS5611 , читаю с него данные с частотой 100 Гц . Далее буду усреднять комплиментарным фильтром с добавкой акселерометра. Скорость рассчитанную из данных акселерометра отфильтруем ФВЧ и это должно решить проблему накопления и ошибки по скорости. До конца не доходит идея с векторным произведением (статья с Хабра) . Мне казалось , что если разделить Az акселерометра на Cos (крена) и Cos(тангажа) то получим нужную составляющую? Или я не прав?

  29. #26

    Регистрация
    11.01.2011
    Адрес
    Ярославль
    Возраст
    30
    Сообщений
    1,561
    Цитата Сообщение от igor_v_t Посмотреть сообщение
    Скорость рассчитанную из данных акселерометра отфильтруем ФВЧ и это должно решить проблему накопления и ошибки по скорости.
    После расчета высоты (с учетом барометра) скорость "acc_velocity" корректирую :
    Код:
     acc_velocity =  (Altitude - Altitude_prev) / alt_loop;

  30. #27

    Регистрация
    19.01.2012
    Адрес
    Киев, украина
    Возраст
    63
    Сообщений
    253
    Цитата Сообщение от Musgravehill Посмотреть сообщение
    После расчета высоты (с учетом барометра) скорость "acc_velocity" корректирую :
    Код:
     acc_velocity =  (Altitude - Altitude_prev) / alt_loop;
    А я просто умножал ее на 0.995 . Такой себе ФВЧ с частотой среза 1 Гц. Длительность цикла 5 миллисекунд.

  31. #28

    Регистрация
    19.01.2012
    Адрес
    Киев, украина
    Возраст
    63
    Сообщений
    253
    Accel_2 = Accel_2 + (float)(accel_Z / DCM_Matrix[2][2]-Accel_2)/500.0;
    delta_A = (float)(accel_Z / DCM_Matrix[2][2] -Accel_2)*0.00204035;
    Speed_A = Speed_A*0.99 + delta_A * G_Dt;
    H_A = H_A + Speed_A*G_Dt + (Baro_alt - Baro_graund - H_A)* 0.1 ;

    Вот такой код где DCM_Matrix[2][2] = Cos (крена) х Cos(тангажа)
    Нажмите на изображение для увеличения
Название: Baro.jpg
Просмотров: 20
Размер:	43.5 Кб
ID:	603112
    Все на столе. Поднимаю на уровень монитора ноутбука На втором подъеме качаем по крену и тангажу градусов на 30 . Потом несколько раз поднимаем. Высота в метрах. 0.1 сек на деление

    Усреднили ускорение по 10 измерениям и баро по 50
    Accel_2 = Accel_2 + (float)(accel_Z / DCM_Matrix[2][2]-Accel_2)/500.0;
    delta_A = (float)(accel_Z / DCM_Matrix[2][2] -Accel_2)*0.00204035;

    delta_A_midd = delta_A_midd + (delta_A - delta_A_midd)*0.1;

    Speed_A = Speed_A*0.99 + delta_A_midd * G_Dt;

    H_A = H_A + Speed_A*G_Dt + (Baro_alt - Baro_graund - H_A)* 0.02 ;

    Нажмите на изображение для увеличения
Название: Baro-2.jpg
Просмотров: 13
Размер:	38.3 Кб
ID:	603152
    Измерения в течении одной минуты.Высота по баро уплыла на20 см. На плоской вершине качали с углами больше 60 град.
    Последний раз редактировалось igor_v_t; 12.02.2012 в 18:35.

  32. #29

    Регистрация
    13.03.2011
    Адрес
    Montreal, Canada
    Возраст
    39
    Сообщений
    2,299
    Записей в дневнике
    19
    Цитата Сообщение от Musgravehill Посмотреть сообщение
    После расчета высоты (с учетом барометра) скорость "acc_velocity" корректирую :
    Код:
     acc_velocity =  (Altitude - Altitude_prev) / alt_loop;
    Я тоже так пробовал. Но при низком времени цикла 3мс,шумит сильно...т.е. шумит высота а разность на малом dt тем более.

  33. #30

    Регистрация
    23.08.2011
    Адрес
    Краснодар
    Возраст
    39
    Сообщений
    1,017
    Записей в дневнике
    2
    Цитата Сообщение от mahowik Посмотреть сообщение
    на пальцах не получается понять каким образом именно интеграл ошибки становится корректирующей величиной проекции вектора ускорения...
    Потому что ошибка от барометра идет постоянно, и ускорение корректируем постояно, но только I-составляющая содержит постоянную часть ошибки, а P и D плавают в +-.


    Цитата Сообщение от mahowik Посмотреть сообщение
    ради эксперимента можно попробовать, но как по мне так уже лучше сразу взять MS5611-01, тогда и в сонаре надобность отпадет

    Да, точность на видео впечатляет. С таким барометром сонар и правда не нужен.


    Цитата Сообщение от igor_v_t Посмотреть сообщение
    Я решил эту проблему при помощи сонара. Добавил в газ производную от высоты по сонару (дифф. составляющая) и проваливаться перестал

    Это-то понятно - мой алгоритм тоже стабилизирует высоту после начала движения, но если бы мы заранее знали, что вот сейчас будет нужна коррекция и её точная величина - то время стабилизации и отклонения уменьшится существенно.


    Цитата Сообщение от igor_v_t Посмотреть сообщение
    Я взял MS5611 , читаю с него данные с частотой 100 Гц

    Ждем результатов и кода.


    Цитата Сообщение от igor_v_t Посмотреть сообщение
    До конца не доходит идея с векторным произведением (статья с Хабра) . Мне казалось , что если разделить Az акселерометра на Cos (крена) и Cos(тангажа) то получим нужную составляющую? Или я не прав?

    Векторное произведение, вернее проекция - это самый простой и 100% точный способ который можно применить на основе уже вычисленных ране данных. Косинус не подходит - AccZ мало, нужны все компоненты вектора (AccZ не учитывает горизонтальные ускорения при угле больше 0)


    Цитата Сообщение от Musgravehill Посмотреть сообщение
    acc_velocity = (Altitude - Altitude_prev) / alt_loop;

    Если для рассчета высоты ACC все равно надо считать скорость в интеграторе, зачем её считать "обратным способом" исходя из неточных показания барометра? Гдавный таргет алгоритма - использовать акселерометр по максимуму, а барометр только для коррекции ошибки. Хотя с более точным барометром можно и пересмотреть стратегию.

    Видео тестирования. Во время съемок ручку газа не трогал ни разу (кроме посадок и выхода на режим Alt Hold)


    Результаты:
    - надо увеличивать D (на нужную высоту выходит толко после 2-й осцилляции), стояло на пределе в 50, так что надо в коде увеличивать раза в 2-3 коэффициент
    - барометр держит +- 1 метр, что соотвествует его возможностям.Больше вряд ли из него можно что то выжать
    - Реакция на резкие возмущения хорошая, на наклоны и горизонтальные ускорения - реакции нет вообще, так что тут зачет.
    - При начале движения просаживается вниз, потом его алгоритм компнсирует но при остановке идет перекомпенсация и подпрыгивает вверх. Тут тоже все в прееделах рассчетного. Выход - или делать более жексткий и быстрый PID-регулятор, либо сразу внести корректировку угла (о чем писал выше)
    -Самое главное - он СТАБИЛЕН. Т.е. он ни разу за время облета 4-х паков не приложился об землю и не улетел выше 4-х метров.
    Последний раз редактировалось alexmos; 12.02.2012 в 21:55.

  34. #31

    Регистрация
    19.01.2012
    Адрес
    Киев, украина
    Возраст
    63
    Сообщений
    253
    Цитата Сообщение от alexmos Посмотреть сообщение
    Это-то понятно - мой алгоритм тоже стабилизирует высоту после начала движения, но если бы мы заранее знали, что вот сейчас будет нужна коррекция и её точная величина - то время стабилизации и отклонения уменьшится существенно.

    Векторное произведение, вернее проекция - это самый простой и 100% точный способ который можно применить на основе уже вычисленных ране данных. Косинус не подходит - AccZ мало, нужны все компоненты вектора (AccZ не учитывает горизонтальные ускорения при угле больше 0)
    А откуда заранее знать что коптер захочет провалиться. Он просто компенсирует провал.
    Вопрос такой - так векторное произведение или проекция. Векторное произведение - это вектор направленный перпендикулярно плоскости, в которой лежат сомножители и по величине равен произведению модулей на синус угла.

    А коптер летает хорошо. Только по сонару Пиды побольше поставить. Лучше стабилизироваться будет. По моему опыту в 2 раза больше чем по баро.

  35. #32

    Регистрация
    23.08.2011
    Адрес
    Краснодар
    Возраст
    39
    Сообщений
    1,017
    Записей в дневнике
    2
    Цитата Сообщение от igor_v_t Посмотреть сообщение
    А откуда заранее знать что коптер захочет провалиться. Он просто компенсирует провал.

    Ну он же всегда проваливается при наклоне и начале движения, и всегда подпрыгивает при остановке. Есть какая-то закономерность, обусловленная физикой.


    Цитата Сообщение от igor_v_t Посмотреть сообщение
    Вопрос такой - так векторное произведение или проекция

    Нет, конечно же не векторное, а скалярное, описка . Нам нужна проекция вектора ускорения на вектор ориентации (по которому стабилизируем углы, в MultiWii он всегда направлен вниз). Из определения http://ru.wikipedia.org/wiki/%D0%A1%...BD%D0%B8%D0%B5 обращаем внимание на строку "Данной операции соответствует умножение длины данного вектора x на проекцию другого вектора y на данный вектор x" ну и дальше все просто.

    Цитата Сообщение от igor_v_t Посмотреть сообщение
    А коптер летает хорошо. Только по сонару Пиды побольше поставить. Лучше стабилизироваться будет. По моему опыту в 2 раза больше чем по баро.
    Спорный вопрос - во первых, два набора пидов усложнят настройку. А во вторых, сонар не всегда точен, и в некоторых условиях может очень сильно лажать... Вот почему его также надо корректировать ускорением:
    Нажмите на изображение для увеличения
Название: sonar_acc.png
Просмотров: 76
Размер:	16.3 Кб
ID:	603410
    Последний раз редактировалось alexmos; 13.02.2012 в 00:09.

  36. #33

    Регистрация
    19.01.2012
    Адрес
    Киев, украина
    Возраст
    63
    Сообщений
    253
    Цитата Сообщение от alexmos Посмотреть сообщение
    Ну он же всегда проваливается при наклоне и начале движения, и всегда подпрыгивает при остановке. Есть какая-то закономерность, обусловленная физикой.

    Спорный вопрос - во первых, два набора пидов усложнят настройку. А во вторых, сонар не всегда точен, и в некоторых условиях может очень сильно лажать... Вот почему его также надо корректировать ускорением:
    Вложение 603410
    Я это не сам придумал.
    Коррекция газа от угла наклона введена в Арду 2.0 давно.

    Два набора Пидов в Арду были более года еще в ArducopterNG. Можно летать и на одном - но тогда с сонаром больше плавать будет по высоте. Это проверено. Если на настройках сонара летать по баро излишне дергается.

    Корректировать сонар по акселерометру - простым алгоритмом не обойдешся. Там проще отбрасывать некорректные результаты измерений.

    Другое дело в баро - там акселем компенсируется шум баро-то есть шум убирается фильтрацией, а возникающее при этом запаздывание , мешающее работе Пид регулятора и приводящее к незатухающим колебаниям компенсируется составляющей рассчитанной по акселерометру.

    Но намного легче будет с хорошим баро. При высокой частоте измерений и меньшем уровне шума его легче фильтровать, а медленный дрейф баро можно компенсировать измерениями по сонару - при желании, но алгоритм оценки достоверности и пригодности для коррекции тоже вопрос не тривиальный. Если на поле, то просто, а если на горбатой местности-?

  37. #34

    Регистрация
    13.03.2011
    Адрес
    Montreal, Canada
    Возраст
    39
    Сообщений
    2,299
    Записей в дневнике
    19
    Цитата Сообщение от mahowik Посмотреть сообщение
    как я уже писал, мысль-идея-решение витает в воздухе в параллели... http://www.multiwii.com/forum/viewto...3&p=8871#p8840
    + еще один рабочий алгоритм http://www.multiwii.com/forum/viewto...start=90#p8876
    BMP085


    MS5611

  38. #35

    Регистрация
    19.01.2012
    Адрес
    Киев, украина
    Возраст
    63
    Сообщений
    253
    Цитата Сообщение от alexmos Посмотреть сообщение
    -Самое главное - он СТАБИЛЕН. Т.е. он ни разу за время облета 4-х паков не приложился об землю и не улетел выше 4-х метров.
    Результат очень хороший. Я приятно удивлен. Я не верил, что из 085 можно такое выжать.
    Мне в прошлом году времени для дотошного изучения баро не хватило (были более интересные проблемы). В этом году вернулся к баро, но уже с MS5611. Судя по результатам на столе с MS5611 получится. Но я поражен Вашими результатами с 085. Я думаю , что китайцев с NAZA вы уже догнали.

    Был бы благлдарен,если бы Вы расписали математику, но без привлечения векторов. Не в обиду и скалярного произведения нет там.
    Свои результаты я выше привел. Код полностью в соседней теме "High end Low cost Quatrocopter"Саму стабилизацию по высоте чуть позже добавлю в программу.До этого при стабилизации по высоте я использовал газ висения, но на этой платформе нужен алгоритм как его измерять. В Арду просто, там есть лог и полетавши берутся данные из лога. Использовать значение газа в момент переключения не очень здорово. Каждый раз аппарат точно вывешивать хлопотно.

    А дальше появляется любопытная возможность повозится и с горизонтальной составляющей акселерометра и компенсировать воздействия от порывов ветра и прочее.

  39. #36

    Регистрация
    23.08.2011
    Адрес
    Краснодар
    Возраст
    39
    Сообщений
    1,017
    Записей в дневнике
    2
    Цитата Сообщение от igor_v_t Посмотреть сообщение
    Результат очень хороший. Я приятно удивлен. Я не верил, что из 085 можно такое выжать
    Спасибо. Уже есть пара идей насчет улучшения. Сейчас явно не хватает силы PID-регулятору высоты, но если его усиливать, все скачки барометра вылезут ещё больше. Так что надо ещё сильнее сглаживать вычисленную высоту. И для сонара надо что то придумывать, если увеличивать коэффициенты PID раза в три, будет сильно подкидывать на кочках, а это не есть гуд. Сонар должен отслеживать медленно меняющийся рельеф местности, но мелкие кочки пропускать.

    Цитата Сообщение от igor_v_t Посмотреть сообщение
    Был бы благлдарен,если бы Вы расписали математику, но без привлечения векторов. Не в обиду и скалярного произведения нет там
    Без векторов я не смогу объяснить В коде "в лоб" взято определение скалярного произведения и длины вектора (из википедии)
    Код:
    (accADC[0]*EstG.V.X + accADC[1]*EstG.V.Y + accADC[2]*EstG.V.Z) *  InvSqrt(fsq(EstG.V.X) + fsq(EstG.V.Y) + fsq(EstG.V.Z),
    что соответсвует A_B_projection = (Ax*Bx + Ay*By + Az*Bz)/sqrt(Bx*Bx + By*By + Bz*Bz)


    Цитата Сообщение от igor_v_t Посмотреть сообщение
    Каждый раз аппарат точно вывешивать хлопотно.
    Точное вывешивание не нужно, можно при любом газе включить удержание. Разница будет только во времени стабилизации PID-регулятором.

    При полете по программе и необходимости выйти на этот режим автоматически, нужно все же знать примерный газ удержания. Или делать автовыод на режим, медленно увеличивая газ и следя за вертикальной скоростью (установка вблизи нуля). У меня в общем пока такой задчи не стоит, не думал особо.


    Цитата Сообщение от igor_v_t Посмотреть сообщение
    А дальше появляется любопытная возможность повозится и с горизонтальной составляющей акселерометра и компенсировать воздействия от порывов ветра и прочее.
    Я уже пробовал, результаты тут: http://www.multiwii.com/forum/viewtopic.php?f=7&t=685
    Тогда у меня было чуть меньше опыта, но со своим выводом в конце темы согласен и теперь.


    Цитата Сообщение от mahowik Посмотреть сообщение
    еще один рабочий алгоритм http://www.multiwii.com/forum/viewto...start=90#p8876
    Занятно, человек вообще отказался от акселерометра Сразу предположу, что он не сможет выставить более-менее рабочий PID, т.к. D-часть брать неоткуда. Судя по видео, у него стоит очень слабый PID, и вряд ли он удержит коптер реалных ситуациях.

  40. #37

    Регистрация
    19.01.2012
    Адрес
    Киев, украина
    Возраст
    63
    Сообщений
    253
    Цитата Сообщение от alexmos Посмотреть сообщение
    Сейчас явно не хватает силы PID-регулятору высоты, но если его усиливать, все скачки барометра вылезут ещё больше. Так что надо ещё сильнее сглаживать вычисленную высоту. И для сонара надо что то придумывать, если увеличивать коэффициенты PID раза в три, будет сильно подкидывать на кочках, а это не есть гуд. Сонар должен отслеживать медленно меняющийся рельеф местности, но мелкие кочки пропускать.
    Опять таки все просто. Ставится ограничение на Пид регулятор (у меня +(100-150) -(40-60) мкс. И высоту держит точно и не подпрыгивает особо. Но газ при этом точно выставлять нужно.
    По І составляющей +-30 мкс.

  41. #38

    Регистрация
    23.08.2011
    Адрес
    Краснодар
    Возраст
    39
    Сообщений
    1,017
    Записей в дневнике
    2
    Предлагаете ограничивать управляющее воздействие (то есть коррекцию газа)? Не выход, мне кажется.. Иначе регулятор будет работать в нерасчетном режиме. И регулятору нужна свобода действий, особено сильному и быстрому

    К посту MultiWii - обсуждаем и отлаживаем Alt Hold - не могли бы вы побьольше комментариев расставлять? Самое главное в нашем общении тут не код, а идеи. И константы лучше выносить в #define и обзывать осмысленными именами и подписывать, чтобы проще было понять потом логику и физический смысл алгоритма.

  42. #39

    Регистрация
    19.01.2012
    Адрес
    Киев, украина
    Возраст
    63
    Сообщений
    253
    Цитата Сообщение от alexmos Посмотреть сообщение
    Предлагаете ограничивать управляющее воздействие (то есть коррекцию газа)? Не выход, мне кажется.. Иначе регулятор будет работать в нерасчетном режиме. И регулятору нужна свобода действий, особено сильному и быстрому

    К посту MultiWii - обсуждаем и отлаживаем Alt Hold - не могли бы вы побьольше комментариев расставлять? Самое главное в нашем общении тут не код, а идеи. И константы лучше выносить в #define и обзывать осмысленными именами и подписывать, чтобы проще было понять потом логику и физический смысл алгоритма.
    Просто указываю диапазон изменения длительности управляющего импульса на регулятор в микросекундах. У нас разные программы и я пытаюсь свести к сравнимым величинам.
    В части свободы регулятора . Без ограничения у меня не получалось получить жесткое удержание без болтанки и быстрое достижение заданной высоты.

    И вопрос - EstG.V.Z -это проекция G на ось Z.

  43. #40

    Регистрация
    13.03.2011
    Адрес
    Montreal, Canada
    Возраст
    39
    Сообщений
    2,299
    Записей в дневнике
    19
    Цитата Сообщение от alexmos Посмотреть сообщение
    Уже есть пара идей насчет улучшения. Сейчас явно не хватает силы PID-регулятору высоты
    высадил кучу паков на выходных... при П более 2-х начинает колбасить вверх вниз, т.е. можно смело уменшать делитель в ПИД регуле...

    Hекоторые идеи по улучшению:
    1. пробовал добавлять ПД регуль по скорости... Точнее Д из ПИД по высоте переехал в П по скорости (что одно и тоже) + в качестве Д по скорости взял ускорение как описывал выше + поставил деадбенд на ПД +/20, но не просто обрубил значения менее 20-ти, а с вычитанием в 20, если ПД более 20-ти (т.е. смещение значений к ценру... типа как вишном ролл/питч деадбенде на аппу)... шум сразу пропал, что отлично и при довольно высоких коэф. чувствительность ПД регулятора не падает...
    Далее занулял ПИ по высоте, а ПД по скорости брал довольно агрессивными. При рывке вверх и движении с вертикалной скоростью 1-2м/с практически мгновенно (~0.5сек) тормозит коптер при активировании альт-холд... но при движенни вниз результат немного хуже. Это скорее всего из-за явной нелинейности моего акселя по оси Z (+128/-152)...
    За счет ускорения поднимается фронт скорости, а также получяется более крутой спад. В отрицателную часть уходит лишь немного в конце... так что можно смело исползовать ускорение, тем более что ускорение гораздо меньше шумит в сравнении со скоростью...

    Нажмите на изображение для увеличения
Название: acc.png
Просмотров: 8
Размер:	4.4 Кб
ID:	603828
    где зеленым-скорость, синим-ускорение, красным-сумма.

    для демо: вниз рукой получалось протолкнуть макс. на 40-50см! Также думаю это даст огромный плюс при порывах ветра...

    2. т.к. "быстрые" составляющие (ускорение и скорость) высчитываются из акселя, думаю можно смело уменьшать частоту алт-холд интегратора/эстиматора и отталкиваться от частоты среза ФНЧ акселерометра. Теоритически конечно чем выше самплинг raw данных с акселя, тем точнее будут показания скорости после интегратора, но при этом придется поднять ФНЧ (к примеру с 20гц на 50 гц), чтобы не получать усредненные raw данные с акселя и не делать "пустых" вычислений. НО с поднятием частоты среза получим чвствительность к вибро. И результат будет только хуже как в алт холд, так и стаб/левел моде.
    Золотая середина тут на мой взгляд - это 20-25гц ФНЧ акселя и 40-50гц частота интегратора соот-но... я как то убедил в этом АлексаВПариже (главный разработчик вии) и он для бма180 выставил 20гц, для бма020 25гц (уже был, т.к. это нижний предел) и для адхл345 тоже 25 гц, чтобы привести все аксели к частоте алт-холд интегратора...

    http://www.multiwii.com/forum/viewto...start=80#p7564
    http://www.multiwii.com/forum/viewto...start=90#p7598

    тут тоже писал об этом:
    http://forum.rcdesign.ru/blogs/83206/

    также при таком подходе съэкономим ресурс процессора...

Закрытая тема

Похожие темы

  1. Crius Hobby MultiWii
    от leprud в разделе Коптеры. Комплектующие, сборка, настройка.
    Ответов: 2931
    Последнее сообщение: 24.02.2017, 03:34
  2. futaba 8, функция hold
    от midiant в разделе Аппаратура, гироскопы, гувернеры, электроника
    Ответов: 5
    Последнее сообщение: 27.12.2011, 14:21

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения