MultiWii

SovGVD
rual:

Подскажите, где берут последню версию ГУИ и прошивку с ГПС ?

code.google.com/p/i2c-gps-nav/ - там недавно видел билд на основе последней dev версии multiwii, с новым GUI, с кучей графиков и пидов

SovGVD
matrus3:

Уже вторую неделю пробую настроить, пару мин висит потом начинает дрейфовать в произвольную сторону.

а магнитное склонение (отклонение) верно выставлено? компас откалиброван?

matrus3:

Не получается откалибровать, ГУИ не реагирует на нажатие кнопки.

как вариант старый GUI, вместе с прошивкой лежит новый GUI и прошивка для самого MultiWii с патчами

rual
SovGVD:

code.google.com/p/i2c-gps-nav/ - там недавно видел билд на основе последней dev версии multiwii, с новым GUI, с кучей графиков и пидов

Вопрос весь в том где в ГУИ настраивается план полета (путевые точки), и исходник из прошивки для работы с этим с протооколом.
Нужно для своей поделки, своё ГУИ писать долго (ибо я не “подоконник”), Мавлинк для ардукоптера весьма гемороен.

SovGVD
rual:

Вопрос весь в том где в ГУИ настраивается план полета (путевые точки), и исходник из прошивки для работы с этим с протооколом.

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

matrus3
SovGVD:

а магнитное склонение (отклонение) верно выставлено? компас откалиброван?

как вариант старый GUI, вместе с прошивкой лежит новый GUI и прошивка для самого MultiWii с патчами

Все делал как в доке написано для r33. Проблему с калибровкой решил, взял ГУИ из последней ДЕВ версии.

Сейчас подключу блутуз и буду смотреть есть ли дрейф в ГУИ.

Alexey_1811
  1. Подскажите как правильно настроить ориентацию осей компаса (как проверить что правильно).
  2. Если я резко наклоняю квадрик то в ГУИ он поворачивается но потом возвращается на пару градусов. Это нормально?
SovGVD
  1. тут по русски
  2. вообще не очень нормально, гира работает “сильнее” чем аксель, хотя смотря насколько резко =)
Alexey_1811

На счет резко я перегнул. Поворачиваю не медленно. Подскажите как побороть.

SovGVD
Alexey_1811:

На счет резко я перегнул. Поворачиваю не медленно. Подскажите как побороть.

посмотреть где угол верный - когда обратно уплывает или когда только повернулся, в первом случае - гира переруливаем, во втором гира нормально, а вот аксель недоруливает
потом поиграться с делителем значений для своих датчиков (в sensors.ino(.pde))
а вообще лучше взлететь, если нормально всё, то забить

mahowik
SovGVD:

отом поиграться с делителем значений для своих датчиков

категорически нельзя делить данные с датчков!!! для акселя если делить, то надо уменьшать acc_1g пропоционально, но при этом просто уменьшается дискретность данных, что позволяет уменьшить шум около нуля (и дрейф соот-но), т.е. около горизонта… гиру вообще не трогать, либо учитывать делители в ИМУ, т.к. при делении не та угловая скорость будет и соот-но калькуляция поворотов…

SovGVD
mahowik:

категорически нельзя делить данные с датчков!!!

вполне можно, если горизонт неверно показывает, я для эталона использую itg3205 из нунчака, обычно датчики нормально работают, но какой то выпиленный аксель тупил, вот к нему методом тыка подбирал делитель… важно проверить что угол наклона платки датчиков такой же как в GUI (ну и конечно откалибровать заранее)
кстатии был аналогичный косяк и с другой гирой, в 2 раза толи уменьшать, то ли увеличивать пришлось делитель, а то платку кручу на пару градусов, а прыгает на 10-15

TimAU

У меня такая же ерунда на 6050, при повороте на 45 градусов он думает что на все 90 развернуло его

mahowik
SovGVD:

но какой то выпиленный аксель тупил, вот к нему методом тыка подбирал делитель…

а чип-соплю удалял (я тупо кусачками выгрыз)? он мог просто переключить 3205 сенсор на другую чувствительность…

SovGVD
mahowik:

а чип-соплю удалял (я тупо кусачками выгрыз)? он мог просто переключить 3205 сенсор на другую чувствительность…

не, там всё отлично было, ровненько выпилил, кондер на питание впаял… дело было именно в датчике

TimAU:

