Comments 25
А как реализована обработка кейса когда связь разрывается? Останавливается ли телега при реальном разрыве связи и как это реализовано?
ну эт, от самой тележки зависит. в данном случае остановится, т.к. в буфере нули будут, а нули для неё, это «стоп».
А реализацию на голых сокетах не пробовали? Я, например, похожую телегу делаю на RPi, и решил что лучшим вариантом для контролирования разрыва будет сокет — ведь он кидает исключение при разрыве связи.
Да там есть TCP и UDP сокеты на ESP8266 (см. предыдущую статью). Реализацию можно любую сделать. А самой ардуине все равно, есть данные -едем, нет — стоим.
Это не лучший вариант. Так можно контролировать только прямое соединение, а соединение через роутер уже имеет ньюансы — разрыв словится только когда пропадёт соединение клиент-роутер, а не смарфон-роутер. А потом когда смарт переподключится и пошлёт следующий пакет, факт разрыва связи будет установлен только по тому что нумерация пакетов уже другая будет. Поэтому в таких случаях самый надёжный вариант — это жёсткие таймауты(например 1000мс) и UDP.
Когда разорвется связь смартфон-рутер, esp8266 будет по барабану, так как UDP сервер поднятый на ней уже будет работать и будет знать IP адрес смартфона. Поэтому двусторонний UDP канал поднимается снова без проблем. A TCP там используется только для команд управления, поэтому если номер пакета будет другой — вообще не страшно. Команда управления гарантированно в пакет влазит.
Проблема не в IP-адресе, а в том что не будет некоторое время команд и приёмник никак не узнает причину — либо источник и правда не даёт команд, или потеряна связь.
ну у каждого свои ТЗ. В данном случае это не важно. При потере данных всё здесь просто останавливается, пока не установится новое соединение.
А как оно поймёт что соединение пропало? будет выполнять последнюю команду… пока не поступит новая, а она не поступает.
здесь наоборот, каждые 200 мс по udp отправляется команда, допустим "«вперед». Пока телега их получает — едет вперед. Обрыв, в буфере UART ноль — остановка.
Команда принимается считанные микросекунды, остальные 200мс с точки зрения приёмника НИЧЕГО не происходит, но тележка почему-то едет, хотя не должна? В целом, у вас получается работа с таймаутами — 200мс нет новых команд, срабатывает таймаут и останов. И, судя по всему, это происходит именно в WiFi-чипе но суть остаётся такая. И команды на самом деле у вас имеют смысл не «вперёд» а «вперёд следующие 200мс».
не, не так. это я забыл нэмножкэ старый код (там разные варианты были). при обрыве так и едет исполняя текущую команду (на телеге эхолокаторы стоят, чтобы об стену не убиться, но не суть). А как только восстановится канал (сервер на телеге слушает постоянно) работает дальше. 200 мс таймаут, я вспомнил, был у меня для ручного управления, так сказать время реакции человека. Чаше нет смысла слать пакеты.
Подскажите, а есть способ проверять связь через роутер?
сейчас тоже столкнулся с этой проблемой.
Разве что постоянно пинать соединение ничего не значащими пакетами с периодичностью позволяющей достаточно оперативно выявлять пропадание связи(кому-то реакция надо секундная, кому-то раз в минуту достаточно) но - это всё трафик и лишняя нагрузка на сеть(один клиент - фигня, а тысяча таких?), поэтому мало где практикуется.
UFO just landed and posted this here
ездиет
мои глаза…
объясните, зачем тут ардуино, когда используется ESP8266?? С его скоростью, I2C и SPI и парой сдфиговых регистров (не обязательно) можно и так управлять машинкой.
Пишете волшебные строчки:
Serial.begin(9600);
… и с ходу получаете проблемы. Пока у ESP работает serial — все остальное висит и это подлагивание хорошо заметно. Поэтому всегда стоит использовать максимальную скорость передачи данных.
Проблема в том что часто на ардуинке переносят serial на другой порт и используется программная реализация, а там огромные проблемы с большими скоростями, поэтому 9600 работает в любом случае и пока хватает этой скорости — нет причин менять.
да, ладно… чему там висеть на 9600. вообще ни разу проблем не было. Только если действительно программно реализовывать, да и то я сильно сомневаюсь.
по акселерометру в андроиде — добавьте lowpass фильтр и движения станут намного более гладкими
Sign up to leave a comment.
Программирование и передача данных в «Ардуино» по «воздуху» с помощью ESP8266. Часть Третья. Здравствуй, «ANDROID»