October 11th, 2012

2019

Робототехника сдвинулась с места

Считаю, что повторение курса программирования закончилось. Хотя в связи с общей сентябрьской сопливостью семьи (тьфу-тьфу, кроме меня!) мы даже урок 13 курса Кириенко так и не довели до конца, но зато качество кода в повторно решаемых задачах было получше, чем при первом проходе годичной давности, и общее потраченное на решение задач время было существенно поменьше. Тренинг по слепому десятипальцевому методу печати был тоже закончен на скорости 100 ударов в минуту.

За время повторения прошлогоднего материала был разработан исполнитель ЛегоРобот в КуМире в Ubuntu, каковой дистрибутив был кинут на флешку, с которой это всё грузится на любую машину. Всё дико тормозит (ибо интерпретатор в компьютере, а не в "кирпиче" робота, а команды робота через bluetooth проходят крайне медленно, чуть ли не на 10Гц), но этого будет вполне достаточно для довольно обширного (думаю этим заниматься до конца ноября) курса.

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



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

Моторы подключаются к портам А и B (здесь и далее -- русские буквы! Ершол -- русский алгоритмический язык, и переключение регистров в нём крайне болезненно для дитятки, он пока не печатает вслепую по-английски), датчики (если они используются) должны быть подключены к портам
-- касание -- 1
-- сонар -- 2
-- RGB датчик (используется только как датчик освещённости) -- 3

Команды включения/выключения моторов (буквы А и В кириллические! и их менять нельзя, они на "кирпиче" написаны -- А, В, С):
-- моторА(вещ мощность)
-- моторВ(вещ мощность)
Мощность -- от 100 до -100, при положительной мощности моторы крутятся в прямом направлении, при отрицательной -- в обратной, при нулевой -- не крутятся. Нужно учитывать, что в реалии там частотно-импульсное управление шаговыми двигателями, и как раз мощность постоянна, но прореживаются подаваемые на мотор импульсы. Поэтому робот будет ехать на модности мотора "20" с одинаковой скоростью что по плоскости, что в гору, что с прицепом, что без прицепа: от скорости "70" это будет отличаться не мощностью на валу, а именно скоростью проворачивания вала двигателя.

Счетчики углов поворота мотора выдают в градусах угол оборота оси от момента последнего сброса (внимание! Погрешность 5-6%):
-- вещ уголА
-- вещ уголB
Сброс датчиков угла поворота:
-- сбросA
-- сбросB

Освещённость от 0 (черный, никогда не бывает -- обычно от 25) до 100 (белый, никогда не бывает, обычно до 80 в хорошую погоду) выдаётся так:
-- вещ свет

Расстояние меряется в диапазоне от 10см до 255смметров) и не слишком велико (больше 255 сантиметров):
-- вещ расстояние

Датчик касания:
-- лог тык - был ли тык после последнего забывания
-- забыть тык – без комментариев (помним, что в КуМире в идентификаторах вполне могут быть пробелы).

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

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

Какие задачи можно решать на таком простом наборе команд? Огромное количество. Вот, например, один из соавторов ЛегоРобот Денис Хачко написал программу измерения диаметра колеса (эта программа меряет довольно точно: ошибается буквально на миллиметр-два). Для измерения ЛегоРобота нужно поставить недалеко от стенки.

использовать ЛегоРобот
алг
нач
  сбросА

  вещ расст
  расст := расстояние

  моторА (20)
  моторВ (20)
  ждать (2.5)
  моторА (0)
  моторВ (0)

  вещ угл
  ждать (0.5)
  угл :=уголА

  вещ путь, оборотов
  путь := расст-расстояние
  оборотов := угл/360
  вывод "Диаметр колеса:", (путь/оборотов)/3.14
кон


