Точність Android акселерометра (інерційна навігація)


109

Я розглядав можливість впровадження Інерціальної системи навігації для Android-телефону, що, як я розумію, важко враховуючи точність акселерометра та постійне коливання показань.

Для початку я встановив телефон на плоску поверхню і відібрав 1000 показань акселерометра в напрямку X і Y (паралельно таблиці, тому гравітація не діяла в цих напрямках). Потім я усереднював ці показання і використовував це значення для калібрування телефону (віднімаючи це значення від кожного наступного читання).

Потім я перевірив систему, знову помістивши її на стіл і відібравши 5000 показань акселерометра в напрямку X і Y. Я б очікував, враховуючи калібрування, що ці прискорення повинні складати до 0 (приблизно) в кожному напрямку. Однак це не так, і загальне прискорення понад 5000 повторень ніде не дорівнює 0 (в середньому близько 10 на кожній осі).

Я розумію, не бачачи свого коду, це може бути важко відповісти, але в більш загальному сенсі ...

Це просто приклад того, наскільки неточні показання акселерометра на мобільному телефоні (HTC Desire S), чи більш ймовірно, що я зробив деякі помилки в кодуванні?


1
webvr-polyfill - чудове джерело натхнення: github.com/borismus/webvr-polyfill/tree/master/src дивляться, як вони заповнюють VR-датчик за допомогою даних акселерометра: github.com/borismus/webvr-polyfill/blob/master / src /…
SC

Питання , який також вважає , гіроскоп: stackoverflow.com/questions/8264518 / ...
Чіро Сантіллі郝海东冠状病六四事件法轮功

Відповіді:


128

Ви отримуєте позицію, інтегруючи лінійне прискорення двічі, але помилка жахлива. Це марно на практиці.

Ось пояснення, чому (Google Tech Talk) о 23:20 . Я настійно рекомендую це відео.

Проблему викликає не шум акселерометра, а шум гіроскопа білого кольору , див. Підрозділ 6.2.3 Поширення помилок. (До речі, вам знадобляться і гіроскопи.)

Щодо позиціонування в приміщенні, я вважаю це корисним:

Локалізація та відстеження в приміщенні на основі RSSI за допомогою згладжувачів Sigma-Point Kalman

Відстеження пішоходів за допомогою вбудованих інерційних датчиків

Підвищення продуктивності крокомірів за допомогою єдиного акселерометра

Я поняття не маю, як ці методи будуть працювати в реальних додатках або як їх перетворити в приємне додаток для Android.

Аналогічне питання це .

ОНОВЛЕННЯ:

Мабуть, є новіша версія, ніж вищезгадана Олівер Дж. Вудман, "Вступ до інерціальної навігації", його докторська дисертація:

Локалізація пішоходів для приміщень у приміщенні


2
Я усвідомлюю, що це вже давно, але у мене з’явилося запитання. Камера в Android JB має функцію "панорама", яка дозволяє робити панорамне зображення, переміщуючи телефон, обертаючи його або переміщуючи його лінійно по одній осі. Для цього потрібно порівняно точно відслідковувати положення телефону - принаймні краще, ніж помилка 20 см / с, згадана у відео, на яку посилається ця відповідь. Як це робиться? Чи є якийсь спосіб покращення якості інерційного відстеження? Або для цього використовується розумна обробка зображень, використовуючи лише камеру?
Том

1
@Тому я вважаю, що останнє, телефон об'єднує фотографії лише алгоритмами обробки зображень. Що змушує вас думати, що телефон повинен відслідковувати своє положення для отримання панорамного зображення? Це можна було зробити зі звичайними камерами ще в 90-х, і зрозуміло, у нас тоді не було акселерометрів у камерах :) Звичайно, знімки були об'єднані на звичайні ПК. Але для цього вам не потрібна позиція, алгоритмів обробки зображень достатньо. Сподіваюся, це допомагає.
Алі

