Pull to refresh

Comments 31

нужен еще модуль Qi charger с индикатором заряда в UI - чтобы ставить машинку на зарядку, когда сидя дома по даче поездишь и проверишь обстановку.

и watchdog - чтобы перезапускал зависшую плату.

WDT у ESP32 нормальный, в отличие от ESP8266

Да и не "зависает" если код без ошибок написан. FreeRTOS великая штука!

Какую максимальную скорость сетевого соединения может обеспечить ESP32?

На ESP32, как и на ESP8266, прекрасно ставятся как Espruino, так и Micropython. Чтобы такие небольшие проекты писать на javascript или python, кому что привычнее. По быстродействию они примерно одинаковы. Espruino удобнее из-за встроенной IDE для заливки. Точное выдерживание PWM сигнала для ESC контроллеров для мощных двигателей или гарантированную обработку прерываний, например от датчиков холла, обе версии ESP не тянут по своим внутренним причинам, независимо от языка. Поэтому писать в ардуино среде на голом С для них нет особого смысла, это не поможет. И так как на этих микроконтроллерах обычно поднимается http или websocket сервер со встроенной html страничкой, то писать скрипт для ESP удобнее сразу в одном стеке, т.е. сразу на javascript (Espruino). Кстати, для радиоуправления даже нет необходимости использовать постоянное websocket соединение, отдельные http запросы обе ESP тянут с частотой в 20-30 мс, что сравнимо с классическими RC пультами. И для управления машинкой в html интерфейсе на телефоне удобно использовать слайдеры, а не кнопки.

Точное выдерживание PWM сигнала для ESC контроллеров для мощных двигателей или гарантированную обработку прерываний, например от датчиков холла, обе версии ESP не тянут по своим внутренним причинам, независимо от языка

А можете рассказать по-подробнее?

Это из-за того, что ESP32 и ESP8266 работают не так, как обычные микроконтроллеры. В обычных разработчик чипа предоставляет полное аппаратное описание чипа, и пользовательская прошивка - это единственный код, который работает в микроконтроллере. Программа пользователя только записывает и считывает биты в регистры. А дальше микроконтроллер делает всю работу аппаратно. Это позволяет точно знать число тактов, сколько занимает каждая команда. И, например, задавать точные временные интервалы при генерации ШИМ сигнала. А также вовремя реагировать на прерывания. А у ESP часть архитектуры закрыта, а доступ к аппаратным функциям делается через софтверный API. То есть, параллельно с вашей прошивкой, внутри ESP крутится какой-то код от производителя чипа. Он жрет много ресурсов и приводит к непредсказуемым задержкам. Поэтому ESP не могут выдерживать точные временные интервалы. Это приводит к куче проблем с управлением электродвигателями и сервоприводами (даже с использованием внешних аппаратных драйверов). Моторы могут дергаться, врубаться неожиданно на полный газ и все такое. По этой же причине на ESP возникают проблемы у софтверных реализаций протоколов UART/I2C/OneWire и при обработке прерываний.

В общем, для очень многих точных аппаратных задач esp НЕ МОГУТ заменить ардуино или stm. И это очень жаль, потому что ESP действительно классные и дешевые чипы. Было бы круто все делать чисто на них. Хотя благодаря большой частоте 80/160/240 МГц, эта проблема сглаживается, конечно. Если подключить обычную серву, то она на первый взгляд, даже заработает. Но может непредсказуемо дергаться и глючить. Аналогично с попыткой собрать на базе ESP энкодер на датчиках холла для определения скорости вращения быстрых моторов, с этим совсем беда. Оно то работает, то пропускает прерывания.

Но для простых задач - вроде обработать нажатия кнопок и обеспечивать web интерфейс, ESP прекрасно подходят. Да и пауза между постоянно пересылаемыми GET запросами там на практике всего около 30 мс, что очень круто. Можно на базе ESP делать радиоуправление в почти реальном времени. Но надо быть готовым к тому, что в любой момент ESP может зависнуть на 300-1500 мс. При этом, если вы своим кодом задержите ESP то ли на 1 мс, то ли на 10 мс, то она молча упадет. Вот такая несправедливость =). Через websocket, который держит соединение постоянно открытым и имеет меньше накладных расходов, пауза между пакетами чуть меньше 20 мс (но сами библиотеки weboscket жрут довольно много памяти, если ее не хватает, проще делать на обычных GET запросах, разница невелика).

