roboforum.ru

Многие из форумчан уже делали лайнтрейсеров примерно такой конструкции: два ведущих колеса, одно подруливающее, линейка датчиков линии. Алгоритмы соотношения скоростей колес в зависимости от положения линии в текущий момент могут быть разными, в частности ПД (есть мнение, и я с ним согласен, что это лучший алгоритм для этого дела. Но чтобы он работал хорошо - нужно правильно подобрать коэффициенты П и Д). Обычно это делают в ручную, ориентируясь на поведение бота - если ездит примерно плавно, то настройка окончена. Мало кто может точно засечь изменение времени прохождения трассы, чтобы можно было определить лучшую пару коэффициентов. Предложенный далее алгоритм предназначен для автоматизации подбора этих коэффициентов.
Исходные данные. У вас уже есть подпрограмма ПД регулятора, и подпрограмма для опроса датчиков линии. Саму трассу придется немного модифицировать - поперек трассы наклеить кусок черной изоленты. Это будет точка отсчета, старт/финиш. Критерием качества прохождения линии будет время прохождения линии, его нужно минимизировать. Подпрограмму опроса датчиков линии нужно дописать таким образом, чтобы бот всегда знал: на старте он или на линии. С датчиков кроме информации о положении линии приходит флаг: старт/финиш или линия. Сама процедура автонастройки имеет несколько режимов, о них далее. Перед началом автонастройки нужно грубо найти минимальный коэффициент П, при котором бот не теряет линию (при нулевом коэффициенте Д). Итак, все готово.
Переход со старта на линию - это событие, по которому начинается заезд. Переход с линии на финиш - это событие, по которому подводится итог и делаются все нужные действия. Чтобы на подбор коэффициентов не влияли случайности, введено фильтрование - результат усредняется за 4 круга.
В начале режим нулевой. Бот выезжает на линию, проезжает 4 круга, усредняет время - это наше первое время, именно его мы будем улучшать. В качестве времени выступает число циклов опроса датчиков линии. Затем режим становится первым.
В первом режиме подбирается коэффициент П при нулевом коэффициенте Д. Увеличиваем его, 4 заезда, усредняем, сравниваем время. Если получилось быстрее - берем новый коэффициент П. Если медленнее - берем старый коэффициент П, а режим становится вторым.
Тут нужно небольшое пояснение. Представьте декартову плоскость, первый квадрант. Ось Х - это П, вторая ось - это Д. Где-то лежит наша точка минимума. Мы не знаем сколько в этой функции двух переменных локальных минимумов. Проверять все комбинации точек - очень долго. Поэтому алгоритм строится на предположении, что минимум у нас один.
Во втором режиме вокруг каждой точки находятся 8 точек (кроме границ). Вокруг нашей выбранной точки лежит 5 точек, в двух из которых мы побывали чуть ранее. Обход остальных точек будем делать по часовой (это связано с тем, что одновременно с уменьшением П увеличивают Д - чаще всего это помогает). Чтобы не проверять точки дважды - их координаты (суть пара коэффициентов) заносятся в кольцевой буфер на 8 пар коэффициентов. После каждой проверки пары сравнивается время. Если его удалось уменьшить - запоминаем эту пару как текущую, если нет - эту пару заносим в буфер и переходим к следующей паре. Как только все точки вокруг текущей оказываются проверенными (во всех их время больше) - мы нашли минимум.
Внешне работа алгоритма выглядит просто - бот катается по трассе минут 5 - 10, потом останавливается. Коэффициенты можно хранить в ее проме, потом считать их оттуда и все.

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

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

Radist писал(а):Не понял каким автоматом и кто должен измерять время круга.

Комп на котором ведется лог и манипуляции коэфами.

Radist писал(а):подозреваю что с компа через радиоканал...

Да.

Добавлено спустя 2 минуты 17 секунд:

vadinator писал(а):Класно! Самообучающийся робик...

Можно и так, ддя этого надо на длинном прямом участке дистанции нарисовать поперечную черту для затемнения всех датчиков или магнит расположить а на боте датчик холла или иначе дать боту информацию о прохождении круга.

Radist писал(а):Выходит что зря я поставил 6 датчиков - хватило бы и 4. Просто мой бот не очень быстрый...

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

Radist писал(а):Это иллюстрация того, что на глаз коэффициенты можно подобрать ОЧЕНЬ грубо.

Еще неизвестно, как этот "локальный минимум" в координатах П и Д выглядит - с ходу трудно оценить.
Легко может оказаться, что этот минимум достаточно острый. Может быть вы просто далеко от него, поэтому кривая такая плавная.

...если они дискретные.

дискретные

А что мешает завести на аналоговый вход?

Снова занялся алгоритмом. Экспериментально определил точку перегиба П - составляющей. Данные такие:

П время, сек
7 11,505
10 10,884
15 10,663
19 10,465
22 10,388
24 10,247
25 10,199 - вот он, минимум!
26 10,331
27 10,359

Так что в моем случае минимум не острый. Но эти данные получены не роботом, а мной - поэтому я и смог привести промежуточные точки. Задача на ближайшее время - чтоб я его запустил, а он сам нашел, что лучше всего когда П = 25.

Научил робота находить П. Он согласен, что это 25, только время показал 10,290. А при П = 26 робот уже сильно дергается, это хорошо видно, а по времени это видно плохо - разница в 0,1 сек на глаз не видна. Если построить график, провал может и будет острым, но не настолько, чтобы глаз заметил разницу. Теперь вместо П - регулятора надо запрограммить ПД. Он у меня есть, но что-то глючит, где-то ошибка в коде.
Будем искать (с)