Создаем ROBO_API

Пища для размышлений:

Виртуальные машины

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

0

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

0

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

Она размножаться не сможет. Без этого теряется весь цимес нейронных сетей )

0

Шутки, шутками, но мне лично нужнО такое API.

0

Нейронные сети. А кто мне расскажет о примерах их удачного промышленного применения?
Между тем, рекомендую поиграть в современные игрушки - там безо всяких сетей правдоподобно имитируется поведение и тараканчиков/бабочек, и всяких солдатиков, трусливых поодиночке и агрессивных толпами.
Для разнообразия и общего развития можно почитать этологов, из популярных - Дольника http://lib.ololo.cc/a/37153 , из первоисточников - К. Лоренца http://lib.ololo.cc/a/18721 и Р.Докинза http://lib.ololo.cc/a/18721 В случае с отцами-основателями, надо ещё делать скидку на то, в каком году написана та или другая из книг.

0

Сообщение от otix-rdx Шутки, шутками, но мне лично нужнО такое API.

Так в чем проблема? Кто не дает?
Я вон ковыряюсь со своим роботом, так по ходу, сначала для отладки, а потом и для взаимодействия его контроллеров между собой и с компьютером, создается довольно развитая и стройная система команд нижнего уровня, реализующая конкретные, вполне законченные функции, опираясь на которые, в свою очередь (пока еще не готовый) центральный контроллер будет исполнять уже команды и задания более высокого уровня (как тот же таракан), уже с некоторой долей автономности и независимости, постепенно наращивая свой интеллект. Сейчас же, пользуясь уже существующими и отлаженными командами, я с виртуального отладочного пульта в компьютере могу задать любые действия из числа уже имеющихся, прогнать робот по определенному пути, получая информацию с датчиков и камеры, имея на пульте в реальном времени напряжение батареи, данные об освещенности, c УЗ дальномера, видео с камеры, данные о положении башни и камеры, могу включать и выключать разные устройства и приводы, контролировать состояние программы контроллера башни (два с лишним десятка флажков в трех байтах слова состояния ее контроллера), непосредственно писать в регистры, коммутирующие исполнительные устройства, и многое другое, что сразу быстро и не вспомнишь. Причем связь с компом может быть как по шнурку с COM - порта (для скорости при отладки, и перезаписи программ через бутлоадер), так и по радиоканалу, до сотни метров и более (без камеры - до километра).

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

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

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

Сообщение от SWK Думаю, чтобы не начинать на пустом месте, в качестве информации для размышления можно ознакомиться с этим: http://ironfetyx.ru/modules.php?name=Pa ... age&pid=54

Это API по ссылке этой:

СБРОС ():Код_ошибки СТОП (Привод):Код_ошибки ДВИЖЕНИЕ (Угол, Расстояние, Скорость):Код_ошибки,

API ПО робота SWK:

Сообщение от SWK 0 (Hex 30) - Стоп. (Оба). 2,3,4 байт могут задавать дополнительные условия. Пока игнорируются. 1 (Hex 31) - Оба вперед. 2 и 3 байт - путь левого и правого колеса(пока - время работы двигателей). 2 (Hex 32) - Оба назад. 2 и 3 байт - путь левого и правого колеса(пока - время работы двигателей). 3 (Hex 33) - Левый вперед, Правый назад. 2байт - путь левого, 3байт - правого. 4 (Hex 34) - Правый вперед, Левый назад. 2байт - путь левого, 3байт - правого. 5 (Hex 35) - Левый вперед, Правый стоп. 2байт - путь. 6 (Hex 36) - Правый вперед, Левый стоп. 3байт - путь. 7 (Hex 37) - Левый назад, Правый стоп. 2байт - путь. 8 (Hex 38) - Правый назад, Левый стоп. 3байт - путь. 9 (Hex 39) - Скорость, 2байт - скорость (Длит. ШИМ_1), 3байт - скорость (Длит. ШИМ_2).

И что есть-то? Спецификации даже никакой нет. Можно для начала ограничится только спецификациями движения. А даже и этого практически нет. "Левый вперед, Правый назад" - слишком мелкий уровень даже для API. А "ДВИЖЕНИЕ (Угол, Расстояние, Скорость)" - тоже какая-то ерунда, какое-то движение вне системы координат...

Где хотя бы спецификации взять (достаточно только движения для начала)?

0

Сообщение от otix-rdx И что есть-то? Спецификации даже никакой нет. Можно для начала ограничится только спецификациями движения. А даже и этого практически нет. "Левый вперед, Правый назад" - слишком мелкий уровень даже для API.

