Керування роботою маніпулятора через веб-інтерфейс

ВСТУП

Людство завжди мріяло про створення автоматичних керованих машин, які будуть виконувати різноманітну роботу. З часом почали з’являтися перші технічні пристрої, які могли виконувати важку та брудну роботу замість людини. Згодом з’явилися і перші справжні роботи, про яких колись писали фантасти.

Зараз робототехніка розвивається великими темпами, тому можна спрогнозувати майже повну автоматизацію виробництва у недалекому майбутньому. Японська фірма Fanuc минулого року випустила 250 тисяч роботів, а Швейцарська ABB Robotics - 190 тисяч. Цього року тайванська компанія Hon Hai Precision Industry уже заявила про початок масового виробництва високотехнологічних роботів, їх буде набагато більше, ніж у Японії та Швейцарії разом - 1 мільйон.

Актуальність теми

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

Мета роботи:

Спроектувати, розробити та реалізувати проект маніпулятора.

Для проектування використовувалися програмні продукти AVR Studio, Proteus 7.4. Для реалізації використовувалися мови програмування C, Assembler, PHP.

Дипломна робота складається із вступу, трьох розділів та висновків.

У першому розділі наведені загальні відомості про робототехніку в світі та в Україні;

У другому розділі наведені відомості про програмні та апаратні засоби, які були використані для створення прототипа;

У третьому розділі наведено опис процесу розробки маніпулятора і системи керування. У висновках підсумовано основні результати дослідження.

РОЗДІЛ 1. АНАЛІЗ РОБОТИЗОВАНИХ МАНІПУЛЯТОРІВ ТА СИСТЕМ КЕРУВАННЯ

 

.1 Дещо про робототехніку

Робототехніка (від робот і техніка; англ. Robotics) - прикладна наука, що займається розробкою автоматизованих технічних систем (роботів). Термін введений письменником-фантастом Айзеком Азімовим в 1942 році (слово робот з'явилося раніше, в п'єсі Карела Чапека «RUR», 1920).

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

 

.1.1 Компоненти роботів

Приводи - це «м'язи» роботів, вони перетворюють потенційну енергію в рух. В даний час найпопулярнішими приводами є електродвигуни, але існують і багато інших, деякі з них працюють від електрики, в той час як інші використовують хімічні речовини або стиснене повітря.

Двигуни: На даний момент більшість роботів використовують електродвигуни, які бувають декількох видів. Двигуни постійного струму, знайомі багатьом людям, швидко обертаються, коли через них проходить електричний струм. Якщо струм пустити в іншому напрямку, двигуни будуть обертатися в зворотну сторону.

Крокові електродвигуни. Як можна припустити з назви, крокові електродвигуни не обертаються вільно, подібно двигунів постійного струму. Вони повертаються покроково на певний градус під управлінням контролера. Це дозволяє простіше ними керувати, так як контролеру точно відомо, на скільки було зроблено поворот, без застосування датчиків. З цієї причини вони використовуються на багатьох роботах і верстатах з ЧПУ.

П’єзодвигуни: Сучасною альтернативою двигунам постійного струму є п’єзодвигуни, також відомі як ультразвукові двигуни. Принцип їх роботи абсолютно відрізняється: крихітні п'єзоелектричні ніжки, вібруючі зі швидкістю більше 1000 разів на секунду, змушують мотор рухатися по колу або прямій. Перевагами подібних двигунів є високий нанометричний дозвіл, швидкість і потужність, несумірна з їх розмірами. П’єзодвигуни вже доступні на комерційній основі, а також застосовуються на деяких роботах.

Повітряні м'язи. Повітряні м'язи - простий, але потужний пристрій для забезпечення сили тяги. При накачуванні стисненим повітрям, м'язи здатні скорочуватися до 40% від своєї довжини. Причиною такої поведінки є плетіння, видиме з зовнішнього боку, яке змушує м'язи бути або довгими і тонкими, або короткими і товстими. Так як спосіб їх роботи схожий з біологічними м'язами, їх можна використовувати для виробництва роботів з м'язами і скелетом, аналогічними тваринам.

Електроактивні полімери. електроактивні полімери (ЕАП) - це сорт пластмас, який змінює форму у відповідь на електричну стимуляцію. Вони можуть бути сконструйовані таким чином, що можуть гнутися, розтягуватися або скорочуватися. Однак, в даний час немає ЕАП, придатних для виробництва комерційних роботів, так як всі вони неефективні або неміцні.

Еластичні нанотрубки. Це багатообіцяюча експериментальна технологія, яка перебуває на ранній стадії розробки. Відсутність дефектів в нанотрубках дозволяє цьому волокну еластично деформуватися на кілька відсотків. Людський біцепс може бути замінений проводом з такого матеріалу діаметром 8 мм. Такі компактні «м'язи» можуть допомогти роботам в майбутньому обганяти і перестрибувати людей.

Розрізняють одномодальні і багатомодальні інтерфейси взаємодії. При реалізації взаємодії сучасних роботів з людиною велике значення мають технології розпізнавання образів і мови.

1.1.2 Системи управління

За типом управління роботехнічні системи поділяються на:

Біотехнічні:

·    командні (кнопкове і важелеве управління окремими ланками робота);

·        копіюючі (повтор рухи людини, можлива реалізація зворотного зв'язку, що передає додаткове зусилля, екзоскелети);

·        напівавтоматичні (управління одним командним органом, наприклад, рукояткою всією кінематичною схемою робота);

Автоматичні:

·    програмні (функціонують за заздалегідь заданою програмою, в основному призначені для вирішення одноманітних завдань в незмінних умовах оточення);

·        адаптивні (вирішують типові завдання, але адаптуються під умови функціонування);

·        інтелектуальні (найбільш розвинені автоматичні системи);

Інтерактивні:

·    автоматизовані (можливо чергування автоматичних і біотехнічних режимів);

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

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

У розвитку методів управління роботами величезне значення має розвиток технічної кібернетики та теорії автоматичного управління.

 

1.1.3 Динаміка і кінематика. Освіта

Роботи широко застосовуються в теорії автоматичного управління та мехатроніки. Робототехнічні комплекси також популярні в галузі освіти як сучасні високотехнологічні дослідні інструменти. Їх використання в різні навчальних закладах середньої та вищої професійної освіти дозволяє реалізовувати концепцію "навчання на проектах", покладену в основу такої великої спільної освітньої програми США і Європейського союзу, як ILERT. Застосування можливостей робототехнічних комплексів в інженерній освіті дає можливість одночасного відпрацювання професійних навичок відразу по декількох суміжних дисциплінах: механіка, теорія управління, схемотехніка, програмування, теорія інформації. Затребуваність комплексних знань сприяє розвитку зв'язків між дослідними колективами. Крім того студенти вже в процесі профільної підготовки стикаються з необхідністю вирішувати реальні практичні завдання. Існують робототехнічні комплекси для навчальних лабораторій: Mechatronics Control Kit, Festo Didactic, LEGO Mindstorms.

1.2 Роботи

Робот (від чеськ. Robota) - автоматичний пристрій з антропоморфною дією, яка частково або повністю замінює людини при виконанні робіт у небезпечних для життя умовах або при відносній неприступності об'єкта. Робот може управлятися оператором або працювати по заздалегідь складеній програмі. Використання роботів дозволяє полегшити або зовсім замінити людську працю на виробництві, в будівництві, при роботі з важкими вантажами, шкідливими матеріалами, а також в інших важких або небезпечних для людини умовах.

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

Промислові роботи є важливими компонентами автоматизованих гнучких виробничих систем (ГВС), які дозволяють збільшити продуктивність праці.

 

.2.1 Побутові роботи

Одним з перших прикладів вдалої масової промислової реалізації побутових роботів стала механічна собачка AIBO корпорації Sony.

У вересні 2005 у вільний продаж вперше поступили перші людиноподібні роботи «Вакамару» виробництва фірми Mitsubishi. Робот вартістю $ 15 тис. здатний дізнаватися особи, розуміти деякі фрази, давати довідки, виконувати деякі секретарські функції, стежити за приміщенням.

Все більшу популярність набирають роботи-прибиральники, за своєю суттю - автоматичні пилососи, здатні самостійно прибрати в квартирі і повернутися на місце для підзарядки без участі людини.

Винахідник Піт Редмонд (Pete Redmond) створив робота RuBot II, який може зібрати кубик Рубіка за 35 секунд.

Існує також напрямок моделізму, що має на увазі створення роботів. Зараз моделісти роблять як радіокерованих роботів, так і автономних. Проводяться змагання за кількома основними напрямками. Серед змагань автономних роботів варто згадати біг на швидкість по білої лінії, боротьбу сумо, робо-футбол.

Виробники роботів

Відомі комерційні моделі роботів

·            Aibo

·  ASIMO

·        I-SOBOT

·        REEM-B

·        SCORBOT-ER 4u

·        STAIR

·        Twendy-One

·        Wakamaru

 

.2.2 Промислові Роботи

Історія

Поява верстатів з числовим програмним керуванням (ЧПК) призвело до створення програмованих маніпуляторів для різноманітних операцій із завантаження та розвантаження верстатів. У 1954 році американський інженер Д. Девол запатентував спосіб управління вантажно-розвантажувальних маніпулятором за допомогою змінних перфокарт. Разом з Д. Енгельберга в 1956 р. він організував першу в світі компанію по випуску промислових роботів. Її назва «Unimation» (Юнімейшн) є скороченням терміну «Universal Automation» (універсальна автоматика).

У 1962 році в США були створені перші промислові роботи «Юнімейт» і «Версатран». Їх схожість з людиною обмежувалося наявністю маніпулятора, який віддалено нагадує людську руку. Деякі з них працюють до цих пір, перевищивши 100 тисяч годин робочого ресурсу.

«Юнімейт» мав 5 ступенів рухливості з гідроприводом і двухпальцевое захватне пристрій з пневмоприводом. Переміщення об'єктів масою до 12 кг здійснювалося з точністю 1,25 мм. В якості системи управління використовувався программоносітель у вигляді кулачкового барабана з кроковим двигуном, розрахований на 200 команд управління, і кодові датчики положення. У режимі навчання оператор ставив послідовність точок, через які повинні пройти ланки маніпулятора протягом робочого циклу. Робот запам'ятовував координати точок і міг автоматично переміщатися від однієї точки до іншої в заданій послідовності, багато разів повторюючи робочий цикл. На операції розвантаження машини для лиття під тиском «Юнімейт» працював з продуктивністю 135 деталей за годину при шлюбі 2%, тоді як продуктивність ручної розвантаження становила 108 деталей за годину при шлюбі до 20%.

Робот «Версатран», який мав три ступені рухливості та керування від магнітної стрічки, міг у обпалювальне печі завантажувати і розвантажувати до 1200 розпечених цегли на годину. У той час співвідношення витрат на електроніку і механіку у вартості робота становило 75% і 25%, тому багато завдань управління вирішувалися за рахунок механіки. Зараз це співвідношення змінилося на протилежне, причому вартість електроніки продовжує знижуватися. Пропонуються незвичайні кінематичні схеми маніпуляторів. швидко розвиваються технологічні роботи, які виконують такі операції як високошвидкісні різання, забарвлення, зварювання. Поява в 70-х рр.. мікропроцесорних систем управління і заміна спеціалізованих пристроїв управління на програмовані контролери дозволили знизити вартість роботів в три рази, зробивши рентабельним їх масове впровадження у промисловості. Цьому сприяли об'єктивні передумови розвитку промислового виробництва.

Функціональна схема промислового робота

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

 

.2.3 Маніпулятори

Маніпулятор - це механізм для управління просторовим положенням знарядь і об'єктів праці.

Маніпулятори включають рухомі ланки двох типів:

·    Ланки, що забезпечують поступальну ходу

·        Ланки, що забезпечують кутові переміщення

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

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

Частиною маніпуляторів (хоч і необов'язковою) є захватні пристрої. Найбільш універсальні захватні пристрої аналогічні руці людини - захоплення здійснюється за допомогою механічних «пальців». Для захоплення плоских предметів використовуються захватні пристрої з пневматичним присоском. Для захоплення ж безлічі однотипних деталей (що зазвичай і відбувається при застосуванні роботів в промисловості) застосовують спеціалізовані конструкції.

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

1.2.4 Система пересування

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

Для переміщення по похилих, вертикальних площинах використовуються системи аналогічні «крокуючим» конструкціям, але з пневматичними присосками.

 

.2.5 Управління

Управління буває декількох типів:

. Програмне управління - найпростіший тип системи керування, використовується для управління маніпуляторами на промислових об'єктах. У таких роботах відсутня сенсорна частина, всі дії жорстко фіксовані і регулярно повторюються. Для програмування таких роботів можуть застосовуватися середовища програмування типу VxWorks / Eclipse або мови програмування наприклад Forth, Оберон, Компонентний Паскаль, Сі. В якості апаратного забезпечення зазвичай використовуються промислові комп'ютери в мобільному виконанні PC/104 рідше MicroPC. Може відбуватися за допомогою ПК або програмованого логічного контролера.

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

. Засноване на методах штучного інтелекту.

. Управління людиною (наприклад, дистанційне керування).

Принципи управління

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

Підлегле управління

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

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

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

 

.2.6 Дії промислового робота

Серед найпоширеніших дій, скоєних промисловими роботами можна назвати наступні:

·    · Переміщення деталей і заготовок від верстата до верстата або від верстата до систем змінних палет;

·        Зварка швів і точкова зварка;

·        Фарбування;

·        Виконання операцій різання з рухом інструменту по складній траєкторії.

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

Переваги використання:

·    Досить швидка окупність

·        Виключення впливу людського фактору на конвеєрних виробництвах, а також при проведенні монотонних робіт, що вимагають високої точності;

·        Підвищення точності виконання технологічних операцій і, як наслідок, поліпшення якості;

·        Можливість використання технологічного обладнання в три зміни, 365 днів на рік;

·        Раціональність використання виробничих приміщень;

·        Виключення впливу шкідливих чинників на персонал на виробництвах з підвищеною небезпекою;

 

.3 РОБОТ CKBOT

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

На виставці Wired NextFest 2008, що пройшла в кінці вересня - початку жовтня в Чикаго, був показаний забавний робот ckBot, якого можна було б прийняти за художній проект з технічним ухилом. Але він-частина серйозної роботи, чиї плоди одного дня можуть стати в нагоді відразу в декількох прикладних областях.

Цікаво, що всі три частини робота ідентичні (кожна побудована з п'яти блоків, що володіють моторизованим зчленуванням, що допускає поворот деталей на 180 градусів). Це не заважає їм у потрібний момент визначитися, які з них стануть ногами, а яка - тулубом.

Американські інженери назвали це вміння "Самозбірка після вибуху" (Self-reassembly After Explosion), втім, уточнюючи, що "вибух" - це просто якесь сильне вплив, не важливо, який природи.

Побудував цю машину Марк Йім (Mark Yim), ад'юнкт-професор інженерії в університеті Пенсільванії (University of Pennsylvania) і його колеги з лабораторії модульних роботів (Modular Robotics Lab).

Як ви вже, напевно, здогадалися, кожен модуль ckBot володіє своїми "мізками", батарейкою, електромоторчіком і системами зв'язку.

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

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

Що може при цьому робота "розкидати" - не цілком зрозуміло. Та й неважливо. Головне - розсипавшись, бот може повернути собі первісний вигляд. Щоправда, в нинішньому варіанті дроїда зарано випускати на справжнє поле бою, нехай спершу наб'є шишок (дивіться відео до кінця).

Логічно запитати: "Навіщо такі складнощі?" Справа в тому, що, за загальним задумом проекту, ckBot і йому подібні машини повинні збиратися з куди більшої кількості модулів. При цьому фігура, яку вони утворюють, залежить тільки від обраної програми, а таких всередині модулів може бути запасено чимало. Хочете - отримаєте "змію", бажаєте - "кішку" або "собаку".

Пам'ятайте змійку Рубіка (Rubik's Snake)? Той же принцип, тільки все крутиться само. Так що новий бот міг би стати класною іграшкою. Але Марк бачить для нього інше поле діяльності.

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

Так, ланцюжок блоків ckBot може замкнутися і, змінюючи форму вийшло обода, котитися зі швидкістю до 1,6 метра в секунду. Це найшвидший спосіб пересування для ckBot, встановили американські дослідники.

СkBot нагадав нам про цілу низку його ідеологічних попередників. Згадаймо, наприклад, робота з університету Корнелла (Cornell University).

Цей апарат міг не просто збиратися з абсолютно ідентичних шматочків, але і будувати свої копії. Правда, бот той стояв на місці, а чергові детальки для збірки його побратима йому треба було класти в строго певне місце. Виходить, що група під керівництвом Йіма зуміла "звільнити" такого самосборщіка, надавши йому і його блокам не тільки здатність до переміщення, а й уміння знаходити один одного. Залишилося тільки навчитися робити такі блоки все більш "розумними" і потужними, і вперед - відпускайте фантазію на волю.

 

.4 Роботи Аquajelly і Аirjelly

Природа не втомлюється дивувати нас красою своїх «технологічних» рішень - а ми не втомлюємося дивуватися. Не дивно, що вона раз у раз надихає дизайнерів та інженерів на те, щоб, по можливості, не винаходити все з нуля, а скористатися її дарами. Так вчинили і розробники «роботів-медуз», що підкорюють воду і повітря з фантастичною красою і грацією.

Таким шляхом пішли і розробники компанії Festo, творці найцікавіших роботів - AquaJelly і AirJelly, що звернули свою увагу на найдавніших представників фауни, медуз. Зрозуміло, до цього включені найсучасніші технології, доступні людству., по суті, являє собою штучну медузу, яку приводить у рух електромотор і адаптивна механічна система. Вона складається з напівпрозорої півсфери і восьми щупалець, а центр її займає водонепроникна ємність, в якій укритий і двигун, і пара Li-Ion батарей, і сервоприводи.

За структурою своєї кожне щупальце повторює анатомію риб'ячих плавників: воно «колишеться» під впливом перистальтичних сил в заповнюють її «судинах», і здійснює хвилеподібні рухи. Рух ж самої AquaJelly в тривимірному просторі забезпечує контрольоване переміщення центру її тяжкості. «Медуза» самостійно стежити за станом своїх акумуляторів і підтримує зв'язок із зарядним пристроєм, при необхідності підзаряджаючи.

Зв'язок підтримується і з іншими AquaJelly в межах доступності. Перебуваючи на поверхні води, робот використовує для комунікації економну радіозв'язок - але основний спосіб зв'язку під водою - це світло. Одинадцять інфрачервоних випромінювачів дозволяють «медузам» взаємодіяти на відстанях до 0,8 м. Це, звичайно, не дуже далеко, але все ж не дозволяє медузам стикатися один з одним.

У «доважок» на сенсори, що відстежує стан навколишнього водного середовища, AquaJelly несе набір датчиків, що стежать за її внутрішнім станом, а чутливий манометр дозволяє роботу «усвідомлювати» глибину свого занурення з точністю до декількох міліметрів.

Але ще більш цікава інша розробка інженерів з Festo - «повітряна медуза» AirJelly. Якщо AquaJelly відчуває себе у воді, як риба, то AirJelly підкорює повітряне середовище, використовуючи схожі схеми. Звичайно, для цілей польоту цей робот використовує свій особливий «бульбашка», який заповнюється легким гелієм. В іншому він влаштований приблизно так само - хоча, на наш погляд, вражає ще більше свого водного побратима.

 

.5 Робот Тetwalker

- це піраміда з шести стержнів, з'єднаних вузлами.
У кожному вузлі знаходиться електроніка і електродвигуни, здатні в широких межах змінювати довжину стрижнів.

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

Тут же слід перекидання на бік. Але оскільки всі сторони машини абсолютно рівнозначні - ніякого "падіння" немає - так робот і рухається.

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

Навіть якщо він скотиться в кратер, то спокійно продовжить роботу. А якщо стінки не надто круті - зможе і піднятися нагору. Чи треба говорити, що звичайний марсохід (з колесами), якщо перевернеться на камені, то тут же і закінчує своє "виступ".

Проте, вважають творці TETwalker, куди цікавіше буде, коли нанотехнології та мікромеханіка дозволять зменшити розміри такого тетраедра в десятки, а може і в сотні разів.

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

І якщо кожен вузол такого робота доповнити стикувальним механізмом міріади подібних машин зможуть формувати ту саму "живу амебу", який міняє форму в залежності від умов, а також загоює пробоїни.

Вона ж зможе автоматично збиратися в радіотелескоп або круглий планетоход типу "перекотиполе".

Мініатюрні і порівняно прості процесори таких модулів зможуть об'єднуватися в єдиний комп'ютер, можливо, схожий на нейронну мережу. "Ми не жили б довго, якщо б наші тіла працювали, як сучасні космічні кораблі, - розповів глава проекту доктор Стівен Кертіс (Steven Curtis). - Коли у нас виникає травма, нові клітини замінюють пошкоджені. Подібним чином неушкоджені одиниці рою об'єднаються, продовжуючи виконання місії, незважаючи на значне пошкодження ".

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

Як би там не було, нинішній трикутний робот - наочний приклад, як може працювати одна клітина такого робота-рою.

Він не тільки ходив (якщо можна застосувати до нього таке слово) за статтю лабораторії в центрі Годдарда, але вже встиг побувати на випробуваннях в Антарктиді.

У січні 2005 року машина виявилася на науковій станції Макмердо (McMurdo), де умови багато в чому нагадують Марс.

Тест показав, що деякі зміни поліпшать роботу робота. Наприклад, розміщення двигунів в середині розпірок, а не у вузлах, спростить конструкцію вузлів і збільшить їхню надійність.

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

Також в рамках даного проекту фахівці розвивають нове програмне забезпечення, що дозволяє трикутниках збиратися в "розумні" (до деякої міри) машини.

1.6 Маніпулятор

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

 

.6.1 Основні поняття і визначення. Структура маніпуляторів

Формула будови - математична запис структурної схеми маніпулятора, що містить інформацію про кількість його подвижностей, вигляді кінематичних пар і їх орієнтації щодо осей базової системи координат (системи, пов'язаної з нерухомим ланкою).

Рухи, які забезпечуються маніпулятором, діляться на:

·  глобальні (для роботів з рухомою основою) - руху стійки маніпулятора, які суттєво перевищують розміри механізму;

·        регіональні (транспортні) - руху, що забезпечуються першими трьома ланками маніпулятора або його "рукою", величина яких порівнянна з розмірами механізму;

·        локальні (орієнтують) - руху, що забезпечуються ланками маніпулятора, які утворюють його "кисть", величина яких значно менше розмірів механізму.

Відповідно до цієї класифікації рухів, в маніпуляторі можна виділити дві ділянки кінематичного ланцюга з різними функціями: механізм руки і механізм кисті. Під "рукою" розуміють ту частину маніпулятора, яка забезпечує переміщення центру захоплення - точки М (регіональні руху захоплення); під "кистю" - ті ланки і пари, які забезпечують орієнтацію захоплення (локальні руху захвату).

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

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

Задачі механіки маніпуляторів.

До основних завдань механіки маніпуляторів можна віднести:

·    розробку методів синтезу та аналізу виконавчих механізмів (включаючи механізми приводів);

·        програмування руху маніпулятора;

·        розрахунок керуючих зусиль і реакцій в КП;

·        урівноваження механізмів маніпуляторів;

·        інші завдання.

Ці завдання вирішуються на базі загальних методів дослідження структури, геометрії, кінематики та динаміки систем з просторовими многоподвіжнимі механізмами. Кожна з розглянутих завдань може бути сформульована як пряма (задача аналізу) або як зворотна (задача синтезу). При визначенні функцій положення механізму, у прямій задачі знаходять закон зміни абсолютних координат вихідної ланки за заданими законами зміни відносних або абсолютних координат ланок. У зворотному - по заданому закону руху схвата знаходять закони зміни координат ланок, зазвичай, лінійних або кутових переміщень у приводах. Рішення оберненої задачі або задачі синтезу більш складно, так як часто вона має безліч допустимих рішень, з яких необхідно вибрати оптимальне. У зворотній задачі кінематики за необхідним законом зміни швидкостей і прискорень вихідної ланки визначаються відповідні закони зміни швидкостей і прискорень в приводах маніпулятора. Зворотній завдання динаміки полягає у визначенні закону зміни керуючих сил і моментів у приводах, що забезпечують заданий закон руху вихідної ланки.

 

.6.2 Класифікація маніпуляторів

Класифікуються маніпулятори за такими признаками:

По характеру виконуючих робіт:

а) універсальні;

б) спеціальні.

. По способу керування:

а) з ручним (копіруючі);

