www.open-tager.ru

Исходные данные такие
Скорость обмена 250кбит/сек, практически это примерно 500пакетов по 32байта за секунду
Выбор из 126 каналов по 1Мгц на скоростях 250kbps и 1Mbps
Для 2Mbps, получается вполовину меньше каналов
http://www.avislab.com/blog/nrf24l01_ru/


Предлагаю начать с "бюрократии"

1. Поделить диапазон каналов(0..126) на дальний(надёжный), средний и ближний(быстрый).
2. Выделить группы адресов(=5байтам)(не путать с каналами) для конкретных применений: оружие, гранаты, артефакты, рации, аптечки, датчики, общее применение.

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

4. Канал на всех площадке предполагается _общий_ то есть узлы всех игроков завязаны в одну сеть.
Чтобы общие события передавались сразу всем игрокам, например звуки обстрела, гранаты, артефакты, статистика.
Если не требуется большая дальность, например чтобы повязка была не слышна другими игроками, программно уменьшаем мощность.

Каналы могут переключатся со скоростью примерно 200мкс + время программа, другими словами реально создать мост переброса данных с одного канала на другой, пока предлагаю этим не заморачиваться. Может быть полезно например для поиска поражённых каналов и постепенным переконфигурированием всех узлов сети без остановки сети. Есть возможность использования одинаковых адресов устройств (несколько одинаковых устройств), и работы с 6 последовательными адресами(фильтрация) на одном канале, хорошо также вписать в эту систему.

_________________
"За 2 месяца максимум можно чертёж сделать, еще за 3 фундамент." (c) Номернабис

Не всё так просто.
Судя по 5 байтам адреса, Вы предполагаете использовать хардварную адресацию nfr24. Но это противоречит идее, чтобы "все слышали всех". Пакеты отсеятся на хардварном уровне.
Также, нужно учитывать особенности работы nrf24: адрес не должен быть произвольным, в нем должны нули и единицы сменяться "достаточно часто, но не очень", иначе будут происходить ложные пропуски пакетов. Это - особенность работы железа. Поэтому я от различных HW-адресов отказался. Все устройства у меня на дефолтном, адресация передаётся в полезной нагрузке. Только так "все смогут слышать всех".

Проектирование радиообмена нужно начинать с определения нужных сетевых уровней, и только потом - их раздельной имплементации. Вы знаете о модели OSI? Конечно, тут не нужно все 7 уровней, тут будет где-то 3-4. Начинать логично с того, что где-то между канальным и транспортным. Т.к. физический у нас уже есть. И только потом подниматься выше.

Я все эти задачи решил. В числе прочего, мой сетевой протокол поддерживает:
- Возможность достоверной доставки пакета (чтобы отправитель знал, дошёл ли пакет, или нет). То есть пакеты с acknowledgement-ами. Это делается НЕ встроенными в радиомодуль средствами по многим причинам.
- Возможность ретрансляции пакетов без перегрузки сети. Причём, любым устройством, в зависимости от ситуации. Но чтобы получить гарантированное покрытие, нужны отдельные ретрансляторы (т.к. игроки склонны бегать по полю ). (Называть такой функционал mesh-сетью не совсем корректно)

Моя система позволяет по радио синхронизовывать любой параметр, а также реализует что-то вроде Remote Procedure Call (RPC).

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

Если готовы делиться информацией, то расскажите как у вас повязка(модуль игрока) с ружьём коннектятся? Железно привязаны друг к другу, или есть возможность любому игроку взять любое ружьё? Как handshake происходит?

_________________
Нет предела совершенству, но ресурсы заканчиваются быстро.

Работает так:
- Чтобы оружие было привязано к повязке, оно должно знать её адрес. Можно записать его в ini-файле. Можно будет настроить через Android-приложение. Позже будут и другие возможности его изменить
- Оружие регистрируется у повязки. Повязка его запоминает в список присоединенных оружий. Этому списку по мере надобности она рассылает команды (включить-выключить, респаун, умереть и т.п.)
Пока оружие не зарегистрировано нигде (повязка не ответила), оно с некоторым периодом непрерывно посылает запрос на регистрацию "своей" повязке.
- Раз в некоторое время оружие посылает heartbeat-команду повязке (проверяет "сердцебиение"). В ответ повязка выдаёт подтверждение heartbeat-а. Оружие знает, что повязка близко и работает. Если ответа нет, оружие выключается, и начинает попискивать, что означает потерю соединения.
Для горячего "отсоединения" оружия от повязки предполагается команда дерегистрации, но это пока не реализовано.

Таким образом, менять оружие можно, но пока ещё не очень удобно. Есть план использовать более удобную штуку, но надо тестировать.

