4. Функция map() использует вещественную арифметику и делает НЕСКОЛЬКО умножений и делений .. рекомендую посмотреть её код. Напомню, что Ардуино UNO, Nano, Pro Mini, Mega2560 не имеют команд для прямой работы с такими числами. Все это делается типовой библиотекой и 1 операция занимает около 2 миллисекунд.
Во-первых, согласно докуметнации map работает с целыми числами:
Цитата:
The map() function uses integer math so will not generate fractions, when the math might indicate that it should do so. Fractional remainders are truncated, and are not rounded or averaged.
Во-вторых, заявленные Вами цифры сильно завышены, на самом деле время выполнения одной из трех арифметических операций составляет примерно 15 мкс, а деления - примерно 50-60 мкс. Хотя, конечно, если их в вычислениях десятки, то это займет определенное время.
Что же касается ПИД, то его наверняка можно переписать на fixed point, что при грамотной реализации сократит время выполнения в десятки раз.
Согласен, подзабыл уже. Все равно там long и это долго, а самое главное что никому не нужно ни разу.
Это map():
long map(long x, long in_min, long in_max, long out_min, long out_max)
{
return (x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min;
}
Имеем 4 сложения-вычитания + умножение и деление. Плюс прием 5 параметров типа long (т.е. через перезапись со стека в регистры и обратно). Грубо по вашей же оценке тактов, тем не менее имеем: 4*16+22+670 + (4 + 5 + 9*4) = около 800 тактов по 62.5нс = 50 микросекунд, вполне терпимо для пары вызовов. В скобках указаны примерные затраты на вызов функции с 5-ю длинными параметрами (5 внутрь + 4 вытаскиваем внутри функции, 1 - передается в регистрах). Можно посмотреть в ассемблере сколько оно займет на самом деле..
Переписать ПИД под фикс. арифметику на long .. не знаю, оно конечно выйдет пошустрее. Ну будет у вас слепой пролет не 6-12 сантиметров, а только 1-2 .. разве от этого легче? :)
Критика конечно имеет место быть, но смысл критики без конструктива? насчет плат Teensy или STM - ни разу не видел их на Робофесте. Третий день катали на Робочелендже - там да, там подобные были.
Как только возникает поворот под прямым углом - теряется. На трассе шорт-трека шел уверенно, выдавая неплохой результат, более сложная трасса
И правильно, что теряется. угол то прямой. Перед прямым углом надо подтормаживать, а то и переходить на самый медленый. И наконец если робот "потерялся", то "должен вращаться" на месте что бы "найтись" и при этом не "найти путь обратно".
ПС: Если вам надо улучшать сцепление, то сапожный клей (клей 88) самое то. Но это куча эксперементов, как мазать и какой толщины слой и за сколько до соревнований это делать. А скорее всего наносить клей паролоновыми валиками на колеса.
Ну, такие эксперименты намного сложнее, чем изготовить самим силиконовые шины. Да и любой резиновый клей со временем на открытом воздухе становится очень жестким, а мазать каждый раз перед соревнованиями - лучше отлить шины.
Насчет притормаживания перед прямым углом - мысль возникала и не раз, но как её реализовать с тремя датчиками? Увы, знаний не хватает, а найти подобную информацию в интернете крайне сложно - везде суют библиотеки, но это не то что нужно. Чтобы дети уверенно знали что и как делать им нужно самим, ручками, прописать весь код, и только потом переходить на использование библиотек.
Думал поставить 5 датчиков, но никак не могу правильно вывести формулу расчета положения линии - работают только крайние и средний датчики, промежуточные выдают положения совершенно не те, что нужно.
P.S. Я сейчас пишу некое "руководство" для конструкторов в возрасте 9-11 лет по САМОСТОЯТЕЛЬНОМУ изготовлению скоростного робота по линии .. но это займет некоторое время и к апрельскому Робофинисту, я конечно же не успею.. планировал выкладку в учебных материалах на сайтах Робофеста и Робофиниста .. но пока не вижу тех, кому это полезно (отзывов на запрос нужна ли такая публикация - пока не увидел)
Было бы интересно взглянуть. Для детей, доступным языком откровенно - ничего нет, приходится все перерабатывать. Особенно что касается связи "Вариант техники + код именно для него". Везде пытаются всунуть сложные математические формулы, физические параметры и прочее.
Слишком сложно для третьеклассников, которые ещё даже дроби не знают, а тут сразу гигантский объем нужно изучить.
Кстати это одна из самых главных причин недолюбливания "Робофестов" и прочих "фестивалей" - для тех кто только начинает - простая гонка по линии уже сложно, а уж давать задания на остановку перед перекрестком, да ещё на скоростном проезде....
По мне - начинающим надо оставить линию, пускай там будут крутые повороты, горки или балка, но безо всяких перекрестков - и на одной линии можно спокойно учиться и учиться. Тем более что вариантов по самим роботам - масса.
Ну, в общем-то да - погорячился слегка. Пересмотрел наши записи и замеры, и оказалось что наша собственная тележка пролетала до 6-8мм трассы вслепую "только так". Видимо оно не так уж и страшно для задач управления. Теплый ламповый аналог - пока ещё оставим для неумех. :)
На Робофесте шортрека - уже есть и вполне себе круто катаются. Мы катались на Нано, ну и что с того?
Какой к-т трения у ваших самодельных (я верно понял?) силиконовых шин? Мягкая микропористая резина с протектором дает к-т поперечного трения в районе 0.72-0.85, для достижимой у меня точности измерений .. не думаю что силикон по ПВХ баннеру даст лучше. Жесткие колеса при большем к-те трения даже предпочтительней - меньше к-т трения качения из-за прогиба шины.
Существуют разные подходы к работе с датчиками. Ваш - далеко не самый удачный.
Дети ведь не попадают на Робофест "в нуля". Нам, чтобы попасть на общероссийские соревнования пришлось поучаствовать на городских, потом заявиться на отборочные областные и только потом нас "пустили" в Москву. К этому времени, все типовые грабли были благополучно оттоптаны не по одному разу. У Вас разве не так?
Внезапно оказалось что "писать книжку" ни разу не проще чем сваять скоростную тележку .. пока добрался до раздела "драйвера - моторы - редукторы - колеса" .. :)
P.S. То, что пишу, к сожалению, тоже не будет содержать "готовых примеров" в виде "вот конструкция и вот к ней готовая программа и комплект настроек". Увы, тут видимо разачарую. Планирую перечислить все типовые грабли при разработке такой тележки и обоснования (простые, понятные для детей - проверка как на своем, так и ещё есть несколько подопытных кроликов) причин их появления и опять же типовые рекомендации по их преодолению. А уж конструкцию и программу - каждый "конструктор в возрасте 9-11лет" будет придумывать и делать самостоятельно. Увы. :)
Какой к-т трения у ваших самодельных (я верно понял?) силиконовых шин? Мягкая микропористая резина с протектором дает к-т поперечного трения в районе 0.72-0.85, для достижимой у меня точности измерений .. не думаю что силикон по ПВХ баннеру даст лучше. Жесткие колеса при большем к-те трения даже предпочтительней - меньше к-т трения качения из-за прогиба шины.
Существуют разные подходы к работе с датчиками. Ваш - далеко не самый удачный.
У нас примерно 15-02 по Шору. Более жесткие наоборот хуже - у них трение намного ниже чем у "прилипающих".
Какой например подход работы с датчиками подскажете? Я сам технарь, программированием волею случая занимаюсь, так что многого не знаю, из того что есть. Пока этот код самый удачныйц из всех что есть. Но увы - прямоугольные повороты...
Думал поставить 5 датчиков, но никак не могу правильно вывести формулу расчета положения линии - работают только крайние и средний датчики, промежуточные выдают положения совершенно не те, что нужно.
Вот прикиньте промежуточный вариант . Линия это граница двух цветов- черного и белого. Для отработки алгоритма нарисуйте трек различного траектории состоящей из двух состыкованых полос, как на автомобильных дорогах, черной и белой. Вот машинка и должна ехать по границе черной и белой полос. Сколько датчиков должно быть ? (!) Четыре. Два впереди - фиксировать ситуацию когда два датчика показывают оба или черное или белое. И два возде ведущих колес - что бы определить мы все же едим на Финиш, или как не странно обратно на Старт. Вот когда отработаете эту методику на различных изломаных треков, то можете перейти движению по линии - виртуально назначая какая сторона Черная, а какая Белая.
Krums, Вы отписались за твердость ваших колес, а я спрашивал за трение по ПВХ баннеру... это как "теплое с мягким". Как "технарю" Вам это должно быть понятно. Мне интересен именно к-т бокового трения колес из силикона. Его несложно измерить в домашних условиях: цепляете свою тележку к "безмену" (динамометру) и смотрите при каком весе колесо начинает смещаться по баннеру трассы (надеюсь есть в доступе). После чего взвешиваете свою тележку и делите вес на динамометре (безмене) на вес тележки. Опыт лучше призвести не менее 12 раз, откинуть оба крайних значения (самое большое и самое малое) и усреднить по 10-и оставшимся.
Этот к-т определяет максимально возможную скорость движения по трассе в поворотах и соответственно предельную крутизну поворота .. т.е. успешное прохождение тех самых 90 градусов.
По датчикам. Тх можно использовать очень по-разному. Какой способ наиболее приемлем .. да фиг его знает, зависит от нескольких факторов, в т.ч. и от ваших предпочтений тоже. :)
1. Датчики можно "превратить" в цифровые и использовать в битовом режиме: 1 - "Черное", 0- "Белое" .. можно использовать типовую формулу, вычисления "отклонения линии от середины тележки". В этом разе, чем больше количество датчиков и чем чаще они стоят по краю линии - тем точнее вычисляется положение.
2. Можно использовать аналоговые значения, ибо линия для аналогового дачтика этот вовсе не "четкая граница", а достаточно расплывчатое пятно. Но. как уже писал - в этом случае датчики надо "калибровать" и приводить их значения к единому стандарту (диапазону). В этом случае можно использовать точно также "много" датчиков, вычисляя отклонение примерно как по вашей формуле (она близка к типовой). Это снова "ещё один map()" что мне кажется дороговатым для скоростного движения
3. Можно реализовать промежуточные "цифро-аналоговые" решения .. их тоже несколько: а) разбить диапазон показаний на несколько градаций вместо черное-белое и привести к цифровым с учетом этого; б) использовать как цифровые, но потом дополнительно уточнять отклонение из аналоговых значений. в) .. ваши и прочие "чумовые" идеи.. :)
.. ну и ещё: на оптимальное количество датчиков влияет как ширина линии трассы, так и способ их обработки в ПО. Есть варианты, когда при вдвое меньшем количестве датчиков можно получить ту же самую точность вычисления отклонения.. Задача поиска "оптимального" количества датчиков в "руководстве" планируется на домашнее, самостоятельное решение. :)
qwone, Датчики возле колес (второй ряд) практически будут диагностировать ситуацию "постфактум" .. типа "пролетели, снимаемся с соревнований". Там есть одно жесткое условие, а именно: тележка все время должна находится на трассе ТАК, чтобы её колеса (точки опоры) были по ОБЕ стороны трассы. Выезд за трассу .. пока-пока. :)
qwone, Датчики возле колес (второй ряд) практически будут диагностировать ситуацию "постфактум" .. типа "пролетели, снимаемся с соревнований". Там есть одно жесткое условие, а именно: тележка все время должна находится на трассе ТАК, чтобы её колеса (точки опоры) были по ОБЕ стороны трассы. Выезд за трассу .. пока-пока. :)[/quote ]
Датчики возле колес определяют на какой стороне мы находимся и куда едем . Например( Пр-чер Лев -бел) это к Финишу. ( Пр-бел Лев -чер) к Старту :) ( Пр-чер Лев -чер) мы на правой стороне и обратно на белой. Конечно лучше иметь еще и гирокомпас. Да впереди поставить не 2 , а 4 или даже 6 датчиков .Каждая пара на разном растоянии от центра движения машины. Вылет за ближнию пару позволит не потерять линию вообще.
Для подобной конструкции, если ставить датчики возле колес, вполне достаточно иметь три передних датчика. ставить 6 и более уже излишне - терям время при опросе, да и гирокомпас не особо поможет - нужно тогда записывать в память весь пройденный путь, и писать программу для корректировки движения с учетом всех ошибок. Для маленьких это нереально. Нужно что-то попроще. Линейка из 5-6 датчиков п\вполне с этой задачей справится, но тут снова проблема ( лично у меня ) - повторюсь - никак не могу найти или подобрать формулу расчета положения линии. все время получается одно и тоже - первый левый например выдает -250, второй слева выдает уже 250, средний ыыдает ноль, и два правых - 250, 280. Как-то так. ( датичики не подобраны по своим параметрам, пока стоят из кучи. как только формула сработает - можно протестировать все датчики и подобрать подходящие).
Насчет функции map - работает отлично! Без неё моторы работают с постоянными скоростями, в результате имеем рысканье, тем более на прямой. да, потеряем время при опросе данных, но за счет механического действия робота - выигрываем секунды. То есть, если без масштабирования робот рыскает, то максимум где он будет иметь высокую скорость - на поворотах, зато на прямой теряет драгоценные секунды сводя на нет все усилия. Так что пусть лучше функция "съедает" программно доли секунды, пусть будет слепая зона 7-12 мм, но это все равно гарантировано высокая скорость и уверенный проезд по всей линии.
Хочу добавить по два датчика с выносом за пределы линии, но сколько ни бьюсь не могу добиться корректной работы вместе с основным массивом - или работает блок с тремя датчиками, или только эти два. По логике должно быть следующее - "Shood" показывает 1 (линию), робот едет вперед, дополнительные датчики показывают белое поле. как только сработал любой из дополнительных датчкиов - значит перед нами крутой поворот, и робот должен поворачивать в сторону сработавшего датчика. Оба датчика показали черное - перед нами перекресток - "Старт" или "Финиш" . Но на практике получается следующее - робот едет, но через пару секунд теряет линию и крутится на месте.
Извините, ваш робот ВСЕГДА подъезжает к перекрестку СТРОГО по линии, так чтобы ОБЕ стороны датчиков сработали ОДНОВРЕМЕННО (оба датчика показали черное - перекресток)? А если нет, то чем отличается перекресток от крутого поворота для робота? Наш, на четверть финале, так и решил и поехал в крутой поворот (и ведь успел зараза!) вместо прямого движения через перекресток. :)
P.S. особенно интересно в свете "6-12мм вслепую" и совсем интересно для "евротрасс" шириной всего 15мм :)
Ну и по вашим исканиям формулы. Она - типовая и легко выводится для случая цифровых датчиков, где-то встречал и в Сети тоже, но уже не помню. Для вашего подхода - выше описан случай 2. Без предварительной калибровки ( map() на каждый датчик) этот подход неприменим. мне так видится. Найдете решение - отпишитесь, добавлю в руководство, если Вы не против. :)
P.S. и ещё: 10-12мм вслепую - это достаточно много, а с map() на каждый датчик для 5шт - может оказаться и фатальным для линий шириной в 20мм (Робофест). Дело в том, что при резком развороте тележки, круговая скорость перемещения блока датчиков значительно выше чем при рыскании по трассе и даже наши 6-8мм не позволили нам применить "автонастройку" датчиков тем способом, который показан в видео отборочного тура уральцев (но там у них машинка шустрее в несколько раз, не Atmel). Блок датчиков при "среднем" вращении проскакивал линию шириной 20мм "только так" двигаясь поперек неё. Пришлось ребенку оставлять "ручную настройку".
P.P.S. перечитал сообщения .. "по трассе Робофеста шел уверенно" .. Краснодар? Уверенно (это первая квалификация) прошло всего 3 тележки из 35. :)
Извините, ваш робот ВСЕГДА подъезжает к перекрестку СТРОГО по линии, так чтобы ОБЕ стороны датчиков сработали ОДНОВРЕМЕННО (оба датчика показали черное - перекресток)? А если нет, то чем отличается перекресток от крутого поворота для робота? Наш, на четверть финале, так и решил и поехал в крутой поворот (и ведь успел зараза!) вместо прямого движения через перекресток. :)
P.S. особенно интересно в свете "6-12мм вслепую" и совсем интересно для "евротрасс" шириной всего 15мм :)
У нас датчики стоят строго над линией ( в том варианте что здесь выложил), так что робот видит только линию, без перекрестков. с шириной 22-25 мм проблем никаких, с вариантом линии 15 мм есть вылеты на повортах, но на "Евро" линии перекрестков нет, так что единственная проблема - с прямыми углами, потому и хочу поставить 5 датчиков.
P.S. и ещё: 10-12мм вслепую - это достаточно много, а с map() на каждый датчик для 5шт - может оказаться и фатальным для линий шириной в 20мм (Робофест). Дело в том, что при резком развороте тележки, круговая скорость перемещения блока датчиков значительно выше чем при рыскании по трассе и даже наши 6-8мм не позволили нам применить "автонастройку" датчиков тем способом, который показан в видео отборочного тура уральцев (но там у них машинка шустрее в несколько раз, не Atmel). Блок датчиков при "среднем" вращении проскакивал линию шириной 20мм "только так" двигаясь поперек неё. Пришлось ребенку оставлять "ручную настройку".
P.P.S. перечитал сообщения .. "по трассе Робофеста шел уверенно" .. Краснодар? Уверенно (это первая квалификация) прошло всего 3 тележки из 35. :)
Нет, не Краснодар, Пенза. Как уже писал - в Москве мы не проехали в первый день, хотя и освещение выключили, но глянцевая линия, + усталость детей сделали свое дело. Всего-то оставалось - повысить порог датчиков, но в том варианте это 12 условий, и в каждом по три датчика....Потому и мучаю нынешний код.
Ну я бы вам предложил опробовать принцип "тараканьи усы" под углом 90-120 градусов между собой и по 3 (три) датчика на ус. Ближайшие датчики на усах следят за линией, а дальше если линия сбилась или поворот на 90 градусов. Усы длиной примерно в 1-0,5 корпуса машины. Попробуйте на рамке сделать . Ну как лозоходы воду ищат. Ну и вывод вместо моторов на светодиоды правая вперед,правая назад,левая вперед,левая назад и ШИМ их регулировка яркостью. Вот так вы отработаете геометрию усов и размещение датчиков на них.
Больше датчиков нужны как раз для более сложных трасс - там где есть перекрестки или инверсия. Ну и обеспечат отсутствие вылетов на очень крутых поворотах.
А по Москве - остается только добавить - заниматься организацией подобных мероприятий должны не "продавцы" от Амперки, а технари! У нас ребятёнок вобще не хотел идти на следующий день - "что там делать, все равно не проедем"... однако в топ-10 попали.
Насчет того чтоб объяснять четвероклассникам тонкости и нюансы - это надо делать, и обязательно. Если бы они ещё имели привычку записывать все эксперименты что делали с кодом - было бы ещё лучше, однако увы - бесполезно. Сколько ни бьюсь - не работает и все.
Ну я бы вам предложил опробовать принцип "тараканьи усы" под углом 90-120 градусов между собой и по 3 (три) датчика на ус. Ближайшие датчики на усах следят за линией, а дальше если линия сбилась или поворот на 90 градусов. Усы длиной примерно в 1-0,5 корпуса машины. Попробуйте на рамке сделать . Ну как лозоходы воду ищат. Ну и вывод вместо моторов на светодиоды правая вперед,правая назад,левая вперед,левая назад и ШИМ их регулировка яркостью. Вот так вы отработаете геометрию усов и размещение датчиков на них.
В таком случае имеет смысл делать массив датчиков, в виде той же рамки - тогда положение линии будет гораздо четче. Вариантов масса, но есть одно "но" - как это реализовать программно? )))) Вся суть не в техническом решении,а в програмном. Поэтому и слетают роботы - нет хорошей программы)
В таком случае имеет смысл делать массив датчиков, в виде той же рамки - тогда положение линии будет гораздо четче. Вариантов масса, но есть одно "но" - как это реализовать программно? )))) Вся суть не в техническом решении,а в програмном. Поэтому и слетают роботы - нет хорошей программы)
Скорее нет хороших программистов. Или у вас нет возможности их нанять. Программисты на Ардуино "деревянные", вот и программы выходят тупые. А так ресурсов хватит, даже написать программу не лезть в ассемблер.
ПС: Я не берусь, так как надо как минимум иметь машинку и место для отработки программы.
В таком случае имеет смысл делать массив датчиков, в виде той же рамки - тогда положение линии будет гораздо четче. Вариантов масса, но есть одно "но" - как это реализовать программно? )))) Вся суть не в техническом решении,а в програмном. Поэтому и слетают роботы - нет хорошей программы)
Скорее нет хороших программистов. Или у вас нет возможности их нанять. Программисты на Ардуино "деревянные", вот и программы выходят тупые. А так ресурсов хватит, даже написать программу не лезть в ассемблер.
ПС: Я не берусь, так как надо как минимум иметь машинку и место для отработки программы.
Дык, и я о том же) а нанять - кто пойдет учить на ставку педагога? Все хотят много и сразу, молодым вобще ничего не нужно. Так и теряем возможность вырастить думающих людей, а не "шахтеров".
"..Если бы они ещё имели привычку записывать все эксперименты что делали с кодом - было бы ещё лучше, однако увы - бесполезно. Сколько ни бьюсь - не работает и все.."
Ну .. тут не знаю и не могу согласиться с Вами. Наш исписал уже "общую тетрадку А4" своими экспериментами с прошлого года, начиная с первых построений схем из конструктора Знаток, систематизации наших аккумуляторов Ni-MH, которые ему отдавались как убитые в фотоаппаратах, систематизации наших DC-моторов (их около 20шт) от разного рода детских игрушек, запись сколько и каким проводом он перематывал свои 2 мотора, процесс центровки якоря и потом замер их ТТХ "что получилось" в итоге (к слову, получилось не ахти, но это его, ребенкины эксперименты!). Все его "эксперименты" тщательно записаны им самим, в т.ч. и те, которые он проводил в мое отсутствие. Это вообще - первое, чему его обучал: изменил что-то - запиши что изменил и как было. Не записал? Молодец, начинай ВСЁ с начала.. пару раз хватает чтобы понять важность ведения дневника экспериментатора. Опять же, примеры великих Вам в помощь - Тесла .. это ведь исключительно благодаря ему и его дневникам мы имеем сейчас все то, что имеем! Более 10 тысяч патентов, в т.ч. и на люминесцентные лампы (запатентованы даже раньше "обычных"), сотовые телефоны и т.д. :)
И при подготовке полно записей: комплект настроек .. изменил это .. время проезда, рыскание, вылет на развороте, перекрестке, вывод. Страниц 5-6 точно есть. :)
А где Вы соревновались на третий день? В robotChallenge? Как туда попали? Вроде бы записать команду можно было только на одно соревнование .. знали бы, наверное тоже бы поучаствовали, но .. не знаю. Наш после Москвы отдохнул только вчера. Только вчера он полноценно сел читать регламент РТК и сделал первую тележку-вездеход на базе нашего "Ардуино как Лего".. поехала, но пока криво. :)
По организации. Не знаю, может у Вас больше соревновательного опыта, но то что я увидел там, как все было организовано и то что я вижу у нас, тут в Новосибирске - небо и земля. Достаточно сказать, что, как понимаю, только из-за хамского отношения к детям некоторых "организаторов" в этом году у нас представительность соревнований упала примерно раза в 2, а то и больше. Так на отборочных нас оказалось всего .. двое, против 8 команд в прошлом году, а у леговцев всего 10-12 команд против 23-25 в прошлом году тоже. Так,имея 6 квот по Hello Robot, Arduino, Новосибирск смог выставить только 1(ОДНУ) нашу команду ..
я уж молчу за то что "опоздали там, опоздали тут, розетки подведены только к половине столов, бейджики на столы раскладывают в твоем присутствии, на ходу, питание половины участников забыто вовсе (кто успел, тот и съел), карантинные столы в зоне свободного доступа "друзей" (студентов) судей и помощников (Вау, беря в руки машинку с карантина, смотри какого робота кто-то сделал), наборы маек, блокнотиков, ручек раздавали в процессе награждения тем, кто на него остался, а не ДО начала соревнований всем, как тут (да ещё и с обменом по размерам!) и т.д. .. деревня одним словом (и сколько не пытаюсь доказать организаторам что надо иначе - бесполезно!). Увы.
И совсем уж молчу за выложенное видео финального заезда в младшей группе с участием дяди-тренера по распоряжению организатора, не взирая ни на какие протесты мои или зрителей .. вот такая она у нас "младшая группа" от 40 лет. :)
"Дык, и я о том же) а нанять - кто пойдет учить на ставку педагога? Все хотят много и сразу, молодым вобще ничего не нужно. Так и теряем возможность вырастить думающих людей, а не "шахтеров".
"
Это да. Пробовал пойти в "неформальную организацию" развить кружок "Ардуино" .. ставка 3тыс. руб. .. в месяц. Ну куда это? В школах, как понимаю "то же самое".. зато писанины отчетов .. "мама не горюй", впечатлился когда ознакомился.
Кстати, черканите мне на arhat109@mail.ru, вышлю вам текущий черновой вариант своего "руководства" на прочитку вашими ребятишками и их отзыв. Предупреждаю сразу - это сильно черновой вариант, с ошибками, кривыми оборотами и т.п. Писано "на скорую руку" с небольшой правкой по рекомендации тренера HRAsh-19.
А где Вы соревновались на третий день? В robotChallenge? Как туда попали? Вроде бы записать команду можно было только на одно соревнование .. знали бы, наверное тоже бы поучаствовали, но .. не знаю. Наш после Москвы отдохнул только вчера. Только вчера он полноценно сел читать регламент РТК и сделал первую тележку-вездеход на базе нашего "Ардуино как Лего".. поехала, но пока криво. :)
Да, мы в Робочелендже участвовали. Регистрация была там, же, на сайте Робофеста, а вобще если что - вот ссылка - http://rus-robots.ru
"Дык, и я о том же) а нанять - кто пойдет учить на ставку педагога? Все хотят много и сразу, молодым вобще ничего не нужно. Так и теряем возможность вырастить думающих людей, а не "шахтеров".
"
Это да. Пробовал пойти в "неформальную организацию" развить кружок "Ардуино" .. ставка 3тыс. руб. .. в месяц. Ну куда это? В школах, как понимаю "то же самое".. зато писанины отчетов .. "мама не горюй", впечатлился когда ознакомился.
посмотрел ваши видео. Около 9 секунд на домашней трассе - очень неплохо, но регулярно фиксируются вылеты на втором развороте. Это неудовлетворительно и на соревнованиях было бы зафиксировано как "ошибка" и непрохождение трассы. Скетч, посмотрю позже, сейчас немного занят .. но сам факт использования датчиков только внутри линии - говорит за то что вариантов программы и схемотехники - просто "много". Этим и интересен "шорт-трек". Кстати, не пробовали гонять в обратном направлении? Трасса далеко не одинакова (и не проста) .. наш в обратную сторону дома ехал на порядок лучше.
посмотрел ваши видео. Около 9 секунд на домашней трассе - очень неплохо, но регулярно фиксируются вылеты на втором развороте. Это неудовлетворительно и на соревнованиях было бы зафиксировано как "ошибка" и непрохождение трассы. Скетч, посмотрю позже, сейчас немного занят .. но сам факт использования датчиков только внутри линии - говорит за то что вариантов программы и схемотехники - просто "много". Этим и интересен "шорт-трек". Кстати, не пробовали гонять в обратном направлении? Трасса далеко не одинакова (и не проста) .. наш в обратную сторону дома ехал на порядок лучше.
вылеты вылечились простым протиранием колес - когда снимали не обратили внимание что колеса были заляпаны грязью, соответственно и сцепления никакого. Протерли - все норм.
Да и вылет как раз потому что разгон на прямой слишком сильный - стоило снизить - и норм. В обратную сторону так же.
Глянул бегло скетч .. Ай-я-яй .. все настроечные константы прописаны .. прямо в коде, собственно и пример тут такой же. Перенастраивать такой код - достаточно кропотливая работенка для дитенков. А создать блок настроечных переменных и использовать их - почему не?
У нас была спец. процедура setupSpeed() (тоже Ардублок), в которую были вынесены все настроечные параметры и менялись они только в одном месте. Более того! Как только поехали за 14сек, сразу же клонировали процедуру и переименовали старую в setupSpeed14() .. и продолжили далее и так появились setupSpeed10(), setupSpeed9() .. надо ехать медленее? Да не проблема! В главном setup() изменил вызов на другую настроечную процедуру и все дела..
Ну и по функциям a(), b(), c(), d() .. по большей части они одинаковы с небольшими изменениями .. тоже легко объединяется через использование параметров к функции. Ардублок не имеет? Не проблема. Делает глобалы со спец. названием и присваиваем им значения перед вызовом, а внутри функции используем эти глобалы вместо настоящих переменных. По завершению вызова переприсваиваем обратно взад... :)
по сути там реализован конечный автомат состояний, но его можно и нужно рисовать иначе. В таком виде - достаточно сложно понять что делается и при каком наборе условий - соответственно править детишкам "на бегу" - возможность исправить что-то не то.
Похоже мой дитенок ленивее ваших .. он до этих моментов дотумкал сам, когда надоело шариться по коду Ардублока в поиске "где же я забыл исправить ещё".. остальное позже. впрочем, уже писал выше, перечитайте. Но у нас и прорамма была не в пример сложнее: около 1000 строк после Ардублока. У Вас - слишком примитивная работа с датчиками, отсюда и проблемы на трассе соревнований, плюс сложность перенастройки отписал выше, а в пылу соревнования - накладывает свои ограничения.
Если бы ещё знать как все это делать))) Умом понимаю что нужно выносить в один параметр, и там только менять,а на практике - черт ногу сломит как все реализовать) Даже простой счетчик поворотов - и то уже проблема.
Мда...поневоле позавидуешь нынешним школьникам - все что нужно есть, а я свой первый компьютер увидел около 20-и лет отроду)))) и даже и не знал что такое информатика, и с чем её едят)
Зато технические реализации - пожалуйста, любые, и на ура.
Похоже, что самое оптимальное размещение датчиков - "на жопе" машинки.Ставятся рядом два датчика буквально впритирку. Нормально они должны фиксировать черную линию. При изменении положения линии будет переход Черный- Белый. Где раньше произошел сдвиг , то в ту сторону и сместилось. Так что идет компенсация, чтобы оба датчика стали черными.
ПС. Так ближе к оси ведущих колес. Это и есть оптимальное расположение. Ближе , но не на самой оси.
Если вы про дополнительные датчики - то да, такой вариант тоже очень хороший, но только с теми доп.датчиками что впереди стоят - тогда позиция робота определяется совершенно точно! Да, тот робот что на видео имеет вынос датчиков сильно вперед, из-за конструктива не можем перенисти немного ближе к колесам - робот срезает углы. Но с другой стороны - он не теряет линию, идет ровно, так что... ))))
Посмотрел видео. Очень медленно. С такой скоростью может ехать и самая простейшая программа и ловить такие повороты. Повторюсь ещё раз:
1. Датчики без обработки ошибок, с жестко заложенными порогами срабатываний в проверках -- крайне примитивный вариант и требует тщательной настройки на конкретные условия проведения соревнований. Малейшие изменения в этих условиях (освещенность, отражение, ширина линии и т.д.) и всё надо перенастраивать полностью и заново. Тренировочного времени может банально не хватить. Собственно это - главная причина того что на соревнованиях Робофест-2017 такое количество "не поехавших вовсе".
А у Вас ещё и дополнительная проблема: Вы за время принятия решения (1 проход loop()) снимаете показания датчиков несколько раз, каждый раз заново в новом условии или управляющем map() .. даже парамиллисекунд при скоростном движении - это НОВОЕ место на трассе и новое значение. Получается что решение принимается по одному показанию - "плавный поворот", а управляющее воздействие в map() по новому показанию датчиков.
1. Показания датчиков надо усреднять по нескольким значениям. Тут есть несколько вариантов: брать 2-3-4-5 замеров складывать и делить на количество замеров - среднее по замерам, можно считать "бегущее среднее с накоплением" это программно проще и быстрей, но будет несколько "затягивать" показания. Насколько? Зависит от частоты замеров (те самые 4-6-8-10-12мм вслепую).
2. Показания датчиков надо очищать от засветки программно (часто советуют фильтр Кальмана, но он достаточно сложен), кроме принятия технических мер (экранирование).
3. Показания датчиков надо очищать от взаимовлияния. Оно сильно зависит от схемы датчика, точнее его выходного сопротивления.
В любом случае, это требует той или иной калибровки датчиков на конкретном поле ..
Поймите, что то, что хорошо едет дома - вовсе не показатель. Для проверки устойчивости, напроситесь в пару кружков или мест где проходят занятия на "попробовать" и попробуйте проехать с той программой, которая у вас хорошо едет дома без настроек. Мы, до всех этих изменений программы, тоже дико удивлялись почему дома едет "на ура", а скажем в ближайшей школе с инженерным классом, где есть поля и занятия - упс. теряет линию местами, а в том же инженерном Лицее НГТУ .. и вовсе не видит линию! И нам верно делали замечания наше новосибирское руководство после наших V-городских соревнований: "ехать быстро - это полдела. Главная задача - ехать надежно, а у вас это не так. Учитесь". :)
P.S. Ну и ещё. Ваше видео наглядно показывает что для скоростного движения на крутых поворотах ваших 3-х датчиков строго "над" линией - категорически не хватает. Даже при такой медленной езде, датчики "вылетают" далеко за линию и фактически перестают управлять тележкой. Ибо ваш подход дает изменение управляющего сигнала только по факту изменения уровня датчиков .. когда все датчики "видят одинаково белое" - ваше управления сводится к простому алгоритму: "вращаемся на месте пока не найдем линию". Для его реализации датчики и вовсе не требуются, только на отлов "нашли линию". Что у вас и происходит на видео.
Пробовал пойти в "неформальную организацию" развить кружок "Ардуино" .. ставка 3тыс. руб. .. в месяц. Ну куда это? В школах, как понимаю "то же самое".. зато писанины отчетов .. "мама не горюй", впечатлился когда ознакомился.
Отсюда: за 1 мсек ваш робот должен проезжать около 3мм трассы. у нас НЕ использовался ПИД вовсе, и вообще всё управление делалось на "табличном конечном автомате". Самый быстрый способ управления для 8/16 разрядных МК. Не надо ничего "считать" вовсе. :)
Про датчики линии. Если не знаешь, как бороться с помехами нужно их возглавить. Для этого приклеили кусочек светодиодной ленты 6500К. Давайте обсудим это решение.
Про датчики линии. Если не знаешь, как бороться с помехами нужно их возглавить. Для этого приклеили кусочек светодиодной ленты 6500К. Давайте обсудим это решение.
Присоединяюсь. Если датчик "ИК", то какой ему прок от такой засветки, да и вообще, его разве волнует какая-то "засветка" акромя своего светодиода? Может источник ваших помех в ином месте? Внешнего отраженного ИК фона от баннера трассы - практически ни разу не наблюдал. Сколько засветишь - столько и кажет. Причем гоняем и при дневном свете и при обыкновенном и люминисцентном .. и даже в полной темноте ночью (дитё уже спит, а интересно жеж чего он там наделал!).
Судя по первому фото, у Вас нет экранировки от светодиода к фотодиоду. Большинство материалов и особенно пластмасс для ИК-диапазона - прозрачны, почти "полностью". Не в курсе? Хорошо помогает экран из люминиевого скотча трубочкой вокруг фотодиода. Я делал обкатку ПВХ-трубок (термоусадка 4мм) люминиевым скотчем и потом из них уже нарезал трубочки на фотодиоды. Держатся достаточно надежно.
Ну и второе. Какое нагрузочное сопротивление у фотодиода? Оно же будет "выходным" сопротивлением вашего датчика и практически "входным" на АЦП входе дуньки. Согласно даташиту оно НЕ должно превышать 10 килоом .. всего.
У меня на старых датчиках стоит 750кОм и 510кОм .. + программная коррекция показаний. Сейчас сделаны 7шт датчиков с дополнительным обвесом на LM358, у которого первый ОУ работает как повторитель сигнала для уменьшения выходного сопротивления, а второй включен как ОУ с регулировкой усиления до 9-12х (как сумеешь) .. плюсом нога светодиода обрамлена гасящим сопротивлением всего в .. 43 ома, что на 5в дает ток около 87мА при допустимых 100мА (на испытаниях светик почти 30сек держал 304мА). И его выход .. а просто выведен наружу отдельно. Итого имеем 4 контакта: +5в, земля, сигнал с ОУ и нога светодиода "на землю".
Тестирование показало что при 87мА на светодиоде и ОУ на 9х .. фотодиод вполне надежно ловит сигнал на дальностях до 5 метров. А при добавлении гасящего сопротивления в 200 ом (итого 243 = 43 внутри датчика + 200 снаружи) и токе 15мА или около того, даже без усиления (К=1) датчик стабильно выдает около 0.5в (около 100 попугаев АЦП) с расстояний в 1.5-2см от линии. При этом "шумовой" сигнал не превышает 10-15 попугаев без экранирования трубочкой с люминиевым скотчем и 2-3 попугая АЦП с трубочкой.
Не просто, но зато надежно и главное регулируемо. Не просто, ибо вся конструкция датчика собрана в "лего" формат 16х16х8мм вместе с крепежом, светодиодом и регулятором усиления (R=100kOm) второго каскада ОУ. Не просто .. там практически неразъемная "микросборка" под лупой. Но такое решение пока у нас - лучшее.
qwone, не получится там подтормаживать "перед" прямым углом.. там нужны иные подходы. Иначе "быстро" трассу и вовсе не пройти.
Ну да. Или веер датчиков или движение змейкой для широты сканирования. Но это все не для "типичного" подхода программирования в Ардуино.
4. Функция map() использует вещественную арифметику и делает НЕСКОЛЬКО умножений и делений .. рекомендую посмотреть её код. Напомню, что Ардуино UNO, Nano, Pro Mini, Mega2560 не имеют команд для прямой работы с такими числами. Все это делается типовой библиотекой и 1 операция занимает около 2 миллисекунд.
Во-первых, согласно докуметнации map работает с целыми числами:
The map() function uses integer math so will not generate fractions, when the math might indicate that it should do so. Fractional remainders are truncated, and are not rounded or averaged.
Во-вторых, заявленные Вами цифры сильно завышены, на самом деле время выполнения одной из трех арифметических операций составляет примерно 15 мкс, а деления - примерно 50-60 мкс. Хотя, конечно, если их в вычислениях десятки, то это займет определенное время.
Что же касается ПИД, то его наверняка можно переписать на fixed point, что при грамотной реализации сократит время выполнения в десятки раз.
Согласен, подзабыл уже. Все равно там long и это долго, а самое главное что никому не нужно ни разу.
Это map():
long map(long x, long in_min, long in_max, long out_min, long out_max)
{
return (x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min;
}
Имеем 4 сложения-вычитания + умножение и деление. Плюс прием 5 параметров типа long (т.е. через перезапись со стека в регистры и обратно). Грубо по вашей же оценке тактов, тем не менее имеем: 4*16+22+670 + (4 + 5 + 9*4) = около 800 тактов по 62.5нс = 50 микросекунд, вполне терпимо для пары вызовов. В скобках указаны примерные затраты на вызов функции с 5-ю длинными параметрами (5 внутрь + 4 вытаскиваем внутри функции, 1 - передается в регистрах). Можно посмотреть в ассемблере сколько оно займет на самом деле..
Переписать ПИД под фикс. арифметику на long .. не знаю, оно конечно выйдет пошустрее. Ну будет у вас слепой пролет не 6-12 сантиметров, а только 1-2 .. разве от этого легче? :)
нужно переходить на тёплый ламповый аналог.
Критика конечно имеет место быть, но смысл критики без конструктива? насчет плат Teensy или STM - ни разу не видел их на Робофесте. Третий день катали на Робочелендже - там да, там подобные были.
И правильно, что теряется. угол то прямой. Перед прямым углом надо подтормаживать, а то и переходить на самый медленый. И наконец если робот "потерялся", то "должен вращаться" на месте что бы "найтись" и при этом не "найти путь обратно".
ПС: Если вам надо улучшать сцепление, то сапожный клей (клей 88) самое то. Но это куча эксперементов, как мазать и какой толщины слой и за сколько до соревнований это делать. А скорее всего наносить клей паролоновыми валиками на колеса.
Ну, такие эксперименты намного сложнее, чем изготовить самим силиконовые шины. Да и любой резиновый клей со временем на открытом воздухе становится очень жестким, а мазать каждый раз перед соревнованиями - лучше отлить шины.
Насчет притормаживания перед прямым углом - мысль возникала и не раз, но как её реализовать с тремя датчиками? Увы, знаний не хватает, а найти подобную информацию в интернете крайне сложно - везде суют библиотеки, но это не то что нужно. Чтобы дети уверенно знали что и как делать им нужно самим, ручками, прописать весь код, и только потом переходить на использование библиотек.
Думал поставить 5 датчиков, но никак не могу правильно вывести формулу расчета положения линии - работают только крайние и средний датчики, промежуточные выдают положения совершенно не те, что нужно.
P.S. Я сейчас пишу некое "руководство" для конструкторов в возрасте 9-11 лет по САМОСТОЯТЕЛЬНОМУ изготовлению скоростного робота по линии .. но это займет некоторое время и к апрельскому Робофинисту, я конечно же не успею.. планировал выкладку в учебных материалах на сайтах Робофеста и Робофиниста .. но пока не вижу тех, кому это полезно (отзывов на запрос нужна ли такая публикация - пока не увидел)
Было бы интересно взглянуть. Для детей, доступным языком откровенно - ничего нет, приходится все перерабатывать. Особенно что касается связи "Вариант техники + код именно для него". Везде пытаются всунуть сложные математические формулы, физические параметры и прочее.
Слишком сложно для третьеклассников, которые ещё даже дроби не знают, а тут сразу гигантский объем нужно изучить.
Кстати это одна из самых главных причин недолюбливания "Робофестов" и прочих "фестивалей" - для тех кто только начинает - простая гонка по линии уже сложно, а уж давать задания на остановку перед перекрестком, да ещё на скоростном проезде....
По мне - начинающим надо оставить линию, пускай там будут крутые повороты, горки или балка, но безо всяких перекрестков - и на одной линии можно спокойно учиться и учиться. Тем более что вариантов по самим роботам - масса.
Ну, в общем-то да - погорячился слегка. Пересмотрел наши записи и замеры, и оказалось что наша собственная тележка пролетала до 6-8мм трассы вслепую "только так". Видимо оно не так уж и страшно для задач управления. Теплый ламповый аналог - пока ещё оставим для неумех. :)
На Робофесте шортрека - уже есть и вполне себе круто катаются. Мы катались на Нано, ну и что с того?
Какой к-т трения у ваших самодельных (я верно понял?) силиконовых шин? Мягкая микропористая резина с протектором дает к-т поперечного трения в районе 0.72-0.85, для достижимой у меня точности измерений .. не думаю что силикон по ПВХ баннеру даст лучше. Жесткие колеса при большем к-те трения даже предпочтительней - меньше к-т трения качения из-за прогиба шины.
Существуют разные подходы к работе с датчиками. Ваш - далеко не самый удачный.
Дети ведь не попадают на Робофест "в нуля". Нам, чтобы попасть на общероссийские соревнования пришлось поучаствовать на городских, потом заявиться на отборочные областные и только потом нас "пустили" в Москву. К этому времени, все типовые грабли были благополучно оттоптаны не по одному разу. У Вас разве не так?
Внезапно оказалось что "писать книжку" ни разу не проще чем сваять скоростную тележку .. пока добрался до раздела "драйвера - моторы - редукторы - колеса" .. :)
P.S. То, что пишу, к сожалению, тоже не будет содержать "готовых примеров" в виде "вот конструкция и вот к ней готовая программа и комплект настроек". Увы, тут видимо разачарую. Планирую перечислить все типовые грабли при разработке такой тележки и обоснования (простые, понятные для детей - проверка как на своем, так и ещё есть несколько подопытных кроликов) причин их появления и опять же типовые рекомендации по их преодолению. А уж конструкцию и программу - каждый "конструктор в возрасте 9-11лет" будет придумывать и делать самостоятельно. Увы. :)
Какой к-т трения у ваших самодельных (я верно понял?) силиконовых шин? Мягкая микропористая резина с протектором дает к-т поперечного трения в районе 0.72-0.85, для достижимой у меня точности измерений .. не думаю что силикон по ПВХ баннеру даст лучше. Жесткие колеса при большем к-те трения даже предпочтительней - меньше к-т трения качения из-за прогиба шины.
Существуют разные подходы к работе с датчиками. Ваш - далеко не самый удачный.
У нас примерно 15-02 по Шору. Более жесткие наоборот хуже - у них трение намного ниже чем у "прилипающих".
Какой например подход работы с датчиками подскажете? Я сам технарь, программированием волею случая занимаюсь, так что многого не знаю, из того что есть. Пока этот код самый удачныйц из всех что есть. Но увы - прямоугольные повороты...
Думал поставить 5 датчиков, но никак не могу правильно вывести формулу расчета положения линии - работают только крайние и средний датчики, промежуточные выдают положения совершенно не те, что нужно.
Вот прикиньте промежуточный вариант . Линия это граница двух цветов- черного и белого. Для отработки алгоритма нарисуйте трек различного траектории состоящей из двух состыкованых полос, как на автомобильных дорогах, черной и белой. Вот машинка и должна ехать по границе черной и белой полос. Сколько датчиков должно быть ? (!) Четыре. Два впереди - фиксировать ситуацию когда два датчика показывают оба или черное или белое. И два возде ведущих колес - что бы определить мы все же едим на Финиш, или как не странно обратно на Старт. Вот когда отработаете эту методику на различных изломаных треков, то можете перейти движению по линии - виртуально назначая какая сторона Черная, а какая Белая.
Krums, Вы отписались за твердость ваших колес, а я спрашивал за трение по ПВХ баннеру... это как "теплое с мягким". Как "технарю" Вам это должно быть понятно. Мне интересен именно к-т бокового трения колес из силикона. Его несложно измерить в домашних условиях: цепляете свою тележку к "безмену" (динамометру) и смотрите при каком весе колесо начинает смещаться по баннеру трассы (надеюсь есть в доступе). После чего взвешиваете свою тележку и делите вес на динамометре (безмене) на вес тележки. Опыт лучше призвести не менее 12 раз, откинуть оба крайних значения (самое большое и самое малое) и усреднить по 10-и оставшимся.
Этот к-т определяет максимально возможную скорость движения по трассе в поворотах и соответственно предельную крутизну поворота .. т.е. успешное прохождение тех самых 90 градусов.
По датчикам. Тх можно использовать очень по-разному. Какой способ наиболее приемлем .. да фиг его знает, зависит от нескольких факторов, в т.ч. и от ваших предпочтений тоже. :)
1. Датчики можно "превратить" в цифровые и использовать в битовом режиме: 1 - "Черное", 0- "Белое" .. можно использовать типовую формулу, вычисления "отклонения линии от середины тележки". В этом разе, чем больше количество датчиков и чем чаще они стоят по краю линии - тем точнее вычисляется положение.
2. Можно использовать аналоговые значения, ибо линия для аналогового дачтика этот вовсе не "четкая граница", а достаточно расплывчатое пятно. Но. как уже писал - в этом случае датчики надо "калибровать" и приводить их значения к единому стандарту (диапазону). В этом случае можно использовать точно также "много" датчиков, вычисляя отклонение примерно как по вашей формуле (она близка к типовой). Это снова "ещё один map()" что мне кажется дороговатым для скоростного движения
3. Можно реализовать промежуточные "цифро-аналоговые" решения .. их тоже несколько: а) разбить диапазон показаний на несколько градаций вместо черное-белое и привести к цифровым с учетом этого; б) использовать как цифровые, но потом дополнительно уточнять отклонение из аналоговых значений. в) .. ваши и прочие "чумовые" идеи.. :)
.. ну и ещё: на оптимальное количество датчиков влияет как ширина линии трассы, так и способ их обработки в ПО. Есть варианты, когда при вдвое меньшем количестве датчиков можно получить ту же самую точность вычисления отклонения.. Задача поиска "оптимального" количества датчиков в "руководстве" планируется на домашнее, самостоятельное решение. :)
qwone, Датчики возле колес (второй ряд) практически будут диагностировать ситуацию "постфактум" .. типа "пролетели, снимаемся с соревнований". Там есть одно жесткое условие, а именно: тележка все время должна находится на трассе ТАК, чтобы её колеса (точки опоры) были по ОБЕ стороны трассы. Выезд за трассу .. пока-пока. :)
[quote=Arhat109-2]
qwone, Датчики возле колес (второй ряд) практически будут диагностировать ситуацию "постфактум" .. типа "пролетели, снимаемся с соревнований". Там есть одно жесткое условие, а именно: тележка все время должна находится на трассе ТАК, чтобы её колеса (точки опоры) были по ОБЕ стороны трассы. Выезд за трассу .. пока-пока. :)[/quote ]
Датчики возле колес определяют на какой стороне мы находимся и куда едем . Например( Пр-чер Лев -бел) это к Финишу. ( Пр-бел Лев -чер) к Старту :) ( Пр-чер Лев -чер) мы на правой стороне и обратно на белой. Конечно лучше иметь еще и гирокомпас. Да впереди поставить не 2 , а 4 или даже 6 датчиков .Каждая пара на разном растоянии от центра движения машины. Вылет за ближнию пару позволит не потерять линию вообще.
Для подобной конструкции, если ставить датчики возле колес, вполне достаточно иметь три передних датчика. ставить 6 и более уже излишне - терям время при опросе, да и гирокомпас не особо поможет - нужно тогда записывать в память весь пройденный путь, и писать программу для корректировки движения с учетом всех ошибок. Для маленьких это нереально. Нужно что-то попроще. Линейка из 5-6 датчиков п\вполне с этой задачей справится, но тут снова проблема ( лично у меня ) - повторюсь - никак не могу найти или подобрать формулу расчета положения линии. все время получается одно и тоже - первый левый например выдает -250, второй слева выдает уже 250, средний ыыдает ноль, и два правых - 250, 280. Как-то так. ( датичики не подобраны по своим параметрам, пока стоят из кучи. как только формула сработает - можно протестировать все датчики и подобрать подходящие).
Насчет функции map - работает отлично! Без неё моторы работают с постоянными скоростями, в результате имеем рысканье, тем более на прямой. да, потеряем время при опросе данных, но за счет механического действия робота - выигрываем секунды. То есть, если без масштабирования робот рыскает, то максимум где он будет иметь высокую скорость - на поворотах, зато на прямой теряет драгоценные секунды сводя на нет все усилия. Так что пусть лучше функция "съедает" программно доли секунды, пусть будет слепая зона 7-12 мм, но это все равно гарантировано высокая скорость и уверенный проезд по всей линии.
Хочу добавить по два датчика с выносом за пределы линии, но сколько ни бьюсь не могу добиться корректной работы вместе с основным массивом - или работает блок с тремя датчиками, или только эти два. По логике должно быть следующее - "Shood" показывает 1 (линию), робот едет вперед, дополнительные датчики показывают белое поле. как только сработал любой из дополнительных датчкиов - значит перед нами крутой поворот, и робот должен поворачивать в сторону сработавшего датчика. Оба датчика показали черное - перед нами перекресток - "Старт" или "Финиш" . Но на практике получается следующее - робот едет, но через пару секунд теряет линию и крутится на месте.
Извините, ваш робот ВСЕГДА подъезжает к перекрестку СТРОГО по линии, так чтобы ОБЕ стороны датчиков сработали ОДНОВРЕМЕННО (оба датчика показали черное - перекресток)? А если нет, то чем отличается перекресток от крутого поворота для робота? Наш, на четверть финале, так и решил и поехал в крутой поворот (и ведь успел зараза!) вместо прямого движения через перекресток. :)
P.S. особенно интересно в свете "6-12мм вслепую" и совсем интересно для "евротрасс" шириной всего 15мм :)
Ну и по вашим исканиям формулы. Она - типовая и легко выводится для случая цифровых датчиков, где-то встречал и в Сети тоже, но уже не помню. Для вашего подхода - выше описан случай 2. Без предварительной калибровки ( map() на каждый датчик) этот подход неприменим. мне так видится. Найдете решение - отпишитесь, добавлю в руководство, если Вы не против. :)
P.S. и ещё: 10-12мм вслепую - это достаточно много, а с map() на каждый датчик для 5шт - может оказаться и фатальным для линий шириной в 20мм (Робофест). Дело в том, что при резком развороте тележки, круговая скорость перемещения блока датчиков значительно выше чем при рыскании по трассе и даже наши 6-8мм не позволили нам применить "автонастройку" датчиков тем способом, который показан в видео отборочного тура уральцев (но там у них машинка шустрее в несколько раз, не Atmel). Блок датчиков при "среднем" вращении проскакивал линию шириной 20мм "только так" двигаясь поперек неё. Пришлось ребенку оставлять "ручную настройку".
P.P.S. перечитал сообщения .. "по трассе Робофеста шел уверенно" .. Краснодар? Уверенно (это первая квалификация) прошло всего 3 тележки из 35. :)
Извините, ваш робот ВСЕГДА подъезжает к перекрестку СТРОГО по линии, так чтобы ОБЕ стороны датчиков сработали ОДНОВРЕМЕННО (оба датчика показали черное - перекресток)? А если нет, то чем отличается перекресток от крутого поворота для робота? Наш, на четверть финале, так и решил и поехал в крутой поворот (и ведь успел зараза!) вместо прямого движения через перекресток. :)
P.S. особенно интересно в свете "6-12мм вслепую" и совсем интересно для "евротрасс" шириной всего 15мм :)
У нас датчики стоят строго над линией ( в том варианте что здесь выложил), так что робот видит только линию, без перекрестков. с шириной 22-25 мм проблем никаких, с вариантом линии 15 мм есть вылеты на повортах, но на "Евро" линии перекрестков нет, так что единственная проблема - с прямыми углами, потому и хочу поставить 5 датчиков.
Упс. "только над линией" как-то не подумалось даже и вовсе. А зачем тогда "больше датчиков"? А если не только "над" - не есть решение? :)
Ещё почитайте это: http://arduino.ru/forum/proekty/lego-kirpich-iz-mega2560?page=3, начиная с поста 124 - это вместе с нашей (пере)подготовкой и с поста 154 - собственно наши приключения на Робофесте. Может что подправите.. :)
P.S. и ещё: 10-12мм вслепую - это достаточно много, а с map() на каждый датчик для 5шт - может оказаться и фатальным для линий шириной в 20мм (Робофест). Дело в том, что при резком развороте тележки, круговая скорость перемещения блока датчиков значительно выше чем при рыскании по трассе и даже наши 6-8мм не позволили нам применить "автонастройку" датчиков тем способом, который показан в видео отборочного тура уральцев (но там у них машинка шустрее в несколько раз, не Atmel). Блок датчиков при "среднем" вращении проскакивал линию шириной 20мм "только так" двигаясь поперек неё. Пришлось ребенку оставлять "ручную настройку".
P.P.S. перечитал сообщения .. "по трассе Робофеста шел уверенно" .. Краснодар? Уверенно (это первая квалификация) прошло всего 3 тележки из 35. :)
Нет, не Краснодар, Пенза. Как уже писал - в Москве мы не проехали в первый день, хотя и освещение выключили, но глянцевая линия, + усталость детей сделали свое дело. Всего-то оставалось - повысить порог датчиков, но в том варианте это 12 условий, и в каждом по три датчика....Потому и мучаю нынешний код.
Ну я бы вам предложил опробовать принцип "тараканьи усы" под углом 90-120 градусов между собой и по 3 (три) датчика на ус. Ближайшие датчики на усах следят за линией, а дальше если линия сбилась или поворот на 90 градусов. Усы длиной примерно в 1-0,5 корпуса машины. Попробуйте на рамке сделать . Ну как лозоходы воду ищат. Ну и вывод вместо моторов на светодиоды правая вперед,правая назад,левая вперед,левая назад и ШИМ их регулировка яркостью. Вот так вы отработаете геометрию усов и размещение датчиков на них.
Упс. "только над линией" как-то не подумалось даже и вовсе. А зачем тогда "больше датчиков"? А если не только "над" - не есть решение? :)
Ещё почитайте это: http://arduino.ru/forum/proekty/lego-kirpich-iz-mega2560?page=3, начиная с поста 124 - это вместе с нашей (пере)подготовкой и с поста 154 - собственно наши приключения на Робофесте. Может что подправите.. :)
Больше датчиков нужны как раз для более сложных трасс - там где есть перекрестки или инверсия. Ну и обеспечат отсутствие вылетов на очень крутых поворотах.
А по Москве - остается только добавить - заниматься организацией подобных мероприятий должны не "продавцы" от Амперки, а технари! У нас ребятёнок вобще не хотел идти на следующий день - "что там делать, все равно не проедем"... однако в топ-10 попали.
Насчет того чтоб объяснять четвероклассникам тонкости и нюансы - это надо делать, и обязательно. Если бы они ещё имели привычку записывать все эксперименты что делали с кодом - было бы ещё лучше, однако увы - бесполезно. Сколько ни бьюсь - не работает и все.
Ну я бы вам предложил опробовать принцип "тараканьи усы" под углом 90-120 градусов между собой и по 3 (три) датчика на ус. Ближайшие датчики на усах следят за линией, а дальше если линия сбилась или поворот на 90 градусов. Усы длиной примерно в 1-0,5 корпуса машины. Попробуйте на рамке сделать . Ну как лозоходы воду ищат. Ну и вывод вместо моторов на светодиоды правая вперед,правая назад,левая вперед,левая назад и ШИМ их регулировка яркостью. Вот так вы отработаете геометрию усов и размещение датчиков на них.
В таком случае имеет смысл делать массив датчиков, в виде той же рамки - тогда положение линии будет гораздо четче. Вариантов масса, но есть одно "но" - как это реализовать программно? )))) Вся суть не в техническом решении,а в програмном. Поэтому и слетают роботы - нет хорошей программы)
В таком случае имеет смысл делать массив датчиков, в виде той же рамки - тогда положение линии будет гораздо четче. Вариантов масса, но есть одно "но" - как это реализовать программно? )))) Вся суть не в техническом решении,а в програмном. Поэтому и слетают роботы - нет хорошей программы)
Скорее нет хороших программистов. Или у вас нет возможности их нанять. Программисты на Ардуино "деревянные", вот и программы выходят тупые. А так ресурсов хватит, даже написать программу не лезть в ассемблер.
ПС: Я не берусь, так как надо как минимум иметь машинку и место для отработки программы.
В таком случае имеет смысл делать массив датчиков, в виде той же рамки - тогда положение линии будет гораздо четче. Вариантов масса, но есть одно "но" - как это реализовать программно? )))) Вся суть не в техническом решении,а в програмном. Поэтому и слетают роботы - нет хорошей программы)
Скорее нет хороших программистов. Или у вас нет возможности их нанять. Программисты на Ардуино "деревянные", вот и программы выходят тупые. А так ресурсов хватит, даже написать программу не лезть в ассемблер.
ПС: Я не берусь, так как надо как минимум иметь машинку и место для отработки программы.
Дык, и я о том же) а нанять - кто пойдет учить на ставку педагога? Все хотят много и сразу, молодым вобще ничего не нужно. Так и теряем возможность вырастить думающих людей, а не "шахтеров".
"..Если бы они ещё имели привычку записывать все эксперименты что делали с кодом - было бы ещё лучше, однако увы - бесполезно. Сколько ни бьюсь - не работает и все.."
Ну .. тут не знаю и не могу согласиться с Вами. Наш исписал уже "общую тетрадку А4" своими экспериментами с прошлого года, начиная с первых построений схем из конструктора Знаток, систематизации наших аккумуляторов Ni-MH, которые ему отдавались как убитые в фотоаппаратах, систематизации наших DC-моторов (их около 20шт) от разного рода детских игрушек, запись сколько и каким проводом он перематывал свои 2 мотора, процесс центровки якоря и потом замер их ТТХ "что получилось" в итоге (к слову, получилось не ахти, но это его, ребенкины эксперименты!). Все его "эксперименты" тщательно записаны им самим, в т.ч. и те, которые он проводил в мое отсутствие. Это вообще - первое, чему его обучал: изменил что-то - запиши что изменил и как было. Не записал? Молодец, начинай ВСЁ с начала.. пару раз хватает чтобы понять важность ведения дневника экспериментатора. Опять же, примеры великих Вам в помощь - Тесла .. это ведь исключительно благодаря ему и его дневникам мы имеем сейчас все то, что имеем! Более 10 тысяч патентов, в т.ч. и на люминесцентные лампы (запатентованы даже раньше "обычных"), сотовые телефоны и т.д. :)
И при подготовке полно записей: комплект настроек .. изменил это .. время проезда, рыскание, вылет на развороте, перекрестке, вывод. Страниц 5-6 точно есть. :)
А где Вы соревновались на третий день? В robotChallenge? Как туда попали? Вроде бы записать команду можно было только на одно соревнование .. знали бы, наверное тоже бы поучаствовали, но .. не знаю. Наш после Москвы отдохнул только вчера. Только вчера он полноценно сел читать регламент РТК и сделал первую тележку-вездеход на базе нашего "Ардуино как Лего".. поехала, но пока криво. :)
По организации. Не знаю, может у Вас больше соревновательного опыта, но то что я увидел там, как все было организовано и то что я вижу у нас, тут в Новосибирске - небо и земля. Достаточно сказать, что, как понимаю, только из-за хамского отношения к детям некоторых "организаторов" в этом году у нас представительность соревнований упала примерно раза в 2, а то и больше. Так на отборочных нас оказалось всего .. двое, против 8 команд в прошлом году, а у леговцев всего 10-12 команд против 23-25 в прошлом году тоже. Так,имея 6 квот по Hello Robot, Arduino, Новосибирск смог выставить только 1(ОДНУ) нашу команду ..
я уж молчу за то что "опоздали там, опоздали тут, розетки подведены только к половине столов, бейджики на столы раскладывают в твоем присутствии, на ходу, питание половины участников забыто вовсе (кто успел, тот и съел), карантинные столы в зоне свободного доступа "друзей" (студентов) судей и помощников (Вау, беря в руки машинку с карантина, смотри какого робота кто-то сделал), наборы маек, блокнотиков, ручек раздавали в процессе награждения тем, кто на него остался, а не ДО начала соревнований всем, как тут (да ещё и с обменом по размерам!) и т.д. .. деревня одним словом (и сколько не пытаюсь доказать организаторам что надо иначе - бесполезно!). Увы.
И совсем уж молчу за выложенное видео финального заезда в младшей группе с участием дяди-тренера по распоряжению организатора, не взирая ни на какие протесты мои или зрителей .. вот такая она у нас "младшая группа" от 40 лет. :)
"Дык, и я о том же) а нанять - кто пойдет учить на ставку педагога? Все хотят много и сразу, молодым вобще ничего не нужно. Так и теряем возможность вырастить думающих людей, а не "шахтеров".
"
Это да. Пробовал пойти в "неформальную организацию" развить кружок "Ардуино" .. ставка 3тыс. руб. .. в месяц. Ну куда это? В школах, как понимаю "то же самое".. зато писанины отчетов .. "мама не горюй", впечатлился когда ознакомился.
Кстати, черканите мне на arhat109@mail.ru, вышлю вам текущий черновой вариант своего "руководства" на прочитку вашими ребятишками и их отзыв. Предупреждаю сразу - это сильно черновой вариант, с ошибками, кривыми оборотами и т.п. Писано "на скорую руку" с небольшой правкой по рекомендации тренера HRAsh-19.
А где Вы соревновались на третий день? В robotChallenge? Как туда попали? Вроде бы записать команду можно было только на одно соревнование .. знали бы, наверное тоже бы поучаствовали, но .. не знаю. Наш после Москвы отдохнул только вчера. Только вчера он полноценно сел читать регламент РТК и сделал первую тележку-вездеход на базе нашего "Ардуино как Лего".. поехала, но пока криво. :)
Да, мы в Робочелендже участвовали. Регистрация была там, же, на сайте Робофеста, а вобще если что - вот ссылка - http://rus-robots.ru
"Дык, и я о том же) а нанять - кто пойдет учить на ставку педагога? Все хотят много и сразу, молодым вобще ничего не нужно. Так и теряем возможность вырастить думающих людей, а не "шахтеров".
"
Это да. Пробовал пойти в "неформальную организацию" развить кружок "Ардуино" .. ставка 3тыс. руб. .. в месяц. Ну куда это? В школах, как понимаю "то же самое".. зато писанины отчетов .. "мама не горюй", впечатлился когда ознакомился.
https://vk.com/cmitnsk а сюда не пробовали? вроде бы там нужен преподаватель.
Это наш "академгородок" .. очень далеко от меня. Новосибирск - был третий город по размерам в СССР. после Москвы и Киева. :)
посмотрел ваши видео. Около 9 секунд на домашней трассе - очень неплохо, но регулярно фиксируются вылеты на втором развороте. Это неудовлетворительно и на соревнованиях было бы зафиксировано как "ошибка" и непрохождение трассы. Скетч, посмотрю позже, сейчас немного занят .. но сам факт использования датчиков только внутри линии - говорит за то что вариантов программы и схемотехники - просто "много". Этим и интересен "шорт-трек". Кстати, не пробовали гонять в обратном направлении? Трасса далеко не одинакова (и не проста) .. наш в обратную сторону дома ехал на порядок лучше.
посмотрел ваши видео. Около 9 секунд на домашней трассе - очень неплохо, но регулярно фиксируются вылеты на втором развороте. Это неудовлетворительно и на соревнованиях было бы зафиксировано как "ошибка" и непрохождение трассы. Скетч, посмотрю позже, сейчас немного занят .. но сам факт использования датчиков только внутри линии - говорит за то что вариантов программы и схемотехники - просто "много". Этим и интересен "шорт-трек". Кстати, не пробовали гонять в обратном направлении? Трасса далеко не одинакова (и не проста) .. наш в обратную сторону дома ехал на порядок лучше.
вылеты вылечились простым протиранием колес - когда снимали не обратили внимание что колеса были заляпаны грязью, соответственно и сцепления никакого. Протерли - все норм.
Да и вылет как раз потому что разгон на прямой слишком сильный - стоило снизить - и норм. В обратную сторону так же.
Глянул бегло скетч .. Ай-я-яй .. все настроечные константы прописаны .. прямо в коде, собственно и пример тут такой же. Перенастраивать такой код - достаточно кропотливая работенка для дитенков. А создать блок настроечных переменных и использовать их - почему не?
У нас была спец. процедура setupSpeed() (тоже Ардублок), в которую были вынесены все настроечные параметры и менялись они только в одном месте. Более того! Как только поехали за 14сек, сразу же клонировали процедуру и переименовали старую в setupSpeed14() .. и продолжили далее и так появились setupSpeed10(), setupSpeed9() .. надо ехать медленее? Да не проблема! В главном setup() изменил вызов на другую настроечную процедуру и все дела..
Ну и по функциям a(), b(), c(), d() .. по большей части они одинаковы с небольшими изменениями .. тоже легко объединяется через использование параметров к функции. Ардублок не имеет? Не проблема. Делает глобалы со спец. названием и присваиваем им значения перед вызовом, а внутри функции используем эти глобалы вместо настоящих переменных. По завершению вызова переприсваиваем обратно взад... :)
по сути там реализован конечный автомат состояний, но его можно и нужно рисовать иначе. В таком виде - достаточно сложно понять что делается и при каком наборе условий - соответственно править детишкам "на бегу" - возможность исправить что-то не то.
Похоже мой дитенок ленивее ваших .. он до этих моментов дотумкал сам, когда надоело шариться по коду Ардублока в поиске "где же я забыл исправить ещё".. остальное позже. впрочем, уже писал выше, перечитайте. Но у нас и прорамма была не в пример сложнее: около 1000 строк после Ардублока. У Вас - слишком примитивная работа с датчиками, отсюда и проблемы на трассе соревнований, плюс сложность перенастройки отписал выше, а в пылу соревнования - накладывает свои ограничения.
Если бы ещё знать как все это делать))) Умом понимаю что нужно выносить в один параметр, и там только менять,а на практике - черт ногу сломит как все реализовать) Даже простой счетчик поворотов - и то уже проблема.
Мда...поневоле позавидуешь нынешним школьникам - все что нужно есть, а я свой первый компьютер увидел около 20-и лет отроду)))) и даже и не знал что такое информатика, и с чем её едят)
Зато технические реализации - пожалуйста, любые, и на ура.
Видео последних тренировок - добавлены два датчика, отслеживающие прямой угол. Пока без проблем, посмотрим что будет дальше)
https://yadi.sk/mail/?hash=pe%2BBoA3U59CGFrt00JdFGQo%2Bz3JOXcl60wLp8MW9LV4%3D
Похоже, что самое оптимальное размещение датчиков - "на жопе" машинки.
Похоже, что самое оптимальное размещение датчиков - "на жопе" машинки.
С чего такое мнение вдруг?)
Похоже, что самое оптимальное размещение датчиков - "на жопе" машинки.Ставятся рядом два датчика буквально впритирку. Нормально они должны фиксировать черную линию. При изменении положения линии будет переход Черный- Белый. Где раньше произошел сдвиг , то в ту сторону и сместилось. Так что идет компенсация, чтобы оба датчика стали черными.
ПС. Так ближе к оси ведущих колес. Это и есть оптимальное расположение. Ближе , но не на самой оси.
Если вы про дополнительные датчики - то да, такой вариант тоже очень хороший, но только с теми доп.датчиками что впереди стоят - тогда позиция робота определяется совершенно точно! Да, тот робот что на видео имеет вынос датчиков сильно вперед, из-за конструктива не можем перенисти немного ближе к колесам - робот срезает углы. Но с другой стороны - он не теряет линию, идет ровно, так что... ))))
Посмотрел видео. Очень медленно. С такой скоростью может ехать и самая простейшая программа и ловить такие повороты. Повторюсь ещё раз:
1. Датчики без обработки ошибок, с жестко заложенными порогами срабатываний в проверках -- крайне примитивный вариант и требует тщательной настройки на конкретные условия проведения соревнований. Малейшие изменения в этих условиях (освещенность, отражение, ширина линии и т.д.) и всё надо перенастраивать полностью и заново. Тренировочного времени может банально не хватить. Собственно это - главная причина того что на соревнованиях Робофест-2017 такое количество "не поехавших вовсе".
А у Вас ещё и дополнительная проблема: Вы за время принятия решения (1 проход loop()) снимаете показания датчиков несколько раз, каждый раз заново в новом условии или управляющем map() .. даже парамиллисекунд при скоростном движении - это НОВОЕ место на трассе и новое значение. Получается что решение принимается по одному показанию - "плавный поворот", а управляющее воздействие в map() по новому показанию датчиков.
1. Показания датчиков надо усреднять по нескольким значениям. Тут есть несколько вариантов: брать 2-3-4-5 замеров складывать и делить на количество замеров - среднее по замерам, можно считать "бегущее среднее с накоплением" это программно проще и быстрей, но будет несколько "затягивать" показания. Насколько? Зависит от частоты замеров (те самые 4-6-8-10-12мм вслепую).
2. Показания датчиков надо очищать от засветки программно (часто советуют фильтр Кальмана, но он достаточно сложен), кроме принятия технических мер (экранирование).
3. Показания датчиков надо очищать от взаимовлияния. Оно сильно зависит от схемы датчика, точнее его выходного сопротивления.
В любом случае, это требует той или иной калибровки датчиков на конкретном поле ..
Поймите, что то, что хорошо едет дома - вовсе не показатель. Для проверки устойчивости, напроситесь в пару кружков или мест где проходят занятия на "попробовать" и попробуйте проехать с той программой, которая у вас хорошо едет дома без настроек. Мы, до всех этих изменений программы, тоже дико удивлялись почему дома едет "на ура", а скажем в ближайшей школе с инженерным классом, где есть поля и занятия - упс. теряет линию местами, а в том же инженерном Лицее НГТУ .. и вовсе не видит линию! И нам верно делали замечания наше новосибирское руководство после наших V-городских соревнований: "ехать быстро - это полдела. Главная задача - ехать надежно, а у вас это не так. Учитесь". :)
P.S. Ну и ещё. Ваше видео наглядно показывает что для скоростного движения на крутых поворотах ваших 3-х датчиков строго "над" линией - категорически не хватает. Даже при такой медленной езде, датчики "вылетают" далеко за линию и фактически перестают управлять тележкой. Ибо ваш подход дает изменение управляющего сигнала только по факту изменения уровня датчиков .. когда все датчики "видят одинаково белое" - ваше управления сводится к простому алгоритму: "вращаемся на месте пока не найдем линию". Для его реализации датчики и вовсе не требуются, только на отлов "нашли линию". Что у вас и происходит на видео.
Так то оно все правильно сказано, надо делать программу получше. Были бы знания)
Пробовал пойти в "неформальную организацию" развить кружок "Ардуино" .. ставка 3тыс. руб. .. в месяц. Ну куда это? В школах, как понимаю "то же самое".. зато писанины отчетов .. "мама не горюй", впечатлился когда ознакомился.
Вести уроки на ютубе наверняка повыгодней будет.
Отсюда: за 1 мсек ваш робот должен проезжать около 3мм трассы. у нас НЕ использовался ПИД вовсе, и вообще всё управление делалось на "табличном конечном автомате". Самый быстрый способ управления для 8/16 разрядных МК. Не надо ничего "считать" вовсе. :)
Самые правильные выводы.
Мне кажется при данных скоростях вам надо обратиться в первую очареть к аналоговой логике а уже ее действия корректировать ардуинкой!
Можно вообще сигнал от крайних датчиков напрямую через транзисторы импульсом на двигатели подавать. Подобие рефлекторной реакции организма на ожог.
Подниму тему в связи с очередной подготовкой к гонкам ..
У кого-нибудь за это время какое-то продвижение в программной реализации - есть?
Наша команда пока железо собирает.
Про датчики линии. Если не знаешь, как бороться с помехами нужно их возглавить. Для этого приклеили кусочек светодиодной ленты 6500К. Давайте обсудим это решение.
Про датчики линии. Если не знаешь, как бороться с помехами нужно их возглавить. Для этого приклеили кусочек светодиодной ленты 6500К. Давайте обсудим это решение.
Присоединяюсь. Если датчик "ИК", то какой ему прок от такой засветки, да и вообще, его разве волнует какая-то "засветка" акромя своего светодиода? Может источник ваших помех в ином месте? Внешнего отраженного ИК фона от баннера трассы - практически ни разу не наблюдал. Сколько засветишь - столько и кажет. Причем гоняем и при дневном свете и при обыкновенном и люминисцентном .. и даже в полной темноте ночью (дитё уже спит, а интересно жеж чего он там наделал!).
Судя по первому фото, у Вас нет экранировки от светодиода к фотодиоду. Большинство материалов и особенно пластмасс для ИК-диапазона - прозрачны, почти "полностью". Не в курсе? Хорошо помогает экран из люминиевого скотча трубочкой вокруг фотодиода. Я делал обкатку ПВХ-трубок (термоусадка 4мм) люминиевым скотчем и потом из них уже нарезал трубочки на фотодиоды. Держатся достаточно надежно.
Ну и второе. Какое нагрузочное сопротивление у фотодиода? Оно же будет "выходным" сопротивлением вашего датчика и практически "входным" на АЦП входе дуньки. Согласно даташиту оно НЕ должно превышать 10 килоом .. всего.
У меня на старых датчиках стоит 750кОм и 510кОм .. + программная коррекция показаний. Сейчас сделаны 7шт датчиков с дополнительным обвесом на LM358, у которого первый ОУ работает как повторитель сигнала для уменьшения выходного сопротивления, а второй включен как ОУ с регулировкой усиления до 9-12х (как сумеешь) .. плюсом нога светодиода обрамлена гасящим сопротивлением всего в .. 43 ома, что на 5в дает ток около 87мА при допустимых 100мА (на испытаниях светик почти 30сек держал 304мА). И его выход .. а просто выведен наружу отдельно. Итого имеем 4 контакта: +5в, земля, сигнал с ОУ и нога светодиода "на землю".
Тестирование показало что при 87мА на светодиоде и ОУ на 9х .. фотодиод вполне надежно ловит сигнал на дальностях до 5 метров. А при добавлении гасящего сопротивления в 200 ом (итого 243 = 43 внутри датчика + 200 снаружи) и токе 15мА или около того, даже без усиления (К=1) датчик стабильно выдает около 0.5в (около 100 попугаев АЦП) с расстояний в 1.5-2см от линии. При этом "шумовой" сигнал не превышает 10-15 попугаев без экранирования трубочкой с люминиевым скотчем и 2-3 попугая АЦП с трубочкой.
Не просто, но зато надежно и главное регулируемо. Не просто, ибо вся конструкция датчика собрана в "лего" формат 16х16х8мм вместе с крепежом, светодиодом и регулятором усиления (R=100kOm) второго каскада ОУ. Не просто .. там практически неразъемная "микросборка" под лупой. Но такое решение пока у нас - лучшее.
Привезем на Робофинист - покажем. :-)