이번에 애플에서 앱스토어 개발자 규칙을 완화하면서 등록될 것으로 예상되는 앱들입니다.

구글 보이스: 승인(예상)
어도비 크리에이티브 스위트 5 : 승인 확실
애드몹: 승인 확실
풍자: 승인(전문가 한정)

거부예상

(신규) 저질 앱스: 승인 거부
“저질 앱스는 더 이상 필요 없다. 유용하거나 또는 일정 형태의 영구적 엔터테인먼트를 제공하는 게 아니라면 승인 받을 수 없다”

포르노 앱: 승인 거부 계속


Posted by 따봉맨

드뎌 바다 "Developer Day" 상세 일정이 떳습니다!!!!


근데 웃기는건.... 날짜가 없습니다.. ㅡ_ㅡ;;;;

언제가 될지는 몰라도 이 날 꼭 참석해야 겠네요... 날짜가 확정되면 댓글로 알려드릴께요~~~

이 날의 주요 안건은 다음과 같이 요약되는군요.

  • Samsung bada technical overview
  • Samsung bada development life-cycle: bada Developers, tools and SDK, application deployment
  • Inside the bada platform : idioms, bada application model, UI, and service-oriented features
  • A practical clinic: installing the SDK, using the simulator, debugging, app demos

참고하세요~~~

'Smart Mobile > Samsung bada' 카테고리의 다른 글

bada Developer Day in Seoul  (0) 2010.03.24
"바다" 어플리케이션 생명 주기  (2) 2010.03.16
바다 Application UI Classes  (0) 2010.03.16
Posted by 따봉맨

2009년 9월 17일 코엑스에서 NHN에서 주최/주관하는 DeView 2009 행사가 있습니다.

데브피아 "스마트폰 모바일 랩"의 공동작업소 DevForge 를 소개하기 위해서 행사에 참여하게 되었습니다.




스모랩을 처음 시작하면서 저는 뭔가 새로운 개발자 커뮤니티 UX 를 여러분께 제공하고 싶었습니다.

지금까지 개발자 커뮤니티를 지탱해온 것은 Q&A 일겁니다. 가장 힘든 시기에 내가 풀지 못한 숙제를 풀어주는 Q&A 게시판이 개발자들을 위한

최고의 커뮤니티 UX 였습니다. 하지만 이런 단편적인 지식은 막 입문한 개발자나 체계적인 개발 지식을 접하거나 개발 경험을 전달해 주지는 못합니다.

스모랩은 우리나라를 모바일 소프트웨어 강국으로 발전시키는 중요한 디딤돌이 되기를 원합니다. 하여 DevForge 라는 공동 작업소 서비스를 통해서

개발자 여러분의 개발 경험을 DB 화 하고, 어플리케이션 개발에 필요한 기술들을 포럼 주민 여러분과 함께 개발하여

개발 환경 및 개발 인프라를 제공하는 것 입니다.


이런 노력은 모바일 개발 환경에 입문한 개발자 여러분에게 날개가 되어 드릴 것입니다. 이제 시작이라 많이 미흡합니다.

그렇지만 데브피아와 스모랩 주민 여러분과 제가 열심히 노력하고 있이니 언젠가는 개발자 여러분의 든든한 지원자가 될 것이 분명합니다.




여러분!!!!! DeView 2009 에서 꼭 뵐 수 있기를 빕니다.

감사합니다.


Posted by 따봉맨


애플에 의해 시작된 AppStore 열풍!!!

애플이 시작했지만 이젠 애플 만의 것이 아닙니다. 산업 전반에 걸쳐 많은 사람들이 AppStore 덕을 보게될 것입니다.

AppStore 열풍의 중심에 있는 사람은 개발자들입니다. 덕분에 귀인 대접을 받고 있지요.

SI 인력시장에서는 부속품이지만, AppStore 세상에서는 그 누구보다도 중요한 키플레이어입니다.

근데 모바일 어플리케이션의 특성상 업무용 프로그램 보다는 게임멀티미디어류의 어플이 강세를 보이고 있습니다.

창의적인 기능과 디자인의 어플리케이션이 더 많은 인기를 누리고 있습니다.

그래서 개발자를 비롯해서 디자이너의 능력도 많이 필요한 상황입니다.

디자이너가 많이 참여해야 우리나라 모바일 어플리케이션이 더 많이 발전할 수 있다고 생각합니다.

개발자가 혼자 개발하면 기능적으로 우수할 수는 있어도, 시각적으로는 많이 떨어지게되지요.

저도 개발할 때 어쩔 수 없이 제가 디자인을 했는데요... 개발 시간만 더 늘어나고, 그 결과는 음.... X 입니다.

디자이너 여러분!!!!!!!!!!! AppStroe 의 열풍의 중심에 서십시요. 개발자와 협업하여 중요한 키플레이어가 되십시요.

개발자와 디자이너가 만날 수 있도록, 데브피아 "스마트폰 모바일 랩"이 앞장서겠습니다.

조금 있으면 시작하는 SKT 모바일 어플리케이션 경진대회에서 디자이너 여러분이 개발자 여러분과 함께 팀을 이뤄 대회에 참석할 수 있도록 노력하겠습니다.

많이 참여해 주세요.

'DayDayDay...' 카테고리의 다른 글

Google I/O 2010  (0) 2010.01.18
광고로 벌어 정승같이 돈 쓰는 "Google"  (1) 2009.08.08
완도갑니다.  (0) 2009.07.30
Posted by 따봉맨


1. "오늘까지"라는 말은 "내일 아침까지"라는 말이다.

2. 프로그램은 내가 원하는대로 움직이지 않는다. 타이핑대로 움직인다.

