Migration one:
Nokitsesin algul enda tööarvutis, kuid kaua see kesta ei saanud. Roboti tagasihoidlikku "aju" ei saa võrrelda multituumalise i5-ga. Mõõtmiste tulemused peaksid olema ilmselt liiga erinevad, nii mulle tundub. Nüüd siis paigaldan arenduskeskkonna roboti enda arvutusmasinale ning edaspidi jätkan ainult "seal".
Migration two:
Koolis ei saanud lõputööga tegeleda - õhtuti aetakse minema.
Kodus ei saa lõputööga tegeleda - kodu on puhkamiseks.
Kolisin koos kõikide vajalike komponentidega tööle - õhtuti on siin hea produktiivne õhkkond, kodule oluliselt lähemal ja satun siia tihti :P
(15x15cm Intel Desktop Board emaplaat , mille mudelit ma ei teagi+ kingston ssd ketas, dc power supply, paar PS3Eye kaamerat)
 |
| lab @ knowit |
Action:
Varasemalt olen koodikirjutamise seisukohalt kokku puutunud vaid roboti käitumisloogikaga, mis on suhteliselt lihtne. Asi piirdus geditiga. Praegu oleks gedit overkill.. or underkill. Ja eriti veel sellepärast, et C++ on minu jaoks võõras, tööl olen tegelenud 99% javaga, koolis 75% :P. Java ja C++ on ikka meeletult erinevad, väga paljusid asju veel ei tea ja lugemist on väga palju. Õnneks on netis palju häid õpikuid.
Tõmbasin linuxi C/C++ eclipse. Eclipset teatavasti ei ole vaja "installeerida" ning siin mingeid jamasi ei olnud. Huvi pärast tõmbasin juurde mingeid Qt pluginaid ka. Kulus ikka aega, et eclipsest botmaster käima saada (mingite teekidega oli lõpuks ikka mingi kamm, osa koodist sai esialgu välja kommenteeritud). Eclipse buildib seda projekti 100 aastat. Ebamugav.
 |
