Використання графічної бібліотеки opengl 6 страница

💸 Как сделать бизнес проще, а карман толще?

Тот, кто работает в сфере услуг, знает — без ведения записи клиентов никуда. Мало того, что нужно видеть свое раписание, но и напоминать клиентам о визитах тоже. Проблема в том, что средняя цена по рынку за такой сервис — 800 руб/мес или почти 15 000 руб за год. И это минимальный функционал. Нашли самый бюджетный и оптимальный вариант: сервис VisitTime.
⚡️ Для новых пользователей первый месяц бесплатно. А далее 290 руб/мес, это в 3 раза дешевле аналогов. За эту цену доступен весь функционал: напоминание о визитах, чаевые, предоплаты, общение с клиентами, переносы записей и так далее.
✅ Уйма гибких настроек, которые помогут вам зарабатывать больше и забыть про чувство «что-то мне нужно было сделать».
Сомневаетесь? нажмите на текст, запустите чат-бота и убедитесь во всем сами!

Неважко зрозуміти зміст бази даних. Вона формується відношеннями: is_a – приналежність об’єкта класу, connects – поєднання двох об’єктів третім (двох кімнат дверима), stands – стан об’єкта (дверей), is_in – місцезнаходження об’єкта (скриньки або робота у кімнаті), is_at – взаємне розташування одного об’єкта біля іншого.

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

Операторні схеми системи планування фактично представляють описи дій, що можуть виконуватися в межах описаної моделі світу. Для мобільного робота це можуть бути дії: відкрити (закрити) двері, перейти у кімнату N, перейти до об’єкта M, пересунути об’єкт P до об’єкта Q тощо.

Кожна операторна схема практично містить у собі:

1) твердження результату реалізації операторної схеми – події, яку забезпечує операторна схема;

2) тест виконання – перевірка відсутності реалізованого цільового факту;

3) тест валідності – перевірка придатності операторної схеми для забезпечення цілі системи планування;

4) список передумов: постановка (і виконання) умов, що передують виконанню дії операторної схеми;

5) список вилучення – список подій, що застаріють на момент виконання операторної схеми;

6) список додавання – список подій, що вносяться операторною схемою.

Схематично опис операторної схеми дії Перейти_до_Object зображено на рисунку 13.3.

Рисунок 13.3 – Структура опису дії у системі планування мобільного робота

Мету системи формулюють у вигляді бажаного факту, до якого система має перейти, наприклад:

де plan – предикат, що забезпечує досягнення поставленої цілі – знаходження поруч об’єктів box1 та box2.

Окрім вказаних компонентів проблемної області, у системі планування необхідно реалізувати, власне, вирішувач. Вирішувачем може бути предикат або набір предикатів у випадку реалізації мовою Пролог [13, 15] або набір відповідних функцій у випадку реалізації на C++ (автором реалізовані обидві схеми).

Як вже зазначувалося, завдання у системі формулюється як бажаний факт стану системи. Якщо такий факт не знаходиться у базі даних (тест виконання), викликається вирішувач, що реалізує схему пошуку рішення. Пошук рішення передбачає:

1) пошук предикатної схеми, яка відповідає поставленому завданню (у тому числі перевірка валідності);

Слід враховувати, що при виконанні списку передумов (звичайно, якщо такий визначено) досягнення підцілей проводиться рекурсивним викликом вирішувача, що вимагає чітких умов виходу з рекурсії.

Серед перспектив розвитку систем планування інтелектуальних роботів слід віднести, по-перше, розширення проблемної області. Таке розширення веде до зростання операторних схем та їх ускладнення. У випадках, коли одна мета може бути досягнута декількома шляхами, виникає необхідність попередньої оцінки складності операторної схеми. При цьому кожній схемі з набору, що забезпечує однакові цілі, відповідатиме відповідний коефіцієнт, а сам набір буде нечіткою множиною [12]. По-друге, функціонування роботів у реальному часі вимагатиме поліпшення процедур знаходження адекватних операторних схем, у тому числі із урахуванням алгоритмів „відкату”, відновлення попереднього стану предметної області. По-третє, розширення проблемної області визначатиметься розширенням кола операцій, виконуваних роботом, а послідовність виконання операцій (технологічний процес) визначатиме стратегію дій робота.

