Создаем ROBO_API

@DY HOTT · Регистрация: 22.01.2010

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

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

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

19.02.2010, 01:40

Сообщение от oiori

:)
Это не виртуальная машина - это дешифратор команд.

Естественно. Я же не собираюсь в 8кб памяти программ VISTA пихать. Все, что мне надо, я на своем любимом флаговом автомате сделаю. Безо всякой мороки с виртуальными машинами, операционками... Тем более в контроллерах нижнего уровня - ходовом, бамперов, башни... Вот для центрального - может, и озабочусь операционкой. И то пока особой необходимости не вижу. Лучше больше интеллекта напихать, чем занимать место ненужными оболочками. Думаю, Мега 128 или аналогичный по возможностям из PIC24-32 вполне справятся.
Не важен процесс, важен результат. С операционкой или без - лишь бы свои задачи выполняло. Лет 20-25 назад на работе на 2-4кб ПЗУ я такие многозадачные контроллеры реального времени делал...

@oiori · 19.02.2010, 01:48

Да, но мне кажется, что в этой теме идет обсуждение ВМ, а не флаговых автоматов для атомарных действий :) Вот я и предлагаю думать в соответствующем направлении. В 8 КБ памяти можно много чего напихать, может и ВМ с RISC набором команд поместится. А весь интеллект будет задаваться с помощью этого самого байт-кода, так что ничего более там не будет. А так как байт-код будет читаться как данные, то место его хранения значения не имеет - хоть на компакт-флеш

19.02.2010, 01:57

Сообщение от oiori

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

Это уже будет функция не ходового, а центрального контроллера, а он будет работать с картами окружающего пространства, промерянного дальномерами и разбитого на квадраты.
Тут скорее я бы вам задал вопрос: Как вы с пульта или компьютера сформулируете роботу задание: "Поехать вперед, не доезжая до стены 1 метр остановится, развернуться, и вернуться в первоначальную позицию"? Каким формализованным языком или набором команд?
Я при своем вполне логичном и рациональном подходе скорее дал бы задание "Проехать в точку с координатами ХУ и вернуться в точку отправления". Трассу робот выберет сам, исходя из кратчайшего пути и наличия препятствий. А ходовой контроллер от центрального будет получать те же команды пути и скорости, что я уже отладил и описал выше.

19.02.2010, 02:03

Сообщение от oiori

Да, но мне кажется, что в этой теме идет обсуждение ВМ, а не флаговых автоматов для атомарных действий :) Вот я и предлагаю думать в соответствующем направлении. В 8 КБ памяти можно много чего напихать, может и ВМ с RISC набором команд поместится. А весь интеллект будет задаваться с помощью этого самого байт-кода, так что ничего более там не будет. А так как байт-код будет читаться как данные, то место его хранения значения не имеет - хоть на компакт-флеш

ROBO_API - это не обязательно ВМ. Это всего лишь инструмент, с помощью которого можно создавать программы для роботов. А инструмент бывает разный, и вовсе не обязательно забивать гвозди микроскопом, хоть и им тоже можно. Я предлагаю для этого молоток. А микроскоп приберегу для чего-нибудь другого, если будет нужно. Кстати, микроскоп у меня был. Лет 30 назад. Я им побаловался, удовлетворил свое любопытство, и продал. Не гвозди же им забивать...

@bivysi · 19.02.2010, 02:19

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

>"Поехать вперед, не доезжая до стены 1 метр остановится, развернуться, и вернуться в первоначальную позицию"
В итоге (как я думаю) должно получиться что-то вроде
пока(Датчик(дальномер)<100см) {
Двигаться(вперед,1см);
}
Компилятор переведет это в что-то вроде

:Метка1
Получить Дальномер, х
Сравнить х,100см
ЕслиМеньшеПереход на метка2
Сервопривод ПравоеКолесо, 1см
Сервопривод ЛевоеКолесо, 1см
ЖдатьВыполнения ЛевоеКолесо И ПравоеКолесо

Переход Метка1
:Метка2
Такого рода инструкции уже можно довольно просто написать (а у SWK они уже реализованы)
Самое интересное будет организовать универсальность. Например унифицировать все обращения к датчикам, сервоприводам, етс. Тогда модификция получившейся ОС для нового робота будем минимальна -- зарегистрировать при старте устройства и написать их обработчики. А для конечного пользователя будет абсолютно неважно, опрашивает он датчик напряжения аккумулятора или дальномер, едет вперед или машет рукой

