• Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

Подключение датчиков типа 10-DOF - акселерометр, гироскоп, магнитометр, температура, давление...

pvvx

Активный участник сообщества
Подключение к ESP датчиков типа 10-DOF (акселерометр, гироскоп, магнитометр, температура, давление, …)

Отлаживаю драйвер для ESP8266 с датчиком на основе блока 10-DOF GY-91:


Пока драйвер успешно живет и тестируется в IRAM (тестовая трансляция и исполнение без прошивки в Flash, а только с загрузкой в память ESP8266 из Eclipse).

Развиваемая скорость сбора обработки данных, при 30% занятости CPU ESP8266 переваливает за 1000 точек на каждый параметр каждого датчика (это поток более 40 кбайт нативных данных в секунду).

Оптимально, чтобы не мешать работе SDK и прочему, решил настраиваться на поток не более 100 точек в секунду. Тогда, пример загрузки шины HSPI (с выводом на UART отладки), выходит примерно такой:
ESP-SPI-10-DOF.gifESP-SPI-10-DOF2.gif
Выходной формат нативных данных уже скорректирован по информации с самих датчиков, но float не применяется, т.к. далее будет необходимо осреднение данных для записи в лог, а в float ESP не успеет обработать такой поток.
Код:
IRAM only SDK Init.
Free Heap: 81096
Free IRAM: 60216
HSPI CLK = 1000000 Hz
Init BMP280...
BMP280 id: 58
Dig BMP280: 4a 6b a9 67 18 fc e8 92 38 d6 d0 0b c5 0a 19 01 f9 ff 8c 3c f8 c6 70 17
Regs BMP280: 0c b7 10 00 80 00 00 80 00 00
Temp: 20.75 C, Press: 79857 Pa
Init MPU9250..
ID MPU9250: 71
ID Mag: 48
Mag: 48 9a 00 7b ff ab ff 41 fe 10 12 00 00 48 9a ac ae a2 00
F(1): 2215,98720,M(-154,-105,-228),A(8164,7348,12076),G(-4,74,-116)
F(1): 2224,98720,M(-149,-96,-228),A(8108,7300,12076),G(-5,30,-86)
F(1): 2232,98722,M(-152,-96,-224),A(8116,7292,12048),G(5,71,-141)
F(2): 2237,98721,M(-154,-94,-222),A(8116,7372,12092),G(-17,12,-49)
F(1): 2241,98725,M(-143,-104,-227),A(8128,7356,12000),G(-12,46,-66)
F(1): 2244,98723,M(-153,-90,-226),A(8160,7380,11984),G(1,75,-159)
F(1): 2247,98724,M(-151,-97,-225),A(8140,7352,12152),G(8,70,-153)
…
Т.е. данные с датчиков полные, с фиксированной точкой. Например для температуры 2247 - надо делить на 100 и выйдет 22.47 С. С этим успешно справиться и java, отображающая данные на Web странице.

Концепция применения драйвера для народа пока не выработана. По этому и создал тему. Необходимо решить область применения или куда и как есть желание использовать. Только после этого драйвер приобретет вид возможный для публикации. Пока я его адаптирую только под свои нужды и уверен что народу такое не надо. Но побочный вариант, после консультации тут возможно родит отдельный открытый драйвер для всех :)

Пока видится такое использование (общие цели):
  1. Передача потока с датчиков в реал-тайм на какой-то внешний сервер.
  2. Накопление и осреднение данных этого потока для проекта сервера статистики с циклической записью данных за промежуток в 1 год с шагом от 5 до 15 минут с графическим выводом для web-свалки.
  3. Драйвер ориентирован на фоновую работу (работу по прерываниям).
Минимальный шаг записи усреднения зависит от размера flash. Для основы берется 4 Мегабайтная flash в модуле ESP8266, с распределением до 3-х мегабайт под циклическую запись годового буфера данных за последний год, с износом flash через год*кол-во возможных перезаписей для конкретной flash. Это где-то от 10000 лет :) Быстрее китай-SDK убьет сектора со своей перезаписью настроек WiFi…
Жду комментов, рекомендаций и метод оптимизаций и т.д. под это дело... Да и вообще куда ещё в народном творчестве возможно использовать данную связку ESP-X-DOF?
Особо приветствуются указание открытых проектов отображения 3D данных с таких датчиков для Web концепции (java/ajax/flash/swf/...).