Це зовсім інше, ніж старі завдання вручну - робити-фотографувати, а потім зшивати-пізніше. Він якось відстежує свою позицію в режимі реального часу. Це трохи складно пояснити, не демонструючи цього. Не потрібно робити фотографії вручну - телефон вирішує, коли ви переїхали досить далеко, щоб зробити ще одну. Під час фотографування він показує невелику смужку внизу з попереднім переглядом панорами. Якщо навести камеру занадто далеко вниз (наприклад), вона починає звучати та показувати стрілку вгору, щоб сказати, що вам потрібно перемістити її вгору.
Том

2
Насправді, здається, використовується обробка зображень - запуск панорами, а потім розмахуючи рукою перед камерою досить сильно заплутає її систему відстеження позицій!
Том

@Tom OK. Я думаю, що він в основному використовує обробку зображень (як свідчить і ваш останній коментар), але, ймовірно, це поєднується з відстеженням орієнтації (але не позиції).
Алі

19

Я просто думаю вголос, і я ще не грав з API акселерометра для андроїд, тому нехай поводиться зі мною.

Перш за все, традиційно для отримання навігації з акселерометрів вам знадобиться 6-вісний акселерометр. Вам потрібні прискорення в X, Y і Z, а також обертання Xr, Yr і Zr. Без даних обертання у вас не вистачає даних для встановлення вектора, якщо ви не припускаєте, що пристрій ніколи не змінює своє ставлення, що було б досить обмежувально. Ніхто так і не читає TOS.

О, а ви знаєте, що INS пливе з обертанням землі, правда? Так що теж є. Через годину, і ви загадково піднімаєтесь на 15 ° схил у космос. Це припущення, що у вас був INS, здатний підтримувати розташування так довго, чого телефон ще не може зробити.

Кращим способом використання акселерометрів (навіть з 3-вісним акселерометром) для навігації буде прив'язка до GPS для калібрування INS, коли це можливо. Там, де GPS не вистачає, INS добре компліментує. GPS може раптом відстріляти вас за 3 квартали, тому що ви занадто близько до дерева. INS не великий, але, принаймні, він знає, що вас не вдарив метеор.

Що ви можете зробити, це записувати дані акселерометра телефонів, і їх багато. Як тижні варті. Порівняйте їх із хорошими (я маю на увазі дуже хорошими) GPS-даними та використовуйте datamining для встановлення співвідношення тенденцій між даними акселерометра та відомими даними GPS. (Про поради: Вам потрібно буде перевірити GPS-альманах протягом днів з хорошою геометрією та безліччю супутників. Деякі дні у вас може бути лише 4 супутники, а цього недостатньо) Що ви можете зробити, це виявити, що коли людина гуляє зі своїм телефоном у кишені, дані акселерометра записують дуже специфічну схему. Виходячи з передачі даних, ви встановлюєте профіль для цього пристрою, з цим користувачем, і яку швидкість представляє ця картина, коли у неї були дані GPS, що йти разом з ним. Ви повинні вміти виявляти повороти, підніматися по сходах, сідаючи (калібрування до 0 швидкостей! ) та різні інші завдання. Те, як утримується телефон, потрібно розглядати як окремий вхід даних. Я відчуваю запах нейронної мережі, що використовується для обміну даними. Щось сліпе до того, що означають входи, іншими словами. Алгоритм шукав би лише тенденції у закономірностях, а не реально звертав увагу на фактичні вимірювання INS. Все, що вона знала б, цеhistorically, 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.І це відповідно перемістить частину вперед. Важливо, щоб він був абсолютно сліпим, тому що просто поміщаючи телефон у кишеню, можна орієнтуватися в одній з чотирьох різних орієнтацій і 8, якщо ви переключите кишені. І існує також багато способів тримати телефон. Ми говоримо тут багато даних.

У вас, очевидно, все ще буде багато дрейфу, але я думаю, вам би пощастило таким чином, оскільки пристрій знатиме, коли ви перестанете ходити, а позиційний дрейф не буде увічненням. Знає, що ти стоїш нерухомо на основі історичних даних. У традиційних системах INS немає цієї функції. Дрейф утримується в усіх майбутніх вимірюваннях і з'єднаннях експоненціально. Нечесна точність або наявність вторинної навігації, яку слід перевіряти через рівні проміжки часу, абсолютно важлива для традиційних INS.

