Easyelectronics.ru

Для этого я и поставил несколько контроллеров, каждый из которых занимается своим делом. Будет колесное или гусеничное шасси, или вообще плавающая модель - все равно центральный контроллер будет посылать ходовому команды "вперед 20", "налево 10", "стоп".
Контроллер бамперов следит за 3 типами датчиков (пола, столкновения, ИК локаторы ближней зоны (до 20-30см), по 4-6 направлениям, и общается с ходовым, предупреждая о препятствиях.
На поворотной платформе вообще будет куча всякого со своим контроллером, который будет общаться только с центральным, набором унифицированных команд. Заманчиво дать ему в подчинение тоже 2-3 более узкоспециализированных, но усложняется межпроцессорный обмен, который и без того непрост. Все-таки с ведомым I2C многовато мороки, хоть на SPI переводи... Несмотря на наличие аппаратной поддержки, приходится каждый шаг контролировать. Со SPI единственное неудобство - куча линий выбора устройств, но это мелочь по сравнению с простотой и удобством протокола. Если бы еще SPI был в мелких (8-18ног) контроллерах... Можно было бы на каждый датчик поставить.
По моему тут вы погорячились. Если мне нужно знать напряжение батареи, а вместо этого он чем-то там махать начнет, я могу ведь ему и не простить...

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

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

Такс, а вот у меня какие соображения. Оставим в сторону ВМ, она, несомненно, нужна в том или ином роде, но в данном случае ВМ пишется под АПИ, а не наоборот.

Итак. Предлагаю такой вариант языка скрипта.

Команда переменной длины. коп:аргумент:аргумент:аргумент... и так далее, сколько надо столько и будет. Обработчик этой конструкции будет проще простого.

БК компилируемый!!! Т.е. все переходы абсолютные. Адресация каждой цепочки начинается от начала ее и до конца. Т.е. как на х86 в COM файлах. Поэтому переменная длина команд нам тут палки в колеса вставлять не будет, да и обрабатывать это можно в две три команды. Компактность и скорость! (интерпритатор нам нахер не уперся, проще заливать в память весь скрипт целиком)

Под память пользователя выделено несколько ячеек памяти. Это как наши статичные переменные. Скажем, 100шт. С учетом того, что это ТОЛЬКО на логику, должно хватить. Те более можно и расширять и добавлять, а более сложные вещи опускать на уровень ВМ, будет куда компактней и надежней.

Многозадачность скриптов. Заводится массив указателей и каждый скрипт может вызывать другой скрипт, при этом ему выделяется свой указатель и он начинает крутиться параллельно первому. В принципе можно и терминировать его, проблем не составит. Сами же скрипты линейные. Общение между ними через те же общие переменные.

На выходных попробую для своего робота написать простейший вариант. Еще тут параллельно может чел один редактор сварганит. Сейчас мы с ним обсуждаем ряд технических моментов.


Критикуйте!

Ох, не люблю я скриптовые языки почему-то... Еще со времен DOS к ним какое-то отвращение, на уровне подсознания, как к чему-то примитивному и ненадежному. Предпочитаю передавать параметры в программу в фиксированном формате, чтобы не заморачиваться с разборкой скриптов. Тем более в мелких контроллерах, где каждый байт на счету.
Ну не люблю я скрипты... хотя на них почти полвиндов построено. Потому Винды такие тормозные и глючные.

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

Не успел ответить вчера - свет вырубили :(

SWG
> "Поехать вперед, не доезжая до стены 1 метр остановится, развернуться, и вернуться в первоначальную позицию"? Каким
> формализованным языком или набором команд?

Очень простым - языком, семантически идентичным какому-нибудь RISC набору команд. У нас же виртуальная машина, вот у нее и будет свой собственный виртуальный язык. И набор периферии.

Допустим, вот скрипт, который может выполнить такую задачу (я предлагаю синтаксис, его можно модернизировать):



Компилируем его на ББ и заливаем полученный байт-код в робота. Робот готов выполнять задания. Как заливать? Как угодно! Можно даже через радио-канал.

SWG, ваша реализация хороша для дистанционного управления. По сути она и есть протокол ДУ. ВМ же позволит научиться роботу думать! Вот посчитайте - сколько кода вы напишете для своего робота в 8 КБ памяти? Достаточно, конечно, но не много. А теперь прикинте, насколько громадный скрипт можно откомпилировать и залить в робота! Он же не будет храниться в памяти контроллера - для него можно организовать внешний носитель. А в памяти микроконтроллера будет находится только виртуальная машина и слой драйверов устройств (драйвер, в данном случае, правильное название). В скрипт можно добавить механизм библитек, так что код для удобства можно будет разбить на кучу модулей.

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

В скрипт можно и нужно добавить потоки. Я предлагаю назвать их заданиями и выполнять все процедуры, вызванные из такого потока, в контексте соответствующего задания. Например вот так:

Задача: Едем вперед, если загорелся свет в комнате, то останавливаемся.
Решить задачу без таймера

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


Блин, да вообще придумать можно 100500 решений, главное всем проявить фантазию!

Погнали дальше. Немного фантазии :)
Все видели редакторы карт для компьютерных игр? Кто сказал, что такое нельзя сделать для робота в реальном мире? Редактируя карту комнаты, раставляя на ней различные объекты и добавляя уже существующие блоки "разумного поведения", например объезда препятствий, можно будет мышкой задать роботу весьма и весьма сложный алгоритм действий. На выходе редактора будет скрипт, который откомпилется компилером и зальется в робота по радиоканалу.

bevice
> например если в системе зарегистрированы датчики напряжения АКБ и дальномер, то получить
> значения измерений с них можно будет одинаковыми командами

Верное замечание! Я как раз использовал этот метод в своем коде. Только для его реализации нужна будет унификация на уровне ВМ, т.е. слой с набором низкоуровневых программ и слой абстракции (HAL, Hardware Abstraction Layer)

SWG
> Ох, не люблю я скриптовые языки почему-то... Еще со времен DOS к ним какое-то отвращение, на уровне
> подсознания, как к чему-то примитивному и ненадежному.

В них нет ничего ненадежного. Это такая же строгая логика как и набор машинных команд. Естественно, понадобится надежная реализация, но уж куда без нее. Да и всегда интересно работать над сложными проектами, это повышает уровень профессионализма и интерес к жизни :)

