<br> [Home](../index.html) > Voxel Structures --- # Voxel Structures - Planning and Control <!-- [Combined Gitlab Project](https://gitlab.cba.mit.edu/bej/relative_robot_automation/tree/master) --> ## Bill-e Swarm In this project, the study and implementation of Bill-e/multiple Bill-es' path planning and control will be conducted. The purpose will be to build/assemble voxel structures of different shapes on demand. I will be conducting a series of small studies exploring each of the variables in the voxel assembly process. ----- ###[Context](https://gitlab.cba.mit.edu/bej/relative_robot_automation/tree/master/background/prior_art/previous_studies) ---- ### Bill-e Simulation *(Click on titles/images for interactive simulations)* #### [IK Model](180418_IK/index.html) <a href="180418_IK/index.html"><img src='img/ik.png' width="30%"></a> <br></br> As a first step, I created an inverse kinematic interactive model of Bill-e in Three.js where the input is a desired point and the output is the list of angles of each joint. The Model also has the option to change the Bille-s' dimensions and the fixed leg for Bill-e to be able to move the other leg. #### [Step](180426_virtual_bill-e/index.html) <a href="180426_virtual_bill-e/index.html"><img src='img/ik2.png' width="30%"></a> <br></br> In the second iteration I implemented the steps forward and backward steps. The legs follow points on a parabola that is drawn between the voxels. In this version the input is the target location and virtial Bill-e figures out the rest. #### [Complex Steps](180509_virtual_bill-e/index.html) <a href="180509_virtual_bill-e/index.html"><img src='img/ik3.png' width="30%"></a> <br></br> In this iteration I implemented a more complex IK model for concave and convex turns. Here still the input for each leg the new positions for both legs and the up vector of the vector. #### [Path Plan](180510_bill-e_path_planing/index.html) <a href="180510_bill-e_path_planing/index.html"><img src='img/pathPlan.png' width="30%"></a> <br> </br> Here, I tried to make Bill-e more intelligent by making him calculate the path from one voxel to another. The assumption is that Bill-e has the map of the existing voxels (in relation to his current position). The algorithm is as follows: > **while** *leg1 is not at target location * **then** >> **store** *x position*<br> >> **while** *leg1 x position is not same as target location x* **then** <br> >>> take step in target x direction<br> >>> count step<br> >>> **if** *looped back to stored x position* **then** <br> >>>> **continue** >> **end**<br> >> **store** *y position*<br> >> **while** *leg1 y position is not same as target location y* **then** <br> >>> take step in target y direction<br> >>> count step<br> >>> **if** *looped back to stored y position* **then** <br> >>>> **continue** >> **end**<br> >> **store** *z position*<br> >> **while** *leg1 z position is not same as target location z* **then** <br> >>> take step in target z direction<br> >>> count step<br> >>> **if** *looped back to stored z position* **then** <br> >>>> **continue** >> **end**<br> >> **if** *number of steps larger than maximum allowed steps (got stuck)* **then** <br> >>> **output** can't reach point <br> >>> **continue** > **end** <br> #### [Shortest Path](180518_bill-e_path_planing/index.html) <a href="180518_bill-e_path_planing/index.html"><img src='img/shortPath.png' width="30%"></a> <br> </br> In the previous path planning algorithm, the found path wasn't necessarily the shortest as it tries to reach minimize the difference between the robot and the target location first in the x, y then z direction. I tried to optimize the former algorithm without adding too much complexity by implementing the previous algorithm using different orders and permutations of x,y,z (xyz, xzy, yxz, yzx, zxy, zyx). The path chosen is the one with smaller number of steps. #### [Frep Build](180521_frep/index.html) <a href="180521_frep/index.html"><img src='img/frep.png' width="30%"></a> <br> </br> <img src='img/1robot.gif' width="23.5%"> <img src='img/cone.gif' width="20%"> <img src='img/openCube.gif' width="20.5%"> <img src='img/overhang.gif' width="20%"> <br></br> The desired shape representation chosen was [frep](https://en.wikipedia.org/wiki/Function_representation) (functional representation). <br> - An object as a __point set__ in space is defined by a __function__ of point coordinates f(x_{1},x_{2},...,x_{n}) which is evaluated at the given point by a procedure traversing a tree structure with **primitives in the leaves** and **operations in the nodes** of the tree. - The points with f(x_{1},x_{2},...,x_{n}) ≥ 0 belong to the object. - The points with f(x_{1},x_{2},...,x_{n})<0 are outside of the object. - The point set with f(x_{1},x_{2},...,x_{n})=0 is called an *isosurface*. <br> In the next section I will explain the order by which the voxels were built. #### [Building Sequence](180521_order/index.html) <a href="180521_order/index.html"><img src='img/order.png' width="30%"></a> <br> </br> The building sequence of the voxels is very important in order to avoid deadlocks which will result in incomplete shapes. The voxel building order is as follows: > **Given** *an frep* >>**for** each *Z slice* >>> find voxel with largest frep value <br> >>> **for** *all voxels in this Z level* >>>> divide them into different ranks based on distance of the voxel with the largest frep value >>> **end** >> **end** > **end** This insures that all built voxels will be neighboring to already built ones. <br> For a single robot, the construction logic is as follows: > start with z value equals 0 and rank equals 0 <br> > **while** not all voxels are built >> **if** *robot is at start location and loaded* >>> **for** *all voxel with current rank and z value* >>>> find closest one >>> **end** >>> go build voxel there <br> >>> update current rank and/or z slice <br> >>> return to home location <br> >> **end** > **end** #### [Bill-e Swarm](180521_frep_building_multiple_robots/index.html) <a href="180521_frep_building_multiple_robots/index.html"><img src='img/swarm.png' width="30%"></a> <br> </br> <img src='img/1robot.gif' width="20.5%"> <img src='img/2robot.gif' width="19%"> <img src='img/3robot.gif' width="20%"> <img src='img/4robot.gif' width="22%"> <br></br> For multiple robots, the construction logic is similar to one robot construction. However, to avoid collision, at each step the robots check if there isn't another robot standing at the step. If there is then wait and try again. #### Underlying Assumptions It is important though to mention the underlying assumptions for the robot construction.<br> >- The voxels are passive inert voxels and send no data to the robot <br> - The frep calculation and division of voxel based on rank is done on a central <br> - Each robot is initially given the following information <br> * its legs positions and up vector <br> * its start/home location (where it can reload) <br> * the desired shape to be built in the following structure: <br> - A 3d array of vectors a[i][j][k]: where i is the Z slice, j is the voxel rank based on the frep and k is index of voxel in an array (k isn't important as the order for building voxels with same rank isn't important) * the legs' location of each of the other robots * an empty 3d binary grid of voxel space which will be later filled by built voxels * the current Z and rank (now 0) - After each built voxel the robot broadcasts the following information to the rest of the robots * the updated voxel grid with the built voxel * the updated Z slice and rank (this can be later removed but will cause more computation for the robots) - At each step * it updates its legs position and up vector * the robot broadcasts its location for other robots to update it #### Points to Change Improve/Explore - Do not make the start/loading location for each robot set from the beginning, change it so once the robot builds a voxels then just goes to the nearest loading point - Currently, each robot plans its path and steps which will require for the robots to have high computational power, try to find a more sophisticated path planing algorithm with minimum calculation maybe by trying to have a set path or have the calculations centralized ----- ### Prior Work #### Assembly Sequence The first variable explored was the sequence in which the voxels will be assembled. In this simulation, a functional representation (frep) of a hollow cube was given as an input as well as the starting point. Getting the optimum construction sequence could be based on multiple parameters like the voxel storage location and structural stability. <br></br> <img src='img/0.gif' width="20%"> <img src='img/1.gif' width="20%"> <img src='img/2.gif' width="20%"> <img src='img/3.gif' width="20%"> <br></br> An extra optimization layer should be added afterwards based on Bill-e/multiple Bill-es' movements. Ideally, having a __Arep__ algorithm that describe the geometry would make more use to the assembly sequence. #### Starting Points In order to speed-up and parallelize the process, the box of robots and storage are deployed in multiple locations around the structure and based on the distance the shape assembly is divided between multiple robots. <br></br> <img src='img/two.gif' width="20%"> <img src='img/three.gif' width="23%"> <img src='img/four.gif' width="19%"> <br></br> The method will eventually nt be used as with the accumulation of error which might make it hard for the parts to register together at the end. #### Path Planning The next step I am working on is, based on a given assembly sequence, the path planning of one or multiple Bill-e's around the structure. The algorithm for finding the shortest path is complete and I am the movement of multiple robots with successful obstacle avoidance. #### Voxels Storage Location The optimization of the voxels' storage location is very important to decrease, the traveling time. Here I am gonna study the effeciency of different storage strategies either central, localized, hierarchical... ------- ### Bill-e 1.5 ### Design The redesign and fabrication of Bill-e using the Jake's [newly designed small rotary axis](https://gitlab.cba.mit.edu/jakeread/smallrotary). <br></br> <img src='img/bill-e_before.png' width="40%"> <img src='img/bill-e_after.png' width="40%"> <br></br> ### Communication <div style="position:relative;height:0;padding-bottom:44.24%"><iframe src="https://www.youtube.com/embed/sp_egqbKYEs?ecver=2" style="position:absolute;width:100%;height:100%;left:0" width="815" height="360" frameborder="0" allow="; encrypted-media" allowfullscreen></iframe></div> ### Communication and Obstacle Avoidance Having an closeup animation of Bill-e's movement, different communication strategies (passive, implicit, explicit) will be studied to find and a matrix of different stragies with pros and cons will be generated. ### Communication and Task Allocation The next steps will be exploring the communication strategies of multiple Bill-es, as well as the task allocation of the robot (Centralized, Hierarchal, Decentralized, hybrid,..). ### Controlling Bill-e through Mods The last step would be to do a demo of controlling/sending tasks to two three Bill-es and seeing them in action. ----- </head>