자동차 조향장치 작동원리 - How Car Steering Works (1/2)

목적: pinion steering 의 의미를 알기 위하여 검색하였고, pinion steering 이 사용되는 Steering 전반에 대하여 정리해 두려고 합니다.

Car Steering 은 조향(자동차 방향을 조정하는 것) 을 이야기 하는 것으로 steering wheel(핸들) 을 움직임으로서 바퀴의 방향을 조정하는 것을 말합니다.


How Car Steering Works
자동차의 방향조절 원리는 무엇인가?

You know that when you turn the steering wheel in your car, the wheels turn. Cause and effect, right? But a lot of interesting stuff goes on between the steering wheel and the tires to make this happen.
당신도 이미 알겠지만 차의 핸들(steering wheel)을 돌리면, 바퀴(wheel)이 돈다. 원인이 있으니 결과가 있는 것이다. 하지만 핸들과 타이어 사이에 많은 일들이벌어진다.

In this article, we'll see how the two most common types of c­ar steering systems work: rack-and-pinion and recirculating-ball steering. Then we'll examine power steering and find out about some interesting future developments in steering systems, driven mostly by the need to increase the fuel efficiency of cars. But first, let's see what you have to do turn a car. It's not quite as simple as you might think!
이 글 에서는, 대표적인 자동차 조향장치(steering system)의 동작원리를 알아보려고 한다: '랙과 피니언(rack and pinion)' 과  '볼 순환식(recurculating-ball)' 이다. 이 둘을 알아본 다음에는 파워 스티어링(power steering)과 그 외에 개발되고 있는 장치들을 이야기할 것이다. 이 장치들의 개발은 연료의 효율성에 초점을 맞춰서 발전되고 있다. 하지만 그 전에, 어떻게 차를 돌리는지에 대하여 이야기 해 보자. 생각보다 쉽지 않을 것이다.

You might be surprised to learn that when you turn your car, your front wheels are not pointing in the same direction.
당신이 차를 회전시킬 때, 차의 앞 두 바퀴가 동일한 방향을 가리키지 않는다는것을 알면 놀랄 것이다.

For a car to turn smoothly, each wheel must follow a different circle. Since the inside wheel is following a circle with a smaller radius, it is actually making a tighter turn than the outside wheel. If you draw a line perpendicular to each wheel, the lines will intersect at the center point of the turn. The geometry of the steering linkage makes the inside wheel turn more than the outside wheel.
차가 부드럽게 회전하기 위해서는, 두 바퀴는 서로다른 원을 그려야 한다. 안쪽에 있는 바퀴가 작은 각도로 돌리 때문에, 바깥쪽 바퀴보다 작은 반경의 회전을 하게 된다. 만약에 각 바퀴의 움직임에 대한 선에 직각 선을 그린다면 회전 시에 중심지점에서 만나는 것을 알 수 있을 것이다. 기하학적으로 회전을 연결시키기 위해서 안쪽 바퀴가 바깥쪽 바퀴보다 더 많은 회전을 하게 된다.


1. Rack-and-pinion Steering

Rack-and-pinion steering is quickly becoming the most common type of steering on cars, small trucks and SUVs. It is actually a pretty simple mechanism. A rack-and-pinion gearset is enclosed in a metal tube, with each end of the rack protruding from the tube. A rod, called a tie rod, connects to each end of the rack.
랙앤피니언 은 가장 일반적인 타입의 조향장치이다. 승용차, 작은트럭, SUV에 주로 쓰인다. 동작원리는 비교적 간단하다. rack 과 pinion은 메탈 튜브로 둘로싸인 기어의 조합을 의미한다. rack의 양 끝은 튜브보다 튀어나와 있으며, tie rod 는 두 바퀴를 함께 동작하게 하기 위해 rack의 양 끝을 연결하는 역할을 한다.

The pinion gear is attached to the steering shaft. When you turn the steering wheel, the gear spins, moving the rack. The tie rod at each end of the rack connects to the steering arm on the spindle (see diagram above).
pinion gear는 steering shaft에 붙어 있다. 핸들을 돌리면, pinion gear는 회전하면서 rack을 회전시킨다. rack의 양 끝에 있는 tie rod는 spindle 위의 steering arm에 연결된다.