Как видим, это тривиальнейшие с точки зрения алгоритмики задачи, но:
-- там много-много формул, и нужно понимать связь этих формул с тем, что происходит в реальном мире: лабораторные работы по физике-математике прежде всего, алгоритмика тут практически вторична
-- это другой Исполнитель, нежели "нарисованный робот", но прежний язык. Плюс Чертёжник, который в этом курсе будет неизбежен. Осваивается мысль про API, модульность и соответствующий стиль программирования.
-- это всё-таки реальное время (хотя и самый простой его вариант).
-- это реальный мир с реальными трудностями (на большой скорости робот не успевает быстро и точно считывать расстояние через медленный канал, так что задача "остановиться на расстоянии 50 см от стенки" плохо выполняется простейшим циклом "нц пока расстояние>50 ехай кц стой" на мощности мотора больше 80. Это отдельная задача -- сделать пропорциональный алгоритм управления остановкой при данных ограничениях аппаратуры.

Традиционные задачи -- прохождение поворота с радиусом R, проверить соседнее помещение на предмет выключенности там света, найти "клад" в виде черного листочка на полу комнаты, вытолкнуть все консервные банки из нарисованного чёрного круга диаметром 1м, узнать скорость движения робота с колёсами разного диаметра (и вычислить, какого диаметра должны быть колёса, чтобы сравняться по скорости с чемпионами соревнований).

Более серьёзные задачи -- сделать из робота радар (в исполнителе Чертёжник можно делать графики. Если робот крутить на месте и брать отсчёты сонара, то можно попробовать нарисовать стенки на поле Чертёжника), проехать как можно быстрее по извилистой чёрной линии (требует использования пропорционального регулятора), выбраться из лабиринта (с невысокими стенками).

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

Заметки с заседания по порождающему проектированию

Вчера у нас было 64 заседание Русского отделения INCOSE. Мы продолжили разбираться с моделеориентированной системной инженерией (http://ailev.livejournal.com/1023574.html), темой была практика порождающего проектирования (материалы тут: http://incose-ru.livejournal.com/36942.html -- докладчиком был Сергей Кравченко, вот страничка с его видеороликами "для тех, кто понимает": https://www.youtube.com/user/zerganalizer).

Мои заметки с заседания:

1. САПРы слабенькие, средние и топовые почти неразличимы в плане возможностей режима "редактирование". Различия становятся драматическими, когда речь заходит о порождающем проектировании. Тут играют свою роль не только мощность геометрического движка, и возможности среды программирования над этим движком. У топовых САПРов в этом плане огромные возможности.

2. Нормальная работа с порождающим проектированием требует знакомства сразу с тремя предметными областями:
-- инженерией (того инженерного уклада -- множества стандартов -- http://ailev.livejournal.com/1027975.html), для которого происходит порождение
-- геометрией (ибо это тот язык, на котором решается задача: все эти NURBS, тесселяции, "массивы" и т.д.).
-- программированием (в том числе в весьма неординарных парадигмах, например "программирование на сапровских деревьях")

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

3. Инструментарий для порождающего программирования пока не слишком развит. Большинство систем представляют либо интерфейс "геометрического ассемблера" с необходимостью программирования во много слоёв, или наоборот, возможность указать небольшое число параметров для чего-то высокоспециализированного и поэтому уже негибкого. Сергей Кравченко как раз утверждал, что он разработал инструментарий, позволяющий облегчить задачу порождающего проектирования в среде программирования CATIA.

4. Представление геометрии "в данных" (а не в программах) хорошо только при передаче информации от "САПР-редактора" к "САПР-редактору". Ежели перейти к порождающему проектированию, то геометрия представляется уже не столько данными (формами, shapes), но и правилами (rules), которые представляют собой программы в некоторой модели вычислений. Передача правил -- это передача программ, для которых "нейтрального" или "онтологического" или ещё какого представления не придумано в общем виде. Поэтому при переходе к порождающему проектированию придётся всё жестче и жёстче настаивать на архитектурном решении, которое было когда-то принято в проекте Simantics: "даже не думать, что можно как-то нормализовать/унифицировать представление модели. Оно всегда глубоко специфично для конкретного солвера, и туда даже не стоит пытаться лезть. Можно заниматься только унификацией работы с данными, которые подаются моделям+солверам на вход, и получаются на выходе из моделей+солверов".

5. В момент осознания, что порождающее проектирование -- это прежде всего программирование над API геометрических движков, появятся САПР, в которых будет меньшая ориентация на редактирование, и большая ориентация на программирование -- то есть САПР, более похожие на привычные IDE. И нужно не забывать, что все эти "деревья" -- это в существенной мере управление конфигурацией, т.е. это вотчина PLM. Так что в связи с неминуемым расцветом порождающего проектирования можно ожидать резкого изменения архитектурных решений и новых (прежде всего связанных с программированием и парадигмами вычислений над геометрией) технологий. Как всегда в таких случаях смены основных технологий, возможна и смена лидеров сапростроения.