2023-1 4족보행 로봇(Quadruped robot) 만들기 #9 (urdf 제작 및 rviz, gazebo 3)

#8까지 해서 4족보행 로봇 prototype의 설계, 모델링, urdf제작 및 gazebo 설정을 계속 공부하면서 맞춰두었던 상태였다.
 
 
하지만 다른 프로젝트를 진행하고 와서 다시 보니 이전에는 보이지 않던 문제도 보였고 더 깔끔하게 '시뮬레이션 환경 세팅 프로세스'를 정립할 수 있겠다는 생각이 들었다. 그래서 설계와 모델링은 그대로 사용하고 urdf와 gazebo 세팅을 처음부터 다시 했다.
 
 
우선 새로 발견한 문제는 총 3개였고 전부 해결했다. 아래는 새로 발견한 문제와 더불어 앞서 다뤘던 문제의 해결 방법을 여러 trial-error와 공부를 통해 찾은 내용을 정리했다.
 
 
①(New)현재의 4절 링크(loop kinematics)를 생략하고 만든 urdf는 기구학이 아예 달라져 시뮬레이션에서 사용한 제어 코드를 실물에 사용할 수 없다.
 
>>방학 때 진행했던 델타 로봇 프로젝트에서 loop kinematic을 urdf와 gazebo에서 구현하는 법을 공부했기에 이제는 쉽게 만들 수 있었다. dummy_tibia 링크를 추가한 후 gazebo joint를 이용해서 구현했다.
 
이 방법은 gazebo에서만 유효하고 urdf 단독으로는 loop kinematics를 구현하지 못한다. 그래서 추후 rviz를 사용하려면 joint_state 노드 관련해서 추가 작업이 필요할 것으로 보인다. 아래 글은 델타 로봇 프로젝트 때 공부한 부분이다.
 
https://istein.tistory.com/110

2023-2 델타 로봇(Delta robot) - #4 (URDF 제작 및 Gazebo 1)

 

 
②(New)추후 기구학 계산을 하다 인지한 문제였는데, 기존 urdf에 세팅의 standby(그냥 서있기)동작의 leg 각도를 쓰면 걷는 과정에서 다리를 들 수 있는 범위가 너무 작다는 것이었다. 
 
>>아직 여러 gait에 필요한 범위가 어느 정도인지 파악이 되지는 않은 상태라 단순히 standby동작을 좀 더 높게 잡는 것으로 일단 해결했다. 이와 관련된 내용은 다음 글에서 자세하게 설명할 예정이다.
 
 
 
③(New)Controller로 effort_controllers/JointPositionController를 사용하니 각 joint별로 각기 다른 controller가 만들어졌고 이 때문에 제어를 위한 topic을 총 12개를 보내야 했다.
 
>>GroupController가 있다는 것을 알게 되어서 바로 이로 교체해 줬다. 일반 controller를 사용하면 각 제어신호로 Float64 type의 topic을 보내야 하지만 GroupController는 Float64Multiarray로 한 번에 받기에 더 깔끔하게 제어가 가능하다. 물론 GroupController를 쓰더라도 joint 각각에 대해 PID gain을 조정할 수 있다.

한편 이전 ros_arm 프로젝트에서는 이를 사용하지 못했던 이유가 아두이노의 버퍼 메모리 용량 때문이었다. 아두이노의 버퍼 메모리 용량이 너무 작아 rosserial로 MultiArray를 보낼 수 없었기 때문이었다. 왜인지 MultiArray는 안 보내져도 멀 티쓰레딩으로 Float64를 동시에 여러 개 보내는 것을 가능했었다;
 
 
추가로 이전 델타 로봇 프로젝트 때와 이번에 ros_control에 대해 알게 된 것이 많아서 아래에 추가로 정리했다. 
=======================================================
●effort_controller는 input을 의미하는 게 아닌 output을 effort로 한다는 의미이다. 현실의 물체를 제어하는 건 결국 힘(토크)이기 때문에(F=ma, T=jw에 따라) effort_controller가 가장 일반적이고 기본적인 controller이다. 뒤에 PositionController냐 VelocityController는 input 신호를 말하는 것이다.
https://answers.ros.org/question/331421/ros-control-effort-controllers-explained/

ros control effort controllers explained? - ROS Answers: Open Source Q&A Forum

 
 
