А не сделать ли нам OSD?
Сто процентов у нас совершенно разные принципиальные решения, судя по заявленным параметрам
Ага, оба поди на stm32 + 1881 и оба показывают OSD. ДА так что прошивки поди подходить будут.
О, строгая цензура не дремлет! А что Вахтанг теперь больше ничем заниматься кроме ваших плат права не имеет? Вы его купили в личное пользование?
Вахтанг может рассказать о схемотехнике девайсов что-то такое, чего я рассказывать не хочу. Так что тон свой язвительный оставьте при себе и делайте ОСД самостоятельно.
Тем, что по-человечески обращается за советом, я с удовольствием помогаю. Спросите у любого разработчика электроники, засветившегося в форуме.
Ну так вы ему в личку напишите, что рассказывать, а что нет. А то мы обратились за советом, и где же ваша помощь? Что-то ее не видно. Или то что я про ваши цены так говорю, вам претит? Я только факты констатирую. Ничего не придумываю. В чем проблема?
А то мы обратились за советом, и где же ваша помощь?
Ну макс я бы не советовал, а в остальном ход мысли у тут правильный.
Ардупилоты поддерживают нормальную частоту обновления данных в этих своих протоколах?
Ардупилоты поддерживают нормальную частоту обновления данных в этих своих протоколах?
Я писал об этом выше. 16 герц на практике получается стандартными средствами для параметров:
oll float Roll angle (rad, -pi…+pi)
pitch float Pitch angle (rad, -pi…+pi)
yaw float Yaw angle (rad, -pi…+pi)
rollspeed float Roll angular speed (rad/s)
pitchspeed float Pitch angular speed (rad/s)
yawspeed float Yaw angular speed (rad/s)
airspeed float Current airspeed in m/s
groundspeed float Current ground speed in m/s
heading int16_t Current heading in degrees, in compass units (0…360, 0=north)
throttle uint16_t Current throttle setting in integer percent, 0 to 100
alt float Current altitude (MSL), in meters
climb float Current climb rate in meters/second
Остальные сильно реже передаются.
С 16 Гц будет всё плохо. Выше никак?
С 16 Гц будет всё плохо. Выше никак?
Дело в том, что там телеметрия и OSD сидят на одном уарте. Если поднять скорость для OSD, то телеметрия (вроде 64 килобита стандартно воздушная скорость) может уже и не справится с потоком. Пробовать надо.
Но без доп настроек вообще порядка 8-10 герц MinimOSD выводит. И когда я поднял частоту в 2 раза, в мишин планере (на компе) все стало на много плавнее отображаться, по мне так просто идеально (после 8 герц то).
Не пролезает и надо разгонять порт потому что протокол уродский? Если это так, то понимаю.
Я писал об этом выше. 16 герц на практике получается стандартными средствами для параметров:
oll float Roll angle (rad, -pi…+pi)
pitch float Pitch angle (rad, -pi…+pi)
yaw float Yaw angle (rad, -pi…+pi)
rollspeed float Roll angular speed (rad/s)
pitchspeed float Pitch angular speed (rad/s)
yawspeed float Yaw angular speed (rad/s)airspeed float Current airspeed in m/s
groundspeed float Current ground speed in m/s
heading int16_t Current heading in degrees, in compass units (0…360, 0=north)
throttle uint16_t Current throttle setting in integer percent, 0 to 100
alt float Current altitude (MSL), in meters
climb float Current climb rate in meters/second
Это точно не индусы писали?
ЗАЧЕМ 4-байтовый флоат гнать там, где хватит 2 байта с фиксированной точкой или даже 1 байта?
Или оно вообще текстом идет?!
Вы за счет одной только правки рук ардуписателям утопчете объем раза в 3. Сможете переписать обмен с наземкой и с осд - все проблемы вылечите махом.
е пролезает и надо разгонять порт потому что протокол уродский? Если это так, то понимаю.
порт на самом АП 57600 (у телеметрии и OSD соответсвенно тоже 5760), но на сколько я понял у самой телеметрии скорость по воздуху сильно ниже (64 килобита). Формально сейчас поток порядка 10 килобит (ну очень грубо я прикинул). Если даже будет 20 то должен пролезть, но там всякие ретрейны пойдут или еще что, я просто не знаю.
Это точно не индусы писали?
ЗАЧЕМ 4-байтовый флоат гнать там, где хватит 2 байта с фиксированной точкой или даже 1 байта?
Или оно вообще текстом идет?!Вы за счет правки мозга ардуписателям утопчете объем раза в 3.
Вы не забывайте, это опенсорс. В нем всегда так. 😃 Гонится конечно не текстом. Править мавлинк ни кто не будет наверное (достаточно много продуктов его уже используют). Конкретно нам самим патчить каждую новую прошивку тоже не вариант. Будем работать с тем что есть. Кстати кроме траффика там могут быть другие проблемы. Например если АП будет в два раза чаще отвлекаться на отправку сообщений (пусть и меньшего объема), у него основные алгоритмы могут начнут тормозить, там же далеко не STM32 используется проц.
Тут по поводу того, что телеметрия на радиомодем в APM должна идти с меньшей скоростью а в OSD желательно c большей. Возможно ли сделать некий “переходник” или “контроллер” или “процессор” с двумя серийными интерфейсами в один приходит от APM со скоростью 57600 (а по USB допускается до 115200 и ничего не тормозит), а из другого уже данные выдаются на радиомодем со скоростью 19200 например (у меня 2000м по земле обеспечивает, там каждый свою скорость должен поставить). Конечно, надо будет внутри править поле скорости передачи и сделать это все в обе стороны. Зато вполне можно объединить с OSD проектируемым.
ЗАЧЕМ 4-байтовый флоат гнать там, где хватит 2 байта с фиксированной точкой или даже 1 байта?
Ну так может быти сделать некое расширение Мавлинка, например #150 с параметрами из #30, но чарами, а не флотами? И гнать его, махонького, с желательной частотой.
Блин, парни. Не загоняйтесь. Какая к черту правка протоколов. Вы хотите сделать OSD которым смогут пользоваться три человека???
Вы хотите сделать OSD которым смогут пользоваться три человека???
Тогда нужно смириться с частотой мавлинка и обрабатывать то, что есть. А если проект будет опенсорцный, то кто захочет(и сможет 😃 ), тот подправит.
Блин, парни. Не загоняйтесь. Какая к черту правка протоколов. Вы хотите сделать OSD которым смогут пользоваться три человека???
Конечно ни кто не будет править протокол. И самое главное нет уверенности что это поможет. Проблема может быть не в трафике, а в частоте посылок.
“процессор”
Имелось в виду что-то такое:
Имелось в виду что-то такое:
Проблема не в скорости порта (по проводам), а в том сколько может сама телеметрия реально передать. Если она вдруг не справится, то значит OSD должна фильтровать данные и посылать некоторые пакеты “через раз”. Но я третий раз напишу. Возможно что и сам процессор APM не справится с увеличившимся _числом_ посылок, он должен будет чаще прерывать основную работу управления ЛА для того что бы отправить данные. Этот вопрос надо исследовать.
Имелось в виду что-то такое:
Там и так в радиомодем сыплется на 57600, беда в том, что редко сыплется.
вроде как в 3др модемах в режиме мавлинк все это реализовано,
в смысле если данных больше чем он может передать то он выбирает по приоритетам,
модем и порт можно настроить на скрость линии 115200 не трогая беспроводную скорость
тоесть по идее можно настраивать объем данных с избытком по потребностям осд
вроде как в 3др модемах в режиме мавлинк все это реализовано,
Не знал что модем проверяет и фильтрует данные. Это хорошо. Тогда схема из поста 202 теряет смысл. Текущих 57600 хватит гарантированно на все посылки для OSD.
Остался второй вопрос.
Не надо забывать что увеличение скорости пригрузит МК APM. Думаю контроллер там и так работает на грани.
екущих 57600 хватит гарантированно на все посылки для OSD
Проблема, что при 57600 дальность связи по модему будет 1000м. Поэтому скорость снижают и перепрошивают MinimOSD на ту же скорость, что и выход APM. Если же 3DR radio может из 57600 внутри себя делать 19200 и посылать в эфир, то уже мелким бесом бегу смотреть, что там куда шить.
Не надо забывать что увеличение скорости пригрузит МК APM
Боды по умолчанию 115200 для связи по УСБ и 57600 для связи по модему, большинство на них и летает. Вряд ли там что перегрузится.
модем и порт можно настроить на скрость линии 115200 не трогая беспроводную скорость
Ищем…