19.02.2010, 02:47

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

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

А для конечного пользователя будет абсолютно неважно, опрашивает он датчик напряжения аккумулятора или дальномер, едет вперед или машет рукой

По моему тут вы погорячились. Если мне нужно знать напряжение батареи, а вместо этого он чем-то там махать начнет, я могу ведь ему и не простить...

@bivysi · 19.02.2010, 03:12

Сообщение от SWK

По моему тут вы погорячились. Если мне нужно знать напряжение батареи, а вместо этого он чем-то там махать начнет, я могу ведь ему и не простить...

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

19.02.2010, 08:34

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

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

@DY HOTT · 19.02.2010, 09:13

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

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

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

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

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

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

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

Критикуйте!

19.02.2010, 09:34

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

@DY HOTT · 19.02.2010, 11:00

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

@oiori · 19.02.2010, 12:09

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

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

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

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

Code
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
const
DEV_TRACTION_MOTOR      = $0E;
DEV_WHEEL_MOTOR         = $0D;
DEV_IR_LOCATOR          = $01;
 
var
integer time_s, time_len;
 
func TimerProc() {
time_s = time_s + 1;
if (time_s = time_len) {
SetDeviceAction(DEV_TRACTION_MOTOR, [0]); // Останавливаем в первоначальной позиции
ExtractFromTimerQueue(TimerProc);
}
 
if (GetDeviceState(DEV_IR_LOCATOR) <= 100) {
SetDeviceAction(DEV_TRACTION_MOTOR, [0]); // Выключаем двигатель
SetDeviceAction(DEV_WHEEL_MOTOR, [180]);  // Разворачиваем робота на 180 градусов.
// Будем считать, что он имеет отдельный поворотный механизм
// А если нет, то разворачивать можно в отдельнойй процедуре
// с контролем соответствующих датчиков
 
SetDeviceAction(DEV_TRACTION_MOTOR, [1]); // go обратно
time_len = time_s;
time_s = 0;
}
}
 
func stort main() {
time_s = 0;
time_len = 0;
SetDeviceAction(DEV_TRACTION_MOTOR, [1]); // Включили двигатель и поехали вперед
SetTimerMode(TimerProc, 1000);
}

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

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

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

@oiori · 19.02.2010, 12:19

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

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

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

Code
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
const
DEV_LIGHT_SENSOR      = $02;
DEV_TRACTION_MOTOR    = $0E;
 
func task LightControl() {
while True do {
if (GetDeviceState(DEV_LIGHT_SENSOR) > $80)
SetDeviceAction(DEV_TRACTION_MOTOR, [0]);
}
}
 
func stort main () {
SetDeviceAction(DEV_TRACTION_MOTOR, [1]);
AddTask(LightControl);
}

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

@oiori · 19.02.2010, 12:26

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

@oiori · 19.02.2010, 12:29

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

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

@oiori · 19.02.2010, 12:33

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

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

@oiori · 19.02.2010, 12:40

DY HOTT

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

да

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

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

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

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

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

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

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

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

@DY HOTT · 19.02.2010, 14:14

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

19.02.2010, 15:14

SWK, ваша реализация хороша для дистанционного управления. По сути она и есть протокол ДУ.

Так у меня ведь пока реализован только нижний уровень. При отсутствии (пока!) центрального контроллера, естественно, я отдаю команды ходовому контроллеру напрямик, с виртуального пульта компа. Должен же он их откуда-то получать. Зато это дает мне удобную возможность отладить нижний уровень и за это время лучше обдумать верхний. Если же свалить все в одну кучу, на один контроллер, пусть даже ARM, да еще с виртуальными машинами, вообще замаешься отлаживать все сразу: и работу датчиков, и ходовую, и скрипты, и ВМ...

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

Ходовому контроллеру, контроллеру бамперов - и 2-4к за глаза (если писать но нормальному), башне от 4 до 8К тоже хватит. А на центральный я планирую пока Мегу 128, или аналогичное из PIC. Думаю, 128кб при моих подходах к программированию хватит на что угодно. (Опыт кое-какой есть). Я же не буду туда Линуха или VISTA совать.

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

А нафига? Центральный контроллер будет получать от компа конкретные задания высокого уровня типа: "Взять под охрану помещение", "Переместиться в точку с координатами XY", "Вести видеонаблюдение в направлении XXX", "Разбудить в ЧЧММ", "Вернуться на базу", а последовательность действий для выполнения будет определять центральный контроллер робота, детализируя приказ для более низких уровней, исходя из логики, заложенной в собственную программу. Если же ему спускать целую портянку скриптов, в которых уже жестко прописаны все мелкие действия, какой же это интеллект? Это уровень древней ЭВМ с перфолентой.

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

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

