DIY контроллер для педалей и кнопок

[GranDoxin]

Откуда такая уверенность? в шутерах имхо сложнее невидимые читы сделать...

Нуб будет сливать по несколько секунд с круга. Любой чит, который поможет ему объехать алиена увидят все и сразу. Так как все ошибки будут как на ладони...

Если чит дает преимущество в сотые доли секунды на переключениях, ну пусть десяточку другую на чем то еще - то это не нуб, а довольно быстрый товарищ.

 

в шутерах имхо сложнее невидимые читы сделать...

Я не про сложность изготовления чита.. это другой вопрос. Я про то, что в симрейсинге, если человек не умеет ездить - никакие читы ему не помогут. В шутерах самый криворукий нубас с аимботом будет косить народ как капусту...

 

млин, а че так сложно то? ))) Световых сигналов то у нас нету. А мой упрощенный вариант, когда один лепесток полностью бросил, оно начало схватывать, ну и орудуй вторым лепестком - ваще никак не катит? )))

Катит, катит! Я просто для общего сведения :)

[CAMOJIET]

В шутерах самый криворукий нубас с аимботом будет косить народ как капусту...

Ну айм бот- осовобождает человека от нужды прицеливаться. В симе он будет за тебя рулить. И не будет у тебя ошибок и ты будешь быстрее алиена. Правда не знаю, зачем этому читу вообще человек, но пути читеров мне в целом не понятны =)

Ну или хотя бы будет за тебя жамкать педали все програмно, а рулить помогать с помощью ффб.

[GranDoxin]

В симе он будет за тебя рулить.

Нет сынок, это фантастика :)

Прицеливаться - да, будет.. Рулить - нет. :)

[TOPMO3]

набыдлокодил очередной релиз 0.14

 

добавлены:

- возможность автокалибровки осей

- новый тип типа пина - аналог в кнопку (analog to button). Позволяет преобразовать аналоговые сигналы (потенциометры, датчики) в цифровые кнопки. Порог "нажатия" настраивается

- объединенная ось, которую обсуждали выше. Берется два аналоговых входа и из них строится одна ось. Предназначено в основном для баранок с двумя лепестками сцепления. Есть два режима работы:

1. оба входа дают свой вклад в ось (степень вклада регулируется) - cooperative work

2. каждый вход работает индивидуально, но на общую ось. Можно например один лепесток откалибровать коротко и использовать для обычных переключений передач, а второй сделать более плавным и использовать для трогания

 

также убрал возможность/необходимость формировать S/N девайса. Он теперь всегда формируется автоматически на основе уникального ID чипа

 

[RomanST]

Плату собрал круглую? Работает?

 

Гик-порно фотки будут? %)

[TOPMO3]

Пока нет, все время чем-то другим занят. Как сделаю, фотки обещаю )))

[ZERgyt]

Что то 0.14 пишет файла нет.

[TOPMO3]

там был баг, поэтому файл перезаливал и видимо побилась ссылка

вот рабочая

 

я, если честно, эту тему тут не особо держу в актуальности, вот здесь стараюсь более-менее - https://opensimhardware.wordpress.com/diy-контроллер-для-педалей-и-кнопок/

[TOPMO3]

Выскажите плиз мнения по пользовательскому интерфейсу, как лучше сделать?

 

Проблема:

Не интуитивно понятен процесс калибровки осей. Например, вот первоначальный сигнал с датчика:

Тут пока все понятно. Сигнал полностью ось не заполняет, поэтому нужно калибровать. Пользователь выставляет ползунки:

И после сохранения уровень оси уже показывает полную шкалу. Вот этот момент сбивает с толку - что произошло, почему вдруг сигнал усилился? Т.е. это подсознательно воспринимается как сигнал датчика, а не уровень оси. Дальше пользователь начинает снова двигать  ползунки и все совсем запутывается.

 

Какие варианты решений тут видятся:

1. После калибровки уводить ползунки на края оси, чтобы визуально уровень оси всегда был между ползунками, а значения калибровки остаются только в полях ввода, пример:

из минусов, как я вижу, то что оять будет сбивать с толку - вроде только что двигал ползунки, и вдруг они снова по краям. Плюс нет никакой связи со значениями в полях ввода

2. Показывать ось только между ползунками калибровки:

из минусов - при узком диапазоне калибровки плохо видно уровень оси, непроизвольно может казаться, что ось дает мало дискретных значений

3. Сделать отдельно уровень датчика и уровень оси. Калибровка тогда будет происходить всегда над уровнем датчика, а результат можно увидеть на уровне оси:

минусы - утяжеляет интерфейс, мне более геморно реализовывать )) Уровень датчика сейчас на ПК никак не отсылается, придется это делать как-то дополнительно..

 

Что думаете, какой вариант лучший? может какие другие идеи у кого есть?

[morganchik]

Из второго варианта еще выделю минус. Даже на твоем примере не до конца видно, соответствует ли крайнее (максимальное) значение оси правому ползунку. Может показаться, что ось достигла максимального значения и мы завершим калибровку, а по факту она была заполнена не до конца, буквально на 5-10 пикселей, в результате в гонке мы можем иметь газ, который работает только на 97%. Мой голос тоже учти, ты знаешь за какой вариант я =)

Изменено 20 января, 2019 пользователем morganchik

[TOPMO3]

32 minutes ago, morganchik said:

Может показаться, что ось достигла максимального значения и мы завершим калибровку, а по факту она была заполнена не до конца, буквально на 5-10 пикселей, в результате в гонке мы можем иметь газ, который работает только на 97%

Согласен, это аргумент. Что думаешь по поводу 3го варианта?

[JohnDoe]

Хорошая задачка…

Только мне кажется, что «бегунки» тут лишние — мне было бы достаточно полей с крайними значениями, прогрессбара «потолще» (для лучшего считывания текущего значения ) и кнопки сброса в дефолт.

P.S.

Третий вариант совершенно чудовищный : )

Изменено 20 января, 2019 пользователем JohnDoe

[TOPMO3]

@JohnDoe, ползунки хороши для визуализации близости значения калибровки к уровню оси. Без них пришлось бы понемногу уменьшать значения калибровки, постепенно "подползая" к уровню оси. Цифра значения оси в середине шкалы актуальна только в отсутствие калибровки, потом на нее уже нельзя ориентироваться 

[JohnDoe]

@TOPMO3 

Они безусловно хороши, но не в данном случае.

Вариант 2. Логичнее остальных в плане наглядности, но поля ввода по краям прогрессбара считываются как крайние значения всей оси, а не значения ползунков.

Варианты 1 и 3.  Помимо «вроде только что двигал ползунки, и вдруг они снова по краям», эти схемы не дают возможности «расширить интервал», поскольку ползунки уже в крайних положениях.

 

6 минут назад, TOPMO3 сказал:

Без них пришлось бы понемногу уменьшать значения калибровки, постепенно "подползая" к уровню оси

Честно говоря, не понимаю проблемы…

Прогрессбар же отображает текущее значение — и чтобы предварительно определить «края» достаточно глянуть на цифры в «отпущенном и нажатом» состояниях. А для «тонкой настройки» ползунки «грубоваты» в любом варианте…

[morganchik]

@TOPMO3 третий вариант мне сложно представить. Тут надо вживую смотреть.

[JohnDoe]

17 минут назад, TOPMO3 сказал:

Цифра значения оси в середине шкалы актуальна только в отсутствие калибровки, потом на нее уже нельзя ориентироваться 

Пропустил эту фразу. А что там выводится после калибровки, если не текущее значение оси?

[TOPMO3]

11 minutes ago, JohnDoe said:

Пропустил эту фразу. А что там выводится после калибровки, если не текущее значение оси?

Там текущее значение оси. Но диапазон оси всегда от 0 до 4096. А значения калибровки - на ось сенсора (т.е. на исходные значения от АЦП)

[JohnDoe]

5 минут назад, TOPMO3 сказал:

Но диапазон оси всегда от 0 до 4096

И это нормально — после калибровки в полях слева и справа будут выставлены минимум и максимум, а текущее значение будет укладываться в этот интервал.

Да, тогда проблематично. Полагал, что Raw там выводится так же как в DIView.

Изменено 20 января, 2019 пользователем JohnDoe

[TOPMO3]

Нет, это не так  работает )

АЦП выдает значения от 0 до 4096. Допустим мы откалибровали ось от 333 до 777 - контроллер будет "растягивать" (масштабировать)  значения от 333 до 777 в интервал от 0 до 4096 и выдавать это как значение оси 

Т .е. навежно как откалибровано, винда всегда видит 4К дискретных значений оси от 0 до 4096

[JohnDoe]

Только что, TOPMO3 сказал:

Т .е. навежно как откалибровано

Я уже понял и исправил пост. То есть всё ещё мрачнее, чем выглядело в первом приближении : )

[TOPMO3]

