roboforum.ru

Можно еще обсудить формат команд

Предлагаемый сэмпловый минимальный ассортимерт:

Базовые приказы:

• результат=стоять();
• результат=иди(<куда=область>);
• результат=возьми_с_места(<объект>); (не перемещая шасси)
• результат=поставь(<куда=область>);

Результат на обычные команды:
1. Буду делать или нет (причина, если не буду)
2. Закончил / не смог / еще выполняю
3. Сколько осталось делать;

Базовые запросы:

• результат(субъект)=кто_дал_эту_команду();
• результат(координаты)=где_я_сейчас();
• результат(координаты)=где_находится(<объект/субъект>);
• результат(область)=область(<координаты>,<радиус_в_см>);

Здесь есть базовые типы - строка(текст), число, дата, координаты в пространстве, область,субъект.

Составная команда "Принеси <объект>":

• иди(область(где_находится(<объект>),50));
• возьми_с_места(<объект>);
• иди(область(где_находится(кто_дал_эту_команду()),50));

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

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

Про Пролог - почитал, интересно и безусловно полезно для ИИ, но непонятно как порядок действий относится к Прологу? Там ведь все промежуточные точки должны быть определены, чтобы движок Пролога смог их перебрать, т.е. если их будет бесконечно много, то задачу не то что решить, ее поставить нельзя будет

Например, нужно будет пройти из точки А в точку Б, но ходить изначально мы умеем только по прямой, а на пути препятствия, поэтому надо сначала пройти из А в В, а потом из В в Б. Так вот точек В бесконечно много, как правильных, так и неправильных.

Надо в общем обдумать эту тему

там примерно так решается всё:
(чтобы не мудрить с синтаксисом я напишу словами).

* есть точка А
* есть точка Б
* идти это двигаться вперёд если нет препятствий, если препятствие по определяем дополнительную точку B расположеную .... и двигаемся через неё.
* ИДТИ от А до Б

Это нечестно, т.к. именно задача поиска пути и есть сложная задача в этом случае, а выбор этой точки - это решение.

У меня есть предложение.
разрабатывать алгоритм на словах не очень интересно и наглядно
(по крайней мере для меня)

Предлагаю найти (или написать самостоятельно) эмулятор робота, определиться с языком программирования и приступить к разработке
совместимых модулей поведения робота.

Причем при выборе предлагаю учитывать следующее

• в конечном итоге ориентироваться на комплексное управление поведением робота с ПК или КПК с возможным вынесением вспомогательных функций узлов на микроконтроллер
• желательно использовать язык С ( конвертеры в С код имеют многие другие языки в том числе пролог и эмуляторы нейросети)

С первым пунктом я согласен, на словах - это не дело.

Что ж идея весьма интересна, и не раз обдумывалась мной, но вот несколько ложек дегтя:
1. Достаточно реалистичное моделирование физики передвижения робота _весма_ сложно, порой даже не знаешь, как к этому подступиться.
2. Моделирование среды функционирования робота, та же история.

Т.е. для создания подобного эмулятора, все упрется в несколько вещей:
1. Физика
2. Среда
3. Графческий Интерфейс

На мой взгляд создание _универсального_ эмулятора практически невозможно, на нашей ступени развития =)
Вот эмулятор, точнее сказать визуализатор под конкретный алгоритм...это пожалуйста.

2setar: Лучше сначала на словах обсудить В "спортивном/олимпиадном программировании" есть такой принцип - если человек не может русским языком объяснить как будет работать его алгоритм и рвется его кодировать, лучше такого человека к компу не подпускать - пустая трата времени.

Про эмулятор - зачем? Можно конечно начать программить это все, но лучше обсудить сначала до состояния полной ясности задачи и ее решения

ок, пусть на словах.

попробуем формализовать задачу, что у нас есть

1. действия которые совершает робот
   
   • движение простое как функция от скорости (стоп, вперёд, назад, вправо, влево)
   • движение сложное ... надо думать
   • издаваемые звуки
   • Визуальная индикация
   • Действия подчинёнными узлами (манипуляторы, башни и т.д.)
   • комплексные задачи (разведка местности ...)
2. информация с внешней среды
   
   • номер датчика, тип датчика, значение
3. информация командная (прямое управление)

