linvinus

linvinus

попробовал подменить sin(Q) на sqrt(1-cos(Q)*cos(Q))
по точности ничего не изменилось

Тут ещё вот в чём может быть дело.
Поведение рояльного колеса я задал через апроксимацию, т.к. я точно не знаю как посчитать его положение.

Код:

"""
    _               _
   | |             | |
   | |B-----A-----D| |
   |L|      |      |R|
    ~       |       ~
            |
            *F
            _
          / /
         /C/ - (caster wheel)
         ~
"""

Входные данные физической модели - скорости левого и правого колеса (vL, vR)
по ним как в обычной одометрии получаю скорость точки A от неё высчитываю положение точки F
а вот как вычислить угол который при этом получится между AF и FC я не знаю, я посчитал что поскольку вилка не растягивается то рояльное колесо (точка С) пойдёт по кратчайшему пути из текущего положения в сторону точки F.
поэтому новое положение точки C я определяю так
1) вычисляю угол между новым положением точки F и старым положением точки C => угол wC
2) от нового положения точки F вычитаю FC по углу wC
WheeC.pos.x = pointF.pos.x - BASE_FC*cos(wC)
WheeC.pos.y = pointF.pos.y - BASE_FC*sin(wC)

т.е. получается что точка C ползёт в сторону точки F, вроде бы вполне естественно.

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

я заметил что точность ухудшается в моменты когда рояльное колесо вращается относительно точки F, когда оно не вращается (угловая скорость платформы постоянна) ошибки вроде бы нет.

dccharacter

А попробуй добавить датчик от мыши и потом использовать разные данные для коррекции друг друга

linvinus

Была у меня и такая идея

И датчик есть, но пока меня интересует математическая модель рояльного колеса.

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

sned

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

linvinus

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

Цитата:

Из за всё того же проскальзывания основных колёс мы не можем определить совершаем ли мы разворот на месте с помощью двух колёс работающих в разные стороны или с помощью отработки только одного колеса и соответственно все радиусы разворота (и расчётные плечи) будут каждый раз разные.

не уловил, почему не можем?
при повороте на месте рояльное колесо двигается по радиусу равному длине между осью ведущих колес и точкой крепления рояльного колеса, при этом линейная скорость вращения рояльного колеса даёт нам угловую скорость вращения платформы

платформа выглядит вот так
forum87/topic15337-105.html#p335776
тут в собранном виде
forum87/topic15337-120.html#p336339

Вложение:

caster_wheel_kinematics.png [ 49.06 КиБ | Просмотров: 2623 ]

у моей математической модели, я нашёл одну ошибку, я знак терял когда вычислял скорость колеса (она всегда была положительной).
но даже после исправления всё равно врёт, не получается восстановить траекторию, видимо где то в кинематике ошибка, в ней я слабоват :oops:

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

Код:

V=VC*cos(Q)
Theta2=Theta2 + VC*sin(Q) / ( BASE_AF + BASE_FC*cos(Q) )

где VC - линейная скорость рояльного колеса
Q - угол поворота вилки относительно корпуса
BASE_FC - длина вилки
BASE_AF - расстояние между осью ведущих колёс и точкой крепления рояльного колеса к корпусу.

если сравнить с рисунком выше то
Theta2 => β - угол поворота платформы в неподвижной системе координат
VC => VF
Q => ψ
BASE_FC => DF
BASE_AF => AD

формула получается такая

Код:

Va=Vf*cos(ψ)
β=β + Vf*sin(ψ) / ( AD + DF*cos(ψ) )

Искомые величины VA и β

при прямолинейном движении
Q = 0
V=VC
Theta2 = const

при повороте появляется ошибка, угловая скорость платформы получается выше чем должна быть, а траектория рояльного колеса опережает траекторию физического колеса
т.е. ошибка где то тут
Theta2=Theta2 + VC*sin(Q) / ( BASE_AF + BASE_FC*cos(Q) )

sned

Пока у меня вопрос только по рисунку,остальное с наскока не осилю.
Что за точка G?
Почему прямой угол GFD а не EDF?
Ведь ED это меняющийся мнимый радиус к которому вилка FD рояльного колеса должна быть всегда перпендикулярна.

linvinus

документ откуда взята картинка

Вложение:

Комментарий к файлу: Kinematics and dynamics of some selected
two-wheeled mobile robots S. NOGA

online.pdf [319.68 КиБ]
Скачиваний: 0

Цитата:

The point E is an instantaneous centre of chassis 4,
and the point G is the instantaneous centre of the bracket.

E- точка вокруг которой вращается шасси
G- точка вокруг которой вращается рояльное колесо

sned

Да, там вроде всё логично но не все понятно, :roll:

ещё бы перевод качественный

linvinus

Ну ежеле что то непонятно то я могу ещё много надавать документов то что нарыл, но просветление пока не наступило

везде рассматривают трицикл типа как здесь http://cse17-iiith.virtual-labs.ac.in/f ... ion=Theory
но у него нет вилки, в этом отличие

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

((

linvinus

Не эпикфэеил но близко.

Датчики as5040 которые я использую forum87/topic15337-120.html#p336564
иногда начинают жутко врать, помогает только сброс датчиков по питанию

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

,
что происходит непонятно, работает-работает потом бац и не работает.

выражается это в том что он вместо диапазона 0..1023 начинает выдавать 0..104..0, никаких ошибок не даёт, типа всё ОК.
после сброса питания всё возвращается в норму.

подстава в том что от этого зависит вращение мотора

т.е. один мотор перестаёт крутиться.
как это отлавливать непонятно.

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

Angel71

по транзистору и периодически передёргивать питание.

linvinus

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

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

пока погоняю с ограничением максимальных оборотов, если поможет то так и оставлю, на спортсмена я не претендовал, 0.1м/с он вроде отрабатывает нормально, быстрее мне не нужно.

Angel71

в даташите на as5040 есть упоминание 30000 об/мин. несложный вариант переделки, как ещё дёргать питание, скорей всего придумать можно.

linvinus

30 000 это инкрементальный, он не годится, вернее им очень сложно управлять bldc.
я использую абсолютное положение а это всего 600 об/мин. и видимо если превысить то у датчика мозги набекрень съезжают :crazy:

теоретически максимальная скорость робота должна быть
pi*0.08*((600/6)/60)=0.418879 м/с

Angel71

600, а если раз в секунду данные получать, то вроде и 1200. зачем нужно кроме скорости вращения знать прям реальный угол, хз. вникать в эти энкодеры пока смысла 0, так что могу только в общем. у стм есть аппаратная поддержка квадртурного энкодера, какие максимальные частоты я не смотрел. можно прикинуть реальность такого варианта - получить угол и потом переключиться на квадратурный энкодер. а так или не превышать скорость, тем более что 10об/сек эт не мало. или прикинуть где что можно переделать - подключение, код, мк сменить.

roboforum.ru

Правила форума

linvinus

Кто сейчас на конференции