P.S. В ESP32 двухядерный процессор, вроде можно один выделить чисто под свой код, на который внутренний код от производителя не будет влиять, но это сложно и требует нестандартных процедур при программировании.

Спасибо. Звучит очень печально, конечно.

Я сейчас вижу, что как-то слишком многословно и непонятно описал. Если коротко, процессор ESP занят своей основной работой - поддержкой Wi-Fi. То что мы пишем для него программы - это внедряем свой дополнительный код к тому коду, который на нем уже работает. Причем обработка Wi-Fi для чипа остается основным приоритетом. Поэтому нельзя своим кодом задерживать непрерывно процессор дольше, чем на несколько миллисекунд. Иначе он по watchdog упадет. И обработка сами чипом Wi-FI вносит непредсказуемые задержки, так как у него более высокий приоритет. Это основное отличие ESP32 и ESP8266 от обычных микроконтроллеров, вроде чипов Atmel в Arduino.

У обычных такие аппаратные штуки действительно аппаратные: например, для реализации UART есть буфер, куда ваша программа записывает строку, а дальше микроконтроллер эту строку отсылает аппаратно в течении некоторого времени, не задерживая вашу программу (она продолжает выполняться, как обычно). Но у ESP нет по-настоящему аппаратного Wi-FI. Они обрабатывают его софтверно самим же процессором, на котором крутится и ваша программа. При этом у ESP есть и типичные аппаратные решения, вроде аппаратного UART с его буфером. Таймеры там всякие, регистры и прочие характерные для обычных микроконтроллеров вещи. Что позволяет относиться к ESP и программировать их как обычные микроконтроллеры. Точнее, это и есть обычный микроконтроллер. У которого единственное предназначение - обработка Wi-Fi. Просто из-за избыточной производительности, мы можем внедрять в него свой код и получать доступ к некоторым аппаратным частям, например тому же аппаратному UART, пинам, таймерам, прерываниям и т.д. Но не ко всем. Часть с Wi-Fi разработчиком закрыта и поэтому для ESP невозможно написать полноценную прошивку, превращающую ее в обычный микроконтроллер с полным контролем над его аппаратными ресурсами. Впрочем, для большинства задач это и не нужно.

Мда, коротко опять не получилось, простите). Я просто большой поклонник этих чипов, жаль только в нескольких нужных мне проектах с точным таймингом столкнулся с проблемами из-за этих ограничений. Но главным их достоинством (помимо дешевизны), имхо является возможность запускать на них javascript (через Espruino) и python (через Micropython). На этих языках программирование ESP превращается в сплошное удовольствие, по сравнению с Си. Так как проекты на ESP из-за поднятого HTTP сервера с html интерфейсом обычно получаются более сложные, чем типичные для ардуинок. Поэтому синтаксический сахар этих языков приходится очень кстати.

Спасибо за подробный ответ.
А вот про условные сервомоторы и софтовый API: я верно понимаю что в ESP32 почему-то не используется аппаратный таймер с PWM выходом для этого?

Использует. По крайней мере, Arduino Core и Espruino последних версий (про Micropython не знаю). Но это не очень помогало, т.к. у wifi все равно более высокий приоритет. Но вообще, может я слишком категорично заявлял насчет серво и PWM, возможно это была специфика моего проекта или конкретно моих модулей. Я встречал аналогичные проблемы по форумам, когда разбирался в чем дело. Но в интернете также полно статей, где никакие проблемы с серво у ESP не упоминаются. Наверно надо просто пробовать и все.

UFO just landed and posted this here

