roboforum.ru

робокотики саламандры и ящерицы http://biorob.epfl.ch/movies ну и бипеды есть
по некоторым проектам есть более детальное описание

до чего домашнее производство плат дошло http://radiokot.ru/forum/viewtopic.php? ... 1#p2643001

Наткнулся я на плату Z-turn Board (ARM + FPGA в одном чипе) http://www.myirtech.com/list.asp?id=502
Решил посмотреть на это как на альтернативу связки linux ARM + микроконтроллер.

Я уже давно хотел понять как именно программируют FPGA, но сильно забуриватся в эту тему не хотелось.
Но сегодня наткнулся на довольно интересный документ где в деталях для начинающих, с картинками, рассказано всё с самого начала,
что качать, как создать проект, что написать, как симулировать, как компилировать, как загружать.
Документ называется "FPGAs!? Now What? (Tutorial)" http://www.xess.com/appnotes/FpgasNowWhatBook.pdf
В качестве примера есть вот такая оценочная плата http://www.xess.com/shop/product/xula2-lx25/

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

Я смотрел в сторону интеграции Linux + fpga, но в век когда всяких микроконтроллеров как грязи, на FPGA стоит лезть только если требуется что то действительно очень быстрое и нестандартное.
Кроме того я искал как можно работать с FPGA под линуксом, как я понял у xilinx есть ПО и для линукса так называемый WebPACK http://www.xilinx.com/support/download.html

Так же я посматривал в сторону комбинации linux + i2c чипы, например есть отдельные модули i2c - ADC, i2c - PWM,
но этого маловато, вот если бы была микросхема где по i2c Было бы доступно 4ре продвинутых таймера STM32Fx с такой микросхемой можно было бы сделать управление двухколёсным роботом без микроконтроллера практически с любого линукс устройства (планшет, телефон и т.п.)

Например вот так сделали управление квадрокоптером https://www.hackster.io/12590/pi0drone- ... ero-4fec08
linux->i2c->pwm->BLDC ESC (Electronic Speed Controller)

У altera тоже есть софт под линух - quartus. Полностью юзабельный, есть крутые платы, типа deo-nano. Куча примеров...

спасибо за наводку, в моей вселенной почему то считалось что с FPGA под линуксом всё плохо.

вот процессор на FPGA нашёл, который даже линукс может запустить https://github.com/embecosm/chiphack/wi ... structions

вот пример робота "Terasic Spider" http://www.terasic.com.tw/cgi-bin/page/ ... 4&PartNo=2

Сейчас все монстры-производители поддерживают линух. Кто этого не сделал, тот сам себе Буратино
Я это понял, когда microchip перевел свой ide на линух.
На deo-nano много есть примеров, это как arduino в мире контроллеров. Кста, не знаю как сейчас, но раньше у Terasic можно было купить deo-nanо по 50$, надо было только притвориться студентом.

Добавлено спустя 35 секунд:
Сейчас 61$
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=139&No=593

The complete design of the MIT Super Mini Cheetah will be made publicly available soon.
https://biomimetics.mit.edu/research/mi ... ni-cheetah


собачьи бега

Интересный учебный робот по формфактору похож на моего R3
https://wiki.eecs.berkeley.edu/biomimetics/Main/Zumy цена $342
Используют ODROID U3 + ARM mbed LPC1786 + самодельная материнская плата
проект полностью открытый есть список что где покупали и как собирали.



Честно говоря комплектация спорная
я бы использовал ODROID C0
и их АКБ Turnigy nano-tech 850mah 2S 25~40C Lipo Pack (US Warehouse) для odroid u3 явно мало у него в пике до 6W потребление, это без моторов.

Судя по их планам они остались не довольны конструкцией на базе zumo https://wiki.eecs.berkeley.edu/biomimet ... myRevETODO

Лаба zumy по калману (интегрирование ускорения для получения позиции и скорости + данные абсолютного положения от внешних AR меток) https://bcourses.berkeley.edu/files/656 ... load_frd=1

файл фильтра есть в этом архиве https://github.com/iamanogre/EE106A_fa1 ... t_code.zip /ros_workspaces/project/src/tfservice/src/


А вот это уже интересно http://iamanogre.github.io/EE106A_fa15/ (яма на горе?)
Два робота автономно ищут где бы лучше подзарядиться

