Разработка робота удалённого присутствия.

• lonely_warrior

  Posts 12

  Joined: Mon Jun 03, 2013 3:12 pm

  Wed Jun 05, 2013 7:17 pm

  Всем доброго времени суток.
  Я искренне надеюсь, что созданная в данный момент тема не станет элементом захламления сего форума, и что мне удастся довести начатое до конца. Честно признаться не всегда у меня это получается. Хотя так у большинства наверное.
  Итак, собственно я уже некоторое время занимаюсь созданием для себя удалённо управляемого робота. Делают сейчас их многие, однако сложно спорить - штука интересная, область их актуального применения весьма широка и не освоена в полной мере. Есть что развивать, над чем работать.
  Очевидно так же, что создаваемая людьми на этом ресурсе операционная система потенциально почти идеально подходит именно для роботизированных конструкций.
  
  Чтобы не говорить о сферическом коне в вакууме, я его сейчас опишу по частям.
  Условная схема работы прикреплена во вложении.
  
  1. Имеется два устройства – робот и оператор. Связь осуществляется через 3G а если повезёт 4G модем, находящийся внутри робота, имеющий статический ip. По факту является сервером.
  2. Серверное приложение, может принимать от оператора короткие текстовые команды. Производится сопоставление команд и выполняется соответствующее действие.
  3. Физическое взаимодействие с миром осуществляется посредством 4 электродвигателей. Все электродвигатели могут производить вращение в обоих направлениях, поэтому питаются посредством H-мостов. H-мосты включаются управляющим сигналом с LPT порта, который опять же контролируется серверной программой.
  4. Четыре электродвигателя отвечают за 4 вида физических действий: движение вперёд/назад, поворот вправо/влево, поворот головы, поднимание рук. Поворот головы в некоторой степени необходим для навигации и в несколько большей для «оживления» разработки, дабы она не являлась просто ведром на колёсах. Согласитесь, ведро на колёсах с поворачивающейся головой несравнимо круче. А с поднимающимися руками просто вершина человеческого прогресса. Так же поднимание рук требуется для стыковки с зарядным устройством. Зарядное устройство представляет собой хреновину похожую на рамку металлодетектора. Заезжая в неё робот поднимает руки, электромагниты на концах рук притягиваются к стенкам рамки и получают питание от них. Ориентировочное напряжение в стенках рамки – 14 вольт.
  5. Робот производит постоянную видео съёмку и звукозапись. Потоком отправляет это оператору. Оператор на основе этого посылает свои команды. Круг замыкается.
  
  
  Что готово.
  Совсем недавнее состояние робота можно увидеть тут - http://www.youtube.com/watch?v=BJMJAf_Zn3A
  Сейчас я частично обклеил его папье-маше и ему стыдно показываться на людях.
  Есть черновые варианты управляющего софта под windows (c#.net) и linux (python 2.7 в altlinux`е). Но это не круто. Мне кажется использование KolibriOS само по себе будет интересным деянием.
  Были готовы H-мосты. Они сгорели. Все. Я плакалъ. Дело в том, что были использованы геркониевые реле. А гадкий LPT при включении компьютера посылает включающий сигнал на все свои выходы. В общем всё замкнуло, а геркониды весьма чувствительны к большому току. Сейчас переделываю всё на биполярниках и ,там где нужны больше мощности, полевых транзисторах. В схему теперь будет добавлен ограничитель на одновременное включение обоих плеч моста.
  Почти готова вся механика. Руки поднимаются (требуется немного доработать), голова поворачивается, робот гоняет по комнате. Готова общая структура – каркас.
  
  Что ещё нужно.
  Да много чего. Здесь и далее, прошу учесть моё отношение к данному делу – меня устраивает концепция «это приемлемо». Я не стремлюсь запилить идеальную вундервафлю. Хочется сделать её максимально хорошо, но не увязать в бесконечном стремлении к идеалу. Понимаю, что с этой концепцией не очень вяжется желание использовать Kolibri. Но тут меня просто охватило желание, и оно в некотором смысле иррационально. Однако одно дело когда твой робот движется под управлением чего-то давно кем-то сделанного и отлаженного, а другое, когда ты внёс свою малую лепту.
  Итак, по пунктам.
  1. Видео поток. Пользователь SoUrcerer говорил что есть возможность хватать отдельные картинки с веб камеры. Меня это более чем устроит. По каналу планирую передавать не сколько сами изображения, сколько результаты работы алгоритма межкадровой разницы, она же «компенсация движения». Должен будет получиться своеобразный аналог кодека MPEG-4. Конечное изображение будет собираться на стороне клиента и уже тогда выводится на экран. С некоторой периодичностью по каналу будет передаваться базовое изображение в нормальном качестве, чтобы сбрасывать накапливающуюся погрешность изображения. Однако пользователь art_zh рекомендовал мне использовать CMOS-сенсор. Насколько я понимаю он считает использование обычной вебкамеры неприемлемым по причине её низкой скорости снятия картинки с окружающего мира (art_zh, это так?). В результате это приведёт к тому, что в движении и тряске камера будет выдавать размытое смазанное изображение. Насколько понимаю CMOS-сенсор способен выдавать большую скорость считывания. Кроме того такая микруха даст разрешение выше 1Мп, контрастом 10-12 бит и скоростью потока >40Mп/с. Да да, это я нашёл обсуждение подобного момента в теме «Колибри в робототехнике». Не уверен, что мне требуется высокое качество изображения. В отличии от парня с кафедры Московского Энергетического Института мне не требуется распознавание образов. Видеопоток будет передаваться оператору и уже человек будет разбираться что там собственного говоря происходит. Поток, как уже упоминалось будет передаваться по беспроводному модему. По этой причине высокого качества съёмки нам не видать – изображение придётся жать настолько насколько совесть позволит. Думаю мне стоит сделать вот что – как соберу робота в боевое состояние (сейчас расковыренный на диване лежит) заставлю его поездить по комнате и запишу видео с его камеры. Посмотрим как оно получится и станет ясно, устроит такое качество съёмки или нет.
  2. Запись звука. Хз, что с этим делать ещё даже не думал. Альтернатива – сенсорный экран. Удастся ли что-то из этого заставить работать и как - тема отдельного эксперимента и обсуждения.
  3. Передача данных по TCP. Ну вроде как тривиально достаточно. Нужно правда будет 3G модем раскочегарить. Да и на «низком уровне» я сеть никогда не писал… Блин я вообще толком на низком уровне не писал, ну да ладно, лиха беда начала.
  4. Управление H-мостами через LPT порт. Не думаю что возникнут особые сложности. Насколько я в курсе, ассемблер с портами разговаривает как с родными.
  5. Воспроизведение заранее записанных сеплов-фраз. По-идее ничего сложного.
  6. Корпус. Непосредственно KolibriOS это не касается, но думаю освещение процесса будет полезно данному форуму. Планирую делать из полимерного пластилина. Хз, как его доводить потом до температуры в 130 градусов. Один вариант гуляет в голове, но соседи за такое убьют. И жена. Но будет весело. Непосредственно пытаться лепить корпус думаю занятие бесперспективное, поэтому делаю сейчас формочки из папье-маше. Возможно это глупо, но хочется красивый и презентабельный корпус сделать, не хуже чем у японцев.
  
  Ну как-то так. Мне понадобится некоторое время освоиться в новой операционной системе. Откомпилить и запустить пару ХеллоуВордов и всё такое.

  Attachments

  

  Общая схема робота.png (149.39 KiB)

  Общая схема робота удалённого присутствия Viewed 13166 times

  Last edited by lonely_warrior on Wed Jun 05, 2013 7:46 pm, edited 1 time in total.

  • Quote

art_zh Kernel Developer

Posts 1465

Joined: Fri Aug 14, 2009 1:46 am

Wed Jun 05, 2013 8:30 pm

1. Мостовые переключатели надо делать на полевиках:
а) они лучше держат индуктивную нагрузку,
б) у них лучше проводимость и время переключения,
в) у биполярников самое слабое место - положительный температурный коэффициент проводимости канала. Он легко приводит к локальному пробою на больших токах.

