Arduino.ru

т.е. ты не понял, написав 1.2.3. что ТТХ механики твоей телеги не соответвует поставленной задаче?

протести свою телегу на линии пересечения основной - остановиться с тормозным путём не более ширины линии.

Тестили. Остановится таким способом можно только на скоростях ДО 35см/сек., и то только с включением реверса моторов на не менее 30мсек.

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

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

А чего тут советовать то, садитесь в авто, заклеиваете лобовуху так чтоб не было видно вперед дальше пары метров и газу! Далеко уедете? Какая будет безопастная скорость? Выводы ИМХО очевидны - В любых условиях безопасная скорость это такая, при которой остановочный путь заведомо меньше расстояния видимости!. Для Вас это означает что надо увеличить зону видимости, т.к. сокращение тормозного пути очевидно зашло в тупик.

Что сделано:

1. Замер тормозного пути с движения "прямо" .. с реверсом и без реверса моторами. Реверс снижает тормозной путь примерно вдвое, но не больше. Со скорости 150мм/сек получить тормозной путь короче 12см - нереально. Колеса леговские 64х20 - тяжелые и инерционные (посмотреть например тут bricker.ru набор 42009). Это "лучшие" наши колеса. Остальные - значительно хуже (инерция больше).

2. Замер поворотов на стоящем колесе, после движения по прямой с разной скоростью. Нормально попасть в линию "без ужимок" можно только на скоростях до 35см/сек. Ну, возможно выжать 40см/сек.. далее - сплошной пролет.

3. Предсказатель поворота (вынос датчиков далеко вперед), за "критические" 10см - позволяет входить в повороты с небольшим снижением скорости, но работает плохо. Только когда телега нормально подъезжает к повороту не цепляя линию из-за кривости движения по прямой. При срабатывании предсказателя на прямой - получаем поворот и выезд за линию на скорости. На извилистых участках может вылететь за линию, даже если сама телега движется "как надо" со всеми вытекающими последствиями: "оба белое - едем прямо!"

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

ок. продолжаем тупить, как обычно.

Ну и ещё, выбивает такой момент: ШИМ с заполнением менее 50 (0..255) - мотор не едет, если стояло. Если один мотор едет, то второй при таком ШИМ - едет очень даже неплохо, что резко увеличивает радиус поворота .. в общем проблема с "вычислить" какой будет радиус при заданном ШИМ на моторах .. сильно нелинейно.

В чем "тупить"? (давайте потуплю) :)

Ау, Клапауций! Так в чем "тупить-то"? То что "не соответствует"? А как сделать чтобы "соответствовало"? :)

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

?!? А чем Мега2560 плоха как прокладка? Поясните, плиз... вроде как запас скорости прохождения loop() более чем 10-и кратный. Как раз наоборот с такой скоростью моторы ваще не успевают отрабатывать воздействия. Куда уж "быстрее", а главное - зачем?

Ну вот .. и Клапауций сдулся. Вот снова, как всегда: чего ни спроси - так никто ничего и не знает. фи. Пошел спать.

плоха тем, что ты её юзаешь, а не кто-то другой - меняй мозги, упоротый.

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

Я чет не понял, Вы авто не водите? Здесь жеж полная аналогия даже выдумывать нечего.  

он и с закрытыми глазами никогда в лесу не бегал. :D

Я в этом не уверен :D

Регулировка оборотов осуществляется изменением напряжения (ШИМ), а должна выполняться регулировка со стабилизацией оборотов, что-то типа, только цифровым способом. 

А толку? стабилизация оборотов равно стабилизация скоро без учета пробуксовок, скольжения и т.д. Что это даст. Уж лучше фактическую скорость мерить, т.е. с учетом пробуксовок, скольжения и т.д. но и это не решит задачу. Проблема в том что динамические св-ва системы не позволяют: 1. пройти заданую траекторию поворота на максимальной скорости (заносит, сила инерции однако и сцепление с трассой) 2.снизить скорость до безопасной, (при которой п.1 не проблема) на отведеном тормозном пути (и снова инерция и  сцепление с трассой). 

