Gdzieś między Polską a Niemcami, a szczególnie w NRD

Twit Programmers of the Year (4)

W pracy kończy mi się walka z programistycznymi twitami, przynajmniej w tym projekcie. Startuje powoli następny, oczywiście znowu o stopień trudniejszy (teraz będzie dużo wariantów z różną funkcjonalnością i procesor z symmetric multicore). No ale trzeba oszczędzać i pewnie mnie przy nim nie będzie, przynajmniej na początku (pewnie zawołają mnie dopiero jak się zacznie walić i palić) . Zobaczymy gdzie teraz trafię.
Ale za to w domu zabrałem się za eksperymenty z Androidem. Na początek spróbowałem działać z sensorami i też od razu natknąłem się na mnóstwo twitów:

  • Na początek zrootowałem swojego tableta (Acer Iconia A700). Nawet łatwo poszło.
  • Wgrałem mu custom recovery, całkiem fajnie działa
  • Wgrałem też mu custom system (CyanogenMod). Tu był problem - jest dużo programów instalujących ten system na zrootowanym urządzeniu, tyle że całkiem niedawno ten projekt przemianował się (na LineageOS) i w ogóle coś się pozmieniało i te starsze wersje zginęły z sieci. Żaden z instalatorów nie działa. Na szczęście znalazłem gdzieś w sieci odpowiedni kompilat (samemu skompilować jeszcze mi się nie udało) i wgrałem go na tableta. I to jest dobre, oryginalny Android ślimaczył się już straszliwie, a ten chodzi całkiem przyjemnie, można było wywalić cały bloatware i ma to parę funkcji więcej.
  • Pisałem wcześniej o problemach z emulatorem Androida, dałem sobie z nim spokój. USB debugging chodzi bardzo dobrze. Potem kupię sobie parę używanych urządzeń z różnymi rozdzielczościami.
  • USB debugging chodzi, tyle że nie na moim telewizorze. Philips ma politykę, że ich telewizory są nierootowalne, soft można instalować tylko z Google Play, a USB debugging mimo że można odblokować, to nie chodzi (tu jeszcze potencjalny problem połączenia USB-A z USB-A). Chociaż ostatnio trochę odpuścili, po niedawnym updacie opcja instalacji z innych źródeł się pojawiła, i co nieco narzędzi poinstalowałem. Debugging ma móc chodzić przez Ethernet, podobno komuś się z tym modelem telewizora udało, mi jeszcze nie. W ogóle to motywacja Philipsa jest "Bo jak zbrickujesz sobie telewizor za 2500 EUR to będziesz płakał" - tyle że mój telewizor był tańszy od mojej komórki i niewiele droższy od mojego tableta. Uprzedzając pytanie: Nie, nie mam komórki za 2500+.
  • No to zacząłem od tableta. Na początek postanowiłem zapoznać się z obsługą sensorów. Jest do tego mnóstwo przykładowego kodu w sieci.
  • Analiza kodu i zależności fizycznych pokazała, dlaczego niemal wszystkie (o ile nie wszystkie) programy robiące za kompas są do niczego. Przyczyny są dość skomplikowane, ale do pojęcia. Objaśnię je, bo to ciekawe:
    • Niemal każda komórka ma akcelerometr, którym można ustalić kierunek "w dół" (to tam, gdzie statycznie mamy przyspieszenie 1g), żyroskop do obrotów i magnetometr, pokazujący kierunek na magnetyczną północ
    • GPS podaje geolokalizację urządzenia, ale nie w którą stronę jest obrócone, więc GPS się do kompasowania nie nadaje.
    • Magnetometr podaje kierunek wprost (przez Ziemię) do bieguna magnetycznego.  Znaczy to jest (jak u nas) jakieś 40º do poziomu.
    • Duża część programów na kompas bierze po prostu składową magnetyczną w płaszczyźnie urządzenia, relatywnie do jego osi Y. Ale jak trzymać urządzenie w ręku i pochylić je trochę do siebie, to ta płaszczyzna ustawia się paskudnie blisko prostopadłości do żądanego wektora, całą dokładność szlag gwałtowny trafia i kompas kręci się na chybił-trafił.
    • Sytuację może poprawić użycie kombinacji  sygnałów z akcelerometru i magnetometru.
    • W zasadzie coś takiego jest dostępne jako wirtualny sensor pozycji urządzenia, tyle ta funkcja zrobiła się deprecated lata temu (od v2.2.x, około 2010).
    • Ponieważ nowe rozwiązanie wymaga jednego calla więcej i trochę zrozumienia (słowo kluczowe: quaternion), prawie nikt nie jest w stanie tego pojąć i prawie wszyscy robią to po staremu.
    • Nawet po nowemu, to pokazuje kierunek na północ magnetyczną, a nie na "prawdziwą" północ.
    • Znając geolokalizację (z GPS-u) można od systemu dostać wartość poprawki żeby pokazać prawdziwą północ, ale nie znalazłem jeszcze ani jednego przykładu żeby ktoś to zrobił. Ja też jeszcze nie załapałem w którym momencie trzeba wykonać jaką operację na quaternionach, ale dojdę do tego.
    • Nawet jak zrobić to dobrze, pokazywany kierunek będzie zakłócany przez zewnętrzne pola magnetyczne.
    • Generalnie wszystkie te programy są zrobione maksymalnie prosto - obracają obrazek igły kompasu zależnie od danych z sensora. Nie będzie to sensownie działać (nawet porządnie zrobione) jak nie trzymać komórki poziomo. Mam pomysł znacznie lepszego interfejsu użytkownika. I jeszcze parę innych pomysłów na aplikacje związane z kompasem.
    • Dlaczego cała ta kombinacja składowych do orientowania się na prawdziwą północ nie jest dostępna jako proste API?
  • Jeszcze generalna uwaga co do API Androida: W całym tym API nie są w ogóle deklarowane wyjątki jakie funkcje mogą rzucać (deklaracja throws). Jak dla mnie to jest zupełnie podstawowy brak w designie - nieprzemyślana obsługa błędów.