б) з автоматичним управлінням (по програмі ЕОМ).

Універсальні М. застосовуються для виконання підйомно-транспортних робіт в машинобудуванні, а також для механізації операцій по обслуговуванні технологічного обладнання (установки і знімання деталей на металорізальних верстатах, зварочні і свердлильні операції).

Спеціальні М. застосовуються:

в ковальсько-пресових цехах;

в ливарному виробництві.

 

.6.3 Автооператори

АО - це маніпулятор, який застосовується в машинах-автоматах, які працюють по жорсткій програмі і оперують штучними об'єктами по загальному циклу машини.

Програмоносіями для АО служать кулачки, перфострічки, магнітні стрічки.

Області застосування АО :

·    Автооператор заливщик для машин литва під тиском .

·        Автооператор для змазки прес-форм машин литва під тиском .

·        Автооператор для обслуговування листоштамповочних пресів .

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

1.7 Захватні пристрої

 

.7.1 Класифікація захватних пристроїв

Захватні пристрої (ЗП) маніпуляторів служать для захвату і утримання в певному (конкретному) положенні об'єктів маніпулювання. Ці об'єкти можуть мати різні розміри, форму, масу і характеризуватися різними фізичними властивостями.

Прикладами ЗП являються: монтажні інструменти (тиски, ключі і ін.)

До ЗП ставляться певні вимоги: загального характеру і спеціальні, зв'язані з конкретними умовами праці.

До числа обов'язкових вимог відносяться : надійність захвату і утримання об'єкту, стабільність базування, недопустимість пошкоджень або руйнування об'єктів, міцність деталей ЗП.

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

В теперішній час ведуться розробки конструкцій ЗП, які можуть захвачувати і базувати неорієнтовано розміщені об'єкти.

Класифікація ЗП ведеться по ряду признаків:

По способу захвату і утримання об'єкта маніпулювання - механічні, пневматичні (вакуумні), електромагнітні і комбіновані.

По виду управління (керування) - некеровані, командні, жостко-програмні, адаптивні (чуттєві).

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

По числу робочих позицій: однопозиційні, багатопозиційні.

По характеру кріплення: незмінні, змінні, швидкозмінні, автоматизовані. По робочому діапазону - широкодіапазонні - можуть удержувати об'єкти в широкому діапазоні розмірів поверхонь захвату ; вузькодіапазонні - можуть удержувати об'єкти в обмеженому діапазоні розмірів поверхонь захвату.

1.7.2 Будова захватних пристроїв і принцип дії

Механічні ЗП некеровані. Виконуються у вигляді пінцетів, розрізних пружніх валиків і втулок (цанг) або тисків з одною або двома рухомими губками, які знаходяться під дією пружин.

Рис.1.1 Механічні ЗП

Розжим робочих елементів таких ЗП проходить при контакті з заготовкою, внаслідок чого можуть бути пошкоджені поверхні деталей або зажимних елементів (недолік). Ці ЗП застосовують в умовах масового виробництва при маніпулюванні з об'єктами невеликих мас і габаритів.

Непривідні ЗП із стопорними механізмами забезпечують чергування циклів зажиму і розжиму деталей, не потребують спеціальних команд від системи керування і додаткової енергії. Деталі утримуються силою пружин внаслідок ефекту самозатягування. Як правило, робота таких ЗП можлива тільки при їх вертикальному положенні.

Командні ЗП. Широко розповсюджені конструкції тискового типу (обценьки). Рух губок забезпечується пневмо-, гідро-, або електроприводом.

Рис.1.2 ЗП з важільними передаточним механізмом і пневмо-гідро приводом

Рис.1.3 Центруючі ЗП з рейковим передаточним механізмом

Рис.1.4 ЗП з розширяючими еластичними камерами

Застосування таких пристроїв обумовлено кригкістю матерії і складною конфігурацією поверхонь багатьох деталей.

Рис. 1.5 Вакуумні, з згинаючими еластичними камерами і електромагнітні ЗП

користувацький архітектура маніпулятор інтерфейс

Рис.1.6 Адаптивні захватні пристрої: а-трьохпалі з активним тросовим механізмом привода ланок; б-адаптивний; в-з тактильним щупом

 

.8 Класифікація приводів

. В залежності від виду енергії, яка використовується для руху робочого механізму привода: пневматичні, гідравлічні, електромеханічні і комбіновані.

. По способу відліку координат:

з відносним відліком координат - по приростам (кроковий двигун);

