Создание собственной системы стабилизации
хм… хоть лсм-ка у меня есть но пока ее еще не подключал… но… есть отличия настройки лсм-ки от виевских.
а какие?
#define LSM330ACC_DEVICE_SIGNATURE 0xE0
.......................................................................
bool lsm330accDetect(sensor_t *acc)
{
bool ack = false;
uint8_t sig = 0;
ack = i2cRead(LSM330ACC_ADDRESS, LSM330_CTRL_REG1_A , 1, &sig);
sig = sig <<5;
if (!ack || sig != LSM330ACC_DEVICE_SIGNATURE)
return false;
acc->init = LSM330ACCInit;
acc->read = LSM330ACCRead;
acc->align = LSM330ACCAlign;
return true;
}
это я подсунул младшие биты первого регистра (они не меняются) для автоопределения датчика, остальное по сути как в вие, только поддержки вием лсм-ки нет, или уже есть?
У моего знакомого аналогичный датчик стал адекватно работать с делителем 1024)))
а я пробовал с 1023 может в этом ошибался?
Сам пользую аналогичный чип,но уже в новом форм факторе и с немного другими адресами и функционалом регистров.
а я не успел купить - лавочку прикрыли 😦
temp[] - это что? коэффициенты меняют длину вектора от акселя, ВИЮ важна длина?
temp - это я ворочал датчик так и осталось, а да делители важна для калибровки -
acc_1G = 256; а потом делителем подгоняется к этой длинне вектора
accelData[0] = temp[1]/32;
accelData[1] = -temp[0]/32;
accelData[2] = accelData[2]/32;
можно попробовать 1g и там 8192 обозвать тогда делитель не нужен, но чёт сомневаюсь что что-то изменится…
acc_1G = 256 и делитель 32 в принципе дают векторы правильные по всем осям, если ставить что-нибудь другое то не досчитывает по осям X,Y…
Выход один - нужна калибровка по всем осям наверно…
Только я не пойму, почему за полную шкалу берётся 16 бит, ведь показания в дополнительном коде и старший бит отвечает за знак, т.е. реальные показания это младших 15 бит, или я что-то не понимаю или сам запутался?
Так вот тараканы зашевелились: полная шкала 15бит(у ДУСов так и в Wii тоже
#if defined(ITG3200)
////////////////////
GYRO_ORIENTATION( ((rawADC[0]<<8) | rawADC[1])/4 , // range: +/- 8192; +/- 2000 deg/sec
8192*4 = 32768 ну если дотошно то должно быть 32767 ибо 32768 уже -1 получается)
так почемууу? аксель считается от 16 бит т.е. 65535 ??? они чё на бивнях считали что-ли? 😃
8192*4 = 32768 ну если дотошно то должно быть 32767 ибо 32768 уже -1 получается) так почемууу? аксель считается от 16 бит т.е. 65535 ??? они чё на бивнях считали что-ли?
погоди, не горячись, что uint16_t, что int16_t всё это одно и тоже 16-битное целое, только знаковое как бы “переломлено в минус” через нуль. Например, если счетчик 8 бит считает в минус …0х02, 0х01, 0х00, а дальше отрицательное переполнение 0xff=-1, 0xfe = -2… 0x80 максимальное отрицательное -128 ( для 16 бит -32768). Т.е ничего неизменилось, диапазон значений тот же 256 или 65536, меняется только “середина” диапазна не 0х80, а0х00.
i2cWrite(LSM330ACC_ADDRESS, LSM330_CTRL_REG4_A, 0x98) вот где кака - должно быть 0Х28, вылезла другая бяка - теряю ДУСы блин…
вылезла другая бяка - теряю ДУСы блин…
В телеметрию выведи сырые данные, а лучше отлачиком “проутюж”
в расчётах разобрался, датчик в 16g включался вот и считал что в два раза больше получаются делители, а следовательно и максимальное число, ДУСы рубятся где-то кальманом я и забыл совсем, что обновлял алгоритм…
Бугага, ДУСы душит файлсейв 😃
теперь у меня две версии с Кальманом и без, разницы пока не вижу…
а ЛСМ-ка по одной оси Y не досчитывает! вот и увод вправо!!!
В общем как только закажу платы для большОй, займусь переделкой Мелкоплаты - нравится она мне, только 6050 ставить не буду, а то NAZE32 получится 😃
Вот интересно, а почему правда в NAZE32 4-я ревизия два акселя, а никто не фильтрует их вместе? хватило бы и комплиментарного фльтра?
Вот интересно, а почему правда в NAZE32 4-я ревизия два акселя, а никто не фильтрует их вместе?
Я тут для побочного проекта считал “векторы” вибраций отдельно акселей и отдельно гироскопов (датчик - пресловутый 6050). Дак несовпадение полное получил, что расстроило, понятное дело.
Причем вибрация - явно ниже 100 Гц, однако суммы квадратов (x^2+y^2) вращались относительно друг друга с изменяющейся частотой! То ли фазовая разница, то ли сам дурак…
Я к чему это все - насколько можно доверять данным с двух разных датчиков?
Буду пробовать калибровку по всем осям делать, делать то всё равно нечего, и посмотрю - нафига ФС душить ДУСы…
Я к чему это все - насколько можно доверять данным с двух разных датчиков?
да доверять то нечему и так, а если векторы вибраций разные то в резонанс не должны по идее попасть?
Причем вибрация - явно ниже 100 Гц, однако суммы квадратов (x^2+y^2) вращались относительно друг друга с изменяющейся частотой! То ли фазовая разница, то ли сам дурак…
Аксель и ДУС мериют разные физвеличины. Как они могли одинаковые (симфазные) данные показать?
Я к чему это все - насколько можно доверять данным с двух разных датчиков?
Если датчики мериют одно и тоже, либо их приводят к одним величинам, но сами дачики разные ( и исправные), то можно повысить отношение сигнал/шум.
Копаюсь в акселе дальше - второй регистр:
#define LSM330_A_HPCF1 0x10 /* High-pass filter cutoff frequency selection */
#define LSM330_A_HPCF2 0x20 /* High-pass filter cutoff frequency selection */
#define LSM330_A_HPCF3 0x30 /* High-pass filter cutoff frequency selection */
выбор частоты среза, но нигде не написано какой?
выбор частоты среза, но нигде не написано какой?
см. стр. 39, там правда для гиры, но вроде как одинаково с акселем.
у гиры 3 бита у акселя 2?
Вечером попробовать надо…
у гиры 3 бита у акселя 2?
Частота среза и там и там 2 бита, частота дескретизации у акселя 4 бита.
Не на 39 странице для гиры задаётся и частота дискретизации и частота среза, у акселя в этом регистре только частота дискретизации 29стр. меня же интересует ВЧ фильтр акселя 30стр. у гиры 40 стр. у гиры я не использую хватает первого регистра 39стр. а у акселя такого нет…
Я сейчас могу задействовать лапу прерывания готовности, BMP выкинул и входы (аппаратные) прерываний свободны, к тому же дорожки около ЛСМ-ки проходят, было бы классно задействовать, хотя тоже самое и программным сделается…
А Вы не пробовали разобраться, что за данные умеет выдавать MPU6000/6050? Там же на борту какой-то onboard Digital Motion Processor заявлен, судя по описанию.
onboard Digital Motion Processor™ (DMP™) capable of processing complex 9-axis MotionFusion algorithms. The parts’ integrated 9-axis MotionFusion algorithms access external magnetometers or other sensors through an auxiliary master I²C bus, allowing the devices to gather a full set of sensor data without intervention from the system processor
А я разобрался куда деваются ДУСы при ФС - на этой платке PPM все каналы уходят при выключении передатчика в 1000, что как раз соответствует калибровке их любимых, в Wii по идее тоже самое будет происходить, значит либо переделывать ПО платки, а лучше всё-таки купить нормальные передатчик с приёмником…
А Вы не пробовали разобраться, что за данные умеет выдавать MPU6000/6050? Там же на борту какой-то onboard Digital Motion Processor заявлен, судя по описанию.
Там 6axis а не 9. Кроме того, вун Дидроновцы уже давно пытаются заюзать DMP, но пока не видно результата. Хотя как вторичный AHRS его можно включить в Ардукоптере. В принципе и код можно оттуда передрать если очень надо, то разобраться там без описания будет сложновато.
Потанцевал с бубном вокруг акселя: перевёл на 400Гц, 1g=1024, acc_lpf_factor = 80. Дёрганий резких нет, имеется увод на 1.5-2 градуса. АХ (ещё не настраивал) имеют место прыжки 0.5м, при использовании акселя имеются небольшие осцилляции на снижении (с магнитометром ведёт себя чуть получше), в целом - лучше чем было но доверять ещё не стоит (акселю)…
а на зависть товарищам из ветки rcopen.com/forum/f123/topic156768/3835 серва быстрая цифровая Operating Speed: 0.07sec.60º/ 0.06sec.60º ведёт себя прилично без осцилляций (стоит как вкопаная в нужном положении)