Да, в том то и дело, что RAW нет, это и есть проблема для п.3 ) Так сделано специально, чтобы не нужно было калибровать каждый раз в случае другой винды - калибровка хранится в самом контроллере. 

И это отлично работает, но при калибровке нужно понимать, что происходит. А я пытаюсь сейчас сделать, чтобы это было понятно любому, кто первый раз на это все смотрит )

6 minutes ago, JohnDoe said:

То есть всё ещё мрачнее, чем выглядело в первом приближении

Точно )

[JohnDoe]

21 минуту назад, TOPMO3 сказал:

но при калибровке нужно понимать, что происходит

В этом то и проблема… Задачка и так была интересной, а стала ещё интереснее : )

Но я не совсем понимаю одну деталь… Если нет «общего диапазона», то как оно «обрезается»? Calib Min/Мax же должны учитываться относительно некоего «целого», а оно в твоём случае сразу же масштабируется. Загадка…

И вдогонку — как тогда работает второй вариант интерфейса? Ведь как только изменится положение бегунков «зелёная зона» должна будет сразу «перекалиброваться» и занять весь диапазон. Видимо, я чего-то сильно недопонимаю…

Изменено 20 января, 2019 пользователем JohnDoe

[TOPMO3]

5 minutes ago, JohnDoe said:

Если нет «общего диапазона», то как оно «обрезается»? Calib Min/Мax же должны учитываться относительно некоего «целого», а оно в твоём случае сразу же масштабируется

Min/Max накладываются на исходные значения АЦП. В исходном виде, когда еще нет калибровки, мы видим например, что максимальный сигнал датчик гуляет например около 3500, мы ставим соответственно Max Calib в 3500 и после сохранения ожидаем увидеть, что теперь ось уже будет добивать до своего максимума в 4095. Если немного не добивает, то можем немного скорректировать предел в 3450 например и т.д. )   Аналогично подбирается нижний предел. Т.е. цель - добиться, чтобы на механический ход педали (или еще чего-то) ось выдавала полный диапазон от 0 до 4095 с нужными нам мертвыми зонами при необходимости

  

12 minutes ago, JohnDoe said:

как тогда работает второй вариант интерфейса? Ведь как только изменится положение бегунков «зелёная зона» должна будет сразу «перекалиброваться» и занять весь диапазон. Видимо, я чего-то сильно недопонимаю…

Пока никак не работает, это же фотошоп у меня ))  Но здесь я особо сложностей не вижу. В ГУИ я могу все значения оси пропорционально укладывать между ползунками,  так же как они сейчас укладываются в целый прогресс-бар

3 hours ago, morganchik said:

Может показаться, что ось достигла максимального значения и мы завершим калибровку, а по факту она была заполнена не до конца, буквально на 5-10 пикселей

Кстати, не обязательно ведь ориентироваться на пиксели ) На цифру значения оси лучше - если есть 4095, то в игре соответственно 100% будет гарантировано

[JohnDoe]

16 минут назад, TOPMO3 сказал:

Если немного не добивает, то можем немного скорректировать предел в 3450 например и т.д.

Судя по тому, что я услышал — вторая корректировка будет не на 3450, а (ось то после сохранения «перекалибровалась») на что-то в районе 4020. И при дальнейшем «урезании» оси каждое следующее значение будет больше предыдущего. Так себе логика…

16 минут назад, TOPMO3 сказал:

В ГУИ я могу все значения оси пропорционально укладывать между ползунками,  так же как они сейчас укладываются в целый прогресс-бар

Исходя из этого можно было бы соорудить «искусственный полный диапазон». Но, насколько я понимаю, работать оно будет только в рамках одной сессии… Да уж : )

Изменено 20 января, 2019 пользователем JohnDoe

[TOPMO3]

54 minutes ago, JohnDoe said:

Судя по тому, что я услышал — вторая корректировка будет не на 3450, а (ось то после сохранения «перекалибровалась») на что-то в районе 4020. И при дальнейшем «урезании» оси каждое следующее значение будет больше предыдущего. Так себе логика…

Нет, именно на 3450 )   Калибровка накладывается не на ось, а на значения АЦП. 

Т.е. в нашем примере в первом случае контроллер растягивает диапазон значений АЦП с 0 до 3500 в диапазон оси с 0 до 4096 

во втором случае контроллер растягивает диапазон значений АЦП с 0 до 3450 в диапазон оси с 0 до 4096

В ГУИ отображается именно эта ось, по сути только для контроля, какие значения оси выдаются контроллером