roboforum.ru

Ребенок в школе делает самостоятельную работу - "Исследование простейших алгоритмов группового поведения роботов при прохождении незнакомых объектов типа лабиринт".

В итоге будем моделировать алгоритм Крейга Рейнольдса.
Правила алгоритма:
1. Держать скорость как у соседа
2. Сохранять до ближайших соседей одно расстояние
3. Постараться ни с кем не столкнуться.
Вообще из-за сложности проект разбит на две части:
1 часть (10 класс) - разработка и создание одного из группы роботов, разработка алгоритма прохождения одиночным роботом простого лабиринта.
2 часть (11 класс) - исследование простейших алгоритмов группового поведения роботов при прохождении незнакомых объектов типа лабиринт.

Сначала думали купить платформы на АЭ.
Но потом спроектировали свою - побольше и поменьше. Остановились на той, что поменьше - тестовый лабиринт будет меньше места занимать.
Корпус распечатан на 3D принтере.
Диаметр итогового ройбота - 80мм.

На скрине все три платформы.
Слева направо: итоговый вариант, промежуточный, магазинный

Пока готов только тестовый - 1 черный



Небольшое видео.

В предосмотре почему-то не видно, но надеюсь, что нормально в сообщение вставится (модераторы - поправьте пожалуйста).
Если не вставится, то вот ссылка на Ютуб.

Будущая группа.


Группа в большом лабиринте.



Тестовый лабиринт (из спроектированных деталей можно собрать несколько вариантов)


Фото/видео тестового подготовлю позже, если будет интерес у сообщества.

на первое время с физическими ботами, ориентироваться не сильно сложно будет? на компьютере можно простенькую программу написать. сходу делать в каком игровом движе, может и не стоит (может уйти больше времени на изучение движка). форму и на ней отрисовывать. ещё кстати processing есть, по подобным алгоритмам в сети есть ряд скетчей. введите, к примеру такой запрос "processing boids".
с физической реализацией для упрощения ориентации можно использовать одну или несколкьо внешних камер. сверху на каждого бумажку с визуальным кодо, по которому идентифицировать каждого робота, определять его положение и направление. или esp32 + камера, кадры передавать или на ботах обрабатывать или отправлять на компьютер. на ботах где-то выше дальномеров, по периметру корпуса 4, 5 или 6ти гранник, на сторонах которых визуальные метки, по которым хотя бы расстояние определять. с камерой на боте для ориентации ещё можно, допустим примерно как тут два варианта маркировки

или ещё какую маркировку продумать
из компактных платформ ещё можно шагающего (два мотора - одним поворачивает, вторым шагает вперёд/назад). вот одного в банку поймал, пока не убежал

вот кстати человек так реализовал

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

Angel71 писал(а):на первое время с физическими ботами, ориентироваться не сильно сложно будет?

Нет.
Первый Черный уже вовсю бегает среди лабиринта из книг.
Проблема с фотиком - сломался. Новый будет только на неделе - тогда и сфотаем/сделаем видео.
Ну и еще лабиринт не доделан - сохнут покрашенные стенки (фанера).
У каждого робота по несколько сенсоров:
Один HC-SR04 - дальняя зона
Два TCRT5000L - средняя зона
4 датчика касания (концевик) - ближняя зона
Думаем, что этого им для "общения" будет достаточно.
На крайний случай, любому роботу из группы можно будет "подсказать" по WiFi куда бежать, кроме того они могут по WiFi общаться между собой.
А о своем состоянии робот сможет сообщать при помощи пищика и/или светодиода.

В школе. Роевое поведение роботов.
Хмм... А как успехи с холодным термоядом?

"Занимаюсь на труде синхрофазотроном." (с)

Физмат класс с ориентацией в сторону робототехники.
В программе обучения есть следующие предметы (помимо основных): мехатроника, электротехника, инженерная графика, программирование, избранные вопросы математики

Это у нас была халява - а сейчас или мозги или деньги (или все вместе).

в том-то и дело, что все датчики видел и есть небольшое опасение, что ориентация для данной задачи может оказаться немного проблемной. в лабиринте один то нормально бегать будет. а для группы с учётом задач вроде многовато косвенных и не очень точных данных. хотя сильно зависит от подхода. должны карту строить, понимать где они сейчас находятся и в каком направлении ориентированы или на полуощупь тыкаться, как-то пытаться понять перед ним стена или другой бот. и т.д., т.е. в том числе и как воспринимать ваши пункты 1 и 2. та же скорость зависит от шима и напряжения аккумуляторов. энкодеров нет, данных об абсолютном положении других нет, относительные кое как косвенно и неточно. т.е. как скорость и расстояние выдерживать? даже данные о скорости в додумываемых попугаях - с разно просевшими акуумуляторами, простым заданием шима реальная скорость будет немного отличаться. до некоторой степени это может и не будет проблемой. ещё двигаются же они не по виртуальным клеткам, перепрыгивая из текущей в одну из 8ми соседних (и обсчёт всех за один тик), а по разным путям с асинхронно работающим кодом на каждом.

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

Все будет без карты.
С условием построения карты сильно дорожает каждый робот и усложняется общий алгоритм взаимодействия.

Angel71 писал(а):т.е. как скорость и расстояние выдерживать?

- возможно будет просто условие нахождения в группе. Возможно, еще реализуем узнавание свой-чужой (стена).

Angel71 писал(а):в общем много от подхода и желаемого поведения зависит и в отличии от виртуальной реализации, для физической при реализации всякие интересные или труднорешаемые особенности могут нарисоваться.

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

