본문 바로가기

인턴, 협업/WIM

2023-2 델타 로봇(Delta robot) - #7 (제어, 완성)

반응형

로봇의 시제품, 정확하게는 테스트 모델이 완성된 지금 남은 것은 실제 작동시켜 보는 것만 남았다.
 
 
물론 이번 제어를 통해서 발생하는 문제를 다시 개선해서 다시 설계 수정을 하는 과정도 필요하겠지만 일단 남은 기간 동안 내가 할 수 있는 한 사이클(설계-제작-제어)은 이번 과정으로 끝나게 된다.
 
 
이번 제어 시도 과정은 아래의 전제하에 진행했다.
 
 
ⓐ동역학, 제어공학적으로 안정적이고, 원하는 time-domain specification*을 만족하는 제어를 하는 것이 아닌 단순히 기구학적인 제어(platform을 원하는 곳에 위치시킴)를 하는 것에 목적이 있다. (물론 내가 가능한 선에서는 고려할 것이다.)
 
ⓑ제어 코드의 효율성을 고려하지 않고 그저 원하는 동작을 하는가에만 초점을 두었다. (cpu, gpu 자원 사용량, 연산속도, 딜레이 등을 전혀 고려하지 않음)
 
+) *Time-domain specification은 제어공학에서 시스템을 평가할 때 사용하는 지표이다. 실제 어떤 제어시스템을 주문할 때 이를 사용한다(고 배웠다.) 아래의 글에서 간단하게 설명하고 있으며 Rise time, Peak time, Overshoot, Settling time을 주로 사용한다. 델타로봇의 parallel robot이기에 최종적으로는 모터 1개의 response보다는 모터 3개 input에 대한 platform(end effecotr)의 response를 평가하는 게 적합하다고 생각한다.
 
 
https://www.electronicsengineering.nbcafe.in/time-domain-specifications-of-in-control-system/

Time Domain Specifications of in control system | Electronics Engineering Study Center

If we want time domain specifications of in control system , the performance of a system in time domain is usually evaluated in terms of the following

www.electronicsengineering.nbcafe.in

 
 
 
 
 
 
 
W-delta prototype의 제어를 위해서는 2가지를 준비해야 했고 ①'컨트롤러와 모터 사이의 통신 설정' 그리고 ②'로봇을 제어할 신호(코드) 제작'. 이 그 2가지 였다.
 
 
 
 

① 컨트롤러와 모터(드라이버) 사이의 통신 설정 및 테스트 제어

 
이 부분이 내가 이번 프로젝트가 어려울 것이라고 생각했던 가장 큰 이유였다.
 
 
그간 여러 장치를 제어하고자 ros를 배웠고 또 나름의 코딩공부, 모터 구조등을 공부헀었지만 이렇게 아예 경험해보지 못한 것을 다루는 것은 처음이었기 때문이다.
 
 
하다못해 USB나 WI-FI, Bluetooth 기반 무선통신이면 경험이라도 있어서 걱정을 하지 않았겠지만 EtherCAT(이더켓) 통신은 들어본 적도 없고 상상해 본 적도 없던 것이었다.
 
 
EtherCAT(이더켓)은 산업용 Ethernet(이더넷) 통신 기술이라고 한다. 생소하지만 자세히 따지고 보면 결국 우리가 흔히 컴퓨터에 인터넷 연결을 위해 꽂는 랜선(LAN)으로 로봇을 제어한다는 것이다.
 
+)아래 블로그에서 비교적 간단하게 이더켓을 잘 설명해 주셨다.
https://blog.naver.com/3lastbaek5/222038214941

[EtherCAT] 이더켓이란?그 장점은?

EtherCAT이란? EtherCAT (이더캣)은 Ehternet for Control Automation Technology이다. 이더넷...

blog.naver.com

 
 
#3 글에서도 모터와 모터 드라이버가 이미 결정돼 있었던 이유로 이더켓 통신이 가능함을 꼽았다. 그러면 왜 굳이 이더켓으로 통신하는 로봇을 만들어야 했을까? 
 
 
먼저 이 로봇이 시제품(prototype)이기 때문이었다. 이번 로봇은 최종품이 아니라 그 최종품을 만들기 위한 중간 단계의 로봇이었고 따라서 최종품이 가지는 중요한 특징을 가져야 할 필요가 있었다.
 
 
WIM은 최종적으로는 훨씬 큰 workspace를 가지는 로봇을 이더켓 통신이 가능한 모터(드라이버)로 제어하는 것이 목적이었기에 그에 맞춰 자체적인 델타로봇 설계 기술과 이더켓 기술을 원하고 있었다. 이런 측면에서 '작더라도 이더켓 통신을 사용하는 델타로봇을 처음부터 끝까지 직접 설계하는 경험'은 반드시 필요했던 것이다. (+물론 WIM뿐만 아니라 나에게도 매우 좋은 경험이 되었다.)
 
 
이렇게 완성한 로봇은 이더켓을 사용하기에 추후 만들 델타로봇 제어의 연구용으로도 사용이 충분히 가능하기도 했기에 이더켓 기반의 로봇을 제작한 것이다.
 
 
 
 
 