2. СОМ-порт слишком медленный для управления мостами, и ему десериализатор нужен.
Лучше работай через LPT: 8 бит как раз хватит на 4 ведущих движка (вперед/назад и вкл/выкл), и еще 4бита на руку и голову.

3. А слабо рукой в розетку попадать для подзарядки?

4. У вебкамеры два недостатка: CCD и USB.
На бегу CCD размазывает картинку, а USB вносит серьезную задержку при передаче.

• Quote

lonely_warrior

Posts 12

Joined: Mon Jun 03, 2013 3:12 pm

Sun Jun 09, 2013 3:43 am

Итак, повозился кое с чем.
В плане программирования немного побаловался с FASM и TinyC. Пытался ещё сделать бинарник на GCC, G++ но как-то не получилось. Может и вернусь к этому, но вероятно хватит того, что есть. А ещё извращался - запускал старый добрый TP7 под DosBox. С тормозами но работает.

Так же сделал запись с веб-камеры встроенной в голову робота, во время его передвижения по комнате. На мой взгляд вполне сносное качество, достаточное для того, чтобы оператор мог ориентироваться в пространстве. art_zh, как показывали мои прошлые эксперименты передача видео по интернету даёт гораздо большую задержку - около 800 миллисекунд, при максимально возможном сжатии и подходящей фазе луны. Управлять не так удобно как хотелось бы, но других вариантов нет, и размениваться на те копейки, которые вносит задержка по usb смысла не вижу. Ну серьёзно.
Видюха вот - http://www.youtube.com/watch?v=yqL8auvib0E

