Разработка hexapod с нуля (часть 7) — новый корпус, прикладное ПО и протоколы общения


    Всем привет! Проектирование, печать и сборка нового корпуса наконец-то завершились. Также завершился запуск новой платы управления на базе STM32F373 и FW успешно перенесено на новый МК. Все ближе подходит релиз версии 1.00 с базовым функционалом. Теперь можно рассказать о том, что еще ни разу не упоминалось в цикле — прикладное ПО для управления и используемые протоколы для коммуникации. Как всегда, будет много картинок, видео и список граблей, на которые я успел наступить с прыжка.

    Этапы разработки:

    Часть 1 — проектирование
    Часть 2 — сборка
    Часть 3 — кинематика
    Часть 4 — математика траекторий и последовательности
    Часть 5 — электроника
    Часть 6 — переход на 3D печать
    Часть 7 — новый корпус, прикладное ПО и протоколы общения

    Небольшой обзор новых изменений


    Были куплены еще 8 штук DS3218MG (с запасом) и удалось полностью перейти на новые приводы (в COXA были MG996R). Это решило проблему с синхронизацией скорости поворота COXA и скоростей FEMUR и TIBIA, так как приводы были разные.

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

    Вес корпуса без электроники и приводов составляет ~1.5кг. Вес приводов ~1.2кг. Электроника весит ~90г, АКБ весит ~148г. Суммарный вес гексапода составляет около 3кг.

    Фото корпуса во время различных этапов его сборки






    Как вы могли заметить, внутри стоит активное охлаждение в виде 2-х вентиляторов 35х35mm. Я оставил их для своего спокойствия. Перегрева ни разу еще не было и не ожидается, так как гексапод столько не проработает, АКБ сядет раньше :) При длительной работе (более 30 минут) от внешнего блока питания наблюдается ощутимый нагрев силовой платы. Термометр в виде левой руки показал температуру около 70 градусов. Также отсутствует теплоотвод в виде медных полигонов на другой стороне платы, это обусловлено её домашним производством. В ближайшее время закажу производство в Китае с учетом этого недостатка, да и вообще многих других.

    Спереди имеются 4 RGB светодиода для индикации состояния гексапода. К примеру, при низком заряде АКБ светодиоды начнут часто мигать красным цветом, попутно сводя с ума пьезопищалкой. При потере соединения светодиоды будут уже мигать синим, но без пищалки и более редко. Если все ОК — горят зеленым. Ну все кейсы описывать не буду :) Ниже видео с процессом инициализации гексапода для наглядности процесса.


    И видео с тестом при потере соединения:


    Китайцы наконец-то произвели и прислали новую плату управления, и минимальный набор компонентов был напаян в тот же день. На плате был найден всего 1 некритичный косяк — перепутаны выводы тактовой кнопки RESET (там их 4), что решается откусыванием 2-х выводов по диагонали.


    Я ожидал больше косяков, но рад что их нет (даже RX и TX не перепутал). Фото платы под спойлером, также добавил пару фоток старого бутерброда для сравнения.

    Плату заказывал на PCBWay, само производство заняло 24 часа, как и обещали. Ехало дольше обычного — 19 дней доставкой ePacket (обычно с этой доставкой доходит за 12-14 дней). Стоимость суммарно составила $12 с производством и доставкой 5 плат (минимальное количество для заказа), что по сравнению с ценами в нашей стране очень дешево.

    На данный момент я не стал переводить коммуникацию на Bluetooth, поэтому гексапод по-прежнему управляется через WIFI соединение (возможность подключения Bluetooth к плате управления уже заложено).

    Фото платы управления




    Фото с описанием разъемов

    Для отладки выведен SWD интерфейс на контакты для пайки проводов (на фото провода уже напаяны). К плате подключаются следующие блоки: концевики с конечностей, шлейф на плату питания для передачи сигнала приводам, пищалка со встроенным генератором, передние RGB светодиоды, питание, балансировочный разъем с АКБ для контроля заряда ячеек.

    Прошивка платы


    Все МК от ST, которые я встречал, поддерживали программирование через USART и STM32F373 не исключение. Это позволяет программировать МК без использования программатора или отладчика, которые не очень дешевые. В данном случае можно использовать любой USB-UART преобразователь за 150 рублей с Ali и программу «STM32 Flash loader demonstrator».

    Для прошивки платы нужно выполнить манипуляцию с BOOT джампером и кнопкой RESET (надеть и нажать). Далее необходимо подключить USB-UART преобразователь к разъему SERVICE (RX, TX, GND) и воспользоваться программой «STM32 Flash loader demonstrator» (как ей пользоваться можно найти в интернете).

    Программное обеспечение


    Перейдем к тому, чего я еще не описывал в процессе разработки — приложение для взаимодействия пользователя с гексаподом (AIWM Control).

    С ноутбуком ходить по улице не очень удобно, поэтому я решил сделать ПО под Android (телефон сейчас у всех в кармане есть). Программа написана на C++ с Qt\QML, что позволило еще и сохранить кроссплатформенность приложения, так что под Windows получить exe-шник не проблема.

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

    Экран подключения. Ну тут все просто — всего 2 кнопки. Отсюда можно перейти на экран управления и на экран терминала. Нажали — перешли. Внутри это реализовано установкой соответствующего индекса в SwipeView, остальное сделает Qt. При входе на экран запускается отдельный поток для обработки коммуникации (мы же не любим, когда интерфейс тормозит) и при выходе с экрана он убивается.

    Скриншоты

    Экран управления. Тут интереснее. На этом экране отображаются заряд батареи и статус модулей гексапода. При ошибке одного из модулей загорается красным соответствующий ему прямоугольник. Так же имеется индикация ошибок для понимания, что же именно произошло с модулем. К примеру, если было неправильно сконфигурировано ядро передвижения, то загорится прямоугольник «Movement engine» и «Configuration error».

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


    Я думаю стоит кратко описать показанные здесь модули и ошибки. Начнем с ошибок.

    • FATAL_ERROR — фатальная ошибка системы. Выставляется в случае обнаружения ошибки, при которой работа невозможна или опасна. К примеру, было обнаружено, что параметр внешней функции имеет невалидное значение. Так как эта функция вызывается другим модулем, то прошивка явно содержит какую-то неверную логику. В этом случае FW запускает аварийный цикл, в котором работает только индикация светодиодами и коммуникация;
    • CONFIGURATION_ERROR — ошибка конфигурации. Выставляется в случае обнаружения неверного параметра в конфигурации (к примеру, длина TIBIA = 0xFFFF мм). Работа в данном случае опасна и одновременно с этой ошибкой выставляется FATAL_ERROR со всем вытекающими;
    • MEMORY_ERROR — ошибка памяти. Выставляется в случае отваливания EEPROM, либо сбоя на шине I2C. Работа невозможна, так как нельзя загрузить конфигурацию. Одновременно с этой ошибкой выставляется FATAL_ERROR со всем вытекающими;
    • VOLTAGE_ERROR — ошибка напряжения. Выставляется в случае обнаружения низкого суммарного напряжения АКБ, либо одной из его ячеек. В этой случае гексапод просто садится на брюхо и пищит, мигая красными светодиодами;
    • SYNC_ERROR — ошибка синхронизации. Выставляется в случае обнаружения пропуска цикла вычислений. Синхронизация в гексаподе завязана на частоту PWM сервоприводов (160 Гц) и все расчеты должны проводиться с такой же частотой. Рассинхронизация возможна в результате выполнения долгой операции (запись большого блока в EEPROM), либо мы просто не успеваем считать;
    • MATH_ERROR — ошибка математики. Выставляется в случае обнаружения деления на 0, сбоя FPU и прочих радостей. В случае установки ошибки отключается модуль, в котором она была обнаружена;
    • CONNECTION_LOST — соединение потеряно. Выставляется в случае обнаружения потери соединения. По идеи, этот блок никогда не должен загореться красным, так как в случае обнаружения потери соединения (а это означает, что от мастера нет пакетов) гексапод перестает слать пакеты с текущим состоянием. Ошибка нужна для внутреннего использования, в случае её установки гексапод садиться на брюхо и мигает синими светодиодами (видео в начале статьи);

    Модули:

    • CONFIGURATOR — отвечает за работу с EEPROM. Предоставляет интерфейс для чтения и записи данных;
    • SERVO_DRIVER — драйвер сервоприводов. Занимается расчетом ширины импульса и организует синхронную передачу значения драйверу PWM;
    • LIMBS_DRIVER — драйвер конечностей. Занимается расчетами траекторий движения конечности и решает задачу обратной кинематики;
    • MOVEMENT_ENGINE — ядро передвижения. Предоставляет интерфейс для переключения между последовательностями и организует передачу координат драйверу конечностей;
    • SYSTEM_MONITOR — модуль слежения за состоянием системы. Предоставляет интерфейс для установки\сброса ошибок, выполняет аналоговые измерения и расчет соответствующих величин (напряжений);

    Есть различные элементы управления для посылки соответствующих команд гексаподу для движения. Мечи тут не просто так — он может ткнуть в кого-нибудь, либо постучать в дверь :) Кстати, из-за довольно большого веса и мощных приводов тыкает он довольно ощутимо.

    Скриншот

    Экран терминала. Сервисный экран, предназначенный для конфигурации и отладки гексапода. Экран очень простой в плане функционала и выполняет 2 функции: принять и послать. Всё. Для коммуникации используется CLI и о нем поговорим чуть ниже.

    Скриншот

    Кишки. Внутри все устроено достаточно просто. Есть 2 потока: главный и поток коммуникации. В главном потоке обрабатываются GUI и ядро приложения, в потоке коммуникации обрабатывается (внезапно) коммуникация. Общение между потоками осуществляется при помощи сигналов и слотов.

    Коммуникация осуществляется при помощи QUdpSocket, а на более верхнем уровне используется SWLP (Simple WireLess Protocol) протокол. Можно не пытаться гуглить описание протокола — это мое детище и о нем поговорим чуть позже.

    Передача пакетов осуществляется по событию таймера. При обработке события таймера поток коммуникации дергает главный поток (генерирует сигнал), который отдает ему данные для передачи. Далее данные запаковываются в SWLP фрейм и передаются по UDP протоколу через WIFI соединение.

    При приеме пакета обрабатывается сигнал от сокета о том, что датаграмма пришла. Далее идет ряд проверок, извлекаются данные и генерируется сигнал главному потоку «Данные пришли — забирай». Все просто. Главный поток, после этого, начинает обновлять интерфейс в соответствии с принятыми данными.

    Протокол коммуникации — Simple Wireless Protocol (SWLP)


    Это основной протокол коммуникации с гексаподом в нормальном режиме работы. В качества транспортного протокола используется UDP/IP. На момент написания статьи формат фрейма (ADU) и полезной нагрузки (PDU) имеют следующий вид:


    • Start marker — маркер начала пакета. Имеет фиксированное значение 0xAAAA. Нужен для дополнительного контроля целостности пакета;
    • Packet number — номер пакета. Протокол UDP не гарантирует очередность пакетов и это поле необходимо для отбрасывания старых пакетов. Значение увеличивается гексаподом при каждом принятии пакета;
    • PDU (Payload Data Unit) — содержит полезные данные (внезапно). Бывает двух типов COMMAND и STATUS;
    • CRC16 — нужен для контроля целостности пакета. Полином 0xA001, алгоритм расчета стащил из спецификации ModBus;

    Большая часть PDU зарезервирована для дополнительных данных, которые могут понадобиться в будущем. Поля в PDU думаю нет смысла описывать, там названия говорят сами за себя. Можно прокомментировать только то, что напряжение передается в mV.

    Больше интересен сам процесс коммуникации. Протокол использует модель «Master — Slave». Master (в данном случае приложение на Android) постоянно посылает пакеты c «PDU COMMAND» минимум 2 раза в секунду, slave (гексапод) на каждый пакет от мастера должен сформировать и отправить пакет с «PDU STATUS». При этом гексапод не может запросить данные у мастера, да и запрашивать то нечего.

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

    В прошивке прием фрейма (ADU) основан на одной из очень полезной функции USART — RTO (Receiver Timeout). Эта штука позволяет установить значение времени «тишины» на линии RX микроконтроллера и как только тишина длиться дольше установленного времени, генерируется прерывание. Это позволяет использовать DMA для приема данных без обработки каждого байта в прерывании и не нужно искать начало пакета в потоке данных.

    Исходя из выше сказанного, пауза между пакетами должна быть больше времени передачи 30 битов. Значение 30 выбрано не просто так, это время передачи 3.5 символа по USARTу (с небольшим запасом) и это правило взято из спецификации ModBus протокола.

    Отрывок из спецификации ModBus


    Протокол отладки — CLI


    Для использования протокола нужно в приложении на экране подключения нажать на кнопку «Терминал». По умолчанию активным протоколом коммуникации является SWPL. Для использования CLI необходимо послать «cli cli cli» для переключения протокола. Приложение это делает автоматически при переходе на экран терминала.

    После этого мы можем использовать команды CLI для управления гексаподом. Команды имеют следующий формат: <имя модуля> <команда> <аргументы>.

    Примеры:
    — «system status» запрашивает текущую информацию о системе;
    — «servo calibration 1500» отключает все сервоприводы от драйвера и устанавливает ширину импульса 1500us для коррекции углов;
    — «config write 0200 0102AABB» записывает данные 0102AABB в EEPROM по адресу 0200;

    Пример установки обратного направления для 1 и 3 привода


    Полный список команд (вывод help)

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

    Грабли


    Ниже я приведу список эпичных ошибок в процессе разработки, начиная с момента печати корпуса:

    • На плате управления я предусмотрел защиту от переполюсовки в виде диода. Компоненты для платы пришли частями и этот самый диод как раз шел в другой партии. У меня были другие диоды в наличии, но я решил впаять перемычку, руководствуясь «Не ну я же разработал эту плату и знаю где + и -». Раз так на 10й я все-таки перепутал VDD и GND. Все обошлось только убитыми стабилизаторами на 3V3 и 5V соответственно, МК остался цел (дорогой негодяй);
    • В драйвере сервоприводов была предусмотрена функция ограничения угла поворота привода и соответственно при настройке я её не включил. Действительно, зачем? В итоге я не заметил как TIBIA уперлась в FEMUR (положение 0 находится близко к границе касания), привод в этом время упорно пытался довернуть TIBIA в нужную позицию. Через минут 15 начало веять теплом от конечности, потрогав её я обнаружил что чёт она горячая слишком. Привод был мертв. Полностью. И DC мотор и оба транзистора. Хорошо, что купил на 2 штуки больше;

    Вроде ничего не забыл эпичного.

    Я не стал перечислять подобные моменты:

    Нужно было вытащить провод от антенны из заглушки. Для этого нужно снять крышку открутив 8 болтов. Что из этого вышло:

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

    Что я забыл? Правильно — провод антенны вытащить, погнали обратно разбирать. В общем было весело :) Хорошо, что к этому моменту я обзавелся электрической отверткой и процесс вращения болтов стал приносить удовольствие.


    Видео


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


    Погуляем в новом корпусе (без звука):

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

    Запустить Qt под Androind не самая простая задача, хотя разработчики максимально это упростили (спасибо им). Стоит ли написать статью по настройке Qt под Android?

    • 93,3%Да28
    • 6,7%Нет. Есть документация на Qt Doc и там все уже написано2

    Похожие публикации

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

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

      0
      Это позволяет программировать МК без использования программатора или отладчика, которые не очень дешевые.

      Это шутка? Я даже не знаю какой еще программатор/отладчик дешевле?
        0
        Ну не знаю. Я свой J-link взял с Ali где-то в районе $40, что явно дороже кого-нибудь CH340. До этого брал J-link за $8, в итоге пришел без прошивки, а та прошивка что подошла может установить только 2 точки останова, да и работал он через раз: то в процессе отладки отвалится, то зальет FW не с первого раза.

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

        Спорить можно долго, но если ли в этом смысл? :)
          0
          китайские клоны Stlink v2 стоят 120р, приходят с прошивкой и, в общем, работают, не было такого, чтоб через раз заливалось. Их даже можно перепрошить прошивкой BlackMagicProbe и получить какой-то убер-отладчик.
        0
        Хм, если Вы используете UDP зачем CRC? в пакете UDP и так присутствует CRC.
        P.S. Стартовый маркер ладно, фиг с ним, для идентификации протокола не помешает :)
          0
          Так после HLK-RM04 UDP разворачивается в SWLP и далее передается по UARTу в МК. CRC как раз и нужно для того, чтобы быть уверенным, что данные прошли по линии до микроконтроллера без сбоев.

          Вероятность мала в виду коротких дорожек, но все же — лишним не будет.
            0
            Так после HLK-RM04 UDP разворачивается в SWLP и далее передается по UARTу в МК. CRC как раз и нужно для того, чтобы быть уверенным, что данные прошли по линии до микроконтроллера без сбоев.

            ок. Теперь ясно, за одно узнал что такое HLK-RM04 :) Честно говоря посмотрел бы в сторону чего нибудь более гибкоконфигурируемого и дешового — esp8266/32.

              0
              Нее, не хватало еще и ESP отлаживать :)
                +1

                Зато можно уменьшить нагрузку на wifi. Да и вобще можно отказаться от стм32, перейдя на есп32.

                  0
                  А вот интересно: чем esp32 будет лучше?
                  У меня сейчас в качестве «мозгов» используется Arduino Due, я думаю заменить ее на Teensy 4.0, уже даже лежит наготове, но пока что Due справляется и нет надобности.
                    0
                    А вот интересно: чем esp32 будет лучше?

                    1) есть rmt — можно генерить аппаратно шим сигнал, аналогичный ppm модуляции — до 32 импульсов на канал. всего каналов 8. в теории можно таким макаром прикрутить до 32 x 8 серв (с использованием 4 x 8 сдвиговых регистров — каждый по 8 бит).
                    2) есть два pwm led (hispeed и lowspeed) каждый 8 канальный, в теории еще +16 серв.
                    3) блютуз и вайфай на борту.

                      0
                      Мне кажется это дело вкуса. Мне очень не нравится документация на ESP32, работа с WIFI через закрытую либу, неизвестно что там. На STM можно без проблем организовать аналоговые изменения, коммуникацию по I2C, USART, SPI почти без участия проца используя DMA (не знаю если DMA в ESP).

                      К примеру, сейчас прошивка гексапода использует 46% ресурсов проца (FLASH и RAM) и еще остался большой запас по производительности, можно очень многое туда добавить. FPU на борту сильно сокращает время работы с дробными числами, что опять же позволяет добавить более сложную математику.

                      Для меня ESP остается Arduin`кой и я не могу воспринять её всерьез :)
                        0
                        не знаю если DMA в ESP

                        есть, почти на каждую переферию свой отдельный dma


                        FPU на борту

                        ну таки тоже у есп32 имеется:
                        IEEE 754-compliant single-/double-precision scalar floating-point unit


                        Для меня ESP остается Arduin`кой и я не могу воспринять её всерьез :)

                        Почему? Вполне серьезный агрегат. Документация кстати гараздо лучше чем на 8266.

          0
          Корпус получился классный!
          Обратил внимание на изогнутую форму бедренной части. Идея интересная: изрядно уменьшает плечо нагрузки, облегчая жизнь сервоприводов. И в сложенном варианте сам робот занимает меньше места. Надо будет у вас скопировать эту идею, пока вы ее не запатентовали ))). Но только после того как устраню упитанность своей Гексы.
          Сейчас задумался о переходе на более компактный dc-dc стабилизатор и контроллер ESP32, возможно немного придется расширить раму робота.
          Смущает миниатюрность подшипников. Какие у них характеристики? Как долго смогут выполнять свои задачи под весом робота? Если можно, поделитесь ссылкой где их заказывали.
          В прошлой статье вы анонсировали некоторые изменения. В частности, хотели установить датчики касания на лапы. В текущей реализации их нет. Вы отказались от этой идеи или еще планируете? Если планируете, как будете размещать провода от концевиков?
          И напоследок чуток по программной части. У вас уже организован канал соединения по WiFi, через который вы можете гонять как медиа, так и управление. Для чего потребовался переход на Bluetooth?
            0
            Сейчас задумался о переходе на более компактный dc-dc стабилизатор
            Какой планируете использовать?

            Смущает миниатюрность подшипников. Какие у них характеристики? Как долго смогут выполнять свои задачи под весом робота? Если можно, поделитесь ссылкой где их заказывали.
            Сложный вопрос. Я не думаю что они разобьются быстро, нагрузки не высокие. Конкретных цифр к сожалению назвать не могу. Из характеристик могу назвать только размеры: 3х8х3. История появления именно этих подшипников простая — это единственные подшипники, которые были в наличии под 3мм фанеру (чтобы не торчали). Купил их у себя в городе, благо там есть магазинчик :)

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

            Фотки




            И напоследок чуток по программной части. У вас уже организован канал соединения по WiFi, через который вы можете гонять как медиа, так и управление. Для чего потребовался переход на Bluetooth?
            Перехода пока не было, но на всякий случай я оставил эту возможность. При коммуникации через WIFI в телефоне не будет интернета, в этом случае приложение не сможет проверить наличие новой версии FW, либо загрузить конфигурацию с сервера и реализовать обновление по воздуху. Но возможность без проблем гонять медиа для меня важнее, поэтому пока остался WIFI.
              0
              Какой планируете использовать?

              Заказал партию таких вот малышек.

              mini360 dc-dc
              Рабочая температура: -40° +85°
              Модель: Mini-360
              Вес, грамм: 1
              Размер: 17 * 11 * 3.8 мм
              Максимальный выходной ток, А: 3.0 (кратковременно)
              Мин. входное напряжение: 4.75
              Максимальное входное напряжение, В: 23.0
              Выходное напряжение, В: 1.0 — 17.0
              Номинальный выходной ток, А: 1.8
                +1
                о мне тоже как раз такие придут завтра для моего монстра.
                Я рассчитываю из 7.4 в 5 конвертировать. Надеюсь обойдется без радиаторов.
                  0
                  Я не поделитесь фотографиями монстра :)
                    0
                    Да конечно. Я его еще лет пять назал спроектировал, наконец добрался до производства. Я его изначально в металле проектировал изначально под сервы MG996R но по разным причинам в том числе из-за переезда задвинул в долгий ящик, да и не было лазерной резки в городе.
                    image
                    image

                    тут недавно попались RDS3225 сервы, да я и заказл 18 штук, перепроектировал узлы, потому что новый сервопривод как раз для роботов (с одной стороны вал с другой полуось опорная) что упростило часть узлов даже.
                    и получилось это.
                    image
                    заказал в металле. прицепил драйвер на 32 канала.

                    видео прошлой недели.
                    m.vk.com/video2389632_456239308

                    есть проблемы. Часть перемычек в femura нужно переделать потому что на не смотря на вечер со штангенциркулем я таки ошибся на миллиметр с отверстиями )) а все потому что они с разных сторон корпуса мерва не симметричные блин ) Новы спроектировал. Чуть поменял лапки, сдвину отверстия для ребра жесткости ниже чтобы увеличить доступный угол femura-tibia, ну и капельку короче. Нужно полностью переделать кончики лап, у меня точка контакта лапы с полом 10x20мм получилось, вообще не годится никуда, волочит лапы) уже перепроектировал нужно заказать печать.
                    Я нарезал всё из АМГ3М 2мм — все-таки мягковат для лап. Сейчас есть вариант или из АМЦ2Н или из титана )
                    Управление в данный момент накидал для orange pi код модуля для подключения беспроводного ps2 контроллера. Аккумулятор я решил попробовать 7.4 на 35А (2s4p схема) и понижающие dc-dc. А дальше буду думать, наверно тоже буду смотреть как и вы в сторону отдельной плоты которая будет отвечать за питание, которой можно будет рулить напряжением и силой тока. В данный момент занимаюсь обратной кинематикой )
                    Да у меня робот двусторонний, то есть его можно перевернуть вверх-ногами, он меняет углы лап и побежал дальше по своим делам ) потому такая конструкция. Думаю чуть уже тело сделать и средние лапы еще выдвинуть миллиметров на 10. И наверно откажусь от штанг в качестве перемычек жесткости tibia и сделаю длинное плечо для серва и оно же будет ребром жесткости (ширина лап всего на 4мм вырастет а жесткость конструкции многократно с устойчивостью к перекосам и прочему) Уже практически все перепроектировал, в том числе и с гибкой на ЧПУ прессе.

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

            Самое читаемое