MultiWii
Подскажите, где берут последню версию ГУИ и прошивку с ГПС ?
code.google.com/p/i2c-gps-nav/ - там недавно видел билд на основе последней dev версии multiwii, с новым GUI, с кучей графиков и пидов
Уже вторую неделю пробую настроить, пару мин висит потом начинает дрейфовать в произвольную сторону.
а магнитное склонение (отклонение) верно выставлено? компас откалиброван?
Не получается откалибровать, ГУИ не реагирует на нажатие кнопки.
как вариант старый GUI, вместе с прошивкой лежит новый GUI и прошивка для самого MultiWii с патчами
code.google.com/p/i2c-gps-nav/ - там недавно видел билд на основе последней dev версии multiwii, с новым GUI, с кучей графиков и пидов
Вопрос весь в том где в ГУИ настраивается план полета (путевые точки), и исходник из прошивки для работы с этим с протооколом.
Нужно для своей поделки, своё ГУИ писать долго (ибо я не “подоконник”), Мавлинк для ардукоптера весьма гемороен.
Вопрос весь в том где в ГУИ настраивается план полета (путевые точки), и исходник из прошивки для работы с этим с протооколом.
нигде, 15 путевых точек как то с пульта задаются (а может быть вообще нет такого еще), потом коптер по ним пролетает
а магнитное склонение (отклонение) верно выставлено? компас откалиброван?
как вариант старый GUI, вместе с прошивкой лежит новый GUI и прошивка для самого MultiWii с патчами
Все делал как в доке написано для r33. Проблему с калибровкой решил, взял ГУИ из последней ДЕВ версии.
Сейчас подключу блутуз и буду смотреть есть ли дрейф в ГУИ.
- Подскажите как правильно настроить ориентацию осей компаса (как проверить что правильно).
- Если я резко наклоняю квадрик то в ГУИ он поворачивается но потом возвращается на пару градусов. Это нормально?
- тут по русски
- вообще не очень нормально, гира работает “сильнее” чем аксель, хотя смотря насколько резко =)
На счет резко я перегнул. Поворачиваю не медленно. Подскажите как побороть.
На счет резко я перегнул. Поворачиваю не медленно. Подскажите как побороть.
посмотреть где угол верный - когда обратно уплывает или когда только повернулся, в первом случае - гира переруливаем, во втором гира нормально, а вот аксель недоруливает
потом поиграться с делителем значений для своих датчиков (в sensors.ino(.pde))
а вообще лучше взлететь, если нормально всё, то забить
отом поиграться с делителем значений для своих датчиков
категорически нельзя делить данные с датчков!!! для акселя если делить, то надо уменьшать acc_1g пропоционально, но при этом просто уменьшается дискретность данных, что позволяет уменьшить шум около нуля (и дрейф соот-но), т.е. около горизонта… гиру вообще не трогать, либо учитывать делители в ИМУ, т.к. при делении не та угловая скорость будет и соот-но калькуляция поворотов…
категорически нельзя делить данные с датчков!!!
вполне можно, если горизонт неверно показывает, я для эталона использую itg3205 из нунчака, обычно датчики нормально работают, но какой то выпиленный аксель тупил, вот к нему методом тыка подбирал делитель… важно проверить что угол наклона платки датчиков такой же как в GUI (ну и конечно откалибровать заранее)
кстатии был аналогичный косяк и с другой гирой, в 2 раза толи уменьшать, то ли увеличивать пришлось делитель, а то платку кручу на пару градусов, а прыгает на 10-15
У меня такая же ерунда на 6050, при повороте на 45 градусов он думает что на все 90 развернуло его
но какой то выпиленный аксель тупил, вот к нему методом тыка подбирал делитель…
а чип-соплю удалял (я тупо кусачками выгрыз)? он мог просто переключить 3205 сенсор на другую чувствительность…
а чип-соплю удалял (я тупо кусачками выгрыз)? он мог просто переключить 3205 сенсор на другую чувствительность…
не, там всё отлично было, ровненько выпилил, кондер на питание впаял… дело было именно в датчике
такая же ерунда на 6050, при повороте на 45 градусов он думает что на все 90 развернуло его
думает гира (резкий поворот и потом назад уплывает) или аксель (повернулось верно, а потом доплывает до 90)?
или аксель (повернулось верно, а потом доплывает до 90)?
У меня этот вариант, ну там не совсем до 90, ну градусов 15-20 доплывает в течении примерно 2 секунд. Как лечить? Заранее спасибо
Как лечить? Заранее спасибо
я такое лечил изменением делителя (при условии что поворот гиры верный, т.е. моментальный поворот совпадает с реальным поворотом датчиков) в коде, например
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 говорит что это не правиьно
У меня этот вариант, ну там не совсем до 90, ну градусов 15-20 доплывает в течении примерно 2 секунд. Как лечить? Заранее спасибо
в Sensors.pde ничего не трогать! ))
для гиры GYRO_SCALE крутить надо в IMU.pde
#define GYRO_SCALE ((2380 * PI)/((32767.0f / 4.0f ) * 180.0f * 1000000.0f))
SovGVD и mahowik, Огромнейшее спасибо, будем лечить …
для гиры GYRO_SCALE крутить надо в IMU.pde
я предполагал что то что в sensors должно выдавать нормализованные значение… а получется что для каждого датчика надо GYRO_SCALE подбирать потом?
я предполагал что то что в sensors должно выдавать нормализованные значение… а получется что для каждого датчика надо GYRO_SCALE подбирать потом?
ну в принципе так и есть из сенсорс идет нормализованное значение, но т.к. там целочисленные вычисления, то делителем точно не подобрать…
а так да, придется GYRO_SCALE для другого датчика менять, но мы же говорим про подстройку конкретного железа, а не общий случай “прoшивка для всех”…
Вий-профи, подскажите, в 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
}
}
новый вроде как более правильный, но насколько широко используемый?