3. 요구 사양은 프로그램을 완성한 후에 추가된다.
기본 사양은 완성품을 고객이 보고 나서 결정된다.
상세 사양은 사용자가 프로그램을 사용해 본 이후에 결정된다.

4. 소프트웨어 설계에는 두 개의 방법이 있다.
하나는 결함이 있을 수 없을 정도로 단순하게 만드는 방법이다.
다른 하나는, 분명한 결함을 눈치채기 어려울 정도로 복잡하게 만드는 방법이다.

5. 코드는 개발 현장에서 사용하는 것이 아니라 납품처에서 사용하는 것이다.
디버그는 납기일까지 하는 것이 아니라, 납품된 이후에 하는 것이다.

6. 프로그래머를 죽이기 위해서는 칼이 필요없다. 프로그램의 요구조건을 3번만 바꾸면 된다.

7. 다른 사람을 믿으라. 그 사람이 해결해줄지도 모른다.
주의사항 - 먼저 자신을 의심해라.

8. 개발에 마지막은 없다. 출시만이 있을 뿐이다.

9. 클라이언트의 요구사항이 제 아무리 뒤늦게 추가되어도 납기일은 변하지 않는다.
이것을「납기 불변의 법칙」이라고 한다.

10. 우리의 고객들은 물과 기능추가를 공짜라고 생각하고 있다.

11. 주머니가 짠 고객일수록 잔소리가 많다.

12. 개발 스케줄은 산수를 무시하며 짜여진다. 영업과는 1+1=2를 이해하지 못하는 사람의 모임이다.

13. 한 명이 쓰러지면 모두가 쓰러진다.

14. 버그가 너무 심하다? 걱정마라. 어느 순간 그것은 기본 사양이 될 것이다.

15. 좋은 설계는 한 명의 천재보다 세 명의 범재를 요구한다.
나쁜 설계는 백명의 범재보다 한 명의 천재를 요구한다.

16. 고객에게 시스템 엔지니어는 부하이며, 프로그래머는 가축이다.
시스템 엔지니어에게 고객은 돈이다.
프로그래머에게 고객은 보이지 않는 악성 바이러스다.

17. 돈과 시간만 있으면, 그 어떤 시스템이라도 만들 수 있다고 생각하는가?
웃어라. 그 기회는 영원히 주어지지 않는다.

18. 품질은 사양 변경의 수와 규모에 의해, 얼마나 열화될지 결정된다.

19. 영업과는 공상이 실현된다고 생각하는 몽상가이다.
시스템 엔지니어는 넘을 수 없는 벽이 없다고 믿는 모험가이다.
프로그래머와는 몽상가와 모험가에 의해 칠흑의 바다에 내던져진 표류자이다.

20. 유능한 프로그래머가 프로그램 설계개념도를 받아들고 최초로 하는 일은, 프로그램의
목적을 이해하는 것이다. 그리고 그 다음으로 하는 일은, 지정된 방법과 시간 안에는
도저히 그 목적을 완수할 수 없다는 사실을 시스템 엔지니어에게 이해시키는 일이다.

21. 프로그램이란, 운과 감에 의해서 작성되는 기적이다.
운과 감이 없다면, 그 기간 내에 그러한 목표를 실현될 수 있을 리 없다.
따라서 사양 변경은 기적에 트집을 잡는 건방진 행위이며, 사양 추가는 기적이 두 번
일어날 것으로 믿는 무모한 행위이다.

22. 시스템 엔지니어는 지구력, 프로그래머는 순발력.

23. 정시에 퇴근하면, 일이 늘어난다.

24. 완벽한 프로그램은 완벽한 시간과 돈을 필요로 한다.
미국의 국가 예산을 무제한으로 사용하는 NASA마저도, 아직 시간과 돈이 부족하다고 한다.

25. 눈으로 훑어볼 틈이 있다면 움직여라. 뇌세포보다 CPU가 더 해석이 빠르다. 그리고, 그 사이,
쉴 수 있다.

26. 불편함을 버그라고 부를 것인가, 사양 상의 제한 사항이라고 부를 것인가는 남겨진 개발일자와
납기일에 의해 결정된다.

27. 정장 대신 캐쥬얼을 입고 출근하는 "캐쥬얼 데이"를 세간에서는 휴일이나 공휴일이라고 부르는
것 같다.

28. 프로그램은 머리로 기억하지 않는다. 몸으로 기억한다.

29. 내일 쉴 수 있다면 오늘 죽어도 괜찮다.

30. 고객은 거짓말을 한다.
영업은 꿈을 말한다.
시스템 엔지니어는 공상을 이야기한다.
프로그래머는 과묵해진다. (혼잣말은 많아진다)

31.「네, 할 수 있습니다」라고 말하기 전에 10초만 곰곰히 다시 생각해보라.

32. 프로그래머는 1분 생각하고 1일을 코딩에 소비한다.
1시간 생각하고 1시간 코딩하는 대신에 말이다.

33. 납품 이후의 디버그는 버그를 부른다.

34. 세 개의 디버그는 하나의 버그를 낳는다. 이것을 버그의 엔드리스 루프라고 한다.

35. 안 좋은 예감은 반드시 적중한다. 그러나 프로그래머는 그 안 좋은 예감에 반응하지
않는다. 그것은 시스템 엔지니어의 일이다.

36. 아수라장을 해결할 수 있는 방법은 오직, 고객이 돈을 지불하는 것 뿐이다.

37. 아마추어는 버그발견의 천재이다.

38. 아, 그건 마이크로소프트에서만 가능한 주문입니다.

39. 프로그래머가 불만이라고 생각하는 부분은 고객도 반드시 불만이라고 생각한다.

40. 건강하기 때문에, 건강을 해친다.

41. 그건, 당신이 말한 요구조건입니다만.