Я вот чего не пойму.
Мне кажется, первое, что нужно оценить, а чего вообще можно ожидать на таких скоростях.
Согласно ГОСТ коэффициент трения автомобильной резины с асфальтом равен 0.8. Лично я очень сомневаюсь, что у колеса робота сцепление с той поверхностью, по которой он катается, больше.
Кстати, первое, что надо бы измерить - это как раз этот коэффициент трения. Чтобы дальше можно было проводить хоть какие-то оценки.

Ладно, пусть М = 1.5 м/с и К = 0.8.
Максимальное замедление 9.81*0.8=7.85 м/с2.
Время торможения t=1.5/7.85=0.191 c.
Тормозной путь S=1.5*0.191/2=0.143 м.
Оценим заодно минимальный радиус поворота, который можно пройти на этой скорости.
R=1.5^2/7.85=0.287 м.
Следовательно, если радиус закругления меньше, для прохождения траектории скорость необходимо снижать.

Собственно, это первые оценки, которые IMHO следовало бы сделать.
Ну а дальше я бы полстроил простенькую численную модель, на которой попытался бы выяснить, что именно ограничивает высокую скорость прохождения трассы и попытался сформулировать предложения по достижению максиммально возможной скорости для конкретной трассы.
Численная модель имеет перед натурным экспериментом, минимум, 3 преимущества:
1. Идеальная воспроизводимость без разброса параметров, что позволяет почувствовать даже малейшие тенденции, которые потерялись бы за шумами в результатах натурной модели.
2. Возможность получить точные данные в тех случаях, когда на натуре невозможно произвести измерения.
3. Экономичность - за доли секунды можно произвести сотни экспеиментов, если требуется перебор каких-то параметров в поисках оптимума.

Спасибо всем, кто подключился к решению задачи в противовес троллям, которые так и не "въехали" в вопрос ..

Да, andriano, всё верно и такой расчет конечно же БЫЛ СДЕЛАН перед постановкой задачи. К-т трения у мягкой резины шины колеса Лего с пластиком поверхности баннера (по нему и будем кататься) практически даже и в 2 раза выше рассчитанного вами. Никаких "заносов" не происходит вовсе на таких скоростях. Занос наблюдали ровно 1 раз, на доп. ускоряющем редукторе 3х .. то есть на повороте "торможением колесом" со скоростей в 4-5 метров в сек.

Минимальный радиус поворота трассы - 300мм. Тоже все соотвествует проезду теоретически на скоростях в 1.5 м/сек .. но только вот "ни получается" побороть инерцию колес. Нужна или переделка схемы размещения датчиков И иной алгоритм, или доработка алгоритма на имеющейся схеме расположения датчиков..

Пока что выяснено, что "мертвая зона" после изменения управляющего воздействия у нас составляет 8-15 см. То есть это примерно 50-100мсек от момента обнаружения сигнала с датчика.. как уже писал, можно вынести датчики на эту величину вперед (есть запас), но тогда на радиусах в 300мм они банально вылетают ЗА линию, несмотря на то что сама тележка едет правильно, и на извилистом участке это будет приводить к тому что то у нас "линия слева", а вот уже "линия справа" .. хотя ехать надо "почти прямо".. большой вынос датчиков - повышает их поперечное смещение при меньших углах поворота тележки .. играет роль как-бы усиления чувствительности датчиков к углу поворота тележки.

За схему регулировки скорости моторов по ПОС - отдельное спасибо. Управление напряжением - это просто *опа, а не регулировка.

Так, похоже что "всё надо было делать не так" .. вроде придумалось что и куда, будем пробовать, всем спасибо. Получится - после соревнований возможно выложу описание техники скоростного движения по линии.

Пока вопрос закрыт, всем спасибо.

А откуда уверенность, что дело именно в инерции колес?

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

Ну и проскальзывание никто не отменял.

Вы, кстати, пишете, что у Вас коэффициент трения в 2 раза выше, чем 0.8 (что, кстати, не рассчитано мною, а взято из ГОСТ), т.е. 1.6, хотя из физики известно, что коэффициент трения сколькжения в принципе не может быть больше единицы (в отличие, правда, от коэффициента трения покоя).

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