А зачем? Это конкретные действия, отрабатываемые ходовым контроллером. Все, что в его компетенции, что он может отработать самостоятельно, и достаточно структуризовано.
Каждая команда - функционально законченный набор действий, которые ходовой контроллер реализует, включая двигатели, реверсируя их, меняя скорость вращения их изменением коэффициентов ШИМ, ограничивая время работы двигателей по времени или по измеренному одометрами пройденному колесами пути. А также другие доступные ему действия - контроль батареи, датчиков бамперов, пищалки, обмен с контроллером бамперов и (вместо отсутствующего центрального) - связь с компом по радиоканалу.
Чего еще требовать от ходового? Или вас не устроило, что тут некуда приткнуть вашу нейронную сеть и огромную память? Так они ходовому не нужны. И вся его программа сейчас чуть больше полутора килобайт. Просто и эффективно.

А "ДВИЖЕНИЕ (Угол, Расстояние, Скорость)" - тоже какая-то ерунда, какое-то движение вне системы координат...

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

Какую еще систему вам надо? Можно привязаться к GPS, но для мелких перемещений (например, в пределах 2-3х комнат) это неэффективно и связано с большими погрешностями.

Где хотя бы спецификации взять (достаточно только движения для начала)?

А зачем? Вам шашечки или ехать? Или докторскую писать? Если не устраивают существующие варианты, сделайте свой.

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

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

0

SWK, как вас торкнуло этими "нейронными сетями" ))) Это же бред - просто шутка...
По теме: ваше "микро API" (точнее - нижний и внутренний чисто уровень реального API) мне понятно и оно должно быть. Меня интересует именно что выше уже, т.е. само API, а не его отдельная внутренняя подсистема.

0

Сообщение от otix-rdx По теме: ваше "микро API" (точнее - нижний и внутренний чисто уровень реального API) мне понятно и оно должно быть. Меня интересует именно что выше уже, т.е. само API, а не его отдельная внутренняя подсистема.

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

Например, обследовать доступное пространство в пределах заданного радиуса или прямоугольника, и составить его карту в памяти, пометив на ней расположение препятсятвий - люков в полу, стен, мебели. Препятсятвия будут делиться на несколько (для начала - 7) категорий, задаваемых 1 байтом в массиве карты.
Например, "Дыра в полу", "лестница", "стена", "небольшой обьект", и так далее. "0" - отсутствие препятствий. По этой карте центральный контроллер (сокращенно - ЦК), в дальнейшем будет прокладывать оптимальный маршрут в заданные точки, и отслеживать свое текущее положение.

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

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

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

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

Конечно, у центрального контроллера (планирую Мегу 128), будут на всяк случай внешнее ОЗУ (от 64 до 512кб), внешнее EEPROM (килобайта 64 или более), и SD флэшка (от 2 до 32 Гб), для хранения карт, заданий, логов, журналов, и прочей инфы. Но это не обязательно иметь в самой микросхеме микроконтроллера, как хочется вам.

И ARM мне в роботе ни к чему. Свои задачи я и на Меге 128 с МикроПаскалем неплохо реализую. Опыт программирования контроллеров имею, и прекрасно представляю, что и как делать. А не просто "взять супер-пупер недерьмовый контроллер", неизвестно зачем.

Сообщение от Bomomd мне не понятно, какие вообще нафиг спецификации.

Но тема то о чем:

Сообщение от DY HOTT Понятно, что шасси и механика может быть различной, ... , а нам бы общую концепцию выработать. Синтаксис.

Для начала (можно и по-русски):

1. размерность_системы_координат (1 | 2 | 3)
2. система_координат (0 - прямоугольная, 1 - полярная, 2 - сферическая, 4 - цилиндрическая)
координата(1 | 2 | 3, 0 - длина, 1 - угол)
3. считываемые(устанавливаемые свойства):
- длина_пути
- x
- y
- z
- азимут
- зенит
- расстояние - в смысле радиус
- высота
- скорость
6. двигатся(1 - вперед, -1 - назад, расстояние | угол)
7. двигатся_в_точку(a, b, c)
8. поворот(азимут, зенит)
9. события:
- сработал_датчик()
- закончено_выполненение_команды()

Если платформонезависимость заявлена - значит на С или C++ (т.е. в данном смысле от МК(мозга) не зависит)? А выше уже сама виртуальная машина - это уже независимость уже от хардвеа "платформы" (в смысле самого бота, движки, сенсоры и т.п.)?