Есть закрытая ветка для разрабов. Там "праздношатающихся" нет! Там безопаснее обсудить. Лично мне интересно. В планах прикрутить таки нордика к Армаде. А можно и через личку - конфиденциальность информации гарантирую. В свою очередь готов Вам предоставить что угодно из своих наработок по вашему запросу. Опять же - при сохранении конфиденциальности.

_________________
Ваше оружие становиться значительно эффективней, если его снять с предохранителя!

Не надо становится неуловимыми Джо, комерсам на такую систему плевать с высокой колокольни


Итак начнём .... Давайте отойдём от шаблонов, мы достаточно грамотные разработчики чтобы не пихать enterprise решения в игрушки. У нас не докторская дисертация, здесь не нужна OSI, дополнительно в реально работающих сетях например IP никогда небыло 7 уровневой модели Надо исходить из функционала который _нужен_ для игры, а для лазертаг игры нужны _события_, а не _данные_!.


1. Протокол доставки точно _не_ должен входить в систему радиоАПИ. РадиоАпи надо описать в терминах UDP, однако у нас радиопакеты всётаки несут не информацию(блок данных) а функцию(событие), как типичные ИК команды. Например повязке или гранате наплевать выключился маркер или нет, при этом от повязки(или наоборот) постоянно передаётся пакет (в вашем термине heartbeat). Ну не пришёл пакет до маркера, ничего страшного придёт попозже, не придёт слишком долго - маркер выключается сам. То есть квитирование не является необходимым элементом для реализации геймплея лазертага, опять таки перестанем мыслить шаблонно, мы делаем не сеть передачи данных, а _игру_.

О пакетах-событиях: информация в событии (для общего канала) должна быть примерно такой
- от кого и для кого(всех)
- ид события, примреная таблица событий
- параметр события, необязательно
- время(счётчик) жизни события: для ретрансляции, завершения активности и тд


2. Ретрансляция и маршрутизация пакетов должна быть отдельной подсистемой, на _отдельных_ радиоканалах. Эта штука медленная, передача пакета по цепочке занимает длительное время соответственно если эти пакеты похранятся в функции роутера и передадутся как-то потом ничего страшного не случится. На первое время эта часть радиоАПИ вообще не нужна, система не заточена на прокат.

Дополнительно давайте определим зачем нужно гарантированное радиопокрытие ?
Пусть какое то событие(ядерный взрыв) не пришло до игрока - значит ему повезло, игра от этого не пострадает. Или не услышал радио пакет "о близком обстреле", значит не повезло. Если это событие(близкий обстрел) придёт заметно попозже - это будет выглядеть глупо В случае Ядрёной бомбы внутри установлен просто мощный радиомодуль 200..300м, квитирование для отметки игрока поражённым для протокола не нужно.


3. Поподробнее (на примерах), зачем это нужно для ХСЛ гемплея, прокат понятно, а вот для личников ?

Было бы интересно сделать в системе "почту событий", в виде "ходячих ящиков" на игроках. То есть например отправить в сеть условное сообщение "игрок такой то заболел". И когда сообщение доберётся до него - игрок выходит из игры. При этом сделать так чтобы у игрока в прошивке не было куска кода принимающего какое то особенное событие "заболел", а просто ему доставлялось стандартное событие из списка. Событие не просто ретранслируется, а именно хранится в модулях игроков, и когда игрок оказывается в видимости передаётся ему.

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


Читал про это, но на практике не столкнулся с такой сложностью, просто после анализа статистики передачи пакетов устройства меняли канал, и применяли там теже самые свои адреса, и всё прекрасно соединялось.


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


В своей _не_ лазертаг системе пробовал использовать кнопку. Сначала поиск устройств между собой на канале регистрации, затем прижимаем кнопки одновременно на обоих устройствах, далее устройства генерируют случайный новый адрес каждый себе и новый канал и обмениюваются этими данными. При отпускании кнопок переходят на новый канал и там подтверждают соединение - результат связи индикация на светодиодах. Работать не будет если на игроке много узлов, придётся выделять какой-то главный модуль типа мастера, им по по идее может стать любой узел.



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

_________________
"За 2 месяца максимум можно чертёж сделать, еще за 3 фундамент." (c) Номернабис

Прямо в точку ! Не нужно никаких прибамбасов. Это только усложняет схемы и .....отвлекает от самого процесса игры.



Еще раз абсолютно верно. Простота - залог интереса широких народных масс