P.S. это пока наброски, буду дорабатывать

... и тут опять я со своими глупостями

Все-таки чего хочется:

1. Принципов определения команд и целей для робота в части формата;

2. Принципов определения новых типов команд и целей "на лету", т.е. составных команд, команд задействующих подключаемые блоки робота (например, поставил на себя ИК-передатчик, подгрузил "драйвер", теперь может включать/выключать телевизор и переключать каналы, воткнулся в LAN-розетку, где есть инет - может сказать что сейчас идет по телевизору);

3. Если совсем хорошо, то некоторых зачатков самостоятельного поиска решений поставленных задач, по аналогии с прологом.

Попробую завтра систематизировать свои наброски по этой теме

У меня реализовано в виде блока простых.

Наверное всетаки от 2х переменных:
M = F(V,t); скорость и время соотв.


ИМХО нужно обеденить в один блок "индикация"


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

Теперь немного детальнее.

1. Разрешённые уровни AI от 0 до 15
   
   • AI (0)   # Полный заперт самостоятельных действий
   • AI (5)   # Обработка команд управления с обработкой информации от жизненно важных датчиков (питание, контактные бамперы ...)
   • AI (10) # Интеллектуальная обработка задач хозяина, разрешены самостоятельный поиск маршрута, синхронизация координат (с возможным движением для этого) ...
   • AI (15) # Полное автономное функционирование, обработка лишь команд изменения AI
   * остальные уровни используются для конкретизации разрешённых действий.
2. Принудительные команды ручного управления
   
   1. Движение платформы простое
      
      • стоп ([V])           # стоп с торможением V=0 или накатом V>0
      • вперёд (t,[V])
      • назад (t,[V])
      • вправо (t,[V])      # плоское движение (если позволяет модель)
      • влево (t,[V])        # плоское движение (если позволяет модель)
      • разворот (A,[V])  # разворот от текущего положения 0 - 360 град. оптимизирован по кратчайшему расстоянию
      • сидеть ()             # если позволяет модель
      • лежать ()            # если позволяет модель
      • стоять()              # если позволяет модель
      * во всех простых движениях используется обработка заданного уровня AI.
   2. Ориентация
      
      • загрузить_карту (имя_карты) # принять на веру карту окружающей месности
      • установить_координаты ([имя карты,] X,Y,A)  # принять на веру текущее положение платформы
      • синхронизировать_координаты ()  # предпринять необходимые действия по синхронизации системы координат на карте (а так же возможно и самой карты) в соответствии с уровнем разрешённого AI
   3. действия сложные
      
      • идти ([имя карты,] X,Y [,A])  # двигаться с текущего положения на заданную карту, и координаты, при необходимости учесть конечное положение угла ориентации платформы.
      • маршрут (массив ([имя карты,] X,Y [,A]))  # двигаться по координатам массива.
      * Везде при движении использовать разрешённый уровень AI.
   4. Индикация
      
      • индикация (N) # Разрешённые уровни индикации от 0 до 15 (нужно уточнять)
      • покажи (устройство_вывода, данные)
   5. информация с внешней среды
      
      • датчик (номер датчика [, тип датчика]) # получаем показания датчика
   6. Действия подчинёнными узлами (манипуляторы, башни и т.д.)
      
      • манипулятор_база (разворот (A) )
      • манипулятор_кисть (сжать (X) )
      • ...
3. комплексные задачи
   
   • разведка_месности ([максимальное_удаление])
   • принеси_пива ()
   • ...

* [] = необязательный параметр
  V = скорость
   t = время
  A = угол
  X,Y = координаты
  N = число

Я вот все думаю как бы задавать на лету сложные команды и дополнять арсенал робота новыми девайсами и способами управления ими без перезагрузки робота.

А я вот думаю, что в твоем понимании налету, и сложные?
Дополнять робота - запросто plugins + plug'n'play что тут думать-то?

plug'n'play - это уже совсем круто, хотябы просто:

1. Добавление новых составных команд либо объяснением роботу как это сделать, либо объяснением только что сделать, чтобы способ  выполнения он искал сам используя уже имеющиеся умения.

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

Кстати порядок определения целей на 99% зависит от того, как робот будет воспринимать окружающий мир тоже важная тема