Создание собственной системы стабилизации
если углы из уг.скоростей не считать, то быстродействие регулятора растет.
угол как раз будет интегральной составлящей, а диф - ошибка угловой скорости… можно конечно заморочится и высчитать ускорение… ещё одна бредовая мысль - с акселя взять центростремительное ускорение? оно ж вдоль осей…
ещё одна бредовая мысль - с акселя взять центростремительное ускорение? оно ж вдоль осей…
Везде шумы шумы и шумы, я не знаю как с ними бороться, а начинаешь бороться, все быстродействие насмАрку…
Всем привет! Запилил новые 2 режима для фана.
Еще ко мне Dji Phantom 3 Advanced пришел. Первые впечатления, что довольно продуманы некоторые ньюансы. Векторного управления на движках я не заметил ,по-моему FOC должен себя иначе вести, но я не уверен. У подвеса обратная связь по положению ротора есть, отклонения отрабатывает плавно, без дребезга. Попробовал погазовать без винтов - коптер видит, что винтов нет, выводит сообщения. По яву - реагирует на угловую скорость, а не на положение. Однако в полете возвращается по яву.
Вообщем надо изучать. Удержание позиции работает четко и быстро, не плавает.
Будет время запилю тесты, сравнение.
Еще в планах попробовать отказаться от компаса вовсе и реализовать задумку с 2-мя ЖПС на диагонали для определения ориентации. Но это попозже
новые 2 режима
Как выглядят критерии “попадания” в заданную точку ?
Проверяется попадание текущего положения в некий квадрат или радиус ??
да, проверяется расстояние от текущего положения коптера до указанной точки, если оно меньше 0,4 м, то переходим в следующую точку. 0,4 м просто взял на глаз.
По идее сфера радиусом 0,4 м получается.
0,4 м, то переходим в следующую точку.
А курс на точку, я так понимаю, считается и корректируется постоянно в течении следования (?)…
Вообще, нельзя ли подсмотреть функцию пересчета положения по GPS в азимут точки ?? Для сравнения со своей:
int16_t get_azimut( float lat1, float long1, float lat2, float long2)
{
float dlon_W, dlon_E,dphi, atn2,tc;
int16_t az;
int8_t sign;
dlon_W = (long2 - long1) - (2*PI*(floor((long2 - long1)/(2*PI))));
dlon_E = (long1 - long2) - (2*PI*(floor((long1 - long2)/(2*PI))));
dphi = log((tan((lat2/2) + (PI/4)))/(tan((lat1/2) + (PI/4))));
if (dlon_W < dlon_E) {
dlon_W = -1*dlon_W;
if (dlon_W >= 0)
sign = 1;
else
sign = -1;
if (abs(dlon_W) >= abs(dphi)) {
atn2 = (sign * PI/2) - atan(dphi / dlon_W);
}
else {
if (dphi > 0) {
atn2 = atan(dlon_W / dphi);
}
else {
if ((-1*dlon_W) >= 0) {
atn2 = PI + atan(dlon_W / dphi);
}
else {
atn2 = (-1*PI) + atan(dlon_W / dphi);
}
}
}
}
else {
if (dlon_W >= 0)
sign = 1;
else
sign = -1;
if (abs(dlon_E) >= abs(dphi)) {
if (dlon_E > 0)
atn2 = sign * PI/2 - atan(dphi / (dlon_E));
else
atn2 = 0;
}
else {
if (dphi > 0) {
atn2 = atan((dlon_E) / dphi);
}
else {
if ((dlon_E) >= 0) {
atn2 = PI + atan((dlon_E) / dphi);
}
else {
atn2 = (-1*PI) + atan((dlon_E) / dphi);
}
}
}
}
tc = atn2 - (2*PI*(floor((atn2)/(2*PI))));
az=tc*toGRAD;
if(az<0){az+=360;}
if(az>359){az=0;}
return az;
}
Если вы про курс носа коптера, то он вообще отвязан, я им управляю с пульта.
У меня при первом хорошем приеме ЖПС высчитываются коэффициенты для пересчета из градусов долготы и широты в метры. Далее все считается в метрах от старта
Вот это обработка в прерывании по приему GPS:
if ((GPS_satellits > 8)&&(GPS_pDop<175))
{
if (flag_start_home == 0)
{
double LAT;
flag_start_home = 1;
GPS_height_start = GPS_height;
GPS_lon_start = GPS_lon;
GPS_lat_start = GPS_lat;
LAT = (double)GPS_lat/10000000.0f;
navUkfCalcEarthRadius(LAT, &KX, &KY);
}
xSemaphoreTake(xGPS_UKF_Mutex, portMAX_DELAY);
GPS_X = ((float)(GPS_lon-GPS_lon_start))*KX;
GPS_Y = ((float)(GPS_lat-GPS_lat_start))*KY;
GPS_alt = ((float)(GPS_height-GPS_height_start))*0.001f;
xSemaphoreGive(xGPS_UKF_Mutex);
StateNavUKF &= ~UKF_BAD_GPS;
flag_get_pvt = 1;
}
сама функция персчета, взята у автоквада:
static void navUkfCalcEarthRadius(double lat, float *k_x, float *k_y) {
double sinLat2;
sinLat2 = sin(lat * (double)DEG2RAD);
sinLat2 = sinLat2 * sinLat2;
*k_y = (double)NAV_EQUATORIAL_RADIUS * (double)DEG2RAD * ((double)1.0 - (double)NAV_E_2) / pow((double)1.0 - ((double)NAV_E_2 * sinLat2), ((double)3.0 / (double)2.0));
*k_x = (double)NAV_EQUATORIAL_RADIUS * (double)DEG2RAD / sqrt((double)1.0 - ((double)NAV_E_2 * sinLat2)) * cos(lat * (double)DEG2RAD);
*k_y /=10000000.0f;
*k_x /=10000000.0f;
}
Если вы про курс носа коптера
Я про нахождение вектора движения от одной точки к другой (его же надо считать, независимо от “носа” аппарата) или я че туплю ?
высчитываются коэффициенты для пересчета из градусов долготы и широты в метры.
короче, упрощенный вариант математики, - приближаем поверхность к плоскости… (я понял).
короче, упрощенный вариант математики, - приближаем поверхность к плоскости… (я понял).
А я уже не понял. А как иначе?
Я понимаю так: вот например есть у нас две точки, у каждой точки долгота и широта. Нам надо узнать вектор, соединяющий первую точку со второй. Возьмем за начало отсчета первую точку. Находим коэффициент пересчета долготы в метры, он зависит от широты, при этом коэффициент из широты в метры постоянен, вроде (в упрощенном варианте). Далее вычитаем из второй точки первую по градусам. Умножаем полученные коэфициенты на разницу в градусах и получаем разницу в метрах, то есть наш вектор.
Та функция navUkfCalcEarthRadius считает уже не просто сферу, а элипсоид, но принцип тот же.
А как иначе? Или я не о том?
А как иначе?
Моя функция принимает координаты двух точек по GPS в радианах (текущая позиция и целевая позиция) а на выходе выдает честный азимут в градусах (угол от направления на север) из текущей точки на целевую… математика была взята мной давно с какого то геодезического сайта (уже не помню) там как бы всё с учетом тонкостей “большой сферы”…
На практике еще не испытывал, потому и интересуюсь - как другие люди делают…
Есть просто мое предположение, что при упрощенном подходе ошибка расчетов будет расти с увеличением дальности…
(Надо в поле походить и посмотреть на практике…)
В любом случае нужно знать не только азимут, но и расстояние до точки в метрах по двум осям. В том коде, что я привел, расстояния высчитываются, а угол можно узнать через atan2f(GPS_Y, GPS_X).
В моем подходе, ошибка будет от несовпадения элипсоида и геоида, а также как вы правильно заметили, что чем дальше от места старта, тем больше ошибка. Но на практике чтоб ошибка хоть как то повлияла, надо от точки старта перпендикулярно линии экватора двигаться километров 100-200 в моей местности. Если вы делаете совсем универсальный аппарат, и он может за один полет пролететь такое расстояние либо вы будете летать на полюсах, то можно каждый раз при приеме ЖПС сигнала делать пересчет коээфициентов.
В любом случае нужно знать не только азимут, но и расстояние до точки в метрах по двум осям.
Зачем ?? если сразу есть угол на точку…
надо от точки старта перпендикулярно линии экватора двигаться километров 100-200
учитывая разрядность <float>, предположу, что ошибка будет видна на гораздо меньших расстояниях… (хотя, что спорить, проверять надо…)
Зачем ?? если сразу есть угол на точку…
Так когда остановится надо, если мы прост полетим в данном направлении? Это раз. Во-вторых, как вы будете зная только направление к точке вводить задание на ПИД , в простом случае - надо что-то типа задатчика интенсивности, типа апереодического звена с насыщением. У меня уже кубический интерполятор стоит, тут без знания расстояния не получится кривые разгона задать и скорости.
ошибка во float есть, но она константа и от расстояния не меняется. Можете проверить перевести градусы из дабла во флоат - потом пересчитать в метры, ошибка будет 10-30 см. Для задания точек, это не существенно. Для ОС удержания позиции существенна, поэтому у меня сначала вычитаются координаты в int32, а потом умножаются на коэффициенты пересчета…
Так когда остановится надо
Согласен, расстояние также желательно (но не обязательно)…
Можете проверить перевести градусы из дабла во флоат - потом пересчитать в метры
Верю на слово. (скорей на выложенное видео полетов…, нет вопросов…)
Я тоже перешел из градусов в метры. У меня на ардуине крутится софт который считывает протокол GPS.
Она все обрабатывает и по I2C передает на другую . Для контроллера полета ,GPS такой же датчик как и аксель , в готовом виде принимает X,Y, высоту,скорость,курс,число спутников. И в протоколе идет только GGA. Чтоб передать дробную часть метров я умножаю расстояния на 10, (растояние тип long ) а контроллер делит на 10.
Запилил новые 2 режима для фана.
Отлично! Центр круга, относительно которого берется направление, фиксируется при включении режима?
Илья, я тебе пару вопросов в скайп написал.
Всем привет, кто читает эту тему.
Кто-нибудь пробовал команды от микшера к ESC прогонять через подобную зависимость? только по оси Х не обороты а коэффициент заполнения ШИМа
Или она уже встроена в регулятор оборотов?
Всем привет, кто читает эту тему.
Кто-нибудь пробовал команды от микшера к ESC прогонять через подобную зависимость? только по оси Х не обороты а коэффициент заполнения ШИМа
…
Или она уже встроена в регулятор оборотов?
Вряд ли в ESC такое есть, это было бы заметно.
Тем более не зря же экспоненты в полетниках для дрон рейсинга делают.
Например без экспоненты по газу вообще не удобно летать, без нее на малых скоростях коптер сложно удерживать по высоте, не хватает диапазона(чувствительности, точности) стика (один щелчок вверх - улетает, один вниз - падает).
Единственно отличие, что там экспонента на стике управления, но разница не большая, просто экспонента проходит дополнительно через ПИД.
Спасибо за ценное замечание. Может в этом есть смысл.
Есть идея получить такую зависимость для своей ВМГ при среднем полетном напряжении аккума. Загнать ее после выхода микшера, перед таймерами с ШИМом.
Возможно получится более линейная отзывчивость. Плюс не надо крутить ПИДы на новом кваде, а достаточно загнать зависимость для нового ВМГ. У кого какие мысли?
Спасибо за ценное замечание. Может в этом есть смысл.
Есть идея получить такую зависимость для своей ВМГ при среднем полетном напряжении аккума. Загнать ее после выхода микшера, перед таймерами с ШИМом.
Возможно получится более линейная отзывчивость. Плюс не надо крутить ПИДы на новом кваде, а достаточно загнать зависимость для нового ВМГ. У кого какие мысли?
Посмотрел замеры тяги двигателя на стационарном стенде (бутылкостенд), зависимость тяги от положения стика. Характристика вполне себе линейная. Мотор EMAX 2205 2300KV с регулем ZTW spider 30A. Так что может и есть в регулях некоторая кривая линеризации. Так как теоретически эффективность пропеллера с увеличением оборотов должна падать, (вентиляторная нагрузочная характеристика пропеллера)
Но тут конечно может оказаться что пропеллер особенно в стационарном положении работает в начальном диапазоне, когда нагрузочная характеристика еще линейна, а вот в движении, на скорости, эта нелинейность может себя уже проявить. Если бы был график (положение стика/обороты) тогда бы можно было бы точнее разобраться.
А в дрон рейсинге эксопнента может быть и не только для линеризации характеристики двигателей, но и для удобства управления на разных углах наклона ну и для резкости управления.
Так что вопрос есть такая характеристика в регулях или нет, еще остается открытым 😃
Надо тупо найти открытую прошивку на регуль и посмотреть 😃
да я тоже проделал тест: