Управление устройствами по протоколу UDP на Arduino или Raspberry

Тема в разделе "Закажу проект", создана пользователем Йен, 31 окт 2016.

  1. Йен

    Йен Нуб

    Коллеги разработчики!
    Всем приветствие!)

    Для оплачиваемой и интересной работы по ооочень интересным проектам ооочень нужен ТВОРЧЕСКИЙ, смышленый и талантливый специалист!

    Что нужно сделать:
    Придумать, продумать, спроектировать собрать систему управления, плату на базе Raspberry или Arduino, которая будет принимать определенные команды по UDP протоколу и инициировать включение/ выключение определенных электронных компонентов.

    Команды выводятся с ПК из игровых приложений.
    Устройства - это имитация вибрации, световые сигналы, система "брызги", система "ветер" .

    Кому интересно и кто реально умеет) - пишите в ВК https://vk.com/id18631155 или на почту redstar4games@gmail.com Мы в Москве - встретимся все расскажем, покажем.
     
    Последнее редактирование: 31 окт 2016
  2. Igor68

    Igor68 Гуру

    Почему на UDP, а не на TCP? Каким образом и какие команды должны передаваться в сторону Rspberry? Это массив с параметрами (проще и быстрее сделать)? Это строка для анализа команды?
    Если кто-то из ребят возьмётся реализовать - предоставлю простой многопоточный рабочий TCP сервер с модулем реализации управления на Си бесплатно (они у меня на слуху).
     
  3. smart_pic

    smart_pic Нерд

    В некоторых случаях UDP лучше чем ТСР.
    Например , по UDP прилетел пакет, его декодировали и выполнили что надо, а в ТСР еще нужно отслеживать начало-конец команды.
    Плюс UDP на контроллерах работает быстрее
     
  4. Igor68

    Igor68 Гуру

    Что держать соединение по UDP не надо - в курсе! про отслеживать начало-конец команды - это тут не причём! Конечно если мы говорим про ОС - я ориентировался на Raspbian.
     
  5. smart_pic

    smart_pic Нерд

    Если ориентироваться на ОС - согласен с вами.
    А если без ОС на МК?
    Я предполагал на МК. тем более в ТЗ это также есть.

    На МК можно еще повесить ДМХ512 протокол и рулить ШОУ машинами для создания
    <<Устройства - это имитация вибрации, световые сигналы, система "брызги", система "ветер" >>.
     
  6. Igor68

    Igor68 Гуру

    Если на ОС(Raspbian) - дам готовый вариант сервера, с заготовкой управления портами ввода-вывода и т.п. Можно как вариант и Apache + php + bash + Python + Си. По другому варианту на МК - не ко мне.
     
    Последнее редактирование: 31 окт 2016
  7. Йен

    Йен Нуб

    Господа, спасибо за активную дискуссию .
    В нашем случае команда приходит от ПК на Windows из игрового приложения с языком програмирования C#, поступает на наш любимый роспберри и, что не указали в задании еще система должна иметь возможность посылать команды обратно в игровое приложение , используя все тот же UDP.
    Так уж исторически сложилось что именно такая связка работает практически без сбоев.
     
  8. Йен

    Йен Нуб

    Кстати, выкладываю более подробную "хотелку" проекта:

    Что мы хотим получить?
    по сути нам нужен многофункциональный универсальный игровой контроллер для получения и обратной отправки команд из игрового приложения, запущенном на отдельном ПК (Windows)
    Что он должен "уметь":

    На прием по UDP протоколу:
    По сигналу из игры включать и выключать электронные механизмы.
    1. В проекте это - система "ветер" -вентилятор 220в , мощностью до 150 Вт с вариацией силы ветра.
    2. Система "вибро" - мотор 12в или 220в в эксцентриком на валу, для имитации вибрации.
    3. Система "брызги" - это обычная водяная помпа 12в от омывателей стекла для авто.
    4. Световая индикация - 3 контурная светодиодная подсветка с "морганием" и плавным затуханием.
    На обратную передачу в игру по UDP протоколу:
    1. Гироскоп - представьте себе, что вы стоите на доске, на которой прикреплен гироскоп, а доска стоит на пружинах. Вы наклоном тела изменяете ее наклон и передаете команду в игру так как будто это джойстик.
    2. Кнопки "действие" - как на игровом пистолете - при нажатии на кнопку контроллер посылает обратно в игру команду. таких кнопок нужно 4-ре.
    3. Ручка "газа" или педаль "газа" - как на мотоцикле, при повороте - сигнал подается в игру и увеличивает "тягу".


    Пожалуйста дайте ориентир по срокам и стоимости.


    Для ответа можете написать мне "Вконтакте" https://vk.com/id18631155
     
  9. smart_pic

    smart_pic Нерд

    Вопросы к ТЗ:
    Вопрос по пункту №1: Каким способом переключается "сила ветра" - А) ступенчато, плавно. Б) тип используемого мотора для "ветра" , можно ли его регулировать ШИМом?
    Вопрос по пункту №2: Силу вибрации не регулируем или все же регулируем . Если не регулируем то просто делаем вкл-выкл
    Пункт 3 - понятен.

    Тип гироскопа ? Или это на усмотрение разработчика?
    С газом, кнопками , поворотом руля понятно

    !!! Самое важное формат команды на отправку и получение
    Частота обмена командами. Я так понимаю , что команды должны на опрос датчиков посылаться с какой то периодичностью - КАКОЙ?

    Здесь предложили два пути реализации: на МК без ОС и с использованием ОС.
    Ваш выбор?
     
  10. Йен

    Йен Нуб

    №1 Можно ступенчато . Можно ли его регулировать ШИМом, да
    №2: Силу вибрации было бы идеально сделать 2-х уровневой.
    Тип гироскопа - на Ваше усмотрение.

    По типу команды и ее периодичностью сегодня напишу
     
  11. smart_pic

    smart_pic Нерд

    Пошли вопросы и .... клиент исчез
     
  12. smart_pic

    smart_pic Нерд

    Позвольте не согласиться.
    При ТСР соединении данные поступаю последовательно и могут дробиться на мелкие пакеты или объединяться. ТСР аналогично приему данных по СОМ порту. Поэтому приходится отслеживать начало и конец команды. Часто признаком конца служит 0x0D 0x0A . А ОС уже эту комбинацию воспринимает как ввод данных.
    При UDP если пришел пакет, то все данные внутри этого пакета. мы знаем его начало и длину, поэтому проще сделать обработку.
     
  13. Igor68

    Igor68 Гуру

    В случае потока (конец строки и т.п.) - вы правы. В случае блока - каждый параметр по своему адресу в блоке.