android compass wydaje się zawodny
Pracowałem nad małą aplikacją compass w ciągu ostatnich kilku dni i uruchomiłem kod, ale wydaje się, że odczyt kompasu nie jest dokładny. Po kalibracji obu telefonów, mój pierwszy test, który znalazłem to w tym, co po prostu trzymałem telefon przed i płaska powierzchnia spojrzał na odczyt, a następnie odwrócił go poziomo i umieścił go na tej samej płaskiej powierzchni (Obrót 180*) i wartość nie zmieniła się 180 * było bliżej 240*.
Następnie przetestowałem czytanie vs kompas, czasami czytanie wydawało się być blisko, ale w innych punktach było więcej niż 50 * off. Próbowałem nawet umieścić mój telefon i kompas na podłodze, aby utrzymać kompasy z dala od jakichkolwiek zakłóceń magnetycznych z tymi samymi wynikami (Uwaga, trzymam również kompas i telefon osobno, utrzymując je w tym samym kierunku, ustawiając się w rzędzie z krawędziami książki).
Następnie umieściłem przykładową aplikację na innym telefonie (pierwszy był nexus S, drugi Motorola droid 1). Między dwoma telefonami różnica waha się od bycia równym w niektórych punktach, ale w większości punktów jest między 50 a 15 stopni off.
Przejrzałem dokumentację, a także przejrzałem wiele różnych postów na forum i nie widzę nikogo z takimi samymi wynikami. W moim kodzie może być jakiś mały błąd, który powoduje, że mój odczyt wychodzi nieprawidłowo, lub jakiś udokumentowany błąd, którego nie widzę.
Wszelkie spostrzeżenia lub sugestie będą bardzo mile widziane!!
Heres my on sensor zmieniony kod w mojej klasie SensorEventListener
public void onSensorChanged(SensorEvent event)
{
// If the sensor data is unreliable return
if (event.accuracy == SensorManager.SENSOR_STATUS_UNRELIABLE)
{
Toast.makeText(main.this, "Sensor Status Unreliable",Toast.LENGTH_SHORT).show();
}
// Gets the value of the sensor that has been changed
switch (event.sensor.getType())
{
case Sensor.TYPE_ACCELEROMETER:
m_vfgravity = event.values.clone();
break;
case Sensor.TYPE_MAGNETIC_FIELD:
m_vfgeomag = event.values.clone();
break;
}
if (m_vfgravity != null && m_vfgeomag != null)
{
if(SensorManager.getRotationMatrix(m_vfinR, m_vfI, m_vfgravity, m_vfgeomag))
{
SensorManager.getOrientation(m_vfinR, m_vforientVals);
m_fCompBearing = (float) Math.round((Math.toDegrees(m_vforientVals[0])) *2)/2;
//convert to 0-360 from -180-180
if(m_fCompBearing < 0.0)
{
m_fCompBearing = 360 + m_fCompBearing;
}
mCompHead.setText("" + (int)m_fCompBearing);
}
calcOffset();
rotateCmp();
}
}
I zakodować na create of my activity
mSMngr = (SensorManager) getSystemService(Context.SENSOR_SERVICE);
mSListener = new cSensorListener();
mSMngr.registerListener(mSListener,
mSMngr.getDefaultSensor(Sensor.TYPE_MAGNETIC_FIELD),
SensorManager.SENSOR_DELAY_UI);
mSMngr.registerListener(mSListener,
mSMngr.getDefaultSensor(Sensor.TYPE_ACCELEROMETER),
SensorManager.SENSOR_DELAY_UI);
Edit: wypróbowałem go również z droidem X z najgorszymi wynikami... Gdy telefon jest obracany wokół 45 stopni (obrócony wokół osi Z komputerowy układ współrzędnych), kurs kompasu może zmienić się o 180 stopni, w rzeczywistości wartość kursu idzie w przeciwnym kierunku do innych telefonów, gdy obraca się w tym samym kierunku. To jedyny telefon, który wytwarza ten wynik nawet po kalibracji w Ustawieniach. Również ich jest kompas live wallpaper testuję przeciwko, że nie ma tego samego problemu. Więc zakładam, że będzie coś, co mogę zrobić w oprogramowaniu, aby tego uniknąć.
3 answers
Mimo, że autor odpowiedział na własne pytanie, muszę tu po prostu wejść, aby wzmocnić niemal całkowitą bezużyteczność wszelkiego rodzaju funkcjonalności kompasu na platformie Android.
Doszedłem do wniosku, że każdy, kto jest uzależniony od aplikacji Android compass, prosi o kłopoty, żadna z nich nie działa niezawodnie i nie jest to wina dewelopera.
Google i mfg po prostu nie zapewniły sposobu na uzyskanie niezawodnej dokładności z tych urządzeń, a nawet aby ustalić czy dokładność jest wiarygodna co jest jeszcze gorsze ponieważ czasami tak jest a wiele razy nie i jeśli ktoś ufa tym urządzeniom do prawdziwego biegania na Orientację niech im pomoże.
Powodem, dla którego autor prawdopodobnie uważa, że osiąga lepsze wyniki, Jest to, że używają całkiem dobrego filtra szumów na przestarzałym czujniku orientacji ( dlaczego nie mogli tego zrobić w nowszej metodzie, jest poza mną ), a w ograniczonych testach na pojedynczym urządzeniu po kalibracji wydaje się to działać, ale w dziedzinie przy użyciu wielu urządzeń odkryłem, że w większości przypadków niezawodność jest zawsze kwestionowana.
Po pierwsze hałas generowany przez czujniki magnetyczne i orientacyjne są straszne, tak można to przezwyciężyć za pomocą odpowiednich technik DSP, a z telefonami z obsługą 2.3 i żyroskopem będzie ogólnie lepiej, ale wstydź się Google i Mfg za marnowanie tyle czasu programisty z tandetnymi implementacjami wyjść sprzętowych i programowych.
Po drugie, przetestowałem przynajmniej 18 telefonów z odpowiednim filtrowaniem DSP i chociaż to czyści szumy, nie pomaga to z dokładnością, nawet ten sam model telefonów ma różne wyjścia (choć niektóre modele wydają się lepsze niż inne) {]}
Po Trzecie masz niewiele w sposobie określenia, czy czujniki są skalibrowane, nawet wykonując spastyczny ruch 8 może lub nie może skalibrować telefonu, a użytkownik nigdy nie wie, czy działa, czy nie, chyba że masz kompas do sprawdzenia, który rodzaj pokonuje telefon prawda?
Uwaga: możesz pomnożyć i zsumować Czujniki magnetyczne ze sobą i wziąć pierwiastek kwadratowy tego sqrt (x*x+y*y+Z * z) i upewnić się, że jest to między 25 A 65 lub tak, jest to jeden wskaźnik, którego możesz użyć do wykrywania anomalnych pól, ale nie jest całkowicie niezawodny, lepiej niż nic, jak sądzę.
Po czwarte, wiele telefonów jest całkowicie zawodnych, skalibrowanych lub nie, co nie ogranicza się do typów modeli, ale prawdopodobnie tandetne QA ze strony mfg, naprawdę Nie wiem dlaczego, ale mogę powiedzieć, że 3 HTC ARIA przyniósł szalenie różne wyniki (JEDEN 30 stopni off, drugi 50, a trzeci prawie na miejscu) to samo z incredible, nexus, itp.
Przetestowałem 18 telefonów i wiele z nich było dość blisko dokładności, jeśli można było poprawnie skalibrować, ale wiele z nich zajęło 2-10 prób (sprawdzaliśmy po każdej próbie kalibracji z kompasem o wysokiej precyzji) i więcej niż kilka razy po prostu nie skalibrowały w ogóle.
Uwaga: musisz rozliczyć się z deklinacja dla prawdziwego przesunięcia północy, co możesz zrobić za pomocą API w Androidzie, jeśli masz dostęp do aktualnych współrzędnych GPS, wysokości, pory dnia itp. problemem nie była deklinacja, a jeśli porównujesz do kompasu, to i tak nie jest to problemem, ponieważ będzie to również wywoływane przez lokalne pola magnetyczne.
Fith, cold starts zawsze wymaga kalibracji każdego testowanego telefonu, który obejmuje X, The incredible, Aria, Nexus i Thunderbolt. Innymi słowy przy pierwszym uruchomieniu odsłuchu czujnika w 95% czasu będzie to wymagało kroku kalibracji (nawet zepsuty zegar jest odpowiedni dwa razy dziennie), więc jeśli nalegasz na dodanie tej funkcjonalności, po prostu powiedz użytkownikowi, aby to zrobił na początku każdego zdarzenia słuchacza.
Jeśli pozostawisz senory włączone (złe dla baterii), to może lub nie musi być ponownie kalibracji w zależności od pól jest napotkane) powyższa metoda Działa ok dla tego.
Najważniejsze jest to, że kiedy pracują, to wydaje się fajne, ale obecnie nigdy nie można być pewnym dokładności azymutu, co czyni je dość zawodnymi i bezużytecznymi do jakiejkolwiek prawdziwej pracy.
Osobiście użyłbym łożyska GPS podczas poruszania się, a następnie metody wektora obrotu, jeśli to możliwe, może to nie być idealne, ale byłoby o wiele lepiej niż craptacular implementacji, które masz w bieżącej linii telefonów do azymutu.
Sorry za dlugotrwala odpowiedz ale zmarnowalem prawie miesiac na probowanie aby to działało z pomocą eksperta DSP inżyniera i mamy prawie napisane o platformie android jako przydatnej w tym zakresie.
A" czasami to działa, innym razem nie, nigdy nie możesz być pewien, chyba że masz prawdziwy kompas " zastrzeżenie powinno być umieszczone w każdej aplikacji compass moim zdaniem.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-06-14 19:01:58
Po wielu testach i debugowaniu. Doszedłem do wniosku, że tak, jak niektórzy z was wspominali różnice w moim droid 1 i Nexus S były czysto sprzętową różnicą i interferencją magnetyczną.
Jednak Droid X był innym problemem, cokolwiek próbowałem, nie mogłem uzyskać poprawnych odczytów z zalecanego sposobu z getRotationMatrix i getOrientation, nawet po dodaniu funkcji współrzędnych re-map. Więc po jakimś majsterkowaniu bez powodzenia pomyślałem, że dam Czujnik orientacji strzela.
Google twierdzi, że ten sposób jest przestarzały i zalecają robienie tego tak, jak zaczynałem, jednak próbowałem wszystkich rodzajów kombinacji w ten sposób bez powodzenia. Więc zignorowałem Ostrzeżenie i użyłem czujnika orientacji ... i zadziałało. Dlaczego ? nie mam pojęcia, droid x jest nowszy od mojego droida 1, więc nie powinien mieć nic wspólnego z używaniem kodu starszego. Jednak ma sens, dlaczego aplikacje compass napisane do target 1.6 będą działać podczas moja aplikacja robi "zalecany sposób" nie działa.
Jeśli ktoś ma lepszy sposób, aby to zrobić, daj mi znać, lub jeśli znasz sposób, aby to działało z getRotationMatrix i getOrientation również powiedzieć.
W przeciwnym razie dla każdego, kto uderzy w tę ceglaną ścianę tak mocno, jak ja, oto kod, który zakończył się dla mnie.
Mój czujnik on zmienił
switch (event.sensor.getType())
{
case Sensor.TYPE_ORIENTATION:
m_vforientVals = event.values.clone();
break;
}
if(m_vforientVals != null)
{
m_fCompBearing = m_vforientVals[0];
mCompHead.setText("" + (int)m_fCompBearing);
calcOffset();
rotateCmp();
}
I zainicjalizuj słuchacz sensora
mSMngr.registerListener(mSListener,mSMngr.getDefaultSensor(Sensor.TYPE_ORIENTATION),
SensorManager.SENSOR_DELAY_NORMAL);
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-06-08 18:37:40
Twój kod wygląda dobrze, jeśli w Twoim kodzie pojawi się błąd, jestem prawie pewien, że oba urządzenia ucierpią na tym. Myślę, że to sprzęt w urządzeniach powoduje różnice. Czy "skalibrowałeś" oba kompasy przesuwając telefon w ośmiu kształtach? Sugeruje to wiele aplikacji compass, w tym oprogramowanie map dostarczane z urządzeniami symbian. To może zadziałać
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-06-06 19:59:33