roboforum.ru

=DeaD= писал(а):Ему религия не позволяет в симуляторе баловаться

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

setar писал(а):Виктор, а не было ли попытки поуправлять виртуальной платформой ?
Сейчас есть много разных эмуляторов роботов.
Это как первый шаг к управлению реальной железкой.
Я пока не знаю когда идея удаленного управления роботом через интернет будет реализована в железе.

Я считал и считаю, что основав все коммуникации внутри робота и за его пределами на основе стандартного TCP протокола, можно взаимодействовать с ним на любых разумных расстояниях, с учетом пинга конечно, как по локальным, так и по глобальным сетям. И такой универсализм в дальнейшем сэкономит массу любых ресурсов. А в связи с хорошей расширяемостью в скоростном и адресном смысле таких сетей ширина канала и др. трудности не будут ограничивающим фактором. Кроме самого протокола нужно реализовать или взять уже готовый механизм истинного PlugAndPlay, чтобы со всякими дровами меньше заморачиваться.
Но если на данном этапе практичнее разобраться и подключиться программно к какому-нибудь симулятору, а также применить ваши разработки OpenRobotics, то это нужно будет сделать.

Виктор Казаринов писал(а):Я верующий только в силу разума. А также умеренный материалист. Напрасно вы считаете, что я упертый в какие-то догмы.

Ну вы же не хотите в симуляторах баловаться?

PS: Вот убрали кнопку "Ответ" у последнего сообщения, приходится извращаться

=DeaD= писал(а):Ну вы же не хотите в симуляторах баловаться?

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

Несложных симуляторов не бывает

Есть MS Robotics Studio и Player\Stage\Gazebo из известных мне более менее распространенных.
Ни ту ни другую никто на форуме так и не освоил. Дальше всего продвинулись с освоением MSRS, но тоже никаких реальных достижений.

=DeaD= писал(а):Несложных симуляторов не бывает

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

Webots - неплохой симулятор.
Программно подключится - очень просто.

http://www.urbiforge.com/ Что это за зверь такой? нужно изучать, однако

Там в FAQ всё написано. Короче это язык для написания программ для управления роботами. Судя по всем не особо прокачанный, раз они даже не особо надеются, что пользователю удастся обойтись только их языком и даже сначала рассказывают как его можно пользовать чисто на роботе для написания дочерней "прошивки" с которой можно взаимодействовать своей C++ программой на ПК или на самом роботе.

=DeaD= писал(а):Есть MS Robotics Studio и Player\Stage\Gazebo из известных мне более менее распространенных.
Ни ту ни другую никто на форуме так и не освоил. Дальше всего продвинулись с освоением MSRS, но тоже никаких реальных достижений.

Какие достижения тут должны быть реальными? И м.б. кто-то раскопал, можно ли к этим студиям программно подключиться как то?

реальные достижения? Ну я считаю ими:
1. Сделать модель своего настоящего робота;
2. Прописать драйверы в этом же формате к настоящему роботу;
3. Написать софт, использующий требуемый формат обмена данными;
4. Обкатать его в симуляторе;
5. Поставить на реального робота, чтобы он в черновой версии сразу заработал;

Добавлено спустя 1 минуту 16 секунд:

Виктор Казаринов писал(а):И м.б. кто-то раскопал, можно ли к этим студиям программно подключиться как то?

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

=DeaD= писал(а):1. Сделать модель своего настоящего робота;

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

=DeaD= писал(а):2. Прописать драйверы в этом же формате к настоящему роботу;

Т.е. высокоуровневые команды?

=DeaD= писал(а):3. Написать софт, использующий требуемый формат обмена данными;

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

=DeaD= писал(а):4. Обкатать его в симуляторе;

Для этого то и нужен симулятор.

=DeaD= писал(а):5. Поставить на реального робота, чтобы он в черновой версии сразу заработал;

Сразу - это только кто-то слишком крутой его должен написать. И вообще, это будет очень подозрительно. ВОт если сотни 2- 3 ошибок, то это нормально.

1. Можно и сначала модель, а потом робота, главное чтобы это получило в дальнейшем соответствие с настоящим роботом;

2. Не высокоуровневые команды, а команды, которые будут одинаково пониматься и симулятором и реальным роботом, чтобы отлаженная в симуляторе софтина потом без модификаций управляла реальным роботом.

3. Софт верхнего уровня, который мы разрабатываем, прошивки микроконтроллеров не считаются. Т.е. в симулятор или реального робота должны из этого софта поступать команды типа "проехать вперед 10см, повевернуть направо на 90 градусов, двигаясь внутренним колесом поворота по окружности радиусом 40см, прочитать состояние дальномера который установлен спереди робота" и т.п.

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

=DeaD= писал(а):проехать вперед 10см

Относительно простая задачка для лабораторных роботов и совсем нетривиальная в реальном мире. Для того, чтобы роболет переместился в воздухе на 10 м над объектом, кот. находится на поверхности моря, нужно учитывать и все воздушные и подводные приповерхностные возмущения а также собственное поведение этого другого объекта. Иногда когда дают людям простую по смыслу команду "слетать на Луну", то ее реализация совсем нетривиальна. Вот я и пытаюсь выявить границы простых и сложных команд и какой узел какую команду может и должен выполнить.

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

"Мозги" робота, давшие эту команду или оператор - человек должен "бамбук курить" пока команда отрабатывается? Это очень не есть карашо.
Есть тщательно отработанная рекомендация FIPA http://www.fipa.org/Она определяет протоколы и языки обмена сообщениями между агентами. Под агентами могут подразумеваться любые субъекты (роботы, программы, люди, составные части роботов).
http://www.fipa.org/repository/standardspecs.html Здесь все регулирующие документы. Данная рекомендация является одной из самых совершенных на сегодняшний день.
Я некоторое время тщательно эту рекомендацию изучал. Оказалось, что существует только 22 (если не забыл) типа сообщений, из которых только 2 типа- базовые, на которых строятся все оставшиеся.

Вот упрощенный вид сообщения:
<тип сообщения> <отправитель сообщения> <получатель сообщения> <содержание сообщения> <метка исходящего сообщения> <ссылка на входящее сообщение> <лимит времени на ответ> <нотация> <идентификатор разговора>

<тип сообщения> “Inform” и “Request” -два базовых речевых акта.
Значение “Inform” и “Request” определяется в двух частях:
–предусловия, которые должны быть истинны для того, чтобы речевой акт достигал цели;
–чего надеется достичь отправитель сообщения.

Речевой акт «Inform».
Содержание представляет собой утверждение(statement).
Предусловие заключается в том, что отправитель:
–считает, что содержание является истинным;
–имеет намерение, чтобы получатель поверил в это содержание;
–еще не считает, что получатель осведомлен о том, является ли содержание истинным или нет.

Речевой акт «Request»
Содержание представляет собой действие (action).
Предусловие заключается в том, что отправитель:
–имеет намерение, чтобы было выполнено действие, указанное в содержании;
–считает, что получатель способен выполнить это действие;
–не считает, что получатель уже намеревается выполнить действие.