Спасибо за совет, но как-то слабо представляю себе КАК им воспользоваться (без шуток, это - не сарказм).
То, что Вы предлагаете, давным-давно сделано в программе на Экселе .. введены все формулы, работают в СГС или СИ (где как удобно) .. так, скажем что трение переднего колеса в повороте получено в 67гр., а трение качения всей тележки в 33гр. и?
В конечном итоге, у него программа оперирует .. увы, "попугаями" АЦП и величиной управляющего ШИМ .. и больше ничем. Причем, варианты кода я выкладывал в своей теме "Ардуино как Лего" совсем не давно.
В чем конкретно заключается ваш совет?
P.S. "трение переднего колеса в повороте" - следует читать как "... приведенное к ведущему внешнему колесу"
P.P.S. Не согласен, что "приводят к неверным результатам", хотя бы на таком примере:
Есть простой расчет движения по заданному радиусу: имеем радиус и ширину колеи ведущих колес. Соответственно, внешнее колесо должно крутиться быстрее внутреннего на соотношение радиусов, по которым они движутся. Их вычисление - тривиально: плюс-минус полуколея.
Но, для скоростного движения этого явно недостаточно, поскольку есть эффект "переноса веса" на внешнее колесо из-за центробежной силы. Перенос веса тоже можно вычислить как зависимость от высоты Ц.Т. и той же колеи и величины самой центробежной силы, которая зависит квадратично от скорости движения по радиусу. А поскольку скорость вращения DC-мотора линейно падает от приложенной нагрузки, то можем учесть и этот "эффект", раскручивая внешнее колесо соответственно "шустрее".
Но, для скользящего переднего колеса опять возникает доп. сила, которая нагружает внешнее колесо .. считаем. В результате получаем соотношение скоростей вращения колес .. зная "вес 1 ШИМ" переводим его в соотношение подаваемого ШИМ на внутреннее и внешнее колесо.
.. как итог, едем по заданному радиусу достаточно точно. И один круг и два и хоть 100500 (может ехать часами). Проверено. А самое забавное, то что как только (позавчера конкретно) пересчитал трение переднего колеса, мои рекомендации к табличным радиусам .. совпали с подобранными ребенком значениями во время второй тренировки на отборочном соревновании до 1..3 /128. :)
(после соревнования осмотр программы и настроек: -"Ты зачем так ужал пропорциональные к-ты?" -"А так получилось. Твои значения не поехали, мои - лучше")
Это как пояснение, где применяется "вес 1 ШИМ". В чем "неверное предположение"?
Ну и ещё: оно же "едет"! Да, но только до определенной предельной скорости... то есть, как понимаю, проблема не в неверном подходе "вес 1ШИМ", а в каком-то "неучтенном факторе", который до этого порога - незначителен. Э-э-э .. сопротивление воздуха?!? (-"от неё реально ветер идет!" (с) сын .. уже не знаю на что думать)
.. в общем, пока взяли таймаут на подумать .. тем более что протектор этой пары колес уже изрядно поизношен. С трассы после каждой покатушки приходится снимать мелкую пыль из остатков резины.
В конечном итоге, у него программа оперирует .. увы, "попугаями" АЦП и величиной управляющего ШИМ .. и больше ничем.
Вспоминается старый анекдот про пьяного, который ищет часы не там, где потерял, а под фонарем - где светлее.
Это очень похоже на Ваши аргументы: ведь все равно оперировать ШИМ. Но проблема в том, что - да, там, где светлее, часы найти принципиально невозможно. Просто потому, что их там нет. Хотя искать - приятнее. Вот точно так же, и с пропорциональностью ШИМ и скорости - да, так считать проще, но добиться успеха невозможно, т.к. это неверно.
Т.е Вы выбрали весь диапазон того, что можно было сделать без знания физики. Но хотите идти дальше. А дальше без этих знаний не получается, метод тыка дельше не работает. Точнее, тыкаясь вслепую, теоретически можно что-то насчупать, но во-первых, это требует очень большого количества попыток, но, самое главное, реальные измерения имеют довольно высокую шумовую составляющую, из-за которой очень трудно уловить тенденции.
И вот здесь могла бы помочь физика. Но мешает то, что Вы ее явно не знаете и подменяете физические законы несуществующими закономерностями.
Вот вопрос первый: ШИМ - это скорость или ускорение?
Ответ: ни то, и не другое.
Рассмотрим для начала электродвигатель, питаемый постоянным напряжением. Это проще, чем ШИМ.
Напряжение на двигателе в первом приближении можно считать суммой ЭДС индукции и падения напряжения на активном сопротивлении якоря. ЭДС индукции пропорциональна скорости вращения. А падение напряжения - току. Ток в свою очередь пропорционален моменту. Другими словами, напряжение пропорционально сумме скорости и ускорения с некоторыми коэффициентами. В некоторых случаях большее влияние оказывает скорость (предел - холостой ход), в некоторых - ускорение (предел - старт с места при нулевой скорости).
Другими словами, подав на двигатель некоторое напряжение, мы ничего не можем сказать ни о скорости, ни об ускорении, если не знаем всю предысторию. Если знаем - можем проинтегрировать и получить результат. Очевидно, с некоторой погрешность. Очевидно, погрешность при интегрировании будет накапливаться со временем. Отсюда выворд: чтобы хоть как-то прогнозировать движения, нам не хватает данных - нужен какой-то еще источник информации. Напримеро, энкодеры на колеса, чтобы мы могли получать не прогнозируемую с погрешностью, а реальную скорость. И из нее и приложенного напряжения - реальное ускорение. И тогда уже можно будет сделать реальный прогноз - уйдет колесо в занос или нет. А не пытаться оценить это исходя из "предельной" величины ШИМ, выявленной при совершенно других условиях с другим соотношением между скоростью и ускорением.
Далее.
Выше мы предположили, что мотор питается постоянным напряжением. У нас он (пока) питается пульсирующим напряжением от ШИМ. И здесь все не так просто: никакой пропрорциональности между средним значением напряжения (читай - величиной ШИМ) не наблюдается. Причина, как я думаю (я могу и ошибатьсся, но именно на такие выводы навели меня результаты обмера электродвигателя, питаемого ШИМ), в том, что часть времени якорь не обесточивается, а работает в режиме торможения (в которкозамкнутом режиме). Из-за этого происходит сразу две неприятные вещи:
- теряется линейность между ШИМ и "эффективным" постоянным напряжением,
- снижается КПД всей системы.
Поэтому я бы пордумал над тем, чтобы все-таки питать колеса от регулируемого постоянного напряжения, т.е. от импульсного регулируемого источника, на выходе которого уже не прямоугольник изменяемой скважности, а регулируемое постоянное напряжение.
В эту сторону я тоже уже рассуждал, но примененный нами мосфетный драйвер моторов (отдельная большая тема в проектах) не имеет режима рекурперативного торможения короткозамкнутым ротором, как понимаю и как вижу на практике. Режим отключенного ШИМ у него тупо разрывает цепь якоря и только: оба нижних мосфета просто переводятся в закрытое состояние и мотор предоставляется "сам себе" на выбег. То есть мотор или получает питание или просто разорвана цепь якоря и на конденсаторе якоря растет напряжение в генераторном режиме. Из-за этого эффекта ШИМ - все-таки "примерная скорость" мотора, но да, только примерная и очень грубая. Тут - согласен. Драйвер L298N - да, при определенном управлении имеет описанный вами эффект периодического КЗ якоря, но его тоже можно использовать в режиме свободного выбега при управлении ШИМом.
Отсюда, подача заданного ШИМ на драйвер приводит со временем к установке одной и той же скорости моторов и достаточно быстро, что мы и наблюдаем на практике. Но, в целом, вычислить какая это будет скорость - на практике малополезно, ибо да, скорость DC-мотора есть следствие поданного напряжения И мех. нагрузки на ротор. Последняя меняется в зависимости от динамики движения. Какие-то эффекты этой динамики мы уже учли, а какие-то ещё нет.
Кроме этого, мне кажется что "предел скорости" у нас связан с подходом к реализации алгоритма - табличное (и достаточно грубое) приближение управляющего воздействия и имитация вещественных чисел дробями по 1/128. Видимо далее этого подхода уже недостаточно.
Ну не могу я объяснить иначе наблюдаемые эффекты: до определенного ограничения максимальной путевой скорости - робот едет очень стабильно и может кататься так непрерывно и очень долго .. "часами", а при превышении этого порога начинается болтанка по линии и она тем больше, чем больше это превышение и "задавить" подбором/перерасчетом настроек табличного управления .. не получается. Идет перекос то в одну, то в другую сторону: или мы тупо теряем трассу и едем в какой-то момент "прямо" не успевая зарулить или наблюдаем сильную "перерегулировку", которая эффективно снижает путевую скорость до .. значений ниже чем "допороговая" скорость движения. Скажем так, макс. скорость "до" порога - время прохождения трассы 11сек., а при макс. скорости выше порога - "вылеты" или прохождение трассы .. 12сек. То есть пропадает весь полезный эффект от повышения из-за "болтанки".
Пока вижу несколько эффектов: а) сопротивление воздуха (маловероятно, но все же); б) высокопрофильная шина (поперечный изгиб резины в повороте - искажение показаний датчиков из-за доп. отклонений); в) недостаток точности вычислений; г) высокая частота дискретизации обработки в 4мсек на управляющий цикл.
п. "б" детальнее: Используемые колеса Лего 62.4х20 имеют резину высотой профиля 13мм и попытки поболтать тележку на колесах показывают что при резкой смене направления движения, изгиб профиля запросто может приводить к ложному срабатыванию датчика .. надо проводить испытания. К сожалению, есть низкопрофильные колеса, но они малого диаметра и наш мотор-редуктор на них не сможет достигнуть требуемой путевой скорости даже наполовину.
Секундомером, вручную. :) Нет энкодеров и их установка не запланирована - некуда.
я о скорости движения телеги относительно трассы спрашивал, а не о скорости вращения колёс - нужно и то и другое, т.к. телега должна адекватно реагировать на отрыв колеса от трассы.
*по сути, если ты не планируешь ставить датчики, то что, вообще, тут обсуждается?
В эту сторону я тоже уже рассуждал, но примененный нами мосфетный драйвер моторов (отдельная большая тема в проектах) не имеет режима рекурперативного торможения короткозамкнутым ротором, как понимаю и как вижу на практике. Режим отключенного ШИМ у него тупо разрывает цепь якоря и только: оба нижних мосфета просто переводятся в закрытое состояние и мотор предоставляется "сам себе" на выбег. То есть мотор или получает питание или просто разорвана цепь якоря и на конденсаторе якоря растет напряжение в генераторном режиме. Из-за этого эффекта ШИМ - все-таки "примерная скорость" мотора, но да, только примерная и очень грубая. Тут - согласен. Драйвер L298N - да, при определенном управлении имеет описанный вами эффект периодического КЗ якоря, но его тоже можно использовать в режиме свободного выбега при управлении ШИМом.
Эта?
Сборка AO4606 на схеме изображена не совсем верно, т.к. в ней помимо полевиков присутствуют встречно параллельно включенные диоды. Которые, кстати, в подобных схемах играют существенную роль и ставятся, если отсутствуют в приборе изначально:
А теперь вопросы:
1. Зачем там нужны диоды?
2. Идет ли через них когда-нибудь ток?
3. Если идет - когда?
Цитата:
Отсюда, подача заданного ШИМ на драйвер приводит со временем к установке одной и той же скорости моторов и достаточно быстро, что мы и наблюдаем на практике.
Давайте оперировать не расплывчатыми понятиями, а конкретными цифрами: "достаточно быстро" - это сколько (постоянная времени в мс)?
Цитата:
Но, в целом, вычислить какая это будет скорость - на практике малополезно,
Но то есть мы уперлись в то, что не знаем, куда дальше копать, но заранее отвергаем как заведомо малополезное то, что нам не хочется (или считаем, что слишком сложно) использовать? Опять очень напоминает пьяного у фонаря.
Цитата:
ибо да, скорость DC-мотора есть следствие поданного напряжения И мех. нагрузки на ротор. Последняя меняется в зависимости от динамики движения. Какие-то эффекты этой динамики мы уже учли, а какие-то ещё нет.
Надо не учитывать отдельные моменты (т.е. не вносить поправки), а изначально аккуратно прописать физику. Тогда и необходимость, чтобы дополнительно что-то учитывать, отпадет.
А проблема в том, что через напряжение на якоре скорость и ускорение связаны между собой. И, не зная скорости, мы никак не сможем вычислить, какое напряжение нам надо подать на якорь для обеспечения определенного ускорения.
Цитата:
Кроме этого, мне кажется что "предел скорости" у нас связан с подходом к реализации алгоритма - табличное (и достаточно грубое) приближение управляющего воздействия и имитация вещественных чисел дробями по 1/128. Видимо далее этого подхода уже недостаточно.
Рано говорить о точности реализации, когда мы еще не сумели найти те зависимости, которые надо реализовывать.
Цитата:
Ну не могу я объяснить иначе наблюдаемые эффекты: до определенного ограничения максимальной путевой скорости - робот едет очень стабильно и может кататься так непрерывно и очень долго .. "часами", а при превышении этого порога начинается болтанка по линии и она тем больше, чем больше это превышение и "задавить" подбором/перерасчетом настроек табличного управления .. не получается. Идет перекос то в одну, то в другую сторону: или мы тупо теряем трассу и едем в какой-то момент "прямо" не успевая зарулить или наблюдаем сильную "перерегулировку", которая эффективно снижает путевую скорость до .. значений ниже чем "допороговая" скорость движения. Скажем так, макс. скорость "до" порога - время прохождения трассы 11сек., а при макс. скорости выше порога - "вылеты" или прохождение трассы .. 12сек. То есть пропадает весь полезный эффект от повышения из-за "болтанки".
Внешне напрашивается такая аналогия с радиоэлектроникой: при увеличении коэффициента устииления усилителя (коэффициент без ООС), охваченного ООС, увеличивается глубина этой самой ООС, что на некотором этапе ведет к неустойчивости и самовозбуждению. Выход - применение более скоростного усилителя.
Собственно, я уже спрашивал о конкретной величине постоянных времени механических узлов. Хотелось бы сравнить эти цифры с пеиодом опроса датчиков и периодом применения управляющего воздействия. Можеи, на предельных скоростях мы уже подходим к пределу Котельникова-Шеннона?
Цитата:
Пока вижу несколько эффектов: а) сопротивление воздуха (маловероятно, но все же); б) высокопрофильная шина (поперечный изгиб резины в повороте - искажение показаний датчиков из-за доп. отклонений); в) недостаток точности вычислений; г) высокая частота дискретизации обработки в 4мсек на управляющий цикл.
а) маловероятно. Для автомобиля это начинает проявляться где-то порядка с 10 м/с. Понятно, что у робота аэродинамика хуже, но учитывая, что сопротивление воздуха пропорционально квадрату скорости, при вчетверо худшей аэродинамике все равно получим не менее 5 м/с.
б,в) возможно. Хорошо бы это промоделировать.
г) может, наоборот, слишком низкая? Если проблемы получаются при увеличении скорости, порвое подозрение - "не успевает", т.е. постоянная времени обраной связи больше, чем необходимо для обеспечения устойчивости.
Кстати, я бы покопал именно в этом, последнем, направлении.
Если нет возможности быстро увеличить частоту опроса/реагирования, может попробовать, наоборот, ее уменьшить. Тогда, если последствием такого изменения будет пропорциональное уменьшение предельной скорости, источник проблемы таким образом будет найден.
Ок, отпишусь по результатам. Ребенок сегодня занят домашним заданием .. проболел неделю теперь сидит догоняет, завтра в школу.
С частотой дискретизации "не всё так просто". Дело в том, что используется Ардублок, который не имеет даже некоторых возможностей wiring, а именно, его pulseINn() не имеет управления таймаутом и мне пришлось собирать свой измеритель расстояний на этих "блоках". Замер делается по 2мсек, каждые 40мсек (устранение дальнего эха) и для выравнивания циклов в промежутках стоит пауза в эти самые 2мсек. Далее, analogRead() читает только по 5 замеров в мсек .. у нас 5 датчиков - вот вам ещё 1 мсек. Все вычисления делаются конечно же очень быстро примерно за 150мксек, но от этого не легче ни разу. А главное в том, что ШИМ - типовой на 490гц, и соответственно ускорять цикл выше 2мсек - нет никакого смысла - не будет ШИМ управления. И так всего 2 периода ШИМ на 1 управляющее воздействие.
Первое что надо - поднимать частоту ШИМ, но этого Ардублок снова не умеет ни разу. Второе - переводить опросы датчиков на прерывания .. аналогично. Все это у меня есть в моей библиотеке, но хочется чтобы ребенок выступал со своей программой всеж-таки, а не "супер-ассемблерной" на базе RTOS. (Очень невыгодно смотрелся его конкурент на отборочных, отвечая на вопрос судьи "Сам делал?", да и мнение сына: -"А я знаю чего он так разнервничался. Он там что-то испортил, я видел и слышал(соседние столы) как он говорил "не знаю нафига это .. пусть будет столько .. блин, я не помню сколько тут было, как теперь поправить?..", помнишь как хорошо он у него ехал на первой тренировке и как метался на второй? - как-то не хочется, чтобы он на тренировке точно также "сел в лужу")
Диоды там конечно же есть. Они нужны для гашения выбросов напряжения от самоиндукции якоря .. как-то не рассматривал их как режим "рекурперативного торможения короткозамкнутым якорем", поизучаю .. но, на практике хорошо видна разница между КЗ-торможением и простым выбегом - её и наблюдаю в реальности.
Инерция мотор-колесо это примерно 10-15мсек на изменение движения, в то время как управляющие воздействия идут каждые 4мсек.
"малополезно" - в смысле "недостаточно точно". При описанном ранее движении по радиусу можно получить точность плюс-минус пара сантиметров от заданного радиуса. Получить точнее - нет. Управляя величиной ШИМ и зная "вес 1ШИМ" можно выставлять скорость движения по прямой тоже плюс-минус 2-5см/сек, не точнее. Собственно этот параметр мною использован не столько для вычисления с какой скоростью идет тележка по трассе, сколько для предварительного рассчета с как быстро и насколько можно изменять ШИМ на моторах, чтобы не потерять сцепление с трассой (макс. величина изменения ШИМ за 1 цикл).
В последнем направлении копали уже достаточно давно - перед пред. городскими соревнованиями. Вполне безболезненно можно увеличивать период цикла loop() вплоть до 8мсек .. мало что меняется. Но там скорости были пониже и трасса существенно проще - по сути всего 2 радиуса в 30 и 60см. Под них и подстраивались. Тут трасса рисована "вручную" и нет двух одинаковых поворотов .. они только с виду одинаковые.
Похоже пока накатались. С тележкой творится нечто странное, причину найти пока не можем:
1. Узв. датчик так и не работает на тележке;
2. Датчики линии стали замерять "что попало" .. сделали процедуру автозамера по принципу того видео. Тележка кружится над линией и сохраняет значения в EEPROM, а при старте читает оттуда. Вот в EEPROM сохраняется завышенное значение белого (и порога) примерно в 2 раза. Вывод на монитор показывает что при включенных моторах датчики замеряют какие-то отфонарные и завышенные значения.
3. При воткнутом USB кабеле приходится подавать питание от аккумуляторов тоже, иначе датчики выдают совсем низкие значения .. вроде как понятно. От USB на плате остается 4.3в .. мало для светодиодов. Но! При подключенном аккуме - он разряжается и значительно в этом режиме. Бред, защитный диод прозвонил - пашет.
В общем, сегодня творится нечто странное и не до покатушек. Прозвонил и перепроверил все соединения .. контакты есть, напруги тоже и все в норме: от аккумов на плате 5.01в, питание моторов 11.6в, на датчиках теже 5.01 .. фигня какая-то.
1. Arhat109-2, забудьте про ШИМ, оассуждайте в реальных физических единицах, а не в непонятных попугаях.
2. Не верю, что трудно увеличить период опроса. Постройте график максимально допустимой скорости от величины периода опроса именно для той трассы, на которой наблюдается эффект увеличения времени прохождения при увеличении скоростного лимита. Только скорость, ради Бога, в м/с, а не в мифических "единицах ШИМ".
3. Постоянную времеи "мотор-колесо" желательно не на глазок, а точно измерить. А также измерить постоянную времени всей тележки. При помощи трещотки, как здесь предлагалось, стробоскопа и т.п., но точно, а не на глаз.
Пока я не разберусь с тем что там в ней приключилось - ничего замерить ни на глаз никак, от слова "вовсе", ибо "не едет". Датчики кажут "чё попало" и наперебой. Узв. датчик вовсе не пашет и тележку "фиг поймаешь".
Починил. В общем, обнаружился внутренний обрыв в питающем проводе от плюса аккумов к расширительному шилду, плюсом косяки в программе из-за Ардублоковской самодеятельности и непропай кварца на датчике расстояний, а самое главное Ардублок кузяво глюкнул и добавлял свой кусок кода в измеритель датчиков .. подробнее дело было так:
1. начал проверять все цепи с питания, обнаружилось что периодически питание пропадает, стоит пошевелить провод. Проверил, зачистил контакты на разъеме - ваще пропало питание. Разобрал тележку, начал звонить (иначе не добраться) - нет плюса на разъеме. Выпаял, поменял провод с мелкого AWG30 на кусок провода от компьютерного БП. Умаялся. Провод толстый, а паяльник чахлый - ещё СССРовский 25вт .. еле запаял, кое как вставил в разъем .. питание появлось. Сборка, запуск .. та же лажа.
2. Полная проверка программы .. вроде все как надо, полез смотреть сгенеренный код в ИДЕ и обнаружил что у него теперь 3 переменных MAX_SPEED. и только одна установлена куда следует .. использованы все 3шт в разных местах, а также пин echo с узв. датчика устанавливается как .. OUTPUT .. полез смотреть что за фигня в Ардублок .. обнаружил что "глюки" с переменной, удалил все определения, использования и повтыкал заново - переменная стала единственная. А нога устанавливается на выход .. потому, что она же использована в процедуре раскрутки драйвера мотора L298N. А вот то, что она же используется на вход в процедуре замера расстояний - "пофиг", не учтено Арудблоком. Оказалось, что в процессе перестроек тележки, наш гений построил вторую процедуру управления моторами с драйвера L298N и, чтобы не переписывать прогу (Ардублок не позволяет переносить/копипастить куски из одного скетча в другой) он сделал вторую процедуру и "вызывающую", чтобы не изменять основной код - имитация виртуальных методов на статических вызовах .. сам допер .. вот, из-за этого, пин использовался в неиспользуемой процедуре, а из-за их нехватки, на него же посадили узв. датчик раз сейчас свободно .. поправил, не помогло. Пересадили echo на А0 - не помогло..
3. Внимательный осмотр узв. датчика .. проверка типового pulseIn() из ИДЕ .. работает но странно. Только если его "потрогать" и если подключены аккумы вместе с USB .. повторный осмотр, обнаружил что как-то странно качается кварц .. пропаял его и пропаял ещё раз среднюю микросхему, остальные вроде как нормальны .. заработало.
4. Проверка диода Нанки, блокирующего подачу напруги в USB разъем при включенных аккумах .. звонится в одну сторону и не звонится обратно. Типа "жив" .. под лупой обнаружилась мелкая ямка строго посередине диода .. как прожженая .. думал это надпись .. выпаял такой же из старой платы, впаял - напруга от USB внезапно стала не 3.8-4.3в (смотря с какого компа) а 4.6 ..
5. Проверка расширительного шилда .. он самопальный, на базе LM2596-ADJ .. кондер на +5в - вспух. Паял старый от какой-то материнки .. выпаял, заменил, подстроил напругу до 5.05в (на этом было 4.92) .. вроде работает. ХЗ как проверить лучше.
6. Сборка тележки ещё раз, контроль всех контактов, соединений .. проверка датчиков - гы, работают. Тележка "поехала", но с визгом ..
7. Разбор левого мотор-редуктора, щеточный узел мотора имеет существенный пропил он и визжит и искрит не-подетски. Зачистил, собрал .. все едет, все крутится, все замеряется.
8. Проверка его программы .. едем "куда попало" .. осмотр в Ардублоке .. "мин нет" .. осмотр в ИДЕ - внезапно среди операторов getSensors3() обнаруживаем кусок, изменяющий скорости моторов .. а .. эт-та чё? .. удаление процедуры полностью, написание её заново .. вроде "прошло". Где, откуда он это сюда прилепил .. фиг знает. Просматривать генеренный код в ИДЕ - ещё то удовольствие .. там уже за 1200 строк "навалом".
.. итого, после всех исправлений и восстановительных операций оно едет очень неплохо, вопрос можно пока закрыть.
Стробоскопа нет, трещотки тоже. Замедление loop() до 12мсек - практически ничего не меняет в характере движения тележки. Больше - начинает промахиваться невзирая на любые регулировки. Съемка на видео - тоже малоинформативна, поскольку 30 кадров в сек - однозначно мало.
Остался только один вопрос: сделанная автонастройка датчиков с покатушкой тележки почему-то пишет в EEPROM завышенное примерно вдвое значение уровня белого, соответственно датчики потом "плохо видят линию". Ручная подвижка тележки с той же самой измерительной процедурой - видит нормальные величины .. что это может быть? С другой стороны, не сильно актуально, поскольку есть подобранный константный массив с "правильными значениями" и он работает устойчиво. Просто хотелось сделать также как на видео: поставил насередину, тележка покрутилась и замерила уровни самостоятельно .. вот, "лажа" получается.
О, этот рыжий робототехник, вчера пришел с улицы, постоял в раздумьях у трассы и с мокрыми лапами прошел четко на перекресток и упал с видом совсем обессилившей животины .. и это при том, что робот его практически не видит и врезается в него регулярно .. шерсть - очень хорошая стелс-техноглогия от узв. датчиков, оказывается. Был конечно изгнан, но трассу пришлось таки мыть. :)
Не хочу быть капитаном Очевидность, но замечу. Ограничивает максимальную скорость на трасе, а не тупого полета без управление, сцепление колес с трасой. Так что бы все же и здесь отыграть, то надо перед запуском измерять и записывать в тетрадь силу сцепления с трасой. Колеса зафиксировать, что бы не крутились и мерять динамометром силу, при которой ваша машинка начинает скользить. А дальше или мыть трасу и колеса спиртом, или чем то еще и опять смотреть. Вплодь до того что бы покрывать колеса разбавленым резиновым или каким-то клеем. Делайте опыты, и может и на этом тоже чего-то отыграете.
ПС: Хотя может WADA вас за употребление "допинга" устранит, потому что первые места уже "куплены за ранее".
Одно это ограничение дает "теоретическое" время прохождения конкретно этой трассы в районе 7.5сек для наших ТТХ. Все что можно было вымерять динамометром - давно измерено и даже где-то тут опубликовано выше. :)
Одно это ограничение дает "теоретическое" время прохождения конкретно этой трассы в районе 7.5сек для наших ТТХ. Все что можно было вымерять динамометром - давно измерено и даже где-то тут опубликовано выше. :)
А вы хоть пользуетесь этим? А то померили, разобрали и... забили. Можно же и колесо шире поставить, меньше радиус и т.д.
На Формуле даже колеса меняют, что бы трасу пройти быстрее.
Не хочу быть капитаном Очевидность, но замечу. Ограничивает максимальную скорость на трасе, а не тупого полета без управление, сцепление колес с трасой. Так что бы все же и здесь отыграть, то надо перед запуском измерять и записывать в тетрадь силу сцепления с трасой. Колеса зафиксировать, что бы не крутились и мерять динамометром силу, при которой ваша машинка начинает скользить. А дальше или мыть трасу и колеса спиртом, или чем то еще и опять смотреть. Вплодь до того что бы покрывать колеса разбавленым резиновым или каким-то клеем. Делайте опыты, и может и на этом тоже чего-то отыграете.
ПС: Хотя может WADA вас за употребление "допинга" устранит, потому что первые места уже "куплены за ранее".
колёса мыть спиртом категорически нельзя, состав жидкости для промывки сдам только в личку под обязательства неразглашения ... но если спиртом уже мыли то их в урну
Мне это ни к чему. Просто там соревнования. На конкретной машинки и на конкретной трасе получается вполне конкретное значение сцепление. Вот его надо уметь точнее определить и перед забегом выставить в программе потому что: 1) если сделать меньше, то теряешь рекорд. 2) если больше, то уже машинка "слетает" с трека. Вот именно в этом и есть соревнование. Умение определить сцепление конкретной машинки на трассе и выставить ее в программе хотя бы внешним потенциометром, если скетч перешивать долго.
ПС: Может машинка вращением на месте это сцепление и измеряет.
О, это да .. послед забега трассу приходится протирать тряпочкой - остаются микрочастицы от резины колес как в Формуле-1, особенно на крутых виражах. Мешают. :)
В общем, оно поехало и одну пару резины мы похоже так и оставим "для тренировок". На соревнования поедет с "запасной резиной". По внимательному рассмотрению характера движения сделали 2 улучшения в программе и в ближайшее время видимо будем катать уже с "предсказателем поворотов". Скорости прохождения как на видео - у него ещё нет, но уже очень близко..
Настройку датчиков сделали так: если тележка по запуску стоит средним датчиком на линии, то читаем настройки из EEPROM, а если все датчики на "белом", то переходим в режим автонастройки с ручным движением датчиков по полю, после чего пишем результат в EEPROM .. работает на ура, но есть 1 недостаток: загрузку программы в тележку приходится делать ставя строго на линию .. иначе, пока компиляется, успевает уходить в режим автонастройки и пишет во флеш всякую чухню (что попалось под датчики)... не сразу доперло почему в EEPROM оказывается фигня. :)
п.б) - высокий профиль резины -- проявляется, но незначительно. Только в крутом развороте и при заходе на перекресток с вн. направления (там зигзаг). Куда больше влияет покачивание тележки из-за амортизации передних колес, особенно в переходных местах, где лампочки датчиков перемещаются. Из-за снижения скорости, хорошо видно как тележка "клюет" носом, причем со стороны внутреннего колеса и наклоняет блок датчиков. Но, тут похоже "неизбежность". Езда на жестких колесах (или скользящая передняя опора 1шт) плохо переносит балку - тележка резко подпрыгивает и теряет линию и, если балка оказалась под углом к курсу, то легко теряет линию насовсем - скользит колесами или опорой вдоль балки. С амортизацией такого нет даже близко - идет ровно, просто не замечая препятствия, только колеса подпрыгивают. На видео, похоже именно это и случилось с рекордсменом - там хорошо слышно "мы теперь вторые! он не прошел вторую квалификацию с балкой - упал" .. или как-то так.
п.в) - имеет место быть тоже, но пока некритично. Попытка моей перестройки программы под DECIMAL(1/1024) на базе long арифметики показывает что настроить тележку можно точней, но менять и разъяснять ребенку что и где ему надо будет исправлять - не стал, пусть так катается, терпимо вполне. Пока оно того не стоит...
п.г) куда как более сильное влияние оказалось от колес передней опоры. Перемещение их по длине тележки - очень сильно влияет на характер управления .. есть некий "оптимум" оказывается между осью вращения тележки, расположения Ц.Т., выноса датчиков от оси вращения и положения передней опоры, которую в поворотах можно принимать за "скользящую"... не всё так однозначно. :)
Я бы все-таки рассмотрел замену передних колес на опору. Правда ребенку такую опору сделать будет непросто. Если вкратце, то она должна иметь эффект пружинки, т.е. быть из нежесткого материала (в идеале из тонкой нержи), на той части опоры что соприкасается с поверхностью должен быть подшипник скольжения (фторопласт, тефлон), достаточно тонкий чтобы не создавать помех для преодоления препятствий. Надеюсь теперь более понятно объяснил какая должна быть опора. Ну и на вес тележки должна быть рассчитана так чтобы при "ударе" не согнулась в 0, иначе толку от нее уже не будет (иначе говоря должна быть и достаточно жесткой).
Нужно будет правильно рассчитать усилие входа на горку/карандаш. Если скорость в момент входа будет слишком мала, то пружинка-опора выкинет машину с трассы, если велика, то может появиться резонанс после прохождения препятствия.
только ведущие колеса меньше и тоньше и соответственно она чуть ниже, вынос датчиков больше и пока не установлена декорация (будет). Тут резина 81.6х38, а у нас стоит 62.4х20.
Менять на скользящую опору .. врядли. Наши опыты показывают, что с ней хуже.
Кстати, у этой трассы есть сильный косяк: на ряде мест от линии трассы до края - менее 10см! Что при разрешенном габарите 200х200 приводит к гарантированному падению "за стол" (бортиков нет) при скоростном прохождении прямых участков у стартовой линии или большого поворота, если тележка идет "не по середине" трассы. Проверено неоднократно, и из-за этого и отказались от широкой резины - колесо вылетает со стола "только так". Предельная устойчивая ширина - не более 175мм (у нас сейчас 165). На картинке - 195мм.
Тогда одеть капролоновые кольца. Можно сделать из 2-х половинок и склеить по месту. Просто у вас всместо 2-х пятен контакта получается их аж целых 4. Считать сложнее.
Да не .. там 2 пятна. Лего оно такое .. под весом детальки слегка прогибаются и колеса стоят немножко нараскоряку, опираясь только внутренним ободом на трассу. Зазор в действительности чуть больше миллиметра. И чем сильнее оно опирается в повороте - тем больше раскоряка. :)
Упс. Вчера открыл регламент, напосмотреть за изменения и внезапно читаю выделенное красным: "п.5. Запрещаются в конструкции робота любые детали Лего и моторы" .. на отборочных ещё было про только моторы .. отписался с вопросом организаторам - пока молчат.
Тем не менее, как понимаю, наша тележка "не проходит вовсе" и как уже отписывался в одной из тем, все печально: на соревнования по Лего мы - пролетаем потому что у нас Ардуино, на всякие Junior Skills - опять пролетаем потому что у нас "семейная команда" и последний шанс - Робофест, для нас тоже стал недоступен, потому что наше Ардуино .. как Лего.
Увы, но констатирую простой факт: в пылу конкурентной боьрбы за продажи и печеньки из госбюджета (не образовательная организация) дети, которые что-то мастерят своими руками выпали и остались никому не интересны. Увы.
В общем, попробуем все-таки поучаствовать, пересобрав тележку из "говна и палок" .. теперь нас интересует вопрос где и какие нормальные гоночные колеса на микропористой резине можно оперативно купить в г. Новосибирск, ибо заказать мы уже ничего не успеем.
Может кто-то что-то оперативно посоветовать? От размера этих колес надо будет строить мотор-редукторы и всю остальную тележку..
Пасибки, позвонюсь, но мне казалось что нужна микропористая резина, а не полиуретан.. насколько он хуже по к-ту трения? На леговской микропорке у нас к-т трения =0.68..0.8 в зависимости от протектора и чистоты колеса..
Полиуретаны могут быть изготовлены с коэффициентом трения от очень низкого, подобно втулкам, подшипникам или сменным вкладышам, до очень высокого, подобно шинам или валам.
Пасибки, позвонюсь, но мне казалось что нужна микропористая резина, а не полиуретан.. насколько он хуже по к-ту трения? На леговской микропорке у нас к-т трения =0.68..0.8 в зависимости от протектора и чистоты колеса..
натянуть кусок резиновой камеры и зашлифовать наждачкой, коэффициент сцепления будет однозначно выше 0,8
По сслыке, позвонился - не берут, отписался "сделать заказ" - тишина. Увы, к сожалению для нашего города ситуация типовая.
В общем ребенка согласился с дербаном его игрушек и сделал 2 шикарных колеса на 63х23, по вашему методу натянув на колеса от его р/у трактора (лежит заброшенный давным-давно, жаль .. больше не поедет) порезанную шину от его же р/у модели (когда-то брал за 2500, не работает давно уже) на микропорке вместо резины от камеры. Спасибо за идею. Покрасил диск акриловым металиком "под бронзу" - получилось очень кузяво. Можно сделать ещё пару на 66х23..
Теперь мотор-редукторы .. наши, обклеенные лего-деталями как понимаю тоже могут забраковать запросто.
Скоростное изготовление новой тележки перенесу в свою тему. Далее - уже там, и фотки и описания..
для очень высоких скоростей моделей авто ширину шин делали как можно мешьше, если не изменяет память миллиметров 5-6, но это не из моих детских увлечений, я ракеты строил и судомодели )))
Я тоже. Ещё самолет. Даже целых 2. А судомодели - долгое хобби": "Драккар" (строился серийно, сколько раз уж и не помню .. делал как подарки к днюхам), "Золотая Лань" (М1:100 сильно упрощенно утопла из-за течи в днище), "82м, 100-пушечный линкор Королева Екатерина (Голландия)" - (М1:100 полный такелаж, рангоут, 4кг свинцового балласта, ходовая модель, без пушек - расстреляна из спичек под звуки похоронного марша в 1978г); "64-х пушечный фрегат Ингерманланд" - (М1:100, остался недостроен, тоже планировалась ходовая модель с пушками. Один 32-фунтовый Единорог даже рассверливал и отсреливал: насквозь 5мм фанеру до 5метров! Выдержал 20 выстрелов; "Петр Первый" - ховодая модель М1:100 .. остальное уже не помню. Какую-то ходовую модельку типа "газнейский когг" делал и вовсе исключительно из спичек .. шпангоуты, корпус, клееные мачты, реи .. :)
Пасибки, позвонюсь, но мне казалось что нужна микропористая резина, а не полиуретан.. насколько он хуже по к-ту трения? На леговской микропорке у нас к-т трения =0.68..0.8 в зависимости от протектора и чистоты колеса..
натянуть кусок резиновой камеры и зашлифовать наждачкой, коэффициент сцепления будет однозначно выше 0,8
На колесах по две полоски от велосипедной камеры сцепление супер .
Кстати, насчет колес - лучшие колеса оказались из мягкого силикона, на робофесте в третий день гоняли на колесах от Робо-Робо, показали неплохой результат для новичков. микропора оказалась более жесткой. Ещё есть вариант ставить "липкую" резину - на тестах, пока у нас не появились колеса с силиконом, просто обматывали двусторонним плотым скотчем - работает на ура. единственно - слишком быстро грязь налипает, теряется эффект сцепления.
Как только возникает поворот под прямым углом - теряется. На трассе шорт-трека шел уверенно, выдавая неплохой результат, более сложная трасса
И правильно, что теряется. угол то прямой. Перед прямым углом надо подтормаживать, а то и переходить на самый медленый. И наконец если робот "потерялся", то "должен вращаться" на месте что бы "найтись" и при этом не "найти путь обратно".
ПС: Если вам надо улучшать сцепление, то сапожный клей (клей 88) самое то. Но это куча эксперементов, как мазать и какой толщины слой и за сколько до соревнований это делать. А скорее всего наносить клей паролоновыми валиками на колеса.
О, узнаю ребячий Ардублок .. тем не менее, недостатки по вашему коду:
1. Строки 45,46,47 читают датчики однократно и их 3шт. Независимо от качества датчиков, ещё есть "контакты" о которых учит сложная наука "электроника": "Электроника - наука о контактах, точне об их отсутствии" :) Нет никакой гарантии, что датчик не "сглючит" и это не выдаст кривой управляющий сигнал, пусть даже "однократно"... вывод: датчики полезно замерять по 2-3-4 раза и усреднять показания. Удобно воспользоваться циклом.
2. Пороговые уровни 500, 800 .. заданы константами. На разных трассах они могут быть сильно разными. Это та причина (а не то что все там думали), почему робот вообще мало у кого поехал. Трасса может быть "матовой", а может быть "глянцевой" .. и отражение даже при собственном освещении светодиодами, даже при "отстройке" от фоновой засветки, даже при работе в ИК диапазоне .. может отличаться значительно. У Вас это никак не учтено.
Для решения, делают "калибровку" датчиков ручную (как было у большинства кто "поехал") или автоподстройку (как было у уральцеев) и запоминают наименьшие и наибольшие показания датчиков и уже из них выводят "порог среднего". Особенно важно для датчиков на фототранзисторах, поскольку они хорошо засвечиваются обычным светом (зависят от внешнего освещения)..
3. Весь код readPosition() рассчитан в предположении что все(!) ваши датчики абсолютно одинаковы. Это не так даже при промышленном производстве, не говоря уже о РАЗНОЙ засветке трассы на разных её участках и при разной скорости движения .. Так можно делать ТОЛЬКО после приведения показания датчика к некоему "среднему" или обощенному варианту. Например, левый датчик работает в диапазоне 300-700, а правый в диапазоне 110-690 .. казалось бы отличие невелико, но оно будет вносит постоянную ошибку в ваши расчеты движения прямо.
4. Функция map() использует вещественную арифметику и делает НЕСКОЛЬКО умножений и делений .. рекомендую посмотреть её код. Напомню, что Ардуино UNO, Nano, Pro Mini, Mega2560 не имеют команд для прямой работы с такими числами. Все это делается типовой библиотекой и 1 операция занимает около 2 миллисекунд.
Для скоростного прохождения трассы Робофеста (10сек. и менее) требуется средняя скорость движения около 1 м/сек, ибо длина трассы около 10метров. Трасса Робофиниста больше - около 14 метров и сложнее. А поскольку движения в поворотах значительно больше чем по прямой, то эту цифру надо как миниум удвоить до 2 м/сек.А если учесть что внешнее колесо должно крутиться в 1.5 раза быстрее внутреннего, то и до 2.5-3м/сек.
Отсюда: за 1 мсек ваш робот должен проезжать около 3мм трассы. И простой расчет показывает что вызов 2 раза map() приведет к слепому проезду 6-12 сантиметров трассы. Какие уж тут повороты под 90 градусов? :) Собственно это - вторая причина почему на Робофесте-2017 из ардуинщиков мало кто поехал. Все кинулись использовать ПИД-регулятор с типовой .. вещественной библиотекой. Приехали. Это та причина, почему у нас НЕ использовался ПИД вовсе, и вообще всё управление делалось на "табличном конечном автомате". Самый быстрый способ управления для 8/16 разрядных МК. Не надо ничего "считать" вовсе. :)
Но, раз Вы пишете за 3-й день соревнований, то стало быть или это "Траектория" (старшая группа - зачем Вам тогда Ардублок?) или "Лего", в котором "все несколько иначе"...
Использование полноценного ПИД и вообще вещественной арифметики возможно только на "ардуино-совместимых" 32-х разрядных МК, имеющих под собой встроенную поддержку вещественных вычислений "за 1 такт" .. Teensy, STM32F4xx и даже STM32F103 уже не проходит по параметру "производительность" ни разу. Но, я считаю что такое использование "совместимых" плат есть ПРЯМОЕ нарушение Регламента соревнования.. и в таких случаях надо подавать протесты.. или требовать явного указания в Регламентах о допустимости "совместимых" плат. Слишком большая разница .. разные весовые категории и сильно.
В общем, если у Вас Ардуино в классическом исполнении - забудьте про map() и прочие "вещественные" вычисления.
P.S. Я сейчас пишу некое "руководство" для конструкторов в возрасте 9-11 лет по САМОСТОЯТЕЛЬНОМУ изготовлению скоростного робота по линии .. но это займет некоторое время и к апрельскому Робофинисту, я конечно же не успею.. планировал выкладку в учебных материалах на сайтах Робофеста и Робофиниста .. но пока не вижу тех, кому это полезно (отзывов на запрос нужна ли такая публикация - пока не увидел)
Спасибо за совет, но как-то слабо представляю себе КАК им воспользоваться (без шуток, это - не сарказм).
То, что Вы предлагаете, давным-давно сделано в программе на Экселе .. введены все формулы, работают в СГС или СИ (где как удобно) .. так, скажем что трение переднего колеса в повороте получено в 67гр., а трение качения всей тележки в 33гр. и?
В конечном итоге, у него программа оперирует .. увы, "попугаями" АЦП и величиной управляющего ШИМ .. и больше ничем. Причем, варианты кода я выкладывал в своей теме "Ардуино как Лего" совсем не давно.
В чем конкретно заключается ваш совет?
P.S. "трение переднего колеса в повороте" - следует читать как "... приведенное к ведущему внешнему колесу"
P.P.S. Не согласен, что "приводят к неверным результатам", хотя бы на таком примере:
Есть простой расчет движения по заданному радиусу: имеем радиус и ширину колеи ведущих колес. Соответственно, внешнее колесо должно крутиться быстрее внутреннего на соотношение радиусов, по которым они движутся. Их вычисление - тривиально: плюс-минус полуколея.
Но, для скоростного движения этого явно недостаточно, поскольку есть эффект "переноса веса" на внешнее колесо из-за центробежной силы. Перенос веса тоже можно вычислить как зависимость от высоты Ц.Т. и той же колеи и величины самой центробежной силы, которая зависит квадратично от скорости движения по радиусу. А поскольку скорость вращения DC-мотора линейно падает от приложенной нагрузки, то можем учесть и этот "эффект", раскручивая внешнее колесо соответственно "шустрее".
Но, для скользящего переднего колеса опять возникает доп. сила, которая нагружает внешнее колесо .. считаем. В результате получаем соотношение скоростей вращения колес .. зная "вес 1 ШИМ" переводим его в соотношение подаваемого ШИМ на внутреннее и внешнее колесо.
.. как итог, едем по заданному радиусу достаточно точно. И один круг и два и хоть 100500 (может ехать часами). Проверено. А самое забавное, то что как только (позавчера конкретно) пересчитал трение переднего колеса, мои рекомендации к табличным радиусам .. совпали с подобранными ребенком значениями во время второй тренировки на отборочном соревновании до 1..3 /128. :)
(после соревнования осмотр программы и настроек: -"Ты зачем так ужал пропорциональные к-ты?" -"А так получилось. Твои значения не поехали, мои - лучше")
Это как пояснение, где применяется "вес 1 ШИМ". В чем "неверное предположение"?
Ну и ещё: оно же "едет"! Да, но только до определенной предельной скорости... то есть, как понимаю, проблема не в неверном подходе "вес 1ШИМ", а в каком-то "неучтенном факторе", который до этого порога - незначителен. Э-э-э .. сопротивление воздуха?!? (-"от неё реально ветер идет!" (с) сын .. уже не знаю на что думать)
.. в общем, пока взяли таймаут на подумать .. тем более что протектор этой пары колес уже изрядно поизношен. С трассы после каждой покатушки приходится снимать мелкую пыль из остатков резины.
Объясните два описанных Вами эффета:
1. Почему расчеты "идут лесом".
2. Почему результаты второго круга отличаются от результатов первого.
Я могу ответить: потому, что Вы считаете, будто величина ШИМ и скорость пропорциональны друг другу с каким-то коэффициентом.
Ваш вариант?
И еще один вопрос: почему Вы считаете, что ШИМ пропорционален именно скорости, а не ускорению? Или для Ваших расчетов это несущественно?
В конечном итоге, у него программа оперирует .. увы, "попугаями" АЦП и величиной управляющего ШИМ .. и больше ничем.
Вспоминается старый анекдот про пьяного, который ищет часы не там, где потерял, а под фонарем - где светлее.
Это очень похоже на Ваши аргументы: ведь все равно оперировать ШИМ. Но проблема в том, что - да, там, где светлее, часы найти принципиально невозможно. Просто потому, что их там нет. Хотя искать - приятнее. Вот точно так же, и с пропорциональностью ШИМ и скорости - да, так считать проще, но добиться успеха невозможно, т.к. это неверно.
Т.е Вы выбрали весь диапазон того, что можно было сделать без знания физики. Но хотите идти дальше. А дальше без этих знаний не получается, метод тыка дельше не работает. Точнее, тыкаясь вслепую, теоретически можно что-то насчупать, но во-первых, это требует очень большого количества попыток, но, самое главное, реальные измерения имеют довольно высокую шумовую составляющую, из-за которой очень трудно уловить тенденции.
И вот здесь могла бы помочь физика. Но мешает то, что Вы ее явно не знаете и подменяете физические законы несуществующими закономерностями.
Вот вопрос первый: ШИМ - это скорость или ускорение?
Ответ: ни то, и не другое.
Рассмотрим для начала электродвигатель, питаемый постоянным напряжением. Это проще, чем ШИМ.
Напряжение на двигателе в первом приближении можно считать суммой ЭДС индукции и падения напряжения на активном сопротивлении якоря. ЭДС индукции пропорциональна скорости вращения. А падение напряжения - току. Ток в свою очередь пропорционален моменту. Другими словами, напряжение пропорционально сумме скорости и ускорения с некоторыми коэффициентами. В некоторых случаях большее влияние оказывает скорость (предел - холостой ход), в некоторых - ускорение (предел - старт с места при нулевой скорости).
Другими словами, подав на двигатель некоторое напряжение, мы ничего не можем сказать ни о скорости, ни об ускорении, если не знаем всю предысторию. Если знаем - можем проинтегрировать и получить результат. Очевидно, с некоторой погрешность. Очевидно, погрешность при интегрировании будет накапливаться со временем. Отсюда выворд: чтобы хоть как-то прогнозировать движения, нам не хватает данных - нужен какой-то еще источник информации. Напримеро, энкодеры на колеса, чтобы мы могли получать не прогнозируемую с погрешностью, а реальную скорость. И из нее и приложенного напряжения - реальное ускорение. И тогда уже можно будет сделать реальный прогноз - уйдет колесо в занос или нет. А не пытаться оценить это исходя из "предельной" величины ШИМ, выявленной при совершенно других условиях с другим соотношением между скоростью и ускорением.
Далее.
Выше мы предположили, что мотор питается постоянным напряжением. У нас он (пока) питается пульсирующим напряжением от ШИМ. И здесь все не так просто: никакой пропрорциональности между средним значением напряжения (читай - величиной ШИМ) не наблюдается. Причина, как я думаю (я могу и ошибатьсся, но именно на такие выводы навели меня результаты обмера электродвигателя, питаемого ШИМ), в том, что часть времени якорь не обесточивается, а работает в режиме торможения (в которкозамкнутом режиме). Из-за этого происходит сразу две неприятные вещи:
- теряется линейность между ШИМ и "эффективным" постоянным напряжением,
- снижается КПД всей системы.
Поэтому я бы пордумал над тем, чтобы все-таки питать колеса от регулируемого постоянного напряжения, т.е. от импульсного регулируемого источника, на выходе которого уже не прямоугольник изменяемой скважности, а регулируемое постоянное напряжение.
Пасибки за развернутый пост.
В эту сторону я тоже уже рассуждал, но примененный нами мосфетный драйвер моторов (отдельная большая тема в проектах) не имеет режима рекурперативного торможения короткозамкнутым ротором, как понимаю и как вижу на практике. Режим отключенного ШИМ у него тупо разрывает цепь якоря и только: оба нижних мосфета просто переводятся в закрытое состояние и мотор предоставляется "сам себе" на выбег. То есть мотор или получает питание или просто разорвана цепь якоря и на конденсаторе якоря растет напряжение в генераторном режиме. Из-за этого эффекта ШИМ - все-таки "примерная скорость" мотора, но да, только примерная и очень грубая. Тут - согласен. Драйвер L298N - да, при определенном управлении имеет описанный вами эффект периодического КЗ якоря, но его тоже можно использовать в режиме свободного выбега при управлении ШИМом.
Отсюда, подача заданного ШИМ на драйвер приводит со временем к установке одной и той же скорости моторов и достаточно быстро, что мы и наблюдаем на практике. Но, в целом, вычислить какая это будет скорость - на практике малополезно, ибо да, скорость DC-мотора есть следствие поданного напряжения И мех. нагрузки на ротор. Последняя меняется в зависимости от динамики движения. Какие-то эффекты этой динамики мы уже учли, а какие-то ещё нет.
Кроме этого, мне кажется что "предел скорости" у нас связан с подходом к реализации алгоритма - табличное (и достаточно грубое) приближение управляющего воздействия и имитация вещественных чисел дробями по 1/128. Видимо далее этого подхода уже недостаточно.
Ну не могу я объяснить иначе наблюдаемые эффекты: до определенного ограничения максимальной путевой скорости - робот едет очень стабильно и может кататься так непрерывно и очень долго .. "часами", а при превышении этого порога начинается болтанка по линии и она тем больше, чем больше это превышение и "задавить" подбором/перерасчетом настроек табличного управления .. не получается. Идет перекос то в одну, то в другую сторону: или мы тупо теряем трассу и едем в какой-то момент "прямо" не успевая зарулить или наблюдаем сильную "перерегулировку", которая эффективно снижает путевую скорость до .. значений ниже чем "допороговая" скорость движения. Скажем так, макс. скорость "до" порога - время прохождения трассы 11сек., а при макс. скорости выше порога - "вылеты" или прохождение трассы .. 12сек. То есть пропадает весь полезный эффект от повышения из-за "болтанки".
Пока вижу несколько эффектов: а) сопротивление воздуха (маловероятно, но все же); б) высокопрофильная шина (поперечный изгиб резины в повороте - искажение показаний датчиков из-за доп. отклонений); в) недостаток точности вычислений; г) высокая частота дискретизации обработки в 4мсек на управляющий цикл.
п. "б" детальнее: Используемые колеса Лего 62.4х20 имеют резину высотой профиля 13мм и попытки поболтать тележку на колесах показывают что при резкой смене направления движения, изгиб профиля запросто может приводить к ложному срабатыванию датчика .. надо проводить испытания. К сожалению, есть низкопрофильные колеса, но они малого диаметра и наш мотор-редуктор на них не сможет достигнуть требуемой путевой скорости даже наполовину.
И еще один вопрос: почему Вы считаете, что ШИМ пропорционален именно скорости, а не ускорению? Или для Ваших расчетов это несущественно?
а, чем вообще в его балалайке измеряется скорость движения относительно трассы?
*нет скорости - нет ускорения, есть некий эмпирический бред.
Секундомером, вручную. :) Нет энкодеров и их установка не запланирована - некуда.
Секундомером, вручную. :) Нет энкодеров и их установка не запланирована - некуда.
я о скорости движения телеги относительно трассы спрашивал, а не о скорости вращения колёс - нужно и то и другое, т.к. телега должна адекватно реагировать на отрыв колеса от трассы.
*по сути, если ты не планируешь ставить датчики, то что, вообще, тут обсуждается?
В эту сторону я тоже уже рассуждал, но примененный нами мосфетный драйвер моторов (отдельная большая тема в проектах) не имеет режима рекурперативного торможения короткозамкнутым ротором, как понимаю и как вижу на практике. Режим отключенного ШИМ у него тупо разрывает цепь якоря и только: оба нижних мосфета просто переводятся в закрытое состояние и мотор предоставляется "сам себе" на выбег. То есть мотор или получает питание или просто разорвана цепь якоря и на конденсаторе якоря растет напряжение в генераторном режиме. Из-за этого эффекта ШИМ - все-таки "примерная скорость" мотора, но да, только примерная и очень грубая. Тут - согласен. Драйвер L298N - да, при определенном управлении имеет описанный вами эффект периодического КЗ якоря, но его тоже можно использовать в режиме свободного выбега при управлении ШИМом.
Эта?
Сборка AO4606 на схеме изображена не совсем верно, т.к. в ней помимо полевиков присутствуют встречно параллельно включенные диоды. Которые, кстати, в подобных схемах играют существенную роль и ставятся, если отсутствуют в приборе изначально:
А теперь вопросы:
1. Зачем там нужны диоды?
2. Идет ли через них когда-нибудь ток?
3. Если идет - когда?
Отсюда, подача заданного ШИМ на драйвер приводит со временем к установке одной и той же скорости моторов и достаточно быстро, что мы и наблюдаем на практике.
Давайте оперировать не расплывчатыми понятиями, а конкретными цифрами: "достаточно быстро" - это сколько (постоянная времени в мс)?
Но, в целом, вычислить какая это будет скорость - на практике малополезно,
Но то есть мы уперлись в то, что не знаем, куда дальше копать, но заранее отвергаем как заведомо малополезное то, что нам не хочется (или считаем, что слишком сложно) использовать? Опять очень напоминает пьяного у фонаря.
ибо да, скорость DC-мотора есть следствие поданного напряжения И мех. нагрузки на ротор. Последняя меняется в зависимости от динамики движения. Какие-то эффекты этой динамики мы уже учли, а какие-то ещё нет.
Надо не учитывать отдельные моменты (т.е. не вносить поправки), а изначально аккуратно прописать физику. Тогда и необходимость, чтобы дополнительно что-то учитывать, отпадет.
А проблема в том, что через напряжение на якоре скорость и ускорение связаны между собой. И, не зная скорости, мы никак не сможем вычислить, какое напряжение нам надо подать на якорь для обеспечения определенного ускорения.
Кроме этого, мне кажется что "предел скорости" у нас связан с подходом к реализации алгоритма - табличное (и достаточно грубое) приближение управляющего воздействия и имитация вещественных чисел дробями по 1/128. Видимо далее этого подхода уже недостаточно.
Рано говорить о точности реализации, когда мы еще не сумели найти те зависимости, которые надо реализовывать.
Ну не могу я объяснить иначе наблюдаемые эффекты: до определенного ограничения максимальной путевой скорости - робот едет очень стабильно и может кататься так непрерывно и очень долго .. "часами", а при превышении этого порога начинается болтанка по линии и она тем больше, чем больше это превышение и "задавить" подбором/перерасчетом настроек табличного управления .. не получается. Идет перекос то в одну, то в другую сторону: или мы тупо теряем трассу и едем в какой-то момент "прямо" не успевая зарулить или наблюдаем сильную "перерегулировку", которая эффективно снижает путевую скорость до .. значений ниже чем "допороговая" скорость движения. Скажем так, макс. скорость "до" порога - время прохождения трассы 11сек., а при макс. скорости выше порога - "вылеты" или прохождение трассы .. 12сек. То есть пропадает весь полезный эффект от повышения из-за "болтанки".
Внешне напрашивается такая аналогия с радиоэлектроникой: при увеличении коэффициента устииления усилителя (коэффициент без ООС), охваченного ООС, увеличивается глубина этой самой ООС, что на некотором этапе ведет к неустойчивости и самовозбуждению. Выход - применение более скоростного усилителя.
Собственно, я уже спрашивал о конкретной величине постоянных времени механических узлов. Хотелось бы сравнить эти цифры с пеиодом опроса датчиков и периодом применения управляющего воздействия. Можеи, на предельных скоростях мы уже подходим к пределу Котельникова-Шеннона?
Пока вижу несколько эффектов: а) сопротивление воздуха (маловероятно, но все же); б) высокопрофильная шина (поперечный изгиб резины в повороте - искажение показаний датчиков из-за доп. отклонений); в) недостаток точности вычислений; г) высокая частота дискретизации обработки в 4мсек на управляющий цикл.
а) маловероятно. Для автомобиля это начинает проявляться где-то порядка с 10 м/с. Понятно, что у робота аэродинамика хуже, но учитывая, что сопротивление воздуха пропорционально квадрату скорости, при вчетверо худшей аэродинамике все равно получим не менее 5 м/с.
б,в) возможно. Хорошо бы это промоделировать.
г) может, наоборот, слишком низкая? Если проблемы получаются при увеличении скорости, порвое подозрение - "не успевает", т.е. постоянная времени обраной связи больше, чем необходимо для обеспечения устойчивости.
Кстати, я бы покопал именно в этом, последнем, направлении.
Если нет возможности быстро увеличить частоту опроса/реагирования, может попробовать, наоборот, ее уменьшить. Тогда, если последствием такого изменения будет пропорциональное уменьшение предельной скорости, источник проблемы таким образом будет найден.
Ок, отпишусь по результатам. Ребенок сегодня занят домашним заданием .. проболел неделю теперь сидит догоняет, завтра в школу.
С частотой дискретизации "не всё так просто". Дело в том, что используется Ардублок, который не имеет даже некоторых возможностей wiring, а именно, его pulseINn() не имеет управления таймаутом и мне пришлось собирать свой измеритель расстояний на этих "блоках". Замер делается по 2мсек, каждые 40мсек (устранение дальнего эха) и для выравнивания циклов в промежутках стоит пауза в эти самые 2мсек. Далее, analogRead() читает только по 5 замеров в мсек .. у нас 5 датчиков - вот вам ещё 1 мсек. Все вычисления делаются конечно же очень быстро примерно за 150мксек, но от этого не легче ни разу. А главное в том, что ШИМ - типовой на 490гц, и соответственно ускорять цикл выше 2мсек - нет никакого смысла - не будет ШИМ управления. И так всего 2 периода ШИМ на 1 управляющее воздействие.
Первое что надо - поднимать частоту ШИМ, но этого Ардублок снова не умеет ни разу. Второе - переводить опросы датчиков на прерывания .. аналогично. Все это у меня есть в моей библиотеке, но хочется чтобы ребенок выступал со своей программой всеж-таки, а не "супер-ассемблерной" на базе RTOS. (Очень невыгодно смотрелся его конкурент на отборочных, отвечая на вопрос судьи "Сам делал?", да и мнение сына: -"А я знаю чего он так разнервничался. Он там что-то испортил, я видел и слышал(соседние столы) как он говорил "не знаю нафига это .. пусть будет столько .. блин, я не помню сколько тут было, как теперь поправить?..", помнишь как хорошо он у него ехал на первой тренировке и как метался на второй? - как-то не хочется, чтобы он на тренировке точно также "сел в лужу")
Диоды там конечно же есть. Они нужны для гашения выбросов напряжения от самоиндукции якоря .. как-то не рассматривал их как режим "рекурперативного торможения короткозамкнутым якорем", поизучаю .. но, на практике хорошо видна разница между КЗ-торможением и простым выбегом - её и наблюдаю в реальности.
Инерция мотор-колесо это примерно 10-15мсек на изменение движения, в то время как управляющие воздействия идут каждые 4мсек.
"малополезно" - в смысле "недостаточно точно". При описанном ранее движении по радиусу можно получить точность плюс-минус пара сантиметров от заданного радиуса. Получить точнее - нет. Управляя величиной ШИМ и зная "вес 1ШИМ" можно выставлять скорость движения по прямой тоже плюс-минус 2-5см/сек, не точнее. Собственно этот параметр мною использован не столько для вычисления с какой скоростью идет тележка по трассе, сколько для предварительного рассчета с как быстро и насколько можно изменять ШИМ на моторах, чтобы не потерять сцепление с трассой (макс. величина изменения ШИМ за 1 цикл).
В последнем направлении копали уже достаточно давно - перед пред. городскими соревнованиями. Вполне безболезненно можно увеличивать период цикла loop() вплоть до 8мсек .. мало что меняется. Но там скорости были пониже и трасса существенно проще - по сути всего 2 радиуса в 30 и 60см. Под них и подстраивались. Тут трасса рисована "вручную" и нет двух одинаковых поворотов .. они только с виду одинаковые.
Секундомером, вручную. :) Нет энкодеров и их установка не запланирована - некуда.
Ставьте трещотку, пишите звук.
Похоже пока накатались. С тележкой творится нечто странное, причину найти пока не можем:
1. Узв. датчик так и не работает на тележке;
2. Датчики линии стали замерять "что попало" .. сделали процедуру автозамера по принципу того видео. Тележка кружится над линией и сохраняет значения в EEPROM, а при старте читает оттуда. Вот в EEPROM сохраняется завышенное значение белого (и порога) примерно в 2 раза. Вывод на монитор показывает что при включенных моторах датчики замеряют какие-то отфонарные и завышенные значения.
3. При воткнутом USB кабеле приходится подавать питание от аккумуляторов тоже, иначе датчики выдают совсем низкие значения .. вроде как понятно. От USB на плате остается 4.3в .. мало для светодиодов. Но! При подключенном аккуме - он разряжается и значительно в этом режиме. Бред, защитный диод прозвонил - пашет.
В общем, сегодня творится нечто странное и не до покатушек. Прозвонил и перепроверил все соединения .. контакты есть, напруги тоже и все в норме: от аккумов на плате 5.01в, питание моторов 11.6в, на датчиках теже 5.01 .. фигня какая-то.
1. Arhat109-2, забудьте про ШИМ, оассуждайте в реальных физических единицах, а не в непонятных попугаях.
2. Не верю, что трудно увеличить период опроса. Постройте график максимально допустимой скорости от величины периода опроса именно для той трассы, на которой наблюдается эффект увеличения времени прохождения при увеличении скоростного лимита. Только скорость, ради Бога, в м/с, а не в мифических "единицах ШИМ".
3. Постоянную времеи "мотор-колесо" желательно не на глазок, а точно измерить. А также измерить постоянную времени всей тележки. При помощи трещотки, как здесь предлагалось, стробоскопа и т.п., но точно, а не на глаз.
Пока я не разберусь с тем что там в ней приключилось - ничего замерить ни на глаз никак, от слова "вовсе", ибо "не едет". Датчики кажут "чё попало" и наперебой. Узв. датчик вовсе не пашет и тележку "фиг поймаешь".
Похоже пока накатались. С тележкой творится нечто странное, причину найти пока не можем:
Подозревается рыжий электростатический проводагрыз.
Починил. В общем, обнаружился внутренний обрыв в питающем проводе от плюса аккумов к расширительному шилду, плюсом косяки в программе из-за Ардублоковской самодеятельности и непропай кварца на датчике расстояний, а самое главное Ардублок кузяво глюкнул и добавлял свой кусок кода в измеритель датчиков .. подробнее дело было так:
1. начал проверять все цепи с питания, обнаружилось что периодически питание пропадает, стоит пошевелить провод. Проверил, зачистил контакты на разъеме - ваще пропало питание. Разобрал тележку, начал звонить (иначе не добраться) - нет плюса на разъеме. Выпаял, поменял провод с мелкого AWG30 на кусок провода от компьютерного БП. Умаялся. Провод толстый, а паяльник чахлый - ещё СССРовский 25вт .. еле запаял, кое как вставил в разъем .. питание появлось. Сборка, запуск .. та же лажа.
2. Полная проверка программы .. вроде все как надо, полез смотреть сгенеренный код в ИДЕ и обнаружил что у него теперь 3 переменных MAX_SPEED. и только одна установлена куда следует .. использованы все 3шт в разных местах, а также пин echo с узв. датчика устанавливается как .. OUTPUT .. полез смотреть что за фигня в Ардублок .. обнаружил что "глюки" с переменной, удалил все определения, использования и повтыкал заново - переменная стала единственная. А нога устанавливается на выход .. потому, что она же использована в процедуре раскрутки драйвера мотора L298N. А вот то, что она же используется на вход в процедуре замера расстояний - "пофиг", не учтено Арудблоком. Оказалось, что в процессе перестроек тележки, наш гений построил вторую процедуру управления моторами с драйвера L298N и, чтобы не переписывать прогу (Ардублок не позволяет переносить/копипастить куски из одного скетча в другой) он сделал вторую процедуру и "вызывающую", чтобы не изменять основной код - имитация виртуальных методов на статических вызовах .. сам допер .. вот, из-за этого, пин использовался в неиспользуемой процедуре, а из-за их нехватки, на него же посадили узв. датчик раз сейчас свободно .. поправил, не помогло. Пересадили echo на А0 - не помогло..
3. Внимательный осмотр узв. датчика .. проверка типового pulseIn() из ИДЕ .. работает но странно. Только если его "потрогать" и если подключены аккумы вместе с USB .. повторный осмотр, обнаружил что как-то странно качается кварц .. пропаял его и пропаял ещё раз среднюю микросхему, остальные вроде как нормальны .. заработало.
4. Проверка диода Нанки, блокирующего подачу напруги в USB разъем при включенных аккумах .. звонится в одну сторону и не звонится обратно. Типа "жив" .. под лупой обнаружилась мелкая ямка строго посередине диода .. как прожженая .. думал это надпись .. выпаял такой же из старой платы, впаял - напруга от USB внезапно стала не 3.8-4.3в (смотря с какого компа) а 4.6 ..
5. Проверка расширительного шилда .. он самопальный, на базе LM2596-ADJ .. кондер на +5в - вспух. Паял старый от какой-то материнки .. выпаял, заменил, подстроил напругу до 5.05в (на этом было 4.92) .. вроде работает. ХЗ как проверить лучше.
6. Сборка тележки ещё раз, контроль всех контактов, соединений .. проверка датчиков - гы, работают. Тележка "поехала", но с визгом ..
7. Разбор левого мотор-редуктора, щеточный узел мотора имеет существенный пропил он и визжит и искрит не-подетски. Зачистил, собрал .. все едет, все крутится, все замеряется.
8. Проверка его программы .. едем "куда попало" .. осмотр в Ардублоке .. "мин нет" .. осмотр в ИДЕ - внезапно среди операторов getSensors3() обнаруживаем кусок, изменяющий скорости моторов .. а .. эт-та чё? .. удаление процедуры полностью, написание её заново .. вроде "прошло". Где, откуда он это сюда прилепил .. фиг знает. Просматривать генеренный код в ИДЕ - ещё то удовольствие .. там уже за 1200 строк "навалом".
.. итого, после всех исправлений и восстановительных операций оно едет очень неплохо, вопрос можно пока закрыть.
Стробоскопа нет, трещотки тоже. Замедление loop() до 12мсек - практически ничего не меняет в характере движения тележки. Больше - начинает промахиваться невзирая на любые регулировки. Съемка на видео - тоже малоинформативна, поскольку 30 кадров в сек - однозначно мало.
Остался только один вопрос: сделанная автонастройка датчиков с покатушкой тележки почему-то пишет в EEPROM завышенное примерно вдвое значение уровня белого, соответственно датчики потом "плохо видят линию". Ручная подвижка тележки с той же самой измерительной процедурой - видит нормальные величины .. что это может быть? С другой стороны, не сильно актуально, поскольку есть подобранный константный массив с "правильными значениями" и он работает устойчиво. Просто хотелось сделать также как на видео: поставил насередину, тележка покрутилась и замерила уровни самостоятельно .. вот, "лажа" получается.
О, этот рыжий робототехник, вчера пришел с улицы, постоял в раздумьях у трассы и с мокрыми лапами прошел четко на перекресток и упал с видом совсем обессилившей животины .. и это при том, что робот его практически не видит и врезается в него регулярно .. шерсть - очень хорошая стелс-техноглогия от узв. датчиков, оказывается. Был конечно изгнан, но трассу пришлось таки мыть. :)
Не хочу быть капитаном Очевидность, но замечу. Ограничивает максимальную скорость на трасе, а не тупого полета без управление, сцепление колес с трасой. Так что бы все же и здесь отыграть, то надо перед запуском измерять и записывать в тетрадь силу сцепления с трасой. Колеса зафиксировать, что бы не крутились и мерять динамометром силу, при которой ваша машинка начинает скользить. А дальше или мыть трасу и колеса спиртом, или чем то еще и опять смотреть. Вплодь до того что бы покрывать колеса разбавленым резиновым или каким-то клеем. Делайте опыты, и может и на этом тоже чего-то отыграете.
ПС: Хотя может WADA вас за употребление "допинга" устранит, потому что первые места уже "куплены за ранее".
Одно это ограничение дает "теоретическое" время прохождения конкретно этой трассы в районе 7.5сек для наших ТТХ. Все что можно было вымерять динамометром - давно измерено и даже где-то тут опубликовано выше. :)
Одно это ограничение дает "теоретическое" время прохождения конкретно этой трассы в районе 7.5сек для наших ТТХ. Все что можно было вымерять динамометром - давно измерено и даже где-то тут опубликовано выше. :)
А вы хоть пользуетесь этим? А то померили, разобрали и... забили. Можно же и колесо шире поставить, меньше радиус и т.д.
На Формуле даже колеса меняют, что бы трасу пройти быстрее.
Не хочу быть капитаном Очевидность, но замечу. Ограничивает максимальную скорость на трасе, а не тупого полета без управление, сцепление колес с трасой. Так что бы все же и здесь отыграть, то надо перед запуском измерять и записывать в тетрадь силу сцепления с трасой. Колеса зафиксировать, что бы не крутились и мерять динамометром силу, при которой ваша машинка начинает скользить. А дальше или мыть трасу и колеса спиртом, или чем то еще и опять смотреть. Вплодь до того что бы покрывать колеса разбавленым резиновым или каким-то клеем. Делайте опыты, и может и на этом тоже чего-то отыграете.
ПС: Хотя может WADA вас за употребление "допинга" устранит, потому что первые места уже "куплены за ранее".
колёса мыть спиртом категорически нельзя, состав жидкости для промывки сдам только в личку под обязательства неразглашения ... но если спиртом уже мыли то их в урну
Мне это ни к чему. Просто там соревнования. На конкретной машинки и на конкретной трасе получается вполне конкретное значение сцепление. Вот его надо уметь точнее определить и перед забегом выставить в программе потому что: 1) если сделать меньше, то теряешь рекорд. 2) если больше, то уже машинка "слетает" с трека. Вот именно в этом и есть соревнование. Умение определить сцепление конкретной машинки на трассе и выставить ее в программе хотя бы внешним потенциометром, если скетч перешивать долго.
ПС: Может машинка вращением на месте это сцепление и измеряет.
О, это да .. послед забега трассу приходится протирать тряпочкой - остаются микрочастицы от резины колес как в Формуле-1, особенно на крутых виражах. Мешают. :)
В общем, оно поехало и одну пару резины мы похоже так и оставим "для тренировок". На соревнования поедет с "запасной резиной". По внимательному рассмотрению характера движения сделали 2 улучшения в программе и в ближайшее время видимо будем катать уже с "предсказателем поворотов". Скорости прохождения как на видео - у него ещё нет, но уже очень близко..
Настройку датчиков сделали так: если тележка по запуску стоит средним датчиком на линии, то читаем настройки из EEPROM, а если все датчики на "белом", то переходим в режим автонастройки с ручным движением датчиков по полю, после чего пишем результат в EEPROM .. работает на ура, но есть 1 недостаток: загрузку программы в тележку приходится делать ставя строго на линию .. иначе, пока компиляется, успевает уходить в режим автонастройки и пишет во флеш всякую чухню (что попалось под датчики)... не сразу доперло почему в EEPROM оказывается фигня. :)
По результатам и проверке пунктов:
п.а) - сопротивление воздуха -- фигня, не похоже;
п.б) - высокий профиль резины -- проявляется, но незначительно. Только в крутом развороте и при заходе на перекресток с вн. направления (там зигзаг). Куда больше влияет покачивание тележки из-за амортизации передних колес, особенно в переходных местах, где лампочки датчиков перемещаются. Из-за снижения скорости, хорошо видно как тележка "клюет" носом, причем со стороны внутреннего колеса и наклоняет блок датчиков. Но, тут похоже "неизбежность". Езда на жестких колесах (или скользящая передняя опора 1шт) плохо переносит балку - тележка резко подпрыгивает и теряет линию и, если балка оказалась под углом к курсу, то легко теряет линию насовсем - скользит колесами или опорой вдоль балки. С амортизацией такого нет даже близко - идет ровно, просто не замечая препятствия, только колеса подпрыгивают. На видео, похоже именно это и случилось с рекордсменом - там хорошо слышно "мы теперь вторые! он не прошел вторую квалификацию с балкой - упал" .. или как-то так.
п.в) - имеет место быть тоже, но пока некритично. Попытка моей перестройки программы под DECIMAL(1/1024) на базе long арифметики показывает что настроить тележку можно точней, но менять и разъяснять ребенку что и где ему надо будет исправлять - не стал, пусть так катается, терпимо вполне. Пока оно того не стоит...
п.г) куда как более сильное влияние оказалось от колес передней опоры. Перемещение их по длине тележки - очень сильно влияет на характер управления .. есть некий "оптимум" оказывается между осью вращения тележки, расположения Ц.Т., выноса датчиков от оси вращения и положения передней опоры, которую в поворотах можно принимать за "скользящую"... не всё так однозначно. :)
Я бы все-таки рассмотрел замену передних колес на опору. Правда ребенку такую опору сделать будет непросто. Если вкратце, то она должна иметь эффект пружинки, т.е. быть из нежесткого материала (в идеале из тонкой нержи), на той части опоры что соприкасается с поверхностью должен быть подшипник скольжения (фторопласт, тефлон), достаточно тонкий чтобы не создавать помех для преодоления препятствий. Надеюсь теперь более понятно объяснил какая должна быть опора. Ну и на вес тележки должна быть рассчитана так чтобы при "ударе" не согнулась в 0, иначе толку от нее уже не будет (иначе говоря должна быть и достаточно жесткой).
Нужно будет правильно рассчитать усилие входа на горку/карандаш. Если скорость в момент входа будет слишком мала, то пружинка-опора выкинет машину с трассы, если велика, то может появиться резонанс после прохождения препятствия.
Сейчас тележка примерно такая:
только ведущие колеса меньше и тоньше и соответственно она чуть ниже, вынос датчиков больше и пока не установлена декорация (будет). Тут резина 81.6х38, а у нас стоит 62.4х20.
Менять на скользящую опору .. врядли. Наши опыты показывают, что с ней хуже.
Может хотя бы срезать внешние кольца на передних колесах? Все меньше сопротивления повороту будет.
Центр масс слишком высоко для устойчивости в поворотах.
Кстати, у этой трассы есть сильный косяк: на ряде мест от линии трассы до края - менее 10см! Что при разрешенном габарите 200х200 приводит к гарантированному падению "за стол" (бортиков нет) при скоростном прохождении прямых участков у стартовой линии или большого поворота, если тележка идет "не по середине" трассы. Проверено неоднократно, и из-за этого и отказались от широкой резины - колесо вылетает со стола "только так". Предельная устойчивая ширина - не более 175мм (у нас сейчас 165). На картинке - 195мм.
?!? Это же "лего"! Ви знаете скока эти колесные диски стоят? :) А к ним и резина имеется .. выкинуть? :)
Тогда одеть капролоновые кольца. Можно сделать из 2-х половинок и склеить по месту. Просто у вас всместо 2-х пятен контакта получается их аж целых 4. Считать сложнее.
Да не .. там 2 пятна. Лего оно такое .. под весом детальки слегка прогибаются и колеса стоят немножко нараскоряку, опираясь только внутренним ободом на трассу. Зазор в действительности чуть больше миллиметра. И чем сильнее оно опирается в повороте - тем больше раскоряка. :)
Упс. Вчера открыл регламент, напосмотреть за изменения и внезапно читаю выделенное красным: "п.5. Запрещаются в конструкции робота любые детали Лего и моторы" .. на отборочных ещё было про только моторы .. отписался с вопросом организаторам - пока молчат.
Тем не менее, как понимаю, наша тележка "не проходит вовсе" и как уже отписывался в одной из тем, все печально: на соревнования по Лего мы - пролетаем потому что у нас Ардуино, на всякие Junior Skills - опять пролетаем потому что у нас "семейная команда" и последний шанс - Робофест, для нас тоже стал недоступен, потому что наше Ардуино .. как Лего.
Увы, но констатирую простой факт: в пылу конкурентной боьрбы за продажи и печеньки из госбюджета (не образовательная организация) дети, которые что-то мастерят своими руками выпали и остались никому не интересны. Увы.
В общем, попробуем все-таки поучаствовать, пересобрав тележку из "говна и палок" .. теперь нас интересует вопрос где и какие нормальные гоночные колеса на микропористой резине можно оперативно купить в г. Новосибирск, ибо заказать мы уже ничего не успеем.
Может кто-то что-то оперативно посоветовать? От размера этих колес надо будет строить мотор-редукторы и всю остальную тележку..
Из двухкомпонентного полиуретана можно самому колёса отлить. Не знаю, продаются они в маленький таре или нет.
Из полиуретана делают промышленные, износостойкие ролики, валики. Чем твёрже полиуретан, тем дороже.
Полиуретановые изделия на заказ. Наверное много денег попросят.
Пасибки, позвонюсь, но мне казалось что нужна микропористая резина, а не полиуретан.. насколько он хуже по к-ту трения? На леговской микропорке у нас к-т трения =0.68..0.8 в зависимости от протектора и чистоты колеса..
Думаю вам нужен дешевый, мягкий полиуретан.
Полиуретаны могут быть изготовлены с коэффициентом трения от очень низкого, подобно втулкам, подшипникам или сменным вкладышам, до очень высокого, подобно шинам или валам.
http://polimer-ug.com/voprosyi-otvetyi/preimushestva/
Пасибки, позвонюсь, но мне казалось что нужна микропористая резина, а не полиуретан.. насколько он хуже по к-ту трения? На леговской микропорке у нас к-т трения =0.68..0.8 в зависимости от протектора и чистоты колеса..
натянуть кусок резиновой камеры и зашлифовать наждачкой, коэффициент сцепления будет однозначно выше 0,8
По сслыке, позвонился - не берут, отписался "сделать заказ" - тишина. Увы, к сожалению для нашего города ситуация типовая.
В общем ребенка согласился с дербаном его игрушек и сделал 2 шикарных колеса на 63х23, по вашему методу натянув на колеса от его р/у трактора (лежит заброшенный давным-давно, жаль .. больше не поедет) порезанную шину от его же р/у модели (когда-то брал за 2500, не работает давно уже) на микропорке вместо резины от камеры. Спасибо за идею. Покрасил диск акриловым металиком "под бронзу" - получилось очень кузяво. Можно сделать ещё пару на 66х23..
Теперь мотор-редукторы .. наши, обклеенные лего-деталями как понимаю тоже могут забраковать запросто.
Скоростное изготовление новой тележки перенесу в свою тему. Далее - уже там, и фотки и описания..
для очень высоких скоростей моделей авто ширину шин делали как можно мешьше, если не изменяет память миллиметров 5-6, но это не из моих детских увлечений, я ракеты строил и судомодели )))
Я тоже. Ещё самолет. Даже целых 2. А судомодели - долгое хобби": "Драккар" (строился серийно, сколько раз уж и не помню .. делал как подарки к днюхам), "Золотая Лань" (М1:100 сильно упрощенно утопла из-за течи в днище), "82м, 100-пушечный линкор Королева Екатерина (Голландия)" - (М1:100 полный такелаж, рангоут, 4кг свинцового балласта, ходовая модель, без пушек - расстреляна из спичек под звуки похоронного марша в 1978г); "64-х пушечный фрегат Ингерманланд" - (М1:100, остался недостроен, тоже планировалась ходовая модель с пушками. Один 32-фунтовый Единорог даже рассверливал и отсреливал: насквозь 5мм фанеру до 5метров! Выдержал 20 выстрелов; "Петр Первый" - ховодая модель М1:100 .. остальное уже не помню. Какую-то ходовую модельку типа "газнейский когг" делал и вовсе исключительно из спичек .. шпангоуты, корпус, клееные мачты, реи .. :)
dell
dell
Пасибки, позвонюсь, но мне казалось что нужна микропористая резина, а не полиуретан.. насколько он хуже по к-ту трения? На леговской микропорке у нас к-т трения =0.68..0.8 в зависимости от протектора и чистоты колеса..
натянуть кусок резиновой камеры и зашлифовать наждачкой, коэффициент сцепления будет однозначно выше 0,8
На колесах по две полоски от велосипедной камеры сцепление супер .
https://www.youtube.com/watch?v=7uOx3RWLQ3I
Ребят, подскажите по коду - работает хорошо, но только на любых криволинейных поворотах, там где робот видит что он идет влево или вправо. Как только возникает поворот под прямым углом - теряется. На трассе шорт-трека шел уверенно, выдавая неплохой результат, более сложная трасса не дается из-за трех поворотов как раз прямоугольных. Код сделан для платы "Роботрек". И так же не получается сделать подобное для 5-и датчиков. Где я ошибся? int _ABVAR_1_shod_direction = 0 ; int _ABVAR_2_shod = 0 ; int _ABVAR_3_position = 0 ; int _ABVAR_4_sensor1 = 0 ; int _ABVAR_5_sensor2 = 0 ; int _ABVAR_6_sensor3 = 0 ; void readPosition(); void setup() { Serial.begin(115200); } void loop() { _ABVAR_1_shod_direction = 0 ; _ABVAR_2_shod = 0 ; readPosition(); if (( ( _ABVAR_2_shod ) == ( 1 ) )) { if (( ( _ABVAR_3_position ) >= ( 0 ) )) { startMotor(1, map ( _ABVAR_3_position , 200 , 900 , 5 , 70 ) ); startMotor(2, map ( _ABVAR_3_position , 200 , 900 , 70 , 5 ) ); } if (( ( _ABVAR_3_position ) <= ( 0 ) )) { startMotor(1, map ( _ABVAR_3_position , 200 , 900 , 70 , 5 ) ); startMotor(2, map ( _ABVAR_3_position , 200 , 900 , 5 , 70 ) ); } } Serial.print(_ABVAR_3_position); Serial.println(); } void readPosition() { _ABVAR_4_sensor1 = analogRead(IN1) ; _ABVAR_5_sensor2 = analogRead(IN2) ; _ABVAR_6_sensor3 = analogRead(IN3) ; if (( ( _ABVAR_5_sensor2 ) < ( 500 ) )) { _ABVAR_3_position = ( ( ( _ABVAR_4_sensor1 * -1 ) + _ABVAR_6_sensor3 ) / 2 ) ; } else { if (( ( _ABVAR_4_sensor1 ) > ( _ABVAR_6_sensor3 ) )) { _ABVAR_3_position = ( -800 + _ABVAR_4_sensor1 ) ; } else { _ABVAR_3_position = ( 800 - _ABVAR_6_sensor3 ) ; } } if (( ( ( _ABVAR_4_sensor1 + ( _ABVAR_5_sensor2 + _ABVAR_6_sensor3 ) ) ) > ( 2300 ) )) { _ABVAR_2_shod = 0 ; } else { _ABVAR_2_shod = 1 ; } }Кстати, насчет колес - лучшие колеса оказались из мягкого силикона, на робофесте в третий день гоняли на колесах от Робо-Робо, показали неплохой результат для новичков. микропора оказалась более жесткой. Ещё есть вариант ставить "липкую" резину - на тестах, пока у нас не появились колеса с силиконом, просто обматывали двусторонним плотым скотчем - работает на ура. единственно - слишком быстро грязь налипает, теряется эффект сцепления.
И правильно, что теряется. угол то прямой. Перед прямым углом надо подтормаживать, а то и переходить на самый медленый. И наконец если робот "потерялся", то "должен вращаться" на месте что бы "найтись" и при этом не "найти путь обратно".
ПС: Если вам надо улучшать сцепление, то сапожный клей (клей 88) самое то. Но это куча эксперементов, как мазать и какой толщины слой и за сколько до соревнований это делать. А скорее всего наносить клей паролоновыми валиками на колеса.
О, узнаю ребячий Ардублок .. тем не менее, недостатки по вашему коду:
1. Строки 45,46,47 читают датчики однократно и их 3шт. Независимо от качества датчиков, ещё есть "контакты" о которых учит сложная наука "электроника": "Электроника - наука о контактах, точне об их отсутствии" :) Нет никакой гарантии, что датчик не "сглючит" и это не выдаст кривой управляющий сигнал, пусть даже "однократно"... вывод: датчики полезно замерять по 2-3-4 раза и усреднять показания. Удобно воспользоваться циклом.
2. Пороговые уровни 500, 800 .. заданы константами. На разных трассах они могут быть сильно разными. Это та причина (а не то что все там думали), почему робот вообще мало у кого поехал. Трасса может быть "матовой", а может быть "глянцевой" .. и отражение даже при собственном освещении светодиодами, даже при "отстройке" от фоновой засветки, даже при работе в ИК диапазоне .. может отличаться значительно. У Вас это никак не учтено.
Для решения, делают "калибровку" датчиков ручную (как было у большинства кто "поехал") или автоподстройку (как было у уральцеев) и запоминают наименьшие и наибольшие показания датчиков и уже из них выводят "порог среднего". Особенно важно для датчиков на фототранзисторах, поскольку они хорошо засвечиваются обычным светом (зависят от внешнего освещения)..
3. Весь код readPosition() рассчитан в предположении что все(!) ваши датчики абсолютно одинаковы. Это не так даже при промышленном производстве, не говоря уже о РАЗНОЙ засветке трассы на разных её участках и при разной скорости движения .. Так можно делать ТОЛЬКО после приведения показания датчика к некоему "среднему" или обощенному варианту. Например, левый датчик работает в диапазоне 300-700, а правый в диапазоне 110-690 .. казалось бы отличие невелико, но оно будет вносит постоянную ошибку в ваши расчеты движения прямо.
4. Функция map() использует вещественную арифметику и делает НЕСКОЛЬКО умножений и делений .. рекомендую посмотреть её код. Напомню, что Ардуино UNO, Nano, Pro Mini, Mega2560 не имеют команд для прямой работы с такими числами. Все это делается типовой библиотекой и 1 операция занимает около 2 миллисекунд.
Для скоростного прохождения трассы Робофеста (10сек. и менее) требуется средняя скорость движения около 1 м/сек, ибо длина трассы около 10метров. Трасса Робофиниста больше - около 14 метров и сложнее. А поскольку движения в поворотах значительно больше чем по прямой, то эту цифру надо как миниум удвоить до 2 м/сек.А если учесть что внешнее колесо должно крутиться в 1.5 раза быстрее внутреннего, то и до 2.5-3м/сек.
Отсюда: за 1 мсек ваш робот должен проезжать около 3мм трассы. И простой расчет показывает что вызов 2 раза map() приведет к слепому проезду 6-12 сантиметров трассы. Какие уж тут повороты под 90 градусов? :) Собственно это - вторая причина почему на Робофесте-2017 из ардуинщиков мало кто поехал. Все кинулись использовать ПИД-регулятор с типовой .. вещественной библиотекой. Приехали. Это та причина, почему у нас НЕ использовался ПИД вовсе, и вообще всё управление делалось на "табличном конечном автомате". Самый быстрый способ управления для 8/16 разрядных МК. Не надо ничего "считать" вовсе. :)
Но, раз Вы пишете за 3-й день соревнований, то стало быть или это "Траектория" (старшая группа - зачем Вам тогда Ардублок?) или "Лего", в котором "все несколько иначе"...
Использование полноценного ПИД и вообще вещественной арифметики возможно только на "ардуино-совместимых" 32-х разрядных МК, имеющих под собой встроенную поддержку вещественных вычислений "за 1 такт" .. Teensy, STM32F4xx и даже STM32F103 уже не проходит по параметру "производительность" ни разу. Но, я считаю что такое использование "совместимых" плат есть ПРЯМОЕ нарушение Регламента соревнования.. и в таких случаях надо подавать протесты.. или требовать явного указания в Регламентах о допустимости "совместимых" плат. Слишком большая разница .. разные весовые категории и сильно.
В общем, если у Вас Ардуино в классическом исполнении - забудьте про map() и прочие "вещественные" вычисления.
P.S. Я сейчас пишу некое "руководство" для конструкторов в возрасте 9-11 лет по САМОСТОЯТЕЛЬНОМУ изготовлению скоростного робота по линии .. но это займет некоторое время и к апрельскому Робофинисту, я конечно же не успею.. планировал выкладку в учебных материалах на сайтах Робофеста и Робофиниста .. но пока не вижу тех, кому это полезно (отзывов на запрос нужна ли такая публикация - пока не увидел)
qwone, не получится там подтормаживать "перед" прямым углом.. там нужны иные подходы. Иначе "быстро" трассу и вовсе не пройти.