Как стать автором
Обновить

Комментарии 38

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

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

А можно вкратце - какие датчики выбрали и почему? Мне бы тоже пригодились.

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

Для них нужны дифференциальные АЦП, чаще всего с ними используют HX711. Если их тактировать от одного источника, то можно считывать данные параллельно подключив их к одной SCL линии.

Почему именно они? Да других вариантов то особо и нет, а те что есть мне не понравились.

Более подробно в 10 части: https://habr.com/ru/post/543620/

Спасибо, и комментарии к статье содержательные. А про гидравлическую систему удержания равновесия не думали? Для уравнивания давлений в каждой ноге достаточно их соединить на короткое время, а переставлять ноги можно и сервоприводами.

Интересная мысль. Вы пробовали такое реализовывать в маленьком масштабе?

Не пробовал, хотелось бы готовую схему найти и пусть дети собирают. Ну или самому подумать придется. Есть вот такие небольшие цилиндры: Пневматический цилиндр 60 и такие: Пневматический цилиндр 60 с пружиной Для небольшого робота проще пневматический вариант использовать, чтобы просто воздух спускать и накачивать из атмосферы, и не заморачиваться с перекачиванием жидкости. Цилиндры достаточно прочные, надо только соответствующее давление в них обеспечить.

Вот пример закрепленной платформы, где можно разглядеть крепление цилиндров: https://www.ftcommunity.de/bilderpool/basteleien/pneumatik/druckluft-hexapod/9135/ Если использовать электромагнитные клапаны за 1-2$ с али, то у них два выхода, а не один, как здесь.

Огонь. Я обязательно попробую этот вариант. Спасибо большое

Ну раз есть такой повод, выкладываю из черновиков заметку про подбор совместимых пневматических деталей к фишертехнику: https://habr.com/ru/post/569036/

Спасибо, обязательно почитаю.

Я вот думаю, а не проще ли использовать линейные актуаторы, они чуть дороже конечно, но проще в использовании.

По сути всё управление сводится к управлению простым DC мотором, а это всего 4 транзистора (H-мост). Я думал установить их в ноги, чтобы TIBIA могла раздвигаться.

У меня есть сомнения по поводу "Для уравнивания давлений в каждой ноге достаточно их соединить на короткое время". Смысл всего этого веселья в том, чтобы выровнять корпус. Если с левой стороны масса больше, то и сила действующая на цилиндры тоже будет больше. Соответственно при соединении пневматики на короткое время мы получим обратный эффект -- нагруженная сторона еще больше просядет, т.к. воздух под давлением массы перейдет к менее нагруженной стороне.

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

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

В общем попробую купить несколько пневматических цилиндров и актуаторов, поиграю немного :)

Вот только не надо гроздей транзисторов:) лучше посмотрите h-bridge на 4 канала SN754410NE за копейки. Но с линейными актуаторами ноги опять тяжелыми станут со всеми вытекающими. А с цилиндрами, поскольку давление в сообщающихся сосудах равно, то и силы давления на каждую ногу должны автоматически уравняться, получится плавающий подвес у робота. Видели столы лабораторные на гидро или пневмоподвесе? Идеально горизонтальные без всякой электроники.

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

Не, ну на дискретных элементах я собирать это не буду конечно. Готовые микросхемы в приоритете -- это дешевле и проще, они для этого и были созданы :)

BF120-10AA  брутто: 0.050 кг
Есть и другие аналогичные тензодатчики различной геометрии и площадке воздействия.
В качестве ADC есть вполне элегантное решение

10 каналов 0,001 - 3,300V
USB(RS232)/UART Communication ADC Module 10 Channel STM32 12Bit AD 

Это получится бутерброд из плат. К тому же АЦП к тензодатчикам лучше ставить как можно ближе, там микровольты и падение на проводах может оказаться критичным, тем более тут клеммы.

Я разметил по одному АЦП в ноге (там в статье есть фото) и уже по цифровому интерфейсу снимаю с них показания.

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

проблема не в датчиках и коммуникации с ними, а в обработке данных с них и механики. 

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

Да вы смеетесь - у вас там написано (страшным казенным языком), что для управления одним шаговым моторчиком вам ну просто необходим четырехядерный PC с Win10. Боюсь представить ваше решение для управления 12 сервоприводами :D

Такого там не написано или читалось по диагонали, управлять шаговым мотором можно вообще без контроллера, ну да ладно, возможно я что-то пропустил в Вашем описании. Сколько в общей сложности у Вас в проекте задействовано выходных и входных портов?
У меня чисто спортивный интерес симуляции системы Вашего алгоритма на своей программно аппаратной платформе.
Если интересно, готов отвечать на ваши вопросы в соответствующем вашем разделе - электроника или в моей статье.

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

