Что-то здесь не так.

andriano
andriano аватар
Offline
Зарегистрирован: 20.06.2015

Жень, а чем "правильный" воздух отличается от атмосферного (ну - кроме химического состава)?

Если мне не изменяет память (которая, как Вы правильно заметили), в атмосферном воздухе меньше кислорода, больше азота, а и преобладания аргона над водяным паром, углекислым газом и пр. что-то не припомню.

ЕвгенийП
ЕвгенийП аватар
Offline
Зарегистрирован: 25.05.2015

Ну, есть определённые нормы состава воздуха. Он собственно в данном контексте нужен, чтобы молярную массу определить. Этот числовой коэффициент в формуле, он же есть корень из произведения показателя адиабаты на универсальную газовую постоянную, поделенного на молярную массу. Тот, состав воздуха, что я назвал, в некоторых статьях используется как "правильный" при составлении таблиц стрелбы. От него уже берутся поправки на реальный состав. При нём молярная масса равна 0,02904 кг/моль.

SLKH
Offline
Зарегистрирован: 17.08.2015

"Ну, есть определённые нормы состава воздуха. Он собственно в данном контексте нужен, чтобы молярную массу определить. "

В контексте данной темы (роботизированная тележка) это совсем не нужно. от слова "абсолютно".

Как и не нужны (от того же слова) никакие умножения/деления результата функции pulseIn().

А нужна всего лишь одна константа (в микросекундах), примерно равная времени пробега звука до препятствия и обратно, с которой результат pulseIn() сравнивается. Ибо роботу совершенно безразличны дюймы/сантиметры, да и учет температуры/давления/состава воздуха ему не нужен для обеспечения остановки на разумном расстоянии (+/- сантиметры).

 

==========

да, никаких поправок на молярную массу и хим.состав воздуха в таблицах стрельбы что-то не припоминаю. только на температуру и давление.

SLKH
Offline
Зарегистрирован: 17.08.2015

slava.ru38 пишет:

Arhat109-2 пишет:

Ещё надо заметить, что для обратного преобразования в расстояние Вы зачем-то делите вычисленное время на 58 (иногда делят на 59), в то время как операции целочисленного деления у Ардуино нет и в помине, а деления вещественных чисел нет как класса чисел и вовсе. Куда как полезнее делить на такие чиселки, которые являются степенями двойки, чтобы заменить деление сдвигами. Если предварительно умножить нашу скорость в 0.335 мм/мксек на скажем 1024, то получим константу 343.040, что мало отличается от 343 (0,012%!) и, в этом случае мы можем измеренное время в микросекундах домножить на эту константу и поделить на 1024, а поскольку "туда и обратно", то на 2048 что куда как экономичнее и быстрее делается Арудиной! Кто и с какого перепою предложил делить на 58 - ума не приложу, каким надо быть безграмотным программистом.

Уважаемый Arhat109-2, спасибо за подробности и глубинные нюансы. Насчет деления - согласен, что умножение ардуино выполнит быстрее. А деление на 58 - это образец на разных сторонних сайта, где приводили примеры перевода времени в сантиметры. Вот я и воспользовался. Другого способа не знал. Сечас постараюсь по вашему совету исправить.

Есть и ещё одна тонкость: и деление на 58, и умножения/сдвиги в этой задачке лишние.

qwone
qwone аватар
Offline
Зарегистрирован: 03.07.2016

SLKH пишет:

Есть и ещё одна тонкость: и деление на 58, и умножения/сдвиги в этой задачке лишние.

const uint32_t  dist = 50 * 58; // где 50 см расстояние до препятствия и 58 поправочный коэффициент
// и если надо изменить расстояние, то можно поменять 50 на нужную величину.

Здесь нет умножения. Умножение делает компилятор, а результат запихивает уже в константу. Вот и сравнимают уже с константой. Некая экономия процессорного ресурса. Да и результат не расстояние, 0 или 1. Препятствие есть или нет.

ua6em
ua6em аватар
Offline
Зарегистрирован: 17.08.2016

andriano пишет:

Жень, а чем "правильный" воздух отличается от атмосферного (ну - кроме химического состава)?

Эталон воздуха на планете Земля - Тебердинский биосферный заповедник, приезжаете, вдыхаете, после этого сами озвучите, чем отличается )))

SLKH
Offline
Зарегистрирован: 17.08.2015

qwone пишет:

SLKH пишет:

Есть и ещё одна тонкость: и деление на 58, и умножения/сдвиги в этой задачке лишние.

const uint32_t  dist = 50 * 58; // где 50 см расстояние до препятствия и 58 поправочный коэффициент
// и если надо изменить расстояние, то можно поменять 50 на нужную величину.

Здесь нет умножения. Умножение делает компилятор, а результат запихивает уже в константу. Вот и сравнимают уже с константой. Некая экономия процессорного ресурса. Да и результат не расстояние, 0 или 1. Препятствие есть или нет.

я про эти строки:

108 impulseTimeL = pulseIn(echoPinL, HIGH,3000); // считывание расстояния с УЗ датчика
109 distL=impulseTimeL/58; // Пересчитываем в сантиметры
 
118 impulseTimeC = pulseIn(echoPinC, HIGH,3000); // считывание расстояния с УЗ датчика
119 distC=impulseTimeC/58; // Пересчитываем в сантиметры
 
128 impulseTimeR = pulseIn(echoPinR, HIGH,3000); // считывание расстояния с УЗ датчика
129 distR=impulseTimeR/58; // Пересчитываем в сантиметры

на кой здесь вычислять сантиметры? 

slava.ru38
Offline
Зарегистрирован: 28.11.2016

Ну да, SKLH. В какой-то степени вы правы. Для выполнения задачи сантиметры не нужны. Но так как-то спокойней было, когда в Serial контролируешь при необходимости расстояние и работу сонаров. Например когда я регламентировал время таймаута, телега отказалась ехать, если не было препятствие ближе 50 см.  Посмотрел в Serial, оказалось при окончании времени таймаута, если препятствие дальше 50 см., то расстояние считалось 0. Отчего логика


if (distL>50 && distC>50 && distR>50) // если измеренная дистанция больше 50 сантиметров - едем

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


	  if (distL>40 || distL==0 && distC>40 || distC==0 && distR>40 || distR==0) // если измеренная дистанция больше 40 сантиметров или равна 0 -  едем 

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

Arhat109-2
Offline
Зарегистрирован: 24.09.2015

SLKH пишет:
Есть и ещё одна тонкость: и деление на 58, и умножения/сдвиги в этой задачке лишние.

Совершенно верно. Определяя расстояние до препятствия по времени задержки сигнала в микросекундах, нет никакого смысла переводить измеренную задержку в расстояние. Можно поступать наоборот: константное "предельное расстояние" до препятствия перевести в микросекунды на куркуляторе и им и оперировать в сравнениях.

Просто несколько удобнее задавать пороги в сантиметрах чем микросекундах для начинающих робототехников .. Ардуино - проект исключительно для начинающих. Не забываем. А так, да - согласен полностью (сам так и делаю). :)