Ładnie się zaczyna. Ciekawe jak będzie dalej.

-----------------------------------------------------------------------------------------------------------------------

Dotyczy: , ,

Kategorie:Pomyślmy, Programowanie

Sledz donosy: RSS 2.0

Wasz znak: trackback

-----------------------------------------------------------------------------------------------------------------------


24 komentarzy do “Twit Programmers of the Year (4)”

  1. charliebravo pisze:

    @Android
    Dlatego ja się wolę jednak iOSem bawić
    @kompas
    1) A to nie jest tak, że optymalnie byłoby wykrywać, że user trzyma urządzenie tak, że „kierunek na biegun” (ZTCP inklinacja magnetyczna) wychodzi jak piszesz, przy pionowej osi urządzenia, i informować delikwenta, żeby przekręcił urządzenie?
    2) Uwzględnianie deklinacji: kwaternion można potraktować jako reprezentację położenia (w sensie orientation). Można go konwertować do innych reprezentacji, na przykład „Euler angles”. Potem wystarczy wybrać właściwy kąt i dodać do niego algebraicznie poprawkę na deklinację, nie?

    • cmos cmos pisze:

      @iOS
      Na pewno też jakieś twity przy nim były, cudów nie ma. Kiedyś też sobie go obejrzę.

      @kompas
      1) Wszystko można, problem jest nie w systemie, tylko w programistach-amatorach. Wymyśliłem fajny program oparty na kompasie i poszukałem co podobnego jest dostępne – nawet ten najlepszy jaki znalazłem w niektórych położeniach urządzenia sobie nie radzi (zwłaszcza na tablecie, bo on ma default orientation landscape, inaczej niż komórka), a nawet mi się parę razy wywalił.
      2) Zdaje się że to jest nawet prościej, poprawka to nawet nie kwaternion, tylko normalny kąt w płaszczyźnie poziomej, który trzeba dodać na sam koniec. Ale jeszcze tego nie sprawdziłem własnoręcznie.

      • charliebravo pisze:

        @iOS
        Oczywiście, ale to i tak co najmniej o poziom lepsze niż Android. I praktycznie nie ma fragmentacji, to jest właściwie jedna platforma sprzętowa więc wszystko dużo lepiej działa.
        @kompas
        To miałem na myśli – poprawka to nie kwaternion tylko skalar, wartość deklinacji magnetycznej jak w nawigacji. A jeśli położenie jest reprezentowane kwaternionem, to tego można łatwo przeliczyć na reprezentację kątową obrotów wokół dowolnie wybranych osi.
        @pomysły na aplikacje nawigacyjne
        To oczywiście kompletnie niepotrzebne w dobie GPSa i reszty, ale zastanawiałem się kiedyś czy nie dałoby się na komórce/tablecie zrobić aplikacji naśladującej automatyczny system astronawigacyjny z Blackbirda. Tam było tak że się go odpalało przed startem, dawało mu się „zorientować” i potem ponoć z wielką precyzją podawał położenie.
        Biblioteki astronomiczne są, optyka pewnie wystarczyłaby do zrobienia czegoś takiego w nocy (w dzień to już mocno wątpię), mocy obliczeniowej więcej niż trzeba, może się kiedyś pobawię ;-)

        • cmos cmos pisze:

          To oczywiście kompletnie niepotrzebne w dobie GPSa
          To dyskusyjne – sam GPS nie daje kompasu, tylko położenie. Kompas trzeba robić innymi metodami, to ograniczenie systemowe nawigacji satelitarnej, a nie wina Androida czy słabych programistów. Kompas magnetyczny słaby jest i wrażliwy na zewnętrzne pola magnetyczne, zastąpienie go czymś solidniejszym byłoby pożądane. W dodatku daleko nie wszystkie komórki sensor magnetyczny mają.

          W moim pierwszym pomyśle nie chodzi o kolejną imitację kompasu z igłą, to co mam na myśli robią tylko bardzo specjalizowane urządzenia. Jest też parę aplikacji w sklepie, ale żadnej bez poważnych wad, nawet ta najlepsza się wali i nie uwzględnia wszystkich sytuacji.
          Mam też drugi pomysł – kompas z UI kopiującym klasyczny, analogowy kompas z igłą, pokazuje coś z sensem tylko jak trzymać urządzenie poziomo. Co w marszu (i nie tylko) nie jest zbyt wygodne, mam dużo lepszą koncepcję UI.

          @astronawigacja Blackbirda
          Słabo to widzę z przyczyn technicznych. Blackbird na pewno robił to w sposób ciągły przy pomocy kamery obejmującej górną półsferę przez cały czas. W komórce, jak chcesz widzieć co pokazuje, musisz skierować kamerę mniej lub bardziej w ziemię, a jak kamera ma widzieć gwiazdy to Ty nie będziesz widzieć ekranu. Chodzenie z głową zadartą do góry nie jest rozwiązaniem. Możesz oczywiście użyć dodatkowej kamery umieszczanej na głowie, ale w tym momencie zaczynam wątpić, czy ktokolwiek by chciał takiego rozwiązania użyć.
          Plus jeszcze wszystkie problemy z light pollution, których Blackbird nie ma.

          • charliebravo pisze:

            @”To dyskusyjne – sam GPS nie daje kompasu, tylko położenie.”
            Moje „niepotrzebne” odnosiło się do astronawigacji w stylu Blackbirda, nie do Twojej aplikacji.
            @astronawigacja Blackbirda
            Nie no, jasne, raczej nie z komórki trzymanej w dłoni w marszu, raczej położonej na stole czy innym stabilnym podłożu. Zwłaszcza że w przeciętnej komórce pewnie nie dałoby się zrobić znośnego (z nierozmytymi gwiazdami) zdjęcia „z ręki”. W gruncie rzeczy to mógłby być program na laptopa operujący na gotowym zdjęciu nawet. Light pollution akurat wątpię, żeby było problem, gwiazdy to jednak bardzo punktowe źródła światła i żadne light pollution tego nie zmieni – najwyżej będą się mniej wyraźnie odcinać.

  2. piotru pisze:

    Bardzo ciekawy temat czujnikow zaawartych w telefonach komorkowych i sposobie ich dzialania .

    Zaczalbym od zastanowienia sie na dokladnoscia tyc urzadzen , kazdy czujnik ma pewna dokladnosc dzialnia , wydaje mi sie ze pomijajac kwestie poziomu telefonu ( tableta ) to dokladnosc nie jest zbyt duza .

    Deklinacja bo o tym tu mowimy w naszej szerokosci geograficznej wynosi od 4 do 5 stopni ( roznica pomiedzy wskazaniem bieguna magnetycznego a faktycznei geograficznego ) Jesli uwzglednimi blad pomiaru urzadzenia to moze sie okazac ze i tak nie jest to dokladne.

    Oczywiscie GPS nie wskazuje kierunku ale juz jesli ruszymy to gps wyliczy nam dokladnie kierunek duzo dokladniej niz kompas.Oczywiscie jak bedzie widoczny sygnal z satelitow . Ale chyba poza ciasnymi dolinami lub kanionami z budynkow raczej nam sie to nie przydazy

    A teraz troche praktyki :

    Te czujniki to taki troche gadzet . W praktyce trudno je wykorzystac ze wzgledu na to ze obarczone sa bledem oraz wplywaja na nie zaklocenia magnetyczne . O ile na morzu lub w powietrzu da sie je skompensowac ( to robi sie na specjalnym stanowisku – dla samolotow ) W praktyce na ziemi wystarczy mam wskazanie kierunku z dokladoscia do 15 stopni co i tak jest za duzo . Nie jestesmy sie w stanie przemieszczac idelanie wedlug kursu magnetycznego . Na wodzie czy w powietrzu i tak musimy jeszcze uzwzglednic dzialnie pradow czy tez wiatru a tu busola niewiele nam pomoze . Na przyklad duzo dokladniejsze urzadzenie VOR w samolotach ma blad pzynajmniej 2 stopnie .

    Na koneic napisze tylko ze jestem pelen podziwu dla ludzi ktorzy w latach pionierskich lotnictwa wyprawiali sie w swiat przy uzyciu tylko busoli i sekstansu i udawalo im sie przeleciec przez atlantyk czy tez ocean spokojny.
    Tak wiec nie ma sie co dziwic ze programisci za bardzo sie nie przykladaja do tego , no bo poco.

    • divak2 pisze:

      Jest facet , który opłynął ziemię nie zabierając żadnych przyrządów navigacyjnych. Żeglarze polinezyjscy z kolei uzywali „map” plecionych ze sznurka i bezbłędnie trafiali w swoje wyspy.

      Wskazanie kompasu jest obarczone błędem na który sklada sie odchylenie południka magnetycznego od geograficznego (deklinacja)i zakócenia pochodzące od pól magnetycznych wytwarzanych przez magnetyki znajdujące się w pobliżu kompasu (dewiacja). I dawni nawigatorzy pracowicie sumowali poprawki odczytywane z map, podających deklinację dla danej okolicy, i z tabeli dewiacji wyznaczonej dla statku przez porónanie wskazania kompasu z kursem jednostki (wykorzystując nabieżniki czy żyrokompas) Ogólnie wyznaczanie dewiacjito była dość żmudna robota i trzeba było to robić co jakiś czas, nawet dla jednostek drewanianych wyposażonych np. w silnik. Kompasy montowano w obudowach , do których mocowano magnesy kompensacyjne (te kolorowe kulki), żeby wskaznia nie wariowały zanadto. Nawet w jakiejś książce o żeglarstwie spotkałem się z uwagą że oświetlenie kompasu nie powinno pobierać prądu większego niż, bo zakóci wskazania.

      Wyobraźmy sobie poprawkę jaką trzeba dodać do wskazania apki kompasowej działającej na telefonie zanjdującym się w samochodzie, mając dodatkowo w pamięci to, co napisał Gospodarz.

      • cmos cmos pisze:

        Wyobraźmy sobie poprawkę jaką trzeba dodać do wskazania apki kompasowej działającej na telefonie zanjdującym się w samochodzie, mając dodatkowo w pamięci to, co napisał Gospodarz.

        Nie ma co sobie wyobrażać – jest do tego specjalna funkcja API, a wszystkie potrzebne dane są w systemie. Jedyny, ewentualny problem jest, że te dane są sprzed kilku lat i jak dotąd nie były zaktualizowane (chodzi o przesunięcie bieguna magnetycznego), to cały czas chodzi na prognozie. Podejrzewam, że kupienie tych danych kosztowało jakiś wagonik stóweczek i aktualizacja będzie nieprędko.

        • divak2 pisze:

          Nie o to mi chodziło. Deklinację na mapach ozanaczano „x stopni, y minut w roku 2010, rocznie algebraicznie dodawać tyle a tyle.” I to zazwyczaj wystarczało do bezpiecznego prowadzenia statku. Wystarcza pewnie i dla API. Natomiast jest pytanie czy apka kompasowa umie skompensować zakłocenia pola magnetycznego pochodzące od namagnesowanych przedmiotów (np. karoseria i silnik samochodu) znajdujących się w pobliżu magnetometrów?

          • cmos cmos pisze:

            Oczywiście że wpływu zewnętrznych pól magnetycznych nie da się automatycznie skompensować w aplikacji. Przecież nawet kompasy magnetyczne na statkach (stalowych przecież) trzeba kalibrować po instalacji, bo inaczej nie będą działać poprawnie. (Znaczy w ogóle na statkach już od dawna używa się żyrokompasów, a magnetycznych to tylko jako backup backupu).
            Bardziej mnie zastanawia, czy apki używające kompasu działają poprawnie w północnej Kanadzie, relatywnie blisko bieguna magnetycznego. O Antarktydę martwiłbym się mniej, mimo że wektor pokazujący na biegun północny będzie tam prawie równoległy do pokazującego na środek Ziemi i o jakiejkolwiek dokładności można zapomnieć. Tyle że tam nikomu nie przyjdzie do głowy używanie smartfona. Ale na Patagonii, to już może być trochę problem.

  3. krwawykrolik pisze:


    Jeszcze generalna uwaga co do API Androida: W całym tym API nie są w ogóle deklarowane wyjątki jakie funkcje mogą rzucać (deklaracja throws). Jak dla mnie to jest zupełnie podstawowy brak w designie – nieprzemyślana obsługa błędów.

    To chyba jest problem z designem Javy (checked vs unchecked exceptions).

    • cmos cmos pisze:

      Chyba jednak nie – API powinno mieć jakieś swoje wyjątki, i nic nie stoi na przeszkodzie żeby były checked. Ten „problem z designem Javy” którym niektórzy argumentują, to tylko żałosne usprawiedliwianie własnej indolencji. Ja tam uważam, że ten pomysł z checked/nonchecked wcale nie jest zły, zresztą w poprzedniej robocie robiliśmy porządną obsługę błędów w Javie i wszystko chodziło jak trzeba.

      • krwawykrolik pisze:

        To ja chyba nie zrozumialem Twojej obiekcji. Chodzi Ci o to, ze API Androida nie uzywa checked exceptions, czy ze nie zadeklarowali wlasnej hierarchii klas do wyjatkow, czy o cos innego?

        • cmos cmos pisze:

          Chodzi mi o to, że nie używają checked exceptions. Powinno być jasne, jakie błędy mogą być sygnalizowane, a jak są checked, to wiadomo czy i gdzie są obsługiwane. To bardzo pomaga w pisaniu porządnych programów. Tymczasem duża część programów z Google Play się po prostu w pewnych sytuacjach albo na niektórych urządzeniach wywala – a to na pewno w co najmniej 99% przypadków po prostu nieobsłużony wyjątek.

          • krwawykrolik pisze:

            Ja jestem przeciwnikiem checked exceptions. Bezpieczenstwo ktore rzekomo maja dawac jest iluzoryczne, za to wymagaja duzo „boiler plate code”. W dodatku refactoring kodu uzywajacego checked exceptions to droga przez meke, bo dodanie nowej deklaracji rzucanego wyjatku do jednej funkcji powoduje kaskade zmian w kodzie ktory tej funkcji uzywa – wiec ludzie unikaja tego. A jak sie chce usunac deklaracje, to jest jeszcze fajniej, bo niby jak znajdziesz wszystkie deklaracje ktore przez usuniecie pierwszej staly sie zbedne?

          • cmos cmos pisze:

            Bezpieczenstwo ktore rzekomo maja dawac jest iluzoryczne

            Mówisz, że bez konieczności deklaracji jest równie bezpiecznie? Chyba jednak trochę mniej. Jak sprawdzasz, czy gdziekolwiek obsłużyłeś exception rzucony gdzieś głęboko?

            za to wymagaja duzo „boiler plate code”

            Nie, no weź, nie przesadzasz trochę? Przecież to działa tak:

            • W funkcji która rzuca exceptiony deklarujesz je jako throws
            • W funkcji która woła tą funkcję, jeżeli nie obsługujesz jakiego exceptiona, musisz dodać go do deklaracji throws tej funkcji. Jeżeli tego nie zrobisz, dostajesz warning czy też error (nie pamiętam dokładnie)
            • Jeżeli obsługujesz ten exception, to i tak masz ten kod, czy exception jest checked, czy nie

            I to wszystko. Gdzie tu masz boilerplate code?

            refactoring kodu uzywajacego checked exceptions to droga przez meke

            Powiedzmy sobie otwarcie, że napisanie dobrego, niezawodnego programu to jest droga przez mękę. Tyle że do wyboru są dwie różne drogi: Można się męczyć robiąc od razu porządnie, dobrze i kontrolowanie, albo oszczędzić sobie tej męki. Tyle że wtedy jeszcze większa męka jest ze znajdowaniem tych wszystkich błędów, których można było uniknąć męcząc się przy robieniu dobrze.

            niby jak znajdziesz wszystkie deklaracje ktore przez usuniecie pierwszej staly sie zbedne?

            Checkstylem, czy podobnymi narzędziami? Trochę wypadłem z Javy i nie pamiętam na pewno, ale chyba checkstyle pokazuje to bezproblemowo i od razu.

  4. krwawykrolik pisze:

    Mówisz, że bez konieczności deklaracji jest równie bezpiecznie?

    Tak, dlatego ze w Javie nie ma odpowiednika deklaracji „nothrow” z C++. Wiec funkcja deklarujaca jakie checked exceptions rzuca moze i tak rzucic jakims unchecked exception #icomipanzrobisz

    Gdzie tu masz boilerplate code?

    Wlasnie wszystkie te deklaracje dodawane do funkcji ktore i tak przekaza ten wyjatek dalej, bo obslugiwany jest wyzej.

    Można się męczyć robiąc od razu porządnie, dobrze i kontrolowanie

    Tak, ale IMHO checked exceptions to nie jest dobry sposob meczenia sie.

    Checkstylem, czy podobnymi narzędziami?

    Nigga, plz. Nie wierze ze to zadziala na 100%.

    • cmos cmos pisze:

      moze i tak rzucic jakims unchecked exception #icomipanzrobisz!

      Znaczy „Jak nie mam kaloszy, to parasola nie ma sensu zabierać”?

      Wlasnie wszystkie te deklaracje dodawane do funkcji

      No weź, przecież to informacja semantyczna, a nie żadne boileplate. Deklarację typu zwracanego przez funkcję też uważasz za boilerplate? W końcu C potrafi działać i bez tego (nie mówiąc o takim na przykład Perlu), znaczy niepotrzebne.

      Tak, ale IMHO checked exceptions to nie jest dobry sposob meczenia sie.

      Zaproponuj lepszy w tym temacie. Jak gwarantujesz, że obsłużyłeś wszystkie twoje wyjątki?

      Nie wierze ze to zadziala na 100%.

      Nigga, plz, przecież to proste. W godzinkę napisałbym skrypt który to sprawdzi w 95%, po następnych dwóch będzie 100%. Tylko po co, skoro już takie są, jako plugin do Eclipsa.

Skomentuj i Ty

Komentowanie tylko dla zarejestrowanych i zalogowanych użytkowników. Podziękowania proszę kierować do spamerów