Drake 시뮬레이션은 실행되는데 예상한 접촉 패치 대신 점 접촉이 나타난다면, 강성을 바꾸기 전에 접촉 모델과 양쪽 충돌 지오메트리를 확인해야 한다. 하이드로엘라스틱 접촉에는 양쪽 모두 적합한 표현이 있어야 하고, 그중 적어도 하나는 컴플라이언트 지오메트리여야 한다. 기본값인 kHydroelasticWithFallback은 하이드로엘라스틱 접촉을 지원하지 않는 쌍에 점 접촉을 적용해 시뮬레이션을 계속 실행할 수 있다. 따라서 시뮬레이션이 실행된다는 사실만으로 의도한 패치 모델이 작동한다고 판단할 수는 없다.
이 글은 2026년 9월 15일에 Drake 1.57.0 하이드로엘라스틱 문서와 해당 릴리스의 소스 코드를 대조해 작성했다. 버전 1.57.0은 9월 10일에 릴리스됐다. 하이드로엘라스틱 표현이 없는 지오메트리 쌍에 관해서는 문서와 소스 코드 사이에 차이가 있으며, 아래에서 따로 설명한다. 실제 Drake 장면을 실행하거나 로봇의 접촉력을 검증하지는 않았다.
강체에도 접촉 표현이 필요하다
‘강체(rigid body)’는 물체의 운동을 어떻게 모델링하는지를 나타낸다. ‘리지드 하이드로엘라스틱(rigid-hydroelastic)’은 충돌 지오메트리의 접촉 표현을 가리킨다. 로봇에 강체 링크나 충돌 메시가 있다는 이유만으로 해당 지오메트리가 리지드 하이드로엘라스틱이 되는 것은 아니다.
컴플라이언트 하이드로엘라스틱 표현에는 내부 압력장이 있다. 리지드 표현은 무한히 단단한 것으로 간주되는 표면을 제공한다. 컴플라이언트 그리퍼 패드가 리지드 공구 손잡이와 접촉하면 모델의 접촉면은 손잡이 표면에 놓인다. 두 컴플라이언트 지오메트리가 만나면 두 압력장이 같은 곳에 접촉면이 형성된다. Drake는 이 접촉면에 걸친 압력을 적분해 합력과 모멘트를 구한다. 이 근사 방식은 Drake의 접촉 모델 설명에서 확인할 수 있다.
이 구분은 파지 문제에서 의미가 크다. 접촉 패치는 공간적인 넓이를 가지지만, 점 접촉은 상호작용을 한 점으로 요약한다. 여기서 하이드로엘라스틱 컴플라이언스는 물체의 변형 상태를 새로 도입하지 않는다. 변형체 모델을 대신하는 방식은 아니다. 접촉 패치를 사용하는 모든 시뮬레이션이 실제 파지력을 정확히 예측하는 것도 아니다. 지오메트리와 재료 근사, 작동 조건은 별도로 검증해야 한다.
힘을 조정하기 전에 접촉 쌍부터 읽는다
시각화용 메시가 아니라 실제 충돌 지오메트리부터 확인한다. 아래 표에서 C는 컴플라이언트 하이드로엘라스틱, R은 리지드 하이드로엘라스틱, U는 하이드로엘라스틱 표현이 없음을 뜻한다. 이는 접촉 모델의 분류이며 실제 재료의 물성을 나타내는 이름이 아니다.
| 지오메트리 쌍 | 엄격 모드 kHydroelastic |
kHydroelasticWithFallback |
|---|---|---|
| C + R 또는 C + C | 지원되는 지오메트리가 서로 교차하면 하이드로엘라스틱 접촉 | 지원되는 지오메트리가 서로 교차하면 하이드로엘라스틱 접촉 |
| R + R | 필터링되지 않았고 컬링할 수 없는 쌍이면 예외 발생 | 점 접촉이 해당 쌍을 지원하는 경우 점 접촉으로 폴백 |
| C + U 또는 R + U | 필터링되지 않았고 컬링할 수 없는 쌍이면 예외 발생 | 지원되는 경우 점 접촉으로 폴백 |
| U + U | v1.57.0 소스 코드 경로에서는 예외 발생. 아래의 문서 차이 참고 | 지원되는 경우 점 접촉 |
이 결과는 해당 릴리스의 접촉 쌍 분류 코드와 엄격 모드·폴백 디스패치 코드를 따른다. 규칙은 접촉 후보가 되는 충돌 쌍에 적용되며, 충돌 필터링과 지원되는 형상인지 여부, 두 형상의 실제 교차도 결과에 영향을 준다. 광역 단계(broad-phase) 충돌 검사에서는 세부 접촉 패치를 계산하기 전에 지원하지 않는 쌍이라는 예외가 발생할 수 있다. 필터링된 쌍은 접촉 계산에서 제외된다. 이는 두 물체가 물리적으로 충돌할 수 없다는 뜻이 아니다.
문서와 소스 코드의 차이: v1.57.0 사용자 가이드에는 하이드로엘라스틱 표현이 없는 두 지오메트리를 엄격 모드에서 무시한다고 적혀 있다. 그러나 같은 릴리스의 소스 코드에서 접촉 쌍 분류기는 두 지오메트리 중 하나라도 하이드로엘라스틱 유형이 정의되지 않으면 kUnsupported를 반환하고, 엄격 모드 디스패치는 이 실패 결과에 예외를 발생시킨다. 따라서 U + U 쌍이 조용히 무시된다고 전제해서는 안 된다. 이는 소스 코드를 읽어 확인한 결과이며, 런타임에서 재현한 시험 결과가 아니다. 이 동작이 모델에 영향을 준다면 설치한 릴리스의 작은 장면에서 직접 확인해야 한다.
폴백 열도 모든 오류를 복구한다는 뜻은 아니다. 폴백 쿼리 API는 먼저 접촉면 계산을 시도한 다음 점 접촉 쌍을 계산한다. 두 번째 계산도 할 수 없으면 여전히 예외가 발생할 수 있다. 반대로 kPoint를 선택하면 처음부터 점 접촉을 요청한다. 이 경우 하이드로엘라스틱 속성이 설정돼 있어도 선택한 접촉 모델을 바꾸지 않는다.
첫 번째 행에도 형상별 제한이 적용된다. 예를 들어 v1.57.0의 분류기는 컴플라이언트 half-space와 컴플라이언트 메시의 조합을 하이드로엘라스틱 접촉으로 지원하지 않는다. 두 half-space 사이에서는 유한한 점 침투 결과를 계산할 수 없어 폴백도 성립하지 않는다. ‘적어도 하나가 컴플라이언트 지오메트리’라는 조건은 접촉 패치에 필요하지만, 그것만으로 형상 지원 여부까지 충족하는 것은 아니다.
그리퍼 사례로 두 가지 설정 오류를 구분한다
컴플라이언트 패드가 리지드 공구 손잡이를 잡는 상황을 생각해 보자. 양쪽 지오메트리에 유효한 하이드로엘라스틱 표현이 있으므로 지원되는 C + R 쌍이다. ‘리지드’라는 단어를 피하려고 양쪽을 모두 컴플라이언트로 지정할 필요는 없다.
이번에는 손잡이의 충돌 지오메트리는 그대로 두고 하이드로엘라스틱 표현만 제거한다. 접촉 쌍은 C + U가 된다. 엄격 모드에서는 표현이 빠졌다는 문제가 예외로 드러나며, 폴백 모드에서는 점 접촉이 만들어질 수 있다. 패드의 하이드로엘라스틱 탄성계수를 높여도 손잡이에 빠진 표현이 생기지는 않는다. 이 문제는 매개변수 조정보다 설정을 먼저 고쳐야 한다.
패드와 손잡이를 모두 리지드 하이드로엘라스틱으로 지정하면 또 다른 문제가 생긴다. 양쪽에 속성이 있어도 R + R 사이에는 지원되는 하이드로엘라스틱 패치가 없다. 모델에서 어느 표면에 컴플라이언스를 줄지 결정하거나, 지원되는 점 접촉 모델을 의도적으로 선택해야 한다. 오류 메시지만 없애려고 분류를 정해서는 안 된다.
Drake에서는 모델 파일이나 API로 속성을 직접 지정할 수 있고, SceneGraph의 기본 근접 속성도 사용할 수 있다. 기본값이 설정된 환경에서는 XML 태그 하나가 없다는 사실만으로 해당 지오메트리를 U라고 단정할 수 없다. 실제로 적용된 속성을 확인해야 한다. 모델이나 API에서 명시한 속성은 기본값보다 우선한다. 설정 경로는 사용자 가이드의 표현 설정 항목에 설명돼 있다.
장면이 실제로 계산한 접촉을 확인한다
전체 로봇 모델을 수정하기 전에 작은 진단용 장면으로 확인한다.
- Drake 버전과 선택한 접촉 모델을 기록한다. 해당 릴리스의 문서와 비교한다.
- 두 충돌 지오메트리의 이름과 실제 적용된 C, R, U 분류를 확인한다. 속성과 함께 충돌 필터링 상태와 지원되는 형상인지도 살핀다.
- 충돌 지오메트리와 접촉 시각화를 표시한다. 사용자 가이드의 Meldis 화면에서는 빨간 힘 화살표가 하이드로엘라스틱 접촉 패치와 함께 나타나고, 초록 화살표는 점 접촉을 나타낸다. 보이지 않는 패치를 없다고 판단하기 전에 접촉면 표시가 켜져 있는지 확인한다.
- 의심되는 원인을 한 번에 하나씩 바꾼다. 예상하지 않은 폴백이 일어났다면 강성·마찰·메시 해상도를 조정하기 전에 해당 쌍의 접촉 표현을 고치거나 점 접촉 사용을 의도적으로 받아들인다.
버전 1.57.0의 공식 하이드로엘라스틱 기초 노트북을 시작 예제로 활용할 수 있다. 진단 기록에는 버전, 접촉 모델, 지오메트리 이름, 실제 적용된 분류, 필터링 상태, 관찰된 패치 또는 점 접촉 결과를 남긴다. 이런 기록이 있어야 설정 변경의 의미를 해석할 수 있다. 접촉력의 정확도를 입증하는 벤치마크는 아니다.
아직 시뮬레이션 환경을 선택하는 단계라면 로봇 시뮬레이터 비교에서 더 넓은 선택 기준을 확인할 수 있다. Drake의 지오메트리 쌍이 의도한 접촉 유형을 만든 뒤에는 Sim-to-Real의 의미에서 시뮬레이션 동작을 실제 하드웨어와 맞추는 별개의 문제를 살펴볼 수 있다. 먼저 어떤 모델이 접촉을 계산했는지 확인한 뒤, 그 모델이 실제 작업을 평가하는 데 쓸 만한지 검증해야 한다.