Android ivmeölçer doğruluğu (Ataletsel navigasyon)


109

Bir Android telefon için bir Ataletsel Navigasyon Sistemini uygulamaya çalışıyordum, bunun ivmeölçer doğruluğu ve okumaların sürekli dalgalanması göz önüne alındığında zor olduğunu fark ettim.

Başlangıç ​​olarak, telefonu düz bir yüzeye yerleştirdim ve X ve Y yönlerinde 1000 ivmeölçer okuması örnekledim (masaya paralel, bu yüzden bu yönlerde yerçekimi hareket etmiyor). Daha sonra bu okumaların ortalamasını aldım ve bu değeri telefonu kalibre etmek için kullandım (bu değeri sonraki her okumadan çıkararak).

Daha sonra sistemi tekrar masaya yerleştirerek ve X ve Y yönlerinde 5000 ivmeölçer okumasını örnekleyerek test ettim. Kalibrasyon göz önüne alındığında, bu ivmelerin her yönde 0'a (kabaca) toplamasını beklerdim. Ancak durum böyle değildir ve 5000 yinelemenin üzerindeki toplam ivme hiçbir yerde 0'a yakın değildir (her eksende ortalama 10 civarında).

Kodumu görmeden bunu yanıtlamanın zor olabileceğini anlıyorum ama daha genel anlamda ...

Bu sadece bir cep telefonunda (HTC Desire S) ivmeölçer okumalarının ne kadar yanlış olduğuna dair bir örnek mi yoksa kodlamamda bazı hatalar yapmış olmam daha mı muhtemel?


1
webvr-polyfill harika bir ilham kaynağıdır: github.com/borismus/webvr-polyfill/tree/master/src ivme ölçer verilerini kullanarak bir VR sensörünü nasıl çoklu doldurduklarına bakın: github.com/borismus/webvr-polyfill/blob/master / src /…
SC

Yanıtlar:


128

Doğrusal ivmeyi iki kez entegre ederek konum elde edersiniz, ancak hata korkunçtur. Pratikte işe yaramaz.

İşte bir açıklama neden (Google Tech Talk) de 23:20 . Bu videoyu şiddetle tavsiye ediyorum.

Soruna neden olan ivmeölçer gürültüsü değil, gyro beyaz gürültüsüdür. , 6.2.3 Hataların Yayılması alt bölümüne bakın. (Bu arada, jiroskoplara da ihtiyacınız olacak.)

İç mekan konumlandırmaya gelince, bunları yararlı buldum:

RSSI Tabanlı İç Mekan Lokalizasyonu ve Sigma-Point Kalman Smoothers Kullanarak İzleme

Ayakkabıya Monte Atalet Sensörleri ile Yaya Takibi

Tek Bir İvme Ölçer Kullanarak Pedometrelerin Performansını Artırma

Bu yöntemlerin gerçek hayattaki uygulamalarda nasıl performans göstereceği veya onları güzel bir Android uygulamasına nasıl dönüştüreceği hakkında hiçbir fikrim yok.

Benzer bir sorudur bu .

GÜNCELLEME:

Görünüşe göre, yukarıdaki Oliver J. Woodman'dan daha yeni bir sürüm var, "Ataletsel navigasyona giriş", doktora tezi:

İç Mekanlar İçin Yaya Lokalizasyonu


2
Bunun uzun zaman önce olduğunun farkındayım, ancak devam edecek bir sorum var. Android JB'deki kamera, telefonu hareket ettirerek, döndürerek veya bir eksen boyunca doğrusal olarak hareket ettirerek panoramik bir resim çekmenizi sağlayan bir 'panorama' özelliğine sahiptir . Bunu yapmak için, telefonun konumunu nispeten doğru bir şekilde izlemesi gerekir - en azından bu yanıtın bağlantılarında videoda belirtilen 20cm / s hatasından daha iyi. Bunu nasıl yapıyor? Eylemsizlik takibinin kalitesini iyileştirmenin bir yolu var mı? Yoksa bunu sadece kamerayı kullanarak yapmak için akıllı görüntü işleme kullanıyor mu?
Tom