DI HALT

> Команда переменной длины. коп:аргумент:аргумент:аргумент... и так далее, сколько надо столько и будет. Обработчик этой конструкции будет проще простого.

да

> БК компилируемый!!! Т.е. все переходы абсолютные. Адресация каждой цепочки начинается от начала ее и до конца.
> Т.е. как на х86 в COM файлах. Поэтому переменная длина команд нам тут палки в колеса вставлять не будет, да и обрабатывать
> это можно в две три команды. Компактность и скорость!

да, это обязательно. Заливаться будет блок кода

> (интерпритатор нам нахер не уперся, проще заливать в память весь скрипт целиком)

А это не понял. Скрипт в память контроллера? Туда лучше заливать откомпиленный код, т.к. синтаксический разбор может быть весьма громоздкой задачей. При разборе нужен уровень представления пром.кода, а это тоже лишние килобайты. Эту часть лучше делать на ПК.

> Под память пользователя выделено несколько ячеек памяти. Это как наши статичные переменные. Скажем, 100шт. С учетом того, что это
> ТОЛЬКО на логику, должно хватить. Те более можно и расширять и добавлять, а более сложные вещи опускать на уровень ВМ, будет
> куда компактней и надежней.

Да, для начала сойдет. Потом же можно будет организовать отдельную микросхему статической RAM чисто под нужды работы байт-кода ВМ. Например, 64КБ хватит более чем. Так как эта память будет относится только к ВМ, а не контроллеру, работа с ней будет выполняться так же с помощью слоя HAL (к примеру)

> Многозадачность скриптов. Заводится массив указателей и каждый скрипт может вызывать другой скрипт, при этом ему выделяется свой
> указатель и он начинает крутиться параллельно первому. В принципе можно и терминировать его, проблем не составит.
> Сами же скрипты линейные. Общение между ними через те же общие переменные.

Да! Как я и говорил - многопоточный механизм с общей памятью

Под скриптом я тут имею ввиду блок БК. А не человеческое представление.

