Progress Bar Eye. Bo dobrze mieć oko na kolejkę w firmowej stołówce. 

data: 27 grudnia, 2022
czas czytania: 6 min
autor: Bartłomiej Kurpanik

Case study narzędzia, które pozwala mierzyć natężenie ruchu w Progress Barze – punkcie gastronomicznym w gliwickim biurze Future Processing.

Skąd pomysł na pbEye? 

Stare powiedzenie mówi, że “potrzeba matką wynalazków”. Muszę przyznać, że pasuje ono jak ulał do programu Progress Bar Eye (pbEye). Idea, która przyświecała stworzeniu tego softu, jest dość prozaiczna – zarówno ja, jak i grupa kolegów z pracy, cenimy sobie czas i nie lubimy go marnować. Szczególnie jeśli trzeba stać w kolejce. Zresztą mało kto z nas lubi bezczynnie czekać czy to na basenie na wolne tory, czy też na obiad, kiedy głód daje o sobie dobitnie znać. Oczywiście można wcześniej wstawać na trening (np. o 5:30) lub jeść główny posiłek ok. 11:00, ale to nie rozwiązuje problemu, a jedynie go unika 😉 

A gdyby pójść w inną stronę i mieć dane o liczbie osób na basenie lub w punkcie gastronomicznym i na tej podstawie decydować o porze pójścia do tego miejsca?  

Nie tak dawno stworzyłem bota do gry World of Warcraft, który łowił za mnie ryby. Było to bardzo banalne połączenie biblioteki OpenCV, która szukała za mnie spławika na ekranie oraz biblioteki PyAutoGUI, która klikała za mnie myszką w spławik. 

Co ma wędka do talerza? 

Pozornie nic, ale w jakimś stopniu ryby ze świata wirtualnego przekładają się na sprawy w Progress Barze albo na basenie. Połączyłem kropki i pomyślałem, że gdybym miał kamery umieszczone przy wejściach do tych miejsc, mógłbym przy użyciu OpenCV obliczyć, ile osób wchodzi oraz wychodzi  i w jakich godzinach. Z wiadomych powodów kwestia trackingu na basenie nie doszła do skutku. Trudno legalną drogą zamontować własną kamerę lub uzyskać dostęp do monitoringu obiektu. 
Jednak sprawa związana z kolejką po obiad wyglądała obiecująco. Myśl o tym wracała za każdym razem, gdy liczba klientów malała bardzo powoli, a czas pomiędzy spotkaniami kurczył się nieubłaganie. Dzięki softowi mógłbym obserwować kolejkę do Progress Baru tak, aby dostać się na obiad nie tracąc czasu w kolejce – to było idealne środowisko (no prawie idealne, o tym trochę później). W sieci lokalnej Future Processing (FP) jest dostępna kamera, która pokazuje kolejkę. Można wejść i sprawdzić. Daje to wgląd w sytuację “tu i teraz”, a mi zależało na bardziej ogólnych wnioskach. Jednocześnie nie mam czasu (a kto ma?;)) na 8-godzinne obserwacje i tworzenie szacunków, kiedy najlepiej wybrać się po obiad. Od czego są nowe technologie? 

Jak patrzeć na kolejkę? 

Na początku musiałem zastanowić się, co tak dokładnie program miałby robić. Liczyć liczbę osób w kolejce? Samą długość kolejki? A może na podstawie ruchów ciała przewidywać co zamówią? 😉 
Cel nadrzędny był oczywisty: chciałem wiedzieć, o której godzinie wyjść na obiad, aby nie tracić czasu na stanie w kolejce. Padło na detekcję ludzi na podstawie obrazu z kamery wraz z informacją o dokładnej godzinie. 

OpenCV 

Moim pierwszym pomysłem było oczywiście wykorzystanie OpenCV. Miałem z nim doświadczenie w Pythonie, ale chciałem, aby program powstał w Node JS. Tutaj zaczęły się trudności. 

Tensorflow.js 

Bardzo szybko przeskoczyłem na Tensorflow.js. Wybrałem go ze względu na swoją popularność i łatwość użycia. Nie miałem czasu i danych na wyszkolenie własnego modelu rozpoznawania ludzi na obrazie z kamery, więc skorzystałem z gotowca – Coco SSD. Było to sprawdzone rozwiązanie z ogromną bazą do trenowania modelu, która akurat zawierała taką kategorię jak “person”. 

Prototyp 

