Modular morphology: defining interfaces for Poppy

Poppy has a modular morphology. This modularity is expressed with all technologies involved. For the mechanics, we use 3D printing techniques allowing to produce quick and low-cost parts. For the electronics, we designed an electronics board based on Arduino allowing to easily plug new sensors. Finally for the software, we built a library using an modular architecture both for the low-level thanks to I/O controllers and for the high-level with primitives paradigms.

This modularity allows for quick experimentation over morphological variants. This functional modularity seems to be enough to allow a wide range of scientific experiments with Poppy and hopefully have real a scientific impact. However, to have an actual impact in the open source community, the technological modularity is essential.

Modularity

In the software, modularity refers to the manner in which a design is decomposed into different “modules”.

It is based on the notion of interdependence within modules and independence between modules. This concept involves two related ideas: the need to allow work on a given module to be carried out without affecting other modules in the design, a concept known as “loose-coupling”, and the need for well-designed “interfaces” between these modules [ref].

The concept of modularity appears as a fundamental property in the the open source software collaboration. Indeed, code modularity allows the overall project to be divided into much smaller and well-defined tasks that individuals can tackle independently from other tasks and without affecting other aspects of the program.

Thus Linus Torvalds, emphasized modularity as a design criterion early in the development of Linux. Indeed without modularity, it would be improbable that contributors could understand the whole design architecture to have a relevant contribution. It would be difficult to add new features or fix bug without affecting other part of the design. Linux needed to be modular to attract and facilitate a developer community. Code modularity allows partitioning of work among a global pool of developers and facilitates the recruitment of new contributors, as it reduces their learning curve to a subset of modules rather than the entire project [ref].

The hardware modularity is not as developed as the software one because it is not possible to abstract the interface. Hardware components have a global shape, connector type and position, and so on, which make difficult to design generic interface.

Yet it would be very useful for a robot platform such as Poppy, made to explore/hack/develop robotics, to easily switch between different technological solutions. On one hand we could test in minute completely different morphologies (new pair of legs for example). On the other hand, and it is maybe the most important point, it would permit to the community to develop their own version of any Poppy’s mechatronics systems without having to consider the whole robot structure. By Poppy’s systems, I mean legs, feet, arms, hands, torso or head.

Splitting Poppy in sub-modules

I think a first simple step toward more modularity could be to split Poppy into sub-modules interchangeable so, for example, the design of the arms does not depend on the the design of the torso and vice-versa.

I would like to suggest these sub-modules:

  • Head (neck + head)
  • Torso (abs, spine, chest)
  • Arms (both from shoulder to hands)
  • Legs (both, include pelvis, legs and feet)

Thus it enables a large wide of reconfiguration of Poppy and people are not limited to evolution of current design but can create completely new morphology while being compatible with other Poppy’s modules.

For example we could have several locomotive system such as two legs, one jumping leg, wheels, 4 legs (centaur) Alion’s legs, or just a static base:

Following the same idea, we could have torso with different number of degree of freedom (0 Dof, 2 DoFs, 5DoFs) or even allow to add more arms, so you can create a Saraswati version of Poppy (©Gerrard Berry).
Yet all these torso versions should be compatible with all version of legs and arms.

Where should we actually split ?

While the overview of the module seems clear for me, the details are still a bit muddled. A typical example are the arms, the functional distinction is not clear. In the current version of Poppy, one of the arms motors is in the torso. On a functional point of view, it should be integrated in the “arms” sub-modules, but on a practical aspect it implies you cut a huge part of the torso and will greatly complicate the interface design.

Another point is the pelvis/torso interface, on one hand, it would be simpler to consider the abs motor as the interface, on the other hand, we do not want to enforce having an abs motor for other submodules…

So there are still questions and I would like to open the discussion about this point: Where do we actually cut the robot in sub-modules ?

Limitations

