ROS가 돌아갈 메인 PC인 Jetson이 있고, 거리가 조금 떨어진 원격지에서 노트북으로 Jetson을 컨트롤하고자 한다.
작년에는 VNC를 이용해 GUI 기반의 원격 접속을 했었는데, 매 순간 큰 단위의 이미지를 전송해야 하다 보니 끊김현상이 심하고 원격 접속이 잘 끊어지는 등 원활하지 않았다.
이번엔 Text 기반의 SSH 접속을 시도해 네트워크 부하를 줄이고자 한다.
우선, 원활한 작업을 위해 라우터에 유선 연결로 Jetson에 이더넷을 연결했다.
아래 1~3의 사항은 이전 포스팅을 참고해 진행했다. 오류 측면에서 설명을 넘어간 부분은 해당 포스팅을 참고한다.
대부분의 내용은 root 권한으로 실행하므로, 아래에서 제시하는 명령어들은 앞에 sudo를 붙이거나 root 권한으로 바꿔 로그인해 진행한다.
root 권한으로 쓰려면 먼저 root 비밀번호를 지정해야 한다. sudo passwd로 현재 유저의 비밀번호 -> root 유저의 비밀번호 설정 -> 재확인 의 절차를 거쳐 설정을 끝낸다. 이후 su - 명령을 내리고 root 유저 비밀번호를 입력하면 프롬프트가 #으로 바뀌며 유저명도 root로 바뀜을 확인할 수 있다. 이때부터는 sudo를 앞에 붙이지 않아도 루트 권한의 명령이 가능하다. 다만, 자칫 컴퓨터가 망가질 수 있으니 신중히!
nmcli g로 현재 상태를 확인한다. connected가 되어 있다면 네트워크가 연결된 것이며, ‘(local only)’ 같은 것이 connected 뒤에 붙어 있으면 연결이 안 된 것이다.
nmcli n으로 네트워킹 상태를 조회한다. ‘enabled’가 되어 있는지 확인하고, ‘disable’로 꺼져 있다면 nmcli n on으로 네트워크를 켠 다음 다시 nmcli n으로 확인한다.
nmcli d로 네트워크 장치를 확인한다. DEVICE 열의 eth0가 유선 연결을 뜻한다. 와이파이로 접속을 했다면 wlp1s0와 같이 뜰 수도 있다. 초록색 글자에 STATE는 connected가 뜬다. 만약 disconnected가 뜬다면 nlcli dev connect <디바이스 이름>으로 커넥트를 먼저 시켜주고 진행한다.
ifconfig나 ip address로 eth0을 찾아보면 inet 뒤에 Jetson의 IP 주소가 나온다. 이를 메모해둔다.
필자는 129.168.0.114가 나왔다.
apt list openssh*
SSH 서버와 클라이언트 등 관련 유틸의 설치 여부를 확인한다. ‘installed’가 있으면 최신 설치가 된 것이고, ‘upgradable’이거나 아직 설치가 되지 않았다면 설치를 진행한다.
apt install openssh-server
apt list openssh*
위와 같이 전부 설치가 된 것을 확인한다.
sshd 서비스가 실행중인지 확인한다. ‘active (running)’ 아라고 표시됨을 확인한다.
systemctl status sshd
sshd가 LISTEN 상태인지 확인한다. ssh는 포트 번호 22번을 사용한다. 따라서 22번에 해당하는 State가 LISTEN임을 확인한다. Port번호가 22번인 것이 2개 있는데, 하나는 IPv4, 하나는 IPv6이다.
ss -nlt
sshd가 LISTEN 상태이더라도 방화벽이 막혀있다면 작동이 안 될 수도 있다. 우선, 방화벽 허용 여부를 확인한다.
iptables -nL
방화벽 관련 유틸 ufw로 방화벽 상태나 허용/비허용을 설정할 수 있다.
ufw staus
위 명령어로 방화벽이 inactive/active인지 확인할 수 있다. 필자는 해당 command를 찾을 수 없다는 오류가 떴는데, ufw가 설치되지 않았기 때문이었다. 따라서 먼저 설치를 진행했다.
apt install ufw
ufw status
그 다음으로는 방화벽을 활성화시키고, 특정 포트 번호, 우리는 22번에 방화벽을 허용한다. 여기서 ‘22’ 대신 ‘ssh’라고 입력해도 된다.
ufw enable
ufw allow 22/tcp
이제 노트북으로(다른 컴퓨터로) Jetson에 접속해보겠다.
다른 컴퓨터로 SSH 접속을 하려면 그 컴퓨터의 user ID와 IP 주소를 알아야 한다. 후자의 경우 1번 과정에서 메모해두었고, 전자의 경우 쉬이 알 수 있다. 터미널 창의 프롬프트 앞, @ 앞에 붙은 것이 유저 아이디이다. 필자의 경우 itricat이었다.
현재 네트워크 연결 상태로는 아래와 같았다. 사용한 공유기는 Jetson과 노트북이 동일했으며, 공유기는 우선 유선 연결되어 인터넷이 가능한 상태였다.
ip address로 조회 시 디바이스 wlp1s0에 inet(IP주소) 192.168.0.4이제 정말 노트북에서 Jetson으로 ssh 연결을 시도한다. 명령어는 일반 유저 권한으로 실행해도 된다. ssh -Y 서버유저명@서버IP주소 식으로 입력한다.
$ ssh -Y itricat@192.168.0.114
그러면 서버 쪽 User의 비밀번호를 입력하라는 문구가 뜬다. 비밀번호를 입력해주면 아래와 같이 유저 이름이 노트북 유저에서 Jetson 유저로 바뀌며 SSH 연결이 성공적으로 수행된다.
와이파이와 이더넷으로 연결법은 다르지만 같은 공유기를 쓰고 있는 상황이다. 그래서 연결이 잘 된 건 아닐까 하여 노트북의 네트워크를 바꿔보았다. (그도 그럴 것이 네트워크 마스크가 255.255.255.0이니 IP 맨 뒷자리가 각각 4, 114이므로 같은 네트워트 내에 존재했다.)
해서 이번엔 노트북을 스마트폰 핫스팟 연결로 인터넷에 연결했다.
wlp1s0에 inet(IP주소) 192.168.18.136다시 4.2의 과정을 반복해보았다.
$ ssh -Y itricat@192.168.0.114
그래도 연결이 잘 되었다! 두 컴퓨터의 네트워크가 다를 때의 연결을 해본 것이다.
실제 가동에서는 Jetson은 배에 싣기 때문에 공유기에서 LAN선으로 직접 유선 인터넷 연결을 할 수 없다. 따라서 유선 연결 없이 Jetson과 공유기만 연결되어 있어도 SSH 연결이 가능한지 테스트해보려 한다.
사실 이 과정은 된다는 걸 알고는 있다. 그래도 혹시 모르니 직접 실습해보았다.
다시 4.2의 과정을 반복해보았다.
$ ssh -Y itricat@192.168.0.114
이번에도 성공적으로 연결이 되었다! 정말정말 끝!
이젠 직접 작동을 해볼 시간이다. LiDAR를 테스트하는 패키지를 실행시켜 볼 것이다. Jetson에 LiDAR를 연결하고, 미리 준비해둔 패키지를 실행시켰다. 당연히 실행은 노트북에서 SSH 접속된 터미널을 통해 했다.
$ sudo chmod 777 /dev/tty*
# USB 연결된 센서에 권한 부여
$ ls -l /dev/tty*
# 권한 부여 상황 확인. LiDAR가 연결된 쪽에서 rwxrwxrwx가 된 것을 확인
$ roslaunch tricat221 test.launch
# ROS 실행
연결된 LiDAR와 Jetson에서의 패키지가 잘 작동했다.
이번엔 창을 하나 더 띄워서 rqt_graph도 그려보았다. 이는 Text 기반의 XTerminal 에서도 창을 띄울 수 있는지 여부를 보려는 시도였다.
다시 터미널을 하나 연다. 이 때는 노트북 유저로 열리기 때문에 ssh 접속을 한 번 더 해줬다. 그리고 rqt_graph를 실행했다.
$ ssh -Y itricat@192.168.0.114
$ rqt_graph
rqt 그래프 창이 열렸다! 사실 토픽 하나가 연결이 안 되어 있었지만, 이것은 SSH 테스트를 위함이라 크게 신경쓰지 않았다. 패키지 내부 문제겠거니…
Jetson에서 직접 작동시킬 때는 로컬에서 작동하므로 당연히 터미널을 여러 개 띄워서 작업이 가능했다.
그러나 노트북에서 SSH로 접속하면 터미널 하나에만 접속이 되므로 한 작업이 실행되고 있을 때 다른 작업(rqt_graph, rviz 등)을 하려고 하면 새 접속을 시도해야 했다. 접속이 많아질수록 서버 쪽은 부담이 커지므로 처리가 느려진다.
아직 방법을 모르는 것일 수도 있겠지만 지금의 지식으로서는 여러 프로세스를 제어하고 싶다면 여러 접속을 하는 수밖에 없는 것 같다.
rqt_graph는 잘 되었지만 rviz로 Rviz를 실행시켜보았을 때는 오류가 뜨면서 프로세스가 동작하지 않았다. 무슨 원인인지는 따져봐야 알겠지만, 실행이 되었더라도 Rviz는 그래픽이 많이 들어가다 보니 속도가 느리거나 Jetson이든 노트북이든 실행 프로세스가 다운되지 않았을까 싶다.
긴 시간 Windows를 써왔기에 GUI가 익숙한 필자로서는 아무리 편리하다고 해도 CLI 환경이 답답하긴 했다. 하지만 GUI 연결은 속도가 너무 느리고 불안정하다. 물론 SSH도 속도가 즉각즉각 반응할 정도의 속도는 아니다. GUI보다는 훨씬 빠르단 소리다. 일장일단이 있어 고심을 해봐야겠다.
