А не сделать ли нам OSD?
С 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 не трогая беспроводную скорость
Ищем…
Проблема, что при 57600 дальность связи по модему будет 1000м. Поэтому скорость снижают и перепрошивают MinimOSD на ту же скорость, что и выход APM. Если же 3DR radio может из 57600 внутри себя делать 19200 и посылать в эфир, то уже мелким бесом бегу смотреть, что там куда шить.
Еще раз. 3DR модем и например мой RFD900 имеют две скорости. Одна для внешнего проводного интерфейса, другая для воздуха. Сейчас, по умолчанию, используется скорость проводного интерфейса 57600. По воздуху же данные летят со скоростью 64 килобита. Оно сейчас у всех так. Но реально поток данных не забивает и 64 килобита. А если вдруг будет забиавать и 64 килобита не будет хватать, то, по утверждению Козина (которому я склонен верить), 3DR сам отфильтрует и будет слать не каждую посылку, а ровно сколько пролезает. И не выстраивать их в очередь, а именно отбрасывать. Тут видимо проблемы нет. 57600 так же хватает для частой передачи информации в OSD.
Боды по умолчанию 115200 для связи по УСБ и 57600 для связи по модему, большинство на них и летает. Вряд ли там что перегрузится.
Перегрузится не порт, может перегрузится процессор, так как количество посылок (даже не байт, а именно посылок) будет больше. Значит процессор будет чаще отвлекаться на отправку данных.
Чет у нас тишина. Кто то видимо код пишет уже. Хоть в курсе держите.
Что-то притихло всё.
Есть ли какие-нибудь новости?
По схеме так и не определились.
Нужно там что то еще доделывать или нет? Помогите нам пожалуйста уважаемый Тим и Вахтанг!
Не надо забывать что увеличение скорости пригрузит МК APM. Думаю контроллер там и так работает на грани.
У Арду оригинального, не аиоп, две атмеги, одна на вывод ввод вторая на вычисления. Хз чем они там между собой общаются, но общатся явно успевают.
Вывод на модем я бы все же сделал из ОСД С пониженным бодом. Это будет самый универсальный вариант, и реальзовать вроде как несложно. Тем более что я например без модема летаю, и ставит его пока не планирую. А вот графика минимосд раздражает.