Android 가속도계 정확도 (관성 탐색)

Android 가속도계 정확도 (관성 탐색)

---

나는 안드로이드 폰에 관성 내비게이션 시스템을 구현하는 방법을 찾고 있었는데, 가속도계의 정확도와 판독 값의 지속적인 변동을 감안할 때 어렵다는 것을 알고 있습니다.

우선 휴대 전화를 평평한 표면에 놓고 X 및 Y 방향으로 1000 개의 가속도계 판독 값을 샘플링했습니다 (테이블과 평행하므로이 방향으로 중력이 작용하지 않음). 그런 다음 이러한 판독 값의 평균을 구하고이 값을 사용하여 전화기를 보정했습니다 (각 후속 판독 값에서이 값을 뺍니다).

그런 다음 다시 테이블에 놓고 X 및 Y 방향으로 5000 개의 가속도계 판독 값을 샘플링하여 시스템을 테스트했습니다. 보정이 주어지면 이러한 가속도는 각 방향에서 0 (대략)까지 더해져야합니다. 그러나 이것은 사실이 아니며 5000 회 이상의 총 가속도는 0에 가깝지 않습니다 (각 축에서 평균 약 10 회).

내 코드를 보지 않으면 대답하기 어려울 수 있지만보다 일반적인 의미에서 ...

이것은 단순히 휴대 전화 (HTC Desire S)에서 가속도계 판독 값이 얼마나 정확하지 않은지를 보여주는 예시일까요? 아니면 코딩에 오류가있을 가능성이 더 큽니까?

---

선형 가속도를 두 번 통합하여 위치를 얻지 만 오류는 끔찍합니다. 실제로는 쓸모가 없습니다.

여기에 설명하는 이유 (구글 테크 토크) 에서 23시 20분는 . 이 비디오를 강력히 추천합니다.

문제를 일으키는 것은 가속도계 소음이 아니라 자이로 백색 소음 입니다. 6.2.3 오류 전파를 참조하십시오. (그런데 자이로 스코프도 필요합니다.)

실내 포지셔닝과 관련하여 다음이 유용하다는 것을 알았습니다.

Sigma-Point Kalman Smoothers를 사용한 RSSI 기반 실내 로컬라이제이션 및 추적

신발에 장착 된 관성 센서로 보행자 추적

단일 가속도계를 사용하여 보수계의 성능 향상

이 방법이 실제 응용 프로그램에서 어떻게 작동하는지 또는 멋진 Android 앱으로 전환하는 방법을 모릅니다.

비슷한 질문 이 있습니다.

최신 정보:

분명히 위의 Oliver J. Woodman, "관성 항법 소개", 그의 박사 논문보다 더 새로운 버전이 있습니다.

실내 환경을위한 보행자 위치 파악

---

나는 단지 큰 소리로 생각하고 있으며 아직 안드로이드 가속도계 API를 사용하지 않았으므로 저를 참아주십시오.

우선, 전통적으로 가속도계에서 내비게이션을 얻으려면 6 축 가속도계가 필요합니다. X, Y 및 Z의 가속도 필요하지만 회전 Xr, Yr 및 Zr도 필요합니다. 회전 데이터가 없으면 장치가 태도를 변경하지 않는다고 가정하지 않는 한 벡터를 설정할 충분한 데이터가 없습니다. 어쨌든 TOS를 읽는 사람은 없습니다.

아, 그리고 INS가 지구의 자전과 함께 표류한다는 것을 알고 있습니까? 그래서 그것도 있습니다. 한 시간 후 당신은 신비롭게 15 °의 경사를 우주로 올라가고 있습니다. 그것은 당신이 전화로는 아직 할 수없는 위치를 그렇게 오래 유지할 수있는 INS를 가지고 있다고 가정합니다.

내비게이션에 3 축 가속도계를 사용하더라도 가속도계를 활용하는 더 좋은 방법은 가능할 때마다 INS를 보정하기 위해 GPS에 연결하는 것입니다. GPS가 부족한 경우 INS는 훌륭하게 칭찬합니다. GPS는 나무에 너무 가까워서 3 블럭 떨어진 곳에서 갑자기 쏠 수 있습니다. INS는 훌륭하지는 않지만 적어도 유성에 맞지 않았다는 것을 알고 있습니다.

당신이 할 수있는 것은 전화 가속도계 데이터를 기록하는 것입니다. 몇 주 동안 가치가 있습니다. 좋은 (정말 좋은) GPS 데이터와 비교하고 데이터 마이닝을 사용하여 가속도계 데이터와 알려진 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.그리고 그에 따라 조각이 앞으로 이동합니다. 주머니에 휴대 전화를 넣는 것만으로도 4 가지 방향 중 하나로, 주머니를 바꾸면 8 가지 방향이 될 수 있기 때문에 완전히 블라인드 상태 여야합니다. 휴대 전화를 잡는 방법도 여러 가지가 있습니다. 우리는 여기서 많은 데이터를 이야기하고 있습니다.

당신은 분명히 여전히 많은 드리프트를 가지고있을 것이지만, 나는 당신이 걷는 것을 멈추었을 때 장치가 알 수 있고 위치 드리프트가 영속적이지 않을 것이기 때문에 당신이이 방법으로 더 나은 행운을 누릴 것이라고 생각합니다. 과거 데이터를 바탕으로 당신이 가만히 서 있다는 것을 압니다. 기존 INS 시스템에는이 기능이 없습니다. 드리프트는 향후 모든 측정 및 복합에 대해 기하 급수적으로 지속됩니다. 경건하지 않은 정확성 또는 정기적으로 확인하는 보조 탐색 기능은 기존 INS에서 절대적으로 중요합니다.