@bivysi · 19.02.2010, 15:37

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

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

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

Новые блоги и статьи Все статьи Все блоги /
Программа для com-порта Uhbif79 05.06.2026 Всем привет, давно хотел изучить Qt, начинал, бросал, потом снова начинал. И сейчас вот смог написать свою первую программу. До этого имел опыт программирования микроконтроллеров, писал прошивки на. . .	Транскрипция 55-минутного видео через Whisper: WhisperDesktop облажался, спас Google Colab[ anaschu 01.06.2026 Понадобилось получить текст из свежезагруженного видео на YouTube. Казалось бы, задача на пять минут. Заняла полтора часа. Делюсь опытом — может кому пригодится последовательность решений. . . .	21 мат мед. Планы на развитие модели здравоСохранения anaschu 01.06.2026 AnyLogic: план развития симуляционной модели рабочего коллектива — динамический абсентеизм, реальные данные, три сценария сравнения Продолжаю серию постов о дискретно-событийной модели рабочего. . .	20. Мат мед. Абсентеизм как отдельный тип простоя anaschu 29.05.2026 Апдейт модели: исправленные баги, абсентеизм и новые механизмы Продолжаю развивать ранее описанную модель рабочего коллектива на AnyLogic. За последние несколько дней был проведён серьёзный. . .
19. здоровье, усталость и психотип работника влияют на производительность предприятия, и наоборот, производительность на здоровье, усталось и психотип anaschu 28.05.2026 Дискретно-событийная модель рабочего коллектива на AnyLogic: здоровье, выгорание, психотипы и микростимуляция Привет, коллеги. Хочу поделиться итогами нескольких недель работы над симуляционной. . .	"Прокси" для последовательного порта Eddy_Em 28.05.2026 Эту штуку написал я достаточно давно. Но сейчас вот понадобилось настроить датчик грозы, но при этом не отключать его от "метеодемона". Соответственно, надо запустить этот "прокси": метеодемон будет. . .	Рефакторинг программы уравнивания. Massaraksh7 26.05.2026 Пример по предыдущей записи в блоге. Но, надо заметить, что, во-первых, там оптимизация не только математики, но и работы с базой данных, и с графами, а во-вторых, это ещё не всё.	Использование TThread в Lazarus для математических вычислений. Massaraksh7 25.05.2026 Производя рефакторинг своих программ на предмет ускорения их работы, обратил внимание на такой аспект, как сокращение времени матвычислений. Дело в том, что приходится работать с большими матрицами. . .

@DY HOTT 0 / 0 / 1 Регистрация: 22.01.2010 Сообщений: 4,000

	Создаем ROBO_API 18.02.2010, 08:30. Показов 294003. Ответов 148 Метки нет (Все метки) Пища для размышлений: Виртуальные машины Понятно, что шасси и механика может быть различной, но в данном случае это уже зависит от реализации непосредственно виртуальной машины, а нам бы общую концепцию выработать. Синтаксис. Может даже свой язык. А если кто и компилятор осилит накатать ваще будет феерично. 0

@oiori 0 / 0 / 0 Регистрация: 15.02.2010 Сообщений: 28
	19.02.2010, 01:48
	Да, но мне кажется, что в этой теме идет обсуждение ВМ, а не флаговых автоматов для атомарных действий :) Вот я и предлагаю думать в соответствующем направлении. В 8 КБ памяти можно много чего напихать, может и ВМ с RISC набором команд поместится. А весь интеллект будет задаваться с помощью этого самого байт-кода, так что ничего более там не будет. А так как байт-код будет читаться как данные, то место его хранения значения не имеет - хоть на компакт-флеш 0