Кстати, количество датчиков принудительно фиксировано или оставлено на усмотрение разработчика?

Может, имеет смысл применение большего количества датчиков, чем 2? Скажем, две пары, имеющие различный вынос?

Ещё и разнести вынесенные датчики пошире, чтобы не реагировали на рысканье, а только на повороты.

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

Я не разделяю инерцию самого колеса и всей тележки. Она достаточно тяжелая - не менее 600гр. с батарейками, лего-детальками, нашим "кирпичем" и супер-моторами .. да и колеса имеют большую вращающуюся массу: шина колеса достаточно тяжелая.

Датчиками практически не ограничены: есть 4 аналогвых самодельных датчика - держат оцифровку очень надежно и стабильны в различении "белое/черное", просто 146%. :) Есть 6 цифровых датчиков, которые сложны в настройке и могут давать серийные сбои длительностью по 1-2мсек .. но зато скорость считывания - это простое чтение ноги порта датчика .. хоть мегагерцы. :) аналоговые датчики тоже можно смело загрублять до 8 бит и иметь скорости оцифровки под мегагерц .. их значение лежат ниже 255. Черное опознают так вообще 0 .. 10.

Есть ограничение на габарит тележки, но нам его хватает с запасом, чтобы поставить 2 группы датчиков, что и сделали и в чем и запутались .. в первую группу "предсказателей поворотов" входят 2 цифровых датчика и смотрят на появление линии с той или иной стороны. Они дают предсказание за 50-100мсек (+16см от оси колес моторов) в зависимости от скорости. Вторая группа - 3 аналоговых датчика: 2 за краями линии и один по центру для определения с какой стороны линия, если вылетели полностью вбок за линию. Это для переключения на алгоритм поиска линии и возврата на неё.

Проблема в том, что если ориентироваться на датчики-предсказатели, то у них получается слишком высокая чувствительность к поворотам тележки и они "врут" в таком разе, а тележка начинает "бесится" на линии - то вправо то влево и с увеличивающимся размахом колебаний пока и вовсе не вылетит за линию. Уменьшение воздействия на мотор = практически просто игнор предсказателей - мало что меняется.

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

Игрались с выносом датчиков пошире от линии или наоборот поближе .. последний вариант - стабильнее, но не дает моторам разгоняться до требуемой скорости. Зато едет значительно чище. Широкое разнесение датчиков - это просто большая пауза на разгон моторов и соотвественно большие проблемы при входе в поворот: надо тормозить лаптем, чтобы вписаться в него .. что приводит к потере скорости в самом повроте, а устойчивого алгоритма ускорения в поворте мы так и не смогли родить: начинается активное рыскание и выход за линию. На высоких скоростях - так вообще "вправо-влево .. все ушел". Третьего - не бывает.

Простите, не знаю регламент, можно ли ставить не два датчика, а, например, по два с каждой стороны, чтобы величину отклоннния от линии определить?

Отрицательная обратная связь (ООС) приводит к возникновению автоколебаний - классический случай.

По науке - нужно применение ПИД-регулятора. Может, это и самый простой вариант - только настройка ПИД=регулятора достаточно сложна. Можно попытаться ООС попроще, можно попытаться ввести в ООС нелинейность, но тут опять же баланс трудоемкости между "настройкой коэффициентов для сложного алгоритма" и "придумывание простого алгоритма + настройка коэффициентов для него".

Но в общем случае: возникновение и нарастание колебаний однозначно говорит, что ООС только по текущим показателям явно недостаточно, нужно вводить зависимость также от производной и/или интеграла.

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

Зная автора  по форуму давно ;) очень вероятно что неустойчивость он же сам и создал своим уровнем понимания. Получив сигнал о повороте он что делает? Он тормозит колесо со стороны поворота. При этом корпус разворачивает в сторону поворота, это первично, траектория повернет потом, может быть, если успеет. Ясно что датчики видят уход с линии и для компенсации ухода начинают тормозить противоположное колесо. Теперь тачку развернет в противоположную сторону для возврата на линию, отчего датчики увидят еще более крутой поворот впереди. Так ей и колбасит. 