이후 정리될 내용
 2. Recirculating-ball Steering
 3. Power Steering
 4. Pump
 5. The Future of Power Steering

참조
http://auto.howstuffworks.com/steering.htm
차량 조향장치 링크 부분에 사용되는 부품

임베디드 소프트웨어 설계 시 고려해야 할 사항(1/3) - 유연한(flexible) 소프트웨어의 필요성

1.
임베디드 시스템 엔지니어링에는 제약사항이 많다. 여러 제약 중 어떤 제약이 나중에 프로젝트 개발에 문젯거리가 될지를 파악하는 일은 쉽지 않다. 앞으로 발생할 변화를 예측해서 애플리케이션에 발생하는 변화를 충분히 수용할 수 있도록 소프트웨어를 유연하게(flexible) 설계해야 한다.

2.
소프트웨어를 설계할 때 시스템을 좀 더 유연하게 할 수 있는 몇몇 훌륭한 원칙이 있다.

모듈화 원칙을 이용해 하위 시스템별로 기능을 분리하고 각 하위시스템이 사용하는 데이터를 감출 수 있다.

캡슐화 원칙을 이용해 서로에 대해 알지 못하도록 하위 시스템 간의 인터페이스를 만들 수 있다. 하위시스템(또는 객체)의 결합을 약한 상태로 유지하면 한 부분을 고치더라도 다른 부분에 영향을 주지 않을 것이라는 확신을 가질 수 있으므로 쉽게 코드를 고칠 수 있다. 따라서 필요에 따라 일부 시스템을 분리했다가 수정하고 다시 제자리에 넣을 수 있다.

시스템을 어떻게 분리해야 하는지를 잘 판단하려면 연습이 필요하다. 최선의 방법은 독립적으로 변경될 수 있는 부분을 찾는 것이다.

3.
이 원칙들은 이론부터 나온 것이 아니라 컴퓨터나 만들어지고 프로그램을 만들면서 생긴 시행착오에 의해 적립이 된 것으로 이것들을 후에 체계적으로 정리한 것이 디자인 패턴 이다.

4.
디자인 패턴에 관심을 가진지는 오래 되었지만, 제대로 적용해 본적이 없었기 때문에 가장 대표적인 패턴인 MVC(Model, View, Controller) 를 간단한 프로그램을 통해 직접 구현해야 할 필요가 생겼다.


참조:
디자인 패턴을 적용한 임베디드 시스템

Robot Framework 이해를 위한 정리(2/3)

테스트 자동화 도입 시 얻을 수 있는 것들 및 경계해야 하는 것들
이해하기 쉽습니다.

1. Common test automation promises
테스트 자동화가 약속하는 것들.

1) Run existing regression tests on a new version of a program
새롭게 변경된 프로그램에 회귀 테스트를 실행할 수 있다.

Being able to run previously created tests without extra effort clearly makes testing more efficient.
이전에 만들어져 있는 테스트를 간단하게 실행할 수 있도록 하여 효율적으로 테스트를 수행할 수 있도록 한다.

2) Run more tests more often
많은 테스트들을 자주 실행할 수 있도록 해준다.

Automation means faster test execution which means more test rounds. Automation should also make creating new test cases easy and fast.
자동화는 빠른 테스트 실행을 의미하기 때문에 테스트를 여러번 할 수 있다는 것을 의미하며, 또한 자동화는 새로운 테스트 케이스를 쉽고 빠르게 만들 수 있도록 한다.

3) Perform tests which would be difficult or impossible to do manually
수동으로 할 때는 어렵거나 아예 못할 것 들도 수행할 수 있다.

For example performance and stress tests are nearly impossible to conduct without automation.
예를 들어 성능 테스트나 스트레스 테스트 같은 것들은 자동화가 없다면 하기 어렵다. 왜냐하면 정말 다양하고 많은 테스트를 수행해야 하기 때문이다.

4) Better use of resources
자원을 효율적으로 사용할 수 있게 된다.

Automating repeating and boring tasks releases test engineers for more demanding and rewarding work.
반복적이고 지루한 일을 자동화 하는 것은 테스트 엔지니어가 의미있는 일을 할 수 있도록 만들어 준다.