@bivysi 0 / 0 / 0 Регистрация: 14.02.2010 Сообщений: 494
	19.02.2010, 02:19
	Ну висту пихать и не обязательно, а вот виртуальную машину как раз можно, при продуманной архитектуре очень полезная вещь может получиться. Вообще смысл виртуальной машины как раз и есть в дешифрации команд, чтобы отделить пользователя от низкоуровнего программирования. Операционка, кстати, выполняет те же самые функции. Так что, как не назови смысл один и тот же. >"Поехать вперед, не доезжая до стены 1 метр остановится, развернуться, и вернуться в первоначальную позицию" В итоге (как я думаю) должно получиться что-то вроде пока(Датчик(дальномер)<100см) { Двигаться(вперед,1см); } Компилятор переведет это в что-то вроде :Метка1 Получить Дальномер, х Сравнить х,100см ЕслиМеньшеПереход на метка2 Сервопривод ПравоеКолесо, 1см Сервопривод ЛевоеКолесо, 1см ЖдатьВыполнения ЛевоеКолесо И ПравоеКолесо Переход Метка1 :Метка2 Такого рода инструкции уже можно довольно просто написать (а у SWK они уже реализованы) Самое интересное будет организовать универсальность. Например унифицировать все обращения к датчикам, сервоприводам, етс. Тогда модификция получившейся ОС для нового робота будем минимальна -- зарегистрировать при старте устройства и написать их обработчики. А для конечного пользователя будет абсолютно неважно, опрашивает он датчик напряжения аккумулятора или дальномер, едет вперед или машет рукой 0

@DY HOTT 0 / 0 / 1 Регистрация: 22.01.2010 Сообщений: 4,000
	19.02.2010, 09:13
	Такс, а вот у меня какие соображения. Оставим в сторону ВМ, она, несомненно, нужна в том или ином роде, но в данном случае ВМ пишется под АПИ, а не наоборот. Итак. Предлагаю такой вариант языка скрипта. Команда переменной длины. коп:аргумент:аргумент:аргумент... и так далее, сколько надо столько и будет. Обработчик этой конструкции будет проще простого. БК компилируемый!!! Т.е. все переходы абсолютные. Адресация каждой цепочки начинается от начала ее и до конца. Т.е. как на х86 в COM файлах. Поэтому переменная длина команд нам тут палки в колеса вставлять не будет, да и обрабатывать это можно в две три команды. Компактность и скорость! (интерпритатор нам нахер не уперся, проще заливать в память весь скрипт целиком) Под память пользователя выделено несколько ячеек памяти. Это как наши статичные переменные. Скажем, 100шт. С учетом того, что это ТОЛЬКО на логику, должно хватить. Те более можно и расширять и добавлять, а более сложные вещи опускать на уровень ВМ, будет куда компактней и надежней. Многозадачность скриптов. Заводится массив указателей и каждый скрипт может вызывать другой скрипт, при этом ему выделяется свой указатель и он начинает крутиться параллельно первому. В принципе можно и терминировать его, проблем не составит. Сами же скрипты линейные. Общение между ними через те же общие переменные. На выходных попробую для своего робота написать простейший вариант. Еще тут параллельно может чел один редактор сварганит. Сейчас мы с ним обсуждаем ряд технических моментов. Критикуйте! 0

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

@DY HOTT 0 / 0 / 1 Регистрация: 22.01.2010 Сообщений: 4,000
	19.02.2010, 11:00
	Скрипты. байт код. Называй как хочешь, лишь бы не путать с нативным машинным языком 0

@oiori 0 / 0 / 0 Регистрация: 15.02.2010 Сообщений: 28
	19.02.2010, 12:26
	Погнали дальше. Немного фантазии :) Все видели редакторы карт для компьютерных игр? Кто сказал, что такое нельзя сделать для робота в реальном мире? Редактируя карту комнаты, раставляя на ней различные объекты и добавляя уже существующие блоки "разумного поведения", например объезда препятствий, можно будет мышкой задать роботу весьма и весьма сложный алгоритм действий. На выходе редактора будет скрипт, который откомпилется компилером и зальется в робота по радиоканалу. 0

@oiori 0 / 0 / 0 Регистрация: 15.02.2010 Сообщений: 28
	19.02.2010, 12:29
	byvysi > например если в системе зарегистрированы датчики напряжения АКБ и дальномер, то получить > значения измерений с них можно будет одинаковыми командами Верное замечание! Я как раз использовал этот метод в своем коде. Только для его реализации нужна будет унификация на уровне ВМ, т.е. слой с набором низкоуровневых программ и слой абстракции (HAL, Hordware Abstraction Layer) 0

@oiori 0 / 0 / 0 Регистрация: 15.02.2010 Сообщений: 28
	19.02.2010, 12:33
	SWK > Ох, не люблю я скриптовые языки почему-то... Еще со времен DOS к ним какое-то отвращение, на уровне > подсознания, как к чему-то примитивному и ненадежному. В них нет ничего ненадежного. Это такая же строгая логика как и набор машинных команд. Естественно, понадобится надежная реализация, но уж куда без нее. Да и всегда интересно работать над сложными проектами, это повышает уровень профессионализма и интерес к жизни :) 0