+)아래의 제어와 통신에 관련된 설명의 경우 제 전공이 아니고 더욱이 관련지식이 많이 부족해서 틀린 내용이 많을 수 있습니다.
 
다른 이유는 '이번 프로젝트에 왜 이더켓을 적용했는지에 대한 이유'보다는 '로봇산업 전반에서 왜 이더켓을 사용하는지에 대한 이유'에 가깝다. 로봇의 정밀한 제어를 위해서는 모터가 정확한 시간에 정확한 동작을 하게 하는 것이 매우 중요하다. 그러기 위해서는 모터(드라이버)와 컨트롤러가 많은 양의 정보를 통신해야 하고(Closed-loop control, Feedback control을 생각하면 된다.) 빠르게 해야 한다.
 
 
이와 관련해서 real-time(실시간성)이라는 용어가 나오는데 이는 컴퓨터공학의 실시간성과는 느낌이 조금 다르고 들었다. 이를 한번 chatGPT한테 물어봤다.
 

 
결국 간단하게 정리하면 빠르게 많은 정보를 고려할 수 있는 closed loop control을 생각하면 되는 것 같다.
 
 
추가로 위의 정보는 모터-컨트롤러 사이의 통신을 집중적으로 다루고 있지만 여러 개의 모터를 제어해야 하는 로봇(특히 메니퓰레이터)의 관점에서 보면 각 모터가 정확하게 (다른 모터와의) 상대운동을 만들 수 있는가의 문제로도 이어진다. 
 
 
메니퓰레이터(Manipulator)로 직선을 그린다고 했을 때(serial이든 parallel이든) 각 모터가 정확한 속도로, 정확한 각도만큼 움직여야 완벽한 직선을 그릴 수 있다. 만약 컨트롤러와 모터 사이의 통신이 원활하지 않으면 삐뚤삐뚤한 직선이 그려질 것이고 이는 로봇의 정밀도의 문제로 이어지게 된다. 
 
 
말이 길어졌지만 요점은 많은 정보를 빠르게 통신할 수 있는 이더켓의 장점이 로봇의 정밀도에도 영향을 줄 수 있다는 것이고 때문에 이번 프로젝트에 적용했다.
 
 
물론 내가 설계한 로봇이 기구적으로 높은 정밀도를 염두에 두고 설계한 것은 아니기에 정밀도를 높이기 위해 이더켓이 적용된 모터 드라이버를 사용한 것은 어떻게 보면 오버스펙의 장치를 사용했다고 볼 수 있다. 이 의문의 답은 앞서 말한 첫 번째 이유로 어느 정도 설명이 될 것 같다.
 
 
 
 
 
 
본격적인 통신에 앞서 이번 테스트에서 사용할 환경(로봇)의 schematic diagram을 그려봤다.


+)schematic diagram에서 PWM이라고 했는데 일반 PWM이 아닌 SVPWM 같은 것을 사용했을 수도 있다. 오히려 그쪽의 가능성이 더 높다.
 
 
 
 
우선 가장 먼저 시도한 것은 SOEM을 이용하여 모터 드라이버와 리눅스가 단순히 통신하는 것이었다.
https://github.com/OpenEtherCATsociety/SOEM

GitHub - OpenEtherCATsociety/SOEM: Simple Open Source EtherCAT Master

Simple Open Source EtherCAT Master. Contribute to OpenEtherCATsociety/SOEM development by creating an account on GitHub.

github.com

여기서 SOEM은 Simple Open EtherCAT Master Library로 리눅스 환경에서 이더켓 통신을 사용하기 위해 사용하는 라이브러리이다. 이미 나와있는 이더켓을 사용하는 ROS패키지나 다른 코드 대부분이 이 SOEM을 사용하고 있는 것으로 보인다.
 
 
EtherCAT의 경우 Master와 Slave 구분을 해야 하는데 나의 경우 모터 드라이버가 자체적으로 Slave이기 때문에 굳이 신경 쓰지 않고 컨트롤러를 Master로 정해주면 됐다.
 
 
SOEM으로 간단한 테스트 하는 방법은 아래의 블로그 글을 참고했다. 나의 경우는 RaspberryPi(Raspbian)이 아닌 노트북에 우분투 환경이었지만 크게 다른 점은 없었다.
 