5) Consistency and repeatability of tests
일관적이고 반복적인 테스트가 가능하게 된다.

Tests are always run the same way so test results can be consistently compared to previous results from previous testing rounds. Tests can also be easily repeated on different environments.
테스트들은 항상 같은 방식으로 실행기 되기 때문에 그 결과는 이전의 테스트들과도 일관성이 있게 나타난다. 테스트들은 다른 환경에서도 쉽게 실행될 수 있다.

6) Reuse of tests
재 사용성이 높다.

Reusing tests from earlier projects gives a kick start to a new project.
재 사용성은 새 프로젝트의 빠른 출발을 돕는다.

7) Earlier time to market
빠른 출시

Reusing tests and shortening test execution time fastens feedback cycle to developers. In the end that shortens the time to market.
테스트 재사용과 빠른 실행은 개발 주기를 더욱 빠르게 한다. 그래서 시장에 빨리 출시할 수 있게 한다.

8) Increased confidence
자신감 상승

Running an extensive set of tests often, consistently and on different environments successfully increases the confidence that the product really is ready to be released.

넓은 범위의 테스트를 자주, 일관성 있게 그리고 다양한 환경에서 성공적으로 실행할 수 있다는 것은 제품의 출시에 대한 자신감을 만들어줄 수 있다.



2. Common test automation problems
테스트 자동화의 문제점

1) Unrealistic expectations
실현 가능하지 않은 기대
Managers may believe test automation will solve all their testing problems and magically make the software quality better. Automation experts should help managers setting their expectations right.
매니저들은 테스트 자동화가 모든 문제를 해결해 주고 마법처럼 소프트웨어의 품질을 향상시켜 줄 것이라고 믿는다. 자동화 전문가들은 매니저들이 기대치를 올바르게 가지도록 도와야 한다.

2) Poor testing practice
낮은 테스트 경험
If testing practices and processes are inadequate it is better to start improving them than bringing in test automation. Automating chaos just gives faster chaos.
테스트에 대한 경험이나 테스트 프로세스가 제대로 갖춰지지 않았다면 그것을 먼저 향상시킨 다음에 테스트 자동화를 논의하는 것이 낮다. 혼란을 자동화 한다면 이해할 시간이 없어 혼란이 먼저 빠르게 찾아올 것이다.

3) Expectation that automated tests will find a lot of new defects
자동화된 테스트가 새로운 문제점을 찾아낼 것이라는 기대
After automated test has been run successfully once it is not very likely to find new bugs unless the tested functionality changes. Automators normally find more defects while they are developing tests than when tests are re-executed.
테스트가 자동화 되고 성공적으로 실행되고 난 다음에는 기능이 변경되지 않는 한 새로운 버그를 찾을 가능성이 낮다. 자동화 하는 사람들은 이미 실행된 테스트를 재 테스트 할 때보다 새로운 테스트를 만들 때 문제점을 더 찾는다.

4) False sense of security
보안에 대한 잘못된 인식
Just seeing a test report with no failures does not mean that the SUT did not have any. Tests may be incomplete, either not testing all features or not able to see failures when they occur. Tests may also have defects and show wrong results.
테스트 리포트에 fail 항목이 없다고 해서 테스트 대상에 버그가 없다는 것은 아니다. 테스트는 완벽하지 않으며, 전체를 다 테스트 하지 못했거나 fail이 발생했을 때 제대로 보지 못했을 수도 있다. 테스트 자체가 문제가 있거나 결과가 잘못되었을 가능성이 있다.

5) Maintenance
유지보수
When the SUT changes also its tests change. Human test engineers are able to handle even major changes without problems but automated tests can fail after a slightest change. If maintaining test automation system takes more time than testing manually it will surely be abandoned. The same will happen also if adding new features to the automation system is too cumbersome.
테스트 대상에 변경사항이 생기면 테스트도 변해야 한다. 테스트 엔지니어 들은 중요한 변경사항을 문제없이 다룰 수 있다. 하지만 자동화된 테스트는 작은 차이점에도 문제가 생길 수 있다. 만약에 테스트 자동화 시스템을 유지보수 하는데 수동으로 하는 것보다 더 많은 시간이 들어간다면 자동화를 하지 않는것이 낮다. 테스트 대상에 새로운 기능이 들어갈 때 다루기가 어렵울 때도 자동화를 하지 않는 것이 낮다.

