Top.Mail.Ru
Перейти к содержанию

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


Рекомендуемые сообщения

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

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

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

 

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

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

 

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

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

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

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

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

Ссылка на комментарий
  • 4 недели спустя...

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

 

добавлены:

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

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

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

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

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

 

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

 

post-1259-0-33017400-1510263593_thumb.png

  • Нравится 4
Ссылка на комментарий
  • 1 месяц спустя...

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

вот рабочая

 

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

Ссылка на комментарий
  • 1 год спустя...

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

 

Проблема:

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

11.thumb.png.5160200a02a0481a3cf099cc09ef6825.png

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

22.thumb.png.acad5789892416e541c08d0381e08e1a.png

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

 

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

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

33.thumb.png.6e026cfb03034e1ac0a1af9115d206d2.png

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

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

44.thumb.png.aef6d54506a1f15f051fb8cb7902eb82.png

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

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

55.thumb.png.a2fe626c0070ad487013ed5c2402b853.png

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

 

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

Ссылка на комментарий

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

Изменено пользователем morganchik
Ссылка на комментарий
32 minutes ago, morganchik said:

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

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

Ссылка на комментарий

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

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

P.S.

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

Изменено пользователем JohnDoe
Ссылка на комментарий

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

Ссылка на комментарий

@TOPMO3 

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

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

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

 

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

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

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

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

Ссылка на комментарий
17 минут назад, TOPMO3 сказал:

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

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

Ссылка на комментарий
11 minutes ago, JohnDoe said:

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

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

Ссылка на комментарий
5 минут назад, TOPMO3 сказал:

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

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

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

Изменено пользователем JohnDoe
Ссылка на комментарий

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

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

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

Ссылка на комментарий
Только что, TOPMO3 сказал:

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

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

Ссылка на комментарий

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

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

6 minutes ago, JohnDoe said:

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

Точно )

Ссылка на комментарий
21 минуту назад, TOPMO3 сказал:

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

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

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

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

Изменено пользователем JohnDoe
Ссылка на комментарий
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% будет гарантировано

Ссылка на комментарий
16 минут назад, TOPMO3 сказал:

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

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

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

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

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

Изменено пользователем JohnDoe
Ссылка на комментарий
54 minutes ago, JohnDoe said:

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

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

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

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

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

Ссылка на комментарий
  • Последние посетители   0 пользователей онлайн

    • Ни одного зарегистрированного пользователя не просматривает данную страницу
×
×
  • Создать...