А не сделать ли нам 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, беда в том, что редко сыплется.