Возможно, вы правы, и дело было в конкретном проекте или не очень качественных модулях. В коде ничего необычного - два датчика холла в качестве двухстороннего энкодера, авиамодельный ESC от мультикоптера с быстрой реакцией (т.е. почти без внутренних фильтров) и стандартная библиотека Servo.h (хотя пытался написать и свою). Это была электролебедка, которая могла включаться на 200-300 мс с несколькими десятками оборотов двигателя через редуктор за это время. Поэтому нужно было точное управление, так как даже одиночные пропуски прерываний были нежелательны. Нюанс в том, что в цикле использовался человек, поэтому были повышенные требования к надежности, иначе это могло привести к травмам. И отсюда же было тщательное и долгое тестирование. К сожалению, на обоих ESP8266 и ESP32 на нескольких экземплярах, купленных у разных производителей, так и не удалось достичь надежной работы без сбоев. Либо раз в несколько секунд начинались пропуски прерываний от датчиков холла, либо появлялись случайные задержки в тайминге PWM сигнала более 0.1 мс, что в моем случае означало либо блокировку мотора во время работы, либо снятие с тормоза, когда он в режиме торможения. А на голом Arduino Nano ни разу ошибок не было. Все варианты конверторов логического уровня, разных библиотек, пинов и всего что только можно было придумать, разумеется были перепробованы. Поведение было одинаковым на всех трех Arduino Core, Espruino и Micropython, что и послужило последней точкой, что проблема аппаратная, раз не зависит от разных языков. Я находил по форумам аналогичные проблемы у людей, кто пытался работать на ESP с точным таймингом (например, с PWM управлять напрямую мосфетами). В итоге мы сдались и остались на Arduino Nano V3 (для прототипирования, я имею ввиду). Однако на более простых задачах, быстродействия ESP должно хватать. Поэтому ни в коем случае не говорю, что они принципиально не годятся для управления моторами или сервоприводами по радиоуправлению. Но с осторожностью... У нас не получилось.

UFO just landed and posted this here

Вот насчет этого не знаю. Я сам думал, что wifi и tcp стек в них аппаратные, по аналогии как реализованы другие аппаратные протоколы, вроде uart/i2c. То есть, это отдельный аппаратный блок, общение с которым делается записью байтов в некоторый участок памяти или в регистры. Из которых он сам потом читает и делает свою работу независимо от центрального процессора. Но оказалось, что довольно значительные ресурсы основного процессора как раз заняты обработкой wifi. А наш пользовательский код — только пассажир на этом поезде).


С отключенным wifi я не пробовал. В документации, кстати, пишут что работа в качестве точки доступа более нестабильна и потребляет больше ресурсов, чем в режиме станции (собственно, на esp8266 максимум подключенных клиентов по умолчанию только 4, что тоже говорит об ограниченности ресурсов). Кстати, если кому потребуется именно стабильная работа wifi блока на ESP, то я в итоге пришел к такой схеме: посылать HTTP запросы GET к ESP не по таймеру setInterval(), а последовательно. То есть, обязательно дождаться ответа (какой-нибудь OK со стороны микроконтроллера), а после делать новый GET запрос. Потому что, похоже, накладывающиеся запросы тоже ее сильно нагружают. И дополнительно использовать таймаут в запросах (для fetch() а javascript есть механизм через signal). Иначе пропавшие пакеты или неудачный запрос могут повесить связь на десятки секунд, вплоть до перезагрузки модуля, а со своим таймаутом у вас будет фиксированная задержка не более 500 мс или секунды, сколько поставите. С таким подходом радиоуправление ESP через wifi в реальном времени работает более менее нормально (я его сейчас использую для RC газонокосилки, получается вполне приемлемо, сравнимо с авиамодельными пультами).

UFO just landed and posted this here

Да, если не поднимать wifi и http/websocket сервер, то наверно почти не будет отличаться от микроконтроллеров arduino (atmega) или stm32. Я так понял, именно wifi и его tcp стек много жрут, что аж аппаратный таймер и прерывания могут перебивать (но не всегда, видимо какое-то стечение обстоятельств, вроде слабого уровня сигнала на пределе дальности, и связанные с этим ошибки. Или большая нагрузка от частых запросов (у меня они были каждые 20-30 мс)). За информацию что нормально работает с шаговыми двигателями спасибо, буду иметь ввиду.