з абсолютним відліком координат (електропривод з зворотнім зв'язком) .

В склад приводу входять підсилювачі потужності, електродвигуни, передаточні механізми, датчики зворотного зв'язку.

Застосовуються електродвигуни загального призначення (асинхронні, постійного струму), а також спеціальні - крокові. Кроковий двигун має дві модифікації: поворотний, лінійний.

Електричні приводи класифікуються:

По роду передаточного пристрою: редукторні; безредукторні.

По степені управління: регулюючий; програмно-керуючий; слідкуючий; адаптивний.

По рівню автоматизації: автоматизований (оператор); автоматичний (без оператора).

Схема автоматизованого електромеханічного приводу:

системакроковий редуктор виконавчий керування двигун механізм

 

.8.1 Гідропривід

Широке запровадження гідропривода в робототехніці визвано такими його перевагами:

·  Швидкодія.

·        Можливість безступінчастого регулювання швидкості вихідної ланки в автоматичному режимі.

·        Великий коефіцієнт підсилення по потужності (великі сили може передавати гідропривід).

·        Простота конструкції, висока надійність.

Недоліки:

·  Можливість витоку робочої рідини через ущільнення приводу.

·        Необхідність застосування пристроїв для охолодження (підігріву) робочої рідини.

В гідропривіді застосовуються такі основні типи гідродвигунів:

·  Лінійні гідроциліндри;

·        Поворотні гідродвигуни (гідромотори).

 

.8.2 Пневмопривод

Одержав широке застосування в конструкціях ПР вантажопідйомністю до 20 кг. Це зумовлено такими перевагами:

·  Простота і надійність конструкції.

·        Висока швидкість вихідної ланки.

·        Можливість використання енергії стиснутого повітря із заводської системи (повітряної магістралі).

·        Можливість використання в агресивних і пожежонебезпечних середовищах.

·        Високий ККД.

·        Невисока вартість конструкції і малі витрати на обслуговування .

Недоліки:

·  Необхідність застосування спеціальних конструкцій позиційних пристроїв.

·        Низька питома потужність (висока ступінь стиску повітря).

·        Шум при роботі.

В склад пневмоприводу входять:

·  Циліндри пневматичні типу ЦРГП.

·        Поворотні пневмодвигуни типу ПДП.

·        Цифрові багатопозиційні лінійні пневмоприводи.

·        Цифрові багатосекційні ротаційні пневмоприводи.

 

.8.3 Комбіновані приводи

·  Електрогідравлічний привод:

·        Привід позиційного типу;

·        Кроковий привод.

 

.9 Системи керування ПР та інформаційні системи

 

.9.1 Класифікація СК ПР

Системи керування класифікують за такими признаками:

. По способу позиціювання:

·  позиційні (малоточкові, багатоточкові);

·        контурні;

·        комбіновані

2. По виду енергоносія:

·  механічні;

·        гідропневматичні;

·        електричні.

3. По способу представлення (подання) інформації:

·  електромеханічні;

·        числові;

·        гібридні

·        циклові;

·        аналогові;

4. По типу програмоносія:

·  з перфострічкою;

·        з магнітним барабаном;

·        з оптичним диском;

·        з магнітною стрічкою;

·        з магнітним диском (дискета);

5. По об'єму інформації в управляючій програмі:

·  жорстко програмні;

·        адаптивні.

6. По способу програмування:

·  методом розрахунку (складання програм);

·        методом навчання;

·        самонавчаємі.

У позиційних СУ задаються початкові і кінцеві положення робочих органів. В малоточкових - число точок позиціювання - до 10. Багатоточкових до 100.

 

.9.2 Види систем керування

·  автономна;

·        комплексна;

·        багаторівнева.

Найбільше застосування для керування ПР знайшли автономні системи СУ спеціального призначення. Випускаються серійно - уніфіковані системи управління ПР - УЦМ устройство уніфіковане циклове модульне, УПМ - устройство уніфіковане позиційне модульне, УКМ устройство уніфіковане контурне модульне.

Малоточечні циклові системи позиційного управління - УЦМ.

Числові системи позиційного управління - УПМ.

Системи контурного управління серії УКМ.

Система управління (тип 1) призначені для ПР, які обслуговують ковальсько-пресового обладнання, ливарне виробництво, лінії гальванічні та металорізальні верстати в умовах великосерійного виробництва.

Рис. 1.7 Структурна схема УЦМ

Система позиційного управління (тип 2) призначені для управління (керування) ПР із значним (великим більше 10) числом точок позиціювання. Застосування - обслуговування підйомно-транспортних операцій, нескладних складальних робіт і операцій контактної точкової зварки.

Рис. 1.8 Структурна схема УПМ

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

Комплексні СУ призначені для управління комплексами обладнання - робот. Використовуються в системах металорізальних верстатів (ЧПУ) - числове програмне управління.

Багаторівневі системи числового управавління роботами застосовуються при обслуговуванні верстатів автоматизованих участків цехів. (Економічно не завжди доцільно).

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

Висновки до розділу 1

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

РОЗДІЛ 2. АНАЛІЗ ЗАСОБІВ ПРОГРАМУВАННЯ ТА РОЗРОБКИ ДЛЯ СТВОРЕННЯ ПРОЕКТУ

 

.1 OpenCV

 

.1.1 Що таке OpenCV

OpenCV - бібліотека комп'ютерного зору з відкритим вихідним кодом[12], доступна для завантаження на SourceForge.net Бібліотека написана на C і C + +, працює під Linux, Windows і Mac OS X. Відбувається активна розробка інтерфейсів для Python, Ruby, MATLAB і інших мов.заточена під виконання в реальному часі. Вона написана на оптимізованому C і може працювати з багатоядерними процесорами. Якщо Ви хочете отримати від бібліотеки більшу продуктивність то Вам доведеться придбати IPP (Integrated Performance Primitives). IPP представляє із себе ряд ретельно оптимізованих функцій для роботи з мультимедіа, криптографією, розпізнаванням мови, стисненням даних і багато чим ще. OpenCV автоматично використовує IPP, якщо вона встановлена.

Однією з цілей OpenCV є надання простої у використанні бібліотеки машинного зору, яка допомагає створювати досить складні додатки в короткі терміни. OpenCV містить в собі більше 500 функцій які охоплюють багато областей, включаючи контроль якості на виробництві, системи безпеки, обробку зображень в медицині, призначені для користувача інтерфейси, стереоскопічний зір і роботобудування. Оскільки комп'ютерне зір і навчання машин йдуть "рука об руку", OpenCV також включає в себе бібліотеку загального призначення MLL (Machine Learning Library, Бібліотека Навчання Машин). Ця під-бібліотека вирішує завдання статистичного розпізнавання образів і кластеризації. MLL дуже корисна для вирішення складних завдань, пов'язаних з комп'ютерним зором, але є досить загальною, для того щоб вирішувати більшість завдань навчання машин.

2.1.2 Хто використовує OpenCV

Більшість вчених і програмістів-практиків знають про деякі аспекти комп'ютерного зору, але мало хто знає про всі області, в яких воно використовується. Наприклад, більшість людей знає, що воно використовується в системах спостереження, і багато хто також знає, що комп'ютерне зір все частіше застосовується для обробки фото і відео в інтернеті. Деякі бачили, як комп'ютерний зір використовується в інтерфейсах ігор. Деякі знають про роль, яку комп'ютерний зір грає в аерофотозніманні та в зображеннях карт вулиць (див. Google Street Map) Деякі знають про ніші, займаної комп'ютерним зором в області безпілотних літальних апаратів і біомедичному аналізі. Але мало хто знає, наскільки звичайною справою став машинний зір у виробництві: практично все, що випускається серійно, на якомусь етапі автоматично перевіряється з використанням комп'ютерного зору.

Відкрита ліцензія для OpenCV була складена таким чином, щоб було можливо створювати комерційні додаткик, використовуючи будь-які можливості OpenCV. Ви не зобов'язані робити Ваш проект відкритим або публікувати зміни, внесені вами до бібліотеки, хоча ми сподіваємося, що ви це зробите. Частково через такі ліберальні умови існує велика спільнота користувачів, що включає в себе такі великі компанії як IBM, Microsoft, Intel, Sony, Siemens, Google, і це далеко не повний список, а також науково-дослідні центри, такі як Стенфорд, Массачусетський технологічний інститут, CMU, Кембридж, і INRIA. Є також група на Yahoo де користувачі можуть задавати питання, що налічує більше 20 000 чоловік. OpenCV популярна у всьому світі, причому великі спільноти користувачів можна знайти в Китаї, Японії, Росії, Європі та Ізраїлі.

З моменту свого альфа-релізу в січні 1999 року, OpenCV була використана в багатьох додатках і науково-дослідних роботах, в тому числі: накладення звичайних карт і фотографій з супутника, вирівнювання документів при скануванні, видалення шуму з медичних зображень, аналіз об'єктів, системи безпеки, автоматичне спостереження, системи контролю якості на виробництві, калібрування камер, а також безпілотні літальні, наземні та підводні апарати. Вона навіть була використана для розпізнавання звуку та музики, де методи розпізнавання образів були застосовані до зображень спектрограм звуку. Бібліотека стала ключовою частиною системи зору робота "Stanley" зі Стенфорда, який виграв 2.000.000 $ на Великих Пустельних Перегонах Роботів DARPA.

 

.1.3 Що таке комп'ютерний зір

Комп'ютерний зір - це перетворення даних, що надходять з фото-або відеокамери, в прийняття рішення або інше уявлення. Всі подібні перетворення виконуються для досягнення певної мети. Вхідні дані можуть включати в себе якусь контекстну інформацію, начебто "камера встановлена ​​в машині" або "лазер вказує на об'єкт, відстань до якого 1 метр".

Новим представленням може бути перетворення кольорового зображення в чорно-біле або видалення руху камери з відеозапису.

Оскільки ми з вами є "візуальними" істотами, то ми можемо помилково вважати, що машинний зір - це дуже просто. Наскільки важко знайти, скажімо, автомобіль, розташований на картинці? Ваша інтуїція може ввести вас в оману. Людський мозок ділить зоровий сигнал на кілька різних потоків інформації. Ваш мозок має систему, яка знаходить важливі частини зображення і зосереджує увагу на них, в той же час пригнічуючи обробку інших частин. Це робиться способом, що залежить від поточного завдання. Ми поки погано розуміємо пристрій цієї системи. Є також асоціативні входи від всіх органів почуттів, на підставі даних з яких мозок може використовувати асоціації, накопичені за роки життя в світі. Також людське око здатне автоматично звужувати або розширювати зіницю в залежності від освітлення, і змінювати діаметр кришталика фокусуючи картинку на сітківці.

У системі ж машинного зору комп'ютер отримує всього лише масив чисел з камери або диска - і більше нічого. Як правило, немає ні вбудованого розпізнавача образів, ні автоматичного управління фокусом і об'єктивом, ні асоціацій, накопичених за роки життя. Здебільшого системи машинного зору все ще дуже примітивні.

Рис. 2.1 Представлення зображення у вигляді масиву

На зображенні 2.1 зображений автомобіль з виділеним бічним дзеркалом. Проте камера побачить всього лише масив чисел. Будь-яке число в цьому масиві має дуже велику шумову складову, і саме по собі дає нам дуже мало інформації, але цей масив - все, що здатний "побачити" комп'ютер. Наша задача полягає в тому, щоб перетворити цей масив в сприйняття "дзеркала".

Рис. 2.2 Побудова 3D зображення з 2D картинок

Зображення 2.2 ще більше показує, чому машинний зір - це так складно. Насправді проблема ще складніша, ніж ми її представили спочатку, оскільки формально її неможливо вирішити. Маючи двовимірне (2D) подання тривимірного (3D) світу, немає єдиного способу відтворення тривимірного сигналу.

Формально, така некоректна задача не має однозначного або остаточного рішення. Одна і та ж 2D-картинка може бути поданням нескінченної кількості 3D-сцен, навіть якщо якість даних була ідеальною. Насправді ж, як уже згадувалося, дані зазвичай пошкоджені шумами і спотвореннями. Ці проблеми пов'язані із змінами в світі (погода, освітлення, відображення, рух), недоліками об'єктивів, кінцевим часом витримки, електричними шумами в камері, артефактами стиснення зображення. З урахуванням всіх цих проблем, як ми можемо домогтися хоч якого-небудь успіху?

При розробці практичної системи ми можемо використовувати знання про контекст, щоб обійти накладаються на нас обмеження. Розглянемо приклад мобільного робота, який повинен знайти і зібрати всі степлери з будівлі. Робот може використовувати той факт, що столи зазвичай знаходяться всередині будівлі, а степлери зазвичай лежать на столах. Це дає неявне посилання на розмір; степлер повинен поміщатися на стіл. Це також допомагає усунути помилкові розпізнання, оскільки степлер не може лежати, наприклад, на вікні або стелі. Робот також може благополучно проігнорувати 200-футовий рекламний дирижабль у формі степлера, тому що під ним немає текстури дерева. Навпаки зображення степлера в базі даних може мати занадто великий розмір або мати незвичайну конфігурацію, так як це пов'язано з тим, хто робив фото. Фотограф міг сфотографувати тільки степлери однакових розмірів. Люди також мають тенденцію знімати об'єкти так, щоб вони були в центрі зображення, і були повернені «по-звичайному» - скажімо, навряд чи хтось стане фотографувати людей вгору ногами. Таким чином у фотографіях, зроблених людьми, є багато «зайвої інформації» включеної туди ненавмисно.

Контекстна інформація також може бути змодельована за допомогою алгоритмів навчання машин. Приховані параметри, такі як розмір і орієнтація на гравітацію, можуть бути помічені в множині, на якій проводиться навчання. Крім того можна спробувати виміряти приховані параметри за допомогою додаткових датчиків. Застосування лазерного далекоміра дозволяє точно виміряти розміри об'єкта.

Наступна проблема, з якою стикаються при вивченні комп'ютерного зору - це шум. Скажімо, завдання про визначення кордонів у зображенні може виявитися неймовірно складною, якщо ми будемо вирішувати його, порівнюючи точки зі своїми найближчими сусідами. Однак, якщо збирати інформацію з околиці точки, завдання істотно спрощується. Реальна перевага повинна з'явитися у вигляді рядка такої негайної реакції сусіда по локальній області, кожна з яких відповідає орієнтації зі своїми сусідами. Шум також можна видаляти, збираючи інформацію протягом проміжку часу. Інші методи будують моделі шуму на підставі доступних даних. Наприклад, так як спотворення, пов'язані з лінзами, добре вивчені, достатньо лише знайти параметри простого многочлена, щоб описати - і, таким чином, майже повністю видалити - подібні спотворення.

Дії або рішення, що виконуються комп'ютером на основі даних з камери, зазвичай виконуються в контексті конкретного завдання. Ми можемо видалити з зображення перешкоди і спотворення так, щоб наша система безпеки била тривогу якщо хтось перелазить через паркан, або зробити систему підрахунку людей, які пройшли повз камери. Програмне забезпечення для роботів, які їздять по офісним будівлям, буде сильно відрізнятися від ПО для стаціонарних камер, тому що ці дві системи мають суттєво різні цілі. Як правило, чим більше обмежень має умову конкретного завдання, тим простіше і надійніше буде рішення.

Метою бібліотеки OpenCV є надання основних інструментів, необхідних для вирішення завдань комп'ютерного зору. Можливо, для вирішення навіть дуже складного завдання функціональності бібліотеки буде достатньо. Навіть якщо це не так, базові компоненти бібліотеки досить просунуті, щоб можна було створити власне рішення практично будь-якої задачі комп'ютерного зору. Для останнього випадку є кілька перевірених методів використання бібліотеки; всі вони починаються з вирішення задачі з використанням найбільшої кількості компонентів бібліотеки. Як правило, після того, як ви розробите це перше чорнове рішення, ви побачите його недоліки і зможете їх виправити, використовуючи свій код і розум (також відоме як "вирішувати проблему, яка перед вами стоїть, а не ту, що ви придумали") . Після цього ви зможете використовувати ваше чорнове рішення в якості тесту, щоб оцінити зроблені вами поліпшення. Нарешті, які б недоліки не залишалися, з ними можна справитися, використовуючи обмеження більшої системи, що включає вашу проблему.

 

.1.4 Походження OpenCV

Бібліотека OpenCV до версії 1.0 створювалася в російському центрі розробки програмного забезпечення Intel, розташованим в Нижньому Новгороді. На в той момент в Intel було багато проектів, пов'язаних з трасуванням променів, 3D відображенням і т.д. Один з авторів, що працюють в той час в Intel, зауважив, що деякі групи студентів з університетів, такі як MIT Media Lab, розробляли відкриті проекти по машинному зору, передаючи код від студента до студента. Це давало кожному новому студенту цінну фору в розробці їх власних програм комп'ютерного зору. Замість того щоб все починати з нуля, нові студенти спиралися на роботу попередніх.

Таким чином, бібліотека OpenCV була задумана як загальнодоступна. Далі до першого релізу, тобто до 2006 року, над бібліотекою працювала команда в Нижньому Новгороді. Головним з російської команди був Вадим Писаревський, який і по колишньому вкладає багато зусиль в OpenCV. Також, Віктор Єрухімов допоміг розвинути ранню інфраструктуру, а Валерій Курякін, керував російської лабораторією.

Спочатку перед OpenCV ставилися наступні цілі:

·  Сприяти дослідженням у галузі комп'ютерного зору шляхом розробки не тільки відкритого, а й ретельно оптимізованого коду. Тепер ніхто більше не повинен винаходити велосипед.

·        Поширення інформації по машинному зору, розробка загальної інфраструктури на якій могли б грунтуватися розробники; код повинен бути зручно читаємий і передаваємий.

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

Розвиток програм, що використовують комп'ютерний зір, спричинить зростання попиту на швидкі процесори. Прискорений перехід на швидкі процесори принесе Intel більший прибуток, ніж продаж програмного забезпечення. Ось основна причина, по якій безкоштовна і відкрита бібліотека була створена в компанії, що спеціалізується на комплектуючих комп'ютера, а не на програмному забезпеченні. У якомусь сенсі, нові ідеї простіше просувати, працюючи саме в "залізної" компанії.

У будь-якому загальнодоступному проекті важливо досягти критичної точки, після якої проект стає самопідтримуваним. OpenCV скачали більше двох мільйонів разів, і це число зростає в середньому на 26 000 завантажень на місяць. Група користувачів наближається до 20 000 учасників. Користувачі внесли великий вклад у розвиток OpenCV і подальша розробка бібліотеки перемістилася за межі Intel.

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

 

2.2 Мова РНР

(англ. PHP:Hypertext Preprocessor - PHP:гіпертекстовий препроцесор), попередня назва: Personal Home Page Tools - скриптова мова програмування, була створена для генерації HTML-сторінок на стороні веб-сервера. PHP є однією з найпоширеніших мов, що використовуються у сфері веб-розробок (разом із Java, .NET, Perl, Python, Ruby). PHP підтримується переважною більшістю хостинг-провайдерів. PHP - проект відкритого програмного забезпечення.інтерпретується веб-сервером в HTML-код, який передається на сторону клієнта.

На відміну від скриптової мови JavaScript, користувач не бачить PHP-коду, бо браузер отримує готовий html-код. Це є перевага з точки зору безпеки, але погіршує інтерактивність сторінок. Але ніщо не забороняє використовувати РНР для генерування і JavaScript-кодів які виконуються вже на стороні клієнта.

 

.2.1 Особливості

PHP - мова, яка може бути вбудована безпосередньо в html-код сторінок, які, в свою чергу коректно будуть оброблені PHP -інтерпретатором. Механізм РНР просто починає виконувати код після першої екрануючої послідовності (<?) і продовжує виконання до того моменту, коли він зустріне парну екрануючу послідовність (?>).

·  Велика різноманітність функцій PHP дають можливість уникнути написання багаторядкових призначених для користувача функцій на C або Pascal.

·        Наявність інтерфейсів до багатьох баз даних

·        в PHP вбудовані бібліотеки для роботи з MySQL, PostgreSQL, mSQL, Oracle, dbm, Hyperware, Informix, InterBase, Sybase.

·        через стандарт відкритого інтерфейсу зв'язку з базами даних (Open Database Connectivity Standard - ODBC) можна підключатися до всіх баз даних, до яких існує драйвер.

·        Традиційність

Мова РНР здаватиметься знайомою програмістам, що працюють в різних областях. Багато конструкцій мови запозичені з С, Perl. Код РНР дуже схожий на той, який зустрічається в типових програмах на С або Pascal. Це помітно знижує початкові зусилля при вивченні РНР. PHP - мова, що поєднує переваги Perl і С і спеціально спрямована на роботу в Інтернеті, мова з універсальним і зрозумілим синтаксисом. І хоча PHP є досить молодою мовою, вона здобула таку популярність серед web-програмістів, що в наш час є мало не найпопулярнішою мовою для створення веб-застосунків (скриптів).

Наявність вихідного коду та безкоштовність

Стратегія Open Source, і розповсюдження початкових текстів програм в масах, безсумнівно справили благотворний вплив на багато проектів, в першу чергу - Linux хоч і успіх проекту Apache сильно підкріпив позиції прихильників Open Source. Сказане відноситься і до історії створення РНР, оскільки підтримка користувачів зі всього світу виявилася дуже важливим чинником в розвитку проекту РНР.

Ухвалення стратегії Open Source і безплатне розповсюдження початкових текстів РНР надало неоціниму послугу користувачам. Додатково, користувачі РНР в усьому світі є свого роду колективною службою підтримки, і в популярних електронних конференціях можна знайти відповіді навіть на найскладніші питання.

Ефективність

Ефективність є дуже важливим чинником при програмуванні для середовищ розрахованих на багато користувачів, до яких належить і web. Важливою перевагою PHP є те, що ця мова належить до інтерпретованих. Це дозволяє обробляти сценарії з достатньо високою швидкістю. За деякими оцінками, більшість PHP-сценаріїв (особливо не дуже великих розмірів) обробляються швидше за аналогічні їм програми, написані на Perl. Проте, щоб не робили розробники PHP, виконувані файли, отримані за допомогою компіляції, працюватимуть значно швидше - в десятки, а іноді і в сотні разів. Але продуктивність PHP цілком достатня для створення цілком серйозних веб-застосунків.

 

.2.2 Історія

Перші версії

Історія PHP починається з 1995 року, коли Расмус Лердорф (Rasmus Lerdorf) створив простий застосунок мовою Perl, що аналізував відвідування користувачами його резюме на веб-сайті. Потім, коли цим застосунком вже користувалися кілька чоловік, а число охочих одержати його постійно збільшувалося, Лердорф назвав своє творіння Personal Home Page Tools версія 1 і виставив для вільного завантаження. З цієї миті почався небувалий зліт популярності PHP.

Як це завжди буває, терміново було потрібне доопрацювання і нові доповнення. Для їхньої реалізації Расмус створює нову версію пакету, тепер уже написану С. Отриманий таким чином інструмент набуває робочої назви PHP/FI (Personal Home Page / Forms Interpreter - Персональна Домашня сторінка / Інтерпретатор Форм), надалі він також буде відомий під назвою PHP 2. Ця версія вже більшою мірою схожа на сьогоднішній PHP. Вона мала синтаксис і спосіб іменування змінних в стилі мови Perl, можливість вбудовування PHP операторів в html-код сторінки, автоматичну інтерпретацію форм, інтеграцію з базами даних. При цьому все працювало досить швидко, оскільки PHP прикомпилювалось до веб-серверу Apache. До 1997 року PHP використовувався вже на 50,000 доменах (не більше 1% всіх веб-серверів).

У тому ж 1997 році до проекту PHP підключилися Зев Сураскі (Zeev Suraski) і Енді Гутманс (Andi Gutmans). Ці студенти Техніону, одного з ізраїльських університетів, намагалися використовувати PHP/FI для одного з комерційних університетських проектів. При цьому їм довелося зіткнутися з багатьма труднощами і обмеженнями цієї технології. Вивчаючи початковий код PHP 2, Зеєв і Енді дійшли висновку про необхідність доопрацювання, а точніше істотної переробки PHP, особливо в плані синтаксису мови. Протягом декількох місяців вони блискуче впоралися з цим завданням.

Закінчивши роботу Зеєв і Енді домовились з Расмусом про співпрацю в галузі розвитку та вдосконалення мови. З цієї миті з'являється PHP Group - група однодумців, що працюють над розвитком технології PHP. Одержаний продукт з'явився на світ у 1998 році під назвою PHP 3.

При цьому головною особливість PHP 3 була можливість розширення ядра, що привернуло до роботи над PHP безліч сторонніх розробників, що створюють спеціалізовані модулі. Їх наявність дала PHP можливість працювати з величезною кількістю баз даних, протоколів, підтримувати велике число API. До кінця 1998 кількість користувачів PHP перевалила за 100000, а PHP був вже встановлений на не менше ніж 10% серверах Інтернету. У той ж час значному поширенню даної мови сприяли публікації в електронній пресі та вихід книжок для вивчення PHP.

Відразу ж після виходу PHP 3, Енді Гутманс і Зев Сураскі почали переробку ядра PHP. В першу чергу належало вирішити проблему підвищення продуктивності. Новий продукт, названий Zend Engine (від імен творців: Zeev і Andi), успішно справлявся з поставленим завданням і був реалізований в 1999 році. Основними реалізованними ідеями є можливість компіляції сценарію у виконуваний модуль, за рахунок чого продуктивність можна було підняти на порядок.

Визнання та поширення4, що працює на цьому ядрі, вийшов в 2000 році. На додаток до збільшення продуктивності, PHP 4 мав нові можливості щодо підтримки сесій, буферизацію виводу, безпечні способи обробки інформації, що вводиться користувачем, і нові мовні конструкції. З виходом 4 версії PHP став використовуватися вже на більш ніж 20% доменів Інтернету.

За час з 2000 по 2004 рік продовжувалися активні роботи з покращення 4 версії, але майже відразу PHP Group приступила до продумування можливостей нової версії. В першу чергу було вирішено підсилити об'єктні можливості мови, що дозволяло використовувати його для реалізації масштабних проектів. Роботи із створення версії 5 велися тривалий час, в них брало участь рекордна кількість фахівців, зокрема Стерлінг Хьюз (Sterling Hughes) і Маркус Бергера (Marcus Boerger).

У липні 2004 року виходить офіційний реліз PHP 5. В першу чергу, як і планувалося, було перероблено весь механізм роботи з об'єктами. І якщо в попередніх версіях об'єктно-орієнтоване програмування на PHP було можливе в мінімальному ступені, а тому і використовувалося на практиці не часто, то PHP 5 володіє прекрасним потенціалом реалізації об'єктного програмування. Окрім цього, PHP збагатився рядом цінних розширень для роботи з XML, різними джерелами даних, генерації графіки і інше.

Серед інших украй корисних доповнень в PHP 5 слід зазначити нову схему обробки виключень. Конструкція try/catch/throw дозволяє весь код обробки помилок локалізувати в одному місці сценарію.

Всі основні бібліотеки для роботи з XML, запозичені в PHP 4, були піддані серйозній переробці. Такі популярні розширення, як SAX, DOM і XSLT, тепер використовують інструмент libxml2, що робить їх ще ефективнішими.

У PHP 5 також включені два нові модулі для роботи з протоколами - SimpleXML і SOAP. SimpleXML дозволяє значно спростити роботу з XML-даними, представляючи вміст XML-документа у вигляді PHP-об'єкта. Розширення SOAP дозволяє будувати на PHP сценарії, що обмінюються інформацією з іншими застосунками за допомогою XML-повідомлень поверх існуючих веб-протоколів, наприклад HTTP. Модуль для роботи з SOAP для PHP 5 надає розробникам засіб для достатньо швидкого створення ефективних SOAP-клієнтів і SOAP-серверів.

Новий модуль PHP 5 MySQLi (MySQL Improved) призначений для роботи з MySQL-сервером версій 4.1.2 і вище, реалізовуючи не тільки процедурний, але і об'єктно-орієнтований інтерфейс до MySQL. Додаткові можливості цього модуля включають - SSL, контроль транзакцій, підтримка реплікації і ін. Очевидно, що, на цьому історія PHP не закінчується. Слід очікувати наступних версій мови із розширеними можливостями.

 

.2.3 Додаткові можливості

Мова явно підтримує HTTP cookies відповідно до специфікацій Netscape. Це дозволяє проводити встановлення та читання невеликих сегментів даних на стороні клієнта.надає можливість організації роботи з користувачем протягом сеансів (сесій). В сесії можна зберігати різні дані, включаючи об'єкти.

 

.2.4 Недоліки PHP

·        Незручність дизайну мови

o     Складні назви поширених функцій (html_entities_decode, mysql_select_db, nl2br тощо)

o     Не підтримується Unicode в версіях до 6.0

·        Непередбачуваність нових версій PHP.

·              Відсутність єдиного драйвера для баз даних

Критика

У статті «PHP: a fractal of bad design» представлений докладний і ґрунтовний огляд проблем в дизайні мови програмування PHP. Автор показує винятковість PHP як одної з найбільш неопрацьованих мов, проблеми в якій носять систематичний характер. Зокрема у статті продемонстровані проблеми в самій мові, бібліотеці функцій, структурах, механізмах роботи з даними, екосистемі, засобах зневадження. Вказані недоробки в безпеці, надійності, цілісності та передбачуваності.

Якщо розглядати безпеку, то як приклад спочатку порочної практики наводиться розрізненість засобів для чищення та нормалізації даних перед їхнім використанням у різних операціях, що є прекрасною підмогою для виникнення в застосунках вразливостей, що дозволяють здійснити підстановку SQL-коду або вбудовування JavaScript на сторінку. Згадки також заслуговує підхід "небезпечний за умовчанням", який тільки останнім часом став переглядатися розробниками PHP, наприклад, причиною безлічі вразливостей є використання register_globals і підтримка виконання зовнішнього коду за URL в директиві include. З проблем у самому інтерпретаторі відзначається спроба виправити в 2007 році цілочисельну вразливість через перевірку "if (size > INT_MAX) return NULL;"; помилка в реалізації функції crypt() в PHP 5.3.7 через яку можна було зайти з будь-яким паролем; DoS-уразливість в PHP 5.4, пов'язана з виділенням пам'яті на підставі переданого користувачем значення в HTTP-заголовку Content-Length.

 

.2.5 Ліцензія

Ліцензія PHP має назву The PHP License version 3.0, ЧАП по цій ліцензії та її текст можна знайти на офіційному сайті The PHP Group, а також файл із ліцензією містить дистрибутив PHP (звичайно license.txt).

 

.3 Apache web-сервер

HTTP-сервер - відкритий веб-сервер Інтернет для UNIX-подібних, Microsoft Windows, Novell NetWare та інших операційних систем. На сьогодні є найуживанішим Веб сервером мережі Інтернетрозроблюється та підтримується спільнотою розробників відкритого програмного забезпечення під керівництвом Apache Software Foundation.

 

.3.1 Історія та назва

Сервер Apache створений на початку 1995 року співтовариством незалежних розробників «Apache Group», члени якої у свій час брали участь у проекті з побудови перших Web-серверів у NCSA (National Center for Supercomputer Applications, USA). «Apache Group» пропонує Web-сервери, сумісні з будь-якою UNІХ-системою, установленої на будь-якій апаратній платформі. Сервер перенесений і на інші операційні системи. Так, уже зараз Apache Web-сервер доступний для OS/2, UNIX-платформ, Windows 2000 та ін.сервер Apache, як і всі інші Web-сервери, базується на ідеях і частині коду, реалізованих у першому по-справжньому популярному Web-Сервері - NCSA httpd 1.3.

Є два пояснення назви проекту. Згідно з Apache Foundation, назву проекту було вибрано з поваги до корінного племені американського континенту апачів, що були відомі за свою витривалість та військову майстерність. Проте, перший FAQ на веб-сайті проекту Apache Server з 1996 до 2001 стверджував, що «назва „Apache“ походить від абревіатури „А PAtCHy server“, що дослівно перекладається як „залатаний сервер“ - сервер, у код якого внесений цілий ряд серйозних змін.» Перше пояснення було підтверджено на Конференції Apache і в інтерв'ю 2000 року з Брайаном Беглендорфом, який, тим не менш, спростував це твердження в інтерв'ю 2007 року, заявляючи, що «сервер Apache не названий на честь племені Джеронімо».

Версія 2 веб-сервера Apache була істотним переписом великої частини коду програми версії 1.x, з сильним нахилом на подальшу модульність та портативність. Версія 2.2 має гнучкіший API авторизації. Вона також включає поліпшені модулі кешу й проксі сервера.

 

.3.2 Можливості

Web-сервер Apache є самостійним, некомерційним, вільно розповсюджуваним продуктом. Продукт підтримує безліч можливостей, багато з яких реалізовані як скомпільовані модулі, які розширюють основні функціональні можливості. Вони різняться від серверної підтримки мов програмування до схем аутентифікації. Існують інтерфейси для підтримки мов програмування Perl, Python, Tcl і PHP.

Популярні методи стискування на Apache включають зовнішній модуль mod_gzip, створений для зменшення розміру веб-сторінок, переданих по HTTP.

Функції віртуального хостингу дозволяють одній інсталяції Apache обслуговувати різні веб-сайти. Наприклад, одна машина, з однією інсталяцією Apache може одночасно містити www.example.com, www.test.com, test47.test-server.test.com і так далі.

 

.3.3 Використання

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

Продукт може працювати в якості кешувального проксі-сервера, що дозволяє істотно підвищити продуктивність роботи користувачів локальної мережі при роботі з документами, розташованими в Інтернет. Можна задавати такі параметри і налаштування проксі-сервера:

типи файлів, які необхідно кешувати або навпаки, не включати в кеш;

максимальний обсяг дискового простору, відведений під кеш;

періодичний перегляд і індексування бази даних кеша з метою вивільнення дискового простору шляхом видалення застарілих об'єктів.зіграв ключову роль у початковому зростанні всесвітньої павутини, і продовжує бути найпопулярнішим у світі веб-сервером, де-факто платформою, на яку орієнтуються інші веб-сервери.

Відповідно до статистики Netcaft за червень 2008 року, Apache є найпоширенішим серверним програмним забезпеченням в Мережі: на цей веб-сервер припадала частка близько 49 % відповідного сегменту ринку (майже 85 мільйонів сайтів). Друге місце за популярністю займають програмні платформи Microsoft - 35,4 % (61 мільйон сайтів).

 

.3.4 Архітектура

Ядро

Ядро Apache включає в себе основні функціональні можливості, такі як обробка конфігураційних файлів, протокол HTTP і система завантаження модулів. Ядро (в відміну від модулів) повністю розробляється Apache Software Foundation, без участі сторонніх програмістів.

Теоретично, ядро Apache може функціонувати в чистому вигляді, без використання модулів. Однак, функціональність такого рішення вкрай обмежена.

Ядро Apache повністю написано на мові програмування C.

Система конфігурації

Система конфігурації Apache заснована на текстових конфігураційних файлах. Має три умовних рівня конфігурації:

Конфігурація сервера (httpd.conf).

Конфігурація віртуального хоста (httpd.conf c версії 2.2 extra/httpd-vhosts.conf).

Конфігурація рівня директорії (.htaccess).

Має власну мову конфігураційних файлів, заснований на блоках директив. Практично всі параметри ядра можуть бути змінені через конфігураційні файли. Більша частина модулів має власні параметри.

Частина модулів використовує в своїй роботі конфігураційні файли операційної системи (наприклад /etc/passwd і /etc/hosts).

Крім цього, параметри можуть бути задані через ключі командного рядка.

Мультипроцесувальні моделі (MPM)

Для веб-сервера Apache існує безліч моделей симетричного мультипроцесування. ось основні з них:

Назва	Розробник	Підтримувані OS	Опис	Призначення	Статус
worker	Apache Software Foundation	Linux, FreeBSD	Гібридна мультипроцесорна-багатонитева модель. Зберігаючи стабільність мультипроцесорних рішень, вона дозволяє обслуговувати велику кількість клієнтів з мінімальним використанням ресурсів.	Середньонавантажені веб-сервери.	Стабільний.
pre-fork	Apache Software Foundation	Linux, FreeBSD	MPM, заснована на попередньому створенні окремих процесів, не використовує механізм threads.	Велика безпека і стабільність за рахунок ізоляції процесів один від одного, збереження сумісності зі старими бібліотеками, що не підтримують threads.	Стабільний.
perchild	Apache Software Foundation	Linux	Гібридна модель, з фіксованою кількістю процесів.	На високонавантажених серверах, можливість запуску дочірніх процесів використовуючи інше ім'я користувача для підвищення безпеки.	У розробці, нестабільний.
netware	Apache Software Foundation	Novell NetWare	Багатонитева модель, оптимізована для роботи в середовищі NetWare.	Сервери Novell NetWare	Стабільний.
winnt	Apache Software Foundation	Microsoft Windows	Багатонитева модель, створена для операційної системи Microsoft Windows.	Сервери під керуванням Windows Server.	Стабільний.
Apache-ITK	Steinar H. Gunderson	Linux, FreeBSD	MPM, заснована на моделі prefork. Дозволяє запуск кожного віртуального хоста під окремими uid та gid.	Хостингові сервери, сервери, критичні до ізоляції користувачів і обліку ресурсів.	Стабільний.
peruser	Sean Gabriel Heacock	Linux, FreeBSD	Модель, створена на базі MPM perchild. Дозволяє запуск кожного віртуального хоста під окремими uid та gid. Не використовує ниті.	Забезпечення підвищеної безпеки, робота з бібліотеками, не підтримуються ниті.	Стабільна версія від 4 жовтня 2007 року, експериментальна - від 10 вересня 2009 року.

2.4 Мікроконтролери AVR

- сімейство восьмибітових мікроконтролерів фірми Atmel.

2.4.1 Мікроконтролери сімейства AVR

Мікроконтролери AVR мають гарвардську архітектуру (програма і дані знаходяться в різних адресних просторах) і систему команд, близьку до ідеології RISC. Процесор AVR має 32 8-бітових регістра. Управління мікроконтролером, по суті, є управління цими регістрами. На відміну від «ідеального» RISC, регістри не абсолютно ортогональні: Три «здвоєні» 16-бітові регістри-покажчики X (r26:r27), Y (r28:r29) і Z (r30:r31) Деякі команди працюють тільки з регістрами r16.r31. Результат множення (у тих моделях, в яких є модуль множення) завжди поміщається в r0:r1

Управління периферійними пристроями здійснюється через адресний простір даних. Для зручності існують «скорочені команди» IN/OUT. Окрім фірмових засобів розробки (IAR, CODEVISION і ін.), існує GNU порт GCC для AVR. Крім того, архітектура AVR дозволяє застосовувати операційні системи при розробці застосувань, основними з яких є FREERTOS і uOS. Не мало важливим є й те, що програмування цих мікроконтролерів здійснюється досить легко. Найпростіший програматор, пристрій за допомогою якого пресональний комп'ютер записує програму в flash пам'ять мікроконтролера, складається з п'яти провідників та вилки LPT порта. Це дозволяє з успіхом використовувати ці присторої новачкам, що хочуть отримати знання з мікроелектроніки.

 

.4.2 Основні сімейства

·  tinyAVR

o 0.5-8 кБ пам'яті програм

o   6-32-вивідний корпус

o   Обмежений набір внутрішніх периферійних пристроїв

·  megaAVR

o 4-256 кБ пам'яті програм

o   28-100-вивідний корпус

o   Розширений набір команд (Команди множення)

o   Обширний набір внутрішніх периферійних пристроїв

·  XMEGA

o 16-384 кБ пам'яті програм

o   44-64-100-вивідний корпус (A4, A3, A1)

o   Підвищена продуктивність за рахунок таких особливостей, як ПДП (Прямий Доступ до Пам'яті), підтримка криптографії, "Система подій".

o   Обширний набір внутрішніх периферійних пристроїв (ЦАП)

 

.4.3 AVR ATMega32

Характеристики

Високопродуктивні, AVR 8 - бітові мікро контролери, що мало споживають[9].

Розвинена RISC архітектура:

·  131 виконувана команда, більшість за один машинний такт

·        32 робочих регістра загального призначення

·        Повністю статичний режим роботи

·        Продуктивність до 16 MIPS при 16 МГц

·        Вбудований 2-х тактовий помножувач

·        Незалежна пам'ять програм і даних

·        32К байт внутрішньосистемно самопрограмуємої FLASH пам'яті з кількістю циклів перепрограмування до 10 000.

·  Опціонально завантажувальна область пам'яті з незалежними ключовими бітами, внутрішньосистемне програмування вбудованою завантажувальною програмою, правильне читання в процесі запису.

·        1024 байт EEPROM з допустимою кількістю циклів стирання-запису до 100 000.

·  2К байт внутрішньої SRAM

·        Програмований ключ захисту программ

·        JTAG (IEEE1149.1 сумісний) інтерфейс

·        Сканування пам'яті відповідно до JTAG стандарту

·        Вбудована підтримка дебаггера

·        Програмування FLASH, EEPROM, охоронних і ключових бітів через JTAG інтерфейс

Периферійні функції

·  Два 8-бітних таймера / лічильника з програмованим переддільником (предделителем) і режимом порівняння

·        Один 16-бітний таймер / лічильник з програмованим переддільником (предделителем), режимом порівняння та захоплення

·        Лічильник реального часу з програмованим генератором

·        Чотири ШІМ генератора

·        8-и канальний, 10-и бітний АЦП

·        Байт-орієнтований, двопровідний інтерфейс

·        Програмований USART

·        Master / Slave SPI послідовний інтерфейс

·        програмований Watchdog таймер з програмованим генератором - Вбудований аналоговий компаратор

Спеціальні функції

·  Reset по увімкненню живлення та вимкнення при зниженні напруги живлення

·        Внутрішній калібрований RC генератор

·        Зовнішні і внутрішні джерела переривання

·        Шість економічних режимів: Idle, придушення шумів АЦП, економічний, режим Вимк. , Режим очікування та режим розширеного очікування.

програмованих виведення вхід-вихід і 1 вхід

вивідний корпус PDIP, 44 вивідний корпус TQFP, і 44 контактний MLF

Напруга живлення:

.5 В до 5.5 В для Atmega32

Тактова частота:

-16 МГц Atmega32

Рис. 2.3 Блок- схема

Рис. 2.4 Розташування виводів

Опис/ L є КМОП 8 - бітним мікроконтролером побудованим на розширеній AVR RISC архітектурі. Використовуючи команди, що виконуються за один машинний такт, контролер досягає продуктивності в 1 MIPS на робочій частоті 1 МГц, що дозволяє розробнику ефективно оптимізувати споживання енергії за рахунок вибору оптимальної продуктивності.ядро поєднує розширений набір команд з 32 робочими регістрами загального призначення. Усі 32 регістра з'єднані з АЛУ, що забезпечує доступ до двох незалежних регістрів на час виконання команди за один машинний такт. Завдяки вибраній архітектурі досягнута найвища швидкість коду і відповідно висока продуктивність, що в 10 разів перевершує швидкість відповідного CISC мікроконтролера./ L містить 32Кбайт внутрішньосистемно програмованої FLASH пам'яті програм, що допускає читання під час запису, 1024 байт EEPROM, 2К байт SRAM, 32 робочих регістра, JTAG інтерфейс сканування внутрішніх регістрів, вбудовану систему налагодження та програмування, три гнучких таймера-лічильника з модулем порівняння, внутрішні і зовнішні переривання, послідовний програмований інтерфейс USART, байт-орієнтований двопровідний послідовний інтерфейс, 8-и канальний, 10-и бітний АЦП з диференціальним програмованим підсилювачем (тільки для TQFP), програмований Watchdog таймер з внутрішнім генератором, порт SPI і шістьма режимами заощадження енергії. В режимі Idle ЦПУ не функціонує в той час як функціонують USART, двопровідний інтерфейс, АЦП, SRAM, таймери-лічильники, SPI порт і система переривань. В Atmega32 існує спеціальний режим придушення шуму АЦП, при цьому в цілому в сплячому режимі функціонує тільки АЦП і асинхронний таймер для зменшення цифрових шумів перетворення. В режимі Вимк. процесор зберігає вміст всіх регістрів, заморожує генератор тактових сигналів, призупиняє всі інші функції кристала до приходу зовнішнього переривання або надходження зовнішньої команди Reset. В режимі очікування працює один тактовий генератор, при зупинці інших функцій контролера. Завдяки швидкому переходу в нормальний режим роботи в тому числі і за зовнішнім переривання Atmega32 успішно пристосовується до зовнішніх умов роботи і вимагає менше енергії, частіше опиняючись в режимі Вимк. У розширеному режимі очікування в робочому стані перебувають основний генератор і асинхронний генератор.

Мікросхеми випускаються при використанні Atmel технології енергонезалежній пам'яті високої щільності. Вбудована ISP FLASH пам'ять дозволяє перепрограмувати область програмної пам'яті внутрішньосистемно через послідовний SPI інтерфейс стандартним програматором, або використовуючи завантажувальну програму з енергонезалежної пам'яті працює в AVR ядрі. Комбінація розширеної 8-и бітної RISC архітектури ЦПУ і твердотільної FLASH пам'яті забезпечують Atmega32 високу гнучкість та економічну ефективність у вбудованих системах управління.

2.5 RISC-архітектура

(англ. Reduced Instruction Set Computing - комп'ютер зі скороченим набором команд) - архітектура процесорів зі скороченим набором команд. Ще відома як «Load/Store» архітектура. Найвідоміші представники: DEC Alpha, ARC, ARM, AVR, MIPS, PA-RISC, Power Architecture (включаючи PowerPC), SuperH, та SPARC.

Основними рисами RISC архітектури є:

·  Мала кількість інструкцій

·        Однакова довжина всіх інструкцій

·        Мала кількість різних форматів інструкцій

·        Відсутність інструкцій які працюють з операндами в пам'яті (за виключенням інструкцій завантаження та збереження)

·        Мала кількість апаратно підтримуваних типів даних

·        Велика кількість ідентичних регістрів загального призначення

Поштовхом для розробки RISC архітектури стало те, що тогочасні (середина 1970-х) компілятори не використовували більшість команд із CISC набору та не могли скористатися перевагами багатьох типів складної адресації. Виконання складних CISC інструкцій вимагало багатьох процесорних тактів, а реалізація різних типів адресування та інструкцій, що реалізовують високорівневі операції, займала більшість площі процесорного кристалу та майже не використовувалась.процесори швидші і економічніші CISC. У принципі, є можливість проектувати процесори на чистій RISC-архітектурі. Але відмовитися від архітектури x86 вже неможливо, оскільки під неї написано більшість поширених у світі програм, включаючи комп'ютерні ігри.

 

.5.1 Філософія перед RISC-ової архітектури

В ранні часи комп'ютерної індустрії програми створювались на мові асемблера. Таке програмування вимагало потужних інструкцій, що реалізують часто вживані високорівневі алгоритми. Тому розробники процесорів намагались вмістити в свій продукт якомога більше інструкцій що виконують максимальну кількість роботи. Також до інструкцій ставились вимоги по зручності використання та універсальності. В кожній інструкції розробники намагались реалізувати всі можливі типи адресації, тобто інструкції могли однаково працювати з операндами, які знаходяться як в пам'яті так і в регістрах чи безпосередньо закодовані в інструкції. Реально введення такої універсальності призводило до того, що кожна дія мала декілька реалізацій в процесорі, розрахованих на різні типи адресування. Крім того, в ті часи, пам'ять була дуже дорогою, тому вигідними були інструкції зі змінною довжиною, що одночасно виконують завантаження операндів та обчислення. Також, процесори мали дуже малу кількість регістрів. Це було обумовлено двома причинами:

·    розміщення на кристалі додаткових регістрів було надто дорогим;

·        введення додаткових регістрів вимагало б розширення формату інструкції, щоб вмістити довші специфікатори регістрів.

На противагу RISC, таку архітектуру називають CISC (англ. Complex Instruction Set Computing)

 

.5.2 Філософія RISC архітектури

Ряд наукових досліджень середини 1970-х років довів, що тогочасні компілятори не використовували переваги складної адресації, а також те що більшість процесорів мали надлишковий набір інструкцій. Також було доведено, що в багатьох випадках складні інструкції виконувались повільніше ніж аналогічний по функціональності набір простіших інструкцій. Відомим прикладом цьому була інструкція INDEX комп'ютера VAX, яка виконувалась повільніше ніж її реалізація на базі циклу. Також, складні інструкції менше підлягали оптимізації під конкретну задачу (напр. заміна множення/ділення операціями зсуву). Метою створення RISC архітектури було:

·  Зменшення набору інструкцій для звільнення додаткової площі на кристалі, де можна розмістити кеш або регістри.

·        Приведення всіх інструкцій до однакового розміру та подібного формату. Це дало б можливість конвеєризації.

·        В ідеалі, всі інструкції повинні були виконуватись за один такт

 

.6 Proteus (система автоматизованого проектування)

VSM - пакет програм для автоматизованого проектування (САПР) електронних схем. Розробка компанії Labcenter Electronics (Великобританія).

 

.6.1 Oпис

Пакет являє собою систему схемотехнічного моделювання, що базується на основі моделей електронних компонентів прийнятих в PSpice. Відмінною рисою пакета PROTEUS VSM є можливість моделювання роботи програмованих пристроїв: мікроконтролерів, мікропроцесорів, DSP та ін. Бібліотека компонентів містить довідкові дані. Додатково в пакет PROTEUS VSM входить система проектування друкованих плат. Пакет Proteus складається з двох частин, двох підпрограм: ISIS - програма синтезу та моделювання безпосередньо електронних схем і ARES - програма розробки друкованих плат. Разом з програмою встановлюється набір демонстраційних проектів для ознайомлення.

Пакет є комерційним. Безкоштовна ознайомча версія характеризується повною функціональністю, але не має можливості збереження файлів.

Примітною особливістю є те, що в ARES можна побачити 3D-модель друкованої плати, що дозволяє розробнику оцінити свій пристрій ще на стадії розробки.

 

.7 AVR Studio

Studio - інтегрована середа розробки (IDE) для розробки 8-ми і 32-х бітних AVR додатків від компанії Atmel, що працює в операційних системах Windows NT/2000/XP/Vista/7. AVR Studio містить асемблер і симулятор, що дозволяє відстежити виконання програми. Поточна версія підтримує всі контролери AVR і засоби розробки, що випускаються на сьогоднішній день. AVR Studio містить в собі менеджер проектів, редактор вихідного коду, інструменти віртуальної симуляції і внутрішньосхемного налагодження, дозволяє писати програми на асемблері або на C / C + +.

 

.7.1 Історія

Раніше існував і фірмовий асемблер під Windows (wavrasm.exe) від Atmel, який поєднував асемблер і редактор, подібно тому, як це робиться в «великих» мовах програмування. Його можна отримати з перших версій AVR Studio, але він досить примітивний і незручний. Потім, мабуть, в корпорації вирішили його не розвивати, обмежившись AVR Studio. Завантажити AVR Studio можна абсолютно безкоштовно з сайту Atmel. Там же доступні і старі версії (на жаль, останні версії пакету стали досить об'ємними - більше 70 Мбайт), але тільки зверніть увагу, що, чим старіше версія, тим менше асортимент підтримуваних контролерів (так, версія 3 підтримує лише Classic).

2.7.2 Характеристики

Характеристики AVR Studio:

* Інтегрований Асемблер;

* Інтегрований симулятор;

* За допомогою плагіна можлива підтримка компілятора GCC у вигляді збірки WinAVR;

* Підтримка інструментів Atmel, сумісних з 8-розрядною AVR архітектурою, в тому числі AVR ONE!, JTAGICE mkI, JTAGICE mkII, AVR Dragon, AVRISP, AVR ISPmkII, AVR Butterfly, STK500 і STK600;

* Підтримка плагіна AVR RTOS;

* Підтримка AT90PWM1 і ATtiny40;

* Інтерфейс командного рядка з підтримкою TPI.

 

.8 HTML

(англ. HyperText Markup Language - Мова розмітки гіпертексту) - стандартна мова розмітки документів у Всесвітній павутині. Більшість веб-сторінок створюються за допомогою мови HTML (або XHTML). Документ HTML оброблюється браузером та відтворюється на екрані у звичному для людини вигляді.є похідною мовою від SGML, успадкувавши від неї визначення типу документу та ідеологію структурної розмітки тексту.разом із CSS та cкриптингом - це три основні технології побудови веб-сторінок.впроваджує засоби для:

·        створення структурованого документу шляхом позначення структурного складу тексту: заголовки, абзаци, списки, таблиці, цитати та інше;

·              отримання інформації із Всесвітньої мережі через гіперпосилання;

·              створення інтерактивних форм;

·              включення зображень, звуку, відео, та інших об'єктів до тексту.

2.8.1 Історія розвитку HTML

У 1980 році фізик Тім Бернерс-Лі, який на той час був співробітником CERN, запропонував і прототипував систему ENQUIRE, яка мала полегшити сумісне користування документами для дослідників CERN.

У 1989 році Бернерс-Лі запропонував впровадити на базі Internet гіпертекстову систему документів.

Вже наприкінці 1990 року він розробив HTML і написав браузер та серверне програмне забезпечення для запропонованої системи. У цьому ж році Тім Бернерс-Лі та Роберт Кайо, інженер інформаційних систем CERN, подали спільну заявку на фінансування проекту, проте цей проект не був офіційно прийнятий CERN.

Наприкінці 1991 року Тім Бернерс-Лі опублікував в Інтернеті перший загальнодоступний опис мови розмітки HTML, відомий як документ «HTML теги» (HTML Tags). В ньому були описані 20 елементів первісної, відносно простої схеми розмітки HTML. За винятком тегу гіперпосилання, який був жорстко підпорядкований внутрішньому SGML-формату документації CERN. Тринадцять із тих елементів ще й досі існують у HTML4.

Бернерс-Лі розглядав HTML як похідну мову від SGML, і в середині 1993 року Спеціальна Комісія Інтернет-розробок (IETF) офіційно визначила її такою, опублікувавши першу специфікацію HTML: «Hypertext Markup Language (HTML)» Internet-проект, авторами якої були Тім Бернерс-Лі та Ден Конолі. Ця специфікація вже містила визначення типу документу, яке чітко зазначало граматику HTML.

Проект втратив силу через 6 місяців, проте був відомий за офіційне визнання в ньому, створеного для браузера NCSA Mosaic, тега додавання зображень, не розділяючи філософію IETF щодо заснування стандартів на успішних прототипах. Так само пізніше в 1993 році в конкуруючому Інтернет-проекті Дейва Раджетта «HTML+ (Hypertext Markup Format)», було запропоновано стандартизувати вже запроваджені браузерами сенсаційні на той час можливості, такі як таблиці та перші інтерактивні форми.

На початку 1994 року, після того, як проекти «HTML» і «HTML+» втратили свою силу, IETF створив Робочу групу HTML (HTML Working Group). В 1995 році Робоча група HTML завершила роботу над документом «HTML 2.0» (опублікований як RFC із номером 1866), першою специфікацією, що мала бути використана як базовий стандарт для подальших вдосконалень HTML. Версія 2.0 окреслювала чіткі відмінності між новим виданням специфікації та попередніми проектами.

Подальші розробки під заступництвом IETF зіштовхнулися з конкуруючими інтересами. З 1996 року специфікації HTML затверджувались Консорціумом W3C, враховуючи доповнення до розмітки, що впроваджувалися компаніями-розробниками браузерів. Тим не менш, у 2000 році HTML стала міжнародним стандартом (ISO/IEC 15445:2000).

Остання специфікація HTML, опублікована W3C наприкінці 1999 року, має назву «HTML 4.01 Recommendation». Усі спірні питання та помилки цієї специфікації були офіційно визнані у списку друкарських помилок, опублікованому в 2001 році.

Версії

Тім Бернерс-Лі представив HTML в дослідницькому центрі CERN в Женеві в 1989 році.

·        HTML (без номера версії, 3 листопада 1992): Найперша версія, орієнтована лише на текст.

·              HTML (без номера версії, 30 квітня 1993): До тексту додаються атрибути, які визначають курсивне або жирне написання літер, та зображення.

·              HTML+ (листопад 1993) Заплановані доповнення, які потрапили до наступних версій, але ніколи не були відокремлені як HTML+.

·              HTML 2.0 (листопад 1995): Визначена стандартом RFC 1866 версія з підтримкою форм. Статус цього стандарту вже «Історичний», також визнані застарілими попередні версії.

·              HTML 3.0: Версія, яка не зазнала поширення, оскільки разом із випуском браузера Netscape Navigator версії 3, цей стандарт вже був застарілим.

·              HTML 3.2 (14 січня 1997): В цій версії були додані численні можливості, такі як таблиці, обтікання текстом зображень, інтеграція аплетів.

·              HTML 4.0 (18 грудня 1997): В цій версії були додані таблиці стилів, скрипти та фрейми. Також, відбулось розділення на Strict (суворе дотримання стандартів), Frameset (з підтримкою фреймів), Transitional (перехідний). 24 квітня 1998 було випущено виправлену версію цього стандарту.

·              HTML 4.01 (24 грудня 1999): Заміна версії HTML 4.0, містить численні дрібні виправлення.

·              HTML 5 (Working Draft, 5. April 2008): HTML 5 має новий словник побудований на основі HTML 4.01 та XHTML 1.0. Також перероблена і розширена пов'язана з HTML специфікація DOM

·              XHTML 1.0 (26 січня 2000): Висловлення стандарту HTML 4.01 засобами XML. 1 серпня 2002 було випущено оновлену редакцію стандарту.

·              XHTML 1.1 (31 травня 2001): Після того, як XHTML буде розділено на модулі, стандарт XHTML 1.1 визначатиме сувору версію, в якій не буде запроваджених HTML 4 можливостей Frameset та Transitional.

·              XHTML 2.0 (в розробці): Ця версія вже не базується на HTML 4.01 і додає деякі нові теги. Буде завершено розділення між представленням та вмістом.

 

.8.2 Документ HTML

Для поліпшення взаємодії, SGML вимагає аби кожна похідна мова (HTML у тому числі) визначала свою кодову таблицю для кожного документа, яка складається з репертуара (перелік різноманітних символів) та позиції символа (перелік цифрових посилань на символи з репертуара). Кожен документ HTML - це послідовність символів з репертуара.використовує найбільш повну кодову таблицю UCS (англ. Universal Character Set - Універсальний Набір Символів).

Проте, однієї кодової таблиці недостатньо для того, щоб браузери могли правильно відтворювати документи HTML. Для цього браузерам потрібно «знати» специфічну кодову таблицю документа, яку автор має зазначати завжди в елементі meta із параметром charset. За замовчуванням використовується кодова таблиця ISO-8859-1, відома також як Latin-1.

Розмітка

Розмітка в HTML складається з чотирьох основних компонентів: елементів (та їхніх атрибутів), базових типів даних, символьних мнемонік та декларації типу документа.

Загальна структура

Документ HTML 4.01 складається з трьох частин:

1.   Декларація типу документа (англ. Document type declaration, Doctype), на самому початку документа, в якій визначається тип документа (DTD).

2.      Шапка документа (знаходиться в межах елементу head), в якій записано загальні технічні відомості або додаткова інформація про документ, яка не відтворюється безпосередньо в браузері;

.        Тіло документа (може знаходитися в елементах body або frameset), в якому міститься основна інформація документа.

Декларація типу документа

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

·        HTML 4.01 Strict (Суворе DTD) підтримує всі елементи та атрибути, які не є такими, що не рекомендується застосовувати, або не входять до документу типу «Набір фреймів»(Frameset).

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"

·        HTML 4.01 Transitional (Перехідне DTD) підтримує все із суворого DTD плюс елементи та атрибути, що не рекомендується застосовувати (більшість із них складають візуальну розмітку)

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"

·    HTML 4.01 Frameset (Набір Фреймів DTD) підтримує все із перехідного DTD плюс самі фрейми.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"

URI в кожній з цих Декларацій типу документа дозволяє браузерам завантажити необхідні DTD-набори мнемонік. Останні дві літери в Декларації вказують на мову DTD. Для HTML це завжди англійська («EN»).

Декларація типу документу потрібна для проведення валідації документу згідно з оголошеним DTD. Кожне DTD містить в собі повну граматику HTML, яка зазначає дозволені та не дозволені елементи для документу цього типу.

Валідація

Так само як і кожна мова, будь-яка комп'ютерна мова має свою власну граматику, словник і синтаксис. І кожен документ, написаний цією мовою, має дотримуватися цих правил. HTML використовує машинно-зчитуючу граматику, яка називається DTD, механізм, успадкований від SGML.

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

Згідно з цією концепцією, «валідація HTML розмітки» визначається як процес перевірки веб-документа за правилами граматики (визначеними в DTD), на які він посилається із елементу doctype.

Один із важливих принципів програмування: «Будьте консервативні в тому, що ви робите; будьте ліберальним в тому, що ви приймаєте».

Браузери дотримуються другої частини цього принципу: вони приймають веб-документи такими, які вони є, та намагаються відтворити їх на екрані, навіть якщо вони не використовують стандартний HTML. Зазвичай це означає, що браузер спробує «здогадатися» про те, що автор документу мав на увазі. Проблема полягає в тому, що різні браузери (або навіть різні версії одного браузера) зроблять різні припущення щодо одних і тих же не стандартних конструкцій, і навіть гірше: якщо HTML-код дуже відрізняється від стандарту, браузер безнадійно заплутається і безладно відтворить сторінку на екрані, або навіть аварійно закриється.

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

Перегляд

Для перегляду HTML-розмітки документа можна використовувати будь-який текстовий редактор. Для перегляду документу, відтвореного за правилами HTML-розмітки, використовується браузер.

Транспортування в мережідокументи можуть бути транспортовані так само як і будь-які інші файли (наприклад, за допомогою протоколів FTP, TCP), проте, зазвичай вони транспортуються із сервера за допомогою протоколу HTTP, або по електронній пошті.

Всесвітня павутина складається в основному з HTML документів, переданих з веб-серверів для браузерів, використовуючи протокол HTTP. До того ж, HTTP використовується для передачі зображень, звуків, відео та іншого супутнього контенту. Для правильного відтворення документу браузером, окрім нього самого передається ще й інша інформація (метадані), у якій зазвичай міститься визначення MIME типу (наприклад, text/html або application/xhtml+xml) та кодової таблиці документа.

Електронна пошта

Більшість графічних поштових клієнтів дозволяють використовувати підмножину елементів HTML (часто визначених стандартом як застарілі та не рекомендовані у розмітці), щоб забезпечити візуальне форматування тексту, роблячи неможливим семантичну розмітку тексту засобами поштового клієнта. Багато таких клієнтів включають в себе WYSIWYG-редактор HTML для складання повідомлень. Використання HTML у повідомленнях електронної пошти є спірним питанням через проблеми з сумісністю у різних поштових клієнтів; також HTML може допомогти приховати фішинг.

 

.8.3 Поточні напрямки розвитку і використання HTML

З моменту свого створення, HTML і пов'язані з нею протоколи порівняно швидко отримали визнання. Однак, в перші роки існування цієї мови розмітки не було жодних чітких стандартів. Хоча її творці спочатку і задумували HTML як семантичну мову, позбавлену презентаційних можливостей, її практичне використання із різними браузерами призвело до додавання багатьох презентаційних елементів і атрибутів в HTML. Останні стандарти пов'язані з HTML відображають зусилля з подолання хаотичного розвитку мови і створення раціональної основи для розробки як змістовних, так і виразних документів. Щоб повернути HTML її роль семантичної мови, Консорціум Всесвітньої павутини розробив мови стилізування такі як Каскадні таблиці стилів та Розширена мова таблиць стилів, аби перенести на них відповідальність за вигляд документу. У зв'язку з цим, специфікація HTML повільно почала повертатися виключно до семантичних елементів.

Семантичний HTML

Семантичний HTML - спосіб написання HTML, що віддає перевагу підкресленню смислу закодованої інформації радше за її подання (зовнішній вигляд). Ще з самого початку свого розвитку HTML мав у складі елементи семантичної розмітки, проте також мав і елементи презентаційної розмітки такі як font, i та center. Також HTML має семантично-нейтральні елементи span та div. З кінця 1990-х, коли Каскадні таблиці стилів почали належно працювати в більшості браузерів, авторам документів було рекомендовано уникати використання презентаційної розмітки HTML з метою розділення представлення і змісту.

У 2001 році, в статті про Семантичну павутину, Тім Бернерс-Лі та інші навели приклади шляхів, за якими, одного дня, «агенти» інтелектуального програмного забезпечення зможуть автоматично прочесати Всесвітню мережу та відшукати, відфільтрувати та встановити співвідношення попередньо непов'язаних фактів на благо користувачів. Такі агенти є незвичайними навіть зараз, але деякі з ідей Web 2.0, мешапів та сервісів порівняння цін стають все ближчими до реалізації. Основна відмінність між цими гібридними веб-застосунками та семантичним агентом, який згадується у статті Бернерса-Лі, полягає в тому, що нинішні шляхи збирання та гібридизації інформації, як правило, створені веб-розробниками, які вже точно знають де шукати потрібну інформацію і яка в неї API-семантика.

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

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

Елементи презентаційної розмітки є забороненими в останніх чинних специфікаціях HTML і XHTML, а також і в проекті HTML 5.

Добрий семантичний HTML також покращує доступність веб-документів. Наприклад, коли браузер або аудіо-браузер може правильно встановити структуру документа, він не буде витрачати час користувачів з вадами зору, на прочитання повторюваної або неактуальної інформації, якщо вона була розмічена правильно.

Проект специфікації HTML 55 - це наступна значна переробка стандарту HTML. Робота над створенням специфікації, відома під назвою «Web Applications 1.0», розпочата WHATWG в червні 2004 року.5 спрямований на скорочення використання заснованих на плагінах, RIA-технологій, таких як Adobe Flash, Microsoft Silverlight і Sun JavaFX, хоча досягнення цієї мети займе багато років.

Специфікація HTML 5 зводиться до надання семантичного рівня мови розмітки і пов'язаних з ними семантичних рівнів API для сценаріїв задля авторизації доступних сторінок в Всесвітній павутині, починаючи від статичних документів і закінчуючи динамічними застосунками. HTML 5 вводить ряд нових елементів і атрибутів, які відображають типову архітектуру сучасних веб-сторінок. Деякі з них є семантичними замінами загально-використовуваних блочних (div) і вбудованих (span) елементів, наприклад елемент nav (навігаційного блок сторінки) і footer. Інші елементи, забезпечують нові функціональні можливості через стандартизований інтерфейс, наприклад елементи audio і video.

Наразі специфікація має статус: «у розробці», та, як очікується, матиме його ще протягом трьох років, хоча розробка частин HTML 5 буде завершена і реалізована в браузерах ще до того, як специфікація отримає остаточний статус Рекомендації W3C., ймовірно, найбільш успішна мова розмітки документів у всьому світі. Проте, коли світові представили XML, було вирішено створити нову версію HTML, похідну від XML. Адже з XML-заснованим HTML інші XML-мови могли би включати частини XHTML, а XHTML-документи могли б включати частини інших мов розмітки. Також автори веб-документів могли б скористатися перевагами редизайну задля очищення деяких з найбільш неохайних частини HTML, а також додати деякі з нових необхідних функцій, таких як покращені форми. Нижче зазначені деякі переваги використання XHTML замість HTML.

Якщо документ є лише чистим XHTML 1.0 (не включає інші мови розмітки), то різниця між XHTML та HTML майже не помітна. Проте, оскільки стають доступними все більше і більше XML-інструментів (наприклад, XSLT для перетворення документів), переваги використання XHTML стають все помітнішими. Наприклад, XForms дозволяє досить просто керувати редагуванням документів XHTML (або будь-яких інших видів документа XML). Семантичні веб-застосунки також зможуть скористатися документами XHTML за своїми потребами. Якщо документ більш ніж просто XHTML 1.0 (наприклад, у документі використовуються мови розмітки MathML, SMIL, або SVG), тоді переваги використання XHTML значно помітніші, адже HTML не підтримує такі комбінації мов розмітки в одному документі.

 

2.9 FreeBSD

- UNIX-подібна операційна система, коріння якої тягнеться від AT&T UNIX, через Berkeley Software Distribution (BSD) гілку операційних систем 386BSD та 4.4BSD. Працює на Intel x86 (IA-32), сумісних з ПК системах (включно з Microsoft Xbox, а також DEC Alpha, Sun UltraSPARC, Itanium (IA-64), AMD64, PowerPC та NEC PC-98 архітектурах. FreeBSD добре зарекомендувала себе як система для побудови інтранет- і інтернет-серверів. Вона надає достатньо надійні мережеві служби і ефективне управління пам’яттю.розробляється, як повноцінна операційна система. Ядро, драйвери пристроїв та базові користувацькі утиліти (так звані Userland), на кшталт командного процесору (shell) розробляються в єдиному дереві джерельних текстів. Це одна з головних відмінностей системи від Linux, у котрій робота над розробкою ядра ведеться однією групою програмістів, базових користувацьких утиліт іншою (на приклад, проектом GNU), а усі пакунки збираються третіми групами у так званий дистрибутив.

 

.9.1 Історія та розробка

Розробка FreeBSD почалася в 1993 році із набору патчів користувачів системи 386BSD, що швидко зростав. Цей набір пізніше виріс і відокремився від 386bsd в окрему операційну систему, що увібрала код від Free Software Foundation. Перша офіційна версія FreeBSD 1.0 вийшла у грудні 1993 року. Walnut Creek CDROM погодилася поширювати FreeBSD на компакт-диску і також надала для роботи проекту окремий комп’ютер з інтернет-з’єднанням. Керівництво до FreeBSD містить докладнішу історичну інформацію про походження системи.

Проте, в січні 1995 року з міркувань законності використання запозиченого у 386BSD коду, а також через судовий процес між Novell та Берклі, проект випустив спеціальну версію системи FreeBSD 2.0, де було переписано більшу частину її коду, чимало якого запозичено у 4.4BSD-Lite.3.0 приніс до проекту багато змін: перехід до двійкового формату ELF, з’явилася початкова підтримка SMP-систем і 64-розрядної архітектури Alpha. У свій час, гілка 3.х серйозно критикувалася, оскільки багато змін не були очевидно вигідними і мало впливали на роботу, однак, вона була необхідним кроком у розвитку проекту, котрий допоміг гілці 4.х стати дуже успішною.4 була дуже популярною серед інтернет-провайдерів і хостерів часів першого «міхура доткомів» і вважалася за одну з найстабільніших і високопродуктивних систем класу Unix. Одним з головних недоліків FreeBSD 4 вважається погана підтримка багатопроцесорних систем, особливо в режимі багатоточності. FreeBSD 4 поставила своєрідний рекорд за тривалістю розробки однієї гілки операційної системи - за п’ять років було усунено велику кількість помилок і отримана на рідкість стабільна система. В середині розробки FreeBSD 4 від неї відокремився проект Dragonflybsd, засновники якого поставили собі за мету серйозну оптимізацію ядра для високо-навантажених систем, зокрема кращу підтримку багатопроцесорності (зменшення часу, необхідного для перемикання ниток і ін.).

Модель розробки FreeBSD

Існує близько 4000 розробників, які працюють над системою на добровільній основі. Всі вони можуть читати дерево репозиторія, але не можуть вносити зміни. Замість цього розробник звертається до коммітера, який має право вносити зміну до коду. Існує близько 400 коммітерів. Розробник може вирости по соціальних сходах проекту і стати коммітером. Кандидатуру нового коммітера пропонує до розгляду ментор майбутнього коммітера. Залежно від основної області діяльності, новий коммітер затверджується основною командою, portmgr@ або docmgr@. Основна команда є адміністративним ядром проекту і складається з 9 чоловік, які вибираються на 2 роки коммітерами зі свого складу. Основна команда вирішує конфлікти між коммітерами.

Учасники проекту розробляють гілку CURRENT («поточна» версія) і декілька STABLE («стабільна», стабільність означає гарантію незмінності інтерфейсів, як API, ABI і так далі).

Новий код поміщають у гілку CURRENT, де він отримує ширше тестування. Нові функції, додані в CURRENT, можуть залишитися в системі або від них можуть відмовитися, якщо реалізація виявиться невдалою. Інколи ця версія може опинитися в непридатному для використання стані. З початком використання perforce як допоміжного репозиторія, і з виділенням projects/ області в svn, проект прагне гарантувати постійну працездатність CURRENT.версія містить тільки ті нововведення, які пройшли перевірку в CURRENT. Проте, ця версія теж призначена в основному для розробників. Не рекомендується оновлювати відповідальні робочі сервери до STABLE, заздалегідь її не протестувавши. На основі STABLE регулярно створюються ретельно протестовані розробниками, групою release-інженерів і ширшим довкола користувачів RELEASE-версії.

Після випуску релізів створюються додаткові гілки розробки для підтримки релізів, але в них вносяться лише найнеобхідніші зміни, що виправляють серйозні помилки або проблеми з безпекою системи. До четвертої версії FreeBSD у стабільної і поточної гілок був один і той же старший номер версії. Потім поточній гілці був привласнений номер 5, а у стабільної залишився номер 4.

Спочатку, FreeBSD використовувала в якості свого логотипу демона BSD, однак у 2005 році, був влаштований конкурс на створення нового логотипу. 8 жовтня 2005 змагання завершилися, і переміг у них Anton K. Gural, малюнок котрого став новим логотипом проекту. Однак, демон BSD залишається талісманом проекту FreeBSD.

Ліцензія

Як і споріднені з нею операційні системи, код FreeBSD розповсюджується під різними ліцензіями. Весь код ядра і весь новостворений код розповсюджується під ліцензією BSD, котра дозволяє будь-кому використовувати і розповсюджувати FreeBSD скільки їм заманеться.популярна завдяки своїй ліцензії, яка істотно відрізняється від широко відомої ліцензії GNU GPL - вона дозволяє використовувати код не лише в вільному ПЗ, але і в пропрієтарному. На відміну від GNU LGPL, яка теж дозволяє використовувати вільний код в закритій програмі, ліцензія BSD простіша і коротша.

Частина коду утиліт розповсюджується за ліцензіями GPL, LGPL, ISC, CDDL та Beerware.

Деякий код доступний лише у двійковому вигляді, на кшталт шару абстрагування апаратних засобів (HAL) драйверів для бездротових пристроїв Atheros та утиліт для Adaptec AAC RAID (поставляється у вигляді пакету).

Сумісність з Linuxзабезпечує сумісність з деякими іншими UNIX-подібними операційними системами, зокрема, з Лінукс. Шар сумісності надає можливість працювати з програмним забезпеченням для Лінукс, котре розповсюджується лише у двійковому форматі, і не може бути портовано на FreeBSD.має два можливих варіанти сумісності: для користувачів та для розробників. Варіант для користувачів має назву, що починається linux_base а для розробників - linux_dist. Обидва варіанти можна встановити із портів, розділ emulators (емулятори).

 

2.9.2 Відгалуження

·    DragonFlyBSD - відгалуження від FreeBSD 4.8. Вона має систему потокової обробки повідомлень, схожу на ту, що застосовується в системах із мікроядром.

·              FreeNAS - дистрибутив на базі мінімального FreeBSD, орієнтований для створення NAS-систем

·              Frenzy - LiveCD-дистрибутив на базі FreeBSD, орієнтований на україномовних та російськомовних системних адміністраторів.

·              FreeSBIE - LiveCD-дистрибутив FreeBSD.

·              BSDeviant - також LiveCD-дистрибутив FreeBSD.

·              PicoBSD - мініатюрна версія FreeBSD, відгалуження від другої вітки, в наш час не розвивається.

·              Darwin - ядро Mac OS X, чимало запозичило у FreeBSD, розробляється фірмою Apple.

·              PC-BSD - дистрибутив із графічним інсталятором, орієнтований на настільні системи.

·              DesktopBSD - дистрибутив для настільних систем.

·              TrueBSD - дистрибутив для настільних систем.

·              RoFreeSBIE - румунський дистрибутив для настільних систем.

 

.9.3 Варіанти установки

Операційна система FreeBSD може бути встановлена з різних носіїв, таких як:

·    dvd-rom;

·              CD-ROM;

·              USB флеш-накопичувач;

·              дискета;

·              магнітна стрічка;

·              FAT-розділ жорсткого диска;

·              віддалений сервер (по протоколу FTP або nfs).

 

.9.4 Порти і пакети

В даний час FreeBSD надає користувачеві дві взаємодоповнюючі технології установки програмного забезпечення сторонніх розробників: колекція портів FreeBSD і бінарні пакети з програмним забезпеченням.

Будь-яка з цих систем може бути використана для установки найостанніших версій додатків з локальних носіїв або прямо з мережі. Тепер колекція портів налічує понад 22 тис. додатків самого різного призначення.

 

.9.5 Талісмани-логотипи

Основним талісманом системи є червоне чортеня, відомий також як beastie. Окрім нього, за талісман також вважається Devilette, дівчина в червоному костюмі демона.

 

.10 Мова програмування С++

 

.10.1 Виникнення і еволюція мови C + +

Бьерн Страуструп є розробником мови С + + і творцем першого транслятора. Він - співробітник науково-дослідного обчислювального центру AT & T Bell Laboratories в Мюррей Хілл (Нью-Джерсі, США). Він отримав звання магістра математики та обчислювальної техніки в університеті м. Аарус (Данія), а лікарське звання з обчислювальної техніки в Кембриджського університету (Англія). Він спеціалізується в галузі розподілених систем, операційних систем, моделювання та програмування. Разом з М. А. Елліс він є автором повного керівництва по мові С + + - "Керівництво по С + + з примітками".

Безумовно С + + багатьом зобов'язаний мові С, який зберігається як його підмножина. Збережено і усі властиві З засоби низького рівня, призначені для вирішення найбільш нагальних завдань системного програмування. С, у свою чергу, багато чим зобов'язаний своєму попередникові мови BCPL. Коментар мови BCPL був відновлений в С + +. Ще одним джерелом натхнення була мова SIMULA-67; саме з нього була запозичена концепція класів (разом c похідними класами і віртуальними функціями). Можливість в С + + перевантаження операцій і свобода розміщення описів скрізь, де може зустрічатися оператор, нагадують мову Алгол-68.

Більш ранні версії мови, що отримали назву "С з класами", використовувалися, починаючи з 1980 р. Ця мова виникла тому, що автору потрібно написати програми моделювання, керовані перериваннями. Мова SIMULA-67 ідеально підходить для цього, якщо не враховувати ефективність. Мова "С з класами" використовувався для великих завдань моделювання. Суворій перевірці піддалися тоді можливості написання на ньому програм, для яких критичні ресурси часу і пам'яті. У цій мові бракувало перевантаження операцій, посилань, віртуальних функцій і багатьох інших можливостей. Вперше С + + вийшов за межі дослідницької групи, в якій працював автор, в липні 1983 р., однак тоді багато можливості С + + ще не були розроблені.

Назва С + + (Сі плюс плюс), було придумано Ріком Маскітті влітку 1983 р. Ця назва відображає еволюційний характер змін мови С. Позначення + + відноситься до операції нарощування С. Трохи більш короткий ім'я С + є синтаксичної помилкою. Крім того, воно вже було використано як назва зовсім іншої мови. Знавці семантики С знаходять, що С + + гірше, ніж + + С. Мова не отримав назви D, оскільки він є розширенням С, і в ньому не робиться спроб вирішити будь-які проблеми за рахунок відмови від можливостей С.

Спочатку С + + був задуманий для того, щоб авторові та його друзям не треба було програмувати на асемблері, С або інших сучасних мовах високого рівня. Основне його призначення - спростити і зробити більш приємним процес програмування для окремого програміста. До недавнього часу не було плану розробки С + + на папері. Проектування, реалізація та документування йшли паралельно. Ніколи не існувало "проекту С + +" або "Комітету з розробки С + +". Тому мова розвивалася і продовжує розвиватися так, щоб подолати всі проблеми, з якими зіткнулися користувачі. Поштовхами до розвитку служать також і обговорення автором всіх проблем з його друзями та колегами.

З моменту виходу в світ першого видання цієї книги мову С + + піддався істотним змінам і уточненням. В основному це стосується вирішення неоднозначності при перевантаженні, зв'язуванні та управлінні пам'яттю. Разом з тим, були внесені незначні зміни з метою збільшити сумісність з мовою С. Були також введені деякі узагальнення і суттєві розширення, як то: множинне успадкування, функції-члени зі специфікаціями static і const, захищені члени (protected), шаблони типу і обробка особливих ситуацій. Всі ці розширення та доопрацювання були націлені на те, щоб С + + стала мовою, на якому можна створювати і використовувати бібліотеки.

Інші розширення, введені за період між 1985 і 1991 р.р. (Такі як множинне спадкування, статичні функції-члени і чисті віртуальні функції), швидше за з'явилися в результаті узагальнення досвіду програмування на С + +, ніж були почерпнуті з інших мов.

Зроблені за ці шість років розширення мови насамперед були спрямовані на підвищення виразності С + + як мови абстракції даних і об'єктно-орієнтованого програмування взагалі і як засобу для створення високоякісних бібліотек з користувача типами даних зокрема.

Приблизно в 1987 р. стало очевидно, що робота зі стандартизації С + + неминуча і що слід негайно приступити до створення основи для неї.
Фірма AT & T Bell Laboratories внесла основний внесок в цю роботу. Близько ста представників з порядка 20 організацій вивчали й коментували те, що стало сучасною версією довідкового керівництва і вихідними матеріалами для ANSI по стандартизації. С + +.

Нарешті, з ініціативи фірми Hewlett-Packard в грудні 1989 р. у складі ANSI був утворений комітет X3J16. Очікується, що роботи зі стандартизації С + + в ANSI (американський стандарт) стануть складовою частиною робіт по стандартизації силами ISO (Міжнародної організації зі стандартизації).

С + + розвивався одночасно з розвитком деяких фундаментальних класів.

 

.10.2 Зауваження щодо проекту мови

При розробці мови С + + одним з найважливіших критеріїв вибору була простота. Коли виникало питання, що спростити: посібник з мови та іншу документацію або транслятор, - то вибір робили на користь першого. Величезне значення надавалося сумісності з мовою С, що завадило видалити його синтаксис.

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

З мови виключалися можливості, які можуть призвести до накладних витрат пам'яті або часу виконання, навіть якщо вони безпосередньо не використовуються у програмі. Наприклад, було відкинуто пропозицію зберігати в кожному об'єкті деяку службову інформацію. Якщо користувач описав структуру, що містить дві величини, що займають по 16 розрядів, то гарантується, що вона поміститься в 32-х розрядний регістр.

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

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

 

.10.3 Порівняння мов С + + і С

Вибір С в якості базової мови для С + + пояснюється наступними його перевагами[13]:

(1) універсальність, стислість і відносно низький рівень;

(2) адекватність більшості завдань системного програмування;

(3) він іде в будь-якій системі і на будь-якій машині;

(4) повністю підходить для програмного середовища UNIX.

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

С + + став використовуватися ширше, але у міру зростання його можливостей, що виходять за межі С, знову і знову виникала проблема сумісності. Ясно, що відмовившись від частини спадщини З, можна уникнути деяких проблем. Це не було зроблено з наступних причин:

·    Існують мільйони рядків програм на С, які можна поліпшити за допомогою С + +, але за умови, що повної переписом їх на мову С + + не потрібно;

·        Існують мільйони рядків бібліотечних функцій та службових програм на С, які можна було б використовувати в С + + за умов сумісності обох мов на стадії зв'язування і їх великої синтаксичного подібності;

·    Існують сотні тисяч програмістів, які знають С; їм достатньо опанувати тільки новими засобами С + + і не треба вивчати основ мови;

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

Опис С + + було перероблено так, щоб гарантувати, що будь-яка допустима в обох мовах конструкція означала в них одне і те ж. Як мова, так і стандартні бібліотеки С + + проектувалися в розрахунку на переносимість. Наявні реалізації мови будуть працювати в більшості систем, що підтримують С. У програмах на С + + можна використовувати бібліотеки С. Більшість службових програм, розрахованих на С, можна використовувати і в С + +.

Мова С сама розвивалася в останні кілька років, що частково було пов'язане з розробкою С + +. Стандарт ANSI для С містить, наприклад, синтаксис опису функцій, запозичений з мови "С з класами". Відбувається взаємне запозичення, наприклад, тип покажчика void * був придуманий для ANSI З, а вперше реалізований в С + +. Опис С + + було доопрацьовано, щоб виключити невиправдані розбіжності. Тепер С + + більш сумісний з мовою С, ніж це було. В ідеалі С + + повинен максимально наближатися до ANSI C, але не більше. Стовідсоткової сумісності ніколи не було і не буде, оскільки це порушить надійність типів і узгодженість використання вбудованих і призначених для користувача типів, а ці властивості завжди були одними з головних для С + +.

Для вивчення С + + не обов'язково знати С. Програмування на С сприяє засвоєнню прийомів і навіть трюків, які при програмуванні на С + + стають просто непотрібними. Наприклад, явне перетворення типу (приведення), в С + + потрібно набагато рідше, ніж в С (див. "Зауваження для програмістів на С" нижче). Тим не менш, гарні програми на мові С по суті є програмами на С + +. Наприклад, всі програми з класичного опису є програмами на С + +. У процесі вивчення С + + буде корисний досвід роботи з будь-якою мовою зі статичними типами.

Зауваження для програмістів на С

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

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

 

.10.4 Ефективність та структура

Розвиток мови С + + відбувалося на базі мови С, і, за невеликим винятком, С був збережений як підмножини C + +. Базова мова С був спроектований таким чином, що є дуже тісний зв'язок між типами, операціями, операторами та об'єктами, з якими безпосередньо працює машина, тобто числами, символами та адресами. За винятком операцій new, delete і throw, а також перевіряється блоку, для виконання операторів і виразів С + + не потрібно прихованої динамічної апаратної або програмної підтримки.

Спочатку мова С замислювався як конкурент асемблера, здатний витіснити його з основних і найбільш вимогливих до ресурсів задач системного програмування. У проекті С + + було вжито заходів, щоб успіхи С в цій області не опинилися під загрозою. Різниця між двома мовами раніше все складається в ступені уваги, що приділяється типам і структурам. Мова С виразний і в той же час поблажливий по відношенню до типів. Мова С + + ще більш виразна, але такої виразності можна досягти лише тоді, коли типам приділяють велику увагу. Коли типи об'єктів відомі, транслятор правильно розпізнає такі вирази, в яких інакше програмісту довелося б записувати операції з втомливими подробицями. Крім того, знання типів дозволяє транслятору виявляти такі помилки, які в іншому випадку були б виявлені тільки при тестуванні. Відзначимо, що саме по собі використання суворої типізації мови для контролю параметрів функції, захисту даних від незаконного доступу, визначення нових типів і операцій не вабить додаткових витрат пам'яті та збільшення часу виконання програми.

У проекті С + + особлива увага приділяється структуруванню програми. Це викликано збільшенням розмірів програм з часу появи С. Невелику програму (скажімо, не більше 1000 рядків) можна змусити з упертості працювати, порушуючи всі правила хорошого стилю програмування. Однак, діючи так, людина вже не зможе впоратися з великою програмою. Якщо у вашої програми в 10 000 рядків погана структура, то ви виявите, що нові помилки з'являються в ній так само швидко, як видаляються старі. С + + створювався з метою, щоб велику програму можна було структурувати таким чином, щоб одній людині не довелося працювати з текстом в 25000 рядків. В даний час можна вважати, що ця мета повністю досягнута.

Існують, звичайно, програми ще більшого розміру. Однак ті з них, які дійсно використовуються, зазвичай можна розбити на кілька практично незалежних частин, кожна з яких має значно менший згаданого розмір. Природно, труднощі написання та супроводу програми визначається не тільки числом рядків тексту, але й складністю предметної області. Так що наведені тут числа, якими обгрунтовувалися наші міркування, не треба сприймати надто серйозно.

На жаль, не всяку частина програми можна добре структурувати, зробити незалежною від апаратури, досить зрозумілою і т.д. У С + + є засоби, які безпосередньо й ефективно представляють апаратні можливості. Їх використання дозволяє позбутися від занепокоєння про надійність і простоті розуміння програми. Такі частини програми можна приховувати, надаючи надійний і простий інтерфейс з ними.

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

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

 

.11 Мова Асемблер

Асе́мблер (англ. assembler) - загальноприйнята назва транслятора з автокоду[15]. Асемблер переводить початкову програму, написану на автокоді, в переміщувану програму на мові машинній. Оскільки асемблер здійснює трансляцію на мову завантажувача, при завантаженні програми необхідна налаштування умовних адрес, тобто адрес, значення яких залежать від розташування даної програми в пам'яті ЦВМ і від її зв'язків з іншими незалежно трансльованими програмами.

У простому випадку асемблер переводить одне речення початкової програми в один об'єкт (команду, константу) модуля завантаження (т. з. трансляція «один в один»). При цьому взаємне розташування об'єктів в модулі завантаження і, зрештою, в пам'яті машини визначається порядком пропозицій в початковій програмі на автокоді і повністю залежить від програміста. Асемблер виконує і допоміжні функції, такі, як підготовка до друку документів необхідної форми, реєстрація зв'язків даної програми з іншими програмами і т. д. Для цієї мети в автокодах передбачаються команди асемблера, які не породжують об'єктів в робочій програмі і призначені тільки для вказівки допоміжних дій асемблера.

Трансляція зазвичай вимагає двох переглядів початкової програми: при першому перегляді здійснюється розподіл пам'яті і надання значень символічним іменам; при другому - формується робоча програма у вигляді модуля завантаження. В процесі трансляції асемблер проводить повний синтаксичний контроль початкової програми (див. синтаксичний аналіз програм), забезпечуючи при цьому достатньо точну діагностику помилок за місцем і характером.

Розширення можливостей автокодів досягається за рахунок використання макрокоманд, що будуються за правилами, близькими до правил написання команд автокоду, але що описують складніші функції, для реалізації яких потрібна група звичайних команд. В цьому випадку перед трансляцією проводиться заміна макрокоманд макророзширеннями - послідовностями команд на базовій мові відповідно до макроозначень. У останніх задається прототип макрокоманди із структурою списку параметрів і процедура генерування макророзширення. Транслятор, що виконує функції макрогенератора і асемблера, називається макроасемблером. При трансляції з мов високого рівня асемблер нерідко використовується для виконання завершальної фази трансляції.

Асемблер (assembler) - система програмування, яка включає мову асемблера та транслятор з цієї мови. Є мовою програмування низького рівня. Чим нижчий рівень мови програмування, тим ближча специфіка роботи програми до самого процесора, для якого вона й була написана. Вважається, що мови низького рівня складніші й потребують більш вузької спеціалізації програміста, оскільки програма написана на асемблері для одного типу процесорів виявиться не завжди придатною для роботи з іншими процесорами. З іншого боку програми написані на асемблері компактні та швидкі, що теж є немаловажливим.

Поки існують процесори, буде існувати й асемблер.

 

Висновки до розділу 2

У розділі були розглянуті засоби та мови програмування для створення власної системи керування роботою маніпулятора через веб-інтерфейс, розглянуті їх переваги та недоліки, а також платформа реалізації проекту.

Розділ 3. Практична реалізація проекту

Маніпулятор було збудовано на базі мікроконтролера AVR ATMega32 виробництва Atmel. Моделювання схеми проводилось у програмі Proteus Portable 7.4. Програма для мікроконтролера була створена у AVRStudio 5.0. Детальніше про ці програмні продукти можна дізнатися у розділі 2. Функції маніпулятора:

-   Можливість повороту на 360 градусів навколо вертикальної осі;

-        Кут нахилу „стріли” маніпулятора - 130 градусів;

         Можливість обертання схвату навколо своєї осі;

         Електромагнітний підпружинений схват;

         Можливість безпосередньо спостерігати за своїми діями реалізована за допомогою веб-камери і бібліотеки комп’ютерного зору OpenCV.

 

.1 Апаратна реалізація

В якості рушійної сили були використані двигуни ДПР-42-Н1-03, а також мікросхема-драйвер двигуна L293D. Керуюча схема збиралась на стандартній двошаровій текстолітній платі з мідним покриттям. Травка плати виконувалась за допомогою хлорного заліза. Розмітка наносилась на заготовку лазерно-прасковим методом.

 

.1.1 Розробка схеми

Схема прототипа була розроблена в програмному комплексі Proteus Portable 7.4. Спочатку, за допомогою програми ISIS було побудовано, перевірено і протестовано макет схеми (Рис. 3.1.)

Рис. 3.1 Макет схеми маніпулятора

Далі, за допомогою програми ARES, елементи було скомпоновано, розведені доріжки та роздруковано шаблон для лазерно-праскового методу перенесення на текстолітову основу (Рис. 3.2, 3.3, 3.4).

Рис. 3.2 Схема з розведеними доріжками

Рис. 3.3 Верхній шар плати

Рис. 3.4 Нижній шар плати

 

.1.2 Лазерно-прасковий метод

На даний момент існує декілька технологій виготовлення друкованих плат в домашніх умовах. Починаючи від ручного виведення малюнка доріжок до "просунутого" - перекладу малюнка плати, надрукованого на лазерному принтері. Зупинимося на останньому способі, як на тому, що потенційно має деякі перспективи. Технологія виготовлення друкованих плат на лазерному принтері складається з наступних етапів:

Ставимо сітку 2,54 мм (0,1 дюйма) - це крок між ногами мікросхем і цілком вистачає на більшість деталей (якщо розміщувати резистори і діоди стоячи). Малювати зручніше з боку деталей, при цьому схема виходить більш наочною, а при друку зображення доріжок не треба перевертати. Зручно зробити окремі шари для друкованих провідників і для зображення деталей (можна включити / виключити при перегляді і друку). Доріжки малюються лінією 2pt, площадки під виводи кільцями 0,7 / 1,5-2,0 мм, під дроти 1,25 / 2,5-3,0 мм (внутрішній / зовнішній діаметр). Після остаточної компоновки деталей і розводки плати зручно обвести її по контуру з припуском 0,5-1 мм лінією 1pt на шарі провідників, для обрізки (особливо актуально для плат із складним контуром). Також позначаємо на шарі провідників отвори для кріплення і інші технологічні мітки.

Увага: перед тим, як щось робити далі, обов'язково двічі перевірте розведення провідників (особливо, якщо робили не в спеціалізованій програмі, а в графічному редакторі) і чи потрібно віддзеркалити зображення перед друком. Загальне правило таке: якщо на малюнку друковані провідники (неважливо якого шару) видно зі свого боку плати, перед друком зображення ПОТРІБНО віддзеркалити (неважливо, від горизонталі або вертикалі, головне один раз). Якщо ж провідники видно «крізь плату» (наприклад, малюємо провідники зі зворотного боку плати, а дивимося з боку деталей), то віддзеркалювати малюнок НЕ ПОТРІБНО. Якщо сумніваєтеся, роздрукуйте зображення кожного шару (це, до речі, рекомендується робити і для перевірки розводки) і прикиньте необхідність віддзеркалення "наживо". Тільки пам'ятайте, що один раз зображення віддзеркалиться при перенесенні з паперу на текстоліт.

Етап 2. З склотекстоліту вирізається заготовка плати з припуском не менше 5 мм. Потім сторону, на якій будуть провідники, ретельно зашліфовуємо "нульовкою", поки вся поверхня не покриється дрібними подряпинами, придбавши золотистий колір неокисленої міді. Після цього знежирюємо всю поверхню спиртом і даємо останньому повністю випаруватися. Самі ж в цей час переходимо до наступного кроку.

Етап 3. Береться лазерний принтер і друкується малюнок доріжок на дуже тонкому крейдованому папері. При друку не забудьте залишити краї приблизно в половину відповідного розміру плати (зліва і справа - половину ширини, зверху і знизу - висоти). Я використовую Samsung SCX 3200 з максимальною "чорнотою" (відключити економний режим, максимальна насиченість) і папір з журналів "Кореспондент". У нього крім дуже маленької товщини є особливість застрягати в принтері перед пічкою, тому після витягування аркуша ми отримуємо незакріплене зображення. Але якщо Ваш папір пічку пройшов, має вийти не гірше. Хоча якщо робити плати доводиться часто, може є сенс зробити можливість відключення печі у вашого принтера.

Етап 4. Отриману роздруківку кладемо на стіл зображенням вгору. Готуємо смужки скотчу шириною сантиметр-два і довжиною в залежності від розмірів плати. Накладаємо заготовку плати на папір підготовленою стороною до зображення і загортаємо краї паперу, фіксуючи папір приготованими смужками скотчу. Папір повинен бути трохи натягнутим, щоб плата не могла зміститися всередині отриманої обгортки. Після цього загортаємо весь "бутерброд" ще одним аркушем звичайного паперу (в один шар). Тепер береться звичайна праска, увімкнена на максимальну температуру і ставиться на загорнуту в папір плату з боку малюнка. Плата прогрівається 20-30 сек. під власною вагою праски, після чого праска кілька разів з натиском проводиться по поверхні плати. Для маленьких плат і незакріпленого зображення досить 4-6 разів з не дуже сильним натиском (не всією вагою). При сильному натиску тонер може поповзти і сусідні доріжки злипнуться, при слабкому - не приклеїтися.

Етап 5. Після охолодження знімаємо зовнішній папір і зрізаємо папір із зворотного боку плати. Потім кидаємо плату з папером що прилип в гарячу (градусів 40-50, тобто терпимо гаряча на дотик) воду і чекаємо, поки папір не розмокне. Коли це станеться, папір можна буде відокремити від плати, а тонер залишиться, надійно припеченний до плати (пальцем не отскребешь). Пальцем під водою скочуємо залишки паперу. Плата сушиться (без додаткового підігріву, щоб тонер не почав відходити), після чого озброюємося лупою і проглядаємо дефекти. Можна охайно промокнути плату туалетним папером, щоб прискорити процес сушіння. При правильно виконаних попередніх кроках дефект що зустрічається найбільш часто - не до кінця видалений папір, що при травленні може призвести до замикання провідників. Папір видаляємо гострим предметом: шилом, голкою, кінчиком ножа. При зворотній проблемі - відсутності провідників там, де вони повинні бути, можна підправити малюнок лаком або незмивним маркером (потрібно заздалегідь випробувати маркер щоб переконатися в його стійкості).

Етап 6. Травимо плату в хлорному залізі. Розчин краще підігріти до тих же 40-50 градусів, правда він все одно охолоджується швидше, ніж травиться плата. Основна проблема при травленні - плата повинна лежати малюнком вниз (щоб продукти реакції опускалися на дно, а не лежали на платі), але при цьому потрібно забезпечити доступ розчину. Я вирішую цю проблему приклеюванням до країв (той самий припуск) сірників, а якщо плата більша можна просвердлити отвори і вставити в них пластикові (не металеві!) стійки для материнських плат. Або ті ж сірники. Після того, як малюнок повністю протравиться, плату виймають, заклеюють сторону з малюнком скотчем, щоб уникнути подальшого подтравливания доріжок, після чого перевертають і стравлюють фольгу з боку деталей. Можна травити плати і у вертикальному положенні, наприклад у вузькому стакані, тоді описаних труднощів можна уникнути, але важче забезпечити рівномірність травлення.

Етап 7. Змиваємо тонер, наприклад, уайт-спіритом, потім свердлимо отвори, вирізаємо плату по необхідному контуру, покриваємо каніфольним лаком, залужуємо контактні майданчики. Далі монтаж деталей.

 

.1.3 Монтаж пристрою

Монтаж елементів на плату проводився за допомогою паяльного пристрою ЕПСН 40/220, флюса F3, припою ПОС 61 та рідини для змивання залишків каніфолі на нейтральній основі.

В якості джерела живлення використовується комп’ютерний блок живлення Codegen 200W (220В, 200Вт), живлення підводиться через стандартний молекс-роз’єм. (J3 на схемі). Обмін даними проводиться за допомогою LPT-під’єднання (J1). Роз’єм J2 служить для підімкнення двигунів та електромагнітного хвата.

Після нанесення доріжок на плату, за допомогою дрилі були просвердлені отвори під ніжки мікросхем та коннекторів. Далі елементи було припаяно і протестовано мультиметром, щоб переконатись у відсутності коротких замикань (КЗ). Таких не знайшлось. Під мікроконтроллер я встановив колодку, щоб можна було його зняти у будь-який момент, не випаюючи. Це зручно, якщо апарат працює в тестовому режимі - можна переставити контролер у програматор, або замінити його у випадку виходу з ладу.

Корпус маніпулятора був створений з пластику - це легше й дешевше ніж металевий, до того ж, даний вид маніпулятора не розрахований на велику вантажопідйомність. На двигуни встановлені редуктори, які, крім того, що збільшують їх (двигунів) потужність, добряче зменшують кількість обертів за секунду (до одного). Це корисно для контролю за пересуванням - адже дана модель двигуна не обладнана зворотним зв’язком. Схват - електромагнітний, трипелюстковий, підпружинений. У спокійному стані - розімкнений пружинами, при подачі напруги стискується магнітом до тих пір, поки не отримає „відпускаючого” сигналу. Електродвигунів всього три. Один обертає безпосередньо сам хват, другий пересуває „плече” маніпулятора по вертикалі, третій обертає маніпулятор по горизонталі відносно землі. Другий і третій двигуни сховані під кожухом в основі пристрою. Підйом „плеча” виконується за допомогою пари „шків-тросик”. Схват також стискується за допомогою тросиків, прикріплених до рухомої частини електромагніта, котрий знаходиться в основі пристрою. Також до стойки маніпулятора прикріплена веб-камера, котра передає зображення на сторінку керування, тож оператор може спостерігати за своїми діями.

 

3.2 Програмна частина

 

.2.1 Програма мікроконтроллера

Мікроконтроллер програмувався мовою С за допомогою AVR Studio i CVAVR.

При прийомі значення (логічної одиниці) на одну з ніжок порта D, встановленого на прийом, контролер дає команду на увімкнення драйвера двигуна і обертання останнього в одну або іншу сторону (залежачи від ніжки, на яку прийшов сигнал), або на стискування/відпускання хвату. Команди приймаються з LPT-порта, яким керує С-програма.

 

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

Програма-посередник між користувацьким інтерфейсом і маніпулятором також написана мовою С. Вона приймає параметри, які передає користувач і транслює їх до процесора маніпулятора. Параметри, що передаються:

·    Кут повороту ліворуч/праворуч;

·        Кут підйому вгору/вниз;

·        Кут обертання схвату;

·        Схватити/відпустити;

Кути вираховуються за допомогою затримки, впродовж якої до маніпулятора надходить той чи інший сигнал. Знаючи швидкість обертання двигуна і час, на який встановлена затримка, можна без зусиль вирахувати, на який кут повернеться/підніметься та чи інша ланка маніпулятора. Програму створено за допомогою GNU C Compiler (GCC), що входить до складу ОС FreeBSD.

 

3.2.3 Користувацький веб-інтерфейс

Інтерфейс користувача написаний мовами програмування PHP i HTML. Користувач заходить на сервер і бачить панель керування маніпулятором, а також вікно, в котре передається відео потік з веб-камери.

ВИСНОВКИ

Автоматизація майже всіх галузей нашого життя стрімко набирає оберти, через деякий час важко буде уявити собі життя без роботів. Вони будуть зустрічатись повсюди - вдома, на роботі, просто на вулицях. Функціональні завдання, які можна доручити машинам - необмежені, тому вже зараз треба розробляти гнучкі та зручні в користуванні машини, котрі полегшать нам життя. Головним результатом магістерської роботи є спроектована і реалізована система керування роботизованим маніпулятором через веб-інтерфейс. Основні результати роботи:

·  Сформульовано вимоги до розробки власної моделі маніпулятора та системи керування;

·        Досліджено сучасні технологіі, методи та засоби автоматизації та керування;

·        Спроектовано і реалізовано власну модель роботизованого маніпулятора та систему керування.

При реалізації проекту було використано:

·  Для проектування прототипу - засоби AVR Studio, Proteus 7.4;

·        Для реалізації системи керування - мови PHP, HTML, C, Assembler;

·        В якості платформи для системи керування - ОС FreeBSD, веб-сервер Apache 2.2;

·        В якості головного процесора маніпулятора - мікроконтроллер AVR ATMega32;

·        Підключення маніпулятора до комп’ютера здійснюється за допомогою паралельного порта (LPT);

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

Список використаних джерел

1.     Енциклопедія кібернетики в 2 т. / За ред. В. М. Глушкова. - Київ: Головна редакція Української радянської енциклопедії, 1973.;

2.      http://www.labcenter.com/index.cfm;

.        AVR RISC microcontrollers handbook By Claus Kühnel, ISBN 0-7506-9996-9, глава «4.2 ATMEL AVR Studio AVR Studio», стр 144-146;

.        http://www.html.net/tutorials/html/introduction.asp;

.        http://www.freebsd.org/;

.        Christopher Negus, Francois Caen, BSD UNIX Toolbox: 1000+ Commands for FREEBSD, OPENBSD and NETBSD, Wiley, May 5 2008, 309 стор., ISBN 0-470-37603-1.

.        http://httpd.apache.org/

.        http://www.php.net/manual/en/index.php

.        http://www.gaw.ru/html.cgi/txt/ic/Atmel/micros/avr/atmega32.htm

.        http://avr123.nm.ru/

.        http://locv.ru/wiki/%D0%9E%D0%B3%D0%BB%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5

.        www.opensource.org

.        Керниган, Ричи. Язык C;

.        Таненбаум Архітектура комп’ютера;

.        Рудаков П.И., Финогенов К.Г. Язык ассемблера - уроки программирования -М.:ДИАЛОГ-МИФИ, 2001.-640 с.