22트러블슈팅과 종합 프로젝트
전원·CAN·모터·SDK 에서 자주 만나는 문제와 해법, 그리고 시뮬레이터 블록 정리 프로젝트를 완성합니다.
막혔을 때 보는 장#
로봇은 전기·기계·통신·소프트웨어가 한데 엮인 물건이라, 문제가 생기면 "어디가 문제인지" 찾는 데 시간이 가장 많이 듭니다. 이 장의 앞부분은 증상으로 찾아가는 색인이고, 뒷부분은 지금까지 배운 것을 모두 쓰는 종합 프로젝트입니다.
표의 근거 칸은 다음 뜻입니다.
| 표시 | 뜻 |
|---|---|
| 위키 DM / 위키 RS | Seeed 공식 DM 시작하기 / RS 시작하기 의 FAQ·안내 |
| Damiao / Robstride | Damiao 모터 위키 / Robstride 모터 위키 |
| 성능 시험 | 저장소의 Performance_Testing.md (B601-DM, Damiao V4 모터 기준) |
| 그리핑 | 비전 그리핑 위키 트러블슈팅 |
| 일반 원칙 | 특정 문서가 아니라 CAN·모터·전원의 일반적인 공학 상식. 실제 값은 장비 문서로 확인하세요 |
같은 모양의 팔이지만 컴퓨터와 연결하는 방식이 다릅니다. SDK 설정 파일(reBotArm_control_py/config/)을 보면 **RS 는 channel: can0(PCAN-USB 를 통한 SocketCAN), DM 은 channel: /dev/ttyACM0(USB-CAN 보드의 시리얼 다리, dm-serial)** 입니다. 그래서 "can0 이 안 올라와요" 는 주로 RS 의 문제이고, "포트 권한이 없어요" 는 주로 DM 의 문제입니다. 자세한 설정은 7장을 보세요.
진단 순서 — 아래에서 위로#
여러 가지를 동시에 바꾸면, 고쳐져도 무엇 때문에 고쳐졌는지 모릅니다. 바꾸기 전에 증상을 한 줄로 적고, 하나 바꾼 뒤 다시 확인하는 습관이 가장 빠른 길입니다. 그리고 실물을 만질 때는 늘 팔에서 1 m 이상 떨어지고 비상정지를 손 닿는 곳에 두라는 것이 공식 위키의 안전 수칙입니다.
증상 색인 1 — 전원#
B601-DM 은 DC 24V, B601-RS 는 DC 48V 입니다(README 사양표). 두 어댑터는 커넥터(XT30)가 같은 모양일 수 있어 실수하기 쉽습니다. 어댑터와 팔에 전압을 크게 적은 라벨을 붙여 두세요. 전원선을 꽂고 뺄 때는 반드시 전원을 먼저 끕니다.
| 증상 | 가능한 원인 | 해결 | 근거 |
|---|---|---|---|
| 전원을 켰는데 아무 반응이 없음 | 어댑터 옆면 입력 전압 선택 스위치가 맞지 않음, XT30 미체결 | 220V 지역은 230V, 110V 지역은 115V 로 스위치 설정. XT30 2+2 를 끝까지 체결 | 위키 DM·RS |
| DM 팔에 48V 를 연결함 | 전압 혼동 | 즉시 전원 차단. Damiao 드라이버는 켤 때 과전압(OV)을 검사해 동작을 거부할 수 있지만, 부품 손상 가능성이 있으니 판매처에 문의 | README, Damiao, 일반 원칙 |
| RS 팔이 유난히 힘이 없거나 자주 꺼짐 | 48V 대신 24V 등 낮은 전압 | 48V 전원 사용 확인 | README, 일반 원칙 |
| 빠르게 움직이거나 무거운 걸 들 때만 꺼지고 재시작 | 전류 부족 → 순간 전압 강하 → 저전압(UV) 보호 | DM: 24V 14.6A~15A 급(키트 24V 15A, 오픈소스 안 MeanWell LRS-350-24). RS: 48V 12.5A 권장, 최대 성능은 48V 25A | README, 위키 DM·RS |
| 동작 중 모터가 멈추고 다시 Enable 해야 함 | 공급 전압이 저전압 문턱(Damiao 예시 최소 15V) 아래로 떨어짐 | 전원 용량·배선 굵기·접점 확인 | Damiao |
| 노트북·Jetson 이 같이 재부팅됨 | 모터와 컴퓨터가 같은 전원을 공유 | 모터 전원과 컴퓨터 전원을 분리 | Damiao |
| 값싼 어댑터에서 잡음·발열 | 무브랜드 전원 | 브랜드 전원 사용(위키도 무브랜드를 피하라고 안내) | 위키 DM·RS |
| 모터 하나를 빼고 꽂았더니 이상해짐 | 핫플러그(전원 켠 채 연결) | 전원을 끄고 연결. 3핀 케이블도 전원·Enable 을 끈 뒤에 바꿈 | 위키 DM·RS |
증상 색인 2 — CAN · 통신#
| 증상 | 가능한 원인 | 해결 | 근거 |
|---|---|---|---|
ip -br link 에 can 인터페이스가 아예 없음 (RS) | PEAK 드라이버를 chardev 모드로 빌드 | make 대신 **make netdev** 로 다시 빌드 → sudo make install → sudo modprobe pcan | 위키 RS |
can0 이 DOWN (RS) | 아직 올리지 않음 | sudo ip link set can0 type can bitrate 1000000 → sudo ip link set can0 up | 위키 RS |
재부팅·재연결 뒤 can0 대신 can1 이 됨 | 인터페이스 번호가 바뀜 | 위키의 pcan_refresh 로 PCAN_IF 를 찾고, 이름을 하드코딩하지 말 것 | 위키 RS |
모터가 전혀 응답 안 함, candump 에 오류 프레임 | 비트레이트 불일치 | 1 Mbps(1000000)로 통일. Damiao 파이썬 예제 중엔 4 Mbps 를 기본으로 쓰는 클래스도 있으니 설정을 확인 | Damiao, Robstride |
| 통신이 가끔 끊기거나 케이블을 만지면 오류 | 종단 저항 누락·중복, 접촉 불량 | CAN 은 버스 양 끝에 120 Ω 하나씩. 전원 끈 상태에서 CAN_H–CAN_L 사이가 약 60 Ω 이면 정상(일반 원칙). PCAN 의 DIP 스위치는 위키 안내대로 120R 위치 | 위키 RS, 일반 원칙 |
오류가 쌓이다 아예 멈춤(BUS-OFF) | 배선 잡음·비트레이트·종단 문제 | 원인 해결 후 재시작. 위키는 PCAN 에 restart-ms 100 옵션을 함께 줌 | 위키 RS, 일반 원칙 |
| 모든 모터가 같은 CAN ID 가 됨 (DM) | 영점 설정 중 CAN ID 칸 옆 Read/Set 버튼을 누름 → 버스 전체에 같은 ID 기록 | 모터를 하나씩만 연결해 ID 를 다시 씀(1~7 → Master ID 0x11~0x17) | 위키 DM |
| 피드백 값이 뒤섞이거나 엉뚱한 모터 값이 읽힘 | Master ID(피드백 ID) 중복, 또는 0x00 | Master ID = CAN ID + 0x10 처럼 모두 다르게, 0x00 금지 | Damiao |
| 스캔하면 일부 모터만 보임 | 모터 사이 하네스 접촉 불량, ID 중복 | motorbridge-cli scan --vendor robstride --channel can0 --start-id 1 --end-id 7 --timeout-ms 300 으로 몇 번이 빠졌는지 확인 후 그 구간 배선 점검 | 위키 RS |
Permission denied: /dev/ttyACM0 (DM) | 시리얼 포트 권한 | sudo chmod 666 /dev/ttyACM* (재부팅하면 풀림 → dialout 그룹 가입이 영구 해결) | 위키 DM, 음성 위키 |
| Jetson 에서 USB 시리얼이 사라짐 | brltty 가 포트를 가로챔 | sudo apt remove -y brltty | 위키 RS |
| 명령을 잠시 안 보냈더니 모터가 보호 모드 | CAN 타임아웃 보호(Damiao CAN Timeout, Robstride 오류 0x01) | 제어 루프가 끊기지 않게, 끝낼 때는 정상적으로 Disable | Damiao, Robstride |
| macOS 에서 텔레오퍼레이션 프레임이 낮음 | 오래된 WCH CH34x 드라이버 | 드라이버 제거 후 내장 AppleUSBCHC0M 사용 | 위키 DM·RS |
# CAN 상태를 볼 때 자주 쓰는 명령 (RS, Linux)
ip -br link | grep can # 인터페이스 목록과 UP/DOWN
ip -details link show can0 # 비트레이트, 오류 상태(ERROR-ACTIVE/PASSIVE/BUS-OFF)
candump can0 # 버스에 흐르는 프레임 엿보기 (can-utils)증상 색인 3 — 모터 · 기구#
| 증상 | 가능한 원인 | 해결 | 근거 |
|---|---|---|---|
| 켜자마자 모터에서 큰 이상 소음 (DM) | ID 설정 중 파라미터 보정이 실행되어 관성 등 값이 덮어써짐 | Windows 용 DM_Tools v1.8.0.1 로 같은 모델 정상 모터의 파라미터를 내보내 가져오기 → CAN ID 수정·저장 → 영점 다시 | 위키 DM |
| 오래 쓰면 2번 모터(어깨)가 멈춤 | 과열 보호. 성능 시험에서 1.5 kg 을 100% 뻗어 들고 있으면 약 3분, 70% 면 약 18분 만에 보호 동작 | 하중 1.5 kg 이하, 도달거리 70% 이내, 속도 70% 이내, 2시간마다 10~15분 휴식, 능동 냉각 | 성능 시험 |
| 여름에 정확도가 떨어짐 | 주변 35 °C 초과 또는 모터 75 °C 초과 | 하중·속도를 낮춤. 직사광선·밀폐 공간 피하기 | 성능 시험 |
| Damiao 모터가 오류를 내며 꺼짐 | 코일 온도가 OT 문턱 초과(권장 100 °C 이하로 설정) → 고장 모드 | 식힌 뒤 재활성화, 하중·자세 재검토 | Damiao |
| Robstride 오류 코드 | 아래 표 참고 | — | Robstride |
| 시뮬레이터와 같은 각도를 보냈는데 실물 자세가 다름 | 영점 틀어짐(분해·충돌·영점 미설정) | 영점 다시 설정. 위키는 "제어 전에 영점을 다시 잡으라"고 안내 | 위키 DM·RS |
| 위치 모드에서 속도·가속이 이상함 (RS) | loc_kp, vel_max, spd_kp, acc_rad 값 불일치 | Studio 에서 Read → Apply Default Template → Write → 읽어서 검증 | 위키 RS |
| MIT 모드에서 떨리거나 처짐 | kp/kd 가 너무 크거나(떨림) 작음(처짐) | 기본 설정값부터 다시. kd 를 조금 올리면 떨림이 줄어듦 | 일반 원칙 (5장) |
| 나사가 헛돎 | 전동 드라이버 과토크 | 3~6 kgf·cm 로 낮추고 나사 교체 | 위키 DM·RS |
| Robstride 코드 | 중국어 원문 | 뜻 | 먼저 볼 곳 |
|---|---|---|---|
| 0x01 | 通信超时 | 통신 타임아웃 | CAN 연결, 제어 루프가 멈췄는지 |
| 0x02 | 参数超出范围 | 파라미터 범위 초과 | 보낸 명령 값의 범위 |
| 0x03 | 电机过流 | 과전류 | 하중, 토크 한계, 충돌 |
| 0x04 | 位置溢出 | 위치 넘침 | 관절 한계, 목표 위치 |
| 0x05 | 温度过高 | 과열 | 냉각, 하중 |
증상 색인 4 — SDK · 환경 · 시뮬레이션과 실물의 차이#
| 증상 | 가능한 원인 | 해결 | 근거 |
|---|---|---|---|
conda: command not found | 셸 초기화 안 됨 | source ~/miniforge3/etc/profile.d/conda.sh → conda init bash | 위키 DM·RS |
No module named 'motorbridge' | 다른 conda 환경이 켜져 있음 | 맞는 환경 활성화 후 pip install motorbridge 또는 SDK 를 pip install -e . 로 재설치 | 위키 DM·RS, 그리핑 |
Multiple top-level packages 설치 오류 | SDK pyproject.toml 패키지 검색 범위 | [tool.setuptools.packages.find] 에 include = ["reBotArm_control_py*"] 추가 | 그리핑 |
| 가상 머신에서 데모가 느리거나 장치가 안 잡힘 | VM 의 USB·실시간 성능 한계 | 실제 Ubuntu PC(위키 권장 24.04 LTS) 사용 | 위키 DM·RS |
| RS 팔인데 DM 처럼 움직임(또는 연결 실패) | config/rebotarm.yaml 의 hardware_yaml 이 다른 모델 | rebotarm_rs.yaml / rebotarm_dm.yaml 중 맞는 것 지정 | SDK 저장소 |
비전 그리핑에서 G 를 눌러도 반응 없음 | hand_eye.npz 없음, 모드가 eye_in_hand 아님, IK 도달 불가 | 보정 다시, --dry-run 으로 먼저 확인 | 그리핑 |
| 30° 를 보냈는데 거의 안 움직이거나 엄청 돎 | 도 ↔ 라디안 혼동 (Playground 는 도, URDF·SDK 는 라디안) | math.radians() / math.degrees() 로 변환 | 이 강좌 9장 |
| 같은 코드인데 RS 와 DM 에서 팔이 반대로 굽음 | 두 URDF 의 축 부호 약속이 다름(j2·j3 부호 반대) | 모델별 부호 표를 두고 변환 | 이 강좌 17장 |
| 시뮬레이터에선 되는데 실물은 처지고 목표보다 낮음 | 시뮬레이터는 기구학만 계산(중력·마찰 없음) | 중력 보상(19장), 게인 조정 | 일반 원칙 |
| 시뮬레이터에선 통과하는데 실물은 책상·몸체에 부딪힘 | 시뮬레이터에 충돌 검사가 없음 | 최저 높이(z) 제한을 코드에 넣고, 접근점을 높게 | 일반 원칙 |
| 시뮬레이터처럼 빨리 움직이면 실물이 과열·진동 | 실물은 가속·토크·열 한계가 있음 | 처음엔 시간 t 를 2~3배로, 점점 줄이기 | 일반 원칙 |
종합 프로젝트 — 블록 정리 로봇#
목표#
시뮬레이터 책상 위의 큐브를 찾아, 정리 칸 A → B → C 로 차례로 옮긴 뒤 처음 자리로 되돌려 놓는 프로그램을 Python Playground 로 작성한다. 모든 이동은 안전 높이로 다니고, 집고 놓을 때는 수직으로 곧게 내려가야 한다.
실물이 없어도 시뮬레이터 Python 탭만으로 완성할 수 있습니다. 쓰는 API 는 arm.cube(), arm.ik(), arm.move_to(), arm.move_line(), arm.open(), arm.close(), arm.wait(), arm.home() 입니다.
코드는 먼저 끝까지 실행되고, 쌓인 동작이 그다음에 차례로 재생됩니다. 그래서 arm.cube() 는 프로그램 맨 앞에서 한 번만 읽고, 그 뒤 큐브가 어디 있는지는 내 변수로 기억해야 합니다. 실제 로봇 프로그램에서도 "지금 물체가 어디 있는지" 를 상태로 관리하는 것은 중요한 습관입니다.
단계별 요구사항#
| 단계 | 요구사항 | 배운 곳 |
|---|---|---|
| R1 준비 검사 | 큐브가 꺼져 있으면(None) 안내하고 멈춘다. 모든 칸과 그 위 안전 높이가 arm.ik(..., down=True) 로 도달 가능한지 먼저 검사하고, 하나라도 안 되면 움직이지 않는다 | 11장 |
| R2 함수로 나누기 | pick(p) 와 place(p) 를 함수로 만든다. 각각 접근점 → 하강 → 그리퍼 → 상승 순서 | 9장 |
| R3 직선 접근 | 집고 놓을 때의 하강·상승은 move_line(TCP 직선), 칸 사이 이동은 move_to | 12장 |
| R4 상태 추적 | 큐브의 현재 위치를 변수 here 로 기억하며 A → B → C → 처음 자리 | 이 장 |
| R5 보고 | 각 단계에서 무엇을 했는지 print, 마지막에 총 동작 시간(초)을 출력 | — |
기본 코드#
아래는 R1~R4 를 만족하는 뼈대입니다. 먼저 그대로 실행해 동작을 확인한 뒤, R5 와 확장 과제를 직접 더해 보세요.
SAFE = 0.10 # 안전 높이: 큐브 위 10 cm
def reachable(p, dz=0.0):
return arm.ik(p[0], p[1], p[2] + dz, down=True) is not None
def pick(p):
x, y, z = p
arm.open()
arm.move_to(x, y, z + SAFE, t=1.5, down=True) # 접근점
arm.move_line(x, y, z, t=1.0) # 곧게 하강
arm.close()
arm.wait(0.5) # 다 닫힐 때까지
arm.move_line(x, y, z + SAFE, t=1.0) # 곧게 상승
def place(p):
x, y, z = p
arm.move_to(x, y, z + SAFE, t=1.5, down=True)
arm.move_line(x, y, z, t=1.0)
arm.open()
arm.wait(0.3)
arm.move_line(x, y, z + SAFE, t=1.0)
start = arm.cube()
if start is None:
print("보기 옵션에서 큐브를 켜 주세요.")
else:
z0 = start[2]
SLOTS = {"A": (0.30, 0.15, z0), "B": (0.40, 0.15, z0), "C": (0.30, -0.15, z0)}
# R1: 움직이기 전에 전부 검사
ok = reachable(start) and reachable(start, SAFE)
for name, p in SLOTS.items():
good = reachable(p) and reachable(p, SAFE)
print(f"칸 {name} {p[:2]} → {'도달 가능' if good else '도달 불가'}")
ok = ok and good
if not ok:
print("도달할 수 없는 칸이 있어 실행하지 않습니다.")
else:
arm.home()
here = start # R4: 큐브 위치 기억
for name in ["A", "B", "C"]:
pick(here)
place(SLOTS[name])
here = SLOTS[name]
print(f"큐브를 칸 {name} 에 놓았습니다.")
pick(here)
place(start)
print("큐브를 처음 자리로 되돌려 놓았습니다.")
arm.home()- 그리퍼가 닫혀도 큐브가 따라오지 않으면 TCP 가 큐브에서 너무 먼 것입니다. 하강 높이를 1 cm 씩 바꿔 보세요.
move_line이 경고를 내면 그 줄을move_to(..., down=True)로 바꿔 원인을 좁힙니다.- 칸 사이
move_to는 관절 보간이라 TCP 경로가 곡선입니다. 큐브를 들고 갈 때 경로가 낮게 처지지 않는지 화면에서 보세요. 신경 쓰이면 칸 사이도move_line으로 바꿔 보세요(확장 과제 E2). - 모델을 RS ↔ DM 으로 바꿔 같은 코드가 둘 다에서 동작하는지 확인하세요. Playground 의
move_to가 모델별 IK 를 알아서 쓰므로 그대로 동작해야 정상입니다.
채점 기준 (100점)#
| 항목 | 기준 | 점수 |
|---|---|---|
| 기능 | 큐브가 A → B → C → 처음 자리 순서로 옮겨지고 끝에 홈 자세 | 30 |
| 안전 검사 (R1) | 큐브 꺼짐·도달 불가 상황에서 움직이지 않고 이유를 출력 (일부러 칸을 (0.9, 0, z0) 로 바꿔 시험) | 20 |
| 경로 품질 (R3) | 하강·상승이 수직 직선, 들고 이동할 때 안전 높이 유지 | 15 |
| 구조 (R2·R4) | pick/place 함수, 위치를 상수(SLOTS)와 상태(here)로 관리, 숫자를 코드 곳곳에 흩뜨리지 않음 | 15 |
| 보고 (R5) | 단계별 출력과 총 동작 시간 | 10 |
| 모델 호환 | RS·DM 둘 다에서 수정 없이 동작 | 10 |
확장 과제#
| 과제 | 난이도 | 힌트 |
|---|---|---|
| E1. 칸을 원 위에 6개 배치하기 | ★★ | math.cos, math.sin 으로 반지름 0.35 m 원 위의 점 만들기 |
| E2. 들고 이동할 때도 직선 | ★★ | 칸 사이 이동을 move_line(..., steps=30) 으로 |
| E3. 가장 짧은 순서로 방문 | ★★★ | 칸 사이 거리 math.dist 로 "가장 가까운 칸부터"(탐욕 알고리즘) |
| E4. 쌓기 계획 (드라이런) | ★★★ | 블록 N개를 한 칸에 쌓는다고 할 때 i 번째 놓는 높이 = z0 + i × 블록 높이. 시뮬레이터 큐브는 하나뿐이니 각 높이로 가서 놓기 직전 자세만 재생하고 높이를 출력 |
| E5. 가상 카메라와 합치기 | ★★★ | 21장의 pixel_to_robot 으로 큐브 위치를 "카메라에서 받은 값"으로 바꾸고, 1 cm 깊이 오차를 넣어도 성공하는지 |
| E6. 말로 시키기 | ★★★★ | 21장의 SKILLS 사전에 "sort" 스킬을 추가해 {"action": "sort"} 로 이 프로젝트 전체를 실행 |
| E7. 펜던트로 같은 일 교시 | ★★★ | 23장의 티칭 펜던트로 같은 동작을 점 교시하고, 코드 방식과 걸린 시간·수정 편의를 비교 |
시뮬레이터에서 완성한 프로그램을 실물에서 돌리려면 ① 모든 t 를 2~3배로 늘리고, ② 최저 높이 제한을 넣고, ③ 처음엔 빈 그리퍼로 한 번 돌려 경로를 확인한 뒤, ④ 비상정지를 손에 쥐고 실행하세요. 시뮬레이터에는 중력·충돌·과열이 없다는 것을 잊지 마세요.
정리#
- 문제는 전원 → 케이블 → 인터페이스 → 스캔 → 활성화 → 영점·설정 → 코드 순서로 아래에서 위로 확인합니다. 대부분 아래 세 칸에서 해결됩니다.
- DM 24V / RS 48V 혼동과 전류 부족이 가장 흔하고 위험한 전원 문제입니다. 권장 전원은 DM 24V 15A 급, RS 48V 12.5A(최대 성능 25A)입니다.
- RS 는 PCAN-USB 로
can0을 1 Mbps 로 올리고(make netdev드라이버), DM 은 USB-CAN 보드의 시리얼(/dev/ttyACM0) 권한을 확인합니다. CAN 버스 양 끝 120 Ω, ID·Master ID 중복 금지. - 과열은 하중·뻗은 정도·시간의 문제입니다. 성능 시험 결론은 1.5 kg 이하, 도달거리 70% 이내, 휴식과 냉각입니다.
- 시뮬레이터는 기구학만 계산합니다. 중력·충돌·열이 있는 실물로 옮길 때는 느리게, 높게, 빈손으로 먼저.
- 종합 프로젝트는 검사 → 함수 → 직선 접근 → 상태 추적 → 보고 의 구조로 만들었습니다. 이 구조는 실물 프로그램에도 그대로 쓰입니다.
확인 문제#
- RS 팔이 연결되지 않습니다.
ip -br link에 can 인터페이스가 하나도 보이지 않습니다. 가장 먼저 의심할 것은 무엇인가요? - B601-DM 이 가벼운 동작은 잘 하는데, 빠르게 크게 움직일 때만 모든 모터가 꺼졌다 켜집니다. 원인과 해결책은?
- 전원을 끈 상태에서 CAN_H 와 CAN_L 사이 저항을 쟀더니 약 120 Ω 이 나왔습니다. 무엇이 문제일 가능성이 큰가요?
- 종합 프로젝트에서
arm.cube()를 각 단계마다 다시 읽지 않고here변수로 위치를 기억하는 이유는 무엇인가요? - 성능 시험에서 1.5 kg 을 도달거리 100% 로 뻗어 들고 있으면 약 몇 분 만에 과열 보호가 동작했나요? 이 결과가 알려 주는 사용 원칙은?
- PCAN 드라이버를 netdev 모드로 빌드하지 않은 것(일반
make는 chardev 모드)입니다.make netdev로 다시 빌드·설치하고sudo modprobe pcan을 합니다. 그다음에야bitrate 1000000으로 올리는 단계가 의미가 있습니다. - 전원 전류 부족으로 순간 전압이 떨어져 저전압 보호가 걸린 것입니다. 24V 15A 급(예: MeanWell LRS-350-24 24V 14.6A) 정격 전원을 쓰고, 배선·접점을 확인합니다. 모터 전원과 컴퓨터 전원도 분리합니다.
- 정상(양 끝 120 Ω 두 개 병렬)이면 약 60 Ω 이어야 합니다. 120 Ω 이면 종단 저항이 한쪽에만 있는 것입니다(PCAN 쪽 120R 설정 또는 버스 끝 종단 확인).
- Playground 는 코드를 끝까지 실행한 뒤에 동작을 재생하므로, 코드 실행 중에 읽는
arm.cube()는 옮긴 뒤의 위치를 반영하지 않습니다. 또 실제 로봇에서도 물체 위치를 상태로 관리해야 센서가 잠시 못 볼 때도 일관되게 동작합니다. - 약 3분입니다(70% 에서는 약 18분). 무거운 물건을 멀리 뻗은 채 오래 들고 있지 말고, 권장 작업영역(도달거리 70%) 안에서, 쉬는 시간과 냉각을 두고 쓰라는 뜻입니다.