roboforum.ru

=DeaD= писал(а):Ну как в чем - мы аппроксимируем траекторию отрезком.

хм, понятно.
ты таких тележек не делал случаем?

GraphD писал(а):ты таких тележек не делал случаем?

В процессе как раз

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

2All

Всем спасибо. Хотя вопрос и был задан не совсем точно - ответы оказались очень полезными!

Подскажите пожалуйста,каковы результаты изысканий? Щас тоже приступил к подобной теме, правда у меня имеются энкодеры. Но движение по не прямой линии от этого намного проще не стало.
Собственно, принимая, что если скорости колес различны, телега будет двигаться по кругу с радиусом
D*V1
______
V1-V2
, где D это база, а V1 и V2 это линейные скорости колес, ражиус поворота относительно некой точки окажется равным этой величине. Для радиуса поворота 10м, который можно считать приближенно прямой, на длине пути 30 см разница хода колес должна быть 4мм, а разница хода на одну прорезь энкодера 7,5 мм. Получается, что прямой ход можно получить только подсчетом времени, за которое колеса поворачиваются на прорезь (одну или несколько) энкодера. Сейчас думаю о реализации алгоритма подсчета времени. Хочется иметь некое усреднение времени за 2 или 4 сектора энкодера- его можно будет реализовать простой суммой и соответствующим шифтом вправо. Но получается, что если одно колесо движется очень медленно, а другое быстро ( например, я вычерчиваю фигуру), одно колесо пройдет например 3 сектора, а другое 1-ничего не усреднишь. И собственно получается, что количество секторов развязано в алгоритме с временем. То есть непонятно, какой формат данных сделать для рисования фигур и прямой езды- их хотелось бы совместить, а в моём решении придется городить огород для каждого режима. Может у кого есть инфа по этой теме? Желательно на асм, но Си тоже уже онемногу читаю, вьезжаю.

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

steel_monkey писал(а):То есть непонятно, какой формат данных сделать для рисования фигур и прямой езды- их хотелось бы совместить

Я предлагал уже формат такой:
t,lvs,rvs,lvf,rvf - время выполнения команды в базовых "тиках", скорость левого колеса в кликах энкодера за 1 "тик" в начале движения, скорость правого колеса за 1 "тик" в начале движения и те же скорости но в конце движения.

Единственная проблема - обеспечить, чтобы начальные скорости команды i были равны конечным скоростям предыдущей команды i-1, ну и достаточно малые клики энкодеров и "тики".

Очевидно этот формат команды позволяет на ходу выполнять почти любые сложные маневры и реализовать этот исполнительный контроллер для этого формата тоже достаточно просто, единственная сложность - надо будет реализовывать очередь команд в МК.

А зачем введены конечные значения? Или предполагается плавное изменение скорости вращения?

steel_monkey писал(а):А зачем введены конечные значения? Или предполагается плавное изменение скорости вращения?

Конечно, иначе все маневры будут рубленными и с остановками.
А тут можно и плавный старт и остановку обеспечить и любые виды маневров "с ходу".