roboforum.ru

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

Примеры таких драйверов: "Механическая модель", "Эскизная модель взаимодействий по опыту", "Квантовая модель" и т.п.

Т.е. каждая такая модель может пользовать лишь отдельные свойства объектов.

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

Как идейка?

Рационально.
То есть вместо всеобъемлющего мозга делаем
эффективную систему рассматривающую задачу в нескольких срезах...
Вот только не возникнет ли эффекта сильной потери информации при переходе от одной системы представления к другой?
или для объекта хранить их все, а обрабатывать по удобной ???

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

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

А что касается этого направления в целом, то рано или поздно обязательно появится более менее единая ОС для домашних роботов, и соответственно новый Билл Гийтс и/или Стив Джобс. И пока это все находится в зародыше шанс есть даже у программеров одиночек. (это так, радужные перспективы )

Что-то я в упор не могу понять сути идеи.

setar писал(а):... для объекта хранить их все, а обрабатывать по удобной ???

Способ выбора удобной системы представления?

NoName писал(а):

setar писал(а):... для объекта хранить их все, а обрабатывать по удобной ???

Способ выбора удобной системы представления?

Это задача оптимизации и оценки точности полученного результата + опыт в решении задач над аналогичными (схожими) объектами.

setar писал(а):

NoName писал(а):Способ выбора удобной системы представления?

Это задача оптимизации и оценки точности полученного результата + опыт в решении задач над аналогичными (схожими) объектами.

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

setar писал(а):Это задача оптимизации и оценки точности полученного результата + опыт в решении задач над аналогичными (схожими) объектами.

Вот и я про то же: как опыт-то программировать, причем чей: машины или человечий?

NoName писал(а):

setar писал(а):Это задача оптимизации и оценки точности полученного результата + опыт в решении задач над аналогичными (схожими) объектами.

Вот и я про то же: как опыт-то программировать, причем чей: машины или человечий?

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

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

=DeaD= писал(а):...но вроде про взаимозаменяемые в realtime модули никто еще не пытался продумать вариант.

Пытались, думали, делали ... работает.

Первый трабл который тут вылезет (если, конечно, я правильно понял о чём речь), интерфейсы модулей. Чтоб попроще, стандартизированнее, и покрывали запросы по инфообмену.

Outcaster писал(а):

=DeaD= писал(а):...но вроде про взаимозаменяемые в realtime модули никто еще не пытался продумать вариант.

Пытались, думали, делали ... работает.

Я не вообще, я конкретно про роботов в части решения сложных и неоднозначных задач Так то я в курсе технологий в разработке ПО в целом

Outcaster писал(а):Первый трабл который тут вылезет (если, конечно, я правильно понял о чём речь), интерфейсы модулей. Чтоб попроще, стандартизированнее, и покрывали запросы по инфообмену.

Например, с типами данных все просто - вводим указание типа данных строкой, а сами данные - просто линейный массив байтов. Как все и решается в Си-подобных языках - есть размер объекта, есть дескриптор, а что он у себя внутри хранит - его личное дело

А вот порядок передачи самой задачи - вопросец тот еще

=DeaD= писал(а):Я не вообще, я конкретно про роботов в части решения сложных и неоднозначных задач

ок., значит понял правильно.

=DeaD= писал(а):Например, с типами данных все просто - вводим указание типа данных строкой, а сами данные - просто линейный массив байтов. Как все и решается в Си-подобных языках - есть размер объекта, есть дескриптор, а что он у себя внутри хранит - его личное дело

А хранить он в себе (ну, или в экземпляре типа, если их много) должен как минимум методы работы с ним, т.е. интерфейс (что само по себе уже не есть гуд ), либо быть стандартным, от чего не лёгше, т.к. стандартных типов всегда будет мало. (это сказано скорее для себя - уж очень сложно в ООП-ориентированные языки после asm-а врубливаться )

=DeaD= писал(а):А вот порядок передачи самой задачи - вопросец тот еще

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

Outcaster писал(а):

=DeaD= писал(а):А вот порядок передачи самой задачи - вопросец тот еще

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

Псевдокод - это информация о том "как сделать", а нам нужно "что сделать", так что тут скорее нужно будет передать четко заданные желаемые результаты, и хорошо если их получится нормализовать...

Казалось бы просто укажи желаемые свойства объектов после действий и все... но...

Например, простой результат "поместить два объекта на расстоянии 10 см друг от друга" в таком виде не представим... и тут начинается самое интересное