Mario_r4, а что не так с Шелботом? Ну да, есть схожесть в построении, но вот я прикрепил к посту пару фото более приятного на вид экземпляра. А суть то та же.
С высоким центром тяжести я мало что могу сделать - мне нужен выской робот, он должен иметь элемент зрительного контакта с человеком. Нужно это для дела. Я бы рад поменьше да пониже смастерить, да не то будет.
Сегодня попробовал кстати его уронить пару раз, посмотреть что будет. Целый остаётся, только ось из переднего колеса вылетает и крутилка головы. Но они не закреплены пока вообще, так что ничего страшного. Он у меня не раз врезался в препятствия на полном ходу - не падал. В целом по ощущениям - если специально его не толкать - падать он не будет.
На платформе внизу забронированно место для двух 14В аккумуляторов литио-ионных. В общем это мелочёвка, не о том сейчас голова болит =)

Attachments

Снимок-2.png (398.8 KiB)

Viewed 13036 times

Снимок-1.png (385.67 KiB)

Viewed 13036 times

• Quote

Mario_r4 Kernel Developer

Posts 2328

Joined: Sun Feb 10, 2013 12:37 pm

Sun Jun 09, 2013 11:01 am

lonely_warrior wrote:С высоким центром тяжести я мало что могу сделать - мне нужен выской робот, он должен иметь элемент зрительного контакта с человеком. Нужно это для дела. Я бы рад поменьше да пониже смастерить, да не то будет.

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

lonely_warrior wrote:Сегодня попробовал кстати его уронить пару раз, посмотреть что будет. Целый остаётся, только ось из переднего колеса вылетает и крутилка головы. Но они не закреплены пока вообще, так что ничего страшного. Он у меня не раз врезался в препятствия на полном ходу - не падал. В целом по ощущениям - если специально его не толкать - падать он не будет.
На платформе внизу забронированно место для двух 14В аккумуляторов литио-ионных. В общем это мелочёвка, не о том сейчас голова болит =)

Испытания на прочность нужно проводить для законченной конструкции.

• Quote

Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!