Call for ideas

For a number of reasons, I am in the process of re-designing a lot of the $500 robot software. Most of the pseudo-realtime stuff will remain for motor control, but it will be isolated in its own OS level task.

What will change is the structure of the control system. In another thread, "Standardized distributed robotics," I talked about how adding a networked joystick started me re-thinking the plumbing.

One poster suggested "player/stage." To tell you the truth, I looked at it and was not very impressed. I think the abstraction model is too low level. There were too many API functions. It seemed like the learning curve exceeded the benefit.

Another person also mentioned CORBA or real-time/embedded CORBA, I'm not so sure I like that either. CORBA has always seemed bloated to me, but then again, maybe I'm old school, who knows.

But here's what I'm thinking, and I bet you micro-controller dudes will like it too:

The system will be message based and object oriented. Thhere will be two types of objects, senders and receivers, Each receiver object will have a single message handler and messages will be standardized and extensible. The best analogy I have is the "DefWindowProc" in the MS Windows API. A sender object may be a sensor or input mechanism.

Communications between objects will be done via "channels" a channel can be ethernet, USB, serial, function call, or even carrier pigeon. One interface class per type of channel should work. USB may be a bit problematic if we start defining messages that can have variable length packets, but that shouldn't be a problem at first, and all we need to do is chunk out the data.

Each sender object will send its messages to the central core "robot." Each receiver object will be layered upon the main "robot" object . A robot object defines the core of what a robot does. A robot object can be library, shared library (or DLL), or a process.

Take a keystroke sender object. It will be implemented as its own process or thread. It will open a channel to the main robot object. It will wait for key strokes from the user. When meaningful keystrokes are sent, they are decoded and made into a set of messages to be sent to the robot. I.e. if the user presses "f," this could mean forward, so a ROBOT_MOVE_FORWARD message can be sent to the robot. (Yes, very simplified for discussion)

The main robot object may, or may not know how to deal with this message. If it does, it will act, if it does not, it will return a failure code.

The "main robot object" is a generic receiver that can be replaced by chaining the API. The default robot object may do nothing, but your wizbang robot object may know how to move. You call into the core and replace the default robot object with your robot object. Then your robot will get all the calls from all the various sender objects. A later module may chain your robot object and further augment the robot "whole."

Other receiver objects could be implemented, but I'm not sure that is necessary. Maybe things like encoders and other sensors may also be receivers, that's one of the things we should think about.

For you microcontroller dudes, this now works out nicely. Suppose your robot is sitting on a USB port. A USB channel can send messages to your robot receiver object. As long as you respond to the messages as defined, it makes no difference how or where your robot is implemented. As long as there is a channel to it, and you implement a message handler, you are a robot.

All in all, this is totally location agnostic, and creating functionality is simply responding to a set of messages. Your robot could be a simple radio link microcontroller turtle, but have the brains of a huge super computer and be coded in exactly the same way as a big stand alone robot with an SMP motherboard.

What do you think? Is anyone interested in working on the development of it? I have a networked CVS repository that I can setup.

Anyone?

Reply to
mlw
Loading thread data ...

...

Don't get me wrong. What you propose could be useful. However, methinks you think too much.

USB channel, ethernet channel, SPI channel, RS232 channel, ... Extensible object-oriented sender/receiver protocol... It was big goals like these that resulted in CORBA (with the help of a standards committee).

For most of my projects, the hardest code has been getting channels set up. Picking a data transmission protocol has usually been easier, and optimal choices tend to be application-specific. In addition, the hardest conceptual task with multi-body systems are often related to timing and synchronization -- items which are very application specific.

General-purpose systems tend to suffer this fate. What's your proposed API?

What are your goals? Maybe it would be best to simplify your design into a routing protocol across different channels, and then provide a default transmission/datagram implementation on top of it, a la TCP/IP. This is a flexible model with a fairly simple API, and it has been wildly successful. That way users can custom-tailor the exact messages being sent without having to change your underlying system or use a restrictive API.

Most of all, have fun with whatever you do.

Daniel

Reply to
D Herring

Story of my life.

Actually, USB, ethernet, I2C, RS232 are all pretty much done in some form. I am a consultant and I do a lot of this sort of stuff.