●JointTrajectory controller와 JointPositionController 차이점 :
그동안 JointTrajectory controller도 rqt의 gui 툴 기준으로 position(angle[rad])를 넣어줬기에 position을 input한다고 착각하고 있었다. 이번 WIM인턴 기간에 공부하던 중 알아낸 것은 gui툴은 position을 controller에 넣어주는 게 아닌 넣어준 position으로 이동하는 trajectory를 input으로 controller에 넣어주고 있었음. 이는 JointTrajectory controller가 ref로서 subscribe하는 topic의 type이 'JointTrajectory'인 것에서 확인 가능하다.
 
한편 JointPosition controller는 말 그대로 ref input으로써 float64의 position(angle[rad])을 subscribe한다.
 
이 글은 JointTrajectory controller에 대한 글
https://get-help.robotigniteacademy.com/t/understanding-the-effort-controller-jointtrajectorycontroller/20787/2

Understanding the effort_controller/JointTrajectoryController

이 글은 JointPosition controller에 대한 글
https://roboticscasual.com/ros-tutorial-control-the-ur5-robot-with-ros_control-tuning-a-pid-controller/

ROS Tutorial: Control the UR5 robot with ros_control - How to tune a PID Controller - Robotics Casual

 
각 특성을 고려했을 때 입력해줘야 하는 parameter의 개수는 다르지만 JointTrajectoryController를 쓰면 부드럽게 이동하고 PositionController를 쓰면 바로 최대한 빨리 그 위치로 움직였다. 따라서 PositionController를 쓴다면 Trajectory Planning을 하는 노드가 반필수적으로 필요해 보인다.
=======================================================
 
 
 
④fusion2urdf로 가져온 urdf를 그대로 쓰면 '분해돼서 link가 한 점에 몰려있음', 'joint에 명령을 주지 않아도 막 움직이면서 날아다님', '계속 바닥면에서 미끄러짐', '움직임이 너무 느림(*이 로봇의 경우 너무 느리게 넘어졌음)', 'link가 탄성이 있는 것처럼 튕김' 등의 문제가 발생한다.
 
>>일단 이 문제들은 어느 하나의 원인에 의해 발생하기보단 여러 문제가 얽혀서 발생하는 문제로 보인다. 그래서 내가 했던 모든 조치를 적었다.
 
●일단 gazebo는 너무 작은 mass와 inertia를 가진 urdf에 대해 오류가 있다는 것 같다. 그 정도가 어느 정도인지는 모르겠지만 이번 quadruped의 모든 link가 1kg(mass 0.1)미만으로 설계되었는데 그대로 urdf를 만들면 어김없이 문제가 발생했다. 따라서 mass와 inertia에 10배(e+1)를 해주었다. 
 
물론 이렇게 하면 모터의 세팅도 실제 모터 datasheet의 값을 사용할 수 없게 되고 동역학적 시뮬레이션은 현실 로봇과 많이 달라진다는 문제가 발생하지만 이번 프로젝트의 경우 중요도가 높지 않다고 생각해서 10배 한 urdf로 진행했다. 
 
 
●fusion2urdf로 만든 urdf(xacro)의 경우 inertial의 inertia가 이상한 경우가 많았다. 대부분의 gazebo 상의 문제들은 inertia(Mass moment of inertia)가 이상하게 설정되어서 생긴다는 국내외 커뮤니티의 글을 많이 봤고 관련된 실험도 여러 번 진행해 봤다.
 
특히 mass와 inertia가 너무 작은 부품의 경우 fusion2urdf로 넘길 때 inertia가 전부 0.0으로 되는 경우가 있는데 이는 gazebo에선 큰 문제가 된다. 
 
또한 값이 충분히 크더라도 오류가 나는 경우가 많아서 자체적으로 fusion2urdf에 문제가 있다는 결론을 내렸었고 해결책으로 urdf inertia calculator를 사용하였다. 관련 사용법은 이전 글에서 자세히 다뤘다.
 
https://istein.tistory.com/104

2023-1 4족보행 로봇(Quadruped robot) 만들기 #8 (urdf 제작 및 rviz, gazebo 2)

https://github.com/gstavrinos/calc-inertia

