roadmap

obraz

roadmap.cameramonit.com

Questions:

  1. Showcase
  2. MVP -
  3. How to interact, User experience
  4. how interaction will work
  5. what the benfit will be

EN

  1. The product must have its own dedicated team, even if it consists of 1 or 2 people. These people must believe in the product and have the freedom to develop it to make it the best for users.

  2. The product should be clearly defined for whom it is - ICP - just as a developer wonders whether he is building for families or singles coming to a big city? Completely different needs.

  3. The product is not a conglomeration of all the functions that come to mind - or we have from other projects. This is not about technical debt (which is fine up to a certain point because it shows the pace and understanding of customers). The point here is not to build a product specifically for anyone…

  4. Product = striving for quality. Services = striving to invoice the project and move on to the next one. It doesn’t connect. That’s why product teams that are not clearly separated from service teams do not achieve success - they cannot be achieved in conditions of constant schizophrenia ;)

  5. Committee decision making. I remember that at Divante we were building a B2B product for Magento. I wanted everyone to be involved - ownership, I read, is important. But making decisions by 15 people in a conference room, this ownership takes away, not gives :) A strong lesson. In the end, I myself - the originator of this product - did not want to come to the meetings :)

PL

Co odróżnia te które się udały od tych które powolnie umarły śmiercią naturalną? Kilka rzeczy przychodzi mi do głowy na szybko:

  1. Produkt musi mieć swój dedykowany zespół, nawet jeśli 1 lub 2 osobowy. Te osoby muszą wierzyć w ten produkt i mieć swobodę rozwijać go, żeby był najlepszy dla użytkowników.

  2. Produkt powinien mieć jasno zdefiniowane dla kogo jest - ICP - tak jak developer zastanawia się czy buduje dla rodzin czy singli przyjeżdżających do dużego miasta? Zupełnie inne potrzeby.

  3. Produkt nie jest zlepkiem wszystkich funkcji jakie przychodzą nam do głowy - albo mamy z innych projektów. Tutaj nie chodzi o dług technologiczny (który do pewnego momentu jest spoko bo świadczy o tempie i zrozumieniu klientów). Tutaj chodzi o to, żeby nie wybudować produktu dokładnie dla nikogo…

  4. Produkt = dążenie do jakości. Usługi = dążenie do zafakturowania projektu i przeskoczenia do kolejnego. To się nie łączy. Dlatego zespoły produktowe które nie są odłączone wyraźnie od zespołów Usługowych nie osiągają sukcesów - nie da się ich osiągnąć w warunkach ciągłej schizofrenii ;)

  5. Podejmowanie decyzji przez komitet. Pamiętam, że w Divante budowaliśmy produkt B2B dla Magento. Chciałem, żeby każdy był zaangażowany - ownership wyczytałem jest ważny. Ale podejmowanie decyzji przez 15 osób w salce konferencyjnej ten ownership zabiera a nie daje :) Mocna nauczka. Na końcu ja sam - pomysłodawca tego produktu - nie chciałem przychodzić na spotkania :)

Competitors:

Amazon’s Ring and Google’s Nest are two of the biggest names in the market, Ring alone has more than half a dozen different models to choose from, our favorites being the $169.99 Video Doorbell Pro, the $199.99 Video Doorbell 3 Plus, and the $129.99 Peephole Cam. If you already use other Google or Nest smart home devices like a Nest Hub smart display, a Nest Mini smart speaker, or a Chromecast, go with the Hello video doorbell if you can afford it.
The Hello earned high marks in our tests for its ability to identify people using face recognition technology, its sharp HD video, its sleek design, and its interoperability with other smart home devices. Pair it with a Nest Mini and Chromecast, for instance, and you can ask your smart speaker to cast video from the doorbell to your TV. You can also stream video from the doorbell to a screen-equipped Amazon Alexa device like the Echo Show, as well as Fire tablets and Fire TV devices, but the Hello doesn’t play nice with Alexa devices without a display.

Solutions