PS: драйверы для АрДурино не предлагать - они не умеют работать в фоне или требуют мультизадачной системы, да ресурсов, которых нет у ESP8266 и ESP32. Тем более у Дурины Spiffs, который не даст никому работать своими задержками и множественными перезаписями flash c длительными стираниями, во время которых работа ESP невозможна.
 
Последнее редактирование:

pvvx

Активный участник сообщества
А как такое можно делать? Если можно, чуть подробнее.
А что мне за это будет? :) Это надо с примерами и всё такое, типа в git проект мне создавать и выкладывать...
-----
Вот сделал для вас:
https://github.com/pvvx/iramsdk
Что дадите в замен? Или просто смоетесь? :)
 
Последнее редактирование:

windalser

New member
А что мне за это будет? :) Это надо с примерами и всё такое, типа в git проект мне создавать и выкладывать...
-----
Вот сделал для вас:
https://github.com/pvvx/iramsdk
Что дадите в замен? Или просто смоетесь? :)
Спасибо. Попробовал, компилируется, пример работает.. Как я понял, это полезно для разработки отдельных кусков программы, которым не требуется связь по wifi,
например, какого-нибудь драйвера.
Хотя, мне первоначально представлялось, что это добавка к полному pvvx SDK как инструмент для быстрой отладки.. когда кусочек IRAM резервируется для загрузки тестов..
Мы используем ESP8266 в качестве WiFi модемов для приборов охранной сигнализации. Как запасной канал связи наряду с GSM модемом. Управляем at-командами. Ничего особенного.. Но работают нормально.
От lua я отказался из-за требовательности к ресурсам. Есть интерес к Aрдуино - Дурине :)
У меня опыт программирования на языке C небольшой.
Имеется b-модуль ESP32 . Опробовал несколько простых тестовых программ на нем под UDK от CHERTS. На виртуальной Linux машине toolchain также работает.
Я бы сказал, что там все очень близко к ESP8266 с точки зрения программирования (только FREE RTOS). Даже появилась альфа-реализация Ардуины для него - http://esp32.com/viewtopic.php?f=2&t=102 .
Думаю, что ESP32 весьма перспективен, хотя в настоящее время им занимаются единицы..
 

pvvx

Активный участник сообщества
Я бы сказал, что там все очень близко к ESP8266 с точки зрения программирования (только FREE RTOS). Даже появилась альфа-реализация Ардуины для него - http://esp32.com/viewtopic.php?f=2&t=102 .
Думаю, что ESP32 весьма перспективен, хотя в настоящее время им занимаются единицы..
От куда и зачем у вас ESP31 (бета ESP32), если пишут что их раздавали всего 200 шт? Вы же на СИ не пишите и тестить пока там нечего.
Китайцам делать нечего - раздавать образцы тем, кто их даже не может програмить?
В принципе это и есть подход Espressif - сделать всё как можно хуже и дольше... :)
Особой ценности у ESP32 может и не случиться, если цена модуля будет в 2 раза больше, только в мире Дурины. За 3 цены модуля ESP-12 уже идут модули с OpenWRT.
Спасибо. Попробовал, компилируется, пример работает.. Как я понял, это полезно для разработки отдельных кусков программы, которым не требуется связь по wifi,
например, какого-нибудь драйвера.
Хотя, мне первоначально представлялось, что это добавка к полному pvvx SDK как инструмент для быстрой отладки.. когда кусочек IRAM резервируется для загрузки тестов..
И такое есть, но оно в непотребном виде - не для публикаций, т.к. будут требовать всё готовое к нему для обслуживания загрузок и прочего, а этого пока нет - большинство манипуляций делается в ручную и не автоматизировано...
Чтобы скинуть https://github.com/pvvx/iramsdk и то потребовалась куча времени хоть на какие прически кода, Make и прочего... Целей всё выкладывать и расписывать у меня нет. Только то, что предлагаю, c участием, чтобы был хоть какой толк. Например эта тема с датчиками... Свою то задачу с ними я решу, но вот общество никаких предложений пока не дает - значит им это не надо.
 
