Zaległości

Już jakiś czas temu wypowiedziałem się publicznie, na forum warsztatu, że podjęcie pracy na Politechnice uważam za jeden z największych błędów w życiu. Na szczęście jest to błąd w pełni odwracalny. No i stało się, zmieniłem pracę. Od maja pracuję dla łódzkiego oddziału Mobica Ltd.

Ze zmiany jestem bardzo zadowolony. Niestety firma musi chronić swoich klientów i jestem zobowiązany do tajemnicy. Także źródło ciekawostek do notatek mi się skończyło.

Końcówka pracy dla uczelni to był prawdziwy sajgon. Robot musiał zostać przygotowany do "prób poligonowych". Próby te odbyły się na przełomie kwietnia i maja na poligonie wojskowym z kompletnie świeżym robotem. W zasadzie wszystko nam się udało przygotować, na miejscu robot został jedynie złożony do kupy.
Robot dostał świeżutkie akumulatory i jeździł jak nigdy wcześniej. Wytrzymał jakąś godzinę, a potem spaliła mu się część silników napędowych!
Generalnie cała "operacja poligon" została uznana za sukces. Osobiście jestem szczególnie zadowolony ze sterowania robotem za pomocą systemu GPS. Całe oprogramowanie zostało przygotowane na ostatnią chwilę. Nie było nawet okazji przetestować czy działa. Zadziałało i to jak. System GPS jest bardzo precyzyjny. Robot bez problemów był w stanie gonić człowieka z nadajnikiem. Nawet przez moment się nie zgubił.

Koniec pracy dla uczelni oznaczał również konieczność przygotowania "raportu końcowego". Co to znaczy? Przygotowanie dokumentacji i raportów do wszystkich zadań z całego półtorarocznego okresu pracy dla Politechniki. Nagle im się k...a przypomniało, że będą potrzebować dokumentacji! Przez półtora roku nawet się nie zająknęli. Przygotowanie tego raportu zajęło mi mniej więcej półtora miesiąca. Jakimś cudem udało mi się odtworzyć historię zadań, także raport w sumie wyszedł mi całkiem rzetelny.

Kilka słów na temat pobytu na terenie poligonu. Super! Prześliczny teren. Sporo zwierzaków. Sprzęt wojskowy :)



Wciąż pracuję nad własnym silnikiem. Jak tylko mam wolną chwilę staram się coś napisać. Niestety z czasem kiepsko ... żona.

EasyCap 4 Channel Usb DVR

Aktualnie pracuję nad tym jak zrobić PIP z kilku kamer. EasyCap 4 Channel Usb DVR to frame grabber, którego używamy do przechwytywania obrazu z kamer analogowych. Ma tą ważną cechę, że dzięki sterownikowi EasyCAP DC60 Driver działa z systemem Linux, co chyba nie jest takie oczywiste w tej kategorii sprzętu. Testowaliśmy jedno konkurencyjne urządzenie i nie udało się go uruchomić.
Frame grabber ma 4 kanały video in. Możliwe jest jednak zbieranie tylko z jednego kanału równocześnie. Zmianę aktualnego kanału można dokonać za pomocą biblioteki Video for Linux 2 - v4l2. Przełączenie kanału jest operacją dość czasochłonną i powoduje, że obraz pobrany tuż po niej zawiera śmieci.

Jak zrobić Pip z takim sprzętem? Użyć kilka frame grabber'ów ;)



Obrazy pobieramy biblioteką OpenCV, funkcje:
cvCaptureFromCAM,
cvQueryFrame.

Zmiana kanału jest możliwa poprzez v4l2, funkcja:
ioctl(file, VIDIOC_S_INPUT, &index),
gdzie file to plik urządzenia otwarty funkcją open i flagą O_RDONLY | O_NONBLOCK,
a indeks to wartość typu int z numerem kanału. 0 i 1 to kanał pierwszy.

3 miesiące przerwy, podsumowanie

Od poprzedniego posta upłynęło już bardzo dużo czasu. W pracy projekt się kończy w trybie przyśpieszonym (czytać: nie ma kasy, więc robimy na szybko ile się da). Przedłużająca się niezbyt przyjemna sytuacja w pracy daje mi się we znaki (uczucie senności, zmęczenie itp). Krótko, nie bardzo mi się chciało pisać.

Z pracy:
- linux frame buffer - bardzo ciekawa bestia,
- obsługa wielokanałowego frame grabbera sterownikiem EasyCAP DC60 Driver,
- fuse - o tym już pisałem,
- wizyta w warszawie,
- przechwytywanie obrazu z kamer ip dedykowaną biblioteką pylon.

Z domu:
- przeprowadzka - w listopadzie zamieszkaliśmy we "własnym" mieszkaniu (nasze nie jest, ale w końcu sami),
- silnik się rozwija. Przemyślałem sobie parę rzeczy i sporo pracy poświęciłem przygotowaniu "framework'a" leżącego u podstaw silnika.

W silniku skończony mam jak na razie system obsługi okien. Prosty w obsłudze i bardzo elastyczny ;) Na poważnie, skupiłem się na elastyczności:
- użytkownik sam może utworzyć okno (np. CreateWindowEx) i przekazać je do systemu,
- użytkownik może wybierać pomiędzy domyślną i własną funkcją obsługi komunikatów,
- nie ma ograniczeń co do ilości okien,
- można dynamicznie tworzyć i zamykać okna,
- system zapewnia dostęp do uchwytu okna (na razie tworzę z myślą o Windows),
- renderować do okna można dowolną metodą: GDI, OGL, DX,
- można renderować do kilku okien naraz,
- można nawet dodać menu ;).

Ograniczenia:
- domyślna funkcja okna korzysta z danych zapisanych za pomocą funkcji SetWindowLong w polu GWL_USERDATA.

Wygoda:
- utworzenie typowych okien wymaga jedynie obiektu menadżera i wywołania odpowiedniej funkcji tworzącej okno.


Koniec.