Технический форум по робототехнике.
=DeaD= » 28 фев 2005, 11:24
Не будет ли эффективным такой подход - создать набор так называемых "драйверов для решения различных задач" - т.е. мы не делаем универсальный "мозг", а делаем универсальное ядро системы, к которому можно подключать различные модели для решения разных задач, возникающих у робота.
Примеры таких драйверов: "Механическая модель", "Эскизная модель взаимодействий по опыту", "Квантовая модель" и т.п.
Т.е. каждая такая модель может пользовать лишь отдельные свойства объектов.
Для решения каких-то задач ядро должно само выбрать нужные модели и с их помощью решить задачи.
Как идейка?
setar » 28 фев 2005, 12:13
Рационально.
То есть вместо всеобъемлющего мозга делаем
эффективную систему рассматривающую задачу в нескольких срезах...
Вот только не возникнет ли эффекта сильной потери информации при переходе от одной системы представления к другой?
или для объекта хранить их все, а обрабатывать по удобной ???
Floksa » 05 мар 2005, 00:45
Потеря информации, уважаемый коллега, возникает всегда. Всё связано со всем, и отсечь несущественное и учесть важное для решения сложной проблемы - это вообще задача для нехилого интеллекта. Чем сложнее проблема и чем больше факторов на неё влияет, тем сложнее их учесть.
Последний раз редактировалось
Floksa 06 мар 2005, 00:55, всего редактировалось 1 раз.
Kanoka » 05 мар 2005, 02:00
Очень дельная идейка, в классической маковской системе все примерно так и работало, сама система почти ничего ни весила и запускалась на 1Mb оперативки, нужные для работы функции, сеть, русский/любой другой языки и т.д. подключалось с помощью экстеншинов, тех самых модулей которые умеют работать только в связке с ядром.
А что касается этого направления в целом, то рано или поздно обязательно появится более менее единая ОС для домашних роботов, и соответственно новый Билл Гийтс и/или Стив Джобс. И пока это все находится в зародыше шанс есть даже у программеров одиночек. (это так, радужные перспективы
)
Outcaster » 05 мар 2005, 13:08
Что-то я в упор не могу понять сути идеи.
NoName » 05 мар 2005, 14:55
setar писал(а):... для объекта хранить их все, а обрабатывать по удобной ???
Способ выбора
удобной системы представления?
setar » 05 мар 2005, 15:33
NoName писал(а):setar писал(а):... для объекта хранить их все, а обрабатывать по удобной ???
Способ выбора
удобной системы представления?
Это задача оптимизации и оценки точности полученного результата + опыт в решении задач над аналогичными (схожими) объектами.
=DeaD= » 05 мар 2005, 15:42
setar писал(а):NoName писал(а):Способ выбора удобной системы представления?
Это задача оптимизации и оценки точности полученного результата + опыт в решении задач над аналогичными (схожими) объектами.
Главное что в случае возможности выбора системы-модуля-метода решения можно уже, например, применять нейросети, т.к. здесь выходов можно сделать мало - только какую модель выбрать.
NoName » 05 мар 2005, 16:25
setar писал(а):Это задача оптимизации и оценки точности полученного результата + опыт в решении задач над аналогичными (схожими) объектами.
Вот и я про то же: как опыт-то программировать, причем чей: машины или человечий?
setar » 05 мар 2005, 16:28
NoName писал(а):setar писал(а):Это задача оптимизации и оценки точности полученного результата + опыт в решении задач над аналогичными (схожими) объектами.
Вот и я про то же: как опыт-то программировать, причем чей: машины или человечий?
Опыт математический накомленный машиной, оценивая минимальность погрешности при решении задачи в том или ином представлении.
=DeaD= » 06 мар 2005, 00:38
Попробую продумать структуру ядра системы и выложить сюда, по идее многие разработчики систем управления роботами применяют модульный подход, но вроде про взаимозаменяемые в realtime модули никто еще не пытался продумать вариант.
Outcaster » 09 мар 2005, 13:21
=DeaD= писал(а):...но вроде про взаимозаменяемые в realtime модули никто еще не пытался продумать вариант.
Пытались, думали, делали ... работает.
Первый трабл который тут вылезет (если, конечно, я правильно понял о чём речь), интерфейсы модулей. Чтоб попроще, стандартизированнее, и покрывали запросы по инфообмену.
=DeaD= » 09 мар 2005, 13:27
Outcaster писал(а):=DeaD= писал(а):...но вроде про взаимозаменяемые в realtime модули никто еще не пытался продумать вариант.
Пытались, думали, делали ... работает.
Я не вообще, я конкретно про роботов в части решения сложных и неоднозначных задач
Так то я в курсе технологий в разработке ПО в целом
Outcaster писал(а):Первый трабл который тут вылезет (если, конечно, я правильно понял о чём речь), интерфейсы модулей. Чтоб попроще, стандартизированнее, и покрывали запросы по инфообмену.
Например, с типами данных все просто - вводим указание типа данных строкой, а сами данные - просто линейный массив байтов. Как все и решается в Си-подобных языках - есть размер объекта, есть дескриптор, а что он у себя внутри хранит - его личное дело
А вот порядок передачи самой задачи - вопросец тот еще
Outcaster » 09 мар 2005, 13:47
=DeaD= писал(а):Я не вообще, я конкретно про роботов в части решения сложных и неоднозначных задач
ок., значит понял правильно.
=DeaD= писал(а):Например, с типами данных все просто - вводим указание типа данных строкой, а сами данные - просто линейный массив байтов. Как все и решается в Си-подобных языках - есть размер объекта, есть дескриптор, а что он у себя внутри хранит - его личное дело
А хранить он в себе (ну, или в экземпляре типа, если их много) должен
как минимум методы работы с ним, т.е. интерфейс (что само по себе уже не есть гуд
), либо быть стандартным, от чего не лёгше, т.к. стандартных типов всегда будет мало. (это сказано скорее для себя - уж очень сложно в ООП-ориентированные языки после
asm-а врубливаться
)
=DeaD= писал(а):А вот порядок передачи самой задачи - вопросец тот еще
В принципе, тут псевдокод помочь может...
Неплохая штука, и почему-то о ней незаслуженно забывают.
=DeaD= » 09 мар 2005, 14:24
Outcaster писал(а):=DeaD= писал(а):А вот порядок передачи самой задачи - вопросец тот еще
В принципе, тут псевдокод помочь может...
Неплохая штука, и почему-то о ней незаслуженно забывают.
Псевдокод - это информация о том "как сделать", а нам нужно "что сделать", так что тут скорее нужно будет передать четко заданные желаемые результаты, и хорошо если их получится нормализовать...
Казалось бы просто укажи желаемые свойства объектов после действий и все... но...
Например, простой результат "поместить два объекта на расстоянии 10 см друг от друга" в таком виде не представим... и тут начинается самое интересное