42. 아, 개발실의 창문은 안 열립니다. 그 이유는 옛날에 한 프로그래머가 그 창문에서···

43. 고객은 최악의 사태를 믿지 않으며, 그 사태에 대한 준비를 악질적인 비용청구라고 생각한다.
시스템 엔지니어는 최악의 사태를 대비하고 준비하려 한다.
프로그래머는 최악의 사태를 누구보다 잘 예상하지만, 무시한다.

44. 만약 다른 직업을 갖게 된다면, 정시퇴근을「도망」이라고 부르지 않는 직업이 좋을 것 같다.

45. 시스템 엔지니어가 프로그래머에게 말하는「상식」은 3시간마다 변한다.

46. 최소한 자기가 쓴 시방서는 읽어주세요.

47. 고객이 시스템 엔지니어에게 사랑받는 방법은, 시스템 개발에는 시간이 곧 돈이라는 사실을
깨닫고 빨리 최종요구조건을 확정하는 것이다.
SE가 고객에게 사랑받는 방법은, 프로그래머에게 미움받는 것이다.

48. 납기일이란, 작업현장이 우리 회사에서 고객의 회사로 바뀌는 날을 의미한다.

49. 가끔 일어나는 버그는 버그가 아니다. 스펙이다.

50. 개발비의 30%는 프로그램의 요구조건을 확정하는데 사용된다.
개발비의 30%는 프로그램의 요구조건을 변경하는데 사용된다.
개발비의 30%는 프로그램의 버그를 잡는데 사용된다.
개발비의 10%만이 프로그램의 개발에 사용된다.

출처 : http://gall.dcinside.com/list.php?id=programming&no=69357&page=1

모두 맞는 말입네다~~~!! ㅋㅋㅋ
Posted by 따봉맨
순진한 개발자가 사내정치에서 살아남는 법

류한석 (IT 컬럼니스트) ( ZDNet Korea )   2008/03/17
개발자 K씨를 재회한 것은 8년만의 일이다. 그는 나와 함께 일했던 직장에서 이직한 이후에 4번이나 더 이직을 했는데, 현재는 실직 상태에서 직장을 구하고 있었다.

솔루션을 개발하는 회사에서는 비전이 없어 그만 두었고, 대기업 계열 SI업체를 들어갔으나 개발이 아닌 관리를 시켜서 그만두었고, 포털에 들어갔는데 할 일이 별로 없고 회사 상황이 정치적이어서 그만두었다고 했다. 그리고 마지막 회사는 소위 벤처기업이었는데, 6개월이나 임금을 받지 못한 상태에서 사장이 사실상 야반도주를 해서 회사가 망했다고 했다.

K씨는 자바를 정말 잘 다루던 개발자였는데, 일반적인 기준에서 볼 때 성격이 좋다고 얘기하기는 힘든 사람이었지만 그 정도면 무난하다고 할 수 있었다. 다만 여느 개발자와 마찬가지로, 타인의 욕구에 관심을 가지거나 커뮤니케이션 스킬이 뛰어난 사람은 아니었다. 다음은 그가 한 얘기이다.

“회사 경영은 나하고 상관이 없다고 생각했어요. 제가 경영이나 관리 같은 것은 잘 모르고요. 회사에서 벌어지는 정치 게임은 질색이에요. 저는 그저 개발만 하고 싶었어요. 그런데 개발에 집중할 수 있는 조직이 참 없더라고요. 이제 저는 어떻게 해야 할까요?”

필자는 그날 K씨와 새벽까지 술을 마실 수 밖에 없었다. 개발자가 개발자답게 일하고 성장할 수 없는 것이 바로 한국의 현실이다. 성장을 하는 것이 아니라 사라져 가고 있다.

개발자는 어떤 사람인가? 문제를 발견하고 문제를 해결하고, 스펙에 따라(또는 창조적으로) 무언가를 만들어 내고, 오랜 시간 동안 한 자리에 앉아서 화면만을 째려보며 몰입할 수 있기에 개발자다. 그것이 그들의 특징이며 그렇게 때문에 개발을 할 수 있는 것이다.

개발자에 대해 IT업계의 다른 직종들은 어떻게 생각하고 있을까? 단편적이지만 그들의 생각을 살펴보자. 어떤 영업맨은 “저한테 저렇게 열 시간 동안 앉아 있으라고 하면 절대 그러지 못할 거 같네요. 어떻게 저럴 수 있나요?”라고 필자에게 반문하기도 했다.

어떤 마케터는 “그들은 쿠폰에 항상 도장을 찍더군요. 작은 것에 민감한 거 같아요. 시야가 좁고 자신들의 분야 외에는 거의 관심이 없는 거 같더군요. 게임이나 애니, 미드 같은 것을 좋아하고. 업계나 시장 돌아가는 상황에 대해서는 관심도 없고...”라고 얘기했다. 실제로 마케터들은 개발자와 함께 일하는 경우가 별로 없어서 그들을 잘 모른다. 원거리에서 그들을 바라볼 뿐이다.

반면에 개발자와 함께 협업하는 경우가 많은 요구분석가, 웹기획자들 중 상당수는 다음과 같은 얘기를 했다. “그들은 커뮤니케이션 스킬이 없어요. 중요한 대화에는 제대로 응하지 않다가 자신들과 상관이 있는 이슈가 나오면 발끈해요. 무조건 안 된다고만 하죠. 도무지 협상이라고는 할 줄 모르는 사람들이에요.”

혼자서 일하는 1인 개발자가 아닌 이상, 대부분의 개발자는 조직에서 협업을 해야 한다. 프로젝트 매니저와 대화해야 하고, 기획자/디자이너/동료 개발자와 협업을 해야 한다. 프로젝트에 따라서는 고객과 직접적인 커뮤니케이션을 해야 하는 경우도 있다. 그리고 사내정치를 피해갈 수 있는 개발자는 거의 없다. 직간접적으로 영향을 받을 수 밖에 없다.