6) Technical problems
기술적 문제
Building and taking test automation system to use is a technical challenge which is unlikely to proceed without problems. Tools may be incompatible with the tested system and they also often have defects themselves.
테스트 자동화를 구축하고 실행하는 것은 문제점을 만날수 밖에 벗은 기술적인 도전이다. 기존에 만들어진 도구들은 테스트 되는 시스템들에 호환될 가능성이 적으며, 그 자체도 문제가 있을 수 있다.

7) Organizational issues
관리적인 이슈
Successful test automation project requires both high technical skills and support from management. Test automation has also big impact on the organization and requires changes in many processes.
성공적인 테스트 자동화 정착되기 위해서는 기술의 수준이 높아야 함은 물론이고 경영진의 지원이 필요하다. 테스트 자동화는 단체에 큰 영향을 주며 프로세스들의 변경을 초래하기 때문이다.

*단어의 뜻
regression test
회귀 테스트는 회귀 버그를 찾는 테스트를 의미한다.
회귀 버그는 이전에 제대로 작동하던 소프트웨어 기능에 문제가 생기는 것을 가리킨다. 일반적으로 회귀 버그는 프로그램 변경 중 뜻하지 않게 발생한다.
회귀 테스트로는 이전의 실행 테스트를 재 실행하며 이전에 고쳐졌던 오류가 재현되는지 검사하는 방법이 많이 사용된다.
 버그가 발생했을 경우 이를 수정하면서 해당 버그를 발견할 수 있는 테스트 케이스를 작성하고 이를 이용해 프로그램을 변경할 때마다 테스트를 다시 수행하는 것이 좋다. 수동으로 할 수도 있지만, 보통은 테스트 자동화 툴을 사용한다.

이전글
Robot Framework 이해를 위한 정리(1/3)

참조
1. Robot Framework의 첫 제안이었던 헬싱키 대학 Laukkanen, Pekka 의 석사논문

Robot Framework 이해를 위한 정리(1/3)

정의
Robot Framework는 테스트 자동화를 위한 툴이다.

기원
기본 아이디어는 헬싱키 대학에 다니던 Pekka Laukkanen 의 2005년 석사 논문 'Data-Driven and Keyword-Driven Test Automation Frameworks'  에서 채택 되었으며  Nokia Siemens Networks 에서 첫번째 버전을 개발 하였다. 2008년부터 오픈소스가 되었다.

배경
1. 프로그램은 계속 커지고 있다.
2. 소프트웨어 품질은 더욱 중요해진다.
3. 소프트웨어 테스트를 잘 해야 한다는 압박이 더 커지고 있다.
4. 테스트 자동화는 분명히 이런 일의 크기를 줄여줄 수 있는 방법이다.
5. 하지만 테스트를 위한 시스템(System Under Test, SUT)이 변경되면 많은 걸 새로 작성해야 하고, 컴퓨터가 필요한 일을 해야 하는 것은 어려운 일이다.
6. 이런 상황에서 편리한 테스트 자동화를 위하여 Robot Framework를 제안한다.

테스트의 종류

			Static
SW Test
			Dynamic			Non Functional
						Functional			Unit
									Component
									System

테스트 자동화 Framework의 발전 3단계

1. 

테스트 데이터가 테스트 스크립트 안에 있다.

하나의 테스트 스크립트는 하나의 테스트를 수행한다.

시스템이 변경 된다면 테스트를 다시 써야 한다.

2. 

잘 디자인 되고, 모듈러 특성, 탄탄한 테스트, 문서화 되어 유지보수 가능

테스트 스크립트는 테스트의 수행만 하는 것이 아니라 테스트 전 기본 셋팅 수행, 테스트 초기화, 에러를 잡아서 원상복구 진행 가능 

여전히 테스트 데이터는 테스트 스크립트 속에 있다. 셋팅하는 스크립트는 테스트 케이스 마다 있다.

3. 

