Arduino Uno и странное поведение ультразвука
- Войдите на сайт для отправки комментариев
Втр, 19/09/2017 - 11:20
Приветствую обитателей форума.
Случилась странность с которой хотелось бы разобраться.
К Arduino Uno подключены через обычные провода три ультразвуковых датчика hc-sr04/hc-sr05, датчики установлены на штативах и направлены в разные стороны, сигналы посылаются и опрашиваются последовательно. Несколько раз была замечена странная синхронизация между датчиками (см. приложенные изображения).
Не могли бы вы мне предложить варианты, из-за чего такое может случиться на аппаратном уровне и что, возможно, следует добавить в сборку для более надёжной работы нескольких ультразвуковых датчиков (до 6 штук)?
Рисунок 1: Иногда второй и третий датчик работают будто в противовес друг другу.
Риунок 2:
Ну, вот вам вариант: Следующее измерение рекомендуется выполнять не ранее чем через 50 мс. (C)
А так, как датчики все работают на одной частоте, то могут ловить какие-нибудь переотраженные сигналы от дернутого ранее сенсора.
Благодарю за быстрый ответ. Да, delay стоит всегда, пробовал его увеличивать, но всё равно оставалась "синхронизация" даже между первым и третьим датчиком, хотя там уже двойной delay + время на опрос между ними.
К слову, известна ли какая-то формула, по которой можно рассчитать более-менее точное время затухания волны до состояния, когда она не будет ловиться датчиками?
Ну, засуньте их в разные коробки и проверьте - действительно ли они свистят в уши друг другу. К тому же схема подключения не приведена. Дело может быть не в бобине вообще.
Если под "затуханием" Вы подразумеваете уменьшение избыточного давления за счет расширения фронта волны, то берете из дэйташита максимальную рабочую дальность, умножаете ее на 2 и делите на скорость звука.
Что же касается вопроса в первом посте, то для начала хотелось бы понять, что именно изображено на рисунках.
Как показывает мой ХШ, на рисунках изображено расстояние, измеренное тремя датчиками, где автор хотел показать корреляцию промеж соседних датчиков. На первом рисунке хорошо просматривается взаимозависимость между синим и зеленым "синфазная" и "противофазная" между зеленым и пурпурным, что дает основание предположить о срабатывании датчиков на переотражения.
Один и вариантов разработанного моим сыном робота-сумоиста: "поскольку все используют одинаковые датчики поиска противника, делаем руку с вынесенным вбок датчиком и вращаяя её ищем сигнал от датчика противника, после чего свистим своим датчиком на датчик противника и уводим руку в сторону от нашего робота. Далее достаточно объехать его сзади и дотолкать до края, держа перед его датчиком этот манок". Возраст автора - 10 лет.
:)
Я не то, чтобы физик, поэтому не имею конкретных представлений о всех тонкостях явления, которое назвал "затуханием". И, да, спасибо, я исходил из тех же расчётов, просто подумал, что, возможно, в датчиках зашито максимальное время ожидания ответа и пролетевший значительно больше двух расстояний сигнал всё ещё может зарегистрироваться следующими в очереди датчиками.
По рисункам всё предельно просто: три графика соответствуют трём различным датчикам, рисуются по принципу соединения отрезком предыдущего показания датчика с текущим. Повторюсь, датчики направлены были в разные стороны и периодически, когда один из них улавливал пролетающий объект(ладонь/тело) , другой/другие тоже давали реакцию. Бывали моменты, когда просто несколько сенсоров одновременно давало артефакт(рисовали изменение расстояния, хотя перед ним ничего не было).
Максимальное время указываете Вы, задавая таймаут для pulseIn().
Но, вообще-то, физику не обманешь: сигнал затухает пропорционально квадрату расстояния, т.е. довольно быстро. Если сделать датчик более чувствительным, начнутся ложные срабатывания на шумы.
Может, оно и "предельно просто", но совершенно неясно: что такое показания датчиков? в каких единицах, где оцифровка осей, чтобы хотя бы понять, колебания на порядки или на доли процента?
Как направлены датчики (под какими углами)? Какова конфингурация помещения? Каков интервал между временем опроса разных датчиков?
Схема расположения датчиков, оцифровка осей и скетч могли бы ответить на многие вопросы, но ведь ничего нет, а хрустальный шар, зараза, - испортился.
Из справочного листка, блеадь! Не надо слушать музыку в плейере. Надо слушать в проигрывателе. Из энибади рашн хеар? Cyka blyat!
// Пригорело. Извините.
int trigPin1 = 11; int echoPin1 = 12; int trigPin2 = 9; int echoPin2 = 10; int trigPin3 = 7; int echoPin3 = 8; int mm; long duration ; void setup() { Serial.begin (9600); pinMode(trigPin1, OUTPUT); pinMode(echoPin1, INPUT); pinMode(trigPin2, OUTPUT); pinMode(echoPin2, INPUT); pinMode(trigPin3, OUTPUT); pinMode(echoPin3, INPUT); } void loop() { digitalWrite(trigPin1, LOW); delayMicroseconds(5); digitalWrite(trigPin1, HIGH); delayMicroseconds(10); digitalWrite(trigPin1, LOW); duration = pulseIn(echoPin1, HIGH); mm = duration/5.8; mm = constrain(mm,0, 4000); Serial.print( "A" ); Serial.print(mm); delay(???); digitalWrite(trigPin2, LOW); delayMicroseconds(5); digitalWrite(trigPin2, HIGH); delayMicroseconds(10); digitalWrite(trigPin2, LOW); duration = pulseIn(echoPin2, HIGH); mm = duration/5.8; mm = constrain(mm,0, 4000); Serial.print( "B" ); Serial.print(mm); delay(???); digitalWrite(trigPin3, LOW); delayMicroseconds(5); digitalWrite(trigPin3, HIGH); delayMicroseconds(10); digitalWrite(trigPin3, LOW); duration = pulseIn(echoPin3, HIGH); mm = duration/5.8; mm = constrain(mm,0, 4000); Serial.print( "C" ); Serial.print(mm); delay(???); }Думаю, что не помешает вот это:
intmm; ->floatmm;Так же, наверное, стоит делать несколько замеров и усреднять показания. Чтобы ускорить цикл - использовать параметр timeout функции pulseIn(), который уже упоминался. В комментариях к pulseIn() можно найти следующее: "This function performs better with short pulses in noInterrupt() context" - иначе можете наловить всякого, если добавите что-нибудь обрабатывающее прерывания. По поводу delay(???) я встречал такое замечание "we suggest to use over 60ms measurement cycle, in order to prevent trigger signal to the echo signal".
По поводу float: не вижу смысла, ибо, во-первых, точность оборудования далека от долей миллиметра, во-вторых, проблем с автопреобразованием в int не возникает, про timeout я уже понял, спасибо.
По поводу 60 мс я тоже читал и именно поэтому задавал вопрос, как можно точнее высчитать время "затухания" волны. Т.к., если применить простейшую формулу: (4(м)*2)/340(м/с) - получаем где-то 24 мс, а изготовитель рекомендует "более 60", что значительно больше рассчётов.
Ну, мало ли, вдруг вы забыли, что делите на float. Но если 3-4% для вас не ошибка, то ладно.
По поводу расчета паузы между замерами... Я не знаю, чем руководствовался составитель datasheet-а. Возможно экспериментальными данными, возможно знанием о дополнительных вспомогательных процессах, происходящих в схеме, которая обеспечивает работу приемо-передатчика. Я бы для начала не делал самостоятельные расчеты, а придерживался рекомендации. Если стабильно заработает - вводите изменения в алгоритм. Во всяком случае будете знать, что железо полностью исправное, а схема соединений - корректна.
Ну так и должно быть.
Разные предметы по-разному отражают сигнал. Соответственно, существует разброс.
Для датчика можно условно выделить 3 зоны:
- зона уверенного приема - только в этой зоне и можно надеяться на более или менее точные измерения,
- зона неуверенного приема - сигнал затухат настолько, что принимается через раз,
- зона вне приема - сигнал затухает настолько, что датчик на него устойичво не срабатывает.
Очевидно, для максимальной дальности измерения берется граница 1 и 2 зоны, а для избежания ложного срабатывания - граница 2 и 3.