그런데 한국에서 사내정치는 중소기업에서 대기업, 인터넷기업까지 만연되어 있다. 많은 개발자들이 정치를 싫어한다. 정확히 표현하면 정치가 미치는 부정적인 영향을 싫어한다고 할 수 있을 것이다. 하지만 조직이라는 것은 그 안에 있는 수많은 조직구성원들이 지위 고하에 따라 자신의 목표와 이익을 추구하는 곳이다. 그리고 그들간의 이해관계는 상충될 수 밖에 없다. 그래서 누군가는 희생자가 된다. 안타깝게도 그 대상은 대부분 개발자이다.

개발자는 현실적인 일정 하에서 보다 나은 기술을 이용하여 높은 품질의 소프트웨어를 만들고 싶어하지만, 어떤 사람들은 기술 자체나 품질은 전혀 상관없이 일자 또는 비용만이 그들의 관심사이다. 그렇다면 그것은 잘못된 것인가? 그럴 수도 있고 아닐 수도 있다. 상황에 따라 답이 다르다. 현실은 단순한 흑백논리로 설명되지는 않는다.

패배하지 않기 위해 이것만은 기억하자

사내정치에서 살아남기 위해서 개발자가 알고 있으면 유용할 세 가지 지침을 제시한다. 다음의 세가지 지침은 서로 연동된다.

1. 나의 목표와 주변의 이해관계를 파악하고 있어야 한다.
자신이 원하는 것이 돈인지 명예인지 지위인지, 아니면 개발을 통한 자아실현인지, 개인생활의 추구인지 명확히 알고 있어야 한다. 또한 나의 목표를 실현하는데 있어 가장 큰 장애물이 무엇인지 알고서 그것을 관리해야 한다. 자신의 목표와 상충되는 목표를 가진 이해관계자의 욕구를 파악하고 그것과의 타협점을 찾아야 한다.

하지만 사실, 대부분의 경우 목표를 실현하는데 있어서 가장 큰 장애물은 자기자신의 성격이다. 그렇지만 성격을 수양하는 개발자가 과연 몇 %나 될까? 아는 것과 실천은 완전히 별개의 단계이다.

2. “너와 나의 진실은 다르다”는 사실을 이해하고 있어야 한다.
자신이 믿는 것만이 정의이고 진실이라는 생각이 들 때, 숨을 세 번 크게 내쉬면서 상대편의 입장에서도 과연 그럴까 다시 한번 생각해 보기 바란다. 내가 알거나 느끼는 것을 쉽게 드러내서는 곤란하다. 대부분의 경우 그것은 설익은 판단이고 타이밍이 적절치 않은 경우가 많다. 하지만 자신의 감정을 주체하지 못하고 ‘욱’한 나머지, 준비도 안된 상태에서 회사를 그만 두어 버리고 경력을 망치는 개발자들이 많다. 퇴사 후 놀고 있는 당신을 사내정치인들은 비웃고 있다.

3. “군자에게는 실수를 해도 소인배에게는 실수를 하지 말라”는 격언을 기억하기 바란다.
이 말은 필자가 회사 생활에서 곤란을 겪는 후배들에게 숱하게 해주었던 말이다. 이 말을 처음 들었을 때의 임팩트는 상당히 크다. 군자(君子)는 점잖고 덕이 있는 사람이다. 그래서 군자는 누가 실수를 해도 그 이유를 스스로 파악하여 너그럽게 이해해준다. 하지만 소인배는 조금만 불이익을 당하거나 무시를 당했다고 느끼면 바로 삐지며, 심할 경우 끝까지 따라다니며 괴롭힌다.

그런데 사람이란 군자에게는 존경심을 갖고서 공손히 대하고 소인배는 무시한 나머지 함부로 대한다. 그것이 인지상정이다. 하지만 만일 그 소인배가 당신의 직장상사라면?

사내정치는 어느 나라에나 존재한다. 한국뿐만 아니라 미국에도 일본에도 있다. 하지만 한국에서 더욱 사내정치가 심할 수 밖에 없는 이유가 있다. 한국은 아직까지 IT업계뿐만 아니라 사회의 여러 분야에서 전문가의 개념이 불분명한 나라이다. 제대로 된 전문가가 출현하고 그 가치를 인정받는 지식사회가 되기까지 앞으로도 꽤 많은 시간이 걸릴 것이다.

한국은 아직은 선진 지식사회가 아니다. 그러므로 고급지식을 가진 사람들이 별로 없을 뿐만 아니라, 설사 있다고 하더라도 그것을 인정하지 못하며, 설사 인정한다고 할 지라도 필요로 하지 않는다. 실력을 인정하는 기준이 없으니, 사내정치가 판을 친다.

전문가를 필요로 하지 않는 사회, 자기계발이 살길
궤변으로 들릴 지 모르지만, 우리 업계에 전문가가 없는 것은 전문가를 필요로 하지 않기 때문이다. 조직 내에 사내정치인이 승진하고 인정받는 것은 조직의 상층부가 몰라서 그런 것이 아니라 그런 사람을 선호하기 때문이다.

성장은 커녕 생존을 이야기해야 하는 현실이 안타깝지만, 일단 생존해야 자기계발을 하고 경력관리를 하면서 기회를 노릴 것이 아닌가? 사내정치를 잘 할 필요는 없지만(그리고 개발자의 특성상 잘 하지도 못 할 것이다), 희생자가 되어서는 곤란하다. 이것이 바로 필자가 개발자 K씨에게 한 말이다.

