Comments 33
Впечатляет объем публикации. А ведь это только начало сбора робота :)
p.s. Может сделать робота, собирающего роботов? :-)
p.s. Может сделать робота, собирающего роботов? :-)
Робота пишущего статьи о сборке роботов? :-)
Не понимаю, что все так к объему статей придираются? Особенно не люблю, когда материал, который занимает страниц 5 А4 формата, разбивают на несколько постов. За примерами далеко ходить не надо. Вон вчерась один опубликовал перевод: «он очень объемный, так что будет две части» (с). А на деле читать особо нечего.
Конкретно к вам претензий естесственно нет, просто подвернулся коммент в тему под накипевшее :)
Сама статья нормального объема, основную часть которой кстати занимает код, который можно было спрятать под спойлер и статья сразу бы стала чище.
И раз уж начал писать коммент: спасибо автору топика за то, что поделился опытом :)
Конкретно к вам претензий естесственно нет, просто подвернулся коммент в тему под накипевшее :)
Сама статья нормального объема, основную часть которой кстати занимает код, который можно было спрятать под спойлер и статья сразу бы стала чище.
И раз уж начал писать коммент: спасибо автору топика за то, что поделился опытом :)
Интересно, добавлю в избранное чтобы почитать по-внимательнее на досуге.
Если будет продолжение, в конце этой статьи сделайте ссылки на следующие части.
Кстати, а вместо BlueTooth можно ли Wi-Fi использовать?
Ещё в качестве спинного мозга хотелось бы использовать что-то по-сильнее Arduino, например старый нетбук с Linux. Можно ли управлять серво из Linux?
Если будет продолжение, в конце этой статьи сделайте ссылки на следующие части.
Кстати, а вместо BlueTooth можно ли Wi-Fi использовать?
Ещё в качестве спинного мозга хотелось бы использовать что-то по-сильнее Arduino, например старый нетбук с Linux. Можно ли управлять серво из Linux?
-Вместо BlueTooth можно использовать Wi-Fi модуль, к примеру вот такой
dx.com/ru/p/vrm04-multifunction-uart-serial-port-to-ethernet-wi-fi-converting-adapter-module-w-antenna-blue-215334
но данный модуль стоит дороже, сам объемнее и весит больше по сравнению с БТ модулем.
-из Linux управлять можно, даже более того на базе Linux существует ROS(robot operation system — www.ros.org ), главное определиться по какому порту управлять серво моторами, и все равно придется использовать либо микроконтроллер либо другую микросхему, которая преобразует команду от нетбука в сигналы подаваемые на драйвера моторов.
dx.com/ru/p/vrm04-multifunction-uart-serial-port-to-ethernet-wi-fi-converting-adapter-module-w-antenna-blue-215334
но данный модуль стоит дороже, сам объемнее и весит больше по сравнению с БТ модулем.
-из Linux управлять можно, даже более того на базе Linux существует ROS(robot operation system — www.ros.org ), главное определиться по какому порту управлять серво моторами, и все равно придется использовать либо микроконтроллер либо другую микросхему, которая преобразует команду от нетбука в сигналы подаваемые на драйвера моторов.
Посмотрите в сторону BeagleBone, а также Raspberry Pi и подобных плат — полноценный компьютер с портами GPIO и многими другими, и размером как Arduino Uno.
Я тоже потихоньку делаю робота для детей и рассматривал вариант с Rapberry Pi. Малинка намного быстрее чем Arduino, однако GPIO не буферизовано и сгорает от малейшей ошибки, отсутсвуют ШИМ-выходы (управление моторами, серво) и аналоговые входы (дешёвые дальномеры). На ардуино легко писать работающий в реальном времени софт, использовать прерывания (например для счёта импульсов с энкодеров на колёсах).
В результате остановился на гибридной схеме, когда Arduino занимается сенсорами и моторами и обрабатывает простейшие рефлексы. Например если дальномеры регистрируют пропасть, то нужно сразу же остановить моторы чтоб не упасть со стола. Raspberry играет роль головного мозга — к ней подключена камера с микрофоном (вынуто из дешёвой веб-камеры) и простейший аудиоусилитель с динамиком. На Raspberry крутится веб-сервер который занимается логикой и передаёт в ардуинный «спинной мозг» комманды вроде «развернись вправо на 90 градусов». Микрокомпьютеры соединяются по последовательному порту (выведен на GPIO) через преобразователь логических уровней 3,3V <-> 5V.
Пока у меня готова только механика, плюс оттестирована работа Arduino с датчиками, так что статья на хабре с полным кодом включая веб-сервер появится скорей всего уже весной. Фотографии можно посмотреть здесь.
В результате остановился на гибридной схеме, когда Arduino занимается сенсорами и моторами и обрабатывает простейшие рефлексы. Например если дальномеры регистрируют пропасть, то нужно сразу же остановить моторы чтоб не упасть со стола. Raspberry играет роль головного мозга — к ней подключена камера с микрофоном (вынуто из дешёвой веб-камеры) и простейший аудиоусилитель с динамиком. На Raspberry крутится веб-сервер который занимается логикой и передаёт в ардуинный «спинной мозг» комманды вроде «развернись вправо на 90 градусов». Микрокомпьютеры соединяются по последовательному порту (выведен на GPIO) через преобразователь логических уровней 3,3V <-> 5V.
Пока у меня готова только механика, плюс оттестирована работа Arduino с датчиками, так что статья на хабре с полным кодом включая веб-сервер появится скорей всего уже весной. Фотографии можно посмотреть здесь.
Я тоже потихоньку делаю робота для детей и рассматривал вариант с Rapberry Pi. Малинка намного быстрее чем Arduino, однако GPIO не буферизовано и сгорает от малейшей ошибки, отсутсвуют ШИМ-выходы (управление моторами, серво) и аналоговые входы (дешёвые дальномеры). На ардуино легко писать работающий в реальном времени софт, использовать прерывания (например для счёта импульсов с энкодеров на колёсах).
Поэтому я и написал сначала про BeagleBone: стоит почти столько же, но больше GPIO, есть ШИМ-выходы, АЦП и другое. Прерывания кстати тоже можно обрабатывать нормально, при большом желании даже некоторые realtime-фичи можно сделать (но не думаю, что понадобится — всё-таки производительность намного больше ардуины). Мне сейчас едут детали для робота, в качестве мозга как раз эта плата планируется :)
Согласен с тем, что стоит все-таки рассмотреть альтернативы. Например, вариант, основанный на Raspberry Pi: habrahabr.ru/company/grambo_pi/blog/203124/
В этом случае отпадает необходимость в Bluetooth и программировать можно непосредственно как сам Raspberry Pi, так и контроллер.
В этом случае отпадает необходимость в Bluetooth и программировать можно непосредственно как сам Raspberry Pi, так и контроллер.
Уважаемые, а за что меня «минусуют»? Я же задал вопрос по теме.
Нашёл вот интересные контроллеры:
http://www.pololu.com/product/1356
к компьютеру цепляются по USB и позволяют управлять серво-приводами. Программировать можно на Java, что должно обеспечить кросс-платформенность.
http://www.pololu.com/product/1356
к компьютеру цепляются по USB и позволяют управлять серво-приводами. Программировать можно на Java, что должно обеспечить кросс-платформенность.
Из того, что бросилось в глаза: вы неправильно делаете debounce. Смысл процедуры состоит в том, чтобы убедиться, что контакт стабилен в течение некого промежутка времени, а вы проверяете в начале и в конце 80мс промежутка. А надо так:
const int debounceDelay = 10; // milliseconds to wait until stable
boolean debounce(int pin) { // Used to distinguish between phantom keypresses and real ones.
boolean state;
boolean previousState;
previousState = digitalRead(pin); // We store switch state,
for (int counter=0; counter < debounceDelay; counter++) {
delay(1); // wait for 1 millisecond,
state = digitalRead(pin); // read the pin,
if (state != previousState) {
counter = 0; // reset the counter if the state changes,
previousState = state; // and save the current state,
}
}
return state; // here when the switch state has been stable longer than the debounce period.
} Ваш код безусловно выглядит красивее, но дребезг контактов длится несколько микросекунд, поэтому приведенный мною код также работоспособен, так как состояние нажатия кнопки проверяется через 80 миллисекунд, к этому времени дребезг уже отсутствует.
Да ладно, вполне работоспособный код, только время надо увеличить. Будет почти что НЧ-фильтр, для частот ниже 1/2Т, согласно дедушке Котельникову :)
Вот например www.ni.com/example/31251/en/
А ваш код вносит задержку в программу целых 10 мс на обработку каждого нажатия, а за это время можно как минимумв космос улететь 10 тысяч инструкций выполнить.
Вот например www.ni.com/example/31251/en/
А ваш код вносит задержку в программу целых 10 мс на обработку каждого нажатия, а за это время можно как минимум
я скопипастил из личного проекта — там речь идёт об управлении вентилями подачи водопроводной воды на 220 вольт, так что с 10ms — это я конкретно перестраховывался, пяти замеров подряд хватит с головой. В любом случае, несколько последовательных замеров лучше, чем только два.
А нет, я наврал, у автора тоже делэй на 80 мс. А надо просто опрашивать состояние входа по таймеру (время сэмплирования), если, например, два раза подряд «1» то кнопка нажата, если 4 раза — кнопка долго нажата. А в свободное от опроса кнопок время другой код выполнять — реалтаймовая система.
Я вижу вы разрабатываете собственный протокол для общения с Arduino. Может имеет смысл использовать стандартный протокол Firmata, он как раз предназначен для коммуникации умных устройств со «спинным мозгом» на Arduino.
Когда создавал систему управления подсветкой — habrahabr.ru/post/165861/, то писал так же методы отправки-получения данных в/из Ардуино через синезуб. Столкнулся с тем, что часть данных в отправляемых пакетах терялась — из-за чего даже пришлось вводить валидаторы на полученные данные.
Вы с этим столкнулись?
Вы с этим столкнулись?
Не много не по теме робототехники, но добавлю свои 2 копейки. Все же советую сразу избавиться от BT и перейти на WiFi. Пусть дороже и тяжелее. Но более стабильная связь.
По работе реализовывал протокол общения iPod'ов с внешним BT устройством. В тепличных условиях все работало стабильно. Но как только вышли из теплицы, то выползли проблемы. Начали тестировать у себя и оказалось что как только в зоне связи появляется еще несколько BT устройств (телефоны, гарнитуры и т.п.), то передаваемые данные просто пропадают. Т.е. я фиксирую отправку данных, а до внешнего устройства они не доходят.
Пришлось разработчиков просить реализовать WiFi. Проблемы со связью ушли.
По работе реализовывал протокол общения iPod'ов с внешним BT устройством. В тепличных условиях все работало стабильно. Но как только вышли из теплицы, то выползли проблемы. Начали тестировать у себя и оказалось что как только в зоне связи появляется еще несколько BT устройств (телефоны, гарнитуры и т.п.), то передаваемые данные просто пропадают. Т.е. я фиксирую отправку данных, а до внешнего устройства они не доходят.
Пришлось разработчиков просить реализовать WiFi. Проблемы со связью ушли.
Что за сайт такой dx.com/, первый раз встречаю. Как быстро доставляют? Почему там, а не на ebay? Цены на dx чуть выше, но незначительно.
Это китайский сайт. Я живу в г.Благовещенске напротив китайского г.Хэйхэ, поэтому имею возможность заказывать товар с ТаоБао, dx либо с других китайских сайтов, доставлять их в Хэйхэ(5-7 дней), а от г.Хэйхэ до г.Благовещенска — 1-2 дня. Таким образом скорость доставки очень высокая.
Вам надо бизнес налаживать, с Благи до Москвы даже почта россии за 7 дней доставит, итого две недели. С ebay мне по два месяца доставляют, на данный момент так и не доставили некоторые товары заказанные 4-го октября! Товары ушли в архив и теперь даже претензию некому предъявить. По адекватным ценам я б лучше с Благи заказывал.
Из китая EMS за ~7 дней доставил… но ценник… грустный, да. А человеку, чтобы массово ввозить придётся же кучу бумажек оформлять… в общем ценник до EMS-ного поднимется… и зачем тогда?
Спасибо за совет. У меня уже имеется сайт, по доставке товаров с таобао, но торговля, мне не по душе, больше интересует ит и робототехника
Читая подобные статьи по робототехнике и учитывая свой опыт, все чаще приходит одна мысль.
Подобные проекты полезны в основном для самого экспериментатора, так как он приобретает опыт, как в разработке, так и в точном изложении своих действий. За это и поддерживаю автора.
А мысль заключается в том, что подобные посты уже теряют свою новизну и привлекательность, так как по сути ничего нового для сообщества не дают. ИМХО нужны отдельные законченные функциональные блоки для предобработки сенсорной информации и механические блоки-приводы (например механическая рука и интерфейсвзаимодействия с ней, система команд). Наверняка подобные проекты есть, но на хабре я их не видел.
Вот тогда, объединив «мозг» и «руку», робот будет более похож на себя и проект будет обладать новизной.
Подобные проекты полезны в основном для самого экспериментатора, так как он приобретает опыт, как в разработке, так и в точном изложении своих действий. За это и поддерживаю автора.
А мысль заключается в том, что подобные посты уже теряют свою новизну и привлекательность, так как по сути ничего нового для сообщества не дают. ИМХО нужны отдельные законченные функциональные блоки для предобработки сенсорной информации и механические блоки-приводы (например механическая рука и интерфейсвзаимодействия с ней, система команд). Наверняка подобные проекты есть, но на хабре я их не видел.
Вот тогда, объединив «мозг» и «руку», робот будет более похож на себя и проект будет обладать новизной.
Понятное дело, что если автор тратит своё время и деньги, то он расчитывает извлечь из этого пользу, например в виде обучения. Робот хорош тем, что определяет понятную, интересную, видимую цель, задаёт критерии для оценки хорошо ли сделана работа. Если просто поставить себе расплывчатую задачу «а вот было-бы неплохо научиться программировать под андроид», то есть риск при первых же трудностях пойти по пути наименьшего сопротивления, а то и просто забросить дело на полупути. А вот робота можно пощупать, не стыдно показать друзьям, при том что реальное железо не прощает ошибок и заставляет таки научиться правильно использовать имеющиеся библиотеки или написать новые.
Что интересно, этот робот по архитектуре почти не отличается от описанного в соседней статье. Автор этой статьи сконцентрировался пока на программировании «головного мозга», в другой статье фокус на «железе», рассматривается вопрос подавления помех по питанию. Вместе статьи гармонично дополняют друг друга, при этом думается что андроидный код с минимальными доработками сможет управлять и тем роботом. Получается универсальная архитектура «сеносоры<->ардуино<->последовательный порт (bluetooth)<->управляющая программа», где один автор может быть силён в программировании, другой в электронике, может ещё кто-то построит по этой схеме дорогого, но очень красивого робота. А хаброчитатель сможет выбрать из этого разнообразия то, что подходит лично ему.
Жду продолжения серии статей.
Что интересно, этот робот по архитектуре почти не отличается от описанного в соседней статье. Автор этой статьи сконцентрировался пока на программировании «головного мозга», в другой статье фокус на «железе», рассматривается вопрос подавления помех по питанию. Вместе статьи гармонично дополняют друг друга, при этом думается что андроидный код с минимальными доработками сможет управлять и тем роботом. Получается универсальная архитектура «сеносоры<->ардуино<->последовательный порт (bluetooth)<->управляющая программа», где один автор может быть силён в программировании, другой в электронике, может ещё кто-то построит по этой схеме дорогого, но очень красивого робота. А хаброчитатель сможет выбрать из этого разнообразия то, что подходит лично ему.
Жду продолжения серии статей.
Sign up to leave a comment.
РОБОТ на базе: android, arduino, bluetooth. Начало