https://lablk.blogspot.com/2017/07/ethercat-soem-ethercat.html

[EtherCAT] SOEM을 활용하여 라즈베리파이를 EtherCAT 마스터로 만들기

라즈베리파이에 SOEM을 설치하여 EtherCAT 마스터로 동작하도록 할 것이다. 라즈베리파이는 B+ 모델을 사용했으며, OS로 2017년 03월 02일 버전 raspbian-jessie를 사용했다. 먼저 최신 버전의 SOEM을 다운로

lablk.blogspot.com

 
★위 글의 내용을 진행해도 테스트 환경에 따라 정상적으로 simple_test와 slabeinfo가 작동하지 않을 수 있는데 그때는 아래 2가지 사항을 확인해 보면 될 것이다.
 
 
1. 가장 애먹었던 부분이 시리얼 이름이 온라인상의 많은 예제처럼 eth0로 되는 게 아닌 enp2s0였던 것이었다. (우분투 환경이라 그런지, Realtek의 이더넷 모듈을 사용해서 그런지는 모름) 이더넷 시리얼 이름을 모를 때는 $ifconfig 명령어로 쉽게 확인 가능하다.
 
 
2. 명령어 앞에 sudo를 붙여준다. 우분투에서 이더넷 포트를 사용하려면 일반적인 usb를 사용할 때와는 달리 권한이 중요한 것 같다.
sudo ./simple_test enp2s0     또는    sudo ./slaveinfo enp2s0

정상적으로 잘 작동했다.
 
2번째 사진을 보면 slave1은 delay가 0이지만 slave2, slave3로 갈수록 delay가 증가하는 것을 볼 수 있다. delay는 daisy chain(serial connection)으로 모터 드라이버가 연결되어 있기에 뒤로 갈수록 증가하는 것으로 보인다. 만약 드라이버가 모두 병렬로 controller에 연결되어 있다면 3개다 delay가 0이거나 같을 것으로 예상된다.
 
 
추가로 delay가 1300ns면 엄청 작은 것이라고 한다. 
 
 
 
 
 
 
SOEM 단독으로 이더켓 통신에 성공했으니 다음으로 시도한 것은 ROS기반으로 모터 드라이버와 통신하는 것이었다.

 
 
다행이 위에서 사용한 SOEM이라는 좋은 툴이 있기에 이를 이용해 ros pkg와 node를 구성했다. 
 

성공했다!
 
 

 

★이후의 개발 과정은 회사 내부의 기술로써 자세히 공개하지는 않고 과정 일부분과 결과만 공개하겠습니다.

WIM 내부 인원 혹은 열람 허가를 받은 분은 '[보호] 2023-2 델타 로봇(Delta robot) - (제어 파트 세부 ver.)' 글을 참고해주세요.

 


●통신에 성공한 이후 실물 로봇을 테스트 제어하기 위해 우선 ros_control의 JointTrajectoryController를 사용했다. 개인적으로 테스트 단계에서는 JointTrajectoryController를 사용하는데 그 이유는 다른 controller는 테스트할 때 터미널이나 코드를 구성해 제어신호를 publish 해줘야 하지만 이 controller는 rqt에서 슬라이더 형태의 gui를 제공하기 때문이다. 덕분에 테스트 단계에서는 훨씬 직관적이고 편하게 로봇을 제어할 수 있다.
 
 
+)만약 rqt에 joint trajectory controller가 없다면 ros_control이 깔려있지 않은 상황일 것이다. 보통은 ros를 설치할 때 같이 설치되는데 설치가 되지 않거나 패키지에 문제가 있는 것이다. 이 경우 ros_control을 설치해 주면 rqt에 생길 것이다.
 
https://wiki.ros.org/ros_control

ros_control - ROS Wiki

The ros_control packages are a rewrite of the pr2_mechanism packages to make controllers generic to all robots beyond just the PR2. The ros_control packages takes as input the joint state data from your robot's actuator's encoders and an input set point. I

wiki.ros.org

 
 
●joint trajectory controller를 이용해서 로봇을 처음으로 제어해 봤다.

잘 작동했다. 뒤쪽 모니터를 보면 슬라이더를 움직이고 있다.
 
  
 
 

②로봇을 제어할 신호(코드) 제작

 
앞에서 ROS를 이용해 리눅스와 드라이버의 통신에 성공했고 gui로 제어를 했으니 이제는 gui가 아닌 노드를 만들어서 joint trajectory controller를 사용할 차례이다.
 
●position_trajectory_controller가 subscribe 하는 topic을 rqt의 topic monitor를 이용해 확인해 보니 /postion_trajectory_controller/command라는 이름의 JointTrajecotry type의 topic을 사용하고 있었다. 즉 그냥 이 topic을 만들어서 publish 해주기만 하면 로봇을 position control 할 수 있는 것이었다.
 
 
데이터의 흐름을 좀 더 이해하기 쉽게 diagram으로 그려봤다.