Так у меня ведь пока реализован только нижний уровень. При отсутствии (пока!) центрального контроллера, естественно, я отдаю команды ходовому контроллеру напрямик, с виртуального пульта компа. Должен же он их откуда-то получать. Зато это дает мне удобную возможность отладить нижний уровень и за это время лучше обдумать верхний. Если же свалить все в одну кучу, на один контроллер, пусть даже ARM, да еще с виртуальными машинами, вообще замаешься отлаживать все сразу: и работу датчиков, и ходовую, и скрипты, и ВМ...
Ходовому контроллеру, контроллеру бамперов - и 2-4к за глаза (если писать но нормальному), башне от 4 до 8К тоже хватит. А на центральный я планирую пока Мегу 128, или аналогичное из PIC. Думаю, 128кб при моих подходах к программированию хватит на что угодно. (Опыт кое-какой есть). Я же не буду туда Линуха или VISTA совать.
А нафига? Центральный контроллер будет получать от компа конкретные задания высокого уровня типа: "Взять под охрану помещение", "Переместиться в точку с координатами XY", "Вести видеонаблюдение в направлении XXX", "Разбудить в ЧЧММ", "Вернуться на базу", а последовательность действий для выполнения будет определять центральный контроллер робота, детализируя приказ для более низких уровней, исходя из логики, заложенной в собственную программу. Если же ему спускать целую портянку скриптов, в которых уже жестко прописаны все мелкие действия, какой же это интеллект? Это уровень древней ЭВМ с перфолентой.

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

SWG, Скрипты (bash, python, perl, lua, php) пользую уже много-много лет, и пока никаких нареканий по ненадежности небыло. А после того, как научился вшивать их в свои программы уважение к скриптам только возросло.
Дайвайте забудем разногласия по-поводу флаговых автоматов, ВМ, ОС и взглянем хотя б на определение ОС в вики:
Операцио́нная систе́ма, ОС (англ. operating system) — базовый набор функций, обеспечивающий управление аппаратными средствами компьютера.
Теперь на ВМ
Виртуальная машина (англ. virtual machine) — программная или аппаратная среда, исполняющая некоторый код (например, байт-код, шитый код, p-код или машинный код реального процессора), или спецификация такой системы (например: «виртуальная машина языка программирования Си»).
и поймем что и то, и другое (в нашем случае) по сути одно и тоже.
Под ОС я понимаю именно ОС, а не GUI, свистелки и чего там еще в столь не любимой висте напридумано.

Адресация со стороны ВМ - я плохо представляю, что это. Компиляторы решают проблему вычисления метки в адрес (абсолютный, относительный, не важно). Т.е. команду
X=1
переводят в что-то вроде "в ячейку с адресом таким-то записать 1". С переходами тоже, мы просто пишем метку в коде, а компилятор вычисляет её адрес. Как это будет делать ВМ? разве, что ввести (как уже предлагалось) переходы на N команд. Но если язык будет компилируемый, то это будет лишним.

З.Ы.
Задача API абстрагироваться от программирования железок напрямую. Это и есть основная функция ОС. Задача ВМ, так же как и реальной машины - выполнять какой-то код, т.е. те самые вышеупомянутые скрипты.
SWG, вы так не хотите пихать линуха и висту, но по сути, ОС и драйверы устройств у Вас уже запихана, для того, чтобы повернуть башню не надо что-то объяснять шд, надо просто послать команду на поворот. И виртульная машина тоже - ведь понимает как-то Ваш робот довольно высокоуровневые команды

Хочу прикрутить нечто подобное к глобусу, но нацеленное на отображение графики в память, откуда оно будет выводиться на светодиоды, касательно компилятора - проблем нет, как будет относительно продуманный синтаксис и система байткода - обращайтесь, сделаю :-)

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

SWG

> Если же свалить все в одну кучу, на один контроллер, пусть даже ARM, да еще с виртуальными машинами, вообще замаешься отлаживать
> все сразу: и работу датчиков, и ходовую, и скрипты, и ВМ...

Вот! В контроллере (пусть и арм) будет только ВМ и драйверы устройств. Ничего больше, поэтому и отлаживать будет почти нечего! Вся отладка будет вестись на ПК - отладка скриптов :) Да, ВМ, конечно, сначала придется разработать и заставить работать, но без этого никуда не деться

> А нафига? Центральный контроллер будет получать от компа конкретные задания высокого уровня

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

> Если же ему спускать целую портянку скриптов, в которых уже жестко прописаны все мелкие действия, какой же это интеллект? Это
> уровень древней ЭВМ с перфолентой.

Так у вас то же самое, но без скриптов и ВМ

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

А зачем фаззи лоджику плавающая точка? Там можно все и целочисленно намутить.

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

Поэтому я и сказал - оптимизировать

Это вы, возможно, с линуксами не встречались.

Holy War Mode off

И меня в это не втягивайте, а то знаете же...

SWG
Я смотрю, ты программу для PIC пишешь на Паскале. Каким компилятором ты пользуешься ?

PS: Я одно время разрабатывал свой собственный компилятор паскаля, как раз для PIC. Сейчас хочу вернуться к старому проекту, переработать (классы, авр-архитектура) и закончить его. Все компиляторы паскаля для PIC, которые я видел до этого, мне очень сильно не нравились.