В принципе это тоже неустойчивость САР, но лечить её логично не ПИД а устранением лажи в коде. Или попробовать конструктивом минимизировать - "ближние" датчики как можна ближе к оси разворота корпуса. 

Так все-таки, что там по регламенту? Можно ли иметь больше двух датчиков освещенности? Тогда можно строить спрямляющие траектории, минимизируя силы инерции, следовательно увеличивая устойчивость и/или скорость?

Никто не учился спортивному вождению "больфих мафынок"? ;) Всякие углы входа в поворот и прочее... Можно ли такое применять у роботов? То есть как применить - понятно, но можно ли по регламенту?

// Можно ли такое применять у роботов? 

Чегож низя физика одна. Тут бы сразу без спортивного вождения, обычным манером, сбрасывая скорость перед поворотом научить )) Учитывая что грубо прикинутый теоретический радиус поворота практически равен требуемому, без притормаживания никак. Управляемый занос думаю нереально делать.

Регламент не ограничен, кроме как габаритными размерами 400х400мм. Можно хоть 100 датчиков. Вчера гоняли на 5-и .. помогает, но плохо. Спрямляющие траектории - строить низзя. Если машинка вылетает всей стороной (колесами, а у нас оно одно на сторону) за линию больше чем на 3 сек, то все - "снято" .. с соревнований. Да, ещё запрещены любые готовые контроллеры и машинки на их основе и с готовой программой, типа на базе Лего NXT, EV3 и прочие готовые конструкторы.. можно даже не на Ардуино, главное - свое.

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

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

А чем ограничен выбор резины? На предмет увеличения коэф. сцепления. Вес и мощность ограничены?

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

andriano, конечно проблема в болтанке благодаря "ООС". Любое управление, возвращающее тележку на трассу - есть ООС. Но по идее её надо делать затухающей .. а вот как? Без снижения скорости до приемлемых 40см/сек у нас вчера так и не получилось, но это не интересно ни разу...

В общем, пока всем участникам огромное спасибо, завтра отпишусь получилась ли сегодняшняя идея ..

P.S. по ПИД: некий аналог у нас есть (величина изменения скорости зависит как от самой скорости так и от длительности проблемы), но его параметры крайне сложно подобрать на практике. В прошлый раз это удалось и тележку мы смогли разогнать до 55-65см/сек. Сейчас задачка чуть сложнее.

А Вы пошарьтесь по робототехническим соревнованиям в вашем городе .. должны быть. Ежели Москва - то точно есть, в прошлом году видел .. но там и задачи посложнее и посеръезнее. Мне и так ещё предстоит заяснить ребенку как и на каких принципах будет построено то, что я хочу ему предложить сегодня.. это явно не уровень его 4-го класса. А прогу-то ему писать.. :)

выбор резины и всей конструкции ограничен .. наличием. Что имеем, то и гоняем. Скажите спасибо что нас принимают на школьные соревнования как "частную команду" в порядке исключения .. в этот раз ардуинщикам даже в регламенте срезали возраст до 10лет .. в прошлом году было "от 12-14" :)

Кстати да, интересная идея с несколькими датчиками на разном расстоянии от линии: можно будет ввести диф. составляющую в ПИД по тому на сколько датчиков отвалились от линии.. надо пгобовать тоже. По крайней мере это понятней для ребенка.

Всё, уехал пилить идею .. отпишусь что получилось.

Вы корректируете траекторию когда аналоговый датчик увидел линию, или добиваетесь равновесного показания обоих крайних датчиков?

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

Ответ: Может. Если папа достаточно хорошо разбирается в предмете - так, что может объяснить это на пальцах. Причем, достаточно объяснить задачу, не навязывая какие-либо методы решения (именно это я имел в виду под словом самостоятельно).

Снимите видео прохождения поворота, желательно сблизи. Замедленное рассмотрение поможет вам, и нам интересно будет

Может, если ему 20 лет и он студент хорошего вуза.

2Logic: После 18 лет - уже не ребенок.