@oiori 0 / 0 / 0 Регистрация: 15.02.2010 Сообщений: 28
	19.02.2010, 12:40
	DY HOTT > Команда переменной длины. коп:аргумент:аргумент:аргумент... и так далее, сколько надо столько и будет. Обработчик этой конструкции будет проще простого. да > БК компилируемый!!! Т.е. все переходы абсолютные. Адресация каждой цепочки начинается от начала ее и до конца. > Т.е. как на х86 в COM файлах. Поэтому переменная длина команд нам тут палки в колеса вставлять не будет, да и обрабатывать > это можно в две три команды. Компактность и скорость! да, это обязательно. Заливаться будет блок кода > (интерпритатор нам нахер не уперся, проще заливать в память весь скрипт целиком) А это не понял. Скрипт в память контроллера? Туда лучше заливать откомпиленный код, т.к. синтаксический разбор может быть весьма громоздкой задачей. При разборе нужен уровень представления пром.кода, а это тоже лишние килобайты. Эту часть лучше делать на ПК. > Под память пользователя выделено несколько ячеек памяти. Это как наши статичные переменные. Скажем, 100шт. С учетом того, что это > ТОЛЬКО на логику, должно хватить. Те более можно и расширять и добавлять, а более сложные вещи опускать на уровень ВМ, будет > куда компактней и надежней. Да, для начала сойдет. Потом же можно будет организовать отдельную микросхему статической ROM чисто под нужды работы байт-кода ВМ. Например, 64КБ хватит более чем. Так как эта память будет относится только к ВМ, а не контроллеру, работа с ней будет выполняться так же с помощью слоя HAL (к примеру) > Многозадачность скриптов. Заводится массив указателей и каждый скрипт может вызывать другой скрипт, при этом ему выделяется свой > указатель и он начинает крутиться параллельно первому. В принципе можно и терминировать его, проблем не составит. > Сами же скрипты линейные. Общение между ними через те же общие переменные. Да! Как я и говорил - многопоточный механизм с общей памятью 0

@DY HOTT 0 / 0 / 1 Регистрация: 22.01.2010 Сообщений: 4,000
	19.02.2010, 14:14
	Под скриптом я тут имею ввиду блок БК. А не человеческое представление. 0

@bivysi 0 / 0 / 0 Регистрация: 14.02.2010 Сообщений: 494
	19.02.2010, 15:37
	SWK, Скрипты (bash, python, perl, lua, php) пользую уже много-много лет, и пока никаких нареканий по ненадежности небыло. А после того, как научился вшивать их в свои программы уважение к скриптам только возросло. Дайвайте забудем разногласия по-поводу флаговых автоматов, ВМ, ОС и взглянем хотя б на определение ОС в вики: Операцио?нная систе?ма, ОС (англ. operating system) — базовый набор функций, обеспечивающий управление аппаратными средствами компьютера. Теперь на ВМ Виртуальная машина (англ. virtual machine) — программная или аппаратная среда, исполняющая некоторый код (например, байт-код, шитый код, p-код или машинный код реального процессора), или спецификация такой системы (например: «виртуальная машина языка программирования Си»). и поймем что и то, и другое (в нашем случае) по сути одно и тоже. Под ОС я понимаю именно ОС, а не GUI, свистелки и чего там еще в столь не любимой висте напридумано. Адресация со стороны ВМ - я плохо представляю, что это. Компиляторы решают проблему вычисления метки в адрес (абсолютный, относительный, не важно). Т.е. команду X=1 переводят в что-то вроде "в ячейку с адресом таким-то записать 1". С переходами тоже, мы просто пишем метку в коде, а компилятор вычисляет её адрес. Как это будет делать ВМ? разве, что ввести (как уже предлагалось) переходы на N команд. Но если язык будет компилируемый, то это будет лишним. З.Ы. Задача API абстрагироваться от программирования железок напрямую. Это и есть основная функция ОС. Задача ВМ, так же как и реальной машины - выполнять какой-то код, т.е. те самые вышеупомянутые скрипты. SWK, вы так не хотите пихать линуха и висту, но по сути, ОС и драйверы устройств у Вас уже запихана, для того, чтобы повернуть башню не надо что-то объяснять шд, надо просто послать команду на поворот. И виртульная машина тоже - ведь понимает как-то Ваш робот довольно высокоуровневые команды 0