из этого проекта можно взять идею автономной навигации при помощи IMU + 4 AR метки по периметру, т.е. пока робот не видит метку он использует только IMU , как увидел положение уточняется по метке.


====================
Готовые H-мосты http://www.aliexpress.com/store/product ... 58046.html
думаю годятся как для DC моторов так и для BLDC можно подключать к любому микроконтроллеру 3в, 5в

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


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



Обратите внимание код работает на планшете, это реально круто.
Как я понял давняя идея Автора сделать видео с гиперссылками постепенно претворяется в жизнь.
когда нибудь на ютубе появится автоматическая привязка рекламы к вещам в кадре.

Его изначальный код 5ти летней давности открыт под GPL https://github.com/zk00006/OpenTLD

Наткнулся на блог где в духе arduino есть статьи про chibios и разное оборудование http://www.playembedded.org/blog/en/tag/chibios/

Пришли датчики AS5045 и новый контроллер StormBGC32 v1.32 с драйверами DRV8313 http://www.olliw.eu/storm32bgc-v1-wiki/ ... rM32_v1.32
(лучше брать 1.31!!! меня китайцы надули)

Старый датчик справа новый слева


В этот раз никаких проволочек, датчики приклеил на двойной скотч, быстро, аккуратно, красиво.

Раньше было вот так
post335261.html#p335261
post335796.html#p335796

В этот раз решил использовать тонкие гибкие шлейфы с коннекторами. (паять провода с шагом 1.27 мало удовольствия).

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

Контроллер изначально идёт с STM32F1 но позволяет установить STM32F4 , две перемычки нужно выпаять и впаять конденсаторы на их место, что я и сделал.

Поскольку прежний мой контроллер использовал продвинутые таймеры Tim1,Tim8 а этот использует три обычных Tim3,Tim2,Tim4
драйвер BLDC пришлось переписать, да и вообще все ножки по другому задействованы.

Поскольку много чего пришлось менять переповерил всю программу и пришёл к таким выводам.
1) я использовал SPI в режиме RXonly с DMA, при этом при каждом новом чтении цепочки датчиков я заново настраивал соединение SPI а по окончании полностью выключал SPI контроллер.
Всплыли следующие косяки которые я раньше не замечал.
- когда SPI выключен он освобождает ножки в результате если они не подтянуты никуда на них остаётся плавающее напряжение
- в режиме Master RXonly сигнал SPI clk никак не привязан к количеству считываемых данных, т.е. он просто тупо молотит пока его не остановят, а поскольку я ещё и DMA юзал то программа вообще плохо контролировала эту ножку, она могла запросто считать за 200us и потом ещё 100us молотит пока не очнётся и не выполнит команду SPI stop
но и тут не всё так просто, в момент когда мы говорим стоп на выходе SPI clk могло быть как 1 так и 0 , т.е. после выключения работают встроенные подтягивающие резисторы, в результате там частенько проскакивали медленные фронты из 0 в 1.

короче косяк на косяке, решил переделать забил на DMA читаю программно, и не вырубаю SPI полностью а лишь останавливаю его SPID3.spi->CR1 &= ~(SPI_CR1_SPE);
теперь все фронты чёткие без сюрпризов, на время чтения лочу программу чтобы другие потоки не перехватили управление

возможно этим были вызваны проблемы с непредсказуемым уходом в режим калибровки

2) в старом контроллере силовые транзисторы напрямую подключены к контроллеру, без промежуточных драйверов в результате транзисторы довольно сильно грелись не зависимо от того какой deadtime я ставил, Это также влияло на точность движения мотора на малых оборотах, в новом контроллере DRV8313 у низ очень маленький вcтроенный deadtime плавность движения повысилась, драйверы почти не греются

3) AS5045 в отличие от As5040 выдают в другую сторону положительное направление(под вопросом, возможно просто фазы моторов отличаются от старого контроллера), убил на это один вечер, не мог понять почему данные есть а моторы не крутятся.

4) as5045 выдают 18бит+1 в режиме цепного чтения, распарсить это оказалось не так тривиально как кажется,получается данные размазаны между несколькими байтами (например 5тый датчик в цепочке размазан по трём байтам)
ещё вечер убил на то чтобы это решить.