Przeszedłem do stworzenia Proof of Concept aplikacji, która ściągała obraz z kamery i używała Coco SSD do rozpoznawania ludzi na obrazie. Zajęło mi to trochę więcej czasu niż oczekiwałem, ponieważ, ku mojemu zaskoczeniu, uruchomienie Tensorflow’a po stronie serwera okazało się trochę bardziej problematyczne niż zakładałem. Koniec końców – udało się! Do prototypu użyłem dostępnych kamer online z widokiem na centrum mojego miasta Rybnika. 

Na pierwszy rzut oka widać, że wykrywanie osób na zdjęciach nie było idealne. Wymagało to lekkiej konfiguracji i efekty były odrobinę lepsze. Testowałem rozwiązanie na innej kamerze, również z Rybnika, z widokiem na Bazylikę. W tym przypadku problem był taki, że modelowi bardzo spodobał się pomnik Jana Pawła II stojący przed wejściem. 

Gwóźdź do trumny 

Testy testami. Przyszedł dzień próby. W wolnej chwili w pracy, wszedłem na Progress Barową kamerę i zapisałem kilka kadrów. Po ich otwarciu, zorientowałem się, że jakość kamery jest tragiczna… Tym razem Tensorflowowi spodobał się śmietnik stojący pod ścianą i czasem osiągał on nawet większego score’a, niż ludzie, którzy akurat przechodzili przez kadr. 

W tym momencie wiedziałem, że Coco SSD sobie nie poradzi z taką jakością kamery… 

Czy to koniec? 

Bardzo szybko wymyśliłem banalnie proste i skuteczniejsze rozwiązanie – sprawdziłem różnicę obecnego obrazu z kamery z podstawowym obrazem, którym był pusty Progress Bar. 
Przebudowałem kod, użyłem biblioteki jimp, która na całe szczęście ma już wbudowaną funkcję sprawdzania różnic pomiędzy dwoma obrazami. 

Niestety Jimp rozpoznawał szum na jakości obrazu jako “ruch”, co trochę negatywnie wpłynęło na wiarygodność danych (te czerwone plamy na zdjęciu wyżej). Zauważyłem jednak, że fałszywy ruch występował tylko do pewnego poziomu. Włączyłem machinę i… zadziałało! Eureka! 😉 . W momencie gdy na Grafanie (program do monitorowania danych) podskakiwały słupki aktywności kolejki, wchodziłem na kamerę ręcznie, aby zweryfikować co się dzieje. Moim oczom ukazywała się kolejka. Sukces! 

Finalnie aplikację udało mi się odpalić tylko przez dwa dni (chyba w środę i czwartek), kiedy nie używałem Dockera i aplikacja działała w tle. 

Podsumowując 

Dane nie są idealne, ale potrafią uzmysłowić użytkownikowi, kiedy pójście na obiad to błąd. 


Słyszałem teorię, że wszyscy po zobaczeniu tych danych zaczną chodzić na obiad wtedy, gdy teoretycznie kolejka powinna być najkrótsza i otrzymamy dokładnie odwrotny efekt: znowu wszyscy będą czekać 🙂

Garść technikaliów​​​​​​​ 

Aplikacja jest zdokeryzowana, a kontener zawiera: 

  • instancję Elasticsearcha, do którego wpadają dane o aktywności, 
  • aplikację Nodową, 
  • instancję Grafany. 

Do pełni szczęścia zabrakło wewnętrznego networkingu w konfiguracji Dockera, plus trzeba samemu stworzyć data source i dashboard na Grafanie. 

Jeżeli masz pomysł na usprawnienie, bardzo zachęcam do kontaktu. Jeśli widzisz miejsce na improvement kodu, zapraszam do zostawiania MRek na gicie. Repo jest dostępne tutaj.

Newsletter

Zainteresowały Cię nasze treści?
Sprawdź co jeszcze przygotowaliśmy.

Adres e-mail

Dziękujemy! Na Twój adres e-mail wysłaliśmy prośbę o potwierdzenie zapisu do newslettera.

O nie! Coś poszło nie tak. Nie zapisałeś się.

Gdyby tylko dało się zapisać Twojego maila dwa razy :)

Niepoprawny mail. Spróbuj jeszcze raz.

Cookies

W pracy serwujemy suchar dnia. Tutaj musimy Cię poczęstować ciasteczkami. Dowiedz się więcej.

Administratorem Twoich danych osobowych jest Future Processing S.A. z siedzibą w Gliwicach. Twoje dane będziemy przetwarzać w celu przesyłania cyklicznego newslettera dot. wydarzeń i inicjatyw realizowanych w Future-Processing. więcej informacji znajdziesz w naszej polityce prywatności.