Architectural Elements

[Sienna]

As I said at some point in the past, I want to discuss the architectural components of the TRS.

I see the following:

Input Library:
Publish Only. Reads voltages, etc, from hardware.

Sensor Library:
Subscribe to input library. Publish to object model. Interprets input library into higher level semantics, and sends them to the object model.

Output Library:
subscribe only. sends voltages etc to hardware.

Movement Library:
Subscribe only. Gets publishes from the object model, and turns them into actuations using output library

Object Model:
Pub/sub: Keeps track of the state of the robot only. No logic. Recieves updates from sensor model, control library, etc. Gives updates to many things.

Algorithm Library:
'remote procedure call' only. Basically, a giant math library, processes as called.

Control Library:
pub/sub. Active control library. Calls algorithm library as needed for support. Continuously running in background, providing planning, etc.

Render Library:
sub only: Listens for updates from the model, displays them.

User Library:
Controls interactions with the user

[Matt]

Object Model:
Pub/sub: Keeps track of the state of the robot only. No logic. Recieves updates from sensor model, control library, etc. Gives updates to many things.

Algorithm Library:
'remote procedure call' only. Basically, a giant math library, processes as called.

Render Library:
sub only: Listens for updates from the model, displays them.


Right, all normal pieces.



Input Library:
Publish Only. Reads voltages, etc, from hardware.

Sensor Library:
Subscribe to input library. Publish to object model. Interprets input library into higher level semantics, and sends them to the object model.

Output Library:
subscribe only. sends voltages etc to hardware.

Movement Library:
Subscribe only. Gets publishes from the object model, and turns them into actuations using output library


The SCL takes care of all this. I'm not sure why you have them all broken out here.



Control Library:
pub/sub. Active control library. Calls algorithm library as needed for support. Continuously running in background, providing planning, etc.


This sounds like something that falls into the lap of individual developers. How one wants to architect or control their bots is entirely up to them. I won't even begin to assume I know how to create actual architecture that everyone out there wants to use. This is the reasoning behind the TRS being modular components that anyone can use their own way. (That being said, any normal robot project will have these items you are listing.)


User Library:
Controls interactions with the user
Again, sounds like something that is up to an individual developer and not in the TRS.

I think this falls closely to your query in the other thread about trying to understand the goal of the TRS & "who" the tools are for. We are stopping short of the line in the sand that goes from core components to actual system/environment. The TRS digs in right there, deep :) It stops short of everything a system needs, that's on purpose. As soon as we cross that line we get into trouble.

Right after that line I can pretty much guarantee that there will be a battlezone of philosophies, tools, architectural approaches, application focus, etc etc etc. It's kinda like us throwing a few swords and shields into the Colosseum and watching the developers beat each other up. It will be fun :) And that is the point, everyone else should be sprinting across that line, and that includes people here working on the project, but the TRS, like a kind old grandma, will sit on that line and watch the children play (maim each other.) :)

[Sienna]

>>>> The SCL takes care of all this. I'm not sure why you have them all broken out here.
To me the SCL sounds like to big a library to work with. But then, that doesn't stop us from subclassing the heck out of it either.

[Alex]

To me the SCL sounds like to big a library to work with. But then, that doesn't stop us from subclassing the heck out of it either.

exactly:) This is going to be probably the largest part of the TRS. It's going to consist of one HUGE library, with many classes and inherited classes. Not quite sure what that class diagram will look like though...

[Matt]

You two may be right. I don't have the complete architecture for the SCL in my head yet so I'm not sure how it's going to work. I just know that I want all those parts to be under that single umbrella to achieve the goals laid out earlier. I'm one of those very stubborn managers that will send engineers back into the war room over and over with "figure it out, you aren't there yet." ;) Just ask Alex :) The best part is when they come back grinning ear to ear and want to show you the magic they just performed.

We can figure out how to architect an SCL that doesn't require the development environment to manage hardware communication code. I'm certain of it.

[LinuxGuy]

exactly:) This is going to be probably the largest part of the TRS. It's going to consist of one HUGE library, with many classes and inherited classes. Not quite sure what that class diagram will look like though...
How about smaller library files separated by type of item? There could be one for sensors (input), motor controllers (output), servo controllers (output), servos (such as Open Servos, standard servos, etc) and others.

There could be a master map file that just includes the map files of libraries that are available. Indexing into larger libraries can slow things down. Having smaller 'catagory' libraries also allows one to not have libraries they may not need, and the master map file can be edited to remove libraries not present. I would have a name.lib file for the actual library and a name.map (or .xml or whatever) to map what is in that library. We might even have smaller versions of libraries we make to include only what we need - this allows for limited storage systems.

8-Dale

[Matt]