такая же ерунда на 6050, при повороте на 45 градусов он думает что на все 90 развернуло его

думает гира (резкий поворот и потом назад уплывает) или аксель (повернулось верно, а потом доплывает до 90)?

TimAU
SovGVD:

или аксель (повернулось верно, а потом доплывает до 90)?

У меня этот вариант, ну там не совсем до 90, ну градусов 15-20 доплывает в течении примерно 2 секунд. Как лечить? Заранее спасибо

SovGVD
TimAU:

Как лечить? Заранее спасибо

я такое лечил изменением делителя (при условии что поворот гиры верный, т.е. моментальный поворот совпадает с реальным поворотом датчиков) в коде, например

void ACC_getADC () {
  i2c_getSixRawADC(MPU6050_ADDRESS, 0x3B);
  ACC_ORIENTATION( ((rawADC[0]<<8) | rawADC[1])/8 ,
                   ((rawADC[2]<<8) | rawADC[3])/8 ,
                   ((rawADC[4]<<8) | rawADC[5])/8 );
  ACC_Common();
}

вот тут вместо 8 попробовать 10 например
НО mahowik говорит что это не правиьно

mahowik
TimAU:

У меня этот вариант, ну там не совсем до 90, ну градусов 15-20 доплывает в течении примерно 2 секунд. Как лечить? Заранее спасибо

в Sensors.pde ничего не трогать! ))
для гиры GYRO_SCALE крутить надо в IMU.pde
#define GYRO_SCALE ((2380 * PI)/((32767.0f / 4.0f ) * 180.0f * 1000000.0f))

TimAU

SovGVD и mahowik, Огромнейшее спасибо, будем лечить …

SovGVD
mahowik:

для гиры GYRO_SCALE крутить надо в IMU.pde

я предполагал что то что в sensors должно выдавать нормализованные значение… а получется что для каждого датчика надо GYRO_SCALE подбирать потом?

mahowik
SovGVD:

я предполагал что то что в sensors должно выдавать нормализованные значение… а получется что для каждого датчика надо GYRO_SCALE подбирать потом?

ну в принципе так и есть из сенсорс идет нормализованное значение, но т.к. там целочисленные вычисления, то делителем точно не подобрать…
а так да, придется GYRO_SCALE для другого датчика менять, но мы же говорим про подстройку конкретного железа, а не общий случай “прoшивка для всех”…

rual

Вий-профи, подскажите, в serial.pde в разных версиях нашёл 2 протокола:
Старый, где валит вся инфа с по букве “Мэ”,

и новый, типа структурированный

void serialCom() {
uint8_t i, c;
static uint8_t offset,dataSize;

while (SerialAvailable(0)) {
c = SerialRead(0);
if (stateMSP > 99) { // a message with a length indication, indicating a non null payload
if (offset <= dataSize) { // there are still some octets to read (including checksum) to complete a full message
if (offset < dataSize) checksum ^= c; // the checksum is computed, except for the last octet
inBuf[offset++] = c;
} else { // we have read all the payload
if ( checksum == inBuf[dataSize] ) { // we check is the computed checksum is ok
switch(stateMSP) { // if yes, then we execute different code depending on the message code. read8/16/32 will look into the inBuf buffer
case MSP_SET_RAW_RC:
for(i=0;i<8;i++) {rcData[i] = read16();} break;
case MSP_SET_RAW_GPS:
GPS_fix = read8();
GPS_numSat = read8();
GPS_latitude = read32();
GPS_longitude = read32();
GPS_altitude = read16();
GPS_speed = read16();
GPS_update = 1; break;
case MSP_SET_PID:
for(i=0;i<PIDITEMS;i++) {P8[i]=read8();I8[i]=read8();D8[i]=read8();}
break;
case MSP_SET_BOX:
for(i=0;i<CHECKBOXITEMS;i++) {activate[i]=read16();} break;
case MSP_SET_RC_TUNING:
rcRate8 = read8();
rcExpo8 = read8();
rollPitchRate = read8();
yawRate = read8();
dynThrPID = read8();
thrMid8 = read8();
thrExpo8 = read8();break;
case MSP_SET_MISC:
#if defined(POWERMETER)
powerTrigger1 = read16() / PLEVELSCALE; // we rely on writeParams() to compute corresponding pAlarm value
#endif
break;
}
}
stateMSP = 0; // in any case we reset the MSP state
}
}

новый вроде как более правильный, но насколько широко используемый?