[Wykrywanie i śledzenie obiektów     ML Kit     Google for Developers](https://developers.google.com/ml-kit/vision/object-detection?hl=pl)

Dzięki dostępnym na urządzeniu interfejsowi API do wykrywania i śledzenia obiektów w ML Kit możesz wykrywać i śledzić obiekty na obrazie lub w transmisji na żywo z kamery.

Opcjonalnie możesz klasyfikować wykryte obiekty, korzystając z wbudowanego w interfejs API przybliżonego klasyfikatora lub z własnego niestandardowego modelu klasyfikacji obrazów. Więcej informacji znajdziesz w artykule Używanie niestandardowego modelu TensorFlow Lite.

Wykrywanie i śledzenie obiektów odbywa się na urządzeniu, dlatego działa również w interfejsie potoku wyszukiwania wizualnego. Po wykryciu i odfiltrowaniu obiektów możesz przekazać je do backendu w chmurze, na przykład do wyszukiwarki produktów Cloud Vision.

Najważniejsze funkcje

MVP będzie polegało na zrobieniu interfejsu tekstowego z powiadamianiem o tym co dzieje się na video, gdzie tak jak chatgpt będziesz pisał co chesz zobaczyć

  1. Panel instalatora
    • wykonanie w python, django + sqlite do konfiguracji
    • instalator może dodawać dane za pomocą kanału email wysyłając wiadomość z nazwą kamery adresem i hasłem
    • instalator może używać aplikacji chat, np whatsapp do wysłania danych dostępowowych
    • wszystkie dane dotyczące kamer są dostępne do wglądu i bazując na nich admin wybiera które chce podłączyć do konkretnej aplikacji
    • baza danych jest osobno, gdyż można wykorzystać inna formę przehcowywania danych kamer
    • interfejsem wymiany z panelem aplikacji jest API
  2. Panel aplikacji dla @admina w oparciu o dane z Panelu instalatora
    • wykonanie w python, django + sqlite do konfiguracji + FTP/webdav do pobierania danych przez usługę VideoToText
    • dodawanie URL streamu z kamer + auth
    • wartość ile ma być zapisywanych minut video na bieżąco jako bufor, np 5 sekund do opisania tego co się w tym czasie działo
    • zapisywanie video do maksymalnie do X minut
    • zapisywanie obrazów jako animacji do udostępnienia do przeglądania: X Sekund
    • dodawanie i zarządzanie integracjami
    • interfejsem wymiany z panelem managera i interfesjem webowym jest API
  3. Panel managera dla kontrioli dostępu
    • lista projektów
    • lista grup i userów
    • określenie czasu dostępu
    • lista zdarzeń jakie mają być udostępnione dla konkretnego grupy usera

  4. Usługa VideoToText Przetwarzanie video i zapisywaniu zauważonych obiektów i zdarzeń do bazy mariaDB: obiekty, cechy, zdarzenia Biblioteki Python i API w pierwszym etapie ułatwiające analizę krótkich video. Na początku będzie zgrubna lokalna analiza a następnie dosyłanie do wyspecjalizowanej usługi na innym serwerze. Dane konfiguracyjne muszą najpierw zostać pobrane z panelu aplikacji i zwrócone w postaci krótkich filmów na serwerze FTP/WEBDAV Filmy są udostępniane dla usera z interfejsu webowego przez http

  5. Interfejs webowy strona webowa do wizualizacji zdarzeń i możliwości przeglądania w formie chat każda kamera ma osobny chat tak jakbyś rozmawiał z różnymi ludźmi z dodatkowymi opcjami, których nie można zaimplementować na zwykłej apce jak podpowiedzi.

  6. Integracja API z popularnymi komunikatorami z pisaniem bezpośrednio na smartphone usera o tym co dzieje się na kamerze + poprzez url możliwość wejścia na interfejs webowy aby zobaczyć więcej

  7. Storage dostepny poprzez FTP/Webdav

W skrócie mamy 3 typy użytkowników + instalator, który dodaje kamery

Trzeba stworzyć makietę na docker compose, każda usługa osobno przez dedykowany IP wewnątrz sieci Kolejna implementacja na proxmox:

Prezentacja dla użytkownika

ROADMAP

Offline upload video - 1 kanał

Przygotowanie docker compose lokalnie

Funkcje Upload:

  1. jedna baza danych konfiguracji + administracji
  2. ftp/webdav do wgrania video i pobierania video
  3. Generowanie w oparciu o upload, poprzez połączenie do API videototext
  4. Generowanie rozpoznanych obiektów w oparciu o bazę danych
  5. Wysyłanie danych do bazy danych a z niej bezpośrednio na powiadamianie
  6. Na stronie www
  7. Na API chat/Email

Statycznie przygotowane + z już przetworzonymi danymi oraz chat webowy dla usera do przeglądania wcześniej nagranego video z jednej kamery

Live, 60 sekund - 1 kanał

Przygotowanie docker compose z runner na gitlab w VPS w proxmox

  1. Panel konfiguracji + administracji + chat webowy dla usera do otrzymywania informacji z aktualnego streamu video z jednej kamery
  2. Usługa videototext w oparciu o API do przetwarzania filmów 60 sekundowych
  3. Chat webowy dla usera do przeglądania nagrywanych danych z ostatnich 60 sekund w pętli z 1 kamery
  4. Zarządzanie użytkownikami: dodanie panelu instalatora i użytkownika
  5. Rozszerzenie możliwości przetwarzania i obsługa panelu dla supervisora
  6. Integracja chatów

Live, 24h - 10 kanałów

Przygotwanie na wirtualiazji proxmox