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.
