DPRG List  

[DPRG] Hello again DPRG. (Re-Introduction) and long message.

Subject: [DPRG] Hello again DPRG. (Re-Introduction) and long message.
From: Huff, Brian L bhuff at uta.edu
Date: Mon Apr 16 17:37:07 CDT 2012

Hello Brad,

I enjoyed your post.  There appear to be a lot of us that are asking the same question, "why is personal robotics so hard."   I think you presented very good reasons: the multi-disciplinary nature of robotics work,  the fact that, to get a well behaved and reliable robot everything has to work (the mechanics, the code, and the electronics).   The building blocks that the average hobbyist can afford are typically not that great.  The sensors that are available to us tend to be imprecise and noisy.

>From talking to David Anderson I get the impression that in addition having a superior robot, one of his greatest strengths was that he was willing to spend a large amount of time "working with his robot".   I work with students at UTA.  We build (OK, we try to build) unmanned systems.  I am continously amused by the fact that my students become confused when a robot they are building does not act the way they think it should.  They assume it wiill work the first time

Brian Huff

From: dprglist-bounces at dprg.org [dprglist-bounces at dprg.org] On Behalf Of Brad garton [bgart at iadfw.net]
Sent: Monday, April 16, 2012 11:15 AM
To: dprglist at dprg.org
Subject: [DPRG] Hello again DPRG. (Re-Introduction) and long message.

I was in the DPRG when I lived in Dallas in 1998. I sort of competed (not very successfully) in the 1998 RoboRama. I moved to Austin and due to the nature of my job, I have spent very little time in robotics since then. I have always wanted to complete the design for Tom Servo that I started back in 1998.  The sensors and controllers available have changed over the years and I am currently trying to get back up to speed again.   That’s what I’m working on now.

My original interest in robotics came from visiting mit.edu cmu, and Stanford research sites. and I became very interested in Rodney Brook’s ideas on robot programming.  When I came to DPRG I discovered people like David Anderson had already implemented much of what I wanted to do, and these robots performed very well at least in a structured environment. I have continued to watch people progress in building personal mobile robots.

Now I have begun implementing again, and as I am older,  I want to consider the big picture (who knows how long I have to work on robots).  One thing that has been observed is that the state of the Art in personal robotics has not progressed much from where it was in 1998. Is this true? I think there is at least some truth to the comment.  SR04 was and is, one of the most capable robots I have observed built by an individual.  Few of us have the skills to match that design, and we would do well to emulate David’s work, in my opinion.  However, what then?

Why is robotics so hard and why is it difficult to move the state of the art forward? If you look at research going on, in industry and the university, there are some new sensor designs available now  (Kinect, SICK etc) and some new techniques (SLAM) and these have been shown to be useful in the DARPA grand challenges for example. Not to mention the Quadrotor designs from UPenn.   All of these are very interesting developments to be sure.  All new since 1998. How can an individual hope to learn and implement robots that are more capable with the new techniques and technologies available now?

I think robotics is hard for the neophyte and I have tried to think of why that is. Here are some things I came up with based on my own experience.

1.       It spans multiple disciplines.

a.        Programming

b.       Mechanical Design

c.        Embedded Systems Design

2.       Why is robot Programming Hard

a.        It is not a typical Program, where system events are predictable, and functions proceed in an orderly sequential manner.  Events are by nature random, and multiple things need to be done apparently simultaneously.

b.       It spans multiple programming Domains.

                                                               i.      Low level machine level programming

                                                              ii.      High level behavioral or AI programming.

c.        We do not understand for the most part how the analogs in Nature work.

3.       Why is the embedded system design problem harder than a lot of other embedded systems design

a.        Robots must carry everything with them.  Power, Computing Resources, Mechanical resources

4.       Why is the mechanical aspect of a robot design difficult?

a.        Dynamics

b.       Actuators are generally power hungry and not so efficient

c.        Environments are complex, not simple

d.       Need to use lightweight materials due to the problem of carrying everything with us.
I came to robotics from a background in Electrical and Computer Engineering. The things I did in my work time were to design embedded systems and eventually I designed workstations for a 3 letter Acronym Company in Austin.  I feel like my skills circa 1998 were up to the Embedded System Design aspects of robotics.  They have atrophied considerably since then.
Rodney Brooks’s ideas allowed us to implement a very simple “AI”, which was perfect for the environment of embedded system design in 1998, but perhaps we have hit the limits of that architecture alone. It would seem we need to develop higher level behaviors at the least.  I still think it can be part of a more capable robot, though I’m not so sure the behaviors we currently use are complete.

I was an ok programmer, but I was not prepared for the challenge I encountered in implementing my robots. I had zero experience in Mechanical design, past an engineering mechanics course in College.  The result was a capable embedded system, on poorly functioning mechanics that kept me from getting to the point of writing interesting Software.  I am correcting these problems now, and may get to the level of being able to complete RoboRama, given sufficient time, but I would like to hear some ideas on how to approach this problem in general.

In particular I want to consider teaming, or crowd sourcing robotics development.  It appears that we can progress more rapidly if we have more canned solutions for the basic problems of robotics, and rather than tackling the whole enchilada at once, combine skills in teams to produce functioning robots, with the key domains above represented.  What do you think?  I can see advantages and disadvantages but want to hear what the group thinks.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.dprg.org/pipermail/dprglist/attachments/20120416/e172b6d0/attachment.html 

More information about the DPRG mailing list