각 장치와 각 개인은 자신의 프로필을 가져야합니다. 그것은 많은 데이터와 많은 계산입니다. 모든 사람은 다른 속도로, 다른 단계로 걷고, 휴대폰을 다른 주머니에 넣는 등의 작업을 수행합니다. 실제 세계에서이를 구현하려면 서버 측에서 처리하려면 번호 처리가 필요합니다.

초기 기준선에 GPS를 사용했다면 GPS가 시간이 지남에 따라 자체 마이그레이션이 발생하는 경향이 있지만 영구적이지 않은 오류가 있습니다. 한 위치에 수신기를 앉아 데이터를 기록합니다. WAAS 수정이없는 경우 100 피트 주변의 임의 방향으로 표류하는 위치 수정을 쉽게 얻을 수 있습니다. WAAS를 사용하면 6 피트까지 내려갈 수 있습니다. 최소한 ANN의 알고리즘을 낮추기 위해 배낭에 서브 미터 RTK 시스템을 사용하면 실제로 더 나은 운을 얻을 수 있습니다.

내 방법을 사용하면 INS와 함께 각도 드리프트가 계속됩니다. 이것은 문제입니다. 그러나 지금까지 n 명의 사용자에게 몇 주 동안 GPS 및 INS 데이터를 쏟아 부을 ANN을 구축하고 실제로이 시점까지 작동하게했다면 지금까지 빅 데이터를 신경 쓰지 않는 것입니다. 그 길을 계속 따라 가면서 더 많은 데이터를 사용하여 각도 편차를 해결하십시오. 사람은 습관의 생물입니다. 우리는 보도, 문, 계단을 오르는 것과 같은 일을 거의하고 고속도로를 가로 지르거나 벽을 통과하거나 발코니에서 벗어나는 것과 같은 미친 짓을하지 않습니다.

So let's say you are taking a page from Big Brother and start storing data on where people are going. You can start mapping where people would be expected to walk. It's a pretty sure bet that if the user starts walking up stairs, she's at the same base of stairs that the person before her walked up. After 1000 iterations and some least-squares adjustments, your database pretty much knows where those stairs are with great accuracy. Now you can correct angular drift and location as the person starts walking. When she hits those stairs, or turns down that hall, or travels down a sidewalk, any drift can be corrected. Your database would contain sectors that are weighted by the likelihood that a person would walk there, or that this user has walked there in the past. Spatial databases are optimized for this using divide and conquer to only allocate sectors that are meaningful. It would be sort of like those MIT projects where the laser-equipped robot starts off with a black image, and paints the maze in memory by taking every turn, illuminating where all the walls are.

Areas of high traffic would get higher weights, and areas where no one has ever been get 0 weight. Higher traffic areas are have higher resolution. You would essentially end up with a map of everywhere anyone has been and use it as a prediction model.

I wouldn't be surprised if you could determine what seat a person took in a theater using this method. Given enough users going to the theater, and enough resolution, you would have data mapping each row of the theater, and how wide each row is. The more people visit a location, the higher fidelity with which you could predict that that person is located.

Also, I highly recommend you get a (free) subscription to GPS World magazine if you're interested in the current research into this sort of stuff. Every month I geek out with it.

---

I'm not sure how great your offset is, because you forgot to include units. ("Around 10 on each axis" doesn't say much. :P) That said, it's still likely due to inaccuracy in the hardware.

The accelerometer is fine for things like determining the phone's orientation relative to gravity, or detecting gestures (shaking or bumping the phone, etc.)

However, trying to do dead reckoning using the accelerometer is going to subject you to a lot of compound error. The accelerometer would need to be insanely accurate otherwise, and this isn't a common use case, so I doubt hardware manufacturers are optimizing for it.

---

Android accelerometer is digital, it samples acceleration using the same number of "buckets", lets say there are 256 buckets and the accelerometer is capable of sensing from -2g to +2g. This means that your output would be quantized in terms of these "buckets" and would be jumping around some set of values.

To calibrate an android accelerometer, you need to sample a lot more than 1000 points and find the "mode" around which the accelerometer is fluctuating. Then find the number of digital points by how much the output fluctuates and use that for your filtering.

I recommend Kalman filtering once you get the mode and +/- fluctuation.

---

I realise this is quite old, but the issue at hand is not addressed in ANY of the answers given.

What you are seeing is the linear acceleration of the device including the effect of gravity. If you lay the phone on a flat surface the sensor will report the acceleration due to gravity which is approximately 9.80665 m/s2, hence giving the 10 you are seeing. The sensors are inaccurate, but they are not THAT inaccurate! See here for some useful links and information about the sensor you may be after.

---

You are making the assumption that the accelerometer readings in the X and Y directions, which in this case is entirely hardware noise, would form a normal distribution around your average. Apparently that is not the case.

One thing you can try is to plot these values on a graph and see whether any pattern emerges. If not then the noise is statistically random and cannot be calibrated against--at least for your particular phone hardware.

참고URL : https://stackoverflow.com/questions/7829097/android-accelerometer-accuracy-inertial-navigation