CC BY
37
Максымив А.П., Рак Т.Е., Пелешко Д.Д. Аналитический обзор методов детектирования огня с помощью средств компьютерного зрения
Осуществлен аналитический обзор современных методов детектирования огня с помощью средств компьютерного зрения. В результате проведенной работы выявлено, что на сегодняшний день проблема разработки системы детектирования пламени актуальна и требует проведения дальнейших исследований. Представлен сравнительный анализ эффективности работы отдельно взятых методов и отмечены проблематичные моменты, которые вызывают снижение качества детектирования. Отмечены перспективные направления развития алгоритмов, которые, по нашему мнению, позволят в значительной степени повысить эффективность системы детектирования пламени.
Ключевые слова: детектирование пламени, компьютерное зрение, видеонаблюдение, автоматизация.
Maksymiv O.P., Rak T.E., Peleshko D.D. The Analytical Review of Fire Detecting Method by Using Computer Vision
The paper made an analytical review of modern fire detection methods by means of computer vision. The results of this work revealed that despite a number of publications in this field, today the problem of developing a flame detection system is urgent and requires further research. This paper presents a comparative analysis of the individual methods efficiency and marked problematic moments that cause reduced quality of detection. Noted the perspective directions of algorithms, which we believe will greatly improve the efficiency of detecting flames.
Keywords: flame detection, computer vision, video surveillance, automation.
УДК 004.[4+896]
ПРОГРАМНА МОДЕЛЬ ПЩСИСТЕМИ КЕРУВАННЯ МОБЫЬНОЮ РОБОТОТЕХН1ЧНОЮ СИСТЕМОЮ К.В. Матвшчук1, В.М. ТеслюК2, А.Я. Зелтський3
Описано особливост розроблення програмного забезпечення шдсистеми вщдалено-го керування робототехшчною системою (РТС). Побудовано ИМЬ дiаграму прецеден-пв, за допомогою яко! вщображено основш завдання, яю виконуватиме РТС у процес функцюнування. Для реалiзацil ПЗ обрано ^ент-серверну архкектуру. Побудовано ИМЬ дiаграми дшльностей для шентсько! та серверно! частин ПЗ, описано принципи !х взаемодн та представлено блок-схеми алгоритмов !х роботи. Розроблено та описано штерфейс користувача, для шентсько! частини ПЗ, обгрунтовано вибiр мови програ-мування для реалiзацil функцюналу системи.
Ключовi слова: робототехшчна система, програмне забезпечення, ИМЬ^аграма, клiент-серверна архiтектура.
Вступ. Автоматизащя проектування та розроблення робототехнiчних систем займае провiдне мiсце серед сучасних напрямш розвитку свiтовоí науки. А-дже дае змогу не тальки автоматизувати складнi технологiчнi процеси та опера-цií, але й замшити людину пiд час виконання важких i небезпечних робiт. Тому важливим завданням е процес проектування систем управлшня механiзмами, технiчного забезпечення, взаемодп цих складникiв, та розроблення спещ^зо-ваного програмного забезпечення. Адже вiд цього етапу напряму залежить фун-
1 acnip. К.В. Матвшчук - НУ "Льв1вська полггехнка";
2 проф. В.М. Теслюк, д-р техн. наук - НУ "Львгвська полггехнка";
3 асисг. А.Я. Зелшський, канд. техн. наук - НУ "Льв1вська полггехнка"
кцiонування та цшсшсть розроблювано1 системи. Використання техтчних за-соб1в, якi забезпечують збирання, реeсIрацiю, передачу, зберiгання, опрацюван-ня та тиражування iнформацií, а також процеси взаeмодií людини i комп'ютера для розв'язання задач управлiння РТС. Ан^з кнуючих систем керування показав ix велике рiзноманiття, залежно вiд виконуваних завдань та ступеня ix авто-матизацií. Такi системи можуть бути повнiстю керованi як людиною, так i прог-рамою, або ж в поеднанням цих способiв. Це РТС з адаптивною системою уп-равлiння, оснащенi сенсорною частиною, з iнтерактивним типом управлшня -беруть участь у дiалозi з людиною вiдносно вибору стратеги правлiння, системи з бютехшчним управлiнням, з iнтелектуальним управлiнням - засноваш на застосуваннi методов штучного штелекту, та автоматичнi - функщонують са-мостiйно [1-6].
Особливостi розроблення ПЗ пщсистеми керування РТС. На основi роз-роблених структурно! та функщонально! схем пiдсистеми вiддаленого управлшня РТС, для реалiзацií ПЗ було використано клкнт-серверну архитектуру [7, 8]. Ця архитектура сьогодт е домiнуючою концепцiею у створенш розподiлениx мережних застосункiв i передбачае взаемодда та обмiн даними мiж ними. Вона мiстить такi основш компоненти: набiр серверш, якi надають шформащю або опрацьовують данi, отримаш вiд клiентiв, якi звертаються до них; набiр клiентiв, якi використовують сервiси, що надаються серверами; мережа, яка за-безпечуе взаемодiю мiж клiентами та серверами.
Для воображения поставленого завдання використаемо дiаграму преце-дентiв. Суть nki дiаграми полягае в такому: проектована система видаеться у виглядi множини сутностей чи акторiв, що взаемоддать iз системою за допомо-гою т. зв. варiантiв використання. Варiант використання (use case) слугуе для опису сервiсiв, що система надае актору. Для розроблення ПЗ використано таку use case дiаграму (рис. 1).
Програмне забезпечення шдсистеми вiддаленого управлiния, вщповвдно до представлено! use-cases дiаграми, працюе за таким алгоритмом:
1. Серверна програма мае iнiцiалiзувати створення мережi та очiкувати шдклю-чення клкнпв.
2. Наступним кроком клieнт мае шдключитися до створено'1 мережi.
3. Пкля успiшного встановлення з'еднання i3 сервером клieнтська програма повинна вщклати серверу команди управлiння танком.
4. Сервер, своею чергою, шсля отримання команд iдентифiкуe !х i конфiгуруe управлiнське рiшення для однк'1 i3 плат управлiння танком. Розроблення дiаграми дiяльностi пiдсистеми керування РТС
Дiаграма дiяльностi в UML - вiзуальне представлення графу дяльностей [9]. Граф дiяльностей е рiзновидом графу сташв скiиченного автомату, вершинами якого е певш дií, а переходи ввдбуваються по завершенню дай.
Дiя е фундаментальною одиницею визначення поведiнки в спепифiкапií. Дiя отримуе множину вxiдниx сигналiв, та перетворюе ix на множину виxiдниx сигналiв. Кожна дiя в дiяльностi може виконуватись один, два, або бшьше разiв пiд час одного виконання дiяльностi. Спепифiкапiя дiяльностi може давати змо-гу виконати юлька потоюв операцш та застосовувати меxанiзми синхрошзацп
для гарантування виконання дiй у правильному порядку. Зокрема, дiаграму дь яльностi серверно! частини програми зображено на рис. 2, а дiаграму дiяльностi кментсько! частини програми - на рис. 3.
Рис. 1. Дiаграма прецедентiв программного забезпечення
Р1ШЕННЯ
Рис. 2. Дiаграма дiяльностi сервера
Рис. 3. Дiаграма дiяльностi ^ента
Дiаграма дiяльностi вщображае, якi дп повинен виконати киент i сервер у процеа функцiонування пiдсистеми. Як випливае iз рис. 2 i 3, сервер надтений бiльшою функцiональнiстю, що цшком закономiрно. Крiм отримання команд вщ клiента, вiн повинен перевiрити стан РТС (чи РТС перемщаеться i в якому станi знаходяться складники РТС). Визначення координат, для прикладу башти, потрiбне при використанш у програмi абсолютних чи вiдносних купв.
У розроблювальнш пiдсистемi клieнтом виступае клieнтський комп'ютер, телефон чи планшет. Вщповщно, сервером може виступати мжрокомп'ютер Raspberry Pi чи якийсь iнший [4, 8]. Загальноприйнятим е положения, що ктенти та сервери - це перш за все програмш модулi. Найчастше вони знахо-дяться на рiзних комп'ютерах, але бувають ситуацií, коли обидв програми - i ктентська, i серверна, фiзично розмiщуються на одшй машиш; у такiй ситуацц сервер часто називають локальним. У нашому випадку клiеитська програма розмщена на ПК, а серверна вщдалена - розмiщуеться на мiкрокомп'ютерi Raspberry Pi. Модель клент-серверно! взаемодл визначаеться насамперед роз-подалом обов'язюв мiж клiентом та сервером. Логiчно можна виокремити три рiвнi операцiй:
• piBeHb представление даних, який по суй е iнтерфейсом користувача i вщповь дае за представления даних користувачевi i введения вiд нього керуючих команд - ^ентська програма;
• прикладний рiвень, який реалiзуе основну логiку застосунку i на якому здiйснюеться необхiдне опрацювання iнформацií - серверна програма;
• рiвень управлiння даними, який забезпечуе збер^ання даних та доступ до них -серверна програма.
Дворiвнева клiент-серверна архтгектура передбачае взаемодiю двох прог-рамних модулiв - клiентського та серверного. Потрiбно зауважити, що не обов'язково ктентська i серверна програми мають бути розмiщенi в однiй i тiй самiй платформi.
Особливостi реамзаци спецiалiзованого ПЗ пiдсистеми управлiння РТС. Вiдповiдно до використано! структури ПЗ розроблено дю програми, якi розмщеш на рiзних платформах. Як внаслвдок, програма сервера створена на платформi Linux, а програма клiента - на XP, Windows 7, Windows 8. На цей час створюеться програма i для платформи Android (для використання планшепв, мобiльних телефошв).
Приклад блок-схеми алгоритму роботи сервера зображено на рис. 4. Пкля запуску РТС ввдбуваеться iнiцiалiзацiя шдсистем сервера для роботи в мереж! 3i сторони клiента надсилаеться команда створення з'еднання мiж РТС та оператором. Шсля встановлення з'еднання пiдсистема керування РТС отримуе ко-манди, пiсля iдентифiкацií яких, виконуе необхiднi користувачевi дií. Для напи-сання програми сервера доцiльно використати мову python, оскiльки тут дуже легко встановити i використовувати бiблiотеку для роботи iз портами RPI.GPIO та бiблiотеки для роботи в мережi [10].
Для використання згадано! вище бiблiотеки потрiбно використати таку команду import Rpi.GPIO as GPIO, а для використання порту UART (com порту) Raspberry треба використати бiблiотеку serial (import serial). Наприклад, для im-цiалiзацií порту, використаемо об'ект GPIO.setmode (GPIO.BOARD).
Для керування шнами Raspberry потрiбно використати набiр команд: GPIO.setup(f1, GPIO.OUT), GPIO.output(f1, True). За допомогою цих команд порт f1 iнiцiалiзуеться як вихвд, а остання команда вiдсилае на нього "лопчну одиницю".
Для встановлення з'еднання з клiентом використовують модуль
import socket s.bind((HOST, PORT)),
де: HOST - адреса Raspberry Pi; PORT - порт, для обмшу повщомленнями з киентом.
1дентифкащя команд
Процедура перемщення
Вщсилання даних на порт _ UART_L
Рис 4. Блок-схема функщонування програми сервера
У pa3i тдключення клiента (conn, addr = s.accept()), можна отримувати да-m з цього порту. data = conn.recv(1024) - отримання даних вщ клiентa. При от-риманш команд вiд клiентa, якi не вщповщають за пеpемiщення РТС, то сервер-на програма iдентифiкуе ix як тaкi, що потpiбно виставити на порт UART, по якому вони вщсилаються до плат управлшня баштою, зброею чи свiтлом. Це можна зробити командою ser.write (str).
При отриманш команд перемщення робототехшчно'' системи використо-вують процедури, як вiдповiдaють за iнiцiaлiзaцiю, вiдповiдно, порту GPIO. А якщо команди не вщповщають за пеpемiщення РТС, то в пpогpaмi передбачено цикл, який приймае дат та формуе з них керуючу стpiчку для UART. Цей цикл представлено нижче.
mas=[,frw,,,bck,,,lft,,,rgt,,,flt,,,blt,,,frt,,,brt,,,stp,,,ext']
elif not data in mas: new=int (data) data=chr (new) i=i+1 str=str+data if i==6: print (new, str)
print ("Send to Uart") print (str) ser.write (str) i=0 str=''
Пiсля прийому команди перетворюемо ii у цiлий тип (отримали CTpi4Ky) i отримуемо по числу символ. Потpiбно вiдсилати символи, щоб на пpоцесоpi виставити число у шютнадцятковш системi числення.
Пiсля виконання циклу на UART порт сервер виставить стpiчкy з шести символiв "5\x04\x01\x05\x03\x00\r", яка вiдповiдае 'E7 04 01 05 03 00 D' (вико-ристання спуску 1 при включеному денному свiтлi РТС). Програма сервера за-вантажуеться одразу пiсля завантаження мiкpокомп,ютеpа Raspberry Pi i вико-нуеться доти, поки включений мшрокомп'ютер з можливiстю тдключення/вщ-ключення киентш.
Особливостi реалiзацil к^ентсько'1 частини ПЗ. Блок-схему алгоритму роботи програми киента зображено на рис. 5.
(Кшець)
Рис 5. Блок-схема роботи wiieHmcbKoi частини ПЗ
На основi алгоритму створено програму, задавши 1й зручний iнтеpфейс для користувача (рис. 6) 1нтерфейс програми подiлено на частини: Управлшня платформою танка. Упpавлiння баштою РТС.
Використання збро! та налаштування napaMeTpiB свiтла (через меню программ).
В рядку стану программ вiдобpажаeться стан поточно! команди, який змь нюеться при натиснент будь-яко! кнопки.
Рис. 6.1нтерфейс програми клкнта
При запуску програми, координати башти зчитуються з файтв, а при вихо-дi з програми координати перезаписуються у B^^Bi,^ файли. Таким чином ми збертаемо координати башти при виключент програми. Потреба в координатах з'являеться тодi, коли потpiбно задати кут повороту башти.
Упpавлiння баштою представлено також двома ваpiантами: ручним i уп-pавлiнням по координатах. Ручне упpавлiння баштою вiдбуваeться аналопчно до упpавлiння РТС з використанням клавiатуpи. При упpавлiннi баштою по координатах у вщповщних полях потpiбно ввести кут повороту i натиснути нап-рям повороту башти.
Функцiю упpавлiння РТС було реатзовано двома способами: за допомо-гою використання клавiш упpавлiння курсором (стpiлки Up, Down, Left i Right), або ж використовуючи кнопки злiва внизу вiкна програми. 1нтерфейс програми для упpавлiння баштою також складаеться iз панелi з кнопками, коpистувачевi пропонуеться здiйснювати поворот башти вручну, аналогiчно упpавлiнню пере-мiщення з використанням клавiатуpи.
На цей час представлена можливкть перегляду вщео з камер та вщео реестратора тiльки за допомогою браузера Internet Explorer. У ньому достатньо прописати адресу 192.168.1.100 i вщео буде вщображатися в даному браузер! Як ваpiант, можна використати програму перегляду вiдео з вiдео реестратора.
У розробленш nporpaMi також peani30BaH0 функцi'í роботи 3i свiтлом та спусковими мехашзмами (рис. 7. та
Q ПЩСИСТЕМА УПРАВ/11ННЯ РОБОТОМ* Параметри свгтла ) Ви кори ста ння спуска Вихщ
V Св1тло денне
V Прожектор денний J
Св1тло ьмчне Прожектор шчний
Рис. 7. Включения денного ceimna Рис. 8. Використання спускових Mexarn3Mie
Висновок. Для pеaлiзaцií моделi ПЗ використано кмент-серверну арх^ек-туру. Для кожно! i3 програмних частин розроблено блок-схеми алгорштшв. Роз-роблено iнтеpфейс киентсько! частини програми.
Розроблене програмне забезпечення е бaгaтофункцiонaльною пiдсистемою вiддaленого управлшня (упpaвлiння пеpемiщенням РТС, параметрами свила, обертанням башти та упpaвлiння використанням збро! та спускових мехaнiзмiв, вщеоспостереження). Також це програмне забезпечення володiе принципом мо-дульностi, в подальшому його функцiонaл можна розширити.
Лггература
1. Tsmots I.G. Hardware and software tools for motion control of mobile robotic system / I.G. Tsmots, V.M. Teslyuk, I. Vavruk // In Proc. of the 12-th International Conference on The Experience of Designing and Application of CAD Systems in Microelectronics, CADSM'2013, Lviv-Polyana, Ukraine, Feb. 19-23, 2013. - Pp. 368.
2. Барашв, Д.Н. Розроблення штелектуально! системи управлшня мобшьними роботами на 0CH0Bi стежачо'1 системи техшчного зору i нечико'1 логiки : автореф. дис. на здобуття наук. ступеня канд. техн. наук: спец. 12.06.08 "Менеджмент" / Д.Н. Барашв; [Ун-т "СТАНКИН"]. - М., 2008. - 222 с.
3. Афонин В. Л. Проектирование и компьютерное моделирование интеллектуальных технологических систем механической обработки / В.Л. Афонин, Т.Н. Зайченко // Доклады Томского государственного ун-та систем управления и радиоэлектроники. - 2011. - Вип. 2-3 (24). - С. 32-44.
4. Babiarz, Artur, et al. "Control System of Mobile Robot Group / Artur Babiarz, et al.// Innovative Control Systems for Tracked Vehicle Platforms. Springer International Publishing, 2014. -Pp. 3-18.
5. Цмоць 1.Г. Моделювання штелектуального управлшня рухом мобтьно'1 роботехшчно'1 системи / 1.Г. Цмоць, I.G. Ваврук, В.М. Теслюк // Науковий вiсник НЛТУ Укршни : зб. наук.-техн. праць. - Лымв : РВВ НЛТУ Украши. - 2013. - Вип. 23.15. - С. 290-300.
6. Юревич Е.И. Основы робототехники / Е.И. Юревич. - Изд. 2-ое, [перераб. и доп.]. -СПб. : Изд-во БВХ-Петербург, 2005. - 416 с.
7. Комарницький М.В. Матвшчук К.В., Теслюк В.М. Структурна та фiзична моделi для автоматизованого проектування тдсистеми ввддаленого управлiння мобшьною робототехнiчною системою / М.В. Комарницький, К.В. Матвшчук, В.М. Теслюк // Науковий вюник НЛТУ Укра'ши : зб. наук.-техн. праць. - Львiв : РВВ НЛТУ Укра1ни. - 2014. - Вип. 24.9. -С. 156-161.
8. Chapter 3: Architectural Patterns and Styles. [Electronic resource]. - Mode of access http://msdn.microsoft.com/en-us/library/ee658117.aspx
9. Software architecture of mobile robotic systems: A case study Capucha Lubomir, Rohal-Ilkiv Boris / 2016 Cybernetics & Informatics, Feb. 2016. - Pp. 1-5.
).
10. [Electronic resource]. - Mode of access http://openmicros.org/index.php/articles /94 -ciseco - product - documentation/raspberry - pi/217 - getting - started - with - raspberry - pi - gpio -and - python.
11. Denysyuk Pavlo. UML Models of Determining the Direction of Motion of Mobile Robotic System / Pavlo Denysyuk, Kateryna Matviichu, Andriy Medvid // Комп'ютерш науки та шформацшш технологи : матер. восьмо! Мiжнар. конф. CSIT'2013, 11-16 листоп. 2013, .Львш, Украша, Нац. ун-т "Львш. полггехшка". - Львш : Вид-во "Вежа i Ко", 2013. - С. 135-136.
Надтшла до редакцп 31.08.2016р.
Матвийчук Э.В., Теслюк В.Н., Зелинский А.Я. Программная модель подсистемы управления мобильной робототехнической системой
Описаны особенности разработки программного обеспечения подсистемы удаленного управления работотехнической системой (РТС). Построена UML диаграмма прецедентов, с помощью которой отражены основные задачи, которые будет выполнять РТС в процессе функционирования. Для реализации ПО выбрана клиент-серверная архитектура. Построены UML диаграммы деятельностей для клиентской и серверной частей ПО, описаны принципы их взаимодействия и представлены блок-схемы алгоритмов их работы. Разработан и описан интерфейс, для клиентской части ПО, обоснован выбор языка программирования для реализации функционала системы.
Ключевые слова: работотехническая система, программное обеспечение, UML диаграмма, клиент-серверная архитектура.
Matviichuk K. V., Teslyuk V.M., Zelinskyy A. Ya. Programming Model of Control Subsystem for Mobile Robotic Technical System
The article describes the features of the development of software for the subsystem of the remote control of robotic technical system (RTS). Use case UML diagram that reflects the main tasks that perform the RTS in the operation process was constructed. To implement the software, client-server architecture was chosen. UML activity diagrams for client and server parts of the software were built, the principles of their cooperation were described and flowcharts of algorithms of their work were presented. The user interface for the client part of software was developed and described; the choice of programming language for implementation of a functional system was proved.
Keywords: robotic technical system, software, UML-diagram, client-server architecture.
УДК 697.1:699.865
WPtYW SPOSOBU ZASILANIA BUDYNKU W ENERGI^ NA WSKAZNIK ROCZNEGO ZAPOTRZEBOWANIA NA NIEODNAWIALN4 ENERGI^ PIERWOTN^
Myroslav Malovanyy1, Anna Zyczynska2, Grzegorz Dys3
Omówiono wplyw wykorzystania odnawialnych zródel energii na wartosc wskaznika rocznego zapotrzebowania na energi^ koñcow^ i nieodnawialn^ energi^ pierwotn^ na przykladzie budynków uzytecznosci publicznej. Przeanalizowano kilka wariantów rozwiqzañ, technicznie mozliwych do realizacji, wykorzystuj ^cych nieodnawialne i odnawialne zródla energii dla zasilania budynków w energi^ na cele ogrzewania, przygotowania cieplej wody i oswietlenie. Przedstawiono struktur^ zapotrzebowania na energi^ na poszczególne cele oraz relacje pomi^dzy wskaznikami zapotrzebowania na energi^ uzytkow^, koñcow^ i nieodnawialne pierwotn^. Uzyskane wyniki porównano do standardu energetycznego obowiqzuj^cego w
1 Kierownik Katedry EZWZN, Myroslav Malovanyy, dr.hab. - Politechnika Lwowska;
2 Prodziekan WBiA, Anna Zyczynska, dr inz. - Politechnika Lubelska;
3 Wlasciciel, Grzegorz Dys, mgr inz - Energetyczna Pracownia Inzynierska ERG S.C.
