제조공정
산업 제조
우리 국가의 기반 시설은 빠르게 노후화되고 악화되고 있습니다. 현재 우리 교량, 폐기물 탱크, 파이프라인 및 원자로의 상태를 철저히 검사할 수 있는 메커니즘이 없습니다. 이러한 구조의 대부분은 설계 수명이 다했으며 열화 여부를 검사해야 합니다. 육상에서의 이러한 상황과 마찬가지로 미 해군 함정과 유조선의 선체와 갑판에 부식 징후가 있는지 검사할 필요도 있습니다. 높은 교량 및 폐기물 탱크와 같은 많은 오래된 구조물은 여러 가지 이유로 조사하거나 검사하기 어려운 경우가 많습니다. 가장 흔한 이유는 검사 과정이 사람에게 위험하거나 구조물에 접근할 수 없는 부분이 있기 때문입니다. 또 다른 일반적인 이유는 전류 프로브 기술이 그러한 구조를 정확하게 검사하는 데 부적절할 수 있다는 것입니다. 따라서 수동 검사는 드물고 힘들고 비용이 많이 들고 위험하고 오류가 발생하기 쉽습니다. 이 문제는 잘 만들어진 검사 로봇에게 완벽한 기회를 제공합니다.
검사 로봇은 일반적으로 자금이 넉넉한 전기 및 기계 엔지니어로 구성된 대규모 팀에 의해 설계 및 개발됩니다. Packbot 510(http://endeavorrobotics.com/products)과 같은 상업용 로봇의 가격은 10만 달러 이상입니다. 개별 과학 박람회 프로젝트의 제약 조건을 감안할 때 여기의 범위는 검사 로봇을 위한 저렴한 프로토타입을 설계, 개발 및 테스트하는 것입니다. 이 프로젝트의 목표는 검사할 표면에 부착된 상태를 유지할 수 있는 작고 가벼우며 저렴한 검사 로봇 프로토타입을 개발하는 것입니다. 이 프로젝트는 다음 작업으로 구성됩니다. 문헌 및 기존 디자인 검토; 요구사항의 명세; 로봇 디자인; 초기 프로토타입 개발 및 테스트 공학 역학 계산; 파이썬을 사용하여 로봇 프로그래밍; 두 번째 프로토타입의 개발 및 테스트 최종 프로토타입의 개발 및 테스트.
로봇을 물리적으로 구축하기 전에 3D 모델링 소프트웨어 SketchUp을 사용하여 로봇을 시각화하고 설계를 개선했습니다. 로봇은 로봇을 제어하기 위한 Raspberry Pi 3 모듈을 포함하여 상용 기성 부품으로 제작되었습니다. 디자인은 반복적인 테스트를 통해 반복적으로 개선되었습니다. Python 코드는 로봇을 프로그래밍하기 위해 처음부터 작성되었습니다. 설계가 발전함에 따라 하드웨어와 소프트웨어 모두 함께 수정되어야 했습니다. 프로토타입은 Washington River Protection Solutions 및 Pacific Northwest National Laboratory의 엔지니어링 전문가와 Washington State의 Senior Design Class에서 시연되었습니다.
대학, 트라이 시티. 전문가의 피드백, 엔지니어링 역학 계산 및 테스트 결과를 기반으로 세 번째 프로토타입을 제작하고 프로그래밍했습니다. 결과 로봇은 합리적인 속도로 벽을 오를 수 있으며 탐색 및 검사를 돕기 위해 여러 대의 카메라가 있습니다. 이 프로젝트에서 생산된 로봇은 이 목적을 위해 특별히 작성된 소프트웨어를 사용하여 독특한 디자인을 나타냅니다. 이 프로토타입은 검사 기능을 강화하기 위해 필요에 따라 새 센서를 추가할 수 있다는 점에서 유연한 플랫폼 역할을 합니다.
프로젝트 작업을 시작하기 전에 기존 솔루션을 평가하기 위해 문헌 검토를 수행했습니다. 현재 사용 가능한 프로브는 고정식 프로브와 이동식 프로브의 두 가지 유형으로 분류할 수 있습니다.
고정식 프로브는 구조물 검사에 가장 널리 사용되는 도구입니다. 그들은 구조의 특정 섹션에 대한 매우 자세한 정보를 제공하고 지속적으로 모니터링할 수 있습니다. 그러나 일단 위치에 배치되면 관찰 범위가 제한됩니다. 이동성 부족으로 인해 대형 구조물을 모니터링하는 데 적합하지 않습니다. 다른 범주는 로봇 장착 프로브로 구성됩니다. 프로브를 자유롭게 이동할 수 있으므로 더 높은 수준의 기능을 제공합니다. 현재 시장에 나와 있는 대부분의 로봇은 특정 작업이나 검사 유형에 매우 전문화되어 있습니다. 일부 로봇은 물, 높은 고도 또는 늪지대의 반고체 지형을 횡단하는 데 특화되어 있을 수 있지만 이러한 로봇 중 어느 것도 구조 검사에 유용하지 않습니다.
수중 검사 로봇 AQUA 1 좋은 예입니다. AQUA는 고도로 전문화되고 고가의 검사 로봇입니다. 수역의 바닥을 기어다니며 해당 지역을 3차원(3D) 스캔합니다. 카메라, 센서 스캔 및 알고리즘을 사용하여 수중에서 지정된 경로를 따라갈 수 있습니다. 검사로봇임에도 불구하고 철제 표면을 오를 수 있는 능력이 없기 때문에 구조적 검사에는 무용지물이다.
또 다른 예는 AETOS 2 입니다. 공중 드론. AETOS 드론은 측량, 조경 매핑 및 비상 대응에 사용되는 쿼드콥터입니다. 로봇 자체는 고출력 카메라를 매달고 있는 원격 조종 쿼드콥터입니다. 카메라는 구조와 풍경의 상세한 이미지와 비디오를 캡처하고 기록할 수 있습니다. AETOS 드론은 용도가 다양하며 공중에서 다리와 같이 노출된 구조물도 검사할 수 있습니다. 드론의 단점은 정밀한 구조적 점검에는 적합하지 않다는 점이다. 점검 도중에 바람에 의해 드론이 움직일 수 있기 때문이다. 드론은 충돌의 위험이 있으므로 밀폐된 구조 내에서도 사용할 수 없습니다. AETOS 드론은 자주 충전해야 하며 오랜 시간 동안 공중에 떠 있을 수 없습니다. 또한 비용이 많이 들고 손상되기 쉬우며 충돌 시 복구하기 어렵습니다.
현재 사용 가능한 로봇 중 일부는 강력한 센서, 여러 대의 카메라 및 암벽 등반 능력을 갖추고 있습니다. 이러한 로봇은 비용이 매우 많이 들고 검사를 수행하기 위해 많은 수를 배치할 수 없습니다. 이러한 로봇과 관련된 손상 위험 및 교체 비용도 매우 높습니다. 일본 후쿠시마 제1원전에서 손상된 원자로를 검사하는 데 사용된 거의 모든 로봇이 2017년 3월 현재 실패했기 때문에 손상은 매우 현실적인 고려 사항입니다. 고가의 로봇의 예로는 MagneBike 3 가 있습니다. . MagneBike는 아직 상업적으로 판매되지는 않았지만 현재 테스트 및 개인 개발 중인 상당히 새로운 로봇입니다. MagneBike는 자유 조인트로 본체에 연결된 두 개의 바퀴가 특징인 로봇 자전거입니다. 이 조인트를 통해 로봇은 윤곽에 관계없이 모든 철 표면에서 자유롭게 움직일 수 있습니다. 각 바퀴에는 측면에 두 개의 레버가 부착되어 있으며 훈련용 바퀴와 유사합니다. 각 레버의 길이는 각 바퀴의 반경보다 약간 큽니다. 레버는 바퀴가 연결된 자기 표면에서 바퀴를 분리하는 데 사용되어 바퀴가 내부 각도에서 부드럽게 이동할 수 있습니다. MagneBike는 고화질 카메라를 지원하도록 설정할 수 있으며 주변 환경의 3D 모델을 생성할 수 있는 3D 매핑 센서를 지원합니다. 로봇은 케이블을 통해 제어되고 전원이 공급되며 쉽게 회수할 수 있도록 연결된 장치입니다. 그러나 MagneBike의 단점은 부러지면 교체하기가 매우 어렵고 사용된 부품이 아무렇게나 된다면 상당히 고가라는 점입니다.
유사한 자기 바퀴 달린 로봇은 미 해군의 다중 세그먼트 자기 로봇 4 입니다. (MSMR). MSMR은 선박 선체 검사를 위해 설계된 해군 로봇입니다. MSMR은 지상 구조 검사용으로 설계되지 않았지만 구조 검사에 쉽게 적용할 수 있습니다. 또한 선체를 검사하는 것과 산업구조를 검사하는 것은 다른 작업이 아닙니다. MSMR은 3분할 로봇으로, 각 부분은 측면에 두 개의 바퀴가 부착된 전자 장치가 들어 있는 금속 상자입니다. 세그먼트는 유연하거나 접합된 커넥터로 연결됩니다.
각 바퀴는 독립적으로 작동할 수 있으며 로봇은 모든 바퀴가 함께 작동할 때 3D 장애물을 쉽게 확장할 수 있습니다. 바퀴는 자화되어 로봇을 지지할 수 있습니다. 로봇의 단점은 밧줄이 없기 때문에 배터리로만 구동된다는 것입니다. 이는 로봇을 제어하기 훨씬 어렵게 만들고 로봇의 검사 수명을 제한하기 때문에 불리합니다. MSMR은 현재 미발매 상태이며 해군에서만 사용됩니다. 로봇은 아마도 가까운 장래에 그렇게 될 것입니다.
검사 로봇의 또 다른 예는 전방향 벽 등반 마이크로봇 5 입니다. . Microbot은 무게가 7.2g에 불과한 초소형 원형 로봇입니다. 직경 26mm, 높이 16.4mm입니다. 봇은 현재 테스트의 마지막 단계에 있으며 아직 상업적으로 사용할 수 없습니다. 로봇은 360° 회전이 가능한 3개의 마그네틱 휠 마이크로 모터를 지원합니다. 바퀴를 사용하면 대부분의 철이 함유된 표면을 쉽게 횡단할 수 있습니다. Microbot은 단일 마이크로 카메라를 지원하도록 설정할 수 있습니다. 카메라는 간단한 이미지와 비디오를 컨트롤러로 다시 보낼 수 있습니다. 로봇도 묶여 있습니다. 보호를 위해 절연될 수 있는 구리선으로 컨트롤러에 연결됩니다. 로봇은 저렴하고 그룹으로 사용할 수 있지만 단일 카메라만 지원할 수 있고 밧줄이 약합니다. 또한 확장 공간이 부족하고 센서를 지원할 수 없습니다.
표면에 부착하기 위해 프로펠러에 의해 생성된 부압 또는 흡입 컵을 사용하는 로봇 디자인이 있습니다. 흡입 컵은 자기 바퀴에 비해 이동성이 제한적이며 여러 대의 카메라와 센서가 장착된 무거운 로봇에는 적합하지 않습니다. 또한, 기계적 마모로 인해 시간이 지남에 따라 흡입력이 저하됩니다. 음압 시스템은 상당한 전력과 일정한 전력이 필요합니다. 전원이 꺼지면 로봇이 표면에서 분리됩니다. 이전에 시도된 각각의 디자인에는 장단점이 있지만 어느 것도 검사 문제를 완전히 해결하지 못했습니다. 문헌 검토를 통해 풍경을 조사하고 이전에 시도한 것에 대해 배우고 나만의 디자인을 생각해낼 수 있었습니다.
검사 로봇은 몇 가지 제약 조건을 충족해야 합니다. 로봇의 첫 번째 제약은 크기입니다. 검사 로봇은 이상적으로 작습니다. 로봇이 검사할 공간 중 일부는 너비와 높이가 1피트 미만입니다. 이 프로젝트에서 크기는 25x25x25cm로 제한됩니다. 크기가 작을수록 브리지 빔과 같은 복잡한 환경에서 로봇의 이동성과 다양성이 증가합니다. 작은 크기의 장점은 로봇이 더 적은 전력을 소비하고 조작하기 쉽다는 것입니다. 로봇도 연결되어야 합니다. 테더링 로봇은 무선 로봇보다 더 빠르고 안정적으로 더 많은 데이터를 보낼 수 있습니다.
로봇의 컨트롤러는 로봇이 무선 신호 범위를 벗어나는 것을 걱정할 필요가 없으며 사고나 고장 시에도 쉽게 로봇을 꺼낼 수 있을 것이다. 또한 검사 로봇은 철저한 검사 및 탐색을 위해 여러 대의 카메라를 지원해야 합니다. 로봇에서 컨트롤러까지의 라이브 카메라 영상은 로봇이 검사 중인 구조를 통해 정확하게 구동되고 컨트롤러에 즉각적인 위험을 경고하는 데 필요합니다. 로봇이 충족해야 하는 또 다른 제약은 철이 있는 표면을 오를 수 있어야 한다는 것입니다. 이 제약 조건을 충족하는 가장 쉬운 방법은 로봇에 자기 바퀴 또는 자기 본체를 사용하여 로봇이 철 표면의 크기를 쉽게 조정할 수 있도록 하는 것입니다. 연강, 저합금강, 철과 같은 강자성 재료가 이러한 구조물을 구성하는 주요 재료이기 때문입니다. 마지막으로 로봇은 저렴해야 하며 비용이 $200 미만이어야 합니다. 저렴한 로봇은 교체가 쉽고 오래된 구조물을 검사할 때 로봇이 손상되는 것은 놀라운 일이 아닙니다. 저렴한 로봇은 또한 더 많은 로봇을 구매하여 작업에 사용할 수 있다는 것을 의미하므로 검사 효율성을 크게 높일 수 있습니다.
위에서 언급한 제약 조건을 충족하는 로봇을 설계하기 위해 저는 LEGO EV3 제어 모듈 및 기타 LEGO 부품으로 프로토타입을 만들기 시작했습니다. 저는 원래 LEGO로 제작하기 쉽고 로봇을 만드는 것이 상당히 쉽기 때문에 프로토타이핑을 위해 LEGO로 작업하기 시작했습니다. EV3 모듈은 LEGO 로봇을 제어하는 프로그래밍 가능한 로봇 코어이며 이미 집에서 사용할 수 있었습니다. LEGO 조각을 사용하여 4개의 모터와 바퀴가 부착된 튼튼한 로봇 본체를 만드는 것은 상당히 쉬웠습니다. EV3를 시작할 때 로봇을 위해 평평하고 컴팩트한 디자인을 만들려고 했습니다. LEGO 부품이 서로 맞물리는 방식 때문에 세 번째 rd 를 부착할 때가 되자 그 아이디어는 실패하기 시작했습니다. 그리고 4 모터. 내 모터를 제어 모듈에 맞출 수 없었습니다. 다음으로, 모듈이 나머지 로봇 위에 매달려 있고 모터는 메인 프레임에서 아치형으로 되어 있는 각진 디자인으로 이동했습니다. 컨트롤러 아래에 편안하게 맞는 메인 지지대를 설계한 후 모터 지지대를 설계할 수 있었습니다. 지지대는 메인 프레임에서 돌출되어 모터에 부착된 하향 경사 암이었습니다. 모터는 테스트 중 구조적 결함을 방지하기 위해 지지대 끝에 완전히 고정되었습니다. 모터와 지지대를 더욱 안정시키기 위해 각 모터를 가장 가까운 모터에 고정 커넥터로 연결했습니다. 또한 커넥터는 모터를 함께 연결하고 보조 프레임워크를 만드는 역할을 하기 때문에 한 모터가 다른 모터보다 훨씬 빠르게 진행되는 것을 방지했습니다.
LEGO 로봇의 구조적 설계와 시공을 마치고 바퀴 디자인으로 넘어갔습니다. 바퀴의 경우 4개의 표준 크기 EV3 바퀴로 시작했습니다. 각 바퀴의 반경은 17mm이고 너비는 17mm입니다. 각 바퀴에는 중공 고무 타이어가 부착되어 있습니다. 바퀴를 자기 운동으로 구성하기 위해 먼저 타이어를 제거했습니다. 타이어를 제거한 후에는 벗겨진 플라스틱 바퀴만 남았습니다. 플라스틱은 바퀴의 대부분을 일관되게 덮고 있는 아주 깊은 움푹 들어간 곳을 가지고 있었습니다. 움푹 들어간 곳 때문에 바퀴에 자석을 직접 부착할 수 없었습니다. LEGO 로봇에 사용한 자석은 K&J Magnetics 6 의 D51-N52 디스크였습니다. . D51-N52 자석은 직경이 5/16"(8mm)이고 두께가 1/16"인 네오디뮴-철-붕소(NdFeB) 디스크 자석입니다.
(1.6mm). 나는 그 자석을 사용하기로 결정했는데, 그 이유는 그들이 바퀴 주위에 사슬을 감고 자석 밴드를 만들 수 있을 만큼 충분히 작았기 때문입니다. 각 D51-N52는 강판에 직접 붙였을 때 2.05lb(9.1뉴턴)의 인장력을 갖습니다. 4개의 바퀴가 자석으로 감겨 있으면 그림 1과 같이 자기력이 LEGO 로봇을 지탱하기에 충분합니다.
나는 내 로봇의 바퀴에 자석을 부착하는 방법을 테스트했습니다. 나는 원래 바퀴 주위에 종이를 감싸고 그 종이에 자석을 붙이려고 했습니다. 그 아이디어는 종이가 자석을 위한 단단한 표면을 제공하기에 너무 약했고 그렇지 않았기 때문에 작동하지 않았습니다.
자석이 서로 뭉쳐서 바퀴를 떠나지 않도록 충분히 강력합니다. 다음으로 클레이나 플레이도우로 바퀴의 구멍을 메우고 그 위에 자석을 부착해 보았습니다. 이 아이디어는 두 재료 모두 슈퍼글루에 달라붙지 않기 때문에 실패했습니다. 두 아이디어 모두 효과가 없었을 때 나는 두 아이디어의 혼합이 효과가 있는지 실험했습니다. 바퀴의 움푹 들어간 곳을 접고 압축한 종이 조각으로 채웠습니다. 그런 다음 스트립을 제자리에 슈퍼글루로 붙였습니다.
그런 다음 바퀴를 얇은 금속 가닥으로 접고 강화한 종이를 감았습니다. 강화된 종이는 견고하면서도 유연하여 내가 자석을 붙일 수 있을 만큼 충분히 유연했습니다. 네 바퀴 모두 자석을 잘 붙인 뒤 타이어 대신 덕테이프로 바퀴를 감쌌다. 내가 타이어를 사용하지 않기로 선택한 이유는 타이어가 두께 때문에 자석의 당기는 힘을 너무 많이 감소시키는 반면 덕트 테이프는 견인력을 제공하면서 당기는 힘을 크게 줄이지 않기 때문입니다. 바퀴를 감싼 후 각 바퀴에 LEGO 액슬을 통과시켜 각 바퀴를 제 모터에 부착하는 데 사용했습니다.
바퀴의 부착은 나의 첫 번째 프로토타입 개발의 끝을 표시했습니다. 프로토타입을 강철 문에 눌러 테스트했습니다. 로봇은 미끄러지지 않고 문에 단단히 붙을 수 있었습니다. 로봇은 25x25x25cm보다 크고 가격이 200달러 이상이며 연결되어 있지 않고 배터리가 필요하고 카메라를 지원하지 않는다는 몇 가지 설계 제약 조건을 충족하지 못했습니다.
그러나 이 초기 프로토타입은 핵심 목표를 충족했습니다. 내 첫 번째 프로토타입의 진정한 목적은 자석을 사용하여 철 표면에 로봇을 효율적으로 부착하는 방법을 이해하고 검사 문제를 해결하기 위해 로봇과 바퀴를 설계하는 방법을 이해하도록 돕는 것이었습니다.
LEGO로 첫 번째 프로토타입 로봇을 만든 후 구성 요소를 선택하고 건설을 시작하기 전에 컴퓨터에서 다음 프로토타입을 설계 및 시각화하기로 결정했습니다. 먼저, 나는 미래 프로토타입의 핵심으로 Raspberry Pi를 사용하기로 결정했습니다. 내가 라즈베리 파이를 선택한 이유는 파이가 매우 가볍고 컴팩트함에도 불구하고 상당히 강력한 회로 기판이기 때문입니다. Pi는 USB 및 이더넷 기능을 유지하면서 모터 제어 보드에 연결할 수 있습니다. 또한 Pi는 매우 저렴한 컴퓨터이며 무료 OS 패키지와 함께 제공됩니다. 그림 2는 Raspberry Pi 3의 사진입니다.
다음으로 L298N 모터 제어 보드를 사용하여 모터를 제어하기로 결정했습니다. L298N은 2개의 DC 모터를 제어할 수 있는 상당히 간단한 모터 컨트롤러입니다. 모터 컨트롤러는 최대 35V의 전압을 처리할 수 있는 것으로 문서화되어 있습니다. 내가 사용하고 싶었던 대부분의 모터가 6V-12V 범위에 있었기 때문에 L298N이 저에게 이상적이었습니다. 보드 자체는 라즈베리 파이의 3분의 1에 불과한 아주 작습니다. 이러한 단순성 때문에 여러 L298N을 저렴한 비용으로 쉽게 구입할 수 있습니다. 또한 Raspberry Pi를 사용한 첫 번째 프로토타입을 위해 단일 카메라로 시작하기로 결정했습니다. 제가 선택한 카메라는 Raspberry Pi NoIR 카메라입니다.
이 NoIR 카메라는 야간 투시경용으로 설계된 Pi 호환 카메라입니다. 다리와 같은 구조물이 켜져 있을 수 있지만 탱크 내부는 아마도 어두울 것입니다. 그래서 표준 Pi 카메라 대신 Pi NoIR 카메라를 선택했습니다. 또한 Raspberry Pi용으로 제작되었으며 다른 어떤 카메라보다 사용하기 쉽기 때문에 NoIR 카메라를 선택했습니다.
내 모터의 경우 표준 6V DC 플라스틱 Arduino 모터를 선택했습니다. 내 드라이버 보드가 전압 제한 내에서 모든 DC 모터를 실행할 수 있다는 것을 알았기 때문에 Arduino 모터임에도 불구하고 이 모터를 선택했습니다. 필요한 모터 토크를 추정하기 위해 아래에 설명된 대로 엔지니어링 역학 계산을 수행했습니다. 플라스틱 모터는 사용 및 배선이 매우 쉽고 저렴합니다. 모터 중 하나가 고장나면 새 모터로 쉽게 교체할 수 있습니다. 모터에는 로봇을 지지하고 움직일 수 있을 만큼 충분히 크지만 쉽게 제어할 수 있을 만큼 작은 플라스틱 바퀴도 함께 제공됩니다. 두 개의 구동 모터 외에 다른 모터를 사용하여 로봇 아래에 지지할 수 있는 레버 메커니즘을 만들고 싶었습니다. 이 메커니즘은 로봇의 프런트 엔드를 지면에서 들어올려 철제 표면에 더 잘 부착되도록 하는 데 사용됩니다. 나는 단순한 플라스틱 로봇 섀시에 로봇을 장착하고 금속 스트립을 사용하여 섀시 자체에 수용할 수 없는 부품에 대해 높은 플랫폼을 형성할 계획이었습니다. 나는 4-AA 배터리 팩 또는 2개의 2-AA 배터리 팩으로 L298N에 전원을 공급하기로 결정했습니다. Raspberry Pi는 전기 콘센트로 확장된 USB 케이블에서 전원을 수신하도록 설계되었습니다. 로봇은 USB 케이블을 사용하여 연결된 유선 Xbox 360 컨트롤러에 의해 제어됩니다. 로봇의 움직임을 제어하는 데 이상적인 방향 패드가 있기 때문에 Xbox 컨트롤러를 사용하기로 결정했습니다. 또한 카메라 제어와 같은 로봇 코드 내 다른 작업에 할당할 수 있는 추가 버튼이 있습니다. 자석의 경우 D51-N52 자석을 계속 사용하기로 결정했습니다. 왜냐하면 바퀴 주위에 자석 띠를 만드는 데 자석을 사용하는 것이 첫 번째 프로토타입으로 자석 바퀴를 만드는 실행 가능한 방법이라는 것을 증명했기 때문입니다.
재료와 구성 요소를 결정한 후 두 번째 nd 프로토타입이 있는 경우 프로토타입의 CAD 도면을 구성하는 작업으로 넘어갔습니다. 그러면 지정한 부품이 도착하면 쉽게 구성할 수 있습니다. CAD 도면을 만들기 위해 SketchUp이라는 소프트웨어를 사용했습니다. 소프트웨어가 무료이고 스스로 배우기 쉽고 사용하기 쉽기 때문입니다. 두 번째 nd 를 만드는 데 사용할 계획인 부품의 온라인 및 물리적 측정(부품이 도착한 후) 사용 프로토타입 로봇을 사용하여 그림 3과 같이 로봇 프로토타입의 사실적인 3D CAD 도면을 구성할 수 있었습니다. 그런 다음 최적의 나사 위치를 고려하여 프로토타입을 더욱 세분화했습니다. 디자인 기능을 추가하고 세부 사항을 수정하는 몇 번의 반복 후에 로봇의 만족스러운 3D 모델을 얻을 수 있었습니다. 이것은 실제 부품을 사용하여 컴퓨터 모델의 물리적 복사본을 구성해야 했기 때문에 프로젝트의 하드웨어 부분을 단순화하는 데 도움이 되었습니다.
모든 부품이 도착하고 CAD 도면이 완성된 후 로봇을 만드는 것은 간단한 문제였습니다. 로봇을 구성할 때 먼저 라즈베리파이를 장착할 구멍을 뚫었습니다. 플라스틱 섀시에 드릴링할 지점을 표시하기 위해 섀시 후면 끝의 상단에 Pi를 누르고 가는 연필을 사용하여 섀시의 각 나사 구멍 아래 영역을 표시했습니다. 그런 다음 Pi의 나사 구멍보다 약간 큰 드릴 비트를 선택하여 각 구멍을 뚫었습니다. 그런 다음 드라이버 보드를 수용하기 위해 섀시 전면에 유사하게 구멍을 뚫었습니다. 드라이버 보드와 Raspberry Pi를 장착하기 위해 #4-40 볼트와 너트를 사용했습니다. 두 보드를 모두 장착한 후 제공된 나사를 사용하여 뒷바퀴를 고정하고
모터를 섀시의 미리 절단된 구멍에 연결합니다. 섀시, 모터, 뒷바퀴가 너트, 볼트, 설명서와 함께 제공되어 두 구성 요소를 섀시에 쉽게 부착할 수 있었습니다.
이 프로토타입의 경우 두 드라이브 모터 사이에 있는 로봇 밑면에 세 번째 모터를 부착하기 위해 튼튼한 양면 테이프를 사용했습니다. 그런 다음 아이스 캔디 스틱 4개를 가져와 세로로 2개 세트로 붙였습니다. 그 결과 아주 두꺼운 아이스 캔디 2개를 얻었습니다. 그런 다음 아이스 캔디 스틱을 반으로 자르고 각 하프 아이스 스틱 끝에 모터 축의 끝을 스케치했습니다. 그런 다음 드릴을 사용하여 모터 액슬을 수용할 새 스틱 각각에 구멍을 뚫었습니다. 그 결과, 나는 4개의 두껍고 절반 길이의 구멍이 뚫린 아이스 캔디 스틱을 얻었습니다. 그런 다음 가장 잘 맞는 두 개의 스틱을 선택하여 중간 모터의 액슬 양쪽 끝에 부착했습니다. 나는 뜨거운 접착제로 아이스 캔디 스틱을 고정했습니다. 이 전동 장치의 목적은 모터가 활성화되면 로봇을 표면에서 밀어내는 리프터 역할을 하는 것이었습니다. 이 장치는 로봇이 철 표면에서 스스로 분리될 수 있도록 설계되었습니다. 또한 로봇이 지면에서 메인 자기 바퀴를 들어올려 다른 표면에서 철벽에 부착할 수 있도록 합니다. 이것은 이 프로젝트의 몇 가지 독특한 디자인 기능 중 하나입니다. 마그네틱 휠 디자인은 또 다른 혁신적인 기능입니다.
세 번째 모터를 부착한 후 구멍이 뚫린 금속 행거 테이프를 사용하여 드라이버 보드와 Raspberry Pi 위에 브리지 같은 구조를 만들었습니다. 행거 테이프는 추가 부품을 장착할 수 있는 2차 표면 역할을 했습니다. 구멍이 뚫려 있어서 섀시에 구멍을 뚫어 메탈 행거 테이프를 끼우고 남은 볼트와 너트로 고정하는 것이 쉬웠다. 로봇 전면의 행거 테이프 브리지 위에 두 번째 드라이버 보드를 부착하여 세 번째 모터를 제어하기 위해 각 보드는 두 개의 모터만 제어할 수 있습니다. 저는 양면테이프를 이용하여 드라이버 보드를 부착할 수 있었습니다. 더 많은 양면 테이프를 사용하여 후면 금속 격납고 상단에 4-AA 배터리 홀더를 부착하여 메인 드라이버 보드에 전원을 공급할 수 있었습니다. 또한 두 번째 드라이버 보드에 전원을 공급하기 위해 두 개의 2-AA 배터리 홀더를 로봇 전면에 부착했습니다.
나는 Raspberry Pi NoIR 카메라를 금속 행거 테이프 브리지 전면에 핫 글루로 접착하여 이 두 번째 프로토타입을 완성했습니다. 로봇을 만들고 나면 바퀴를 자화하는 일만 남았습니다. 바퀴에서 타이어를 제거하고 각 바퀴에 양면 테이프를 붙였습니다. 플라스틱 바퀴와 모터는 그림 4에 나와 있습니다. 나는 각 바퀴에 두 개의 고리가 있도록 각 바퀴의 테두리 주위에 작은 원형 D51-N52 자석을 붙였습니다. 모든 자석을 추가한 후 자석을 보호하기 위해 한 겹의 덕트 테이프로 두 바퀴를 모두 덮었습니다. 뒷바퀴를 자화하기 위해 바퀴 주위의 링에 자석을 열간 접착 한 다음 덕트 테이프로 감았습니다. 덕트 테이프를 사용한 이유는 당기는 힘이 크게 줄어들지 않을 정도로 얇지만 자석을 보호할 수 있을 만큼 강하기 때문입니다.
로봇의 모든 구성 요소를 부착한 후 함께 배선하기 시작했습니다. 라즈베리파이의 전원은 측면에 있는 마이크로 USB 포트를 통해 들어왔습니다. 그런 다음 배터리 팩을 해당 드라이버 보드에 연결했습니다. 모터는 또한 모터와 함께 제공된 전선을 사용하여 드라이버 보드에 연결되었습니다. 나는 전선을 모터의 전원 리드에 납땜하고 나사로 드라이버 보드에 연결했습니다. 그런 다음 Pi의 GPIO 핀을 드라이버 보드에 연결했습니다. GPIO 핀은 Raspberry Pi의 범용 입력/출력 핀입니다. 일부 핀은 접지 및 전원에 사용되는 반면 일부는 와이어를 통해 신호를 보내는 데 사용할 수 있습니다. GPIO 2 &6을 하나의 드라이버 보드에 연결하고 4 &9를 다른 드라이버 보드에 연결했습니다. 이 핀은 5V 핀이었고 드라이버 보드를 통해 모터를 이동하고 제어하는 데 사용되었습니다. 그런 다음 핀 11, 12, 13 및 15를 첫 번째 드라이버 보드에 연결하고 핀 16 및 18을 다른 드라이버 보드에 연결했습니다. 이 핀은 실제 모터 제어 신호를 보내는 데 사용되었습니다. 각 모터
제어를 위해 2개의 핀이 필요했고 로봇이 3개의 모터를 사용했기 때문에 드라이버 보드는 보드당 5V 및 접지 외에 모터 제어를 위해 6개의 연결된 신호 GPIO 핀이 필요했습니다. 필요한 GPIO 핀을 연결한 후, 내 Pi와 노트북 사이에 이더넷 케이블을 연결하여 내 노트북이 내 Raspberry Pi와 원격 데스크톱 연결이 가능하도록 하여 모니터, 키보드 및 마우스가 필요하지 않았습니다. 또한 USB를 통해 전원 허브를 Pi에 연결했습니다. 허브가 Xbox 컨트롤러에 연결되어 Xbox 컨트롤러를 통해 로봇을 제어할 수 있었습니다.
두 번째 nd 를 디자인할 때 가장 어려운 점 프로토타입은 코드였습니다. 내 첫 번째 프로토타입은 하드웨어 모델에 불과했습니다. 코드가 실행되지 않았습니다. 제 이유는 제 1 st 프로토타입을 시도했지만 코드와 함께 4개의 모터를 모두 동시에 움직일 수 없었습니다. 첫 번째 프로토타입은 주로 자기 휠 개념을 테스트하고 미래 프로토타입을 위한 이상적인 디자인을 찾는 데 도움이 되도록 만들어졌습니다. Raspberry Pi에서는 Python으로 코딩했습니다. 내가 이해할 수 있는 유일한 Raspberry Pi 언어였기 때문입니다. 하지만 코드 작성을 시작하기 전에도 내 노트북과 호환되는 원격 데스크톱이 되도록 로봇을 설정해야 했습니다.
내 Pi를 설정하려면 모니터, 키보드 및 마우스를 Raspberry Pi에 임시로 연결해야 했습니다. 그 후 Pi를 부팅하고 이더넷을 통해 고정 IP를 설정했습니다. 저는 192.168.1.10을 선택했는데 주소가 간단하고 쉽기 때문입니다. IP를 설정하려면 수정해야 했습니다.
내 Pi의 /ect/dhcpcd.conf. dhpcd.conf 파일은 Pi의 IP 및 네트워크 연결을 제어합니다. 고정 IP를 설정하려면 파일 시작 부분에 줄을 추가해야 했습니다.
인터페이스 eth0
고정 ip_address=192.168.1.10 고정 라우터=192.168.1.1
Pi의 고정 IP를 설정한 후 Linux 패키지 tightvncserver를 설치했습니다. Tightvncserver는 VNC(가상 네트워크 연결) 서버를 Raspberry Pi에 설정할 수 있도록 하는 패키지입니다. 원격 데스크톱 연결은 VNC 서버를 통해 실행됩니다. VNC 서버를 설정한 후 내
를 통해 Raspberry Pi에 대한 원격 데스크톱 연결을 생성할 수 있었습니다.노트북. Pi에 액세스할 수 있음을 확인한 후 모니터, 키보드 및 마우스의 연결을 끊었습니다. 그런 다음 로봇 코딩을 시작했습니다.
먼저, 어떤 GPIO 핀이 내 Pi의 어떤 모터에 해당하는지 알아낼 방법이 필요했습니다. 각 GPIO 핀이 활성화되면 단일 모터를 일정한 속도로 앞이나 뒤로 회전합니다. 따라서 각 모터에는 2개의 해당 GPIO 핀, 순방향 모션 컨트롤러 및 역방향 모션 컨트롤러가 있습니다. 각 GPIO 핀이 무엇에 해당하는지 알아보기 위해 각 GPIO 핀을 개별적으로 테스트하는 프로그램을 작성하여 어떤 GPIO 핀이 어떤 작업을 수행했는지 기록할 수 있도록 했습니다. 내 프로그램에 대한 댓글을 통해 관찰한 내용을 기록했습니다.
RPi.GPIO 가져오기 잠자기 시간에서 GPIO로 가져오기
GPIO.setmode(GPIO.BOARD)
GPIO.setup(12,GPIO.OUT) #왼쪽 뒤로 GPIO.setup(11,GPIO.OUT) #왼쪽 앞으로 GPIO.setup(13,GPIO.OUT) #오른쪽 앞으로 GPIO.setup(15,GPIO.OUT) # 오른쪽 뒤로 GPIO.setup(16,GPIO.OUT) #리프터 아웃 GPIO.setup(18,GPIO.OUT) #리프터 인
GPIO.출력(12,GPIO.HIGH)
절전(2) GPIO.출력(12,GPIO.LOW)
수면(1)
GPIO.출력(11,GPIO.HIGH)
절전(2) GPIO.출력(11,GPIO.LOW)
수면(1)
GPIO.출력(13,GPIO.HIGH)
절전(2) GPIO.출력(13,GPIO.LOW)
수면(1)
GPIO.출력(15,GPIO.HIGH)
절전(2) GPIO.출력(15,GPIO.LOW)
수면(1)
GPIO.출력(16,GPIO.HIGH)
절전(0.5) GPIO.출력(16,GPIO.LOW)
수면(1)
GPIO.출력(18,GPIO.HIGH)
절전(0.5) GPIO.출력(18,GPIO.LOW)
수면(1)
다음으로 내 Raspberry Pi가 Xbox 컨트롤러에서 보낸 신호를 수신하고 이해할 수 있도록 하는 소프트웨어나 코드가 필요했습니다. Xboxdrv는 Linux용 Xbox 컨트롤러 드라이버입니다. 나는 그것을 설치하고 내 Pi를 내 Xbox 컨트롤러에 연결하는 데 사용했습니다. 일반적으로 프롬프트에서 'sudo xboxdrv' 명령을 실행하면 연결된 Xbox 컨트롤러의 입력이 명령 프롬프트 창에 표시됩니다. 그러나 내 Xbox 컨트롤러는 Microsoft에서 만든 것이 아니므로 xboxdrv에서 정상적으로 지원되지 않습니다. 다음 명령을 실행하여 문제를 해결했습니다.
sudo xboxdrv – device-by-id 1bad:f02e –type xbox360 –detach-kernel-driver –mimic-xpad
xboxdrv 사용법과 정상적인 기능을 코드로 수정하는 방법을 연구한 끝에 이 명령어를 만들 수 있었습니다. 이 명령을 사용하여 연결된 컨트롤러를 1bad:f02e인 장치 ID를 사용하여 Xbox 컨트롤러로 식별했습니다. 이 명령을 사용하면 명령 프롬프트에서 컨트롤러의 입력을 볼 수 있습니다.
에서 입력 값에 액세스하는 방법이 필요했습니다.Python program, so that I would be able to use the values to control my robot. After some searching online, I found a Python program that received and displayed Xbox controller input values on Github 7 . The code was by martinohanlon. I downloaded the code onto my Raspberry Pi and started working on modifying it to control the motors on the robot based on the values it received. The problem I faced was that the code was so long and complex, that I was unable to tell where the input value from the Xbox controller was read. To solve that problem, I went through the program and I made a series of print statements that printed the variables of the program as it ran. Through the process of observing the values as buttons were pressed, and deleting print statements, I was able to find the main event system in the program at line 265:
#run until the controller is stopped while(self.running):
#react to the pygame events that come from the xbox controller for event in pygame.event.get():
#thumb sticks, trigger buttons
if event.type ==JOYAXISMOTION:#is this axis on our xbox controller
if event.axis in self.AXISCONTROLMAP:#is this a y axis
yAxis =True if (event.axis ==self.PyGameAxis.LTHUMBY or event.axis ==self.PyGameAxis.RTHUMBY) else False
#update the control value self.updateControlValue(self.AXISCONTROLMAP[event.axis],
self._sortOutAxisValue(event.value, yAxis)) #is this axis a trigger
if event.axis in self.TRIGGERCONTROLMAP:#update the control value
self.updateControlValue(self.TRIGGERCONTROLMAP[event.axis], self._sortOutTriggerValue(event.value))
#d pad
elif event.type ==JOYHATMOTION:#update control value
self.updateControlValue(self.XboxControls.DPAD, event.value)
#button pressed and unpressed
elif event.type ==JOYBUTTONUP or event.type ==JOYBUTTONDOWN:#is this button on our xbox controller
if event.button in self.BUTTONCONTROLMAP:#update control value
self.updateControlValue(self.BUTTONCONTROLMAP[event.button], self._sortOutButtonValue(event.type))
Within the main event system, I searched for the component that handled the directional pad (d- pad) on the Xbox controller, as I was planning on using it to control the motors on the robot.
After finding the directional pad control component, I added some statements to the end that sent signals through the GPIO pins to the motors whenever a certain direction was pressed on the D- Pad:
#d pad
elif event.type ==JOYHATMOTION:#update control value
self.updateControlValue(self.XboxControls.DPAD, event.value) if event.value ==(0,1):#Forward
GPIO.output(11,GPIO.HIGH) #Left Forward GPIO.output(13,GPIO.HIGH) #Right Forward
elif event.value ==(0,-1):#Backward GPIO.output(12,GPIO.HIGH) #Left Backward GPIO.output(15,GPIO.HIGH) #Right Backward
elif event.value ==(1,0):#Right GPIO.output(11,GPIO.HIGH) #Left Forward
GPIO.output(15,GPIO.HIGH) #Right Backward elif event.value ==(0,1):#Left
GPIO.output(12,GPIO.HIGH) #Left Backward GPIO.output(13,GPIO.HIGH) #Right Forward
GPIO.output(12,GPIO.LOW) GPIO.output(11,GPIO.LOW) GPIO.output(13,GPIO.LOW) GPIO.output(15,GPIO.LOW)
After successfully configuring the motors, my next challenge was to code the Raspberry NoIR camera. The Pi camera came with a Python camera package. Coding it so that pictures were taken or videos were recorded every time certain buttons on the Xbox controller were pressed was fairly easy.
#button pressed and unpressed
elif event.type ==JOYBUTTONUP or event.type ==JOYBUTTONDOWN:#is this button on our xbox controller
if event.button in self.BUTTONCONTROLMAP:#update control value
self.updateControlValue(self.BUTTONCONTROLMAP[event.button], self._sortOutButtonValue(event.type))
if event.button ==0 and event.type ==10:camera.capture(‘image’ + imgNum + ‘.jpg’) imgNum =imgNum + 1
if event.button ==1 and event.type ==10:if isRec ==False:
camera.start_recording(‘video’ + recNum + ‘.h264’) isRec =True
else:
camera.stop_recording() isRec =False
if event.button ==1 and event.type ==10:if isPrev ==False:
camera.start_preview() isPrev ==True
else:
camera.stop_preview() isPrev ==False
For this portion of the code, I did have to make variables to serve as counters every time a picture or video was taken, so that they would be numbered. I also had to make Boolean variables that determined whether a video was being taken, to prevent the robot from trying to take another video while one was already recording. After coding the camera, I was finished with programming the robot.
The first thing I recorded was the mass of the robot. Using a standard kitchen scale, I recorded the mass of the robot to be 0.66 kg. While not being especially light, prototype 2a was significantly lighter than prototype 1, which had a mass of 0.92 kg without cameras. Prototype 2a was also measured to be 15 cm long x 18 cm wide x 12 cm tall. Prototype 2a could meet the size constraint, which was another improvement over prototype 1. Prototype 2a could stick to ferrous surfaces. While the motor of prototype 1 could not overcome the magnetic pull force and move the robot, prototype 2 could move the robot downward or sideways but not upward when attached to a vertical steel wall. The 3 rd motor on the robot that was planned for lifting of off surfaces was also unable to function because of a lack of torque. Prototype 2a had only mounted 1 camera, and thus failed the multiple camera requirement. However, prototype 2a was an improvement over prototype 1. Prototype 2a only cost about $120 to build compared to prototype 1, which cost more than $400 even without cameras.
I calculated force and torque using equations from the literature as shown below.
Figure 5 shows a sketch of the robot climbing an inclined plane and the forces present.
| For a robot at rest in the plane: | m*(N1 + N2) =Mgsinq | (1) |
| Perpendicular to the plane: | N1 + N2 =F(M1) + F(M2) + Mgcosq | (2) |
| For a vertical wall q =p/2. | N1 + N2 =F(M1) + F(M2); m*(N1 + N2) ≥ Mg | (3) |
| The required magnetic force is | F(M1) + F(M2) ≥ Mg/m | (4) |
With two motors, the torque needed from each is t ≥ MgR/2 (5)
The paper by Wang and Kimura (IEEE 2014) shows that the friction coefficient for tape covered wheel on metal m =0.45. The mass of my robot prototype 2a is M =0.655 kg. The acceleration of gravity g =9.81 m/s 2 . From equation (4), the required magnetic force =14.5 Newton. The pull force of the N52 magnet away from a steel surface has been tested and reported by the manufacturer KJ Magnetics. It is shown for different distances in Figure 6. The thickness of the duct tape I used is 0.01”. At a distance of 0.01”, the pull force is 1.26 lb per magnet according to the data plotted in Figure 6. In SI units, this pull force per magnet =5.6 Newton. To get a magnetic force of at least 14.5 Newtons calculated from equation (4), we need at least 3 magnets in contact at all times (one per wheel). The m value of 0.45 is only an estimate. If it is lower (say 0.25), the required magnetic force is higher, about 26.1 Newton.
Thus, for safety, we need 2 rows of magnets per wheel.
Torque is important, because it is the rotational force (force multiplied by radial distance) that the motor must generate to move the robot. From equation (6), we know that the torque must be greater than MgR/2 for each of the front wheel motors. For prototype 2a, this works to torque being more than 0.08 Newton meter per motor. The plastic encased motors I used in the prototype 2a (Figure 4) were rated by the manufacturer as 0.1 Newton meter each. In my tests, prototype #2a could stay attached to a vertical surface and climb down. However, it struggled to climb up the vertical wall. The torque was barely enough to fight gravity. The results of this test of prototype #2a show that the force and torque calculations were correct. The lesson I learned from building and testing prototype 2a is that the robot should be lighter or a motor with greater torque should be used. The use of CAD and mechanics calculations made the design and development process systematic and logical. Figure 7 shows the underside of prototype 2a. The three motors and the popsicle sticks can be clearly seen.
After developing and testing Prototype 2a, I realized that there were multiple changes I could make to it to make it fit the constraints better, without constructing an entirely new bot. So instead of starting from scratch, I decided to make a series of modifications and upgrades to Prototype 2a, resulting in the creation of Prototype 2b.
The first change I made to prototype 2a was that I removed all the motors. The motors did not work as expected for climbing up a vertical wall because of lack of torque; so, all of them had to be replaced or removed. I replaced the drive motors with two new larger motors, and I simply removed the third motor without replacement. The new motors were Uxcell 12V high torque gearbox motors. They were chosen, because their torque rating was much higher than that of the motors they replaced, but these new motors were heavier. I fastened both motors to the underside of the robot, where the previous motors had been using strips of double sided tape for preliminary testing. The new motors had a mass almost 100 g more than that of the old motors and so adding both new motors added almost 200 g to the mass of the robot.
I removed the driver board that controlled the third motor, because there was no longer a third motor on the robot, so there was only a need for a single driver board. Next, I removed all of the battery packs on the robot. Battery packs add unnecessary mass to a robot, and only limit its inspection life. Additionally, using batteries increases chances of motor failure when the robot is in deployment, because batteries might run out of battery power in the middle of a run, resulting in the need for an emergency retrieval. I then moved the remaining driver board onto the metal hanger above the Raspberry Pi, where the 4-AA battery pack had been previously. This allowed me to remove the metal hanger at the front of the robot because it was not being used. I also removed two posts with magnetic disks at the rear of the robot that were included in Prototype 2a to increase the stability of the rear. I found out through testing that the posts were not needed.
At this stage, I encountered a major problem. My wheels were no longer compatible with my motors because the new motors had a different shaft compared to the old motors. I tried drilling and cutting the wheel wells to make the wheels fit the motors, but neither solution worked. After some research on what items fit a D shaped motor shaft, I found out that oven knobs often fit D shafts. After buying some oven knobs, I tested them to see if they attach to the motors. After finding out the oven knobs were compatible with the new motors, I sawed the top off the oven knobs, resulting in flat disks that fit onto the new motors. I then drilled out the wheel well on the wheels, after which I superglued the disks to the wheels. By supergluing the disks to the wheels, I made it so that they would be able to attach to the motor. After attaching the wheels and motors, I set up the cameras. I hot glued the Pi NoIR camera to the back of the robot and made it face backwards for my rear-view camera. I then took a wide-angle, fish-eye camera, and hot glued it to the front of my robot facing forwards for my main camera. I then double sided taped and hot glued an endoscopic inspection camera to the front rim of the chassis facing downwards. The use of oven knobs to connect wheels to the new motor shaft is an innovative solution developed in this project.
After modifying prototype 2a, there were many components to re-wire. I had to re-solder a wire to the power leads of the motors and connect it to the remaining driver board. I then removed all of the wires connected to GPIO 4, 9, 16, or 18, as they were no longer in use. I also decided to use a 12 V power cable to power the driver board instead of a battery pack. To do so, I cut the output end of the power cable off, so that all that remained was the adapter and a length of wire. I then separated the two strands of power wire, one being positive and the other being negative, and stripped the wires so that both wires were exposed at the end. After twisting and tightening the exposed wire, I connected the positive wire to the ground slot on the driver board, and the negative wire into the voltage slot on the driver board. I left the NoIR camera connected to the Pi, but I connected both the other cameras to my laptop so that my laptop directly received feeds directly from the cameras instead of getting them through the Pi, with the exception of the NoIR camera. To finish, I swapped the Xbox Controller with a Super Nintendo Entertainment System (SNES ) controller. An SNES controller is a much lighter and simpler controller than an Xbox controller and unlike the Xbox controller which requires a powered hub for power, an SNES controller can be powered by the Raspberry Pi. The two controllers are shown side by side for comparison in Figure 8.
Since the Raspberry Pi had already been completely set up with the previous prototype, I was able to dive straight into programming. While no new code was needed to test the motors, since the previous motor test program worked, a new controller code became necessary because I changed the controller and was no longer using an Xbox controller. Because of the simpler nature of the SNES controller, there was no driver similar to xboxdrv for the SNES controller.
The Pi is capable of interpreting the input from the SNES controller by default. After doing some research and looking into how to interact with an SNES controller through Python, I wrote the following controller program from scratch:
import pygame
import RPi.GPIO as GPIO GPIO.setmode(GPIO.BOARD)
GPIO.setup(12,GPIO.OUT) #Left Backward GPIO.setup(11,GPIO.OUT) #Left Forward GPIO.setup(13,GPIO.OUT) #Right Forward GPIO.setup(15,GPIO.OUT) #Right Backward
global hadEvent global x
global y global a global b global up global down global left global right
hadEvent =False x =False
y =False a =False b =False up =False
down =False left =False right =False
pygame.init()
pygame.joystick.init()
j =pygame.joystick.Joystick(0) j.init()
def game_controller(events):global hadEvent
global x global y global a global b global up global down global left global right
for event in events:
if event.type ==pygame.JOYBUTTONDOWN:hadEvent =True
x =j.get_button(0) y =j.get_button(3) a =j.get_button(1) b =j.get_button(2)
if x ==1:x =True
print(“x”) elif y ==1:
y =True print(“y”)
elif a ==1:
a =True print(“a”)
elif b ==1:b =True print(“b”)
elif up ==1:up =True print(“up”)
elif event.type ==pygame.JOYBUTTONUP:hadEvent =False
x =j.get_button(0) y =j.get_button(3) a =j.get_button(1) b =j.get_button(2)
if x ==1:
x =False elif y ==1:y =False elif a ==1:a =False elif b ==1:b =False
elif up ==1:up =False
elif event.type ==pygame.JOYAXISMOTION:hadEvent =True
if event.axis ==1:
if event.value <=-1:
up =True print(“up”)
elif event.value>=1:down =True print(“down”)
else:
down =False up =False
elif event.axis ==0:
if event.value <=-1:left =True print(“left”)
elif event.value>=1:right =True print(“right”)
else:
right =False left =False
while True:game_controller(pygame.event.get())
if up ==True:#Forward GPIO.output(11,GPIO.HIGH) #Left Forward GPIO.output(13,GPIO.HIGH) #Right Forward
elif down ==True:#Backward GPIO.output(12,GPIO.HIGH) #Left Backward GPIO.output(15,GPIO.HIGH) #Right Backward
elif right ==True:#Right GPIO.output(11,GPIO.HIGH) #Left Forward GPIO.output(15,GPIO.HIGH) #Right Backward
elif left ==True:#Left GPIO.output(12,GPIO.HIGH) #Left Backward GPIO.output(13,GPIO.HIGH) #Right Forward
else:
GPIO.output(12,GPIO.LOW) GPIO.output(11,GPIO.LOW) GPIO.output(13,GPIO.LOW) GPIO.output(15,GPIO.LOW)
This code operates by importing Pygame, which is a Python package. Pygame is used for constructing videogames through Python. It adds several features, such as interpreting and translating input values from a video game controller. Because of the simplicity of an SNES controller, there were no extra steps needed. Towards the beginning of the program, I defined the GPIO pins to be used for motor control. I then listed variables I planned to use, and assigned the connected controller to pygame.joystick() and then j. I then created an event system where a value sent by the controller is defined as an event, for example, pressing a button or moving a joystick. I then specified the events I care about, such as movement on the directional pad (d- pad) or a button being pressed. I assigned a value of 1 to a variable if the event it is connected to occured. I also wrote additional code to convert the numeric value 1 to the Boolean True. At the end, there is an infinite loop that fetches the values of events that were triggered. If any of the d- pad values are triggered, the program sends signals to the motors through the GPIO pins. After running this code, the robot responded smoothly to the SNES controller. I did not need any other code for controlling this prototype.
Once again, I started by recording the mass of the robot. Using a standard kitchen scale, I recorded the mass of the robot to be 0.71 kg. Prototype 2b ended up being heavier than prototype 2a, despite the removal of the battery packs, but this can be attributed to the motors which were heavier in prototype 2b. Prototype 2b was measured to be 15 cm long x 18 cm wide x 12 cm tall. Prototype 2a and 2b are the same size despite the changes between the two, the overall structure of the robot did not change. Prototype 2b was once again able to meet the size constraint. Prototype 2b had the ability to attach to ferrous surfaces and was the first prototype that could climb up on vertical ferrous surfaces. Figure 9 shows Prototype 2b climbing a vertical steel door. Prototype 2b mounted 3 cameras, and all of them sent back acceptable feeds, which was a large improvement over prototype 2a. Prototype 2b cost $170 to build compared to the $120 of prototype 2a. This increase can be attributed to the cost of cameras and the cost of better motors.
After building the last two prototypes, I wanted to apply the knowledge I had gained to create a new prototype that was smaller, more compact, and more efficient. To do this, I planned to design my own chassis, and refrain from using tapes and superglue to hold parts together.
To start building my robot, I took a polycarbonate sheet and cut my chassis out of it. For my chassis, I chose a simple 6 cm wide x 11 cm long rectangle. I chose that size and shape because it was simple and based off of preliminary measurements I took, it was the smallest feasible size for mounting the parts I had chosen. After cutting out the chassis with a saw, I smoothed out the edges and corners with a file and sandpaper. I then set the Raspberry Pi on the rear end of the chassis and marked where all of the holes were, so that I would be able to drill them out. I then set the rear wheel on the underside of the chassis and marked holes for it. I also marked holes for the motors I chose at the front of the chassis. The motors I chose were Pololu 12 V gearbox motors with a gear ratio of 298:1. The motors also came with mounting brackets that attached to the motors and had holes for screws. I finally marked a large hole between the Pi and the motors for the inspection camera.
After drilling all of the holes, I screwed down all of the parts except for the Pi. Before I screwed down the Pi, I laid down a thin sheet (4 mm thick) of packing foam underneath where the Pi would be to absorb shock and prevent contact between the metal on the Pi and the bolts and nuts on the robot. I also attached a folded metal hanger tape with the same bolts as the Pi. The hanger tape formed a bridge over the Pi. I cut a smaller 4.5 cm wide x 5.5 cm long piece of polycarbonate to screw to the top of the metal hangar. I screwed a driver board to the top of the smaller polycarbonate. For the wide-angle camera, I folded and cut thin scrap metal to form a pouch for the camera with a hole for the lens. The pouch had sides that folded in and held the camera. The pouch also had a flat bottom that extended out to either side. I screwed the metal pouch down with two of the screws that also held the motors. I slid the inspection camera down into the hole that had been drilled for it. The Pi NoIR camera was held by a retaining block that was hot glued to the top of the Ethernet port on the Pi. For the wheels, I used 60 mm diameter x
8 mm thick Pololu plastic wheels. To magnetize the wheel, I covered it in a thin layer of double sided tape and put the magnets in a ring around it. I the covered the magnets with a single layer of duct-tape for protection and traction. After finishing the wheels, I attached a 3V LED light on either side of the wide-angle camera holder. I also used double sided tape to attach an ultrasonic sensor to the bottom of the robot.
The robot utilizes an HC-SR04 ultrasonic distance sensor. The HC-SR04 is a very common and popular hobby ultrasonic distance sensor. The sensor is also the least expensive and easiest to use of its type to demonstrate sensor integration. The HC-SR04 is designed mainly with compatibility and simplicity in mind, allowing it to be easily connected to a Raspberry Pi or Arduino.
The HC-SR04 functions by sending a sound wave, which bounces off the object at which the sensor points, and then receiving the sound wave. The time between the sending and the reception of the sound wave is recorded and output. The time can then be multiplied by the speed of sound and divided by 2 to identify the distance between the sensor and the surface it is pointed towards. The HC-SR04 has 4 pins for connection purposes. The pins are ground, voltage, trigger, and echo. The ground pin is to be connected to ground. The voltage pin is to be connected to a+5V source. The trigger pin will cause the sensor to produce a sound wave for as long as it is receiving +3V. The echo pin sends back +5V in a burst as long as the wait time for the sensor to receive the signal. The sensor has a range of 2 cm to 400 cm. On my robot, the HC-SR04 serves to demonstrate that an ultrasonic sensor can be mounted underneath the robot. A more expensive, advanced ultrasonic sensor can be mounted to measure the thickness of the metal surface and identify degradation.
For the wiring of prototype 3, many elements stayed the same from prototype 2b but one changed. Because the Pololu wheels blocked the micro USB port on the Pi, I was unable to use it for power. After some research, I found that I could use the GPIO pins instead. I cut a USB to micro USB cable so that one portion was the USB end and a length of cable. Within the cable were two separate wires. I split and stripped those wired. I then soldered the exposed parts of the wires to the female end of a breadboard jumper. I covered my work with heat shrink tubing. I used a multimeter to tell which end was positive voltage and which end was negative. I connected the positive wire to GPIO 9, and the negative end to GPIO 14. Those two GPIO’s were 5 V &ground respectively. After connecting the USB end of the charging cable to a 5 V adapter, the Pi ran perfectly. Once again, wires were soldered to the leads of my motors, and connected back to my driver board. The driver board was connected to GPIO 11, 12, 13, &15 for control and GPIO 2 &6 for 5V and ground. The driver board was also connected to a 12 V power supply. The LED lights were wired and soldered in parallel. They were attached a 330Ω resistor, GPIO 16 &18 for power, and GPIO 9 for ground. The ultrasonic sensor which was added to this prototype was wired to GPIO 4, 29, 30, and 31. Pin 4 was used for voltage, 29 was for output, 31 was for input, and 30 was for ground. The NoIR camera was once again connected to the Pi, while the other cameras are connected to my laptop. The robot is still controlled by a USB SNES controller. The wiring diagram is shown in Figure 10.
To save myself the work of setting up and configuring the Pi, I moved the SD card from prototype 2b to prototype 3. Because the only new need of code for prototype 3 was for the ultrasonic sensor, I mainly just simplified and commented my SNES code, only adding a few extra lines, as shown below.
#Developed By Nikhil Devanathan 2017
#Program to control Raspberry Pi robot with wired USB SNES controller #Uses directional pad (d-pad) for motor movement
#Leaves button and triggers open for mapping
#Imports necessary packages into python
import pygame #Package that is used for game controller mapping import RPi.GPIO as GPIO #Allows control over binary pins on Pi from gpiozero import DistanceSensor
#Sets GPIO pins for motor control GPIO.setmode(GPIO.BCM)
GPIO.setup(18,GPIO.OUT) #Left Backward GPIO.setup(17,GPIO.OUT) #Left Forward GPIO.setup(27,GPIO.OUT) #Right Forward GPIO.setup(22,GPIO.OUT) #Right Backward GPIO.setup(23,GPIO.OUT) #Light1\
GPIO.setup(24,GPIO.OUT) #Light2/ Work together to power LED lights
#Conifgures ultrasonic sensor
ultrasonic =DistanceSensor(echo =6, trigger =5, threshold_distance =0.02)
#Creates variables for controller mapping
global hadEvent global x
global y global a global b global up global down global left global right
#Assigns Variables for controller mapping hadEvent =False
x =False y =False a =False b =False up =False
down =False left =False right =False
#Initializing pygame and controller pygame.init() pygame.joystick.init()
j =pygame.joystick.Joystick(0) j.init()
#Defining controller event system def game_controller(events):
#Defining variables for use in controller event system
global hadEvent global x
global y global a global b global up global down global left global right
#Searches for an event in the system for event in events:
#If a button is pressed
if event.type ==pygame.JOYBUTTONDOWN:#Set map values
hadEvent =True
x =j.get_button(0) y =j.get_button(3) a =j.get_button(1) b =j.get_button(2)
#If a button is released
elif event.type ==pygame.JOYBUTTONUP:#Set map values
hadEvent =False x =j.get_button(0) y =j.get_button(3) a =j.get_button(1) b =j.get_button(2)
#If there is axial montion on the directional pad
elif event.type ==pygame.JOYAXISMOTION:
#Set values for y axis hadEvent =True
if event.axis ==1:
if event.value <=-1:up =True
elif event.value>=1:down =True
else:
down =False up =False
#Set values for x axis elif event.axis ==0:
if event.value <=-1:left =True
elif event.value>=1:right =True
else:
right =False left =False
lightOn =False #Value to use with b button light control
#Infinite Loop while True:
#Get an event from the event system game_controller(pygame.event.get())
#Motor controls beased on directional pad values if up:#Forward
GPIO.output(17,GPIO.HIGH) #Left Forward GPIO.output(27,GPIO.HIGH) #Right Forward
elif down:#Backward GPIO.output(18,GPIO.HIGH) #Left Backward GPIO.output(22,GPIO.HIGH) #Right Backward
elif right:#Right
GPIO.output(17,GPIO.HIGH) #Left Forward GPIO.output(22,GPIO.HIGH) #Right Backward
elif left:#Left
GPIO.output(18,GPIO.HIGH) #Left Backward GPIO.output(27,GPIO.HIGH) #Right Forward
else:
GPIO.output(18,GPIO.LOW) #Reset GPIO.output(17,GPIO.LOW) GPIO.output(27,GPIO.LOW) GPIO.output(22,GPIO.LOW)
if a:#If a is pressed, for holding light on GPIO.output(23,GPIO.HIGH) #Light1 GPIO.output(24,GPIO.HIGH) #Light2
else:#If a is released, for turning light off GPIO.output(23,GPIO.LOW) #Light1 GPIO.output(24,GPIO.LOW) #Light2
if b:#If b is pressed, for holding solid light if lightOn:#If the light is on
GPIO.output(23,GPIO.LOW) #Light1 GPIO.output(24,GPIO.LOW) #Light2 lightOn =False #Declare that the light is off
else:#If the light is off GPIO.output(23,GPIO.HIGH) #Light1
GPIO.output(24,GPIO.HIGH) #Light2 lightOn =True #Declare that the light is on
if y:#If Y button is pressed
#Scan distance to ground with ultrasonic sensor u =ultrasonic.distance
print u
The only changes made to this program were the addition of comments throughout the program, and the deletion of unnecessary code segments.
Using a standard kitchen scale, I recorded the mass of the robot to be 0.26 kg. The mass of prototype 3 was significantly reduced compared to every other model. Prototype 3 was measured to be 14 cm long x 9 cm wide x 12 cm tall. Prototype 3 was the smallest of the prototypes and was more than a factor of two smaller than prototypes 2a &2b. Prototype 3 had the ability to attach to ferrous surfaces and was able to move on ferrous surfaces of speeds of
0.18 meters/second, making it the fastest prototype. Prototype 3 mounted 3 cameras, and all of them sent back acceptable feeds. Prototype 3 cost $175 to build compared to the $120 of prototype 2a and the $175 of prototype 2b. This can be attributed to the cost of cameras and the cost of smaller motors. Sample images from the three cameras are shown in Figure 11 and the results of robot testing are shown in Tables 1 and 2. The final prototype can be seen in Figure 12.
Source:Design and Development of a Low-Cost Inspection Robot
제조공정
KUKA는 독일에 기반을 둔 로봇 회사로 세계 최고의 산업용 로봇 생산업체 중 하나입니다. 그들은 원래 1973년에 세계 최초의 6축 로봇을 만들었고 오늘날 그들의 로봇은 자동차, 금속 가공 및 식품을 포함한 여러 산업에서 사용되고 있습니다. 본사는 독일 아우크스부르크에 있지만 미시간주 쉘비 타운십에도 북미 본사가 있습니다. 선두 제조업체인 KUKA는 제품 라인을 최신 상태로 유지함으로써 최고의 위치를 유지합니다. 가장 최근에 추가된 것 중 하나는 금속 절단 및 프로토타이핑 응용 분야를 위한 로봇 밀링 기술입니다. 로봇 밀링은
인간이 공장 설정에서 작업할 때 일반적으로 작업을 수행하는 데 필요한 모든 도구가 있는 작업 공간이 설정되어 있습니다. 산업 환경의 로봇 작업 공간도 마찬가지입니다. 로봇의 작업 공간에 대해 생각하는 방법은 다양하지만 기본적으로 로봇이 작동하는 공간으로 정의됩니다. 이것은 생산 라인 또는 작업셀에 있을 수 있습니다. 작동 위치는 중요하지 않습니다. 모든 산업용 다관절 로봇에는 정의된 작업 공간, 즉 한 영역을 이동할 수 있는 공간이 있습니다. 물론 로봇 작업 공간은 인간 작업 공간보다 훨씬 더 커질 것입니다. 이 금속 정확도의