[quote="Pingvin"
Есть закрытая ветка для разрабов. Там "праздношатающихся" нет! Там безопаснее обсудить. [/quote]

В принципе с одной стороны это конечно так, но с другой стороны - получается противоречие с предыдущей цитатой.

_________________
Лазертаг - приходите к нам с друзьями, а лучше со своими врагами.

Ещё раз напоминаю - будет общая плата ядра ARMada/Caustic, считайте - это 40-ногий DIP контроллер!
Шилды легко каждый может сделать сам ЛУТОМ либо вовсе на макетке собрать.

Тут же все равно заводскую плату (ядро) покупать придется!

_________________
Ваше оружие становиться значительно эффективней, если его снять с предохранителя!

+100!
Так и будет!

Нафига пользователю ковырять настройки таймера, DMA, SPI, USART и прочей хрени?!
Запрятать все это глубоко и надолго в либу.
Пользователю дать внятное API.
Давно об этом толкую.

_________________
Ваше оружие становиться значительно эффективней, если его снять с предохранителя!

Я займусь подготовкой документации по своей системе радиообмена в ближайшее время. Может действительно сразу в паблик.



Да ради бога, "отходите от шаблонов". Я всего лишь хотел сказать, что задачу целесообразно разделить на несколько:
1. Физическая передача - нужно научиться программировать радиомодуль.
2-3. Канальный уровень - нужно адресовать пакеты, чтобы они могли доходить от одного конкретного устройства к другому
4. Транспортный уровень - нужно уметь "поддерживать связь" тем или иным образом, прозрачно для приложения. У меня для того есть Acknoledgement-ы, хотя поддерживается работа и без них - это лишь один бит в пакете. Ну и ещё есть некоторые фишки. Не хотите такой возможности - не делайте. Это усложнит жизнь.
5-7. Собственно, сама полезная нагрузка пакета. Какая команда что означает, как сериализуются аргументы команды и т.п.

Эти пункты между собой абсолютно независимы. Мало того, легко сменить любой из этих уровней без ущерба остальным. Если, конечно, код написан нормально.
Если вы предлагаете начать разработку с последнего пункта (5-7) - пожалуйста. Всё равно придётся решить все задачи, которые я описал выше, так или иначе. "Грамотные разработчики", обычно, не пытаются смешивать всё в одну кучу.
И модель OSI - это не какая-то абстрактная фигня, а только лишь призыв: давайте не путать теплое с мягким, и подходить последовательно.

[офтоп]Когда говорят о несоответствии TCP/IP модели OSI, имеют в виду, что сопоставление уровней иногда (крайне редко!) неоднозначное. Например, непонятно, на каком уровне работает ARP, на канальном или сетевом (ARP узнаёт мак-адреса в подсети по айпишнкам). И причина этому не в том, что "ребята просто взяли и сделали, не оглядываясь на теоретиков", а что в те времена, когда создавался TCP/IP, ничего понятно ещё толком не было, поскольку как раз практического опыта было мало. Ещё верно утверждение, что TCP/IPv4 устарел, а OSI не может устареть.[/офтоп]


Ну тут я не могу со всем согласиться. Делайте, посмотрим. Я свою систему сделал и скромно предлагаю своё решение. "Протокол доставки точно _не_ должен входить в систему радиоАПИ" - я так-то про это и говорю, это разные уровни по той же OSI, и они независимы. Если я правильно понял, что именно Вы называете словом радиоАПИ.
И ещё немного моего занудства: не называйте, пожалуйста, ретранслятор роутером. Это совсем разные вещи. Термины давно придуманы, новых не требуется...

В общем, не буду разбирать по цитатам, отвечу так на остальное:

"Ретрансляция - штука медленная" - Это почему? У меня это просто один пакет. И ведь nrf24 слушает только один канал!

Почему я считаю, что HW-адреса, это плохо? - Ещё и потому, что если адрес закодирован в пакете, то легко перейти на другой радиомодуль, если понадобится. Ведь это только замена физического уровня! Меняется только код непосредственной работы с модулем.

Зачем все эти навороты (ретрансляция, синхронизация параметров) личникам? - Во-первых, я нацелен не только на личников, а хочу сделать универсальное решение. И у меня даже что-то получается. Личнику всё равно приятно поменять настройки с телефона, например. Блютус-мост один на несколько человек, думаю, "личники" потянут. А если игра целиком на системе Caustic, то это всё нужно для статистики и управления игровым сценарием, для возможности удобного размещения индикаторов игрового процесса в любой точке поля. И вообще, почему бы не выжать из технологии максимум? Мне не интересно писать простой код, хочется что-то нетривиальное. Я делаю лазертаг не чтобы как можно скорее срубить бабла, и не чтобы сделать ещё один таг8. По большей части, я делаю его по приколу.

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