Программирование и передача данных в «Ардуино» по «воздуху» с помощью ESP8266. Часть Третья. Здравствуй, «ANDROID»

[@argamidon]

А как реализована обработка кейса когда связь разрывается? Останавливается ли телега при реальном разрыве связи и как это реализовано?

[@Tarson]

ну эт, от самой тележки зависит. в данном случае остановится, т.к. в буфере нули будут, а нули для неё, это «стоп».

[@argamidon]

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

[@Tarson]

Да там есть TCP и UDP сокеты на ESP8266 (см. предыдущую статью). Реализацию можно любую сделать. А самой ардуине все равно, есть данные -едем, нет — стоим.

[@Alexeyslav]

Это не лучший вариант. Так можно контролировать только прямое соединение, а соединение через роутер уже имеет ньюансы — разрыв словится только когда пропадёт соединение клиент-роутер, а не смарфон-роутер. А потом когда смарт переподключится и пошлёт следующий пакет, факт разрыва связи будет установлен только по тому что нумерация пакетов уже другая будет. Поэтому в таких случаях самый надёжный вариант — это жёсткие таймауты(например 1000мс) и UDP.

[@Tarson]

Когда разорвется связь смартфон-рутер, esp8266 будет по барабану, так как UDP сервер поднятый на ней уже будет работать и будет знать IP адрес смартфона. Поэтому двусторонний UDP канал поднимается снова без проблем. A TCP там используется только для команд управления, поэтому если номер пакета будет другой — вообще не страшно. Команда управления гарантированно в пакет влазит.

[@Alexeyslav]

Проблема не в IP-адресе, а в том что не будет некоторое время команд и приёмник никак не узнает причину — либо источник и правда не даёт команд, или потеряна связь.

[@Tarson]

ну у каждого свои ТЗ. В данном случае это не важно. При потере данных всё здесь просто останавливается, пока не установится новое соединение.

[@Alexeyslav]

А как оно поймёт что соединение пропало? будет выполнять последнюю команду… пока не поступит новая, а она не поступает.

[@Tarson]

здесь наоборот, каждые 200 мс по udp отправляется команда, допустим "«вперед». Пока телега их получает — едет вперед. Обрыв, в буфере UART ноль — остановка.

[@Alexeyslav]

Команда принимается считанные микросекунды, остальные 200мс с точки зрения приёмника НИЧЕГО не происходит, но тележка почему-то едет, хотя не должна? В целом, у вас получается работа с таймаутами — 200мс нет новых команд, срабатывает таймаут и останов. И, судя по всему, это происходит именно в WiFi-чипе но суть остаётся такая. И команды на самом деле у вас имеют смысл не «вперёд» а «вперёд следующие 200мс».

[@Tarson]

не, не так. это я забыл нэмножкэ старый код (там разные варианты были). при обрыве так и едет исполняя текущую команду (на телеге эхолокаторы стоят, чтобы об стену не убиться, но не суть). А как только восстановится канал (сервер на телеге слушает постоянно) работает дальше. 200 мс таймаут, я вспомнил, был у меня для ручного управления, так сказать время реакции человека. Чаше нет смысла слать пакеты.

[@Alexeyslav]

Смотри, эхолокаторы не видят котов — будут их таранить :-D

Время реакции человека — 100мс, у вас ещё +200 в наихудшем случае — эта задержка уже будет существенной. Я бы снизил до 20-50мс или величину времени за которую тележка проезжает не более 5мм, чтобы это не стало узким местом.

[@Ramzess_II]

Подскажите, а есть способ проверять связь через роутер?

сейчас тоже столкнулся с этой проблемой.

[@Alexeyslav]

Разве что постоянно пинать соединение ничего не значащими пакетами с периодичностью позволяющей достаточно оперативно выявлять пропадание связи(кому-то реакция надо секундная, кому-то раз в минуту достаточно) но - это всё трафик и лишняя нагрузка на сеть(один клиент - фигня, а тысяча таких?), поэтому мало где практикуется.

[@proton17]

Автор объяснил свое отношение к esp-link в прошлой публикации...

[@buratino]

ездиет

мои глаза…

[@Tutanhomon]

В Москве многие так говорят — ходиют, ездиют. Я не знаю в чем причина такого феномена. Вроде столица, кому как не москвичам знать русский. Говорю просто потому, что столкнулся с этим года три назад.

[@besitzeruf]

объясните, зачем тут ардуино, когда используется ESP8266?? С его скоростью, I2C и SPI и парой сдфиговых регистров (не обязательно) можно и так управлять машинкой.

[@Alexeyslav]

Можно, но это классические костыли. Здесь же разделение сущностей — ESP8266 занимается коммуникацией, а ардуина — логикой управления, что даёт возможность НЕЗАВИСИМО развивать оба модуля.

[@Hellsy22]

Пишете волшебные строчки:
Serial.begin(9600);

… и с ходу получаете проблемы. Пока у ESP работает serial — все остальное висит и это подлагивание хорошо заметно. Поэтому всегда стоит использовать максимальную скорость передачи данных.

[@Alexeyslav]

Проблема в том что часто на ардуинке переносят serial на другой порт и используется программная реализация, а там огромные проблемы с большими скоростями, поэтому 9600 работает в любом случае и пока хватает этой скорости — нет причин менять.

[@Tarson]

да, ладно… чему там висеть на 9600. вообще ни разу проблем не было. Только если действительно программно реализовывать, да и то я сильно сомневаюсь.

[@psinetron]

по акселерометру в андроиде — добавьте lowpass фильтр и движения станут намного более гладкими