The old Anibots were spheres. Single shape bodies are trivial in the Breve world. Rolling ball robots were easy. One might say that it's too fantastic--but I happen to know that there are in fact multiple ways of implementing real world spherical robots as I studied the literature a bit back in 2004 for my Northeastern University final "capstone" project which involved spherical robots.
What I wanted to do presently was start out with a single bot and consider that a module (the module is the blue sphere in the screenshot).
The next step in development would grow that single module by adding another similar module, and so on adding modules. In the simulation I wanted to connect the rolling spheres together somehow, such as with some rigid body struts forcing a fixed distance between the bots.
This would be part of the context to coerce new behaviors to be learned for the goal, which at first would be pushing the box as far as possible. As more modules are connected together, different strategies will emerge for how to move the entire multi-bot ensemble for the best outcome.
Easy Things are Hard (or at Least Annoying)
This simulation environment doesn't make it easy to just tie moving bodies together. Obviously the collision detection would have to be turned off if it was done as the above screenshot indicates, but even then there isn't a simple or obvious solution in Breve. And again, if it was implemented in the real world it would be possible, in this case as inverse mouse-ball drive robots connected together with rigid links.
There are many possible solutions, for instance manually calculating the bot positions--but then why am I using this simulator? I might as well make my own. So, perhaps sooner than I had anticipated, I may have to develop a Breve-like alternative sim world, perhaps using Panda3D. Or maybe I will use Bullet and Ogre3D, both of which I've used in the past but not at the same time.
Another cool idea that I thought of to bind the bots together is to use an external object. It would be kind of like the triangular thing used to place billiard balls. But this fence would expand to fit any number of balls from 1 to n. I started to implement it as a rectangle. But then I ran into the problem that arbitrary rigid bodies aren't free; so I started making it out of links and revolute joints; but a loop of those was not stable.
There are other options, like trying to make a custom rigid body shape which would have to be scaled to fit around the number of modules.
Whatever the case, it's time that could be viewed as "wasted."
The Curse and Second-Order Cybernetics
The curse of AI work is to waste time on implementing tools. And if one is doing AI with embodied robots, the curse also involves making robotic hardware. All this ``other'' work subverts focusing on the juicy stuff.
However, my view on this has changed a bit over the years. As second-order cybernetics seems to say, the researcher is inherently part of the system :
Occurring between observer and observed, interaction is the primitive from which arises what-can-be-known.
Not merely passive, observers are participants--in a particular sense, that they themselves have direct impact on what they see, on how they observe.
There will always be the design of the design, and the control of the control. Recognizing that is probably better than ignoring it.
- J. Klein, BREVE: a 3D Environment for the Simulation of Decentralized Systems and Articial Life. Proceedings of Artificial Life VIII, the 8th International Conference on the Simulation and Synthesis of Living Systems, 2002.
- P.A. Pangaro, New Order from Old:The Rise of Second-Order Cybernetics and Implications for Machine Intelligence. 1988/2002.