Давайте подумаем о задаче езды немножко с другой точки зрения.
Какой параметр движения робота является ключевым в данной задаче?
Очевидно, что скорость поворота.
То есть в каждый момент разница между скоростями колёс робота должна быть
оптимальной.
Если мы представим реализованный релейный алгоритм графически,
у нас получится примерно такая картинка.
Если по вертикальной оси мы отложим разницу в скоростях колёс,
у нас есть всего три ситуации.
Два датчика с белым полем под ними, белый и чёрный,
и чёрный и белый.
И всего три возможных разницы в скоростях колёс.
Она нулевая, она положительная
и она отрицательная.
Естественно, в такой ситуации все повороты будут резкими.
Что можно поделать для того, чтобы это каким-то образом сгладить?
Очевидно, что скорости колёс можно регулировать плавнее.
И мы же помним, что мы используем аналоговый датчик линии, то есть,
помимо чёрного и белого, мы видим все промежуточные оттенки.
Давайте ещё раз посмотрим на фрагмент трассы.
Мы стараемся установить датчик линии таким образом,
чтобы он находился над границей линий.
То есть, если мы представим то пятно инфракрасной подсветки, которое
создаёт датчик, оно будет располагаться, например, вот таким образом.
Мы видим, что в круг попала половина белая, половина чёрная, но,
с точки зрения датчика, это среднее серое значение,
потому что он видит это всё как одну точку.
Следовательно, если он сместится левее,
у него будет абсолютно белое значение.
Если он сместится правее, будет абсолютно чёрное значение.
А также будет множество промежуточных значений, где уровень серого,
с точки зрения датчика, будет различным.
Таким образом, мы можем
запомнить желаемое значение уровня серого под датчиком и всегда к нему стремиться.
Давайте представим это графически.
Снова по вертикальной оси отложим разницу в скоростях колёс,
а по горизонтальной разницу между
текущим значением датчика и тем желаемым, который мы измерили вначале.
Назову это δS, например.
То есть у нас получится просто какая-то прямая, проходящая через 0.
То есть, если у нас нет разницы в желаемом значении датчика и текущем,
нам не нужна разница в скоростях колёс.
Если у нас разница получилась,
значит у нас и колёса будут крутиться с разной скоростью.
Причём здесь допустимы отрицательные значения, потому что,
если мы из желаемого значения 300 вычтем значение, которое мы получаем на чёрном,
например, 700, у нас получится отрицательное значение вот этой δS.
И разница в скоростях колёс также будет отрицательной.
То есть мы вот эту разницу считаем, допустим,
скорость левого минус скорость правого.
Соответственно, если скорость правого больше скорости левого,
то разница будет отрицательной.
И, пожалуйста, мы добиваемся того, что мы хотим.
То есть скорость регулируется пропорционально изменению
серости под датчиком, точнее, разницы в скоростях колёс.
Как это может быть реализовано алгоритмически?
Давайте сразу посмотрим в код.
Во-первых, в начале программы,
в setup мы будем запоминать то желаемое значение, средний уровень серого,
к которому мы всё время будем стремиться, хранить его в переменной игры.
А затем при каждом проходе основного цикла мы будем
вычислять так называемую ошибку,
которая состоит из разницы между текущим значением под
датчиком и тем самым желаемым, который мы сохранили.
Это та самая δS, которая была на предыдущем графике.
На самом деле, обычно ошибка обозначается буквой e латинской.
Когда мы знаем ошибку, нам нужно вычислить управляющее воздействие,
то есть как это отразится на оси y нашего графика.
Управляющее воздействие обычно обозначается
латинской u и в данном случае состоит всего лишь из ошибки,
взятой с каким-то коэффициентом, то есть уровнем наклона этой самой линии.
Ну это очевидно, потому что мы считываем значения с датчика линии
в каких-то одних условных единицах, имеющих один диапазон,
управляем моторами, используя другие условные единицы в другом диапазоне и,
естественно, нужен некий коэффициент, чтобы сопоставить
единицы измерения серого и единицы скорости колёс.
Эта самая K, которую мы определили в начале программы, и есть.
И далее мы вызываем известный нам drive.
Здесь мы видим некое макроопределение BASE_SPEED.
Это желаемая скорость, к которой мы будем стремиться.
Мы хотим, чтобы на обоих колёсах всегда была эта скорость.
Соответственно, когда роботу нужно поворачивать,
к этой скорости на одном колесе будет прибавляться управляющее воздействие,
а на другом колесе из неё оно будет вычитаться.
Здесь ничего странного нет, потому что мы помним,
что само управляющее воздействие также может быть отрицательным.
Когда текущее значение датчика больше, чем желаемое среднее.
Давайте мысленно забежим вперёд и представим,
какие ещё вещи нам понадобятся.
А, как мы знаем, когда мы просто включаем робота путём подключения питания,
он тут же устремляется вперёд.
Нам нужно будет добавить кнопку, после которой он стартует.
Это первое.
А, во-вторых, при использовании данного алгоритма нам хотелось бы выставить
робота на самое среднее серое значение.
Поэтому нам было бы удобно видеть, что сейчас считывает датчик.
Поэтому мы добавим к роботу уже известный нам четырёхсимвольный дисплейчик
и перед запуском посмотрим, в какое положение лучше всего установить датчик.
Какие изменения в коде это повлечёт?
Во-первых, мы не забываем про библиотеку для работы с дисплейчиком.
Во-вторых, обратите внимание, что у нас сейчас остался всего лишь один датчик.
Нам второй в данном алгоритме не нужен.
Мы подключили кнопку и дисплей,
задали ту самую базовую скорость,
а также ввели некий коэффициент K с неким
условным значением 0.2.
О том, как подбирать эти значения, мы поговорим чуть позднее.
И как мы будем осуществлять запуск робота теперь?
В разделе setup заведём цикл while,
который будет работать до тех пор, пока кнопка не нажата.
То есть робот никуда не поедет, пока мы его не запустим.
А внутри этого цикла мы будем постоянно выводить на дисплей то,
что сейчас мы видим под датчиком.
Возможно, нам понадобится добавить сюда небольшую задержку,
чтобы цифры на дисплейчике не так быстро скакали, и мы их успевали прочитать.
А также мы здесь считываем то самое значение, к которому мы
будем стремиться на протяжении всей остальной работы программы.
Когда мы из цикла выйдем, это значение останется в глобальной переменной игры.
Теперь робот стал выглядеть вот так.
У него появился экранчик, который транслирует показания датчика.
Сам датчик остался один, и он установлен справа.
Из-за этого у нас немножко поменялся код, о чём мы поговорим чуть позже.
Также появилась заявленная кнопка, с помощью которой его удобно запускать.
Ещё нужно сказать пару слов о том, почему датчик установлен таким образом.
Вначале я его поставил ниже и в очередной раз убедился, что это плохое решение,
потому что пятно, которое датчик видит, получается маленьким.
И все изменения, которые под ним происходят,
с точки зрения датчика происходят очень быстро.
То есть чёрное появилось и заняло собой всё пятно.
И это мешает решать нам задачу плавной регулировки.
Поэтому я приподнял датчик для того, чтобы он видел большее пространство под собой.
Это повлекло ещё одну проблему, связанную с тем, что у нас в студии
много дополнительного света, который отражается и засвечивает датчик.
Поэтому придётся придумать какую-то юбочку для него,
чтобы избавиться от той самой паразитной засветки.
Теперь заглянем в изменения, которые произошли в коде.
Ну первым делом все упоминания левого датчика и пина
левого датчика я заменил на то же самое, только для правого датчика.
То есть все LEFT_SENSOR_PIN и так далее стали RIGHT_SENSOR_PIN,
затем, оказалось, что удобно добавить задержку перед концом setup, чтобы робот
не рвался из ваших рук после того, как вы нажали кнопку, вы успели убрать пальцы.
Ну а самое главное — это то, что у нас изменился знак ошибки.
Раньше мы вычитали целевое значение из значения левого датчика,
а теперь мы вычитаем его из значения правого датчика.
Поэтому у нас поменяются знаки в вызове драйва.
Чтобы робот реагировал на изменения корректно.
Алексей ПерепелкинРуководитель направления развития цифрового творчества
Дмитрий СавицкийНаучный сотрудник
