Standardized distributed robotics

As I am working on my robot, I had sort of a flash last night.
I wrote a network enabled joystick program that could use a joystick
connected to one machine to control a robot over a wireless (or wired) network.
Before it is really clear what I'm thinking, let me explain the robot system I have so far, it is a pseudo real-time cooperative multitasking system that should be portable, but it is currently running under Linux.
It has one main high priority loop that uses task structures to call into "handler" routines. After all the work is done that needs to be done per iteration, it calculates how long it should sleep, then loops again. It works pretty well, and is similar to stuff I did long ago in my embedded days.
There are basically two classes that are important, tasks and event handlers. Tasks get called periodically. Event handlers get called by tasks. Event handlers may be shared amongst multiple tasks.
The robot program uses multiple tasks, with one event handler. The main event handler handles key strokes, error conditions, etc.
Using this structure, I simply created a network listening task that waited for a fixed length packet from the network joystick program, from which it created a "event" and passed it along to the main event handler.
Last night, I started thinking, I was stupid, I should have made the network task far more generic and written it so it could accept more than one connection, have bi-directional communication, as well as handle any sort of event.
So I am embarking on doing this, as I think about it, if I publish the event specification structure and format. Try to make a fairly standard API library, it should be possible to fully distribute the functionality of the robot over multiple computers fairly easily. This should be lighter weight than something like MPI or PVM, and be able to have built in error protection needed for robotics.
Any thoughts? Anyone have any suggestions on what the API should look like?
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Player/Stage already has network-transparent distributed robotics built in.
cheers, Rich.
--
rich walker | Shadow Robot Company | snipped-for-privacy@shadow.org.uk
technical director 251 Liverpool Road |
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Rich Walker wrote:

Got a URL?

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

playerstage.sourceforge.net
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 | snipped-for-privacy@shadow.org.uk
technical director 251 Liverpool Road |
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Rich Walker wrote:

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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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 | snipped-for-privacy@shadow.org.uk
technical director 251 Liverpool Road |
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Rich Walker wrote:

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

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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 | snipped-for-privacy@shadow.org.uk
technical director 251 Liverpool Road |
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Rich Walker wrote:

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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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 | snipped-for-privacy@shadow.org.uk
technical director 251 Liverpool Road |
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Rich Walker wrote:

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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
"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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Padu wrote:

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."
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
snipped-for-privacy@gmail.com wrote:

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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Yep. And I still think you're wrong :->
cheers, Rich.
--
rich walker | Shadow Robot Company | snipped-for-privacy@shadow.org.uk
technical director 251 Liverpool Road |
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Rich Walker wrote:

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.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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 | snipped-for-privacy@shadow.org.uk
technical director 251 Liverpool Road |
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
wrote:

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).
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Si Ballenger wrote:

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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.