MPU6050 모션 실험

질문

불편을 숫자로 바꿀 수 있는가. 그리고 그 숫자를 만드는 보드가 죽으면 제품은 어떻게 되는가.

Glide의 하드웨어가 여기서 나왔다. 아두이노 보드 하나로 "지금 이 차가 얼마나 멀미를 일으키는가"를 숫자로 만들었다. 그 숫자가 임계값을 넘기 전에 손목을 두드리는 단계까지 갔다. 여기서 정한 측정 방식과 진동 패턴이 그대로 제품의 하드웨어가 됐다. 실패도 그대로 남았다.

왜 재야 했나

멀미는 "불편하다"는 말로만 오간다. 그러면 나아졌다는 주장도 확인할 방법이 없다. 재는 법이 먼저 필요했다.

지표는 MSDV를 골랐다. 멀미를 재는 세 방식(MSDV, MISC, FMS)을 비교한 결과다. 국제 표준 ISO 2631-1에 근거가 있어서 남들과 같은 단위로 이야기할 수 있다.

재는 것만으로는 아무것도 바뀌지 않는다. 숫자가 몸에 닿아야 한다.

어떻게 했나

• 센서 두 개 – MPU6050을 차체와 머리에 각각 붙였다. 멀미는 차의 움직임이 아니라 차와 머리의 차이에서 온다.
• 50Hz, 200샘플 보정 – 시작할 때 200개 샘플로 정지 상태를 잡아 중력을 뺀다. 이후 50Hz로 적분해 MSDV를 계산한다(설계값).
• 진동 패턴 – 225ms 켜짐, 100ms 꺼짐, 225ms 켜짐. 실제로 차에 타 보며 골랐다. 한 번 길게 울리면 놀랐고, 짧게 두 번은 알림으로 읽히지 않았다.
• 좌우 분리 – 모터를 좌우로 나눠, 어느 쪽으로 쏠릴지를 세기 차이로 먼저 알렸다.

된 것과 안 된 것

된 것. 정지 보정을 마치면 손으로 흔드는 정도의 움직임도 MSDV 곡선에 잡혔다. 임계값을 넘기 2초쯤 전에 진동을 보냈다. 이 2초가 Glide의 예고 시간 2~7초의 출발점이다(설계값).

안 된 것. 보드에 붙인 MPU6050 두 개가 I2C 버스에서 동시에 잡히지 않았다. 주소 충돌과 배선을 며칠 뒤졌지만 끝내 둘을 같이 읽지 못했다. 실시간 측정이 여기서 막혔다.

센서 주기도 어긋났다. GPS는 1Hz, IMU는 50Hz다. 맞추려 하는 대신 역할을 나눴다. GPS는 예고 시점을, IMU는 실시간 강도를 맡는다.

그래서 만든 두 번째 경로. 아이폰 CoreMotion으로 같은 식을 다시 구현해 대체 경로로 삼았다. 보드가 없어도 가짜 센서 값으로 같은 화면이 돌아간다. 센서가 죽은 날 이 경로가 시연을 살렸다.

여기서 남은 규칙

측정 단위를 먼저 고른다. 표준 지표를 쓰면 같은 값을 여러 곳에 같은 식으로 구현할 수 있다. Glide에서는 센서 보드와 웹 콘솔과 iOS 앱이 같은 MSDV 식을 쓴다. 보드에서 잰 값과 앱이 보여 주는 값이 서로 어긋나지 않는다.

데모는 최악의 환경을 가정해 만든다. 대체 경로가 없으면 하드웨어 하나가 발표를 결정한다.

실패한 배선은 제품 구조로 남는다. I2C가 안 된 결과가 지금의 구조다. 보드와 앱은 직접 붙지 않고 웹을 경유한다.