ZigoBot Designer

A need for 3D simulator

2D simulation has gotten very exciting recently, agents playing somehow completely autonomous, and all of us were expecting humanoid agents to somehow have this way of thinking on their robot body and finally a real autonomous agent to be born, but all the things done in 2D field was not enough for this great purpose, still there were low-level skills needed to be implemented on agent, and without those, no humanoid robot could be capable of doing high level decisions. So 3D simulator came in, bringing in real simulation needed for completing decision mechanisms, and the idea to use humanoid robot models, simulated, to enable low-level actions like walking, and to adapt very high-level decision mechanisms used in 2D simulation to a real-time, real-world 3D simulation, and to create broader, more complex ( and maybe unpredictable ), and more real situations. 

Design process for a simulation robot

To design a robot for simulation, there are steps that should be done: A robot should be chosen, Attributes of its parts should be extracted, like dimension, mass, density and joints, all of these steps are needed to simulate the agent, then someone should type the attributes, correct them, debug them and finally with all of these done, a robot scene is ready.

Designing problems

There are problems and speed dumpers that significantly reduce speed of this process, and they appear when all of the information needed is ready and robot information is going to be coded. Currently the only way to create a robot from known information is to type them as a scene by hand, which is greatly time taking and has a great error probability, and what about updating the robot? Just take in mind that main goal is to develop intelligent softwares that fit in a real robot, which its technology improves day to day and an update once in a while is needed for softwares. Take this too: When a robot is first made for simulation, like the soccerbot, it is not going to be the full featured robot for simulation, think about reasons of simplifying simulation, like it’s not necessary to have a turn able neck at first but it is necessary to have legs and stuff, cause the first problem for soccerbot to be solved was not how to look to a particular position, but how to maintain balance and have ability to walk, then when the time came, in which soccerbot is ready and can walk, run: it is going to be needed. Not previously but now. Now that’s the time which an update is needed to create a neck and head and etc for robot. This was one little problem that can be solved in a day or two, but take in mind the process of adding hips or vertebrae, and everybody agrees that a humanoid robot should have both of these! There are other problems that may occur, which do not relate to robot structure, but related to limitations of specific tools of simulation, like a problem joschka once talked about: "I designed size of soccerbot big enough so that our would not encounter any bugs with ode
because of size values"; in that time simulator had problems interacting with ode when sizes were very small, and specially HOAP-2 (which is represented in simulator as soccerbot) was very small for this purpose (It's height is somehow less than 0.5m). Now that these obligations have gone, its time to reduce the size of soccerbot to its original size, and that means a heap of trouble! Now that everyone has put what can be done in moving soccerbot, is it going to be the model, for future researches? Well, this robot is not the complete thing to build simulations upon, and even the robot itself is in process of update. Just consider that we are developing intelligent systems to fit in real humanoid robots, not imaginary ones. There may be needed to create a new robot for simulation and that means that all of the things above will happen again for simulation. Ain't this robot small enough to fall when he kicks the ball?! Or is the FIFA ball going to be scaled down to enable this robot to kick it?! With current way of developing robot scenes, this process is completely boring and hard enough to maintain a robot for future changes – There seems that automated software is needed to handle this problem.

Introduction to ZigoBot-Designer

These are problems that can be solved by automated softwares, designed specially for this purpose. See how AutoCAD simplifies creating and managing designs for designing engineers Currently there is no such software and all modifications to simulation robots are done by hand, that is why updating and correcting process for robots are done this slow. To solve this great problem, Zigorat has thought about creating a software responsible for this purpose, and currently the software created for this purpose – ZigoBot Designer – is ready and is capable of creating complete robots and load and update them while showing the result as a 3D simulation.

ZigoBot Designer

Design Specifications of ZigoBot Designer: (This application is mainly designed for simulator development) On first hand, let's clear out format of a scene: A robot scene is written in S-expression format and is composed of nodes. There are several nodes in a scene, ex. transforms, Cylinders, AgentAspect, SingleMatInitEffector, TimePerceptor, Space, etc. Which all represent something about the robot to be loaded, like for the TimePerceptor, a perceptor to send robot time information. All of these nodes can have parent nodes, which then creates a scope to child nodes, like for example a joint node is child of a Transform node. Every node has its own parameters and respecting values, like for a transform node, a 'name' compound which sets name of node. There are constants and definitions set by define statements and aside from these all, are evaluation statements. With the help of definitions, scene can be written more human understandable, but even with those, a scene for a robot like HOAP-2 comes awfully big and mind-twisting. ZigoBot Designer has a full-featured built-in S-Lang expression parser which is capable of parsing any element in scene, so a scene can be loaded and changed. Aside from the powerful parser, there is a powerful merge system that merges all the information and saves to scene so that simulator can interact with it. There are two top-level windows in application:
First one is a graphical window (uses gtk as base for high-level X-System interaction) to show information and change/update them, and all control stuff is there. There are buttons and menus designed to ease designing process. Second one is another graphical window that is responsible to show the robot resulted from the first window as 3D objects. Here you can move the camera and look at robot from every point of view and check your work result – like the soccer monitor. Designed interface is very handy and everything needed is out there near hand, so no hand-coding is needed to create robot, while updating is eased with load and save support. Application architecture is open and anything can be added to less than 10 minutes, and is heavily documented like our sources which were released before.

Future of robot simulations