Последнее редактирование:

pvvx

Активный участник сообщества
Это Вы просто неправильно датчики позиционируете. :) Назовите их "i2c sensor" и люди к Вам потянутся. Не все же знают: что такое 10DOF.
А я их на SPI гоняю с их встроенным FIFO (у MPU9250 512 байт). I2C не потянет толпу датчиков на одной шине при нормальных скоростях. И I2C убивает рабочее время CPU ESP826 - I2C пусть в Ардуино и Lua используют, я стараюсь эту тормозную шину не пользовать, но по ней тоже в данном проекте ещё будут другие датчики, которые медленные... :) Пару раз в секунду можно отработать на 400кГц I2C.
 
Последнее редактирование:

pvp

New member
Да и вообще куда ещё в народном творчестве возможно использовать данную связку ESP-X-DOF?
Ну вот, например, у меня так:
в качестве 9-DOF использован POLOLU minIMU-9 V3, Информация по скоростям с каждого колеса берётся с ABS автомобиля (пока при помощи ELM327). Плюс ещё лазерный измеритель расстояния до дорожного покрытия. Соответственно, корректирую наклоны кузова авто (поперечный и продольный), решая задачу 6-DOF (магнетометр на данный момент не использую) и учитывая продольное и центробежное ускорения, рассчитанные по скоростям колёс. Сейчас это работает через USB HID на AT90USB162. Обсчитывается (якобиан там и кватернионы) на компе в C# WinForms. Хочу сделать всё через вай-фай и чтобы в ДЖАВЕ всё считалочь и через аякс бралось компом. Соответсвенно, производительности ESP8266 не потребуется (так как всё будет по прежнему обсчитываться компом), но отображаться будет в браузере, сл-но никакого отдельного приложения для компа.
upload_2016-3-4_17-46-4.png
 
Последнее редактирование:

pvvx

Активный участник сообщества
Соответсвенно, производительности ESP8266 не потребуется (так как всё будет по прежнему обсчитываться компом), но отображаться будет в браузере, сл-но никакого отдельного приложения для компа.
У вас мало точек отсчетов в секунду. По моим расчетам там нормально более 100 точек в секнуду, а если датчиков много, то это уже нормальный поток и требуется производительность для съема и упаковки этих данных для пересылки. По этому никакие I2C не годятся. Только SPI и FIFO.
Развиваемая скорость сбора обработки данных, при 30% занятости CPU ESP8266 переваливает за 1000 точек на каждый параметр каждого датчика (это поток более 40 кбайт нативных данных в секунду).
В итоге передача по WiFi с 10DOF уже 40 килобайт в секунду. А ещё надо вставлять метки времени и какую-то синхронизацию их с приемником.
Только такие скорости позволяют кое-как определиться к примеру с простым движением рук человека. А машина - она большая и тяжелая. Т.е. неуклюжая и имеет малые силы для больших ускорений... до одного Же. Если только не об столб :)
 
Последнее редактирование:

pvp

New member
В итоге передача по WiFi с 10DOF уже 40 килобайт в секунду. А ещё надо вставлять метки времени и какую-то синхронизацию их с приемником.
:)
А это проблема для EPS - 40 kb/sec? Требуется только передать, например, UDP пакетом сырые данные на хост и всё. А хост сам всё посчитает. Или я чего-то не понял в ваших рассуждениях. Обработку на борту можно пока и не делать. Потом допилится.
О каких метках времени идёт речь - номер пакета прилепить (+1 байт к пакету) и всё. Если номера последовательны - значит всё гуд и пропусков нет. Считаете свои дирижёрские гестуры. Вы же знаете с каким темпом данные быдет вылпёвывать MPU (с каким-то, но постоянным). Мне кажется, стоит поток гнать исключительно по UDP. Никаких вам поисков начала-конца, как в случае с tcp. все простенько и быстренько. Ага?
 