테스트 데이터는 테스트 스크립트와 분리된다. 이것은 두가지 분명한 이득이 있다.
1) 하나의 드라이버 스크립트로 여러 테스트 케이스에 사용할 수 있다.
2) 테스트 디자인과 Framework의 구분 해준다.
 - 테스트 될 특정 분야 지식
 - 프로그래밍 기술
이 3단계의 테스트 자동화 Framework는 Keyword Driven, Data Driven Framework 라고 불리며 이것은 이 논문의 제목 이다.


이후 진행
1. 설치(python, wxPython-unicode, robotframework(RIDE에서 바로 실행가능), robotframework-ride 설치, 이후 필요에 의해 pySerial 등 설치)
2. 실제 테스트케이스를 통한 분석


다음글
Robot Framework 이해를 위한 정리(2/3)

참조
1. Robot Framework 홈페이지
2. Robot Framework의 첫 제안이었던 헬싱키 대학 Laukkanen, Pekka 의 석사논문

내가 성장 가능하다고 생각하는것의 힘! - Carol Dweck: The power of believing that you can improve

현재의 내가 해결하기에는 조금 역부족인 일을 만났을 때 어떻게 생각하시나요?

크게 두 가지 반응을 보입니다.

1. 이거 풀기에는 내 능력이 부족하구나.
2. 아직은 내가 못푸는구나.

둘다 비슷한 반응이라고 생각할 수 있지만
1번은 능력이 부족한 것에 초점을 두는 것이고,
2번은 '아직'은 못풀지만 조금 더 성장하면 풀 수 있다는 것에 초점을 두는 것이라고 합니다.

스탠포드의 캐롤 드웩교수는 이 두가지의 마음가짐이 얼마나 학생들의 미래에 영향을 주는지 여러 연구결과를 통해서 증명해 줍니다.

"어떠한 상황에서도 나는 성장할 수 있습니다!" 라고 몸으로 이해했으면 좋겠네요.


두 유형의 사람 비교

자신의 능력이 성장할 수 있음을	알고 있는 사람	모르고 있는 사람
뇌의 활동	뇌 안의 전기 활동이 활발	뇌 활동이 거의 없음
실수에 대처하는 법	실수를 분석, 실수를 통해 배우고 개선	자신의 실수에서 도피
진학(과목이 어려움) 시 성적 변화	성적이 떨어져도 금방 회복	점점 성적이 떨어짐
어려운 과제에 대한 반응	스스로 멍청하다고 느끼고, 스스로 포기하고 싶게 한다.	머릿속의 뇌세포가 새롭거 더 강한 연결고리를 만드는 과정이라고 인식. 문제가 어려울 때가 똑똑해지고 있는 때라고 인식

아이들에게 성장 가능성을 알려주기 위한 방법
지혜로운 칭찬을 해야 합니다.
지능이나 재능을 칭찬하는 대신,
아이들이 거치는 과정을, 그들의 노력, 계획, 집중, 인내, 향상됨을 창찬해야 합니다.
이런 “과정에 대한 칭찬”은 어려움에 쉽게 굴하지 않는 강인한 아이들을 길러 냅니다.

사용할 Python GUI 비교 및 선택하기

하나의 필요(python에서 어떤 GUI를 주로 사용할 것인가)가 생겨 고민 과정을 정리해 보았습니다. 정리를 해 놓아야. 왜 그런 생각을 했는지, 돌아볼 수 있기 때문입니다.


목적: Python에서 주로 사용할 GUI 선택


검토 자료
검색을 통해서 동영상, 여러 비교 웹페이지 들을 돌아 다녔고, 그 결론으로
1. 'stackoverflw' 의 한 질문과 답변 (링크)
2. wxPython과 PyQt 를 둘다 처음 사용해본 개발자 의견 (링크)
3. 동일한 고민을 하고 wxPython을 고른 분의 글 (링크)


개인적 요구 사항은
1. 사용성(짧은 시간에 결과 확인)
2. 범용성(어느 OS에서나 사용 가능)
3. PC에서 사용
이었습니다.


간략하게 정리하면
1. PyQt, pyGTK, wxPython 이 유명도 면에서 선정 대상이 되었고
2. 그중 pyGTK 가 범용성 면에서 점수가 낮아 먼저 탈락 되었습니다.
3. PyQt 와 wxPython 중 어떤 것을 선택하는지 문제인데,
   위 검토자료의 2, 3 이 다른 의견을 주었습니다.
