roboforum.ru

Предлагаю обсудить такой вариант управления шасси:

1. Создаём очередь из команд вида (Ls,Rs,Lf,Rf,T), где *s,*f - начальные и конечные скорости вращения соответственно левого и правого колёс, T - желаемое время выполнения команды.
2. Разрешено докладывать команды в очередь, обнулять очередь, узнавать размер очереди и расчетный % выполнения текущей команды.
3. Если по обратной связи видим, что не вписываемся в заданную траекторию, тогда снижаем скорости, увеличивая время манёвра и всё равно выполняем маневр по заданной траектории.
4. При включении специального режима - можно автоматически сглаживать переходы между командами, типа если с места подали команду поехать на полном ходу вперед и больше команд нету - можем её преобразовать в 3 команды - разогнаться по прямой, проехать, аккуратно замедлиться.

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

Кто что может сказать по поводу недостатков такого подхода и или еще что-то дельное?

По итогам думаю сделать реализацию такого протокола в рамках своего модуля GATE-A8D8M2 и выложить исходники.

мне нравится.
а для бота надо функцию написать, ваще класс будет!

Небольшое замечание. Колеса у нас крутятся не только вперед но и назад.

• 1. Вариант (Ls,Rs,Lf,Rf,T)
  где *s,*f - начальные и конечные скорости вращения соответственно левого и правого колёс,
  отрицательные *s,*f значения реверс,
  T - желаемое время выполнения команды.
• 2. Вариант (Ls,Rs,Lf,Rf,Ld,Rd,T)
  где *d направление вращения 0 или 1.

может так?

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

/**
    * \example commands_list
    * command regexp:
    * \code
    * ( ((M|R|L)( ((F|S|B)[0-9A-F]{2}) | (C[0-9A-F]{4}) | (G[01]) )) | (D[0-9A-F]{2}) )
    * \endcode
    * Commands list:
    * \code
    * MFxx    < оба мотора вперед с xx скоростью
    * MSxx    < оба мотора тормозят с xx мощностью
    * MBxx    < оба мотора назад с xx скоростью
    * MCxxxx   < оба мотора пройдут xxxx расстояние
    * MGx     < разрешение выполнить комманды для обоих моторов
    * RFxx    < левый мотор вперед с xx скоростью
    * RSxx    < левый мотор тормозит с xx мощностью
    * RFxx    < левый мотор назад с xx скоростью
    * RCxxxx   < левый мотор пройдет xxxx расстояние
    * RGx     < разрешение выполнить комманды для правого мотора
    * LFxx    < левый мотор вперед с xx скоростью
    * LSxx    < левый мотор тормозит с xx мощностью
    * LBxx    < левый мотор назад с xx скоростью
    * LCxxxx   < левый мотор пройдет xxxx расстояние
    * LGx     < разрешение выполнить комманды для левого мотора
    * Dxx     < опросить датчик xx
    * \endcode
    */

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

2SkyStorm: разумеется, отрицательные значения для скоростей допустимы

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

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

avr123.nm.ru писал(а):DeaD, а твой протокол как то согласуется с тем что применяют производители модулей для роботов ? Девантеч и прочие ?

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

У робоклуб-овского контроллера аналогичный ВРОДЕ протокол. А импортные я не изучал так как они мне не нужны, но у них же они есть и дока есть наверняка. Иначе как бы они модули в "кучку" собирали ?!

а почму мы рулим скоростью ? по идее же регулировать то мы должны перемещение... может задавать угол поворота, и время выполнения задания? зная радиус колеса мы посчитаем перемещение в основном "моске".. а контроллер шасси проедет сколько нужно, рассчитет ШИМ, замедления при пуске\останове.... если уж лезти в управление верхнего уровня ...

avr123.nm.ru писал(а):У робоклуб-овского контроллера аналогичный ВРОДЕ протокол. А импортные я не изучал так как они мне не нужны, но у них же они есть и дока есть наверняка. Иначе как бы они модули в "кучку" собирали ?!

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

Я же говорю таких финтов ни у кого не видел, поэтому если видели - укажите где

Добавлено спустя 2 минуты 50 секунд:

Duhas писал(а):а почму мы рулим скоростью ? по идее же регулировать то мы должны перемещение... может задавать угол поворота, и время выполнения задания? зная радиус колеса мы посчитаем перемещение в основном "моске".. а контроллер шасси проедет сколько нужно, рассчитет ШИМ, замедления при пуске\останове.... если уж лезти в управление верхнего уровня ...

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

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

кхм... я бы не сказал.. вот например мы задали скорость 10 об\мин... а колесо нагружено чем нибудь, оно не могет крутиться быстрее 7 оборотов.. а мы наверху посчитали что крутили колесом 1 секунду с такой скоростью... чтобы исправить ситуацию нужно чтобы привод шасси выругалс вверх что мол нимагу твое задание выполнить... получается только 7 оборотов.. верх принял посчитал что нужно делать отправил... дак зачем нагружать передачами? посчитать скорость из поворота и времени на поворот пара тактов... и обратна связь по положению тут есть.. иначе нада будет в верхние мозги еще и данные с энкодеров слать чтобы они у себя обр связть по положения организовали... да и что нагружать то контроллер? ШИМ аппаратный скорее всего, кроме почты и записи регистров таймеров, да обработки данных энкодеров нечего делать больше контроллеру.. пускай чуток арифметики на себе гоняет ... я кстати накидал тут драйвер.. два Н моста.. на полевиках... + логика.. на вход ШИМ и направление.. забирает 2 вывода на 1 движок... ща в электронике выкину ...

Duhas писал(а):кхм... я бы не сказал.. вот например мы задали скорость 10 об\мин... а колесо нагружено чем нибудь, оно не могет крутиться быстрее 7 оборотов.. а мы наверху посчитали что крутили колесом 1 секунду с такой скоростью... чтобы исправить ситуацию нужно чтобы привод шасси выругалс вверх что мол нимагу твое задание выполнить... получается только 7 оборотов.. верх принял посчитал что нужно делать отправил... дак зачем нагружать передачами?

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

Duhas писал(а):посчитать скорость из поворота и времени на поворот пара тактов... и обратна связь по положению тут есть.. иначе нада будет в верхние мозги еще и данные с энкодеров слать чтобы они у себя обр связть по положения организовали... да и что нагружать то контроллер? ШИМ аппаратный скорее всего, кроме почты и записи регистров таймеров, да обработки данных энкодеров нечего делать больше контроллеру.. пускай чуток арифметики на себе гоняет ... я кстати накидал тут драйвер.. два Н моста.. на полевиках... + логика.. на вход ШИМ и направление.. забирает 2 вывода на 1 движок... ща в электронике выкину ...

Не вижу особого смысла перегружать контроллер, лучше пусть он параллельно сервами рулит и данные с АЦП и i2c пересылает.

ладно .. каждому свое ... просто эсли посмотреть с точки зрения дисциплин ТАУ и приводов роботов ваш подход не правилен)

просто эсли посмотреть с точки зрения дисциплин ТАУ и приводов роботов ваш подход не правилен)

А какой правилен?

Duhas писал(а):ладно .. каждому свое ... просто эсли посмотреть с точки зрения дисциплин ТАУ и приводов роботов ваш подход не правилен)

1. Обоснуйте честно не понял;
2. Вы предлагаете существенно сузить количество разных доступных маневров, существенно усложнив протокол (введя разные команды для разных движений), но при этом перенести вычисление кликов и скоростей вниз, так что ли?