короче, всё заработало , двойной скотч рулит

Зы а вот так я травил платы (фото пересвечено, в реальности раствор тёмно зелёный)

Вот так работает почти идеальный колёсный привод в моём понимании )



Начиналось всё с блочной коммутации и датчиков холла, тут post280709.html#p280709 и следующие несколько страниц

Потом по совету Дмитрия попробовал аналоговые датчики холла post282194.html#p282194
с ними почти получилось, но конструкция была крупная а датчики капризные, но сейчас я понимаю что теоретически с ними можно получить результат сравнимый с моим текущим.

Поскольку я посчитал что с аналоговыми датчиками холла не получилось, я забросил привод, и сдел робота на базе платформы ZUMO. Но там редукторы 1/100 поэтому мотор всегда работает на высоких оборотах, из за чего довольно сильно жужжит.

Но в прошлом году захотел сделать рояльное колесо с энкодером, а потом вспомнил про привод и решил проверить как будет работать с ним post335261.html#p335261

Сейчас сделано так:
Управление по положению а не по скорости, поэтому можно управлять скоростью колеса от 0 до максимума (0.2м/с, примерно 286 об/мин скорость вращения мотора), переходные процессы очень быстрые, как на повышение так и на понижение.
Управление с обратной связью, на мотор подаётся ровно столько тока чтобы он занял необходимое положение, но не более, так что мотор практически не греется на нулевых скоростях (к примеру на видео, там где очень медленно вращается, pwm на уровне 10%).
Конечно нужно ещё протестировать в боевых условиях, но первые результаты меня уже радуют.

Работает это примерно так:
1-й поток, читает энкодер и в соответствии с текущим положением и заданной мощностью выдаёт ШИМ, работает на максимальной частоте (это эмуляция коллектора в DC моторе)

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


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

Преимущества:
скорость колеса напрямую не связана с частотой выполнения алгоритма.

К примеру, если делать управление по скорости, то для того чтобы точно поддерживать заданную скорость вращения, желательно выполнять pid с высокой частотой, однако, если скорость колеса слишком низкая, то энкодеры не будут показывать скорость из за дискретности (у меня мотор связан с колесом через понижающий редуктор 1/6), при этом пид будет считать что колесо остановилось поэтому будет поднимать pwm, в результате на низких скоростях колесо будет дёргаться.

Недостатки:
пока не выявил

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

linvinus писал(а):Разбираюсь с одометрией
у меня такие варианты
1) есть энкодеры на моторах bldc
2) есть энкодеры на рояльном колесе, знаю абсолютный угол поворота вилки рояльного колеса и скорость вращения
...

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

На какой частоте интегрируешь одометрию? Идеальный вариант - интегрировать {x,y,phi} на каждом тике энкодера на любом из ведущих колёс. Из теории на пальцах: для пары dL и dR (тики энкодеров для правого и левого колеса) существует бесконечное множество возможных положений робота, хотя они все лежат в некоторой окресности. Вообщем чем меньше шаг интегрирования тем точнее.

Как считать одометрию по двум ведущим колёсам понятно.


Я хочу попробовать другой способ.



Рояльное колесо намного меньше проскальзывает относительно пола, я через него хочу высчитать положение робота.
Вот тут на фото видно конструкцию рояльного колеса с двумя абсолютными энкодерами post336339.html#p336339
Т.е. зная угловую скорость рояльного колеса, и абсолютное положение вилки относительно корпуса, нужно вектор скорости рояльного колеса привести к вектору скорости платформы и его интегрировать для получения положения в абсолютной системе координат, при этом мы не знаем на какой угол повернулось рояльное колесо относительно земли.

Геометрически я привёл скорость от колеса до центра оси между ведущими колёсами, и общие двежения совпадают, но несовпадает точное положение (я проверяю в математической модели на питоне post351449.html#p351449), до тех пор пока робот едет прямо всё совпадает идеально, как только появляется вращение вилки рояльного колеса так набегает погрешность или формула что то не учитывает.

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

и тут


Есть формулы для Steeting-wheel когда нет, вилки, т.е. ось вращения колеса и ось поворота колеса относительно корпуса совпадают.

Но они не подходят в моём случае по понятной причине.