Конкретный приведенный пример относится где-то к 7-9 классу (точно не помню).

2ТС: Мне кажется, было бы интересно прокатать разные алгоритмы на одном простом примере трассы - прямая, переходящая в круг минимального радиуса.

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

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

Может - не может .. не о том речь. Нет тут никаких дифуров в частных производных .. есть некоторые трудности с программированием. В его ардублоке такое не накатаешь.

Arhat109-2, это я написал к тому, что с ребенком надо заниматься, и в будущем это принесет свои плоды. Так что все правильно. И не расстраивайся - на день (два-три) - это еще не "затягивается". Нельзя допустить, чтобы эта вещь его утомила. Так что пусть двигается в своем темпе, не нужно форсировать.

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

Это всё понятно, спасибо. Я похоже подпалил ему наш кирпич .. жрет 150мА и AMS1117A греется не по-детски с Li-ion аккумов 12.35в. (* завтра меня побьют *)

У вас при поворотах центр вращения впереди корпуса машинки.

Интересно, если приклеить двусторонним скотчем груз сзади (сместить центр тяжести назад), как это скажется на радиусе поворота.

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

кратенькая справка о назначении рулевой трапеции

"При передаче усилия руля на рулевой привод , последний  должен повернуть управляемые колеса на определенный угол. Здесь должно обязательно соблюдаться одно условие,

поворот колес должен  осуществляться на неодинаковые углы.

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

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

Это соотношение выполняется с помощью конструкции рулевой трапеции, включающей в себя поворотные рычаги и шарнирные рулевые тяги. Именно подбором угла наклона рулевых рычагов, их длины и длины поперечной тяги удается добиться необходимого соотношения углов поворота колес."

Это наша тележка с прошлых соревнований. Тоже 2 ведущих колеса и шаровая опора. Также тут видно характерное расположение передних датчиков. Расстояние от оси колес до шаровой опоры примерно равно расстоянию от оси до линии установки датчиков. Это условие нам подсказали в прошлый раз и по нашим экспериментам оно дает самое оптимальное управление на 2-х датчиках. Тут "мелкие колеса" Lego 42x38, моторы теже самые, датчики цифровые, лего-кирпич - предыдущий вариант: "большой" 120х80х50 мм на базе 8 батареек АА по 1.5в. Ширина колеи около 16см. Тут ширина линии всего 2см. Достигнутая скорость на этой фото = 55-65см/сек. Предельная скорость по прямой = 85см/сек. Драйвера моторов L298N, на которых высаживалось около 1.5в от питания.

Сейчас: тот же конструктив 2 колеса + шаровая опора (эта же), колеса 62х20 (больше и уже), питание 3S Li-ion и мосфетные драйвера моторов. Как результат имеем предельную скорость движения по прямой 150см/сек, при практически той же ширине колеи в 180мм, но за счет меньшего размера блока и узких колес он помещается между моторами и все существенно ниже по высоте - более чем вдвое.

Кроме этого на этой линии стоит 3 аналоговых датчика, и дополнительно вперед на 10см вынесен блок с ещё двумя цифровыми датчиками (тутошние с фото).

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

Поскольку наш кирпич на базе 2560 как-то странно греется стабилизатором питания и в покое теперь жрет 150мА вместо привычных 86 .. то будем переходить на резервную УНО пока совсем не спалили Мегу...

К сожалению, сейчас фотать просто нечем .. заломалось все что было за последний месяц. А на старые цифромыльницы, которые ещё есть - дома снимать тяжко - слишком темно и получаются очень плохие кадры. Не до фотиков..

Да, посмотрел. От передние датчики вынесены вперед осями на 16, соответственно расстояние между датчиками 13*8 = 104мм ..

Если спереди поставить аналоговые датчики, то можно попробовать определять поворот или только касание линии, по скорости нарастания(падения?) показаний АЦП.

Или поставить спереди по два цифровых датчика с каждой стороны, под углом.

Если пришел сигнал касания линии только с датчика 2, плавно подруливать, если сразу с 1 и 2, то круто поворачиваем.

Только угол между датчиками подбирать опытным путём придётся.