GitHub - gstavrinos/calc-inertia: Based on a provided URDF (or xacro), it reads all geometries that have a mass inertial tag, an

 
●gazebo tag에서 self_collide가 켜져 있는 경우에도 심한 진동이나 모델의 붕괴가 발생할 수 있다. 로봇 내에서 link 간의 충돌에 대한 시뮬레이션이 무조건 필요한 경우가 아니라면 이를 false로 두고 시뮬레이션을 하는 것을 추천한다.
 
 
●미끄러지는 문제의 경우 inertia에 의한 것도 있었겠지만 link와 ground 사이의 마찰력의 부재, joint의 관한 진동도 큰 영향을 주었다. 그래서 gazebo tag에 <mu1>, <mu2>를 추가해 줬고, 진동을 잡기 위해 모터의 effort_limit과 controller.yaml의 PID gain을 조정해 주었다. 특히 마찰계수의 경우 현실과 같은 0.6~0.8을 사용하니 문제가 충분히 개선되지 않아서 임의로 10.0이라는 비현실적인 수치를 주었다. 
 
추가로 PID gain의 경우 모델마다 다르겠지만 나의 경우 D값을 낮추는 것으로 문제를 크게 줄였다.
 
 
●link가 탄성이 있는 것처럼 움직이는 것은 gazebo tag의 kp, kd 값을 조절해 주는 것으로 해결했다. 이 또한 이전 #8글에서 다뤘다.
https://istein.tistory.com/104

2023-1 4족보행 로봇(Quadruped robot) 만들기 #8 (urdf 제작 및 rviz, gazebo 2)

https://campus-rover.gitbook.io/lab-notebook/campusrover-lab-notebook/faq/bouncy-objects

bouncy-objects.md - Autonomous Robotics Lab Notebook

 

 
 
 
 
 
 
 
 
 
이렇게 새로운 urdf를 만들었고 아래는 위에서 말한 내용들을 추가한 fusion2urdf를 이용한 urdf제작 프로세스이다.
================================================================
※이 과정으로 만드는 로봇 urdf는 기본적으로 토크, 속도 제어가 아닌 각도 제어가 전제이다.
 
1. 모델을 인벤터나 fusion으로 제작한다. 이 과정에서 mass나 inertia는 신경 쓰지 않아도 된다.
 
 
2. fusion에서 부품들을 assemble한다. 이때 fusion2urdf에 맞는 방식으로 제작해야 한다.(#7 글에 설명 O)
 
 
3. 성공적으로 urdf를 만들었다면 display.launch로 우선 rviz에서 모델이 잘 나왔는지, joint는 이상 없는지를 확인한다.
 
 
4. 이상이 없다면 description 패키지에서 아래의 것들을 수정한다.
ⓐurdf의 link별로 알맞은 mass로 수정해 준다. 이때 너무 가벼워서 오류가 발생한다고 판단되는 경우 적절하게 n배 해준다.
 
ⓑurdf inertia calculator로 수정한 mass에 맞는 inertia를 계산한 후 urdf에 반영해 준다.
 
ⓒ.gazebo에서 <mu>, <mu2>, <kp>, <kd>, <self_collide> tag등을 적절하게 넣어준다. (#8 글에 설명 O)
 
ⓓlaunch 폴더의 controller.launch와 controller.yaml을 수정해 준다. (#8 글에 설명 O)
 
ⓔgazebo.launch로 urdf가 무너지지 않고, 미끄러지지 않고 잘 서 있는지 확인한다.
 

5.잘 만들어졌으면 임시로 controller를 JointTrajectoryController로 바꿔주고 yaml도 그에 맞게 바꿔준다. 이는 rqt에서 제공하는 Joint Trajectory Controller 플러그인을 사용하기 위함이며 제어 코드가 없을 때 gui로 간편하게 joint가 잘 작동하는지 테스트할 수 있다. 
 
6.로봇이 잘 움직이고 사실적으로 움직이는지 확인한다. 만약 문제가 있으면 앞으로 돌아가 수정한다.
 
7.mass, inertia, gazebo tag, PID gain을 적절히 수정해 더 사실적인 움직임을 만든다.
================================================================
 
 
 
아래는 완성된 urdf를 gazebo에서 시뮬레이션한 것이며 역기구학 해석과 제어코드도 어느 정도 만든 후에 찍은 영상이다. 역기구학과 제어코드에 관한 내용은 다음 글에서 다룰 예정이다. 

물리적으로 문제없이 잘 작동한다.
 
영상에서 보여준 동작은 push_up과 quadruped robot의 기본적인 gait 중 하나인 crawling이다. 이는 다음 글에서 다룰 것이고 gait에 대한 글은 따로 작성할 예정이다.
 
 
 
여기까지 오는데 너무 오래 걸렸지만 이제 어지간한 로봇은 gazebo에서 시뮬레이션해볼 수 있겠다는 자신감이 생겼다.
 
 
 
 

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