Комментарии 36
Добавляйте:
1) https://www.seeedstudio.com/item_detail.html?p_id=2573. Очень дёшево (ну да, это маркетинговый проект MediaTek, подозреваю, что продают они его в ноль, но что ж с того), по ресурсам богаче нашего Unwired One и Onion Omega. Минус — не уверен, что это можно как-то в России официально купить.
2) Intel Edison (ну да, я понимаю, что тут про MIPS, но читатель таки имеет право знать). Недёшево, зато там много мегабайт и мегагерц. Его немного трудно купить в розницу, но это вопрос, который при небольшом желании можно решить. Ну и у нас в Unwired Kit планируется плата-адаптер под Edison, которая позволит с ним использовать как разные платы расширения, так и наши беспроводные сети.
Но в принципе для какого-то машинного зрения и т.п. задач этого всего мало, там более другие мощности по-хорошему нужны. А более другие мощности — это или Raspberry Pi, или более другие цены.
P.S. VoCore — сразу в хлам, там медленный и горячий Ralink стоит. Они сейчас делают вторую версию на медиатеке.
А почему не рассматриваете Raspberry Pi? Соотношение цена/качество/возможности на мой взгляд очень даже.
У меня несколько другая задача. Я не пытаюсь составить каталог всех возможных устройств для роботики. У меня есть платформы, с которыми я умею работать (в создании некоторых из них я принимал участие), и я пытаюсь понять, какие из этих платформ пригодны для того, что у меня спросили (обучение роботике), а какие — нет. Я ожидаю комменты типа «платформа XYZ для роботики непригодна, так как ее производительность/память не позволит выполнять такой-то алгоритм распознавания, а среди периферии нет интерфейса к такому-то классу активаторов».
Может я ошибаюсь, но мне показалось что у Вас в статье как то нечетко сформулированы требования.
Распознавание образов и общее управление — это одна задача решаемая одним классом "платформ".
Управление (сервоприводами например) и сбор информации с датчиков (зачастую не слишком "умных") — это совершенно другая задача решаемая другим классом "платформ" (Контроллеры).
Все Вами перечисленные платформы — это смесь того и другого (ну типа как Cortex Ax и Cortex Mx вместе смешать и сравнивать).
Мне кажется нужно как то разделить задачи. И под каждую свою платформу выбирать.
А с распознаванием образов с использованием OpenCV в реальном времени, по моему, разве что MIPS Creator ci20 справится… (возможно… но не уверен).
Интересное соображение. А что сейчас вкладывается в словосочетание «интеллектуальная система»?
несколько поздновато отвечаю (не смотрел почту на выходных)…
Мне кажется (лично мне), что гораздо практичнее делать распределенную систему. Первичной обработкой данных и управлением железом занимаются контроллеры, а задачей принятия решения и сложной обработкой занимается другой модуль.
По крайней мере, именно по такому принципу я делал (чисто поиграться) робота (колесное шасси + манипулятор + куча датчиков).
Плата гироскопа и акселерометра — свой контроллер (ATMega8). Сканер (шаговый двигатель + ультразвуковой дальномер) + управление ШИМ сервомашинок манипулятора + ШИМ 4-х двигателей колес + шаговые двигателе обзорной видеокамеры — STM32F103.
А общее управление через отдельный протокол (радиоканал) — программа на Linux с расчетом, что бы можно было Малину прямо на борт поставить… Управление отдельными (физически отдельными) модулями со своими контроллерами по относительно высокоуровневому API.
Ну так просто проще. Все же управлять в режиме реального времени кучей периферии на низком уровне под Linux — не реально (как минимум сложнее чем на голом контроллере). A написать специализированное ПО в виде "черного ящика" с заданным API и функционалом под конкретный контроллер просто. Контроллеры для этого и предназначены.
А под Linux удобно делать/отлаживать общее управление и сложные задачи с использованием готовых библиотек типа OpenCV.
У меня такое ощущение, что все подразумевают что то, чуть чуть да свое.
Предпочитаю не теоретизировать, а решать конкретные задачи.
Мне кажется (лично мне), что гораздо практичнее делать распределенную систему. Первичной обработкой данных и управлением железом занимаются контроллеры, а задачей принятия решения и сложной обработкой занимается другой модуль.
По крайней мере, именно по такому принципу я делал (чисто поиграться) робота (колесное шасси + манипулятор + куча датчиков).
Плата гироскопа и акселерометра — свой контроллер (ATMega8). Сканер (шаговый двигатель + ультразвуковой дальномер) + управление ШИМ сервомашинок манипулятора + ШИМ 4-х двигателей колес + шаговые двигателе обзорной видеокамеры — STM32F103.
А общее управление через отдельный протокол (радиоканал) — программа на Linux с расчетом, что бы можно было Малину прямо на борт поставить… Управление отдельными (физически отдельными) модулями со своими контроллерами по относительно высокоуровневому API.
Ну так просто проще. Все же управлять в режиме реального времени кучей периферии на низком уровне под Linux — не реально (как минимум сложнее чем на голом контроллере). A написать специализированное ПО в виде "черного ящика" с заданным API и функционалом под конкретный контроллер просто. Контроллеры для этого и предназначены.
А под Linux удобно делать/отлаживать общее управление и сложные задачи с использованием готовых библиотек типа OpenCV.
А что сейчас вкладывается в словосочетание «интеллектуальная система»?
У меня такое ощущение, что все подразумевают что то, чуть чуть да свое.
Предпочитаю не теоретизировать, а решать конкретные задачи.
«с моторчиками и другими активаторами» -> «актуаторами»
Почти все платы не подходят для робототехники, Linux не обеспечит real-time. Делать упор на производительность процессора и память — это не то что нужно. Нужны SPI, I2C, UART, USB HS, RF, GPIO и толерантность к 3/5 В. Выводы должны держать ток хотя бы 15мА. DMA контроллеры для периферии. Желательно параллельная шина 8-32 бит (для камеры, памяти, экран). Ну, и всегда помнить про силовую нагрузку двигателями + датчики (обратная связь).
Вот Intel в свои последние микропроцессоры для DIY встраивает гироскоп/аккс/компас + термометр.
Digilent chipKIT Wi-FIRE, микроконтроллерная плата с Microchip PIC32MZ EF кажется лучшим кандидатом.
Вот Intel в свои последние микропроцессоры для DIY встраивает гироскоп/аккс/компас + термометр.
Digilent chipKIT Wi-FIRE, микроконтроллерная плата с Microchip PIC32MZ EF кажется лучшим кандидатом.
Спасибо. Ну как контроллер с RTOS и SPI, I2C и DMA плата Digilent chipKIT Wi-FIRE лучше всего в списке. Но есть в робототехнике всякие не-real-time задачи сложного семантического распознавания образов, которые можно было бы решать на более высокопроизводительном встроенном компьютере типа MIPS Creator ci20? Типа чтобы сделать связку из Digilent chipKIT Wi-FIRE и MIPS Creator ci20?
Я понимаю, что вы продвигаете MIPS, и мне как программисту не очень важно, что внутри микропроцессора и какой набор инструкций — MIPS, 8051, ARM. Всё равно на С (С++) пишется всё. Вопрос упирается в среду разработки, библиотеки и сообщество, как тут верно заметили. И в этом плане Atmel, RPi и STM32 лидируют.
Насколько мне известно, в учебный процесс у нас в стране пошёл Milandr 1986. Это достойный чип, который избавился от «детских болезней». Я с ним работал, хорошее впечатление, периферия, толерантность, ADC/DAC, и платы сейчас в Зеленограде доступны по 4-5 тыс.р. Но для «самоделкиных» STM32 за 200р. вне конкуренции. Смогут ваши платы в 1000р. уложиться?
Насчёт идеи раздельной обработки данных. Сейчас вроде только такой подход и есть. Но вот я знаю, Toshiba сделала на Cortex-M платы с распознаванием образов и, естественно, с периферией и софтом. Т.е. то что другие на ПЛИС делают, Toshiba реализовала на Cortex-M. Я думаю, если Cortex-M7 (или ваш MIPS 32) подешевеет и получит больше памяти и пойдёт в народ, то мы увидим много новых проектов. Хотя мне больше 8051 по душе.
Насколько мне известно, в учебный процесс у нас в стране пошёл Milandr 1986. Это достойный чип, который избавился от «детских болезней». Я с ним работал, хорошее впечатление, периферия, толерантность, ADC/DAC, и платы сейчас в Зеленограде доступны по 4-5 тыс.р. Но для «самоделкиных» STM32 за 200р. вне конкуренции. Смогут ваши платы в 1000р. уложиться?
Насчёт идеи раздельной обработки данных. Сейчас вроде только такой подход и есть. Но вот я знаю, Toshiba сделала на Cortex-M платы с распознаванием образов и, естественно, с периферией и софтом. Т.е. то что другие на ПЛИС делают, Toshiba реализовала на Cortex-M. Я думаю, если Cortex-M7 (или ваш MIPS 32) подешевеет и получит больше памяти и пойдёт в народ, то мы увидим много новых проектов. Хотя мне больше 8051 по душе.
Можно ссылку на платы с распознаванием образов от Toshiba? Это случаем не проект OpenMV?
Не могу утверждать что там за проекты. Год назад пытался войти с ними в контакт, не вышло. Вижу отдельно их линейку процессоров, обратите внимание на вторую часть, там где Cortex-R. Capricorn-Bt1, но плату на нём не вижу. Возможно, я напутал с распознаванием образов, прошу прощения, вижу у Toshiba отдельный процессор этим занят.
http://toshiba.semicon-storage.com/eu/product/automotive/display-controller/lineup.html
http://toshiba.semicon-storage.com/eu/product/automotive/micro.html
http://toshiba.semicon-storage.com/eu/product/automotive/display-controller/lineup.html
http://toshiba.semicon-storage.com/eu/product/automotive/micro.html
Платы с STM32 безусловно очень дешевы и для рынка «самоделкиных» против них идти трудно. Но рынок образовательных программ для университетов — это не то же самое, что и рынка «самоделкиных». Например, покажите мне аналог курса Connected MCU, не на на основе Microchip PIC32MZ EF, а на основе STM32. Курс Connected MCU (см. https://habrahabr.ru/post/282001/ ) создан для обучения программированию микроконтроллеров и содержит не только традиционное мигание лампочками и соединения с простой периферией, но и материалы про RTOS, элементы микроархитектуры встроенного процессора и лабы по наблюдению поведения кэшей.
I/O надо делать на EtherCAT — там очень неплохие характеристики по задержкам и пропускной способности.
А платформу надо брать ту, для которой есть хороший рантайм для Matlab/Simulink. Так получите наилучшую среду для разработки и тестирования алгоритмов управления роботами.
А платформу надо брать ту, для которой есть хороший рантайм для Matlab/Simulink. Так получите наилучшую среду для разработки и тестирования алгоритмов управления роботами.
Это очень интересно. А можете показать пример использования Matlab/Simulink для роботов?
Не могли бы вы привести пару примеров плат с хорошим райнатаймом для Matlab/Simulink?
EtherCAT стоит хороших денег ввиду лицензирования технологии. На этой ниве, если уж брать во внимание промышленные протоколы, то вполне себе можно CanOpen освоить. Он, конечно, не для трансляций FullHD контента, но свою роль выполняет практически идеально.
Соглашусь с матлабом и добавлю LabView.
Соглашусь с матлабом и добавлю LabView.
Если оно для обучения — то надо быть готовым к тому, что *каждый* ученик сломает пару-тройку в ходе экспериментов. Так что подходит или нет — определяется, в первую очередь, бюджетом.
И всё же для «обучения», то есть научения ребят, главнейший критерий — сформированное Сообщество. У Raspberry Pi — оно очень большое. А это значит, что ребята смогут находить примеры, просить совета и пояснений в Сети.
Сколько раз я видел роботов, у которых «зрение» работает на «большом компьютере», а логика самого робота (принятие решений по движению) — на Arduino. Поскольку примеры ребята нашли именно под «старый» восьмибитный контроллер…
В общем — начинайте выбирать с Сообщества — где больше, тот контроллер лучше для Вашей задачи.
Сколько раз я видел роботов, у которых «зрение» работает на «большом компьютере», а логика самого робота (принятие решений по движению) — на Arduino. Поскольку примеры ребята нашли именно под «старый» восьмибитный контроллер…
В общем — начинайте выбирать с Сообщества — где больше, тот контроллер лучше для Вашей задачи.
А ROS на все эти платы можно установить? Ибо платформа без ROS для серьезной робототехники бесполезна.
а RTOS редко используют напрямую для быстродействующих вещей. В основном используется прослойка в виде FPGA, на котором генерируются сигналы высокой точности, также он же и предварительно обрабатывает поступающие извне сигналы, это сильно снижает требования к системе, на которой находятся основные, высокоуровневые алгоритмы обработки данных и принятия решений на их основе.
Вкратце, дешманская малинка и какой-то Спартан вполне могут управлять парой робоманипуляторов-рук и при этом показывать очень приличные показатели точности и контроля позиции. И при этом не вываливаться за пределы бюджета в пару сотен долларов в железе. Использование аналогичной железки, которая поддерживает RTOS выльется далеко за пределы этого бюджета.
Вкратце, дешманская малинка и какой-то Спартан вполне могут управлять парой робоманипуляторов-рук и при этом показывать очень приличные показатели точности и контроля позиции. И при этом не вываливаться за пределы бюджета в пару сотен долларов в железе. Использование аналогичной железки, которая поддерживает RTOS выльется далеко за пределы этого бюджета.
Тут имеется ввиду ROS (Robot Operating System) — Операционная система для роботов
Понял.
Тогда понятие «серьёзной робототехники» и ROS не особо совместимы. Серьёзные роботы (промышленные, медицинские, от Диаконт для атомной промышленности) не работают под ROS. И никогда не будут. А эксперименты типа пылесосов и прочих мобильных платформ, заточенных под «свободу действий» это пока не особо серьёзно. Было бы интересно, если бы ROS была менее требовательна к железу, но и тут пичаль.
ИМХО тупиковое направление. Я бы не стал на этой основе строить учебный процесс.
Тогда понятие «серьёзной робототехники» и ROS не особо совместимы. Серьёзные роботы (промышленные, медицинские, от Диаконт для атомной промышленности) не работают под ROS. И никогда не будут. А эксперименты типа пылесосов и прочих мобильных платформ, заточенных под «свободу действий» это пока не особо серьёзно. Было бы интересно, если бы ROS была менее требовательна к железу, но и тут пичаль.
ИМХО тупиковое направление. Я бы не стал на этой основе строить учебный процесс.
Во-первых есть ROS Industrial. Во-вторых все серьезные автономные роботы работают под РОС. Не индустриальное, но всякие охранные, автономные, сервисные и тп.
«ИМХО тупиковое направление. Я бы не стал на этой основе строить учебный процесс.»
После такого заявления можно сделать вывод, что вы либо слабо понимаете что такое РОС, либо слабо понимаете современную робототехнику. Сейчас никто не пишет SLAM или другие серьезные вещи с нуля на коленке. Под этим я и понимал «серьезную» робототехнику.
«ИМХО тупиковое направление. Я бы не стал на этой основе строить учебный процесс.»
После такого заявления можно сделать вывод, что вы либо слабо понимаете что такое РОС, либо слабо понимаете современную робототехнику. Сейчас никто не пишет SLAM или другие серьезные вещи с нуля на коленке. Под этим я и понимал «серьезную» робототехнику.
ROS официально поддерживается в Matlab, а также в Labview.
Вот тут дан хороший ответ по поводу ROS и Matlab.
http://answers.ros.org/question/56721/ros-vs-matlabwhich-is-best/?answer=56859#post-id-56859
«I see MATLAB (Octave or Scilab) as a great tool for the prototyping phase…
After this phase there is the system development phase (design and implementation).
In this phase you design and implement the code you have prototype in MATLAB and other functionalities that are necessary to make your system work.
ROS provides this functionality out-of-the-box, and a lot of extra components ready to use.»
Вот тут дан хороший ответ по поводу ROS и Matlab.
http://answers.ros.org/question/56721/ros-vs-matlabwhich-is-best/?answer=56859#post-id-56859
«I see MATLAB (Octave or Scilab) as a great tool for the prototyping phase…
After this phase there is the system development phase (design and implementation).
In this phase you design and implement the code you have prototype in MATLAB and other functionalities that are necessary to make your system work.
ROS provides this functionality out-of-the-box, and a lot of extra components ready to use.»
а ещё через несколько ответов окажется, что существует ROS-Industrial-Professional-Enterprise-Mega, которая вообще ИИ и работает на монетке в 10 копеек.
И не надо передёргивать, я не говорил о написании чего-то «с нуля», и понятие «серьёзности» это далеко не использование готовых фреймворков, а стоимость техпроцесса, в котором участвует робот. Если для вас серьёзность заключается в том, что на пылесосе стоит РОС и пылесос распознаёт кота, то у нас разные понятия о серьёзности.
И не надо передёргивать, я не говорил о написании чего-то «с нуля», и понятие «серьёзности» это далеко не использование готовых фреймворков, а стоимость техпроцесса, в котором участвует робот. Если для вас серьёзность заключается в том, что на пылесосе стоит РОС и пылесос распознаёт кота, то у нас разные понятия о серьёзности.
А вы как видите процесс разработки робототехнических систем? Я совсем новичок в области и хотелось бы знать о каких роботах идет речь?
а кто на что способен. нива эта настолько обширна в плане разнообразности решений, что тут есть исключительно ИМХО, и кто будет утверждать обратное — дилетант. Поэтому я и выразил лично своё мнение.
Те роботы, с которыми мне приходилось сталкиваться работали на ПЛК производителя, программировались на примитивных языках типа LD/FBD/etc, изредка приходилось поднимать из могил старинные манипуляторы, оснащать их новыми сервоприводами и рулить логику работы на NI SbRIO через LabView. ничего экстраординарного типа «найти выход из безвыходной ситуации с помощью нейросети» не было, просто траектория + иногда машинное зрение (определить позицию и наличие перемещаемого компонента). но все эти операции требовали максимальной точности, повторяемости и бесперебойной работы. ибо косяк в работе системы чреват потерей иногда жирного бабла. В таких случаях ессно никто не будет использовать ни рос, ни какие-то иные решения, которые имеют массу непонятно как работающего кода. то как с LinuxCNC — система крутая, гибкая и всё такое, но почему-то EMG ставят на свои станки FANUC.
Те роботы, с которыми мне приходилось сталкиваться работали на ПЛК производителя, программировались на примитивных языках типа LD/FBD/etc, изредка приходилось поднимать из могил старинные манипуляторы, оснащать их новыми сервоприводами и рулить логику работы на NI SbRIO через LabView. ничего экстраординарного типа «найти выход из безвыходной ситуации с помощью нейросети» не было, просто траектория + иногда машинное зрение (определить позицию и наличие перемещаемого компонента). но все эти операции требовали максимальной точности, повторяемости и бесперебойной работы. ибо косяк в работе системы чреват потерей иногда жирного бабла. В таких случаях ессно никто не будет использовать ни рос, ни какие-то иные решения, которые имеют массу непонятно как работающего кода. то как с LinuxCNC — система крутая, гибкая и всё такое, но почему-то EMG ставят на свои станки FANUC.
В принципе процесс разработки робототехнических систем не отличается от процесса разработки любых других систем управления реального времени. Будь то система управления самолетом, лифтом или промышленным конвейером. Чаще всего это встраиваемые системы, но может быть и другая реализация.
В общем случае выбор средств, платформы, и методов разработки зависит от требований к самой системе, начиная от функциональных требований, требований к надежности и заканчивая ценой конечного изделия и стоимости разработки/времени, потраченного на проект. Поэтому даже для робототехнических проектов, из-за последних требований, реализация может быть разной — от ардуины и до промышленных контроллеров за 10 тыс баксов.
Лично для лаборатории робототехники или платформы для обучения я считаю важным, чтобы средства охватывали максимально возможный спектр приложений. Чтобы студенты учились на чем-та таком, что применяется в реальных системах и в конце концов получали знания, которые потом могли бы применить в будущем в работе и карьеры.
С этой точки зрения, как уже указали, промышленные ПЛК уже сами по себе являются неплохим желехом для лаборатории — даже если робота не получится создать, общие принципы создания хард-реал-тайм систем привьются конкретно. Но если стеснены в средствах, то подойдет и распберри.
Саму софтверную платформу — операционки, драйвера, интерфейсы связи я даже не рассматриваю — тут такой разнобой, что принуждать студентов изучать все это не имеет смысла — потеряете время и суть, а робота не сделаете.
Поэтому следует сконцентрироваться только на средствах разработки, программирования и тестирования управляющих алгоритмов. Лично для меня в этом деле Матлаб/Симулинк вне конкуренции. Вы моделируете свой алгоритм у себя на компьютере, а потом загружаете сгенерированный код в железо, где он исполняется в реальном времени и делает то же самое, что и в модели — вот и есть краткая суть процесса разработки в данном случае.
Данный подход (называется Model Based Design) применяется в промышленности, автомобильной электронике, самолетах, роботах и т.д уже вот уже как десятилетие и позволяет достичь значительного сокращения времени разработки управляющего софта при меньшей квалификации программиста. Точнее программист становится не нужен. Все делает сам разработчик алгоритма.
Ну и еще одно преимущество — вы можете начать делать свои алгоритмы для роботов с ардуино и распберри, а закончить сверхнадежной системой управления для HVDC — и все с одной средой.
В общем случае выбор средств, платформы, и методов разработки зависит от требований к самой системе, начиная от функциональных требований, требований к надежности и заканчивая ценой конечного изделия и стоимости разработки/времени, потраченного на проект. Поэтому даже для робототехнических проектов, из-за последних требований, реализация может быть разной — от ардуины и до промышленных контроллеров за 10 тыс баксов.
Лично для лаборатории робототехники или платформы для обучения я считаю важным, чтобы средства охватывали максимально возможный спектр приложений. Чтобы студенты учились на чем-та таком, что применяется в реальных системах и в конце концов получали знания, которые потом могли бы применить в будущем в работе и карьеры.
С этой точки зрения, как уже указали, промышленные ПЛК уже сами по себе являются неплохим желехом для лаборатории — даже если робота не получится создать, общие принципы создания хард-реал-тайм систем привьются конкретно. Но если стеснены в средствах, то подойдет и распберри.
Саму софтверную платформу — операционки, драйвера, интерфейсы связи я даже не рассматриваю — тут такой разнобой, что принуждать студентов изучать все это не имеет смысла — потеряете время и суть, а робота не сделаете.
Поэтому следует сконцентрироваться только на средствах разработки, программирования и тестирования управляющих алгоритмов. Лично для меня в этом деле Матлаб/Симулинк вне конкуренции. Вы моделируете свой алгоритм у себя на компьютере, а потом загружаете сгенерированный код в железо, где он исполняется в реальном времени и делает то же самое, что и в модели — вот и есть краткая суть процесса разработки в данном случае.
Данный подход (называется Model Based Design) применяется в промышленности, автомобильной электронике, самолетах, роботах и т.д уже вот уже как десятилетие и позволяет достичь значительного сокращения времени разработки управляющего софта при меньшей квалификации программиста. Точнее программист становится не нужен. Все делает сам разработчик алгоритма.
Ну и еще одно преимущество — вы можете начать делать свои алгоритмы для роботов с ардуино и распберри, а закончить сверхнадежной системой управления для HVDC — и все с одной средой.
lingvo, donvictorio спасибо за развернутые ответы, многие вещи прояснились.
Со студентами вроде все понятно. А как быть со школьниками? Что им давать когда из лего уже выросли, а матлаб рано? Может есть некий «Matlab or kids»? Хотя признаю, это наивно
Со студентами вроде все понятно. А как быть со школьниками? Что им давать когда из лего уже выросли, а матлаб рано? Может есть некий «Matlab or kids»? Хотя признаю, это наивно
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Какие из данных платформ подходят для лаборатории робототехники и интеллектуальных систем?