Кожен пристрій і кожна людина повинні мати свій профіль. Це багато даних і багато розрахунків. Кожен рухається з різною швидкістю, з різними кроками, і кладе свої телефони в різні кишені і т. Д. Напевно, щоб реалізувати це в реальному світі, знадобиться обробка чисельних номерів на стороні сервера.

Якщо ви використовували GPS для початкової базової лінії, частина проблеми полягає в тому, що GPS має тенденцію до власних міграцій у часі, але вони не є постійними помилками. Помістіть приймач в одному місці та запишіть дані. Якщо виправлень WAAS немає, ви можете легко виправити місцеположення, що рухаються у випадкових напрямках на відстані 100 футів навколо вас. З WAAS, можливо, до 6 футів. Насправді, вам може пощастить із системою RTK під вимірювачем на рюкзаку, щоб принаймні знизити алгоритм ANN.

Ви все одно будете мати кутовий дрейф з INS, використовуючи мій метод. Це проблема. Але, якщо ви зайшли так далеко, щоб створити АНН, щоб викласти на тиждень варті дані GPS та INS серед російських користувачів, і насправді ви працюєте до цього моменту, ви, очевидно, не заперечуєте над великими даними. Продовжуйте цей шлях і використовуйте більше даних, щоб допомогти вирішити кутовий занос: Люди - це звички. Ми, як правило, робимо те саме, як ходити по тротуарах, через двері, вгору по сходах, і не робимо шалених речей, як прогулянка по автострадах, крізь стіни чи біля балконів.

Тож скажімо, ви берете сторінку від Big Brother і починаєте зберігати дані про те, куди їдуть люди. Ви можете розпочати картування, куди очікували б піти люди. Це досить впевнена ставка, що якщо користувач починає сходити вгору по сходах, вона знаходиться в тій же самій базі сходів, що і людина, що передувала їй. Після 1000 ітерацій та декількох коригувань найменших квадратів ваша база даних майже знає, звідки ці сходи з великою точністю. Тепер ви можете виправити кутовий дрейф і розташування, коли людина починає ходити. Коли вона вдаряється ціми сходами, або повертається цією залі, або рухається тротуаром, будь-який дрейф може бути виправлений. Ваша база даних міститиме сектори, які зважуються на ймовірність того, що людина ходитиме туди, або що цей користувач ходив туди в минулому. Просторові бази даних оптимізовані для цього за допомогоюdivide and conquerвиділяти лише значущі сектори. Це було б на зразок тих проектів MIT, коли обладнаний лазером робот починається з чорного зображення і малює лабіринт в пам'яті, роблячи кожен поворот, висвітлюючи, де всі стіни.

Ділянки з високим рівнем руху отримують більшу вагу, а райони, де ще ніхто не набирав ваги. Більш високі роздільні здатності областей руху мають більшу роздільну здатність. Ви, по суті, отримаєте карту, де б хто не був, і використали б її як модель передбачення.

Я не здивуюсь, якби ви могли визначити, яке місце людина займала в театрі, використовуючи цей метод. Враховуючи достатню кількість користувачів, які йдуть в театр, і достатню роздільну здатність, ви мали б відображати дані про кожен ряд театру та наскільки широкий кожен рядок. Чим більше людей відвідують місцеположення, тим вища вірність, з якою ви могли б передбачити, що ця людина знаходиться.

Також я настійно рекомендую отримати (безкоштовну) підписку на журнал GPS World, якщо вас цікавлять поточні дослідження цього роду. Щомісяця я визираю з цим.


"було б приєднати до GPS, щоб калібрувати INS, коли це можливо. Там, де GPS не вистачає, INS приємно робить компліменти". Це те, для чого потрібна фільтрація Калмана. Він поєднує в собі сильні сторони кожного методу, щоб усунути слабкі сторони іншого
ендоліт

8

Я не впевнений, наскільки великий ваш компенсація, адже ви забули включити одиниці. ("Приблизно 10 на кожній осі" не говорить багато.: P) Це сказало, що це все-таки пов’язано з неточністю обладнання.

Акселерометр чудово підходить для таких речей, як визначення орієнтації телефону щодо сили тяжіння або виявлення жестів (струшування або удару телефону тощо)