1
@Tom İkincisine inanıyorum, telefon resimleri yalnızca görüntü işleme algoritmalarıyla birleştiriyor. Telefonun bir panorama resim oluşturmak için konumunu takip etmesi gerektiğini düşündüren nedir? Bunu 90'lı yıllarda sıradan kameralarla yapmak mümkündü ve belli ki o zamanlar kameralarda ivmeölçerimiz yoktu :) Tabii ki resimler sıradan bir PC'ye dizilmişti. Ancak bunun için pozisyona ihtiyacınız yok, görüntü işleme algoritmaları yeterli. Bu yardımcı olur umarım.
Ali

Bu, eski manuel olarak bazı fotoğrafları çekip sonra dikme işinden oldukça farklı. Bir şekilde konumunu gerçek zamanlı olarak takip ediyor. Göstermeden açıklaması biraz zor. Manuel olarak fotoğraf çekmek zorunda değilsiniz - ne zaman başka bir fotoğraf çekmek için yeterince uzağa gittiğinize telefon karar verir. Siz resimleri çekerken, alt kısımda panoramanın önizlemesini içeren küçük bir çubuk gösterir. Kamerayı çok aşağıya çevirirseniz (örneğin), kamerayı tekrar yukarı hareket ettirmeniz gerektiğini bildirmek için bip sesi çıkarmaya ve yukarı ok göstermeye başlar.
Tom

2
Aslında görüntü işlemeyi kullanıyor gibi görünüyor - bir panoramayı başlatmak ve ardından elinizi kameranın önünde sallamak, konum izleme sistemini oldukça karıştıracaktır!
Tom

@Tom OK. Sanırım esas olarak görüntü işlemeyi kullanıyor (son yorumun da önerdiği gibi), ancak muhtemelen oryantasyonu izlemeyle birleştirilecek (ancak konumu değil).
Ali

19

Sadece sesli düşünüyorum ve henüz bir android ivme ölçer API ile oynamadım, bu yüzden bana katlanın.

Her şeyden önce, geleneksel olarak, ivmeölçerlerden navigasyon almak için 6 eksenli bir ivmeölçere ihtiyacınız olacaktır. X, Y ve Z'de hızlanmalara, aynı zamanda Xr, Yr ve Zr dönüşlerine de ihtiyacınız var. Döndürme verileri olmadan, cihazın tutumunu asla değiştirmediğini varsaymazsanız, bu oldukça sınırlayıcı bir vektör oluşturmak için yeterli veriye sahip olmazsınız. Zaten kimse Hizmet Şartları'nı okumaz.

Oh, ve INS'nin dünyanın dönüşüyle ​​sürüklendiğini biliyorsun, değil mi? Yani o da var. Bir saat sonra ve gizemli bir şekilde 15 ° 'lik bir yokuştan uzaya tırmanıyorsunuz. Bu, bir telefonun henüz yapamayacağı, konumu bu kadar uzun süre koruyabilen bir INS'ye sahip olduğunuzu varsayar.

Navigasyon için ivmeölçerleri (3 eksenli ivmeölçer ile bile) kullanmanın daha iyi bir yolu, INS'yi mümkün olduğunca kalibre etmek için GPS'e bağlanmaktır. GPS yetersiz kaldığında, INS güzel bir şekilde iltifat ediyor. Bir ağaca çok yaklaştığınız için GPS sizi aniden 3 blok öteden vurabilir. INS harika değil, ama en azından size bir meteor çarpmadığını biliyor.