개발자는 자신의 개발력과 장점을 해치지 않는 선에서, 이해관계자를 파악하고 그들의 욕구를 다루는 능력을 갖추어야 한다. 자신의 목표를 분명히 해야 하며, 감정에 치우쳐서 일을 그르치지 말아야 한다. 그러지 못한다면 결국 희생자가 될 뿐이다.

그러한 희생을 몇 번 당하다 보면, 개발업에 대한 애정이 식어버려 자기계발을 등한시하게 될 뿐만 아니라 성격까지 나빠져서 더욱 더 안 좋은 상태에 처하게 된다. 그렇게 사라져간 개발자들이 참 많다.

이런 조언을 하는 것에 대해 한편으로는 미안하게 생각한다. 언젠가 개발력만으로도 인정받을 수 있는 사회가 오면(너무 낭만적인 표현이다), 사내정치 대신 좀 더 아름다운 세상에 대해 이야기하겠지만 지금은 아니다. 정신을 똑바로 차리고 이 난세에서 생존하기 바란다. 환경을 바꿀 수 없으면 자신을 바꾸어야 하며, 자신을 진화시킨 개발자에게는 반드시 기회가 올 것이다. 세상은 장기적으로 볼 때 스스로 혁신하는 사람의 편이니까 말이다. @

원본 : http://www.zdnet.co.kr/builder/dev/etc/0,39031619,39166851,00.htm

'DayDayDay...' 카테고리의 다른 글

오랜만의 인라인 로드, 22km 달렸습니다.  (0) 2008.03.20
휴가의 마지막 월요일  (0) 2008.03.17
일주일 휴가 더~~  (0) 2008.03.11
Posted by 따봉맨
컵퓨터 비젼에 관심을 갖고,
무엇을 할까 생각하다가..
로보트를 만들어보자 생각했다.

근데 내가 어떻게 만들어???
그래서 로봇도 소프트웨어로 에뮬레이션 해보면 재밌겠다 싶더라고..

http://www.ibm.com/developerworks/linux/library/l-robotools/index.html

영어 공부할 겸.. 읽어 봅시다.

Open source robotics toolkits

Use virtual arenas to test your robotics algorithms

developerWorks
Document options
Set printer orientation to landscape mode

Print this page

Email this page

E-mail this page

Document options requiring JavaScript are not displayed


New forum features

Try private messaging, read-tracking, and more


Rate this page

Help us improve this content


Level: Intermediate

M. Tim Jones (mtj@mtjones.com), Consultant Engineer, Emulex

05 Sep 2006

Building a robot involves skills from many disciplines, including embedded firmware and hardware design, sensor selection, controls systems design, and mechanical design. But simulation environments can provide a virtual arena for testing, measuring, and visualizing robotics algorithms without the high cost (and time) of development. This article introduces you to some of the open source robotics toolkits for Linux®, demonstrates their capabilities, and helps you decide which is best for you.
Software robot?

Researchers at the University of Washington coined the term Softbots -- a combination of software and robot. The term intelligent agent is now more commonly used, especially in the context of Internet-capable entities. In 1996, Franklin and Graesser introduced the first agent taxonomy to classify viruses as autonomous agents.

The spectrum of traditional robots is large and varied, but with the advent of software agents (the virtual robot counterpart), these variations have expanded. Many of the characteristics of physical robots lend themselves to robots in the virtual domain. For example, mobility in physical robots implies some sort of locomotion, but mobile soft robots (or agents) can have mobility -- here, the ability to migrate between hosts in a network. Figure 1 shows a shallow view of autonomous robotics in the physical and virtual domains. This article focuses on software agents as a mechanism to simulate robots in synthetic environments.


Figure 1. Shallow taxonomy of autonomous robots
Shallow taxonomy of autonomous robots

Elements of a robot

Whether you're talking about a physical robot or a virtual (soft) robot, the fundamental concepts are the same. The robot has a set of sensors used to perceive its environment, a set of effectors to manipulate its environment, and a control system that allows the robot to act in an intentional and useful way (see Figure 2).


Figure 2. The fundamental elements of all robotic systems
The fundamental elements of all robotic systems

In the physical world, a fire-fighting robot could use temperature sensors, infrared (IR) sensors, a Global Positioning System (GPS) to perceive its environment, and motors and perhaps a fire extinguisher as effectors to manipulate its environment. A virtual search agent could use Web servers and HTTP interfaces to both perceive and manipulate the environment (the Internet) and a console as an effector to communicate with a user.

The system shown in Figure 3 is that of a closed loop, with sensors feeding the control system that drive changes in the environment. Another way to think about this is in terms of feedback. If the control system specifies an act that changes the environment, the sensors can validate this change, feeding back the new state of the environment to the control system. An open-loop system would have to assume that the acts successfully changed the state of the environment, which can never be a good thing.


Figure 3. Closing the loop with the environment
Closing the loop with the environment

When building a robot, you must consider the sensors, the effectors, and the control system as a whole. For this article, I focus on the control system and the ways in which you can simulate and validate it before spending time embedding it in a physical robot.



Back to top


Robotics and simulation

Simulation plays a key role in the field of robotics, because it permits experimentation that would otherwise be expensive and/or time-consuming. Simulation permits you to try ideas in dynamic, synthetic environments while collecting stimulus response data to determine the quality of the control system. Simulation also allows the evolution of robotics control systems, which depend on random permutations of the control system over many generations (as demonstrated by genetic algorithms).

Linux and robotics

Linux is a popular operating system for robotics, because at its roots, it shares a similar history with robotics. Robotics is a field of experimentation. It's about optimizing, trying new things, and evolving toward the future. Linux, at its heart, is about the same things. Early robots were oddities and exhibited few practical applications. Similarly, Linux began as hobbyist operating system but has grown into a powerful and stable operating system that can be found from tiny embedded devices to supercomputers (including many robots).

