Urządzenie lokalizacyjne, znajdujące się i poruszające wraz z lokalizowanym obiektem, wysyłające (odbierające?) dane przez internet.

Pomysły:

  • budowa własnego lokalizatora (moduł dla internetu z kartą SIM, odbiornik GPS, sterowanie ustawieniami np. Bluetooth, procesor ogarniający całość),
  • gotowy moduł np z rodziny tanich lokalizatorów TK102/TK106

Rozwiązanie pierwsze jest ambitniejsze, daje większe możliwości -jak choćby wspomniana możliwość sterowania urządzeniami obiektu (samochód/łódź) poprzez internet, SMS etc. Rozwiązanie drugie zaś – proste, tanie, jednak w tym wypadku trzeba wpasować się w wizję autorów.

Opiszę zarówno wykorzystanie gotowego urządzenia jak i fragmenty tworzenia swojego… Będzie zatem o programowaniu w asemblerze, elektronice, układach cyfrowych itd.

Gotowy lokalizator TK102, TK106.

Urządzenie niewielkie, niedrogie dość niezawodne, do działania potrzebuje zasilania, zasięgu GPS (radiowej widoczności nieba), karty SIM z dostępem do internetu i …wiedzy gdzie wysyłać dane o lokalizacji.

Wymienione urządzenia zostały przetestowane i dobrze sprawdzają się, pasując do założeń.

To co pozostaje do wykonania to oszukanie nieco poprzez podanie przetworzonego napięcia akumulatora w taki sposób, aby urządzenie sądziło iż jest zasilane z własnej baterii (w znanych mi przypadkach nie wystarczy podanie napięcia zasilającego przewodem). Można to łatwo osiągnąć podając odpowiedniej wielkości napięcie (tutaj 4,4V) na zacisk ‚główny’ baterii, oraz – poprzez rezystor- na zacisk dodatkowy. Napięcie 5V uzyskane z przetwornicy (np. z wejściowego 12V) – przepuszczone przez diodę krzemową – spadek ok. 0,65V – uzyskamy 4,4V -jak z baterii. Kondensator o dużej pojemności ‚załagodzi’ zmiany napięcia.

Schemat i foto.

Pozostaje sprawdzić, czy po ew. zaniku zasilania (które w zasadzie zdarzy się tylko przy odłączeniu akumulatora obiektu śledzonego) lokalizator ponownie włączy się i rozpocznie pracę. W wypadku TK106 tak się właśnie dzieje. Dla TK102 – konieczny dodatkowy kondensator z rezystorem, symulujący przyciśnięcie OnOff po włączeniu zasilania.

Miejsce umieszczenia lokalizatora, powinno zapewniać możliwie najlepszą ‚radiową’ obserwację nieba. Wiadomo, dla uzyskania pozycji GPS wymagana jest widoczność przynajmniej 4 satelitów. Wykluczone zostają zatem wszystkie miejsca zasłaniające odbiornik od nieba karoserią (no chyba, że jest to Trabant i karoseria nie -metalowa). Dobrym pomysłem wydaje się miejsce pod deską rozdzielczą z przodu lub z tyłu. Szyba nie utrudnia odbioru sygnału GPS.

Co nadaje lokalizator i skąd to pochodzi?

TK106 nadaje co 15 sekund poprzez GPRS protokołem UDP na ustalony adres IP i port coś podobnego do:

1409261359,+486*******2,GPRMC,055920.000,A,5354.6300,N,1414.9510,E,3.74,349.42,260914,00,0000.0,A*44,L,,imei:353579018219978,125

nadawane frazy składają się z szeregu danych, m.in daty/godziny, numery telefony (wygwiazdkowany) fragmentu frazy RMC (Recommended minimum specific GPS) i numeru IMEI urządzenia.
RMC opisana jest tutaj.

 

Próbne frazy sygnału NMEA symulowanego dla poruszającego się odbiornika można uzyskać np tutaj (program napisany w Delphi dla Windows. Tak, tak -używałem kiedyś Windows.). Wydaje się, że można prosto przerobić to także dla Python i Linux.

Słówko jeszcze o NMEA, pozycji GPS oraz wspomnianych 6 bajtach, w których można zawrzeć dokładną pozycję obiektu w dowolnym miejscu na Ziemi.

Pozycja GPS jest określana poprzez podanie dwóch współrzędnych – podobnie jak X i Y na wykresie, tutaj jest to fi i lambda lub -innymi słowy- lat (latitude) i lng (longitude) – czyli szerokość i długość geograficzna. Na wykresie X i Y występowały jako dodatnie lub ujemne, podobnie współrzędne geograficzne – umownie szerokość północna (N) jako dodatnia, południowa (S) -ujemna, oraz długość wschodnia (E) dodatnia i zachodnia (W) ujemna.