Yapabileceğiniz şey, telefon ivme ölçer verilerini ve birçoğunu kaydetmek. Haftalar değerinde. Bunu iyi (gerçekten iyi demek istiyorum) GPS verileriyle karşılaştırın ve ivmeölçer verileri ile bilinen GPS verileri arasındaki eğilimlerin ilişkisini kurmak için veri işlemeyi kullanın. (Uzman ipucu: İyi geometriye ve çok sayıda uyduya sahip günler için GPS almanağı kontrol etmek isteyeceksiniz. Bazı günler yalnızca 4 uydunuz olabilir ve bu yeterli değildir) Yapabilecekleriniz, bir kişinin Cep telefonuyla yürürken ivmeölçer verileri çok özel bir model kaydediyor. Veri belirlemesine bağlı olarak, o cihaz için o kullanıcıyla bir profil oluşturursunuz ve GPS verisine sahip olduğunda bu modelin ne tür bir hızı temsil ettiğini belirlersiniz. Dönüşleri, merdiven çıkmayı, oturmayı algılayabilmelisiniz (0 hız süresine kalibrasyon! ) ve çeşitli diğer görevler. Telefonun nasıl tutulduğu tamamen ayrı veri girişleri olarak ele alınmalıdır. Veri madenciliği yapmak için kullanılan bir sinir ağı kokusu alıyorum. Başka bir deyişle, girdilerin ne anlama geldiğine kör bir şey. Algoritma, yalnızca kalıplardaki eğilimleri arar ve INS'nin gerçek ölçümlerine gerçekten dikkat etmez. Tek bileceğihistorically, when this pattern occurs, the device is traveling and 2.72 m/s X, 0.17m/s Y, 0.01m/s Z, so the device must be doing that now.Ve parçayı buna göre ilerletecekti. Tamamen kör olması önemlidir, çünkü cebinize bir telefon koymak, 4 farklı yönden birine ve cepleri değiştirirseniz 8'e yönlendirilebilir. Ayrıca telefonunuzu tutmanın birçok yolu var. Burada çok fazla veriden bahsediyoruz.

Açıkçası hala çok fazla sürükleneceksiniz, ancak bence bu şekilde daha iyi şansınız olacak çünkü cihaz yürümeyi ne zaman bıraktığınızı bilecek ve konumsal sürüklenme sürekli olmayacak. Geçmiş verilere göre hareketsiz durduğunuzu biliyor. Geleneksel INS sistemleri bu özelliğe sahip değildir. Sürüklenme, katlanarak gelecekteki tüm ölçümler ve bileşikler için devam eder. İnanılmaz doğruluk veya düzenli aralıklarla kontrol edilecek ikincil bir navigasyona sahip olmak, geleneksel INS için kesinlikle hayati önem taşır.

Her cihaz ve her kişinin kendi profiline sahip olması gerekir. Bu çok fazla veri ve çok fazla hesaplama. Herkes farklı adımlarla farklı hızlarda yürür ve telefonlarını farklı ceplere koyar, vb. Elbette bunu gerçek dünyada uygulamak, sunucu tarafında işlenecek numara hesaplamaları gerektirir.

Başlangıçtaki temel için GPS kullandıysanız, sorunun bir kısmı GPS'in zaman içinde kendi geçişlerine sahip olma eğiliminde olmasıdır, ancak bunlar kalıcı olmayan hatalardır. Bir alıcıyı tek bir yere yerleştirin ve verileri kaydedin. WAAS düzeltmesi yoksa, çevrenizde 100 fitlik rastgele yönlerde sürüklenen konum düzeltmelerini kolayca alabilirsiniz. WAAS ile belki 6 fit'e kadar. En azından YSA'nın algoritmasını düşürmek için bir sırt çantasında metre altı RTK sistemi ile daha iyi şansınız olabilir.

Benim yöntemimi kullanarak INS ile hala açısal kaymaya sahip olacaksınız. Bu bir problem. Ancak, n kullanıcı arasında haftalarca GPS ve INS verisi dökmek için bir YSA oluşturmak için bu kadar ileri gittiyseniz ve gerçekten bu noktaya kadar çalıştırdıysanız, açıkçası şu ana kadar büyük veriye aldırış etmiyorsunuz. Bu yolda ilerlemeye devam edin ve açısal kaymayı çözmeye yardımcı olmak için daha fazla veri kullanın: İnsanlar alışkanlığın yaratıklarıdır. Kaldırımlarda, kapılardan, merdivenlerden yukarı yürümek gibi hemen hemen aynı şeyleri yapıyoruz ve otoyollarda, duvarlardan veya balkonlardan yürümek gibi çılgınca şeyler yapmıyoruz.