One of the greatest advantages to simulation occurs in multi-robot simulations. A popular venue for these simulations is in Robot Soccer, where either through simulation or with physical robots, one team of robots competes against another in the popular world sport of soccer (making it ideal for international competition). The robots must compete cooperatively against the other robots on their team (possibly with communication) as well as competitively with the robots on the opposing team, making it a challenging test of robot behavior.

But there are downsides to simulation. The real world tends to be messy and noisy, and synthetic environments are fundamentally difficult to model. Simulating a robot also tends to be difficult, as sensors in the real world can often exhibit different or unexpected characteristics. Despite the disadvantages, you can learn a lot by simulating robots in synthetic environments.



Back to top


Open source toolkits for Linux

Several open source toolkits are available for building robotic control systems. This article looks at mobile robot simulators, a physics modeling system, and finally, a simulator that supports embedding a simulated control system in a physical robot. The vast majority of toolkits available run on Linux, primarily because of the open source model. Open source software is a platform from which you can develop software more quickly and with less effort, so it's ideal. Linux also permits customization not possible in other operating systems (such as minimizing and extending the kernel). Links to these toolkits and more are in Resources section at the end of this article.

ODE

Russell Smith's Open Dynamics Engine (ODE) is an open source physics engine with which you can simulate articulated rigid body dynamics. In this way, you can simulate the physics of real-world objects independent of a graphics library (for which you could use OpenGL). You can use the ODE to model all sort of objects in synthetic environments, such as characters in three-dimensional game environments or vehicles in driving simulations. In addition to being fast, the ODE supports collision detection for real-time simulation.

What is an articulated rigid body?

An articulated rigid body is a structure that consists of a variety of shapes connected by various kinds of joints. For example, consider the joints that make up the leg or the elements in a vehicle's chassis, suspension, and wheels. The ODE can model these elements efficiently, including friction models.

The ODE currently supports the ball-and-socket, hinge, slider, fixed, angular motor, and hinge-2 (for vehicle joints) joint types, among others. It also supports a variety of collision primitives (such as sphere and plane) and several collision spaces.

The ODE is written primarily in the C++ programming language, but it exposes clean interfaces in C and C++ for integration with your application. What makes the ODE even better are the licenses under which it's released: the GNU Lesser General Public License (LGPL) and the BSD License. Under either license, you can use the ODE source in commercial products without a fee. As a result, you'll find the ODE in a variety of commercial games, flight simulators, and virtual reality simulations.

The source example in Listing 1 shows a simple world with Mars' gravity and a sphere that currently has some upward velocity. Given that the world has gravity, that upward velocity won't last long; eventually, the sphere reaches the apex and begins its descent. After the initialization is complete (that is, objects created in the world and their attributes set), you can simulate the physics of the world with a call to dWorldStep. To understand what's happening, you make a regular call to dBodyGetPosition and pass in your sphere's identifier to get its current position.


Listing 1. Simple ODE experiment of a sphere in a world with gravity
		 
#include <iostream>
#include <ode/ode.h>

#define time_step		 (float)0.1

int main()
{
  dWorldID myWorld_id;
  dBodyID mySphere_id;
  dMass sphereMass;
  const dReal *pos;
  float time = 0.0;

  /* Create a new world */
  myWorld_id = dWorldCreate();

  /* Create a sphere in the world */
  mySphere_id  = dBodyCreate( myWorld_id );

  /* Set the world's global gravity vector (Mars) -- x,y,z */
  dWorldSetGravity( myWorld_id, 0, 0, -3.77 );

  /* Set the Sphere's position in the world -- x,y,z */
  dBodySetPosition( mySphere_id, 0, 0, 100 );

  /* Set the Sphere's mass (density, radius) */
  dMassSetSphere( &sphereMass, 1, 2 );
  dBodySetMass( mySphere_id, &sphereMass );

  /* Give the sphere a small amount of upward (z) velocity */
  dBodySetLinearVel( mySphere_id, 0.0, 0.0, 5.0 );

  /* Run the simulation */
  while (time < 5.0) {

    /* Simulate the world for the defined time-step */
    dWorldStep( myWorld_id, time_step );

    /* Get the current position of the sphere */
    pos = dBodyGetPosition( mySphere_id );

    std::cout << "position (" << pos[0] << ", "
             << pos[1] << ", " << pos[2] << ")\n";

    /* Next time step */
    time += time_step;

  }

  /* Destroy the objects */
  dBodyDestroy( mySphere_id );
  dWorldDestroy( myWorld_id );

  return 0;
}

So, if you need an industrial-quality physics engine (that operates on Linux as well as other platforms) to simulate your mobile robot or unmanned aerial vehicle in realistic environments, the ODE is a superb choice. Used with the OpenGL application program interface (API), the ODE generates photo-realistic graphics with realistic physics, as well.

Simbad robot simulator

Simbad is a three-dimensional robot simulator written in the Java® programming language (so it runs on Linux and other platforms that support the Java virtual machine, or JVM); however, the simulator includes support for Python scripting (through Jython). Simbad was designed to study artificial intelligence (AI) algorithms in the context of autonomous robotics, and it includes a rich graphical user interface (GUI) for visualization not only of the robot's actions but also from the robot's perspective.

What makes Simbad interesting is that it's simple to use and allows you to create new robot behaviors quickly. But while developing for Simbad is simple, it's actually an extensible framework for robotic simulation.

With the simulator, you can create or tailor an environment, and then develop your robot controller using a variety of sensors. Available sensors include a vision sensor (color monoscopic camera), range sensors (sonars and IR detectors), and bumpers for collision detection.

