Pierre,

Basically, there will be a lot of modules, e.g sensor systems, controller, mode of communication, motion systems, power supply, I/Os, etc. And for each system, there will still be subsystems.

this is a way to classify the possibilitie universe (sensor, controller, power suply). But a lot of other way can be imaginated as actionors module set up with (controller, power supply etc...).

Without search a basis which permit an optimal design, I am sure that can find a low nimber modules baisis which can permit to solve a big range of problematic. This is the  subject of this debate.

All robots require some sort of perception from the real world, some behaviour to react to it, and ultimately some methods of achieving this reaction.

This means that you probably best to have a module to takes input from sensors i.e. level abstraction, and feature detection. Followed simply by a reaction module, which provides all the "smarts", then a motion module.

Depending on how its written, code reusability is an important aspect that needs to be examined in more detail. For a practical example, the Nubots code repository (see Link), has many different applications, for many different robots (different hardware abstractions), and modules are selected and included in CMAKE system for C++.

https://github.com/NUbots/robocup

So you say Motion+(sensor+A.I)+Tools... and that this problem go with the C code object design. Interresting. Thank you for this answer.

Dear all,

• I would start with thinking of software abstraction rather than hardware before actually setting up a list of sensors or actuators. This enables to abstract from heterogeneity of the robot implementations and functionality. It also would enable to abstract from particular programming techniques, languages and implementations.

I see that most part of you think group basis from the hardware parts as sensor, motors... Even the way to start from a software abstraction take root in an hardware analysis. what is about a functional basis (not inside fonction but out function)? what about the biomimetism?

Maybe a we could discover new way to imagine our hardware system by restarting our robot conception from a design which is not linked with the actual technologies.

I think that's because robots are typically designed to do physical tasks in the world, and without thinking about thinking about the hardware, you can't constrain the possible ways to do the tasks or understand the environmental context in which they have to be done (and that environmental context and how your robot interacts with it is usually the thing that causes your beautiful theoretical solution to break down).

Biomimetics is almost an orthogonal problem -

     first, low level biomimetic systems are even more dependent than most robots on the specific details of the hardware involved because they are so much more dependent on the details of the system's relationship with its environment, and

     second, high level biomimetic systems can be implemented as part of the software/decision-making component, along with any other approaches to that element, and so are just one more tool available to control the robot's behavior within the context of its physical structure.

With respect to the functional aspect, I have been thinking about ways to generalize task descriptors lately.  If you want more information about the task definition problem, I'd suggest looking at the verification and performance evaluation research - the environment often drives the hardware (you wouldn't build an underwater robot for Mars), but the task drives the performance evaluation.

But if your real question is, why can't we think about designing the physical robot based on the desired task or function rather than based on available hardware, then the answer is that of course we can.  It's just frustrating (and often unproductive) to design an ideal robot in your head that you can't build or test and that therefore won't get the job done.  The entire field of robotics is built around trying to create a capable robot by compensating for inadequate sensors, inadequate actuators, inadequate perceptual processing, inadequate understanding of the environment, and inadequate ability to design software that actually does what we really want it to do.

this approach is horizontal. If everything is linked to the environement and the task in the present you can have only horizontal technologie improuvement. By this way the capitalisation of the technical power is not optimized. When I speak about biomimetics, I speak about it more as an other technologie to make a more large point of view about the technical possibility.

For me the problem is also about the human psychism. People are conditionated to see always the same solutions for the same problems. But the reality is much more complex.

Robotic revolution could follow the computer evolution if it would folliow the same devellopement. Cybernetic, turning device was design as theoritical ideal things before hardware with the performence we know apears. I think it need to be the same for robot else they will continue to be simple curiosity in the technical world.

Hi

You can think a module as a complete actuation, sensing and control.

If you are considering an industrial manipulator, then you need,

a model for each category of rotational joints (waist, elbow and shoulder joints)

a model for each category of prismatic joints (orthogonal and coo-linear)

an End effector module (male-female connection)

This mean you need 5 modules for the joints and one for the end effector.

This is an interesting discussion.

As a rule, I would see the basic robot as a motion control system.  That means the basic elements for control are as they always are:

• sensing (= joint position / speed / torque / ... measurements)
• computing / control law (= determine your actuation signal)
• actuation (= set the computed actuation values, e.g. currents on motors or similar)

Of course, this needs to be embedded into a conceptual architecture that is actually a basic robot.  To do this, I suggest the modules

• control (= the above structure)
• safety (= functionality to protect environment incl. persons)
• power (= supplying, controlling, switching; stationary vs. mobile; ...)

At this level, of course, there is still no mention of any purpose or application-related aspects.  To add that, I would suggest the following points:

• task (= description of actions to be executed)
• constraints (= what capabilities does robot have, e.g. force control, gripper type, etc., and what capabilities are required by intended actions; also, environmental constraints, obstacles, coordination with other ongoing actions etc.)
• quality control (= condition handling concerning the results of the action ranging from simple signaling and error handling to complex automatic recovery from exception conditions; also includes possible communication to other instances, machines, people, ...)

I am not sure that the above makes sense in all of the wide world of robotics, but in an industrial environment it is a reasonably useful scheme. 

After each of the above areas is detailed to a reasonable degree, one can start looking at the embodiments in HW and SW.  But I am assuming that your question might have been more directed at the conceptual level, am I right?

Best regards,

Björn

yes, it is a conceptual question. Thank you for your answer. Well, I like this detailed conceptualisation in objets with caracteristics. My aim is to see differrent cultures of the robotic accross this and maybe find a concensus or just new ideas to permit an exponential robots developement just as for computer.

it is interresting to see differrent basis to have new idea. Unfortunatly, I have very few new basis conception. Everything turn around power/control/motion/interphasis/mechanical links. But at least I have this first list and thank you all for this :-). I am sure that it exist a sort of transvers way to analyse the designing of a robot. In a computer programme for exemple you can use a function to build an other function which can do equivalente work. Imagine for exemple a module of power and if you assemble two you get a two time more power module : power+power=2power. This is simple actually, but imagine now something like : (power+control)+(power+control)=(motion+interface). Well it can look meaningless but it is illustrate what I am searching as an other sort of robot basis. special basis with totally differrent and new rules of assembly with new possibilities...

If you add a chassis module, this will provide strength, ease of assembly and more robust connections between the modules. Think of it as a skeleton with some internal nervous system. Also limit your modules to about 10. If you go beyond that, expect performance degradation.

well, yes. maybe a special module which permit to create a skeleton around other modules assembly could permit to change the property of their assembly. Now I just need o find how to generalize the concept of skeleton around more discipline and not only the mechanical. thank you about this idea.