Diyelim ki Big Brother'dan bir sayfa alıyorsunuz ve insanların nereye gittiğine dair verileri depolamaya başlıyorsunuz. İnsanların yürümesinin beklendiği yerlerin haritasını çıkarmaya başlayabilirsiniz. Oldukça kesin bir bahis, eğer kullanıcı merdivenlerden yukarı çıkmaya başlarsa, kendisinden önceki kişinin çıktığı merdivenle aynı basamakta olacaktır. 1000 yineleme ve en küçük kareler ayarlamasından sonra, veritabanınız bu merdivenlerin nerede olduğunu büyük bir doğrulukla bilir. Artık kişi yürümeye başladığında açısal kaymayı ve konumu düzeltebilirsiniz. O merdivenlere çarptığında veya o koridordan döndüğünde ya da bir kaldırımdan aşağı indiğinde herhangi bir kayma düzeltilebilir. Veritabanınız, bir kişinin oraya yürüme olasılığına veya bu kullanıcının geçmişte oraya gitmiş olmasına göre ağırlıklandırılan sektörler içerir. Mekansal veritabanları bunun için optimize edilmiştirdivide and conquersadece anlamlı olan sektörleri tahsis etmek için. Lazer donanımlı robotun siyah bir görüntü ile başladığı ve labirenti hafızaya boyadığı, her dönüşü alarak, tüm duvarların olduğu yeri aydınlattığı MIT projeleri gibi olurdu.

Trafiğin yoğun olduğu alanlar daha fazla ağırlık alır ve hiç kimsenin 0 ağırlık almadığı alanlar. Daha yüksek trafik alanları daha yüksek çözünürlüğe sahiptir. Esasen herhangi birinin bulunduğu her yerin bir haritasına sahip olursunuz ve bunu bir tahmin modeli olarak kullanırsınız.

Bu yöntemi kullanarak bir kişinin tiyatroda hangi koltukta oturduğunu belirleyebilirseniz şaşırmam. Sinemaya giden yeterli sayıda kullanıcı ve yeterli çözünürlük verildiğinde, tiyatronun her sırasını ve her sıranın ne kadar geniş olduğunu eşleyen veri elde edersiniz. Bir yeri ne kadar çok insan ziyaret ederse, o kişinin bulunduğunu tahmin edebileceğiniz doğruluk o kadar yüksek olur.

Ayrıca, bu tür şeylerle ilgili güncel araştırmalarla ilgileniyorsanız, GPS World dergisine (ücretsiz) abonelik almanızı şiddetle tavsiye ederim. Her ay bununla uğraşıyorum.


"Mümkün olduğunda INS'yi kalibre etmek için GPS'e bağlanmak olurdu. GPS yetersiz kaldığında, INS güzel bir şekilde iltifat ediyor." Anladığım kadarıyla Kalman filtrelemesi bunun için.
Diğerinin

8

Ofsetinizin ne kadar harika olduğundan emin değilim, çünkü birimleri eklemeyi unuttunuz. ("Her eksende 10 civarında" pek bir şey söylemiyor.: P) Yine de muhtemelen donanımdaki yanlışlıktan kaynaklanıyor.

İvme ölçer, telefonun yer çekimine göre yönünü belirleme veya hareketleri algılama (telefonu sallama veya çarpma vb.)

Bununla birlikte, ivmeölçeri kullanarak ölü hesaplama yapmaya çalışmak sizi birçok bileşik hataya maruz bırakacaktır. Aksi takdirde ivmeölçerin delice hassas olması gerekir ve bu yaygın bir kullanım durumu değildir, bu yüzden donanım üreticilerinin bunun için optimize ettiğinden şüpheliyim.


Cevap için teşekkürler. İvmeölçerler, dururken hem X hem de Y eksenlerinde yaklaşık -0,8 ms ^ -2 okurlar, bu yüzden bunu ofsetim olarak kullandım. "Yaklaşık 10" bit ile, 5000'den fazla yinelemenin, sensörden tek bir eksende her bir ivmenin toplamının kabaca 0 ms ^ -2 (ofsetin üzerinde ve altında eşit şekilde dalgalanması durumunda olacağı gibi) değer), ancak bunun yerine ivmeyi tek yönde daha fazla kaydetme eğilimindeydi, bu da pozisyon bulmak için çift entegrasyondan sonra telefonun dakikada 3 metre hareket ederken çalıştığını gördü.
woodstock365