Порты:
- 18 под приводы
- 3 под передние RGB светодиоды
- 1 для управления питанием сервоприводов
- Аналоговый вход для мониторинга напряжения АКБ
- 8 для датчиков касания (6 DI, 1 SCL, 1 master clock)
- 1 для пищалки
- 3 для FTDI (USART)
- 2 для MPU6050 (I2C)
- 2 для дисплея (I2C)
- 2 для SWD
- 2 для WIFI (USART)

Итог: 43 пина

Это если при условии принять плату управления как черный ящик с выводами.

И как понимаю до навигации Вы еще не дошли, или это будет пугливый гексаход, шарахающийся от препятствий?

Я пока не думал в этом плане, для этого нужно математический движок подготовить.

Первое что приходит в голову -- лидар. В рамках помещения отлично подойдет. Для открытой местности...а нужно ли это? Там АКБ на 20 минут, далеко все равно не уйдет.

Для определения препятствий можно использовать камеру, которая уже в нем есть. 20 FPS должно хватить с запасом

Я даже не знаю нужна ли навигация в нем. В целом это реализуемо. Нечего не мешает поставить в него RPI с какой-нибудь нейронной сетью и так же по WIFI управлять им, как я сейчас с телефона.

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

"Да вы смеетесь - у вас там написано (страшным казенным языком), что для управления одним шаговым моторчиком вам ну просто необходим четырехядерный PC..."
 
Возможно кто-то со мной не согласится но тот факт что FSM статический по сравнению с FSM динамическим, существенно ограничивает функционал и многозадачность разрабатываемых систем ввиду очевидных ограничений DSP платформ. На моих глазах не одна высокотехнологичная фирма на определенном этапе развития отказывалась от DSP в пользу PC под полноценными OS.


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

Операционка и тем более ПК тут избыточны. Операционки хорошо подходят для реализации высокоуровневой логики (той же навигации). Думать о том, как там работает I2C или DMA процессора во время реализации алгоритма построения маршрута...мне бы не очень хотелось :)

Микроконтроллер на 72МГц спокойно вытаскивает весь текущий функционал с запасом. У меня есть знакомый, который решил реализовать гексапода на FPGA, вот наблюдаю что из этого получится.

Я надеюсь, что не потерял нить беседы, возможно я о чем-то другом написал, не о том что Вы имели ввиду

А вы не думали использовать ОС в прошивке контроллера управления? При беглом осмотре исходников меня смутил гигантский while(true). Поддерживать такие проекты наверное не очень удобно.

гигантский while(true).

Это который в main? Внутри ОС такой же цикл.

Поддерживать такие проекты наверное не очень удобно.

С этим нет проблем

А вы не думали использовать ОС 

Чтобы подрыгать сервоприводами? Для светодиодов тоже ОС ставить?

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

"В практической разработке робототехники взор профессионального кодера должен опережать видимую клиентом реальность и запросы на несколько горизонтов дальше."
XYZ

Внутри ОС такой же цикл.
Для каждой задачи он свой, и время для них распределяется по приоритетам.
С этим нет проблем
Возможно, но я лично привык использовать ОС даже в маленьких проектах, хуже от этого не становится, а поддержка и масштабирование гораздо проще.
Чтобы подрыгать сервоприводами? Для светодиодов тоже ОС ставить?
Мне показалось что там задач на контроллере было побольше, да и новые возможности добавляться скорее всего тоже будут.

Как мне кажется использование ОС во всех проектах дисциплинирует разработчика делать упор в сторону гибкости масштабирования и удобства поддержки программы. Но тут нужно самому попробовать и решить для себя как будет удобно работать дальше. Конечно же это решение будет зависеть и от того какая ОС для МК будет использоваться.

Под слоеным пирогом я понимаю вот это

это ужасно. Для первого прототипа сойдет, но не для последующих и тем более для конечного продукта.

Мой прототип вообще был ужасен в плане эргономики и технологичности :)

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

Могу предположить что следующий шаг будет в сторону ARM

Он там был изначально -- сначала SAM3X8E, сейчас STM32F373.

да, сейчас вернулся к фото, рассмотрел как есть.

По сути это не полноценный робот. Сейчас это просто шестиногая платформа, которая выполняет команды с более высокого уровня. А в качестве этого высокого уровня может выступать все что угодно.

AIWM -- сейчас реализуется только WM часть, AI часть потом :)

Ответ выше.

Тут возможно и по току сервы можно судить

Как показывает практика -- нельзя

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

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