X i Y były wyrażone liczbowo, podobnie jak długość i szerokość, które jednak wyrażona są w stopniach i ułamkach stopni. Zapis np. +53,926310 i +14,277255, szyli szerokość ponad 53 stopnie Nord i długość ponad 14 stopni East można przedstawić w nieco ładniejszy -nawigacyjny- sposób, mianowicie jako stopnie, minuty i ułamki minut:

N53o55,5786 E014o166353. Jak to przełożyć na Kulę Ziemską? Zostało to wymyślone około 1569 roku i od nazwiska twórcy nazwane siatką Merkatora.

Orientacja w temacie będzie niezbędna do skonstruowania własnego lokalizatora i oprogramowania do niego.

Tak więc nasza długość – oś X otacza Ziemię i zawiera się w zakresie od W180 (-180) do E180 (+180). Jest to 360 stopni, każdy stopień ma 60 minut czyli 360 * 60 = 21600 minut. Dokładnie tyle ile mil morskich ma równik, bo 1 mila morska na równiku odpowiada 1 minucie kątowej długości geograficznej. Jedna mila morska to 1852,5 metra.

Dla szerokości – naszego Y, zakres wynosi od S90 (-90) do N90 (+90). Z różnic zakresów wynikają też historyczne uwarunkowania zapisów długości i szerokości. Tak jak każdy nawigator ze wstrętem zapisuje pozycję z ułamkami stopni zamiast minut, tak żaden nie zapisze długości geograficznej inaczej w trzycyfrowej postaci stopni – często z wiodącym zerem. Wracając do szerokości – jedna minuta kątowa odpowiada jednej mili morskiej, czyli 1852,5 metra. W każdym miejscu.

Co jednak z przeliczaniem długości kątowej na odległość poza równikiem?

Odległość 1 minuty kątowej wzdłuż równoleżnika (a więc równolegle do równika) równa jest 1 mili morskiej pomnożonej przez cosinus szerokości geograficznej tego równoleżnika. I tak dla równika będzie to dokładnie jednak mila, zaś dla szerokości geograficznych Polski, Świnoujścia – około

 

cosinus(54st) * 1852.5 = 1089 metrów

…a na biegunie? Taki paradox… znacie zagadkę o przejścu z bieguna północnego 1km na południe, skręt o 90 stopni w prawo, 1km na zachód, skręt o 90 stopni w prawo i znów 1km na północ. Tadam! jesteśmy w tym samym miejscu! Przeszliśmy trzy proste odcinki ułożone pod kątem prostym i wróciliśmy w to samo miejsce …hmm. To taka nawigacyjna anegdotka.

Ok.
Fraza z TK106, nadana poprzez GPRS na IP:port, odebrana, podzielona wzdłuż przecinków, sprawdzone IMEI i nr telefonu, mamy datę i godzinę oraz pozycję. Hop do bazy danych.
Po odebraniu następnej znów itd…
Przetwarzając to sprytnie, możemy uzyskać na początek taką wizualizację:

Prędkości obliczane na podstawie ilorazóœ odległości i czasu, wizualizacja Google-gauge
do tego mając pozycje i bazę danych TERYT określamy najbliższe miejscowości i odległości do nich (proszę zwrócić uwagę na ostatni wiersz każdego z okienek).

Tadam!
Teraz zaprzągnijmy do pracy analizę – sprawdzamy w sposób prawie-ciągły pozycje śledzonych obiektów względem interesujących obszarów. Dołączamy SMS i/lub powiadomienia Messenger…

Radości!
WikS.

Lokalizator obiektu (pojazdu, łodzi). Od czego zacząć i jak musi działać?

Urządzenie, zasilane ciągle – a więc np z akumulatora samochodowego, ‚widzące’ niebo – odbierające sygnał GPS niezależnie od położenia obiektu, przesyłające w jakiś magiczny sposób cyklicznie dane o swoim położeniu. Ale także odbiornik tych danych, miejsce ich gromadzenia, oraz jakiś przyjemny sposób wizualizacji.

Założenia:

  • urządzenie lokalizacyjno -nadawcze (i odbiorcze?),
  • magiczne medium przenoszenia informacji
  • odbiór i wizualizacja danych.

Spróbuje je nieco rozwinąć, zacznę jednak od środka, magiczne medium bowiem zdeterminuje zarówno urządzenie jak i stopień końcowy zestawu.