| Eclipse + botmaster |
Tahtsin Qt Creatori peale panna, kuid siin mul juhtus nagu Laaril - ruum sai otsa. Robotil puudus varem SSH ketas ning bootisime 8-gigase usbi pulga pealt (läheb ka eelmise pildiga kokku :D) ja nii oligi jäänud, et arvuti ainus partitsioon on 7,5 gigane. Qt Creator palus 4gb vaba ruumi.
Tuli siis muretseda GParted ning partitsiooni laiemaks venitada.
Qt Creator installeerus kaua, sest tõmbas oma sõltuvuste rahuldamiseks pool internetti alla. Käisin vahepeal kinos.
Tulin kinost tagasi ja jäi vaid klikata paar "next"-i ja üks "finish".
Botmasteri *.pro projekt oli roboklubi svn-is ka olemas. Avasin selle Qt arenduskeskkonnas and it worked like a charm - avab ruttu, buildib ruttu, jooksutab ruttu. Mõnus.
Ah, see tekst on nagu mingi jutt, see pole plaanipärane ja kribamise peale kulub liiga palju aega, katsun üle minna "märkmete" režiimi.
Research:
Leidsin huvitavaid näiteid pilditöötluse algoritmidest ja nende parendusest. Parim leid ja inspiratsioon esimesteks katsetusteks - http://code.google.com/p/qt-opencv-multithreaded/
- +
- Ilus kood, põhjalik dokumentatsioon
- Põhiline väärtus seisneb threadide kasutamises - kasutatakse Qthreadi võimalusi
- Värskeim opencv ja lahedad qt vidinad
- Dedicated thread to capture frames from camera.
- Dedicated thread to perform image processing on captured frames.
- Option to drop frame if image/frame buffer is full
- Näited OpenCV funktsioonide kiirendamisest:
- Smooth (Blur, Gaussian, Median) - kümnesse
- muud
Väga väärtuslikud näidislahendused, mis võivad olla väga kasulikud ja mida võiks integreerida/meie süsteemi üle võtta. Ettevaatlikuks tegi üks avastatud bugi fps-i kuvamise funktsionaalsuses.
Testing:
Oma arvutis oli ilus tulemus, kaamerast tuli 30fps. Koos gaussi filtriga (kernel width/height: 7/7, X/Y sigma 0/0) jäi "pildi kuvamise" kiirus sisuliselt samasuguseks nagu pildi "pildi võtmisel", või noh.. halvimal hetkel 2fps aeglasem. Ilma puhvrita - robotil peaks olema n-ö LIFO "pilditöötlemispoliitika" - last in, first out. Kui robot jõuab võtta rohkem pilte, kui suudab töödelda, siis tuleb vahepealsed kaadrid minema visata.
Roboti arvutis oli tulemus natukene aeglasem. Aga muidu tulemus sama - kui gaussi filter peale panna, siis jõudluse kadu ei näe.
Probleem ja challenge: Oleks vaja kaamerast välja võluda rohkem kaadreid sekundis, riistvara võimaldab (max 125fps@320x240 ja 60fps@640x480). Olemasoleva kaamera driveri (ov534) lähtekoodi uurides selgub, et teoreetiliselt ka draiver peaks lubama. On vaja 60@VGA.
OpenCV kaudu rohkem "paluda" ei õnnestu. Küll aga õnnestus opencv funktsionaalsuse abil muuta pildi resolutsiooni (Valdur rääkis, et nii ei saanud varem. WIN!):
cap.set(CV_CAP_PROP_FRAME_WIDTH, 640); //töötab
cap.set(CV_CAP_PROP_FRAME_HEIGHT, 480); //töötab
cap.set(CV_CAP_PROP_FPS, 60); // ei tööta
cap.set(CV_CAP_PROP_BRIGHTNESS, 249); //töötab
Vanemast ov534 draiverist (aasta 2009 vms) oli olemas patchitud versioon, kus capture fpsi sai muuta modprobe abil käsurealt. Aga sellel vanal draiveril polnud V4L tuge, mis on halb ja meile ei sobi. Umbes selline oli Marguse kommentaar.
Võib siis otsida adekvaatseid variante, kuidas seadistada kaadrite arvu või siis minna kiiremat ja põnevamat teed, h4xxida driverit ennast.. lähtekood on ju olemas.
OV534 Driveri Hakkimine:
Okei, vaikimisi lähtekoodi ei ole ja see tuli tõmmata.
sudo -s
cd /usr/src
apt-get update
apt-get install -y build-essential kernel-package linux-source guvcview
tar --bzip2 -xvf linux-source-*.tar.bz2
ln -s `find . -type d -name "linux-source-*"` linux
Täisa mõnus on kasutada neid '*' tähekesi, tihti on tutorialides taolises kohas miski a la '<your version>' (nt robo wikis on) ja siis tuleb see käsitsi asendada.
"ov534" draiveri lähtefail asus nüüd siin ("linux" kaust on symlink, nii on edasi mugavam): "/usr/src/linux/drivers/media/video/gspca/ov534.c" ja enne näppimist tegin koopia ka.
Driveris endas tegin väga lihtsa muudatuse, kahes massiivis kommenteerisin välja kõik muud reso ja fps optsioonid peale selle, mis mul vaja - 60fps@VGA.
Minu kerneli draiveris read 621-636
Enne:
static const struct rate_s rate_0[] = { /* 640x480 */
{60, 0x01, 0xc1, 0x04},
{50, 0x01, 0x41, 0x02},
{40, 0x02, 0xc1, 0x04},
{30, 0x04, 0x81, 0x02},
{15, 0x03, 0x41, 0x04},
};
static const struct rate_s rate_1[] = { /* 320x240 */
{125, 0x02, 0x81, 0x02},
{100, 0x02, 0xc1, 0x04},
{75, 0x03, 0xc1, 0x04},
{60, 0x04, 0xc1, 0x04},
{50, 0x02, 0x41, 0x04},
{40, 0x03, 0x41, 0x04},
{30, 0x04, 0x41, 0x04},
};
Pärast:
static const struct rate_s rate_0[] = { /* 640x480 */
{60, 0x01, 0xc1, 0x04},
//{50, 0x01, 0x41, 0x02},
//{40, 0x02, 0xc1, 0x04},
//{30, 0x04, 0x81, 0x02},
//{15, 0x03, 0x41, 0x04},
};
static const struct rate_s rate_1[] = { /* 320x240 */
//{125, 0x02, 0x81, 0x02},
//{100, 0x02, 0xc1, 0x04},
//{75, 0x03, 0xc1, 0x04},
//{60, 0x04, 0xc1, 0x04},
//{50, 0x02, 0x41, 0x04},
//{40, 0x03, 0x41, 0x04},
//{30, 0x04, 0x41, 0x04},
};
Nii lihtne ongi.
Tegelikult võtsin veel välja ka kaamera punase tulukese põlemise, ledi värv läheb punaste pallidega kokku, roboti katsetustel võib häirida :))
Kuna testisin mitu korda ja erinevat moodi, siis tegin draiveri kompileerimiseks shelli skripti ja aina käivitasin seda..
#!/bin/bash
# Rebuild OV534
echo "[Neve v3 arendus] Ehitan draiverite moodulid: ov534, gspca_ov534, and gspca-main..."
cd /usr/src
cp -p linux-headers-$(uname -r)/Module.symvers linux
cd /usr/src/linux
make oldconfig
make modules_prepare
make SUBDIRS=drivers/media/video/gspca modules
echo "[Neve v3 arendus] Paigaldan uue gspca_ov534 draiveri + asendan gspca_main..."
cd /usr/src/linux
cp -p drivers/media/video/gspca/gspca_main.ko /lib/modules/$(uname -r)/kernel/drivers/media/video/gspca
cp -p drivers/media/video/gspca/gspca_ov534.ko /lib/modules/$(uname -r)/kernel/drivers/media/video/gspca
depmod
echo "[Neve v3 arendus] Kustutan vanad draiverid, laen uued.."
modprobe -r gspca_ov534 gspca_main
modprobe gspca_ov534
Testing:
Põhimõtteliselt tänaseks kõik. 60fps puhul on juba näha, et töötlus jääb maha, aga siiski tulemus on täitsa vinge:
640x480 pildi kuvamine koos gaussi filtriga (kernel width/height: 3/3, X/Y sigma 0/0 - nagu meie robotil on olnud seni): capture rate hüppab vahemikus 45-59fps, processing rate ~45fps. Kui processing threadile kõrgem prioriteet määrata, siis tulemused paranevad.
Botmasteril on selline jõudlus hetkel vaid siis, kui gaussi filter ja LUT(bgr->hsl) on välja lülitatud. Seega testitud lahenduste kasutuselevõtt võib tublisti parandada jõudlust.
Loodetavasti olen õigel teel :)
