Создание собственной системы стабилизации
Самый лучшый вариант (так по секрету) берём мосх в каропке(F4 естественно) - и в коробку к нему засовываем overo(оно мааленкое, но злостное), по spi или can) - получаем полётнег у которого всё есть - мосх летать умеет, а overo с видео и линуксом дружить - оно конечно дороже чем малина но зато малюпааахонькое и прячеццо везде… Надо разграничивать задачи ИМХО…
Имеем - старший младший - да как угодно - один заклинило второй домой принёс, второй заклинило первый СОС кричит и данные какие может собирает если надо… можем второй мосх в горячем резерве таскать - видим первый неадекват второй - подрубаем…
Кстати, в переписке как раз и говорят, что мол AR.Drone уже давно как под Cortex A8 1GHz и много памяти и SDK и другие приблуды, а мол флагманский продукт Pixhawk - всего на F4 (типа не успели родить, а оно уже морально устарело).
Это видимо для лего-программирования, СДК наверно позволяет подрубить какое-нибудь образно-графическое ИДЕ. Для широкого рынка НЕПРОФИ и НЕХОББИ (компактный игрушечный аппарат, с достаточной автономностью) это важно.
сделать паузу, перестать добавлять новые фичи и довести до ума то что есть. - ИМХО вот это было бы дело.
вот я тоже в целом за это, хотя не в курсе чего у них там не доделано… вроде всё летает?
Надо разграничивать задачи ИМХО…
Вот это очень правильно, и Ф4 для полетника пока за глаза, ну если не навешивать на него глаза, пространственные радары и ИИ.
Ну по сути распыляться на множество проектов и выпускать недоделанные продукты это не айс, блин по сути у них из-за бага с ГПС квадрики бывает улетают)))) а они линукс линукс, итак функционал зашкаливает, дальше только интеллектуальные системы.
Ах ха ха, пока мы тут пытаемся сделать STM32F4… Дидроновцы уже обсуждают, куда дальше идти ))))) VR Brain то же вроде имеют уже более мощный контроллер…
Если я правильно понял, все катится к Linux подобным решениям и соответствующим процессорам. Уже сейчас делают порт (не дидроновцы, хотя HAL под Linux какой то уже есть) под BeagleBone Black, да и вроде под RPi то же.
В общем, с нашими ресурсами(временными, материальными), плестись нам в хвосте паровоза )))
Добрый день! Со своей колокольни могу сказать (лежит прям передо мной BBBlack), что Linux - не Real Time OS. Там latency мама не горюй. Сейчас вот пилю windows embedded 2013 на эту плату. Старт платы 7 сек до полной загрузки системы. Плюс ко всему это самая настоящая real time os.
Плюс на BBBlack аппаратное граф ядро, по умолчанию можно сразу фпв прикручивать.
Надеюсь к лету допилю хотяб альфу полетника
У меня вопрос к знатокам:
Кто нибуть может объяснить мне доходчиво - что есть у MPU6000 параметры “bandwindth” и “delay” в (регистре 0х1А), то что это “ширина полосы” и “задержка” я знаю 😃, а вот какой полосы или чего полосы не пойму,…
Предполагаю что (в виду наличия “delay”) при установке значения 0х1А , отличного от нуля, он начинает просто пропускать циклы измерения в положенной ему полосе 1 Кгц…?? Я прав ?
Добрый день! Со своей колокольни могу сказать (лежит прям передо мной BBBlack), что Linux - не Real Time OS.
Так никто и не говорит про обычную Linux, они то же есть RT.
Плюс на BBBlack аппаратное граф ядро, по умолчанию можно сразу фпв прикручивать.
Как прикручивать? Что даст граф. ядро?
Как прикручивать? Что даст граф. ядро?
Например: видео идет с цифровой камеры, дальше накладывается OSD и идет на HDMI выход (или через IP протокол) (дальше например цифровой downlink на землю) - в общем, все в цифре.
А зачем это инерциалке???
хотим птиц в свиней в полёте гонять - так это отдельный модуль инерциалке это никак не нужно…
Как прикручивать? Что даст граф. ядро?
Добавлю к предыдущему оратору:
граф ядро позволит использовать одну камеру HD для съемки с борта, а также для передачи на землю СЖАТОГО сигнала с телеметрией и т.д.
И да, я наконец-то допилил свой spyderquad до полноценного БПЛА. Ночью отрывался от пола дома. Вечером на воздухе совершу первый полет, и выложу все в тему про CC3D, так как использую именно этот контроллер.
граф ядро позволит использовать одну камеру HD для съемки с борта, а также для передачи на землю СЖАТОГО сигнала с телеметрией и т.д.
а видео кодировать графическое ядро умеет? хватит ли ресурсов на все?
а видео кодировать графическое ядро умеет? хватит ли ресурсов на все?
там на видео отдельный проц с уже зашитым кодеком x264 и еще какими-то.
А зачем это инерциалке??? хотим птиц в свиней в полёте гонять - так это отдельный модуль инерциалке это никак не нужно…
Да чего вы уперлись в эту инерциалку? Инерциалке даже STM32F4 не нужен! Посмотрите на мультивий, он прекрасно живет и без 32 бит.
Кто нибуть может объяснить мне доходчиво - что есть у MPU6000 параметры “bandwindth” и “delay” в (регистре 0х1А), то что это “ширина полосы” и “задержка” я знаю , а вот какой полосы или чего полосы не пойму,…
Не знаю, я брал описание здесь www.i2cdevlib.com/devices/mpu6050#registers
Инерциалке даже STM32F4 не нужен! Посмотрите на мультивий, он прекрасно живет и без 32 бит.
Тама как бы не совсем инерциалка, да хочется сделать ИНС надежней и стабильней, не размениваясь на целочисленную оптимизацию.
там на видео отдельный проц с уже зашитым кодеком x264 и еще какими-то.
чето я не нашел у am3359 аппаратного x264 кодека, может конечно плохо искал)))
чето я не нашел у am3359 аппаратного x264 кодека, может конечно плохо искал)))
Кто нибуть может объяснить мне доходчиво - что есть у MPU6000 параметры “bandwindth” и “delay” в (регистре 0х1А), то что это “ширина полосы” и “задержка” я знаю , а вот какой полосы или чего полосы не пойму,…
- Delay - это не параметр.
- DLPF - Это Digital Low Pass Filter - Любой сигнал выше указанной частоты, будет обрезан. Грубо говоря, можно отфильтровать быстрые вращения (вибрация). Потому как коптер - штука достаточно медленная (инерционная) - поэтому высокие частоты - это шум и вибрация, которую можно отбросить. Обычно этот фильтр выставляют в 20 или 42 HZ. Теперь Delay - если фильтра нету, то Delay = 0, если фильтр включить, то MPU надо собрать несколько отсчетов, что бы подсчитать частоту сигнала и отфильтровать его (если надо), поэтому появляется задержка между реальным измененим и когда MPU выдает их на выходных регистрах.
так это програмный декодер, а таблица показывает загрузку CPU при использовании разных кодеков.
так это програмный декодер, а таблица показывает загрузку CPU при использовании разных кодеков.
Да нету там аппаратного энкодера h.264, есть сопроцессор NEON, который может ускорить кодек, но есть ли такие кодеки с подержкой NEON я не знаю.
Ладно, тема действительно выходит за рамки этого топика (хотя других мест и нету где это обсудить можно)
Да, действительно аппаратно нигде не заявлена поддержка 335х кодеков, видимо попутал с 35х, 37х линейками.
Но тема интересная на самом деле, и думаю, что понятие собственной системы стабилизации включает в себя понятие SoC, ну или на крайняк ARM 😃
Да нету там аппаратного энкодера h.264, есть сопроцессор NEON, который может ускорить кодек, но есть ли такие кодеки с подержкой NEON я не знаю.
У TI вроде есть SDK она может и сгенерит код, который будет по максимуму использовать ресурсы контроллера. но загрузка CPU большая, только и будет кодировать)))