Привет! Има ли напредък по проекта?
Преди време и аз имах такъв проект в главата, но като ни натовариха в университета, трябваше да се замързи.
Аз се бях спрял да използвам Raspberry Pi. На него върви Debian(или тяхното Rasbian + може и Arch Linux, има избор), като има достатъчно GPIO-та, I2C, SPI, 2*USB, etc. Не е необходимо да се използват стъпкови мотори, с обикновенни DC ти е практически необходимо няколко транзистора (аз се бях спрял на вече разработените платки от yasko [надявам се темата да не е затрупана], просто защото имах налични). И в двата варианта може да ги управляваш чрез ШИМ, като си имаш отделна нишка в процесора, която се грижи да генерира точни импулси върху изведените GPIO пинове. Относно ротирането на камерата, щях да използвам серва, които отново ще минат по същата процедура.
https://github.com/23pointsNorth/tsrp Тук бях започнал да пиша, но така и не се стигна до хакатона Използвам ROS (Robot Operating System), като идеята зад него е да може, ако се прави по-тежък процессинг, да мине на някакъв друг сървър или подобно, + да може лесно да се размножът платформите с вече направена комуникационна инфраструктура м/у тях. Като цяло ако правиш нещо роботско на по-високо ниво, е невероятно удобно и допълнително има страшно много различни библиотеки.
В крайна сметка, ще има един Apache сървър, отваряш страничката, кликаш/пращах команда, тя се изпраща към ros node (инстанция на програмата, да речем), която си spawn-ва нишка, а тя се грижи примерно на този пин да има такъв ШИМ.    
Камерката се закача на USB-то, като буквално на 5 реда с OpenCV (вече част от ROS) може да вземеш кадър, да го покажеш на web-страничката или да го изпратиш някъде в локалната мрежа. Може да се сложи малко Image Processing и да се напише нещо автономно - примерно роботчето се движи на някъде, като види човек/лице, обръща се към него, тилтва камерата, следи го. Като му свършва батерията, може да се прибере и да се зареди само.
Тъй като имаш Линукс + платформата подържа хардуерно различни варианти, може да правиш каквото си искаш, да връзваш високоговорители, микрофони,  акселерометри, жироскопи, термални датчици, въображението е единствената граница.

Ето и фронтална снимка

А утре 2.06 ще да го бъде ли ?

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

Както повечето от вас сигурно знаят, скоро ще започнат ежемесечните събития(Първото - 10 Април). Затова реших да дооправя, всъщност да съединя всичките части и  да тествам кода за управление.
За основа съм използвал платформата, разработена от клуба в София. Вместо да модифицирам напълно сервотата, съм ги залъгал с 2 еднакви резистора на мястото на потенциометъра, че постоянно се намират в централно положение. Единственият проблем е ,че пропорционалността на въртене се изменя в много малък диапазон - в момента съм тествал на 100мс от централното положение,което се оказа различно за 2-те сервота (1370 и 1430мс). Съответно съм и махнал зъбчето, непозволяващо непрекъснато въртене.
Използвал съм 5 RPR датчика - едина в центъра, позволяваш следенето и на прекъсваща линия и 2 от всяка страна. Към контролера се подават вече дигитални стойности, използвайки ЛМ393, като схемата е еднаква с тази разработената от yasko.
На платката са изведени и изводи за управление на Н-мост, както беше използвано в началото.
Микроконтролерът е PIC18F4620, което може да се каже, че е overkill. Но самата платформа се използва и за други тестващи цели- както например изведеният rs232(4-те женски пина с края на платката- харесал съм си мястото до него за SPI комуникация).А с поставянето на 1 джъмпер в една от 2-те позиции се реализира съответно или следенто на линия, или реализиране на тестващата версия.
Снимки:
Снимка 1
Снимка 2
Снимка 3
Снимка 4
Това което се чудя, е как да покрия (да направя сянка) на стърчащите сензори

Утре, 3 март, ще има ли ежеседмичното мероприятие?

Според мен просто ще се посетят всеки от 8-те сензора последователно(т.е. няма да слушаш само за точно един определен), практически без да се изчаква излишно време м/у тяx (всъщност какво е необходимото време на мултиплексорите да изменят избрания пин- може ли да се пренебрегне?). След това по вече изцяло създадената картина на околността ще се вземе решение какво да се направи. Това  поне ми се струва логичният вариант.
За мен е по интересно какъв тип ще са вземаните решения, от колко ще може да избира(напред/назад/ 90'ляво/ 90' дясно или ще бъде завой на Х градуса на тази страна - което би вдигнало възможните решения поне според мен прекалено много), и кога всъщност ще се счете едно решение за правилно (т.е например сензорите предизвикали това събитие да се променят(намалеят), или изцяло всички сензори да виждат празното пространство, или Х време след вземането на решение да няма сблъсък).

Супер ! Какъв ''workshop'' ще бъде ? Да носим ли помощни материали a.k.a. поялници, съзнание и др.