Havacılık seyrüsefer terimi "ölü hesaplama" için +1. Her ne kadar ölü hesaplaşma, bir INS'den çok bir kamera ile gezinmeye daha uygun bir şekilde uygulanacaktır.
RyanJMcGowan

7

Android ivmeölçer dijitaldir, aynı sayıda "kova" kullanarak ivmeyi örnekler, diyelim ki 256 kova vardır ve ivmeölçer -2g ile + 2g arasında algılama yapabilir. Bu, çıktınızın bu "kova" cinsinden nicelleştirileceği ve bazı değerler kümesi etrafında atlayacağı anlamına gelir.

Bir android ivmeölçeri kalibre etmek için 1000 noktadan çok daha fazlasını örneklemeniz ve ivme ölçerin dalgalandığı "modu" bulmanız gerekir. Ardından çıktının ne kadar dalgalandığına göre dijital nokta sayısını bulun ve bunu filtrelemeniz için kullanın.

Modu ve +/- dalgalanmayı elde ettiğinizde Kalman filtrelemesini öneririm.


1
Kalibrasyon yöntemleri arıyordum. Görünüşe göre öneriniz ihtiyacım olan şey. Sadece onaylamam gerekiyor. Modu bulduğumda 0,5 olduğunu söyle. "O zaman çıktının ne kadar dalgalandığına bakarak dijital nokta sayısını bulun ve filtrelemeniz için kullanın." Lütfen biraz daha detaylandırır mısınız?
Nazerke

1
İvme ölçerin 256 çıkış noktasına sahip olduğunu ve okumalar arasında 0,015 m / s ^ 2 dalgalandığını varsayalım. Cihazınızı masanın üzerine koyduğunuzda, çıktınız 0,015 m / s ^ 2'nin katlarında bile dalgalanabilir. Diyelim ki 0 +/- (X * 0,015) okuma elde ettiniz. X'i bulmanız gerekir (çift sayı olacaktır). Örneğin benim X'im 3 olabilir. Bu durumda, ivmeölçer okumasındaki 0,045 m / s ^ 2'den daha az olan değişiklikleri görmezden gelirim
Alex Stone

yani android telefonlar ivmeölçerler henüz o kadar iyi değil .. doğru mu?
Techsin

4

Bunun oldukça eski olduğunun farkındayım, ancak eldeki konu verilen yanıtların HERHANGİ BİRİNE değinilmemiştir.

Gördüğünüz şey, yerçekimi etkisi de dahil olmak üzere cihazın doğrusal ivmesidir. Telefonu düz bir yüzeye yerleştirirseniz, sensör yaklaşık olan yerçekimine bağlı ivmeyi bildirecek ve 9.80665 m/s2böylece gördüğünüz 10'u verecektir . Sensörler doğru değil, ancak O KADAR hatalı değiller! Peşinde olabileceğiniz sensör hakkında bazı yararlı bağlantılar ve bilgiler için buraya bakın .


17
Hayır - sanırım şu soruyu yanlış anladınız: "... X ve Y yönlerinde okumalar (masaya paralel, dolayısıyla bu yönlerde yerçekimi hareket etmiyor)". 9,8 / s2, Z ekseninde olacaktır.
teapot7

0

X ve Y yönlerindeki ivmeölçer okumalarının, ki bu durumda tamamen donanım gürültüsü olan, ortalamanızda normal bir dağılım oluşturacağını varsayıyorsunuz. Görünüşe göre durum bu değil.

Deneyebileceğiniz bir şey, bu değerleri bir grafiğe çizmek ve herhangi bir modelin ortaya çıkıp çıkmadığını görmek. Aksi takdirde, gürültü istatistiksel olarak rastgeledir ve buna karşı kalibre edilemez - en azından belirli telefon donanımınız için.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.