These kind of submodules still raise a limitation because the interface has a fixed size, which will constraint the overall size of the robot elements. It should be possible to create a bigger robot, maybe until 120cm but it will be difficult to have a smaller robot than 60cm while keeping the same interface. Yet it already releases constraints over the Poppy design, and in a second time, an extension could be to have scalable interface.

This is a good idea, especially if we want to make the Poppy project a concept for building and hacking several types of robot. Poppy Dog, Ergo Poppy, as we discussed earlier.

The main problem is indeed the interfacing between modules, both hardware and software:

  • The hardware should be easy to swap. It must have robust electrical connection (the minimum is power + a robust and fast communication port), And we may need a small computational unit in each submodule.
  • On the software side, it is still fuzzy to me. There is a lot of devellopment to do before seeing any improvements in the control of a Poppy and other robots. Morevover each module will need its own computational unit (How do you handle automatically the motors ID, etc).
  • Finally you have the problem of multiple batteries (you may have one per submodule) that should distribute the power to all submodules without running into problems, but that is a later goal.

My opinion is that full modularity should not be a top priority right now but it is something to keep in mind for the design of the next generation of Poppy, especially during the design of the new servos. The first step to me is to design an easy way to plug motors and 3D printed part together, because changing parts of Poppy takes too much time and effort currently. Only then we can think of making Poppy really modular.

@Nicolas should have a lot to teach us about ways to do modular robotics.

There is also this recent project at IROS this year: http://spectrum.ieee.org/automaton/robotics/diy/fable-modular-robotics

I agree with this. Taking the knee as example. There is one motor. I imagine an universal interface between motor and lower leg, and another one with an interface with upper leg. If the motor changes, only two parts have to be redesigned. The upper and lower legs can be designed independantly (it may have more versions than motor interfaces)
Maybe the risk is to increase the weight and the robustness to fall.

Concerning modularity, I think the way to cut shall be functional:

For instance for dynamic walking, you need two legs, one pelvis and one heavy torso. But no head and no arms. For my future expiriments, I have a biped structure with tunable dumbbell on the torso.
But if someone works on arms and wants to connect to my legs, I will remove the dumbbell torso.
I think working on pure module is not possible.
Idem for the arms, only one arm is useless, and I should say, two arms are also useless. The trio arm1, arm2, shall give a good concert (that is the big advantage of Poppy). But without legs, the arms are OK.

Maybe the modularity can be restricted to upper body vs legs.

The perfect modularity of a robot is my dream for many years. It’s a really difficult way but improve massively the possibilities and developpement speed when the base structure is done.

Some insects in nature are “modular”. The stick insect for example, if you snatch an antenna of a baby stick insect it will have a chance to be replaced by a leg. Each member have its own nervous system, that is what allows the insects to have really quick reflexes.

My robot association (MakingBot) is inspired by this kind of structure.

We have a main module (the body) who manage power consumption, modules detection, and the global robot management. In the surface of this body we have 20 headers for modules connections.
We have defined a protocol from detection to global robot management inspired by the USB standard. During the boot sequence the robot create an OpenRave simulation model who will permit to manage the robot.
Each module have its own computational unit who manage IK, touch sensing, … With this structure you can have a really good reactivity for the touch sensing for example.

We have start to develop our own servos, in our modules each servos are plugged one after the others. We have create a small protocol for motor communication with natural addressing (the motor ID depend of the connection order).

The variable power consumption is a big problem! In my robot each module give his consumption during the boot and a heavy electronics système manage continuously the consumption of each modules to keep the robot safe. If you want to create a battery module no problem, during the boot you have to say “hey I’m a battery module, update the power board software for me please!”

It’s really difficult to explain all the “trap avoidance”, one day we will post a wiki to explain it all.
For the moment I can give you a small presentation (an Eurobot cup poster) of Proteo if you want (the image is too big to be pushed here).

An example of modular robot:

Very interesting, and they are using visual programming, probably Blockly. Way to go. Anyone found documentation on this project?

yes :
http://aut.elektro.dtu.dk/staff/djchr/publications/Pacheco2013.pdf
http://www.staff.dtu.dk/djchr