По самодельной RC газонокосилке пока особо нечего сказать, так как она не до конца сделана (может позже напишу статью) - обычная бензиновая, к которой приделаны колеса от б/у гироскутера с его родной, но перепрошитой платой . Управление моторами по UART, поэтому ESP32 хорошо вписалась, так как на ней можно параллельно запустить кучу своей логики и сложный HTML интерфейс на телефоне/планшете (что особенно важно на этапе отладки с обратной связью). Я пытаюсь заставить ее определять высоту травы с помощью нескольких ультразвуковых HC-SR04 и лазерных VL53l0X дальномеров и следовать по границе скошенной травы, как делают автоматизированные сельскохозяйственные комбайны. Идея в том, чтобы вручную по радиоуправлению проехать по контуру, а внутри она сама по спирали все скосит сама. Но пока нормально работает только ручное радиоуправление. В будущем хотелось бы прикрутить сегментацию скошенной/не скошенной травы и всех препятствий нейросетью, чтобы сделать полностью автоматической. Я даже обучил пару тестовых нейросеток - на первый взгляд, работает довольно неплохо. Нейросеть успешно различает скошенные и не скошенные участки. Но пока не удалось избавиться от вибраций камеры, это планы на следующий сезон. В этом смысле ESP32 как базовый контроллер очень хорош, потому что к нему одновременно по wifi может подключиться пульт ручного управления (телефон или вторая ESP32 с джойстиком) и внешний компьютер с нейросетью и автопилотом, работающий по камере. От первоначального варианта с Aruco маркерами и определения своих координат на карте относительно них пришлось отказаться, потому что в реальности они камерой телефона определяются всего с 4-5 м, и оказываются часто загорожены листвой/кустами/деревьями.

А не пробовали посмотреть как логика обхода комнаты устроена у роботов пылесосов с лазерным дальнометром? У сяоми первого поколения прошивка была вскрыта и ее можно посмотреть. Или даже сам пылесос использовать как управляющий модуль, правда придется или поставить стены вокруг участка или проложить магнитную ленту и вынести датчик холла вперед косилки.

Да… Идей там можно придумать много) Мне, например, очень нравится идея с визуальной одометрей (ORB SLAM 2), с синхронизацией по редким ARUCO маркерам, стоящим по углам газона. Как это сделано в UcoSLAM. Так газонокосилка сможет ездить между кустами, а маркеры будут синхронизировать с глобальной картой и давать реальный масштаб.

UFO just landed and posted this here

Мне переделка бензиновой обошлась в 2000 руб за б/у гироскутер и ещё два самоцентрирующихся колёсика спреди, кажется по 200 руб за штуку. И управление через ESP8266. Я просто на штатные оси косилки закрепил деревянный брусок 40х40 мм, а к нему прикрутил мотор-колеса родными зажимами, снятыми с корпуса гироскутера. Получилось очень просто и бюджетно. Я наверно напишу статью через пару недель, надо только наделать фотографий и причесать код.

UFO just landed and posted this here

Это выглядит очень круто, чтобы попробовать сделать самому и познакомиться с робототехникой. Закажу комплектующие и отпишу что из этого в итоге получится. Один нюанс только пока не понял, каким образом выставляются вольты на ftdi-преобразователе?

Как правило, перемычкой на самой плате. Паять ничего не нужно, просто переставить.

"р", "р." и даже один раз "руб.", хотя уже давно есть "₽". Но всего в трёх местах число отделено от единицы измерения пробелом (

UFO just landed and posted this here
Тут несколько векторов:
— кружки робототехники, в которых, как правило, либо arduino либо mindstorms. Да и бывают проекты, когда есть красивый корпус, но нет начинки.
— роботы телеинспекции (топ решения слишком дороги). Был проект поездить по трубе, поискать трещины.
— собственные нужды — контроль помещения, игрушка ребенку и т.п.
Так что, полезность присутствует.
По поводу воспроизведения проектов — это бесценный опыт, учитывая, что многие проекты просто не допилены, а некоторые имеют потенциал, который не сразу заметен.

Относительно умных жалюзей — дело хорошее, однако в свой majordomo не стал их внедрять.
UFO just landed and posted this here
Возможно, вы правы. Но по поводу труб, я имел в виду те трубы, в которые может пролезть человек. Но почему-то не хочет… Хотя сложно было что-то предложить кроме хвоста из проводов, хотелось автономного решения.

Контроль помещения тоже разный бывает. Был забавный случай, когда упавшие вещи из корзины на камере напоминали лежащего человека. И рассмотреть поближе не было возможности. А так да, камеры справляются.

В моем понимании «сделать с нуля» — это спроектировать плату, выйти на kickstarter, придумать язык программирования. Шутка.
UFO just landed and posted this here

Хороший проект! я вижу широкие возможности.

Скажите, а текущее изображение с камеры как-то сохраняется в ОЗУ модуля? по коду - нет. Это возможно?

Sign up to leave a comment.

Articles