I like the way you are thinking Dale :) This thread is turning into a good SCL discussion now, maybe we should push these posts over the the SCL thread?

[LinuxGuy]

I like the way you are thinking Dale :) This thread is turning into a good SCL discussion now, maybe we should push these posts over the the SCL thread?
Thanks. :veryhappy::veryhappy:

I think it really does belong here, but there is going to be some overlap between this and the SCL discussion. I think the SCL discussion should just be about what is in it and how that is managed and accessed. If you like what I laid out for the architecture of the SCL and everyone else likes it, that part can be considerd done and we can move on to the actual guts of the SCL.

8-Dale

[Matt]

If you like what I laid out for the architecture of the SCL and everyone else likes it, that part can be considerd done and we can move on to the actual guts of the SCL.


I like the direction you were taking, but we need to have everyone do a lot more discussing before anything is finalized. I'm not even following everything you said yet! LOL

I do think your SCL proposals need to get posted over in the SCL thread though. I'm not sure what's left to discuss here. The architecture is TROM, SCL, rendering tool, & AL. All other items fall outside the TRS. Am I missing something that is still in the air?

[LinuxGuy]

I like the direction you were taking, but we need to have everyone do a lot more discussing before anything is finalized. I'm not even following everything you said yet! LOL
Oh, I definitely agree. We have to have a consensus amongst the group. I definitely don't want to be seen as trying to push something through without input from the rest.

I do think your SCL proposals need to get posted over in the SCL thread though. I'm not sure what's left to discuss here. The architecture is TROM, SCL, rendering tool, & AL. All other items fall outside the TRS. Am I missing something that is still in the air?
OK. It will provide for more discussion and a great intro into working on the guts of the SCL.

8-Dale

[Adrenalynn]

Why is breaking them into so many libraries useful?

That's a hypothetical to the group. I can think of plusses and minuses myself. If it's too monolithic, we're carrying weight into every app that we don't need. If it's too spread out, no one will be able to figure out what they need to include. Anyone remember early C implementations [I'm thinking like Whitesmith C] where you had to include and link everything in the darned world every darned time, just to print "hello, world" on stdout? There's no issue with us hurting any windows programmer's feelings with it being too monolithic. [points at dotNet libraries, and even worse, at the MSDN tree]

[LinuxGuy]

Why is breaking them into so many libraries useful?
This allows the SCL to scale down to smaller, more resource limited, systems. It also allows the SCL to be easily tailored to each individual system and use. Even an x86 system on a robot can end up having limited resources, by design, or as a function of the hardware. :happy:

That's a hypothetical to the group. I can think of plusses and minuses myself. If it's too monolithic, we're carrying weight into every app that we don't need. If it's too spread out, no one will be able to figure out what they need to include.
The way the SCL is broken out makes a big difference. If done like I describe or a similar way, it's sensible and with reasonable library names, it will be easy for advanced users to find where everything is and carve the SCL into just what they need.

8-Dale

[Alex]

How about smaller library files separated by type of item? There could be one for sensors (input), motor controllers (output), servo controllers (output), servos (such as Open Servos, standard servos, etc) and others.I think you're spot on with this Dale, and I always thought about this myself; I just didn't know if/how it could be accomplished. I know in .NET there are things called assemblies and namespaces (http://msdn2.microsoft.com/en-us/library/ms973231.aspx) that allow you to "sort of" do this, but I don't know enough about C++ (we're agreed that this is the language for the TRS, right?) has this capability.


If it's too monolithic, we're carrying weight into every app that we don't need. If it's too spread out, no one will be able to figure out what they need to include.Absolutely! The last thing we want is something that people can't even use because it's too difficult to figure out what pieces they need. But, we also don't want a huge library (such as I mentioned previously:rolleyes:) that results in too much overhead (hmm... where company can we think of here...) of the system thus creating a scenario that requires way too many resources in order to run.

[Matt]

A diagram for the masses. :P

Starred items are the ones we are building. This chart should help people to understand where these components reside in the bigger picture.

The "other" boxes in the Modular System Building Components area would be things like Voice recognition modules, vision modules (roborealm), path planning/navigation tools, anything else you want to plunk into your system to make it work. These are software tools you can build or buy.

The "other" boxes in the GUI area would be things like advanced clickable rendering tools (click a leg and pull on it and it actually broadcasts this to the TROM which moves the robot), GUI Wizards that help configure a brand new robot out of the box (walks you though calibrating the joints and such) and so on...

The IDEs are the top layer, wrapping up tools in the lower layer or possibly completely built out as proprietary systems by companies. Here you would find things like motion editors, tutorials, very shiny graphical interfaces, etc. Think LEGO mindstorms or Bioloid or MSRS or URBI.

Hope this helps everyone :)

240