Standardized distributed robotics

Player/Stage already has network-transparent distributed robotics built
in.

cheers, Rich.


--
rich walker         |  Shadow Robot Company | rw@shadow.org.uk
technical director     251 Liverpool Road   |
need a Hand?           London  N1 1LX       | +UK 20 7700 2487
www.shadow.org.uk/products/newhand.shtml

Got a URL?

Gazebo is the 3d simulation component;


http://www.cim.mcgill.ca/~junaed/robotics/psg/psg_intro.html

is an intro

cheers, Rich,

--
rich walker         |  Shadow Robot Company | rw@shadow.org.uk
technical director     251 Liverpool Road   |
need a Hand?           London  N1 1LX       | +UK 20 7700 2487
www.shadow.org.uk/products/newhand.shtml

It looks interesting. What is your opinion? It seems a little "too much"
don't you think?

I think a lot of the time we strive too hard for some state of perfected
abstraction that, in the end, the tools we create to help us actually make
the chore more difficult.

I think:

the fact that it exists means that you'd have to have a *really* good
reason to write an alternative.



Right - so don't make any more than you need :-> use the ones that exist
and are actively supported.


cheers, Rich.

--
rich walker         |  Shadow Robot Company | rw@shadow.org.uk
technical director     251 Liverpool Road   |
need a Hand?           London  N1 1LX       | +UK 20 7700 2487
www.shadow.org.uk/products/newhand.shtml

A "really" good reason, or merely a "reason?"

Probably the hardest skill for sharp technical people to master is
"reuse a thing that exists, rather than roll-your-own".

Everyone clever knows perfectly well that they could
write/make/build/design a better one. Problem is, they never seem to
take into account (a) development time vs cost, and (b) debugging time.

Learning to use existing components and libraries is a really good way
to gear up your productivity in leaps and bounds.

cheers, Rich.

--
rich walker         |  Shadow Robot Company | rw@shadow.org.uk
technical director     251 Liverpool Road   |
need a Hand?           London  N1 1LX       | +UK 20 7700 2487
www.shadow.org.uk/products/newhand.shtml

By that thinking, we'd all be using betamax, riding horses, using flat iron
cut nails, hand washing our cloths on a board, and so on. There would no
robotic development.

I disagree with your conclusion. I don't think that "technical people" have
failed to master "re-use," because that is simply untrue. We re-use tons of
stuff like compilers, operating systems, etc. I think it is more of an
artistic/aesthetic drive. Many of the pre-existing tools and stuff are very
primitive, not quite the embodiment of a whole concept. Since they are
incomplete, they don't give us something "big enough" to make it worth
while, yet demand familiarity with foreign abstracts to be useful.

With regards to the player/stage code base, I'm not convinced that the
metaphors they use are the right way to go.

Non-sequitur, argument reductio ad absurdum, ...



You mean you've never sat and watched in despair as a group of
otherwise-sane engineers decide they can't use flex and bison but have
to write their own C++ class hierarchy to parse configuration files?

(Or equivalent in any other line of business).


That's a fair point. However, usually the effort required to get
up-to-speed with the existing item is much, much lower than the effort
required to debug the newly-written one, so you've got to have a really
good reason to want to write a new one. "I don't much like that one"
isn't it.



Well, if the time to produce an equivalent set of metaphors, implement
the codebase, and debug it, is low enough for you, then feel free :->

cheers, Rich.


--
rich walker         |  Shadow Robot Company | rw@shadow.org.uk
technical director     251 Liverpool Road   |
need a Hand?           London  N1 1LX       | +UK 20 7700 2487
www.shadow.org.uk/products/newhand.shtml

I don't think so at all. Isn't the idea that there is a "better way" to do
something the foundation of invention? You can't expect people *not* to
want to invent.

It depends on what you want to accomplish. A dependency on flex and bison
projects may not be acceptable.


I think it is more than a fair point. It is also about control, diminishing
returns, and the difference between an expense and an investment. Every
framework or library to be "re-used" takes an amount of effort and learning
to use. At the end of such a process you are "using" someone else's code,
it is an expense. This is not a problem if it provided you with a real
benefit, but if the time and effort to "come up to speed" with a third
party system is non-trivial, to be worth it, the framework must be
substantial enough to to make it worth the expense.

I've managed a lot of software projects and, in general, I like the idea of
buying or using instead of building, but it, like all other decisions, is
not a given. Just because something already exists does not mean it is the
best decision to use it.

The time and effort to come up to speed are real expenses, measurable in
hard cash. It adds nothing to the portfolio of the company, but it takes up
engineering time.

My best argument about this is jiffy lube or a service garage. The time and
effort "expense" to *go* to a jiffy lube plus the $49.99 for the service is
far more than the cost of changing your own oil. I can change the oil and
filters in both my cars in less than 1/2 an hour, for about $15 each.

A few years ago the alternator on my truck died. Running on battery, I drove
home, stopped at autozone, picked up an alternator for about $80 and
installed it when I got home in about 15 minutes (alternators are easy!).
The truck was under warrentee, but $80 IMHO was cheaper than driving to the
dealer, dealing with the mechanic, and then waiting or getting a loaner,
then going BACK to the garage after work to get my truck.

