А как реализована обработка кейса когда связь разрывается? Останавливается ли телега при реальном разрыве связи и как это реализовано?
ну эт, от самой тележки зависит. в данном случае остановится, т.к. в буфере нули будут, а нули для неё, это «стоп».
А реализацию на голых сокетах не пробовали? Я, например, похожую телегу делаю на RPi, и решил что лучшим вариантом для контролирования разрыва будет сокет — ведь он кидает исключение при разрыве связи.
Да там есть TCP и UDP сокеты на ESP8266 (см. предыдущую статью). Реализацию можно любую сделать. А самой ардуине все равно, есть данные -едем, нет — стоим.
Это не лучший вариант. Так можно контролировать только прямое соединение, а соединение через роутер уже имеет ньюансы — разрыв словится только когда пропадёт соединение клиент-роутер, а не смарфон-роутер. А потом когда смарт переподключится и пошлёт следующий пакет, факт разрыва связи будет установлен только по тому что нумерация пакетов уже другая будет. Поэтому в таких случаях самый надёжный вариант — это жёсткие таймауты(например 1000мс) и UDP.
Когда разорвется связь смартфон-рутер, esp8266 будет по барабану, так как UDP сервер поднятый на ней уже будет работать и будет знать IP адрес смартфона. Поэтому двусторонний UDP канал поднимается снова без проблем. A TCP там используется только для команд управления, поэтому если номер пакета будет другой — вообще не страшно. Команда управления гарантированно в пакет влазит.
Проблема не в IP-адресе, а в том что не будет некоторое время команд и приёмник никак не узнает причину — либо источник и правда не даёт команд, или потеряна связь.
ну у каждого свои ТЗ. В данном случае это не важно. При потере данных всё здесь просто останавливается, пока не установится новое соединение.
А как оно поймёт что соединение пропало? будет выполнять последнюю команду… пока не поступит новая, а она не поступает.
здесь наоборот, каждые 200 мс по udp отправляется команда, допустим "«вперед». Пока телега их получает — едет вперед. Обрыв, в буфере UART ноль — остановка.
Команда принимается считанные микросекунды, остальные 200мс с точки зрения приёмника НИЧЕГО не происходит, но тележка почему-то едет, хотя не должна? В целом, у вас получается работа с таймаутами — 200мс нет новых команд, срабатывает таймаут и останов. И, судя по всему, это происходит именно в WiFi-чипе но суть остаётся такая. И команды на самом деле у вас имеют смысл не «вперёд» а «вперёд следующие 200мс».
не, не так. это я забыл нэмножкэ старый код (там разные варианты были). при обрыве так и едет исполняя текущую команду (на телеге эхолокаторы стоят, чтобы об стену не убиться, но не суть). А как только восстановится канал (сервер на телеге слушает постоянно) работает дальше. 200 мс таймаут, я вспомнил, был у меня для ручного управления, так сказать время реакции человека. Чаше нет смысла слать пакеты.
Смотри, эхолокаторы не видят котов — будут их таранить :-D

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

Для esp8266 в качестве сетевого интерфейса ардуины есть прошивка esp-link, которая умеет всё тоже само только лучше. Плюс можно по воздуху прошивать, не все ардуины, но Nano точно.

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

ездиет


мои глаза…
В Москве многие так говорят — ходиют, ездиют. Я не знаю в чем причина такого феномена. Вроде столица, кому как не москвичам знать русский. Говорю просто потому, что столкнулся с этим года три назад.
объясните, зачем тут ардуино, когда используется ESP8266?? С его скоростью, I2C и SPI и парой сдфиговых регистров (не обязательно) можно и так управлять машинкой.
Можно, но это классические костыли. Здесь же разделение сущностей — ESP8266 занимается коммуникацией, а ардуина — логикой управления, что даёт возможность НЕЗАВИСИМО развивать оба модуля.
Пишете волшебные строчки:
Serial.begin(9600);

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