Vbar Touch. Первое впечатление
Ну не в разы, а скорее в два раза. У новых ACCESS арчеров, средняя задержка до 13ms. У модуля кроссфаер тоже самое. +4 ms на межфреймовый интервал S.Bus надо добавить (VBC это касается тоже). Мне кажется, что вы берете данные по frsky 3-5 летней давности, а сравниваем здесь с топовой, самой свежей аппой.
Со шнурком по USB там тоже может быть так, что отклик быстрее лишь по ощущениям. Потому что, большие задержки (в сравнении передатчик-приемник) вносит и буфферизация на USB хосте плюс, если монитор хотябы 60 герц, то добавляется минимум 16мс задержка между командой и отрисованным кадром, а это ни двойной, ни тройной буфферизацией не лечится. И вообще, везде где встречается слово буффер - это значит есть задержка.
Инпут может поступить в любой момент времени, далее осуществляется пересчёт в зависимости от значения инпута. Т.о. следующее положение модели зависит от delta time * value от контроллера. Чем меньше delay между контроллером и движком, тем точнее будет просчитываться положение модели в симуляторе. Критичным в данном случае является время доставки данных от контроллера и fps в симуляторе. Т.е… к примеру, если в 120 fps симулятор работает, это ~8мс на кадр, если задержка у контроллера больше, то симулятор будет ждать данные от контроллера.
Буферизация изображения предназначена не для уменьшения задержек инпута, предназначеня для борьбы с screen tearing (разрыв экрана) и напротив она создаcт дополнительный инпут лаг.
Буферизация изображения предназначена не для уменьшения задержек инпута, предназначеня для борьбы с screen tearing (разрыв экрана) и напротив она создаcт дополнительный инпут лаг.
Двойная и тройная (у опенГЛ) буферизация предназначена для того, чтоб вовремя вывода изображения на дисплей процессор не простаивал, а подготавливал следующий кадр. К tearing это не относится почти никак. Чтоб на экран не выводился непрорисованный фрейм используется вертикальная синхронизация.
UPD. Но да, если рисовать в аппаратный “буфер”, который на данный момент отображается на экране, то никакая синхронизация не поможет. Тут надо отличать софтовую буферизацию и аппаратное переключение страниц.
Двойная и тройная (у опенГЛ) буферизация предназначена для того, чтоб вовремя вывода изображения на дисплей процессор не простаивал, а подготавливал следующий кадр. К tearing это не относится почти никак. Чтоб на экран не выводился непрорисованный фрейм используется вертикальная синхронизация.
UPD. Но да, если рисовать в аппаратный буфер, который на данный момент отображается на экране, то никакая синхронизация на поможет. Тут надо отличать софтовую буферизацию от аппаратной.
Это актуально если у GPU есть что рисовать, и чтобы не ждать CPU, рисуем. Актуально для игр и не актуально для симулятора где мы имеем одну простую модель, с примтивными шейдерами, и 1 источником которая летает внутри sphere / sky box с текстурой и задачей максимально быстро и по возможности похоже отразить действие управления. Если инпут будет долгий, то мы либо попадём в какую-то часть кадра, но уже изменить его невозможно и отрисуем на следующем, либо если fps низкий будем скипать кадры беря актуальный инпут на момент подготовки кадра. Т.о., повторюсь, решающим фактором для симулятора является fps и задержка инпута.
Ну так я об этом и писал
Д
UPD. Но да, если рисовать в аппаратный “буфер”, который на данный момент отображается на экране, то никакая синхронизация не поможет. Тут надо отличать софтовую буферизацию и аппаратное переключение страниц.
Максим, я в рзработке игр 15 лет. Давайте не будем просто продолжать. Вы уже напридумывали каки-то буферы инпутов (наверное про клавиатуру речь) и т.д. Которые если и спользуются то для тач управления или ввода текста. Можно скрутить настройки сима и увидите результат. В жизни вертолёт летает гораздо выше 60 и даже 144 fps
Ну а я 18 лет в низкоуровневой разработке и что?, а на данный момент уже лет 6 как разрабатываю сетевые симуляторы для тестирования роутеров в сетях 4 и 5 поколений, и с сетевыми адаптерами приходится работать через регистры. А подобные заявления в мой адрес, что я мол чего то напридумывал, ну это как то опрометчиво, мягко говоря. Вы хотя бы спросили, что именно я имел ввиду.
Вот вам спецификация контроллера от интел. intel.com/…/extensible-host-controler-interface-us…
С 57 страницы начинается описание архитектуры, вы можете для себя изучить и понять как, где и чего происходит буферизация. Пакет/транзакция ни из какого USB устройства мгновенно в ядре операционной системы не появляется, а максимальная задержка, определяется длинной кольцевого буфера и частотой пакетов/транзакций, а так же как именно устройством настроена толерантность задержки.
Вау ! Да тут собрались СПЕЦИАЛИСТЫ !😃
То есть шанс разобраться в происходящем значительно возрастает!
Но давайте так сказать вернемся “к истокам” …
В системе: пилот - аппа - приемник - исполнительный механизм(серво) - реакция модели.
Работают следующие “задержки”:
Пилот - собственно реакция пилота
Аппа - время от воздействия на стик до момента формирования управляющего сигнала. Включая время отработки АЦП, опрос всех каналов, формирование пакета в данном протоколе и его отправка по ВЧ.
Приемник - время на распаковку (проверки пропущенных пакетов и все такое), формирование канального PWM или Sbas сигнала.
Серво - собственно быстродействие самого сервопривода
Реакция модели - зависит от конструктивных особенностей (площади поверхностей, углы отклонения, центровка и балансировка) и люфтов в шарнирных соединениях.
А еще кроме скорости, огромное значение имеет точность! То есть разрешающая способность, начиная от датчиков стиков и дальше по списку…
В случае с вертолетами, добавляется “черный ящик” ФБЛ которая вносит свои задержки как по железу, так и по ПО … 😵
Подключив (желательно по ЮСБи без промежуточных устройств) аппу к симулятору, ситуация несколько упрощается 😒
Теперь важно оценить это самое “быстродействие/ точность” в поведении симуляторной модели, отбросив субъективность ощущений конкретного пилота …😛
Опять все не просто ! 😉
Измерить задержку между включением переключателя и изменением значения канала (с точностью до 1мс) в пакете S.Bus можно с помощью той же ардуины как для VBCt так и для FrSky. Уже делал для FrSky PWM выходов. На PC не знаю, не занимался этим. Проще всего взять камеру с 1000fps и поснимать одновременно движение стика и ответное движение визуализации канала на мониторе. Потом на раскадровке измерить время отклика.
Все равно те измерения (только передатчик приемник) ничего не решат. Эти же данные написаны у производителя в спецификации к продукту. Я ими и занимался только потому, что тут же на форуме был “спор”, что у frsky задержка аж 60мс.
Если в симе летать комфортно, то что те измерения дадут? Что и в какую сторону настраивать без детального анализа они всеравно не покажут.
+4 ms на межфреймовый интервал S.Bus надо добавить (VBC это касается тоже).
У VBC нет SBUS. Как раз фича в том что приемник встроен в ФБЛ и нет промежуточных протоколов типа SBUS. Поэтому скорость передачи у ВБЦ быстрее других, включая Футаба. Хотя протокол передачи именно Футабий используется FHSS
Об этом я почему то не задумывался. Тогда это минус еще ~4-6 ms
Я писал - то что я почувствовал: летал в симуляторе по воздуху (приемник+ардуино) тут же включил шнурок и полетел гораздо лучше.
Летал на FrSky Taranis+Mikrobeast поменял на VBC+Neo - и полетел гораздо лучше и точнее. Филиппы и ролы стали не размашистые а ближе к одной точке.
А что поменялось? Задержки остались, как вы говорите ну почти такие которые на полет не влияют - а я увидел другую картину. Вертолет тот же самый, сервомашинки и лопасти и аккумуляторы остались те же. Просто замена Аппаратура+Приемний+ФБЛ на другую Аппаратура+ФБЛ.
И топ пилоты квадратов наверное не просто так перешли на Crossfire, им эти миллисекунды ничего не дают.
Просто убирая задержки в одном месте - повышается качество управления ЛА. Да не в разы, но точность возрастает. Попробуйте сами и тогда говорите - что разницы нет.
Та надо бы попробовать. Я своим скептицизмом и прагматизмом отдаляю от себя это событие.
Есть у нас в клубе один начинающий вертолетчик с старым Гоблином и VBC (не touch). Возможно он и поделится, но его еще поймать надо. Достаточно редко его вижу
У VBC нет SBUS. Как раз фича в том что приемник встроен в ФБЛ и нет промежуточных протоколов типа SBUS. Поэтому скорость передачи у ВБЦ быстрее других, включая Футаба. Хотя протокол передачи именно Футабий используется FHSS
FHSS это контейнер / метод передачи. Что там внутри, какой компрессор (алгоритм сжатия) можно же передавать 10кб, а можно и 3 кб но нужен будет распаковка, какой декодер, который может быть soft, но будет создавать задержку, а может и чип паяный - это всё проеприетарщина каждого производителя в которой они сейчас и соревнуются. Замерить можно при желании.
Ну а я 18 лет в низкоуровневой разработке и что?
То что вы не шарите если по простому - тестер или QA судя по компетенциям, может быть PM. Но точно не дев который код копал 18 лет.
😃 Очень опрометчивое заявление. В чем именно я не шарю?
Очень опрометчивое заявление. В чем именно я не шарю?
Пусть будет опрометчивое.
Вау ! Да тут собрались СПЕЦИАЛИСТЫ !😃
Опять все не просто ! 😉
Всё достаточно просто - чем больше данных передаём, тем дольше будет их обработка-распаковка. Теоретически даже может быть prediction (предсказание). Даже в случае с USB, больше кидаем - дольше задержка, меньше кидаем объем payload - меньше латентность (размер буффера разный для 64 байт и для 2 килобайт). Чтобы прокинуть 4 канала ненужно много информации и это там на уровне 0,2ms для одного пакета данных. Никаких там 16-20 ms нет. Поэтому и ощущается разница по шнуру и воздуху. А дальше решает либо депакер (драйвер) софт или хард или какие-то свои методы упаковки / оптимизации. Если всё хранится в Neo, часть данных можно кидать контрольными битами в одном int, а не упакованные integer / float. Грубо говоря в В бар мне нужено перекинуть 1 byte оффсет по кривой с разрешением 0…255, а сама кривая сидит в Neo в виде float значений. То. мне не нужно кидать по радио каналу 4 байта float. Или же паковать его, потом там распаковывать. За счёт этого и достигается скорость.
Давно уже платится за софт.
Какая блин распаковка? По проводу/воздуху данные всегда передаются с избыточным кодированием. О 10/12 слышали? 10 бит кодируются 12тими
Какая блин распаковка? По проводу/воздуху данные всегда передаются с избыточным кодированием. О 10/12 слышали? 10 бит кодируются 12тими
Мы про сим или уже перехали на воздух? Про латентность в USB сначала почитайте или у программеров спросите.
Ещё раз тезисы (для вас Максим персонально):
Важно в случае с симуялтором:
- FPS. Как часто тикает физика. Как часто рисуется картинка. Очень важно!
- Как быстро передаются данные от пульта. Да, представьте себе, задержка зависит от объема данных которые кидаются. 1 байт или 1кб это существенно. Можете почитать спецификацию USB если не верите на слово.
- Движок симулятора тоже может обрабатывать параметры инпута по своему - строить историю ввода и т.д.
- По воздуху, я не сильно компетентен, но полагаю, что работает похожая формула - меньше передаём, меньше задержка. Меньше это значит насколько эффективно пакуем или используем данные. Тоже самое и про избыточное кодирование - либо кодируем больше избыточно, т.к. протокол требует больше данных либо меньше.
- Трипле буффер не ускоряет в случае с симулятором - response time. В лучшем случае у вас будет плавная картинка и инпут лаг в пару кадров. Если дёрнуть шаг в минус и плюс резко, вы получите анимацию с некоторой задержкой.
Если у вас, Максим ещё остались вопросы или вы с чем-то не согласны - пишите мне в л.с. по возможности отвечу. Ещё раз прошу - не сводить тему к упражнениям на различные тематики. Если чем-то вас задел, сорри, не было такой задачи.
Какая разница? Что по USB шнуру, что по воздуху электомагнитная волна распространяется с той же скоростью и подчиняемая тем же законам физики.
Я не понимаю. Вы мне вот ту тавтологию как тестеру написали? Или как PMу?
Какая разница? Что по USB шнуру, что по воздуху электомагнитная волна распространяется с той же скоростью и подчиняемая тем же законам физики.
Разница в количестве передаваемых данных. Меньше передаём - быстрее отклик. Если В бар кидает только оффсеты, а не честные значения, то он будет работать быстрее, но это моё предположение, не утверждаю что так и есть. Но я бы так и сделал, имея все данные на борту внутри Neo, нет никакого смысла кидать честные значения кривых газа или шага и т.д. У нас же по сути по X шкала (это разрешение стика) не имеет большого значения. 5 точек. Значения имеют по Y. Вот они и хранятся на самом вертолёте. Тоже самое и циклик - не обязательно кидать полное значение, достаточно перекидывать дельту (разницу).
Это заблуждение. Частота пакетов и битрейт не пропорционально связаны. Можно передавать большими пакетами 10Гбит без сколь либо больших затрат вычислительных мощностей, а если надо заполнить линк малыми пакетами то, например на архитектуре x86 возникает проблема попадания в кэш. 10Gb линк, например, может дать 14.8Mpps если посылать один и тот же пакет (64b), но если пакет всегда меняется, то скорость падает уже до 10.8Mpps (это на Haswell)
Если у вас это лишь предположение, то это предположение. Чтобы точно знать нужно это проверить.
Это заблуждение. Частота пакетов и битрейт не пропорционально связаны. Можно передавать большими пакетами 10Гбит без сколь либо больших затрат вычислительных мощностей, а если надо заполнить линк малыми пакетами то, например на архитектуре x86 возникает проблема попадания в кэш. 10Gb линк, например, может дать 14.8Mpps если посылать один и тот же пакет (64b), но если пакет всегда меняется, то скорость падает уже до 10.8Mpps (это на Haswell)
Если у вас это лишь предположение, то это предположение. Чтобы точно знать нужно это проверить.
Если у вас есть соответствующее оборудование и компетенции и вы готовы пойти дальше чем текст - было бы замечательно узнать результаты вашего реверс инжиниринга Mikado V Bar Touch. На этом я спать, а вы пишите … пишите.
А так вообще, вы уже меня извините Максим - недорого аутсорсе, а я думаю что точно на 100% в точку попал - ну нее, неее )))