Jako najrozsądniejsze wydaje się przesyłanie danych poprzez internet – GPRS, albo UDP albo TCP (zachęcam do zgłębienia skrótów np. w Wikipedii). W takim wypadku odbiór danych będzie stosunkowo prosty, zasięg spory, pytanie jak wpompować dane do internetu i jak je z niego wyciągnąć?

Zacznę od wyciągania danych. Pomysł -serwer, może być nawet taki zbudowany na RaspberryPi, lub zwykłym (nawet wiekowym) komputerze / laptopie. To co istotne, aby serwer miał swoje stałe miejsce w internecie (stałe IP), pod które można przesyłać dane skądkolwiek.

Co do ‚wpompowania’ danych do internetu, obecnie rozsądnym pomysłem wydaje się użycie czegoś na podobieństwo popularnego modułu SIM900, który przy użyciu karty SIM – będąc w zasięgu sieci komórkowej, w prosty sposób będzie w stanie przesyłać i odbierać dane do serwera, którego adres będzie stały. Kolejne pytanie w tym wypadku – w długim okresie najistotniejsze – koszty przesyłania danych, a więc także ich ilość.

Przy założeniu, że chcemy mieć ciągłą pozycję obiektu – powiedzmy co 15 sekund aktualizowaną pozycję, czyli informacja o pozycji przesyłana 4 razy w minucie –> 240 razy w każdej godzinie –> 5760 razy w ciągu doby –> 180 tyś razy w miesiącu. Ile tej informacji potrzeba na raz? Tak naprawdę -w minimalistycznym wydaniu- wystarczyłoby kilkanaście bajtów (6 bajtów pozycja, 8 bajtów czas) – co daje 2,5MB. Jeśli jednak skorzystamy z popularnego lokalizatora, np takiego jak TK106, będzie to jednorazowo max ok. 150 bajtów, czyli miesięcznie <30MB.

Wystarczy w takim wypadku oferta na kartę SIM z taką ilością danych. Mnie udało się znaleźć kilka lat temu 300MB za 5PLN miesięcznie. Obecnie oferty ilości internetu ‚idą’ w stronę gigabajtów, więc to nie jest problemem.

Kolejnym wąskim gardłem wydaje się zasilanie lokalizatora. Musi on przecież pracować non-stop. I znów, wracając do rodziny lokalizatorów TK102, TK106 – praktyczny, średni pobór prądu to ok 70mA (tyle co cztery świecące diody LED). Czy to dużo? Wydaje się, że nie. Odwołując się do praktyki – samochód z akumulatorem o pojemności 60Ah – trzy lata pracy odbiornika – bez problemów.

Rozważania trochę z gotową tezą końcową 🙂 -wiem, to nie sztuka, jednak bazuję na swoich doświadczeniach, których oczywiście nie miałem zabierając się za pomysł.

Wracając do zasilania, w przypadku budowanego samodzielnie lokalizatora, odpowiednim wydaje się 5V, dla lokalizatorów gotowych – wspomnianych wcześniej, źródłem zasilania jest bateria wewnętrzna o napięciu 4,4V. W samochodzie / łodzi – akumulator 12V lub 24V.

Do wyboru klasyczny zasilacz liniowy np. na popularnym układzie 7805, lub przetwornica napięcia.

Lepszym rozwiązaniem wydaje się tutaj przetwornica z napięcia wejściowego (jakie właśnie mamy) na 4,5 – 5V.

Z uwagi na sprawność, cenę, (nie)wielkość i trwałość. Warto wspomnieć o zakresie temperatur pracy dla wszystkich elementów lokalizatora, będących faktycznie na zewnątrz. Zakładam, że będą osłonięte przed wodą i wilgocią, jednak temperatura lato/zima będzie oddziaływać na nie zawsze.

Przed rozbieraniem na czynniki drobniejsze, zerknąć warto jeszcze na pomysł serwera dla danych z lokalizatora. Sporo zależy tu od wymagań, czy planujemy jedynie wizualizację i odbiór, czy może komunikację dwustronną, bogatszą o możliwość uruchamiania urządzeń (alarmu, świateł, etc) z serwera. Pomiar temperatury lub …cokolwiek nam się marzy 🙂

Najprostsza wersja, działająca już na popularnym RaspberryPi (naprawdę wspaniałe na początek do nauki!) – to serwer Apache z PHP i bazą danych MySQL, stroną wizualizacji z JavaScript oraz mapami Google. Fajnie to poskładać samemu, planuję to opisać w dalszej części. Może być to także serwer na Flask lub Django, a wizualizacja – również z mapami Google – podobna jak tutaj:

http://django.wiks.eu/mmap

Ok. Szkic został sporządzony, zapraszam do następnego wpisu – lokalizator cz.2