0

Спецификация (объектная модель) должна быть:
1. полная
2. удобная
3. не избыточная (хотя это и не очень большой грех)
Потом программная модель реализации:
1. процедурная или 2. объектная

Если это не будет решено - не понятно что кодировать то и как.

0

Сообщение от SWK Конечно, у центрального контроллера (планирую Мегу 128), будут на всяк случай внешнее ОЗУ (от 64 до 512кб), внешнее EEPROM (килобайта 64 или более), и SD флэшка (от 2 до 32 Гб), для хранения карт, заданий, логов, журналов, и прочей инфы.

Эк вас разнесло, однако, толще чем меня ))) А меня чуть камнями люди не закидали.

p/s Больше не буду подшучивать над Вами, даю честное слово! По сабжу лучше поработать конкретно.

0

"Эк вас разнесло, однако, толще чем меня "

Ну по крайней мере у Валерия уже телега катается, и большая часть механики уже готова и отлажена.

0

Сообщение от otix-rdx Сообщение от Bomomd Если платформонезависимость заявлена - значит на С или C++ (т.е. в данном смысле от МК(мозга) не зависит)? А выше уже сама виртуальная машина - это уже независимость уже от хардвеа "платформы" (в смысле самого бота, движки, сенсоры и т.п.)?

чо-то тупанул здесь. Получается модель: mostir и slave устройства. mostir - основной мозг, он рулит - вот для него и нужна спецификация, а виртуальная машина mostir-устройству не нужна. А вот в slave-устройстве она (виртуальная машина) как раз и нужна, и чем проще и меньше - тем лучше (под разные мелкие МК ее надо будет написать на asm-е). Здесь т.е. важнее протокол обмена mostir-slave сформулировать.

Пример:
1. Робот-паук с 6-ю ногами и головой. В данном случае, на каждую ногу - одно slave-устройство (управлять 2/3 сервами и датчиками ноги). Итого: 6 slave-устройств в виде маленьких плат с простеньким МК, и 1 - mostir-устройство в голове.

2. В случае робота с одним мощным МК, например, с 2-мя колесами. Этот МК есть mostir-устройство и одновременно slave-устройство. Т.е. в нем, кроме основной программы, тоже вертится виртуальная машина slave-устройства.

0

Вы правильно говорите, что нужен в первую очередь продуманный, расширяемый протокол обмена. Я не понял про виртуальную машину для slave устройств. Например тот же паук. Предположим у него есть мозг - центральный контроллер, он mostir. Есть набор сенсоров и исполнительные механизмы (это slave)/ От сенсоров к мозгу может поступать вполне предсказуемый поток информации, который собственно определяется конструкцией и ролью сенсора в системе. И от мозга к ногам может поступать вполне определенный набор команд. На мой дилетанский взгляд башка должна обрабатывать непрерывно сенсоры, слать команды ногам. Вот тут и нужен протокол обмена, причем придумывать можно сколь угодно долго. Например между головой и ногами добавим этакий спинной мозг - ходовой контроллер (как у SWK). Тогда протокол можно будет упростить, разделив управление уже на две части. Можно много чего придумать. Скажем если вдруг голова откажет, ходовой контроллер должен обезопасить робота (остановить двигатели например, сигнализировать как-то). Ну типа как безусловный рефлекс, если человека сильно напугать - он обосрется и это произойдет без участия мозга.
Я думаю вам стоит присмотреться к роботу SWK, у него четкое разделение на функциональные блоки, что логично и удобно. Я кончил.

0

Сообщение от Bomomd Я кончил.

:) no somments

0

Сообщение от Bomomd Например между головой и ногами добавим этакий спинной мозг - ходовой контроллер (как у SWK).

Вот именно - это и есть slave-устр-во. А по сабжу предлагается реализовать его в виде виртуальной машины (VM). Что не есть главное. Поскольку начинать надо с mostir-устройства, а для этого и нужны спецификации (объектная модель). А потом уже и закодировать конкретно эту VM (или какой там простейший автомат командный) для slave-устр-ва.

0

Сообщение от shurup Сообщение от Bomomd Я кончил.

:) no somments
Шуруп опять ввернулся в тему, шо бы превратить ее во флуд )))

0

ну как бы оно slave по отношению к головному контроллеру, но мастер по отношению к исполнительным устройствам. Ничего не мешает ему ВНЕЗАПНО стать мастером по отношению ко всей системе, если например голова сдохнет.

0