Angel71 писал(а):а уз мешать друг другу сильно могут. если с уз будут трудность, можно сделать согласование. к примеру у первого тймаут по времени и если последний долго не сообщал о сканировании, начинать скан. включил уз, измерял, отключил и в эфир "первый закончил"/"второй давай сканируй". второй закончил скан, сообщает третьему. и т.д.

Думали сделать "плавающий" период опроса. Но этот вопрос решим как будут несколько роботов.
Сейчас надо все, что сделали оформить и сдать сделанное (это прохождение одиночным роботом лабиринта).

meoita писал(а):Драйвер двигателя не позволяет манипулировать скоростью вращения мотора, приходиться некоторые вопросы по другому решать.

какой драйвер (микросхема) используется? в каких-то наверно можно по некоторому протоколу частоту шима или ещё что задавать. в некоторых отдельный пин для шима. в некоторых можно шимить через два управляющих пина. для примера drv8833 (отличий между разными decay режимами заметить не удалось)

Драйвер "TZT teng.5A"

Карта управления

не успел картинку добавить. ну вот такой же случай. шимировать одновременно через один из управляющих пинов. один в смысле, для in1 и in2 только один из них шимить. из in3 и in4 тоже только один.

Пробовали - реакция только на наличие/отсутствие сигнала, т.е. управление "1" или "0". Но с ШИМом тоже работает - 125 как "0", выше как "1" воспринимается.

Код: Выделить всё • Развернуть

void SetPwm(uint16_t pwm1, uint16_t pwm2)
{
  __HAL_TIM_SET_COMPARE(&htim3, TIM_CHANNEL_1, pwm1);
  __HAL_TIM_SET_COMPARE(&htim3, TIM_CHANNEL_2, pwm2);
}

void Servo::stopMotor()
{
  SetPwm(1, 1); //slow decay
}

//direction 0 - to minimum of potentiometr value, 1 - to maximum
void Servo::runMotor(bool direction, uint16_t pwm)
{
   bool decayMode = 0; //decay 0 - fast, 1 - slow
  if(config.invertRotation)
      direction = !direction;
   
  if(pwm > pwmMaxPulseWidth)
    pwm = pwmMaxPulseWidth;
  if(direction)
  {
    pwm1 = decayMode; // TIM_CHANNEL_1
    pwm2 = pwm; // TIM_CHANNEL_2
  }
  else
  {
    pwm1 = pwm; // TIM_CHANNEL_1
    pwm2 = decayMode; // TIM_CHANNEL_2
  }
  SetPwm(pwm1, pwm2);
}

не помню, почему так и переделывал ли потом. на всякий, может для вашего мк и прочего так тоже подойдёт.
да не, похоже просто код причесать нужно и заработает шим. на всякий перепроверить, привильно ли собственно шим настроен и задаётся. скважность это не прямое линейное управление скоростью. т.е. задали 3% или 95%, не будет вращать прям на 3% или 95% от максимальной скорости. до некоторой скважности вращения не будет совсем. потом еле-еле будет пытаться вращать, но всё ещё "мощности" не хватит. потом постепенно (зависимость не линейная) скорость должна увеличиваться. в определённый момент будет максимальной, но шим ещё сколько-то там докручивать можно. тут с этим всем ещё с нагрузкой момент.
допустим потенциометр подключить к мк, на один пин единицу, а второй шимить в зависимости от того как выкручен потенциометр. из простого, можно скважность через консоль в уарт отправлять.
с шимом скорость калибровать. или замерять, допустим оптопрерывателями в двух точках на "трассе". или на вал/колесо метку как сделать и оптопарой частоту замерять. потом сделать массив из нескольких значений соответствия скоростей шиму и промежуточные интерполировать по простому вычислять, ну или засисимость определить и более точно вычислять.

Angel71 писал(а):просто код причесать нужно и заработает шим. во-первых скважность это не прямое линейное управление скоростью. т.е. задали 3% или 95%, не будет вращать прям на 3% или 95% от максимальной скорости. до некоторой скважности вращения не будет совсем.

Управляющий канал понимает только наличие/отсутсвие сигнала на нем.
Пробовали разную скважность ШИМ (меняли по 1%) - не работает с этим драйвером как хотелось бы.
Ну, или мы не умеем.

пока из догадок, что нужно перепроверить (мультиметром и/или даталоггером), настроен ли шим правильно, как потом скважность задаётся, может попробовать другие частоты шима. с этим драйвером не сталкивался и даташит что-то не наодится (маркировку микросхемы драйвера трудно понять, у китавайцев в лотах вплоть до всякой дичи на подобии l298 упоминается), но возможно как и с drv8833 ещё какой нюанс с шимом. в drv8833 там внутренний генератор для шима на 50кгц (не приятно на некоторых моторах, пищит и дополнительных муторных телодвижений), т.е. внешний шим накладывается на внутренний.
п.с. альтернативный вариант, если не захочется возиться или с тем драйвером что-то не так, это использовать другие драйверы. тот же drv8833 или что на подобии из недорогого и компактного. из вариантов не очень (короткое легко устроить), хоть на транзисторах (посмотрите схему и код той же openservo).

Angel71 писал(а):с этим драйвером не сталкивался и даташит что-то не наодится (маркировку микросхемы драйвера трудно понять

Даташит тоже не нашли. Только вот такое видео - ссылка.

Вторая причина, по которой не использовали что-то другое - дефицит свободных выводов на Ардуино. Мультиплексоры ставить не выход - места мало на теле робота.

В принципе, как писал уже выше, мы все проблемы отсутствия регулирования скорости моторов решили.