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?

Reply to
mlw
Loading thread data ...

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

cheers, Rich.

Reply to
Rich Walker

"mlw"

So if I understood right, you want to expand the framework you're using for joystick control to any module right? Something like CORBA or DCOM? IMO, it's a nice concept, but how will you cope with network delays and inherent unrobustness of wireless (or even wired) networks? If you're looking for ideas on how to set up your API, I believe I've heard before someone implemented CORBA for embedded systems and real time. That thing is generic and multiplatform for sure.

Cheers

Padu

Reply to
Padu

Well, I've done a lot of service programs. The networking stuff is fairly trivial.

It had not considered network latency all too important as I think it is fairly obvious that time critical stuff be kept in the pseudo-realtime loop. Now that you mention it, however, it may be an interesting problem.

IMHO, CORBA is too big and bulky. I was thinking of something very much smaller and more efficient.

Reply to
mlw

Got a URL?

Reply to
mlw

playerstage.sourceforge.net

Gazebo is the 3d simulation component;

formatting link
is an intro

cheers, Rich,

Reply to
Rich Walker

"mlw"

I agree, and I that was the discussion I had with this friend of mine, but according to him, this "embedded CORBA" is really lightweight, and his department at Northrop-Grumman (if I recall correctly) was applying it with success. I don't have any more specific knowledge on this embedded CORBA thing, therefore I cannot support it neither bash it. It is on my list of "things to investigate" though.

Regarding latency, I agree, the near-real-time stuff will be on tight-fast loops probably on microcontrollers, but even for the higher level stuff (usually processed in a PC), the network delay may be unacceptable. For some other things it may be ok.

For example, in one of my prototypes, I had my mini-itx board constantly (every 2 seconds) reading an ini file to setup internal parameters. Because I had wifi on the mini-itx, I was changing the ini over the net with my laptop and it served the purpose of my test (not having to stop the rover, connect monitor and keyboar and then change its parameters), but I wouldn't rely on a wifi link to do any other thing that demands a minimum of time response.

Cheers

Padu

Reply to
Padu

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.

Reply to
mlw

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.

Reply to
Rich Walker

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

Reply to
mlw

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.

Reply to
Rich Walker

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.

Reply to
mlw

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.

Reply to
Rich Walker

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.

Reply to
mlw

"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

Reply to
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 ), 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."

Reply to
mlw

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

Reply to
aiiadict

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.

formatting link
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.

Reply to
mlw

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).

Reply to
Si Ballenger

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.

Reply to
mlw

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.