Создание собственной системы стабилизации
Смотрите, какой подарок нам готовит ST: www.st.com/internet/com/press_release/p3273.jsp
какой подарок нам готовит ST
Фактически - тот же mpu9150
Ибо никаких подробностей ни там, ни тут не известны
Фактически - тот же mpu9150 Ибо никаких подробностей ни там, ни тут не известны
Зато тут обычный ARM32, можно залить уже отлаженные алгоритмы DCM, MARG, что там еще есть… Могу предположить, что тут вообще не будет готового sensor fusion алгоритма (ну или зальют какой нибудь общеизвестный), заливай что хочешь.
А в MPU все шито-крыто, максимум удалось спереть 6axis DMP и то никто не знает как оно работает на самом деле.
А в MPU все шито-крыто, максимум удалось спереть 6axis DMP и то никто не знает как оно работает на самом деле.
16 апреля обещали все открыть…
Внутри там явно какой-то арм, вопрос стоит только в доступности документации от производителя
Зато тут обычный ARM32, можно залить уже отлаженные алгоритмы DCM, MARG, что там еще есть… Могу предположить, что тут вообще не будет готового sensor fusion алгоритма (ну или зальют какой нибудь общеизвестный), заливай что хочешь.
А в MPU все шито-крыто, максимум удалось спереть 6axis DMP и то никто не знает как оно работает на самом деле.
И далее ИМХО переход на 32 разрядные процессоры имеет смысл только для сервиса, или задач обработки изображений.
16 апреля обещали все открыть…
Внутри там явно какой-то арм, вопрос стоит только в доступности документации от производителя
Так что ждем 16 апреля
Насчет датчика LSM330DL@ST ставьте смело, уже пару месяцев юзаю один из первой партии работает отлично в отличии от ITG3205 + LIS3DH (хотя и эта связка неплохо себя показала).
Может Вы сравнивали с MPU 6000 или хотя бы какие то цифры по дрейфу .
Еще раз почитал форум Invensense, короче судя по всему, с MPU6050 полная ж. 9DOF DMP на нем не получится сделать. На замену ему идет MPU9150 и вроде он пин-совместим с 6050, но от этого не легче…
Так что, по моему решение от ST, получше, там обычный проц, обычные программы, обычные интерфейсы (ну по размерам чуть больше, но не критично я думаю).
И далее ИМХО переход на 32 разрядные процессоры имеет смысл только для сервиса, или задач обработки изображений.
Да я вообще думаю, что можно было сделать плату с сенсорами и на них ARM32 для нормального обсчета с выдачей углов Эйлера, кватерионов или что там еще может понадобится. На максимальной скорости с нормальным Kalman фильтром.
А все остальное, Навигация, GPS, Телеметрия - потянет и обычная AVR. 😃
Так что, как вариант, можно сделать шилдик под Ардуину с ARM32 на борту и местом под плату с датчиками (AllInOne/FreeIMU). Под это дело можно адаптировать тот же пират.
Внутри там явно какой-то арм, вопрос стоит только в доступности документации от производителя
дык инфа чуть ли не с начала года имеется:
- Two power supply options: internal regulator (3.6 V to 6 V), external regulated voltage (2.4 V to 3.6 V)
- Compact design: 13 x 13 x 2 mm
- L3G4200D: 3-axis digital gyroscope (roll, pitch, yaw), 16-bit data output, ±250°/s, ±500°/s, ±2000°/s selectable full scale
- LSM303DLHC: 6-axis geomagnetic module, ±2 g, ±4 g, ±8 g, ±16 g linear acceleration programmable full scale, from ±1.3 Gauss to ±8.1 Gauss, I2C digital output
- STM32F103REY: WLCSP package, high density performance line ARM®-based 32-bit MCU
- LDS3985M33R: ultra low drop-low noise BiCMOS 300 mA voltage regulator.
- Flexible interfaces: CAN, USART, SPI and I2C serial interfaces; full-speed USB 2.0
- Free ADC channels for external inputs
- In-system ceramic resonator
- Application programming interfaces for firmware upgrading
(мелкий pdf по этому поводу)
если цену сделают как обещали (30-40 баксов), это очень и очень заманчивый модуль.
можно было сделать плату с сенсорами и на них ARM32 для нормального обсчета с выдачей углов Эйлера, кватерионов или что там еще может понадобится. На максимальной скорости с нормальным Kalman фильтром.
опенсорсный и опенхардварный (с натяжкой) CHR-UM6-LT Orientation Sensor давно ждет своих владельцев 😉
Я тут собрался потихоньку мигрировать на STM32 с целью иметь минимум 12 выходов на моторы и 2-3 на подвес и навигационную информацию обрабатывать с частотой 500-1000 Гц. Дальнейшая идея обработка изображения для обхода препятствий и т.д. Попутно сейчас начали возится с Глонасом, поскольку на GL8088 обещают точность 2 метра. Короче собрались приступить к рисованию платы под Глонас и заодно прилепить туда же MPU6000 и MS5611, но как то MPU6000 сложно добываются. Есть в США но отправляют в США, Канаду и Мексику. MPU9150 пока не видно. LSM330DL@ST можно купить на Терраэлектронике, что для нас немного дальше чем в США😒 но терпимо. А с учетом последней информации по LSM333 нахожусь в раздумьях куда двигаться.
MPU6000 я помучил на столе и получил по гироскопам при интегрировании уход <1 град в минуту, шумы акселерометра сравнительно большие (1g=4096 шум ±20 ), но быстродействие радует.
Первые подлеты с MPU6000 тоже понравились. и в сравнении с датчиками предыдущего поколения по моему впечатлению это лучше.
Сравнивалась ArduIMU V3 и APM2 с Crius MultiWii .
Поэтому очень интересует информация по датчикам STM/
опенсорсный и опенхардварный (с натяжкой) CHR-UM6-LT Orientation Sensor давно ждет своих владельцев
За 150$ - позолоченный наверное…
опенсорсный и опенхардварный (с натяжкой) CHR-UM6-LT Orientation Sensor давно ждет своих владельцев
Да вопрос даже не в цене, а в том что датчики получше появились, а у меня такое впечатление, что с хорошими датчиками можно меньше с механикой возится. Вибрации меньше влияют.
Тот же MultiPilot32 переходит сейчас на STM32F4, там и частота побольше и FPU имеется. Так что в новых разработках лучше сразу его использовать.
За 150$ - позолоченный наверное…
дык конкурентов-то нет, вот и творят чего хочут. ST когда еще выкатит свой вариант, да когда еще он до прилавков доберется…
с хорошими датчиками можно меньше с механикой возится. Вибрации меньше влияют.
с хорошими датчиками вибрации можно измерить и учесть их, а без этого влиять они все равно будут.
с другой стороны, древний Flymentor 3D на аналоговых гирах держит вертолет лучше, чем навороченные арду-мега-траляля-пилоты с самыми последними датчиками 😉
MultiPilot32 переходит сейчас на STM32F4, там и частота побольше и FPU имеется.
кстати, бесплатные компиляторы уже умеют задействовать FPU?
кстати, бесплатные компиляторы уже умеют задействовать FPU?
Ну вроде CodeSourcery ARM toolchain поддерживает FPU, тока я не в курсе, поддерживает ли F4
3.4.1. Enabling Hardware Floating Point
GCC provides three basic options for compiling floating-point code:
• Software floating point emulation, which is the default. In this case, the compiler implements
floating-point arithmetic by means of library calls.
• VFP hardware floating-point support using the soft-float ABI. This is selected by the
-mfloat-abi=softfp option. When you select this variant, the compiler generates VFP
floating-point instructions, but the resulting code uses the same call and return conventions as
code compiled with software floating point.
• VFP hardware floating-point support using the VFP ABI, which is the VFP variant of the Procedure
Call Standard for the ARM®Architecture (AAPCS). This ABI uses VFP registers to pass function
arguments and return values, resulting in faster floating-point code. To use this variant, compile
with -mfloat-abi=hard.
дык конкурентов-то нет, вот и творят чего хочут. ST когда еще выкатит свой вариант, да когда еще он до прилавков доберется…
Ну если там готовый софт, то да, может оно и стоит 150$ (хотя навряд ли).
LSM330DL@ST можно купить на Терраэлектронике, что для нас немного дальше чем в США😒 но терпимо.
да ладно?) я тут прал f103c8t6, тут же и светодиодные гирлянды и cp2102,кварцы планарные)LSM330DL едет новой почтой 1-3 дня
да ладно?) я тут прал f103c8t6, тут же и светодиодные гирлянды и cp2102,кварцы планарные)LSM330DL едет новой почтой 1-3 дня
Спасибо, это действительно лучше.
Ну вроде CodeSourcery ARM toolchain поддерживает FPU, тока я не в курсе, поддерживает ли F4
как я понял, ни фига не поддерживает, товарищ примерно так разъяснил:
CoeSourcery, к слову, можно считать погибшим, так как он был куплен, и те теперь везде суют свои шароваровые тулзы. Перспективы туманны.
Использовать CS можно, но он не поддерживает аппаратную плавающую точку. Потому вместо него используют самособранный порт тулчейна linaro. Я пару месяцев назад собирал windows MinGW версию с танцами с бубном, но получил нерабочий ld. С тех пор я этим вопросом не занимался до появления острой необходимости. Текущее состояние того порта я не знаю и даже ссылка на source где-то утрачена.
Дмитрий, а как мне правильно сделать слияние моей локальной ветки с другой веткой (это про CC), чтоб ненапортачить, а то смотрю есть такая sambas/mag_baro_testapp, но перейти нормально в неё немогу
serg@Pirat:~/OpenPilot$ git checkout sambas/mag_baro_testapp
error: Your local changes to the following files would be overwritten by checkout:
flight/CopterControl/Makefile
flight/Modules/Attitude/attitude.c
Please, commit your changes or stash them before you can switch branches.
Aborting
или мне просто переместить пока эти два файла?
запустился я на этой ветке, заброшена видать она давно, даже USB нет, так что несмог даже посмотреть что творится теперь…
спрятать свои патчи - git stash
слияние текущего состояния ветки с чем-то еще - git merge имя_ветки
восстановить свои патчи git stash apply
код для компаса можно стырить из Pololu (331 пост)
даже USB нет
GCS пересобирали? станция просто может не работать с несоответсвующими ветками.
да так в том то и дело что пересобрат, не у неё USB коннекта, сейчас попробую…
неполучилось -
serg@Pirat:~/OpenPilot$ git merge sambas/mag_baro_testapp
Auto-merging flight/CopterControl/Makefile
CONFLICT (content): Merge conflict in flight/CopterControl/Makefile
Auto-merging flight/CopterControl/System/coptercontrol.c
CONFLICT (content): Merge conflict in flight/CopterControl/System/coptercontrol.c
Auto-merging flight/CopterControl/System/inc/pios_config.h
CONFLICT (content): Merge conflict in flight/CopterControl/System/inc/pios_config.h
Auto-merging flight/CopterControl/System/pios_board.c
CONFLICT (content): Merge conflict in flight/CopterControl/System/pios_board.c
Auto-merging flight/PiOS/Boards/STM32103CB_CC_Rev1.h
CONFLICT (content): Merge conflict in flight/PiOS/Boards/STM32103CB_CC_Rev1.h
Auto-merging flight/PiOS/Common/pios_bmp085.c
CONFLICT (content): Merge conflict in flight/PiOS/Common/pios_bmp085.c
Auto-merging flight/PiOS/STM32F10x/pios_exti.c
CONFLICT (content): Merge conflict in flight/PiOS/STM32F10x/pios_exti.c
Auto-merging flight/PiOS/STM32F10x/pios_i2c.c
Automatic merge failed; fix conflicts and then commit the result.
может лучше зайти в ветку вытащить всё что нужно, а потом прикручивать к своей?
flight/CopterControl/Makefile - здесь я прописываю что хочу иметь в прошивке, а в станции?
ну вот же руководство к действию:
fix conflicts and then commit the result.
автоматически слияние проходит когда вы добавили/удалили строчку, иначе каждый конфликтный файлик ручками редактировать и оставлять только нужное.
кстати, а что вы собрались делать с этой веткой? она умеет моргать светодиодом по любой активности барометра или компаса. чтения и тем более записи цифр в дерево объектов там нет.
а в станции?
\ground\openpilotgcs\src\libs\libs.pro - библиотеки, можно отключить opmapcontrol, обязательно огромную glc_lib, sdlgamepad по вкусу
\ground\openpilotgcs\src\plugins\plugins.pro - плагины, соответственно комментируем OPMap, ModelView и GCS Control. до кучи можно Notifier, PipXtreme, HITLNEW
Дело в том, что у меня i2c никак неотображается в станции, хоть бы ошибку какую выдало…