The APIs for the sensors are clean and intuitive to use. The example in Listing 2 demonstrates the use of sonar and how to detect a hit (an object detected).


Listing 2. A snippet of code demonstrating simulated sonar use
		 
int sonar_id, total_sonars;

// If at least one sensor has a hit
if (sonars.oneHasHit()) {

  // Find out how many sonars are on the robot
  total_sonars = sonars.getNumSensors();

  // Iterate through each sonar
  for ( sonar_id = 0 ; sonar_id < total_sonars ; sonar_id++ ) {

    // Does this one have a hit?
    if (sonars.hasHit(sonar_id)) {

      // Emit the details (angle, range)
      System.out.println( "Sonar hit at angle " +
                           sonars.getAngle(i) +
                           " at range " +
                           sonars.getMeasurement(i) );

    }

  }

}

Other sensors available in Simbad follow a similar pattern, creating an intuitive set of APIs.

What really makes Simbad so useful is its console for robot simulation and visualization. As Figure 4 shows, the Simbad console gives you a real-time view of the world, an inspector panel that provides robot details (including the camera), and a control panel for managing the simulation.


Figure 4. The Simbad robot simulator and visualizer console
Simbad Robot Simulator and visualizer console

Simbad also provides good documentation and tutorials to get you up and running quickly in both the Java and Python languages. And along with single-robot simulation, you can simulate multiple robots simultaneously. Overall, the Simbad simulator is a great environment for testing ideas in intelligent robotics algorithms. Simbad is available under the GPL open source license.

TeamBots

TeamBots is a portable multi-agent robotic simulator that supports simulation of multi-agent control systems in dynamic environments with visualization. What makes TeamBots unique compared to other simulators such as Simbad is the portability of the control system. You can develop your control system and validate it on the simulator, and then test your control system in a real mobile robot (using the Nomadic Technologies Nomad 150 robot).

The TeamBots API provides an abstraction layer for the control system (see Figure 5). As a result, the control system has no idea whether it's running on a simulator in a synthetic environment (TBSim) or in a mobile robot platform in a real environment (TBHard).


Figure 5. The TeamBots API abstraction layer to the control system
The TeamBots API

The TeamBots simulation environment is very flexible and easily allows the construction of synthetic environments with objects and other robots. It is easy to add walls, arbitrary objects, roads, and other robots running the same or different control systems. In this way, you can build predatory/prey simulations (as one example). In addition, objects need not be static. You could place objects that move around the environment or objects that can move if nudged by a robot (such as a ball).

With TeamBots, you can model different types of robot simulations. For example, in 1997, Georgia Tech used TeamBots to win the American Association for Artificial Intelligence (AAAI) mobile robot competition with two simulated Nomad 150 robots foraging in a dynamic environment. The goal was for the two robots to search the environment, and then pick up and return the blue objects to the blue bin and the orange objects to the orange bin (see Figure 6). To add some complexity to the competition, the orange balls were dynamic and constantly moved around the environment.


Figure 6. TeamBots simulation of foraging behavior
TeamBots simulation of foraging behavior

In Figure 6, mobile robot 1 has a blue object and is moving toward the blue bin to drop it off. Robot 0 is searching.

You can also use TeamBots in the development of robotic soccer players. As soccer is a sport with international appeal, it's a great platform for competition between international universities and groups. Rules for robot soccer can differ (especially when considering the varieties that exist for mobile platforms, bipedal platforms, or Sony Aibo), but all share the fundamental model of the game.

In Figure 7, Robot 1 (yellow/white) is moving toward the ball in a goal attempt. Robot 0 (blue/red) is the opposing goal keeper and is positioning for a block. Robot soccer is actually quite interesting to watch, and the TeamBots distribution provides several teams that you can employ or use to experiment for new strategies.


Figure 7. Demonstrating TeamBots in the SoccerBots domain
TeamBots in the SoccerBots domain

TeamBots provides a Java API for soccer that allows you to concentrate on the "brain" of the player. The effector API permits turning the robot, moving at a certain speed, kicking the ball, or simply moving the ball. Sensors are built at a high level and provide APIs for determining the vector to the ball, an array of vectors to other players (team and opponents), getting the current heading, getting a vector to the opposing goal, and so on.

To give you an idea of the level of the TeamBots Soccer API, check out Listing 3, which presents a very simple strategy. This strategy (derived from the SoccerBots source by Tucker Balch) simply looks for the ball, heads to it, and then kicks it (without regard to the direction of the goal). It's a random strategy but demonstrates the simplicity of the API.


Listing 3. Simple soccer player snippet using the TeamBots SoccerBots API
		 
public int TakeStep()
{
  Vec2 ball;
  long T;

  T = abstract_robot.getTime();

  // Get the vector to the ball
  ball = abstract_robot.getBall(T);

  // Point ourselves to it
  abstract_robot.setSteerHeading(T, ball.t);

  // Go to it (maximum speed)
  abstract_robot.setSpeed(T, 1.0);

  // If we can kick it, do so!
  if (abstract_robot.canKick(T)) abstract_robot.kick(T);

  return(CSSTAT_OK);
}

The TeamBots distribution is a great environment for both prototyping and simulating mobile robots and also for executing them within real robots using the TBHard environment. TeamBots is open source (developed by Tucker Balch of Georgia Tech and Carnegie Mellon University) and can be used freely for educational and research purposes. The simulator was developed in the Java language and is distributed with full source code and several examples to help you get up and running quickly.



Back to top


Other toolkits

One of the most well-known mobile robot platforms for which numerous simulators have been written is called Khepera. Unfortunately, Khepera evolved into commercial software and is no longer open source. Fortunately, toolkits such as KControl are still available for developing control systems for Khepera on Linux.

