SRF04 Ультразвуковой датчик - неточные показания

Question

SRF04 Ультразвуковой датчик - неточные показания

arduino-uno sensors

У меня есть Arduino Uno, подключенная к ультразвуковому датчику SRF04. Я использую библиотеку отсюда: https://code.google.com/p/srf04-library/

Затем я использую базовый скрипт "Сантиметр", который есть в примерах. Это дает мне показания, но они кажутся неточными примерно на 20-25%. Когда он читает 100 см, расстояние фактически приближается к 80 см.

Я заменил SRF04 другим, и возникла та же проблема. Кроме того, кажется, что когда он читает вне диапазона (или даже на поверхностях, которые дают неравномерный «отскок»), я получаю очень случайные цифры (например, -5 см).

Кто-нибудь сталкивался с чем-то подобным?

@fistameeny, 👍4

Обсуждение

Вы использовали метод setaverage? Если да, то какое значение вы использовали?, @jfpoilpret

Нет, я не использовал его, просто настройка по умолчанию, @fistameeny

5 ответов

Лучший ответ:

▲ 2

Это довольно стандартно. Высота над уровнем моря и температура воздуха изменяют скорость звука в достаточной степени, чтобы вызвать эти ошибки, а небольшие изменения в датчиках могут усугубить проблему. Я бы попытался рассчитать вашу собственную шкалу, чтобы преобразовать время пинга в расстояние, используя фактические измерения из того места, где вы живете; Библиотека, вероятно, использует скорость звука на уровне моря.

Точно так же любая форма, плохо отражающая или поглощающая ультразвук, может привести к ошибочным показаниям. С этим действительно нечего делать, извините. Если у вас есть несколько датчиков, направленных на несколько градусов друг от друга, вы, скорее всего, получите тот, который покажет правильное расстояние.

17 июн 14, @BrettAM

В этом случае точность расстояния не так важна — я пытаюсь определить, проходит ли кто-то через два датчика, но полезно знать, что показания могут быть затронуты., @fistameeny

Расстояние на 25% больше, чем ожидалось, а скорость звука всего на 5% медленнее на высоте 15 000 футов (на 13 % медленнее на высоте 60 000 футов). [источник](http://www.fighter-planes.com/jetmach1.htm)., @Gerben

Эта диаграмма включает разницу температур, которой не было бы при комнатной температуре на каждой высоте. Системы отопления и кондиционирования воздуха также сильно влияют на давление . Добавьте ошибку 1%, закодированную в библиотеке, которую нашел jfpoilpret, и вариации в датчиках, которые, как я видел, были на удивление большими у других брендов. Тем не менее, я согласен, что ошибка довольно велика; Могут быть и другие неизвестные., @BrettAM

▲ 3

Хотя БреттМ обсудил некоторые замечательные моменты, которые могут возникнуть с ультразвуковыми/сонарными датчиками/датчиками "Ping", я заметил несколько других, когда использовал эти датчики.

Первая и наиболее распространенная проблема с датчиками этого типа – это точное определение того, что вызывает срабатывание значения расстояния. Рассмотрим на абстрактном уровне, как они работают. У вас есть бит, который передает «пинг». Он передает «пинг» и останавливается. В этот момент бит, который прослушивает «pong», активируется и начинает прослушивание. Эти датчики работают, отправляя этот «пинг» и запуская таймер, первый «понг», который слышит датчик, запускает реакцию на остановку таймера, и расстояние, грубо говоря, вычисляется отсюда. Обратите внимание, что датчик не может определить, откуда исходит «понг». Если вы исполняете йодль на горе, вы не знаете, какая поверхность отражается эхом, и это та же проблема, с которой вы потенциально столкнетесь с вашим датчиком.

Обычно, когда я работаю с людьми, чьи датчики получают неточные показания, подобные описанным вами, возникают некоторые варианты этой проблемы. Часто показания являются «короткими» из-за того, что в конусе «пинга» есть препятствие, из-за которого звук отражается назад быстрее, чем ожидалось для измеряемой поверхности. Напомним, что звук — это не точный, направленный лазер. Скорее он распространяется волнами от источника. По моему опыту, любые объекты в пределах дуги примерно 160 градусов (по моему опыту) перед вашим датчиком могут привести к тому, что эти показания будут необычными. Это может быть пол, ваша обувь, измерительные приборы. Теоретически датчик создан, чтобы избежать этих показаний, на практике не очень.

Чтобы проверить, так ли это с вашей настройкой сенсора, я бы порекомендовал провести несколько экспериментов. Сначала установите Arduino и датчик в фиксированное положение и таким образом, чтобы датчик находился на краю опорной поверхности, а перед ним не было ничего, кроме поверхности, которую вы хотите измерить. Так, например, установите датчик на самом краю стола лицом к стене. Измерьте расстояние от стены до края опорной поверхности (края стола). Некоторое отклонение является нормальным, как описано BrettM, но 20% на 100 см, по моему опыту, это многовато. Как только вы получите надежное, повторяемое чтение, начните менять обстановку. Поместите что-нибудь на переднюю дугу датчика и посмотрите, как это повлияет на него. Переместите датчик/опорную поверхность к объекту и от него. Обычно, когда я вижу такие значения, как -5, это означает, что что-то было слишком близко к датчику или, возможно, мешает другой датчик.

Стоит убедиться, что в зоне, где вы работаете, нет других датчиков расстояния. Другие устройства, отправляющие похожие запросы, могут давать необычные показания (поскольку они не различают, кто чей пинг/понг).

17 июн 14, @Nahkki

Спасибо. Я провел некоторые тесты, как вы описываете, но минусовые значения меня несколько сбили с толку. Я сделаю более точный расчет, а затем приступлю к дальнейшим испытаниям., @fistameeny

Я полностью могу это оценить. Датчики пинга, которые мы называли этими датчиками в моей лаборатории, отвратительно шумные (как, честно говоря, и большинство датчиков). Они, безусловно, полезны и ценны, но есть так много вещей, которые могут привести к их неожиданному поведению, что данные от них всегда должны быть подозрительными и фильтроваться., @Nahkki

▲ 0

У вас есть удовлетворительный ответ на этот вопрос?

У меня та же проблема с датчиком HC-SR04. Это должно быть с точностью до миллиметра, вместо этого я получаю ~ 30% + от значений. Например) @ 30 см, показание составляет ~ 40 см. @ 15 см, показание составляет ~ 20 см.