Однак, намагання зробити мертвий перерахунок за допомогою акселерометра, це піддасть вам багато складних помилок. У іншому випадку акселерометр повинен бути безумовно точним, і це не є звичайним випадком використання, тому я сумніваюся, що виробники апаратних засобів оптимізують його.


Дякую за відповідь. Акселерометри читали близько -0,8 мс ^ -2 на осях X і Y, коли вони нерухомі, тому я використовував це як своє зміщення. Під бітом "Близько 10" я мав на увазі, що понад 5000 ітерацій, складання кожного з прискорень на одній осі від датчика, не дорівнює приблизно 0 мс ^ -2 (як би, якщо він рівномірно коливався вище та нижче зміщення значення), але замість цього, як правило, було зареєстровано прискорення більше в одному напрямку, яке після подвійної інтеграції для пошуку позиції спрацьовувало, коли телефон рухався близько 3 м за хвилину.
woodstock365

+1 за використання авіаційного навігаційного терміна "розрахунок мертвих". Незважаючи на те, що мертві рахунки були б більш доречними для навігації з камерою, ніж INS.
RyanJMcGowan

7

Android акселерометр цифровий, він відбирає прискорення за допомогою тієї ж кількості «відра», скажемо, що є 256 відра, а акселерометр здатний чути від -2 г до + 2 г. Це означає, що ваш вихід буде квантований у перерахунку на ці "відра" і буде стрибати навколо деякого набору значень.

Щоб відкалібрувати андроїдний акселерометр, потрібно відібрати набір значно більше 1000 точок і знайти «режим», навколо якого коливається акселерометр. Потім знайдіть кількість цифрових точок на те, скільки коливається вихід, і використовуйте його для фільтрування.

Я рекомендую фільтрувати Kalman, як тільки ви отримаєте режим і +/- коливання.


1
Я шукав методи калібрування. Здається, ваша пропозиція - це те, що мені потрібно. Мені просто потрібно підтвердити. Як тільки я знайду режим, скажіть, що це 0,5. Я не отримав "Тоді знайдіть кількість цифрових точок на те, скільки коливається вихід, і використовуйте це для вашої фільтрації". Не могли б ви детальніше розглянути детальніше.
Nazerke

1
Скажімо, ваш акселерометр має 256 вихідних точок і коливається на показниках 0,015 м / с ^ 2 між показаннями. Якщо ви покладете свій пристрій на стіл, ваш вихід може коливатися навіть кратними 0,015 м / с ^ 2. Скажімо, ви отримуєте читання 0 +/- (X * 0,015). Вам потрібно знайти X (що було б парним числом). Наприклад, мій X може бути 3. У цьому випадку я б ігнорував зміни в показанні акселерометра, менші 0,045 м / с ^ 2
Алекс Стоун,

значить, акселерометри Android телефонів ще не такі хороші .. правильно?
Techsin

4

Я усвідомлюю, що це досить старе, але питання, про яке йдеться, не вирішується в БУДЬ-кого із наданих відповідей.

Що ви бачите, це лінійне прискорення пристрою, включаючи вплив сили тяжіння. Якщо ви покладете телефон на рівну поверхню, датчик повідомить про прискорення через гравітацію, яка приблизно становить 9.80665 m/s2, отже, дає 10, які ви бачите. Датчики неточні, але вони НЕ ТАКІ неточні! Дивіться тут для деяких корисних посилань і інформації про датчик може бути після.


17
Ні - я думаю, що ви неправильно прочитали запитання: "... читання у напрямку X та Y (паралельно таблиці, тому жодна гравітація не діє в цих напрямках)". 9,8 / s2 буде на осі Z.
чайник7

0

Ви робите припущення, що показання акселерометра в напрямках X і Y, що в даному випадку є повністю апаратним шумом, сформували б нормальний розподіл у середньому. Мабуть, це не так.

Одне, що ви можете спробувати, - це побудувати ці значення на графіку і подивитися, чи з’являється якийсь шаблон. Якщо ні, то шум є статистично випадковим і не може бути відкалібрований - принаймні для вашого обладнання телефону.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.