My investment in tools over the years has paid dividends. It is the
difference between and "expense" and an "investment"



The statement "the effort required to get up-to-speed with the existing item
is much, much lower than the effort required to debug the newly-written
one" is very debatable. Obviously, no one would re-write or duplicate
apache because it represents a HUGE amount of effort unless they had a very
good reason. Not all products are they substantial.


I'm not sure I need/want an equivalent, I like some of the features, but,
like I said, not convinced its the right way to go.

"mlw"

That's a very compeling argument. For example, in my department I do not
authorize the use of external components unless we have their source code
and we are able to jump in and fix an eventual bug in the library if
necessary (and we had to do it more than once). Of course there are certain
occasions where there simply is no alternative and you have to trust. It's a
risk management decision.

Having said that, our main product is entirely based on one thirty party
library, and if we hadn't used it, I don't believe we would have released
our product in the market soon enough to be competitive and with the quality
level we have.

Cheers

Padu

That's one reason.

The "time to market" is certainly a valid concern, but it is not the only
one, obviously.

Hey, I'm not saying one way or the other, buy, use, or create - these are
important considerations for any project. My point was that "buy" or "use"
are not always an effective use of engineering time if the technology you
intend to use has a greater learning curve and cost than overall benefit.
Sometimes a higher engineering cost to develop a technology reaps rewards
than using or buying can not.

I remember I was working on a project a few years ago and the management
wanted to buy a recommendations system. It cost us $400,000 plus consultant
time, and it took two months to implement. (I was against the purchase from
the start) A year later, they wanted ANOTHER $250,000 to maintain our
license. This was a startup DOT COM company, the previous year we had
*lots* of money, that year we were struggling. The previous management had
been fired (thank <insert deity here>), I said I could write a system in
two months that would be faster and free. So, using my original design
notes generated prior to buying the $250K system, I embarked on my
development. I had a working prototype in a couple weeks to test the
algorithms. I had a working system a month after that.

I have since designed a similar system on my own and sell it, not, alas, for
$400K

The DOT COM company went out of business, but I firmly believe that paying
close to half million dollars on an "always buy before create" strategy
helped kill it. I won't say the the vendor cheated us, because they dealt
mostly with huge retailers to whom their fees are meaningless. I firmly
blame management for not doing a proper cost/benefit analysis, relying,
instead, on a dogma of "buy before create."

what does arguing have to do with "standardized distributed robotics" ?

You asked for opinions.  You got some, now you are arguing against
them.

If your ideas are so good, put them into code, post it here, and ask
for *alternative* ways to code, optimize, algorithms, APIs, etc.

Take what you think is good feedback, integrate it into your code,
and be happy and productive.

Rich

Why are people so adverse to debate? I am not meaning to argue against them,
per se' I am discussing the relative merits of them. You mean you NEVER
discuss ideas? How do you flesh out a concept? How do you design anything?


I have a web site and all my robot code is public and GPL.
(www.linuxpcrobot.org) What's your point?


I'm sorry, that's just stupid. Debate and discussion are the foundation of
learning. It is where both sides of the debate come to a deeper
understanding of the topic.

This thread, for instance, had NOTHING to do with my "Standardized
distributed robotics," it had to do with Rich challenging the notion that I
should try to come up with a system as one already existed.

He mentioned player/stage. It was a very good suggestion. I went there, read
about it, looked into it, and came to the conclusion  that I didn't think
it was beneficial. I replied with my reasons, and so on.

I hope Rich, while possibly disagreeing with me, at least had fun in the
discussion.

Yep. And I still think you're wrong :->

cheers, Rich.


--
rich walker         |  Shadow Robot Company | rw@shadow.org.uk
technical director     251 Liverpool Road   |
need a Hand?           London  N1 1LX       | +UK 20 7700 2487
www.shadow.org.uk/products/newhand.shtml

Actually, don't you think there are slightly more options than simply
"right" and "wrong?" There are multiple options that do not clearly qualify
as "wrong." Just as there are multiple options that do not clearly qualify
as "right."

Obviously, I don't think I am wrong, but I can see how some people wouldn't
choose the approach I am taking.

I looked at player/stage and I like the amount of support it has, but I just
saw too much abstraction and not enough modularity.

Much of the design work that I need to do is the sort of stuff I do
professionally, so it isn't a huge leap for me.

Oh yes, but that spoils a good argument.



Have you looked at TIPC:

http://tipc.sourceforge.net/

which is now in the linux kernels, and so *might* be useful for
providing distributed robot data structures...

cheers, Rich.

--
rich walker         |  Shadow Robot Company | rw@shadow.org.uk
technical director     251 Liverpool Road   |
need a Hand?           London  N1 1LX       | +UK 20 7700 2487
www.shadow.org.uk/products/newhand.shtml

I agree. I think all this is a little "too much". Have you gotten
the $500 robot to move yet? I've tried to follow other
discussions on "distributed networks" and most lack any kind of
practical reality check (but really good for some "hanger flying"
when things are slow).

The $500 robot has been moving for some time. The code available on the web
site has *always* made a robot that could move,

The $500 robot, if is anything, is based on purely practical implementation
of theoretically correct concepts.

One of the reasons I don't like the player/stage project is that the robotic
systems seem more theoretical than practical.