[#4 URDF 제작 및 Gazebo 1]에서 이어집니다.
이전 #4까지 완료하면 URDF를 만들어서 gazebo에 올린 후 control(ros_control)할 기초적인 준비까지 끝난 것이다.
우선 테스트 제어 전에 controller의 정보를 간략하게 정리해 보면 다음과 같다.
type : effort_controllers/JointGroupPositionController
topic : /arm_position_controller/command (Float64MultiArray)
+)만약 #4에서 controller를 effort_controllers/JointPositionController 그대로 사용했다면 topic은 각 controller(motor)별로 /controller이름/command (Float64)로 사용하면 된다.
추후에는 여러 가지(속도, 토크, 가감속 시간 등)를 고려해야겠지만 결국 이 로봇의 제어는 "어떤 모터를 몇 도에서 몇 도로 움직여라"가 될 것이다.
즉 내가 테스트에서 확인할 것은 원하는 모터를 원하는 각도로 움직일 수 있는가이다.
현재 PositionController를 사용하고 있기에 FloatMultiArray로 들어간 3개의 값은 각각 motor_1, motor_2, motor_3의 position input(각도, [rad])이 될 것이다.
이를 염두에 두고 터미널로 직접 제어 신호를 publish 해주었다.
+그냥 layout을 복사해 사용해서 복잡한 것이고 원래는 data 부분만 publish 해주면 된다.
잘 움직인다.
사실 위의 시뮬레이션에 결과를 얻기까지 내가 추가로 설정해 준 부분이 몇 가지 있다. 아마 대부분은 앞선 과정만을 따라한 후 테스트를 하면 '원하는 각도까지 움직이지 못하거나', '과하게 진동하거나', '아예 움직이지 않을 것'이다.
여러 원인이 있을 수 있겠지만 내가 아는 범주에선 2가지가 주요 원인이다. (URDF와 ros_control 세팅이 잘 되었다는 가정하에)
ⓐxacro(urdf)의 joint limit tag에서 부족한 velocity나 effot를 주었다.
ⓑPID gain이 너무 맞지 않다.
ⓐ의 경우 xacro(urdf)의 joint 중에서 actuating을 하는 joint(active joint)만 갖고 있는 tag이다. 내가 만든 델타 로봇의 경우 Base-Bicep의 revolute joint에 있다.
revolute기준 upper, lower는 해당 joint의 최대, 최소 각도를 나타내고, effort는 토크[N*m]를, velocity는 각속력[rad/s]을 나타낸다.
하지만 이를 단순히 힘, 속력으로 생각하고 값을 넣으면 안 된다.
1. 이 tag는 limit tag, 즉 최댓값이기에 해당 모터(joint)가 항상 그 토크, 그 속력으로 움직이는 게 아닌 필요시 입력한 토크와 속력을 낼 수 있다는 것이다.
2. 속력만 높고 토크가 충분하지 않으면 가속하는 데에 너무 긴 시간이 걸려 결국 느린 평균속력을 보일 것이고, 반대로 토크만 크고 속력이 충분하지 않으면 빠르게 가속할 수 있음에도 최대속도에 걸려 느리게 움직일 것이다. 결국 여러 값을 넣어보며 복합적으로 테스트를 해봐야 한다.
3. 현실에서 모터 단독으로는 생각보다 큰 토크를 만들기 어렵다. 하지만 빠른 각속력[rpm]을 만드는 것은 가능하다. 그래서 사용하는 것이 감속기(reducer)이며 말 그대로 '감속기는 감속을 통해 토크를 증가시키는 기능'을 한다. 예를 들어 토크 1N*m, 3000rpm
모터에 50:1 감속비를 가진 감속기를 장착하면 토크 1 x 50 = 50N*m, 3000 / 50 = 60rpm를 작동을 할 수 있게 된다. limit tag의 값을 바꿀 때 이를 고려해서 바꾸면 추후 실물을 제작할 때 훨씬 도움이 된다.
3+) 실제 감속기는 효율의 문제가 있어서 위처럼 50:1을 쓴다고 토크가 50배가 되는 것이 아닌 조금 약한 토크가 나오게 된다. 감속기의 종류, 단(stage) 수에 따라 다르지만 통상적으로 80-95% 사이의 효율을 생각하면 된다.
3++)나도 이 과정을 통해서 델타로봇의 설계를 바꿨다. 이전 설계에서는 감속기 없이 모터 단독으로도 토크가 충분하다고 생각했지만 시뮬레이션을 해보니 가만히 있을 때가 아닌 움직일 때 토크가 많이 부족했다. 사실 최초 토크 계산 때도 정지 상태의 토크 계산 * 2 정도로만 토크를 구했었다. 모터의 원래 스펙에 20:1, 30:1, 50:1 등의 감속비를 곱해서 시뮬레이션을 돌려보았고 그 결과 30:1을 사용해야 한다는 결론이 나와서 해당 감속기를 추가하는 것으로 설계를 변경했었다.
일단 gazebo에 로봇을 spawn 하는 데에 성공했고 제어도 가능한 것을 확인했으니 최종적으로 내가 의도한 ws(workspace)를 충돌 없이 커버할 수 있는지 확인해야 했다.
나는 간단하게 ws의 8개 꼭짓점을 모두 찍는 node를 만드는 것으로 확인했다.
●t를 통해서 속도를 조정한다. (실제 제어 시에는 sleep으로 하지 않는다.)
●각 꼭짓점으로 platform을 이동시키는 모터의 각도, 즉 역기구학 계산은 이전과 같이 아래의 사이트를 이용했다. (어디까지나 테스트이기에 아직은 굳이 역기구학을 적용한 코드를 짤 필요는 없다고 생각했기 때문이다. 물론 이후에 꼭 할 것이다.)
https://www.geogebra.org/m/eAFWSVCM#material/Hf5jfb7T
delta simulator
delta simulator
www.geogebra.org
●참고로 위 사이트의 각도를 읽을 때 좌표계와 각도 기준을 잘 봐서 코드에 넣어야 한다. 내가 만든 델타 로봇의 좌표계와 각도 기준 설정은 아래 그림과 같다.
bicep1이 +x방향을 보게 했고 ws가 base기준 -z방향에 형성되게 했으며 모터의 각도에서 +방향이 아래쪽으로 회전하도록 했다.
+)최초 robot spawn후의 모터의 각도는 0.0이 아니다. Steady state error가 너무 크고 PID gain을 바꿔줘도 개선되지 않길래 0.0 명령을 주었더니 줄어드는 것을 보고 알았다. (약 5º > 약 0.45º)
●Base는 3개의 모터 축 중심이 포함된 평면이 원점 평면으로 설정했고, Platform은 중앙의 구멍 중심을 원점 평면으로 잡았다.
위의 코드를 작동시켰더니 잘 작동하면서 내가 적어도 시뮬레이션 상에서는 내가 의도한 ws를 이 델타로봇이 커버할 수 있음을 확인했다.
이렇게 로봇의 설계, 모델링, URDF제작, Gazebo 환경 올리기가 끝났다. 이제 이를 기반으로 실물을 제작하는 것과 실제 모터를 제어하는 일만 남았다.
========================================================================
정확한 정보 전달보단 공부 겸 기록에 초점을 둔 글입니다.
틀린 내용이 있을 수 있습니다.
틀린 내용이나 다른 문제가 있으면 댓글에 남겨주시면 감사하겠습니다. : )
========================================================================
'인턴, 협업 > WIM' 카테고리의 다른 글
2023-2 델타 로봇(Delta robot) - #7 (제어, 완성) (0) | 2023.09.08 |
---|---|
2023-2 델타 로봇(Delta robot) - #6 (실물 로봇 제작) (0) | 2023.08.31 |
2023-2 델타 로봇(Delta robot) - #4 (URDF 제작 및 Gazebo 1) (0) | 2023.08.17 |
2023-2 델타 로봇(Delta robot) - #3 (설계와 모델링) (0) | 2023.08.12 |
2023-2 델타 로봇(Delta robot) - #2 (ws와 치수 결정을 위한 IK, FK analysis) (0) | 2023.07.20 |