That is sort of one of the things I think needs to be addressed, keeping functions that should be "grouped together," together.

Well, general purpose solutions for general implementation methodologies tend to grow to be huge monsters. That should not be confused with a general purpose solution to a specific problem.

Actually, the design I proposed is fairly simple. I do, as it happens, have a transmission/datagram implementation already. (I have actually done something very similar for high speed web sites using PHP)

The transmission/datagram protocol can be formatted and exchanged over the channels to be implemented.

Well, that's "exactly" what was proposed.

Absolutely, its not as if I'm being paid. (Unless someone wants to pay me :-)

Reply to
mlw

Don't you suppose this core is going to become a bottleneck as you get more ambitious? After reading this I started musing about a peer-to-peer scenario; your core could manage these connections, but shouldn't have to dispatch every message from every sender if a direct channel exists between a specific sender and receiver. If such a channel can be made then the core only has to be made aware of it.

Also, do you anticipate situations where a single sender might broadcast to multiple receivers?

But maybe both of these thoughts are overkill. I have no experience say one way or the other.

- Owen -

Reply to
Owen Lawrence

The problem with a "direct channel;" is that you lose control over the path of a message. The bottleneck issue is a concern, but, truth be told, if the software is done right, then a bottleneck would be hard to do. We are still talking about something moving in the physical world, and that is inherently slow. The objects themselves should deal with time sensitive matters.

The design, for simplification reasons, is not 100% distributed. The robot core needs to be a single computer. The platform, sensors, etc. can be anywhere, but the main controlling processes are assumed to be on one machine.

Hmm, do you have an example of why this would be necessary?

Well, I'm aiming for something usable, small learning curve, and extensible. Over complication for unlikely flexibility is almost always a problem.

Reply to
mlw

Use IP Multicast - it's what it's for.

I started drawing up a protocol to do this a while ago, but got bogged down in other things. It's probably in our CVS somewhere...

cheer,s Rich.

Reply to
Rich Walker

"mlw"

Reset. In my robot I'm using a custom made protocol over RS485. RS485 is multidrop per nature, and when the master (the PC) sends a message to node number 255, everybody listens and do whatever the master is commanding. So far the only message that I'm broadcasting is reset, but there may be others.

Most of the protocols I've studied before implementing my own (Robin, Modbus, JAUS) foresee broadcast.

Cheers

Padu

Reply to
Padu

If you're processing images from a camera you're moving a fair amount of data. Depending on what you need to do with that data it could easily be time-sensitive. I assumed your main controller would do that processing, so how would you distribute such a function?

Seems reasonable.

Maybe not necessary, but desirable? Padu gave a good example. Anything I come up with is more hair-brained. Like controlling multiple robots as a hive. "Execute pattern F(i)" where i is the index of a particular instance, and each instance knows how F varies for its particular value. Or using the output of a single camera to feedback for overall goal setting, obstacle avoidance, and logging (to produce a video result) as three separate processes. Of course if you're not scaling up to the n'th degree then there's not going to be any need to optimize the daylights out of your architecture. But hey, you asked. :)

Absolutely. Absolutely!

- Owen -

Reply to
Owen Lawrence

Well, in the object model I am envisioning, some "camera object" would do the processing. I hadn't envisioned a camera interface, per se' I envisioned small information packets, 2 maybe 3 integers max. things like key presses or motor speed/position information, but shuffling around camera data is a whole different problem. It is a valid point to think about.

Is it reasonable to have some camera object so abstract? Something to think about for sure.

To a point, I'm not totally happy with it.

Sending multiple packets to multiple objects implies either asynchronous operation or either ignoring response values or aggregating them in to an array or something. I'm not opposed, but I have to ask, "is it in keeping with the core design goal?"

I actually love the idea, but there are a lot of very good general purpose distributed control systems like PVM and MPI. I originally considered MPI as the basis of the robot, and am not 100% convinced I shouldn't focus on that is the communications core.

MPI has some VERY COOL features, a lot of which I would be duplicating. Damn!! Now I am thinking about MPI.

You know, it makes a lot of sense too. The university environment would probably deal with it better. I need to think how to make the master/slave model work for this, we'd still have messages. Oh, bother.

Yes.

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.