13.4 Реалізація програми системи планування робота у Visual C++

Реалізація системи планування робота засобами Visual C++ має певні особливості. По-перше, підхід Пролог-програм, що ґрунтується виключно на базах даних, у Visual С++ утруднюється відсутністю безпосередньо вбудованих у мову С++ засобів обробки баз даних, що вимагатиме реалізації спеціальних засобів подання. По-друге, розробку Visual С++-програми буде неможливо уявити без реалізації системи виконання розроблених планів.

Звісно, що вирішення завдання із розробки планів істотно залежатиме від початкового стану системи. Кожен об’єкт світу робота має бути однозначно описаним у БД програми.

Початкова база даних програми відповідає схемі, поданій на рисунку 13.4.

Рисунок 13.4 – Початкове розташування об’єктів у системі планування

Таким чином світ робота складатиметься з п’ятьох кімнат, поєднаних дверима (відкритими або закритими). У кімнатах знаходяться скриньки. Робот, як дієвий об’єкт такого обмеженого світу може виконувати такі дії:

− завантажуватися скринькою та звільнятися від неї.

Опишемо основні моменти розробки програми для системи розробки планів робота в обмеженому просторі, повний код якої наведено у додатку А.

1. Для опису початкового, поточного та кінцевого станів системи планування оголосимо клас СRoboPlan, наведений у прикладі 13.1.

Приклад 13.1 – Основний клас системи розробки планів робота

Як видно клас складається з трьох змінних-членів (типу покажчика на рядок) та ряду функцій. Поля *relname, *agent, *sobj1 та *sobj2 означають: ім’я відношення, що входить до складу факту бази даних; програмний суб’єкт (aгент), який виконує дію; два об’єкти sobj1 та sobj2, на які спрямовується дія.

Наявність у класі покажчика *next вказує на організацію даних у вигляді зв’язаного списку [8]. Об’єкти класустворюватимуться конструкторами трьох типів, що відповідатимуть різним ситуаціям конструювання об’єктів.

Функція dataformer() відповідає за ініціювання бази даних системи прийняття рішень, addfact() – за додавання фактів у базу даних від час роботи програми, а delfact() – у декілька реалізацій здійснює вилучення окремих фактів з БД програми. Функція delfactall() здійснює вилучення усіх фактів із подібними ознаками. Пере-вірка наявності або відсутності фактів у БД програми здійснюється за допомогою перевантаженої функції dbtest(), а пошук необхідних фактів – за допомогою findfact(). Також функції класу забезпечують друк бази даних (функція Print()) і обертання зв’язаного списку БД (функція Revers()).

Функції deciser(), find_action(), support_action(), old_cleaner() та new_adder() безпосередньо реалізують прийняті схеми побудови систем планування.

2. У програмі автоматичної генерації планів робота факти про стан об’єктів системи подаються зв’язаним списком [7, 8] та ініціалізуються функцією dataformer():

Приклад 13.2 – Функція ініціалізації стану світу робота

CRobotPlan *a23=new CRobotPlan(" connects", " door12", " room1", " room2", a22);

CRobotPlan *a24=new CRobotPlan(" connects", " door12", " room2", " room1", a23);

CRobotPlan *a25=new CRobotPlan(" connects", " door23", " room2", " room3", a24);

CRobotPlan *a26=new CRobotPlan(" connects", " door23", " room3", " room2", a25);

CRobotPlan *a27=new CRobotPlan(" connects", " door24", " room2", " room4", a26);

CRobotPlan *a28=new CRobotPlan(" connects", " door24", " room4", " room2", a27);

CRobotPlan *a29=new CRobotPlan(" connects", " door34", " room3", " room4", a28);

CRobotPlan *a30=new CRobotPlan(" connects", " door34", " room4", " room3", a29);

CRobotPlan *a31=new CRobotPlan(" connects", " door45", " room4", " room5", a30);

CRobotPlan *a32=new CRobotPlan(" connects", " door45", " room5", " room4", a31);

3. Для вирішення завдань системи реалізуємо функцію-вирішувач – deciser(), що структуруватиме послідовність прийняття рішень:

Вирішувач розпочинається з перевірки наявності у базі даних цільового факту. Насправді, якщо цільовий факт є вже присутнім у БД програми, будь-яка активність із програми втрачає сенс. Далі за допомогою функції find_action() знаходиться спосіб дій робота, що задовольняє поставленій меті завдання. Якщо необхідний спосіб дій знайдено, необхідно виконати усі передумови виконання дії – реалізується функцією support_action(). Функція old_cleaner() реалізує вилучення застарілих фактів з БД програми (список викреслення), а new_adder() додавання нових фактів (список додавання).

Якщо, наприклад, перед системою виникає завдання, у програмі створюється об’єкт типу CRobotPlan, для якого викликається функція-вирішувач, наприклад:

у даному випадку задається цільовий факт знаходження робота у кімнаті “room1”.

4. Для знаходження способу дій робота, що відповідатиме меті програми, реалізуємо функцію find_action(). Вибір способу дій цілком залежить від вигляду цільового факту. Наприклад, якщо завдання програми – “відкрити двері 23” сформулювати як новий цільовий факт:

у функції find_action() йому відповідатиме така ділянка програмного коду:

З програмного коду видно, що здійснюється перевірка, чи наявний факт “Двері23” у БД, і чи не знаходяться вони у відкритому стані.

5. Підтримка здійснення дій робота у програмі розробки планів реалізується функцією support_action(). Для кожного обраного способу дій у support_action() існує власний набір передумов. Зокрема дія “взяти скриньку” передбачатиме знаходження робота поряд з означеним об’єктом. Це реалізується такою ділянкою коду:

{CRobotPlan *subgoal=new CRobotPlan(" is_at", " robot", sobj1, NULL); // підціль

6. Реалізація списків викреслення та додавання забезпечується функціями old_cleaner() та new_adder(), що у випадку виконання дії “закрити двері” матимуть такі ділянки коду:

З наведеного коду видно, що як результат виконання дії “закрити двері” вилучатиметься закритий стан дверей і додається відкритий.

7. Встановлення початкової мети системи планування легко реалізувати за допомогою спеціального діалогового вікна із комбінованими списками. Кінцевий вигляд такого діалогового вікна наведено на рисунку 13.5.

Рисунок 13.5 – Вигляд діалогового вікна формування мети робота

За допомогою комбінованих списків “Агент” (містить значення “робот”, “скринька1”, “скринька2”, “скринька3”), “Дія” (“перейти_до”, ”штовхати_до”, “відкрити”, “закрити”) та “Об’єкт дії” (усі двері, кімнати та скриньки) можна сформувати завдання робота. Натискання кнопки “Підтвердити” означатиме закінчення вибору, перевірку коректності завдання та запуск системи планування. Перелік дій, що, в результаті, запланує система прийняття рішень виводитиметься до списку у правій частині діалогового вікна.

Натискання кнопки “Показати” запускає функції графічного відображення розробленого плану дій робота.

13.4.2 Реалізація графічного подання стану системи

Створення системи планування дій робота потребує демонстрації дій, щодо яких прийнято рішення, у головному вікні програми. Тому другим аспектом програми є створення системи функцій графічного відображення.

На рисунку 13.6 наведено повний вигляд інтерфейсу програми планування дій робота у замкненому просторі.

Рисунок 13.6 – Вигляд вікна програми планування дій робота

Під час побудови графічної компоненти системи планування слід звернути увагу на такі її аспекти:

1) у конструкторі головного вікна необхідно реалізувати об’єкти-складові віртуального вікна програми;

2) для дискретного переміщення графічних об’єктів необхідно реалізувати обробник таймера;

3) за допомогою окремих функцій реалізувати формування робочого протору робота та опис поточного стану об’єктів системи – робота, дверей, скриньок.

1. Пояснити загальні принципи проектування системи планування дій робота у обмеженому робочому просторі.

2. Пояснити структуру опису дії у системі планування дій робота.

3. Пояснити порядок знаходження рішень у програмі планування дій робота.

4. Пояснити порядок формування графічного інтерфейсу програми планування дій робота у обмеженому просторі.