4. 하지만 2번의 개발자가 직접 두 라이브러리를 가지고 직접 동일한 GUI를 구현을 해 보았고 PyQt 가 1일 걸리는 일을 wxPython으로 일주일이 걸리고, 코드의 이해도도 PyQt 가 wxPython에 비해서 높다고 하였습니다.

결론은
PyQt 공부하기로 했습니다.


추가로
python korea 에 비슷한 질문이 있고, 답변이 좋아서 기록해 둡니다.

170925 update

  - GUI 는 PyQt 를 사용하는게 제일 편합니다. 이유는 Designer Tool 때문

  - GUI 를 구성할 때는 원하는 모습으로 만들 수 있어야 하는데 이 때 바탕의 배치(layout)를 잘 활용하고 각 Widget의 Minimum, Maximum 크기를 설정하고, Dock Widget 을 활용하면 가능합니다.

  - 보통 버튼을 누르면 특정 동작을 진행해야 하는데 이 때 thread 를 사용해야 GUI 가 멈추지 않습니다. QThread를 활용 하는것이 편리해서(pyqtsignal) 저는 간단한 것만 사용했는데 내부에 bug가 많다는 글을 본적이 있어 신경쓰고 있습니다.

Arduino 실습 1 - 외부 LED 1개 동작하기

목적: 아두이노 보드의 외부에 LED를 연결하여 동작하게 할 수 있다.

순서
    1. 실험에 필요한 준비물 이해
    2. 하드웨어 연결
    3. 소프트웨어(Arduino 내부 마이크로컨트롤러에 쓰일) 작성
    4. 실행결과 확인


1. 실험에 필요한 준비물 이해

    a. LED 의 동작 원리: 짧은 쪽이 캐소드(Cathode), 긴 쪽이 에노드(Anode), 짧은 쪽은 GND(그라운드), 긴 쪽을 VCC(전원)에 연결.
    b. 저항(1K) 가 필요한 이유: 저항은 밝기의 조절과 제품의 보호(여기서는 LED)를 위한 것이며, 여기서는 1k 사용.
    c. 아두이노 UNI R3 에서 필요한 부분: VCC(전원), GND(그라운드), Digital Output(여기서는 8번 1개 사용)
        - Digital 출력의 의미: 마이크로 컨트롤러 내부 값 셋팅에 의해 특정 핀의 값을 0 또는 1로 줄 수 있는 것.

   d. 브레드 보드: 부품들 간의 연결을 점프 케이블이라는 것을 이용해서 간편하게 연결하도록 도와주는 도구.

아래 진한 빨간색 선처럼, 각 칸들의 연결이 고정되어 있으며 그 칸들에 점프케이블을 꽂아서 각 부품들을 연결할 수 있는 도구

        

2. 하드웨어 연결
    a. Arduino(Arduino UNO 3 이며 앞으로 Arduino 로 표시) 의 GND 에 하얀색 선(Jump Wire 이며 앞으로 선 표시)을 LED의 캐소드에 연결
    b. LED 의 에노드와 연결된 곳에 1k 저항선을 연결
    c. 1k 저항선의 다른쪽에 노란색 선을 꽂은 다음 Arduino 의 Digital Output  8번과 연결
하드웨어 연결 완료

3. 소프트웨어(Arduino 내부 마이크로컨트롤러에 쓰일) 작성
    a. Sketch 의 동작원리 이해
        ① 아두이노 IDE 에서 기본코드에는 setup 과 loop 함수가 기본 작성되어 있으며 그 안에 코드를 추가 가능

          ② Setup은 Arduino 가 처음 구동될 때(프로그램이 처음 설치될 때, 업로드 될 때) 기본 셋팅을 해 주는 것으며,

          ③ Loop는 계속 무한반복하며 실행하는 곳이다.

    b. 필요한 코드 작성

    c. UNO R3에 작성된 코드 넣기

        - 업로드(위 화살표, 빨간색 네모) 클릭하여 Arduino 에 새로운 프로그램 전송

4. 실행결과 확인