●IK의 경우 나는 이미 코드를 갖고 있었다. 이전 #1에서 델타로봇의 IK(Inverse Kinematics)를 공부하기도 했고, #2에서 사용한 Delta-robot kinematic의 코드가 있었기 때문이다. 이 매트랩 코드와 배운 지식을 바탕으로 rospy를 기반으로 한 IK for W-delta를 만들었다. 이 과정에서 Delta-robot kinematic의 코드와 내가 만든 W-delta prototype의 좌표계 세팅이 달라서 이를 반영해 주었다.
 

 
+) 아랫부분은 제어에 대한 이해가 부족한 상태에서 빠르게 기능을 흉내내기 위해 나름대로 탐구하고 시도한 방법입니다. 실제 현장에서는 여러 동역학, 제어공학, 모터드라이버의 기능 등을 이용한 solution을 사용합니다.
 
●사실 위 diagram의 control code는 제대로 된 것이 아니다. 위 diagram은 단순히 어떤 platform의 postion을 주면 그 postion에 해당하는 joint의 angle state를 계산해 그 angle로 모터를 회전시키는 방식이다. Position controller를 사용하여 Point to point 동작을 만들 때 제어 신호로써 '시작점'과 '끝점' 2개만 주게 되면 모터는 (추가 설정이 없는 이상) 가능한 최대의 가속력을 주어 가속한 후 최대의 속도로 이동한 후 다시 최대의 가속력을 주어 감속할 것이다.
 
 
이 방식의 문제는 모터가 과하게 큰 토크를 사용한다는 것이고, 때문에 감속 때 오버슛(overshoot)도 크게 발생하여 정밀도도 떨어진다는 점이다. 물론 과한 토크로 인한 내구성의 문제도 발생할 것이다.
 
 
●때문에 position control을 이용해 가속과 감속을 조절하기 위해 나는 '시작점'과 '끝점'을 입력으로 받으면 그 사이를 '여러 개의 점'으로 나눈 다음 그 점들을 연속적으로 publish 하는 방법을 사용했다. 직관적으로 이해하기 쉬운 방법이면서, 점들의 수와 그 사이 delay를 조절해서 모터의 속도를 조절할 수도 있다는 특징이 있었다.
 
+)당시 나는 이를 Motion planning으로 표현했는데 이 표현이 맞는지는 잘 모르겠다. 
 
 
 
위 과정을 바탕으로 Point to point를 먼저 구현했고 이를 이용해 앞선 Gazebo 시뮬레이션에서 했던 'ws 꼭짓점 찍기' 동작 외에도 'Pick and place' 동작, 'Helix curve 그리기' 등을 구현했다. (Gazebo때의 코드는 IK노드가 없어 angle을 input으로 주었지만 이번 코드는 IK노드가 있기에 position을 넣어주면 됐다.)
 
 
물론 그 과정에서 platform의 제어 계산 상의 position과 실제 로봇 platform의 위치가 일치하는지도 확인했다. 영점도 눈대중으로 조정하고 간단하게 만든 코드를 사용한 로봇치고는 만족스러운 정확도를 보여줬다. 
 
 
Pick and place (Slow)

 
 
Pick and place (Fast)

 
 
ws vertice

 
 
 
Helix curve

 
 
 
 
 
 
 
여기까지 마치니 인턴기간이 끝났다. 다행히 끝나기 전에 잘 작동시키는 것까지 성공해서 정말 다행이었다.
 
 
아래는 이번 제어 코드에는 담지 못했지만 추후 제대로 된 제어코드를 짤 때 사용하려고 찾아본 글이다. 
 
https://robotics.stackexchange.com/questions/10052/position-control-vs-velocity-control-vs-torque-control

Position Control vs Velocity Control vs Torque Control

Please can somebody explain to me the difference between Position Control, Velocity Control, and Torque Control? Specifically, I am thinking in terms of a robot arm. I understand that position cont...

robotics.stackexchange.com

 
https://www.motioncontroltips.com/what-is-a-motion-profile/

What is a motion profile?

www.motioncontroltips.com

 
이번 프로젝트와 로봇에 대한 리뷰는 다음 #8에서 다룰 예정이다.
 
 
 
 
 
 

========================================================================
정확한 정보 전달보단 공부 겸 기록에 초점을 둔 글입니다.
틀린 내용이 있을 수 있습니다.
틀린 내용이나 다른 문제가 있으면 댓글에 남겨주시면 감사하겠습니다.   : )
========================================================================

반응형