센서가 0, 0, 0을 돌려줬다

leJOS 로 로봇 키트를 다루는 과제를 했다. ColorSensor 에서 값을 읽는 부분이다.

int r = sensor.getRed();
int g = sensor.getGreen();
int b = sensor.getBlue();

세 값이 전부 0으로 나왔다.

Open Table of contents

증상 — 배선부터 의심했다
방식을 바꾸니 값이 나왔다
원인이 소스에 있었다
제약이 만든 구조
정리

증상 — 배선부터 의심했다

처음에는 하드웨어를 봤다.

포트를 바꿔 꽂아 봄
다른 센서를 꽂아 봄
전원을 다시 넣어 봄

여전히 0이었다. 그런데 같은 포트에 다른 종류 센서를 꽂으니 값이 나왔다. 포트도 배선도 아니고 ColorSensor 만 안 되는 것이었다.

방식을 바꾸니 값이 나왔다

leJOS 는 프로그램을 두 가지로 짤 수 있다.

[방식 A]  NXJ 를 올려 프로그램이 로봇 안에서 돎
[방식 B]  PC API 로 컴퓨터에서 돌고 Bluetooth 로 로봇을 제어

과제는 B 로 하고 있었다. 같은 로직을 A 로 옮겨 봤다.

[A 방식]  R, G, B 값이 나옴
[B 방식]  0, 0, 0

하드웨어도 센서도 같은데 실행 방식에 따라 갈렸다. 왜 다른지는 그때 알 수가 없었다.

원인이 소스에 있었다

이 라이브러리는 소스가 공개돼 있다. 받아서 원격 쪽을 열어 봤다. PC API 의 센서 포트는 RemoteSensorPort 였다. 그것이 LCP 로 포트를 흉내 내고 있었다.

즉 컴퓨터 쪽 SensorPort 는 진짜 포트가 아니라 무선으로 명령을 주고받아 흉내 낸 것이다. 클래스 이름이 양쪽에 똑같이 있어서 코드만 봐서는 같은 것으로 보였다. 그 껍데기가 ColorSensor 에서 왜 0만 주는지는 그때 못 밝혔다. 되는 쪽으로 옮기는 것으로 끝냈다.

문서에도 두 방식의 차이를 설명하는 표는 있었다. 다만 센서별로 어디까지 되는지가 없었다.

[문서]  방식의 개념 차이
[소스]  실제로 뭐가 되고 안 되나

둘이 다른 정보였다. 그동안 한 것은 전부 안 되는 것을 되게 하려는 시도였다. 이 일 뒤로 문서를 읽고 안 되면 소스를 여는 순서가 생겼다. 소스 열기가 최후 수단이 아니라 두 번째 수단이 됐다.

제약이 만든 구조

원인은 알았지만 과제는 해야 했다.

[A 방식]  센서는 됨. 컴퓨터의 계산 능력을 못 씀
[B 방식]  계산은 됨. ColorSensor 가 안 됨

둘 다 필요한데 하나씩만 된다. 그래서 두 부분이 다른 곳에서 돌게 나누기로 했다.

로봇 안: 센서를 읽는다
컴퓨터: 계산한다
    ↓
값을 주고받아야 한다

Bluetooth 로 둘 사이를 잇는 통신이 필요해졌다. 원래 과제에 없던 부분이 하나 늘었다.

제약이 없었으면 안 나눴을 것이다. 한 방식으로 다 됐으면 그냥 그렇게 했다. 제약이 구조를 만든 셈이다.

정리

센서가 0만 돌려줘서 배선과 포트와 전원을 먼저 의심했다
다른 센서는 되고 ColorSensor 만 안 됐다
실행 방식을 바꾸니 값이 나왔다
PC API 의 SensorPort 는 LCP 로 흉내 낸 껍데기다
클래스 이름이 양쪽에 같아서 코드만 봐서는 안 갈린다
문서에는 개념 차이만 있고 센서별 한계는 없었다
소스 열기를 최후가 아니라 두 번째 수단으로 삼게 됐다
제약 때문에 구조를 나누게 됐고 없었으면 안 나눴다