roboforum.ru

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

Здесь же можно обсуждать нужность тех или иных изменений.

Точно нужны:
1. Пофиксить косяк с поддержкой полных команд PinModeF0=Adc (сейчас вроде работает только PMF0=A)
2. Обеспечить команду перегрузки контроллера (чтобы можно было без механического вмешательства обновлять прошивку, если старая жива); реализовано!
3. Обеспечить нормальный вывод версии прошивки ORFA;
4. Реализовать таймер на выполнение команды для движков, чтобы если пропала связь с вышестоящим контроллером по уарту - не приходилось срочно бежать до робота, который пытается заехать на стену реализовано!
5. Добавить поддержку энкодеров в версии для OR-AVR-M128-DS;
6. При старте контроллера не включать сразу сервы в 1500us, а держать их выключенными до явной команды хотя-бы 1 серве.

Может быть будут нужны:
1. Обеспечить поддержку управления движками на OR-AVR-M128-DS в формате сервокоманд (для унификации + получим плавные старты и остановку);
2. Обеспечить поддержку серий команд (чтобы можно было сохранять в контроллере пачки команд и запускать их пакеты на выполнение по командам через UART) - для танцев, ходьбы роботов, готовых комбинаций движений колёсных платформ и т.п.
3. Частный случай пункта 2 - стартовые последовательности команд (выполняющиеся при запуске контроллера).

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

WatchDog для целей контроля связи с ПК (чтобы робот не уезжал на стенку, когда теряет связь с ПК в ходе движения).

W=(N | R,<timeout_ms>) - настроить режим работы WatchDog:
N - выключить,
R - включить с перезагрузкой МК если в течение <timeout_ms> не поступила команда N

N - сбросить таймер WatchDog (эту команду нужно слать с интервалом менее <timeout_ms>, чтобы МК не перезагрузился по таймеру)

Перегрузку МК можно выполнить командой W=R,0

Пока с Vooon'ом решаю, где будем вести репозитарий проекта - приложу файлы и прошивки сюда.

Планируем итерацию по поддержке энкодеров:

1. Простой этап - считаем показания квадратурных энкодеров:
- добавляем команду EG, которая возвращает значения энкодеров EG=<enc0>,<enc1> в виде пары целых чисел со знаком.
- для красоты добавляем команду ER, которая сбрасывает значения энкодеров в 0.

2. Поддержка очереди команд формата MQ=<SL,SR,T>. Расшифровка команды: целевая скорость левого двигателя (кликов энкодера в секунду), целевая скорость правого двигателя (кликов энкодера в секунду), время (мс), за которое от текущих скоростей двигатели должны перейти к целевым скоростям. При этом обратная связь ПИД-регулятора должна быть реализована по счетчикам энкодеров.

Служебные команды:
* MR - очистить очередь команд, добавить в неё команду MQ=0,0,1000, если текущие скорости не нулевые.
* ML - получить количество команд в очереди и время в мс, на которое еще вперед есть команды (ответ - ML=<commands_left>,<time_left_ms>). Если команды кончаются на ненулевых скоростях - в очередь автоматически кладется команда MQ=0,0,1000.
* MC[=<p>,<i>,<d>] - ввести коэффициенты ПИД-регулятора и показать их в ответе, если они переданы, вывести текущие коэффициенты если нет. Ответ в любом случае MC=<p>,<i>,<d>

3. MA - автокалибровка платформы (перед ней должно быть свободного места на 1 секунду пути на полном ходу)

Первый этап сделан, энкодеры считаются, вроде до 300 кликов в секунду всё окей, наверное и больше не проблема.

В архиве модифицированные и новые файлы для прошивки и сам .hex-файл прошивки для OR-AVR-M128-DS

Что даст на практике нововведение? Пример приведите .

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

=DeaD= где то на форуме я видел вы вроде реальные эксперименты с одометрией делали, в одометрии вся фишка в точности измерения промежутков времени между тиками, пока вы это до компа передадите это +- лапоть будет.
на мой взгляд должно быть так:
Обьект odometry
вых свойство1 позиция x mm
вых свойство2 позиция y mm
вых свойство3 позиция q rad
вых свойство4 количество тиков левого мотора
вых свойство5 количество тиков правого мотора
вых свойство6 скорость левого мотора
вых свойство7 скорость правого мотора
вх свойство8 передаточное число левого колеса (для перевода тики в мм, это передаточное число редуктора + диаметр колеса)
вх свойство9 передаточное число правого колеса (для перевода тики в мм, это передаточное число редуктора + диаметр колеса, т.к. может отличаться)

linvinus, а куда вам эта одометрия на уровне ПК?

так у вас цель
1. Возможность узнать, сколько конкретно проехали.
2. Возможность давать команды сколько проехать, а не на какую мощность включить движки (более точные движения)

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

1. Что значит в каком направлении неизвестно? Вполне себе известно, энкодеры квадратурные, направление учитывается. Значение счетчика энкодера - целое со знаком.

2. Остальное не понял, какой еще синус и косинус?

1. ладно я спорить не буду, вам виднее.
2. это уже реализация, детали например тут http://www.mech.tohoku-gakuin.ac.jp/rde ... robot.html

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

1. а где можно потом эти данные применить? координаты не посчитать, на какой угол повернулись непонятно.
например как вы скажете куда проехать? L=200- тиков R=400тиков? и что получите на выходе? Без размеров базы сказать на какой именно угол вы повернулись невозможно.
это кстати должно быть 10м свойством
вх свойство10 - размер базы (параметр 2d если по формулам из приведённой выше ссылке)

даже если предварительно вывести что для поворота на 45 градусов левое колесо должно пройти 200тиков а правое 400, при повороте на колёса будут действовать разные силы, даже если скорость вращения будет константа, сказать что правое колесо успеет пройти 400 тиков за тот промежуток времени, за который левоее пройдёт 200тиков , нельзя.
тогда может получиться так: левое прошло 200тиков, остановилось, но правому осталось ещё 100тиков, и где мы теперь?

2. да мы считаем положение робота в системе координат x,y,q.
считать эти данные в компьютере уже будет поздно.

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

=DeaD= писал(а):Хм, ну можно и такую информацию, как вы сказали, собирать. Не велика проблема. Однако я считаю, что если команды проезда по заданным траекториям будут выполняться достаточно точно - рассчитать примерные координаты робота по ним не станет проблемой.

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