An interesting three-dimensional robot simulator with dynamics is available in Gazebo. Gazebo models not only standard robot sensors (such as inertial measurement units, GPS receivers, and monocular cameras) but also real-world rigid-body physics for robotic environments. Gazebo supports a plug-in model in which you can load new robot sensor models into environments dynamically.

Finally, a useful robot navigation toolkit is Carmen -- the Carnegie Mellon Robot Navigation Toolkit. Carmen implements a modular architecture that provides fundamental navigation primitives such as obstacle avoidance, path planning, and mapping. As well as providing a two-dimensional simulator, Carmen supports several physical robot platforms running Linux.



Back to top


Building Linux robots

Getting started building Linux-based robots isn't as difficult as you might think. In fact, some high-school science curriculums are using Linux and readily available hardware as the core for Linux-based robots. For example, you could use an old PC motherboard as the system core (or better yet, an old laptop), and boot Linux from a USB drive (which would consume significantly less power than a CD-ROM or hard/floppy drive). The onboard parallel port can be easily transformed into a multitude of devices, such as discrete inputs and outputs, or to drive a set of stepper motors. The serial port can be used to sink GPS coordinates, or with an external device, as an A/D (Analog to Digital) or D/A (Digital to Analog) converter. Finally, you can purchase inexpensive USB Web cameras to give your robot the ability of sight.

But what really makes Linux shine in this environment is the ability to simplify the environment to make robot control system design accessible to anyone through higher level languages such as Python. Michael Surran of the Greater Houlton Christian Academy in Maine offered recently, for the second year, a high school robotics course that features Linux and readily available hardware. At the core of their curriculum is the use of Python. Since Python is an interpreted language, it's very easy to experiment with algorithms, without the need for lengthy compile cycles (what makes interpreted scripting languages so useful in the first place).

If you're looking beyond the homebrew Linux solution, Carnegie Mellon University recently introduced the "Qwerkbot" platform from their Mobile Robot Programming Lab (MRPL), which runs the 2.6 Linux kernel. The "Qwerk" is an ARM9-based board with 8MB of flash, and 32MB of SDRAM; it includes four onboard motor controllers, 16 servo controllers, 16 digital I/Os, 8 12-bit analog inputs, and a whole lot more.



Back to top


Conclusion

Robot simulators can greatly simplify the job of building physical robots. Through simulators, you can test ideas and strategies before putting them into hardware. Luckily, the Linux and open source communities have several options that are not only easy to use but can even support direct linkage to hardware platforms.



Resources

Learn
  • The Open Dynamics Engine is a physics engine for modelling articulated rigid-body dynamics.

  • The Simbad robot simulator is a great tool for robot simulation and visualization.

  • The TeamBots distribution is a great environment for both prototyping and simulating mobile robots as well as executing them within real robots using the TBHard environment. TeamBots is open source (developed by Tucker Balch of Georgia Tech and Carnegie Mellon University) and can be used freely for educational and research purposes.

  • The RoboCup Soccer competition's extensive set of rules that define what's permitted in play, from the size of the field to the ball used (an orange golf ball).

  • The 2005 RoboCup held in Osaka, Japan, included a variety of robotic soccer events, including traditional mobile robot players, bipedal robots, Sony Aibos, simulated virtual players as well as several other robotic demonstrations. The RoboCup Web site provides some great video footage of this event.

  • The American Association for Artificial Intelligence Web site maintains a good (and current) list of AI topics and research. Their robotics page will keep you up-to-date on the latest happenings in the world of soft and hard robotics (as well as their open source projects page).

  • Khepera II remains based on the Motorola 68331 CPU (the miniature Khepera is a bit outdated). In addition to the mobile platform, many options exist to extend the platform, such as with a video camera module, a gripper module, and a radio modem to permit communication with other Khepera mobile robots.

  • The Gazebo multi-robot simulator implements not only a realistic robot simulation but also an accurate simulation of rigid-body physics for the robot's environment.

  • Carmen is a robotic navigation toolkit that provides simulation and support for physical robot platforms. It implements several navigation primitives, such as mapping and path planning.

  • Find interesting recipes for the Qwerkbot, including a pan-tilt unit for a camera, at CMU.

  • "Do-It-Yourself Robots with Linux", a Linux Journal article by Michael Surran's explains why Linux and older PC hardware make a great platform for building mobile robots.

  • To run Java on Linux, you can use the Blackdown Java Linux package.

  • In the developerWorks Linux zone, find more resources for Linux developers.

  • Stay current with developerWorks technical events and Webcasts.

Get products and technologies
  • Order the SEK for Linux, a two-DVD set containing the latest IBM trial software for Linux from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.

  • With IBM trial software, available for download directly from developerWorks, build your next development project on Linux.


Discuss


About the author

M. Tim Jones

M. Tim Jones is an embedded software architect and the author of GNU/Linux Application Programming, AI Application Programming, and BSD Sockets Programming from a Multilanguage Perspective. His engineering background ranges from the development of kernels for geosynchronous spacecraft to embedded systems architecture and networking protocols development. Tim is a Consultant Engineer for Emulex Corp. in Longmont, Colorado.


Posted by 따봉맨
사용자 삽입 이미지

나도 나중에 이렇게 되면 어떻하지????????????????

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
Posted by 따봉맨


오래전에 찍었던 거에요..

팝디제이를 있게 한 사람들입니다.

옛날 생각이 막나네....

등장인물
==========

택구형
병영형
성현이형
종렬이형

카메라맨
==========
따봉맨
Posted by 따봉맨


병영형. 오래된 동영상이네... ^^
형이 이 것을 볼 수 있을까????
보게되면 연락줘여~~

기부스하시고, 개발하는 모습ㅋㅋㅋㅋ
Posted by 따봉맨
이전버튼 1 이전버튼