Это не совсем "решение", но вот что я сделал. Для расчета расстояния я разделил еще на 1,25.

расстояние = (продолжительность/2,0)/29,4/1,25

Теперь мои показания выглядят намного точнее (+/-0,5 см) в диапазоне от 0 до 30 см. И хотя это было не идеально, на расстоянии 2 м было 202 см.

Не уверен, что это проблема с датчиком или с Arduino... Может быть, ему не хватает питания, так что часть эхо-импульса не регистрируется в Ardu как High. Я использую свою плату на USB 5V, который, в свою очередь, снят с Raspberry Pi2. Тем не менее, 25 % — это огромное расхождение...

ВАУУУУУУ, Я ЧТО-ТО НАШЕЛ!

После написания последнего абзаца я подключил Arduino к своему ПК (вместо RPi), загрузил ПО без коэффициента 1,25, и показания правильные! (более или менее. НЕ +30% раньше)

Так что да, это из-за отсутствия питания.

Надеюсь, это относится и к вам, и в этом случае мы наконец сможем решить эту проблему навсегда.

1 окт 16, @Dan

Очень плохая идея решить наблюдаемое значение по умолчанию в библиотеке, добавив жестко запрограммированную константу, которая «кажется» компенсировать значение по умолчанию и не имеет никакого научного смысла. Скорее меняйте библиотеку на лучшую!, @jfpoilpret

Да, если датчик был плохо изготовлен и имеет пропорциональное смещение, это практически единственный способ «исправить» проблему. К счастью, это было не так!, @Dan

ОП упомянул, что заменил датчик на другой без какого-либо эффекта, поэтому я не считаю датчик неисправным., @jfpoilpret

▲ 2

Это спасло мой проект:

https://create.arduino.cc/projecthub/panagorko/next -уровень-ультразвуковой-датчик-a67478?f

Пожалуйста, расскажите, я чуть не сдался. Этот драгоценный камень кажется малоизвестным, я потратил два полных дня напрасно, пытаясь улучшить точность своего ультразвукового датчика.

11 окт 20, @Siva

Хотя эта ссылка может ответить на вопрос, лучше включить сюда основные части ответа и предоставить ссылку для справки. Ответы, содержащие только ссылки, могут стать недействительными, если связанная страница изменится., @sempaiscuba

@*jfpoilpret* · Accepted Answer · 2014-06-17 19:44-00:00

Просто не используйте эту библиотеку, она плохо спроектирована.

Вот как рассчитывается расстояние туда и обратно (фрагменты кода):

long sum = 0;
for (int i=0;i<_average;i++)
{
    digitalWrite(_trigPin, LOW);
    delayMicroseconds(2);
    digitalWrite(_trigPin, HIGH);
    delayMicroseconds(10);
    digitalWrite(_trigPin, LOW);
    _duration = pulseIn(_echoPin, HIGH);
    sum=sum+_duration;
}
return(int(sum/_average));

Если мы удалим усреднение (поскольку _average равно 1 по умолчанию), это сведется к следующему:

digitalWrite(_trigPin, LOW);
delayMicroseconds(2);
digitalWrite(_trigPin, HIGH);
delayMicroseconds(10);
digitalWrite(_trigPin, LOW);
return int(pulseIn(_echoPin, HIGH));

pulseIn обычно возвращает unsigned long, который представляет собой количество микросекунд для прохождения звуковой волны, излучаемой датчиком, туда и обратно.

Если мы считаем, что скорость звука в воздухе составляет около 340 м/с (при средних условиях температуры и высоты), и если мы рассмотрим объект, который находится на расстоянии 3 м от вашего датчика (что является приблизительным максимальным диапазоном датчик SRF04), то pulseIn() должен вернуть:

3 x 2 / 340 x 1000000 = 17646 мкс

Пока мы не видим особых проблем, это нормально.

Теперь, если мы посмотрим на временную диаграмму SRF04, она упоминается что если объект не обнаружен, датчик отправит эхо 36 мс; в этой ситуации pulseIn() вернет 36000us.

Проблема здесь в том, что 36000 не помещается в int (максимальное значение = 32767), преобразование в int изменит его на отрицательное значение! Это объясняет ваши странные отрицательные результаты.

Что касается точности, у используемой вами библиотеки есть еще одна проблема; вот как рассчитывается расстояние в см:

int DistanceSRF04::getDistanceCentimeter()
{
        return (getDistanceTime()/29/2);
}

Проблема здесь заключается в вычислении int, его лучше выполнять как float . Для скорости звука 340 м/с время эха в нас следует делить на 29,4 (т.е. 1000000/340/100), а не на 29, что может повлиять на окончательное расчетное расстояние!

Если вы хотите продолжать использовать эту библиотеку, просто забудьте о методе getDistanceCentimeter() и замените его следующим кодом:

distance = (int) (sensor.getDistanceTime() / 29.4 / 2);

Затем все вычисления выполняются как float и преобразуются в расстояние int только в конце.

Ваш код также должен явно обнаруживать отрицательные значения, означающие "объект не обнаружен".