pvvx

Активный участник сообщества
А это проблема для EPS - 40 kb/sec? Требуется только передать, например, UDP пакетом сырые данные на хост и всё. А хост сам всё посчитает. Или я чего-то не понял в ваших рассуждениях. Обработку на борту можно пока и не делать. Потом допилится.
О каких метках времени идёт речь - номер пакета прилепить (+1 байт к пакету) и всё. Если номера последовательны - значит всё гуд и пропусков нет. Считаете свои дирижёрские гестуры. Вы же знаете с каким темпом данные быдет вылпёвывать MPU (с каким-то, но постоянным). Мне кажется, стоит поток гнать исключительно по UDP. Никаких вам поисков начала-конца, как в случае с tcp. все простенько и быстренько. Ага?
UDP - проблема. Потеря данных.
При загрузке в 30% на чтение c датчиков (CPU будет занят 30%) и по TCP уже проблема.
Легко поднимается до почти 800Гц (по акселям и дусам) (даже с моим софтовым i2c в мк). Только что попробовал. Но это не суть данной темы.
Каким образом, если I2C - это 400кГц, а для снятия 1000 показаний надо минимум 10 тактов I2C на один байт, а необходимо считать более 20 - т.е. не менее 20*1000*10 = 200000 тактов шины I2C. И всё это время CPU будет занят I2C и не сможет отрабатывать WiFi.
 

pvp

New member
UDP - проблема. Потеря данных.
При загрузке в 30% на чтение c датчиков (CPU будет занят 30%) и по TCP уже проблема.
UDP ведь проще - не надо соединение устанавливать и т. п.
Забиндился - и плюй в порт, ничего не слушая, разве нет?
Всегда так поступал, если какие-то анные нужны на постоянной основе каким-либо узлам в подсети. Обязательно проверю, какие потери будут с рассылкой от ESP по UDP.

А почему проц будет занят на 30%? SPI же аппаратный и по прерываниям, не так ли?
Или это сдк столько кушает сейчас?

Да, и попробуйте гестуры на 100Гц обрабатывать. Мне кажется, что этого более чем достаточно (покрутил сейчас свою инерциалку в руках - ну нет никаких задержек, всё плавненько, видос что-ли выложить?)
 
Последнее редактирование:

pvvx

Активный участник сообщества
А почему проц будет занят на 30%? SPI же аппаратный и по прерываниям, не так ли?
Или это сдк столько кушает сейчас?
А кто будет читать регистры SPI на медленной внутренней шине ESP8266 и выставлять СS-ы на разные микросхемы? Время на вход и выход из прерывания вы тоже не учитываете?
I2С сделать по прерываниям не представляется возможным. Это надо 800 кГц прерывания :)
Читать побайтно из SPI по прерываниям тоже невозможно. Даже поблочно. Слишком короткие блоки.
Да, и попробуйте гестуры на 100Гц обрабатывать. Мне кажется, что этого более чем достаточно.
Пробовал - всё Ok.
 

pvvx

Активный участник сообщества
Так зачем Вам тогда 1кГц опроса?
Для акселерометра и прочих данных.
Картинка загрузки получившегося дана в первом сообщении. Код теста давался в другой теме :)
Вам бы не городить винегрет - любой современны смартфон дает ваши данные на 100 Гц.
 

pvvx

Активный участник сообщества
Зачем? Как быстро вы будете руками-то размахивать? С частотой сети (50Гц) что-ли?
Руками - это условно. Мне нужны все показания, включая яркость, давления и прочие. И желательно векторные :p
Как понимаю, вы хотите меня уговорить использовать I2C и не получить результата :)
UDP на WiFi - это оно и есть - потеря данных в минимум 1% при чистом эфире.
Может для вашего авто это и подойдет. Там всё равно какие данные оно будет получать, а какие не получит.
 
Последнее редактирование:
Сверху Снизу