Rapid Prototyping of Dmitri, a Hexapod Robot

Matt Bunting1 and Jonathan Sprinkle2

Abstract Dmitri is a hexapod robot designed to explore bio-logically influenced behaviors, manufactured using 3D printing.The use of 3D printing results in not only rapid turnaroundtime of the physical components, but helps to evaluate softwareor simulation. Biologically inspired robots may involve complexshapes to correctly mimic biology, and such designs are onlyeconomically feasible through the use of 3D printing. Rapidprototyping of software also works in a symbiotic relationshipwith the mechanical design, so an iterative process may changebased on the evaluation of the complete electromechanicalsystem. Presented is the rapid prototyping methods used todevelop Dmitri in both hardware and software. Artifacts andconsiderations using 3D printing in robotics is also discussed.

I. INTRODUCTIONRobotics design in the last five years has taken advantage

of modern manufacturing methods, allowing fast designevaluation and more complex designs while at a low cost.Specifically, 3D printers are becoming a popular choice forrobotic development given the low maintenance required.Through the use of 3D printers, developers may decideto evolve the system in either the software or hardwarelevel, thus the iterative design cycle encompasses all customcomponents in the system.

Biologically influenced robotics is an up-and-coming fieldregarding computation, sensing, and mechanics. Design ofelectromechanical structures that imitate real biological enti-ties requires complex shapes and curves. The complexity ofthe designs results in an expensive manufacturing process,except when 3D printing is used. Development of a bio-logically inspired robot has its challenges, and may requireredesign when not all biological aspects may be identicallyreproduced [1]. Thus, designs must be changed and reman-ufactured to test new designs in a physical implementation.

With the use of rapid prototyping tools for complex de-signs in robotics, the system may be designed and simulatedwhile being tested in reality. The real world feedback in thedesign helps to eliminate design or simulation errors.

Discussed is the manufacturing and software design ofDmitri. First we describe is a brief history of the manufac-turing process. We then introduce the sensors, actuators, andprinted components. Finally we discuss the complexity ofprogramming, operating, and exploring the execution spaceof the physical platform, and describe a domain-specificenvironment to synthesize software that automatically im-plements the necessary sequences of events to operate the

1Matt Bunting is a Ph.D student with the Department of ElectricalEngineering, University of Arizona, 1230 E Speedway Blvd, Tucson,Arizona mosfet@email.arizona.edu

2Jonathan Sprinkle is faculty member with the Department of ElectricalEngineering, University of Arizona, 1230 E Speedway Blvd, Tucson,Arizona sprinkjm@email.arizona.edu

platforms low-level behaviors in order to make it functionat a high level.

A. BACKGROUND

Dmitri began as a class project at the University ofArizona in 2009. The first implementation was created withhandmade components. Though results were achieved withthe original machine learning projects, the mechanism wasimprecise and poorly fit. Future projects using the platformmay not have produced desired results because of the hard-ware implementations. Tools such as Solidworks could beused to easily conceive better designs. Typically CNC millingmachines are used to realize the new designs, and thereforethe design must take the machining limitations into account.For most milling machines, designed must be limited toa 2.5D design. The use of milling machines also requiresa a strong knowledge of cutting bits, materials, federates,coolants, cutting depths and widths, etc. [2] Milling machinesalso require constant attention to ensure that they do notcrash. Through the use of a 3D printer, design evaluation andimplementation could happen at a very rapid rate. Parts pro-duced from 3D printing are also strong enough for productioncomponents [5]. 3D printing does not require the sameamount of attention to the manufacturing process, and full 3Ddesigns may be manufactured without tooling considerations.Since then, various iterations and improvements have beenmade in the mechanical design.

After gaining widespread attention, various groups decidedto purchase copies of Dmitri for use as a trade show demon-stration, an artistic demonstration, and as a research tool.It became clear that the software to operate Dmitri neededto account for a wide range of experiences. Inexperiencedusers needed to develop custom behaviors without knowingprogramming techniques, while advanced users needed lowlevel control. Previous graphical programing interfaces areeasy to visualize program syntax and functionality, likein Lego Mindstorms. Unfortunately, these tools typicallyremove all low level control of the system, which experi-enced programmers may need. The use of domain specificmodeling tools can be used to create a tool to meet allrequirements [6] [7]. Similarly, the durability needed to beincreased for an unknown set of implementations.

II. HARDWARE

Each of the six legs consists of three Dynamixel MX-28motors for three degrees of freedom (3DOF). The hexapedallayout is similar to that of most insects, but does not followany single specific creature. A Point Grey Chameleon camera

Fig. 1. Dmitri, built using 3D printing.

is mounted on a 3DOF mechanism, operated by three dynam-ical AX-12 motors. Much of biology uses vision for the mainperception sensor, which is the focus of Dmitri. Therefore,the camera is currently the only sensor. A Compulab fit-PC2 is mounted on the top to provide computation. The fit-PC2 communicates with the motors using an FTDI chip. Thedesign of Dmitri can be seen in figure 1.

Originally, the frame and linkages were hand-made usingbrass and solder. This quickly became a time-consuming andimprecise process. Changes in the design were also slow toimplement, specifically regarding the leg design as six totalidentical parts needed to be created on each iteration. Withaccess to a Dimension BST 1200es 3D printer, Solidworkswas used to design new segments for Dmitri. Through theuse of the 3D printer, many of the parts were conceived,designed, and printed in the same day.

ABS plastic is certainly not as durable as brass, so the newdesigns needed to accommodate the weaker material. Once apart was printed, it was immediately implemented and tested.Due to the additive process, the resulting parts are much moreflexible than injection-molded ABS plastic. The printed partsalso are fairly porous and have a grain, similar to that ofwood. Each part needs to consider the torsion and shear forcebased on the printing orientation. By changing the printingorientation, parts could much more easily handle the mainstress in the manner that they are to be used.

The layer resolution of the printer is not very fine at.254mm, so changing the orientation for strength may resultin imprecise parts. Fortunately, Dmitri does not requirehigh precision in most of the parts, except for in the headmechanism.

A. HEAD MECHANISM

Figure 2 shows the current design of the head mechanism.The head mechanism uses an intricate set of involute gearsand shafts, designed in a similar way to a differential gearsystem. This design enables relocation of the motors, reduc-ing the mechanisms profile. Because of both the resolutionand strength of the printed ABS, gears had to be printedwith a large diametral pitch. Fortunately, printing spur gears

Fig. 2. Head mechanism design.

results with the face parallel to the printing layers results invery usable gears. Bevel gears are also best printed in thisorientation, but the layer resolution causes the teeth to be alittle rough.

Printing circular shafts poses a trade off problem. Shaftsare usually used to transmit a torsional load, and ideallyare perfectly cylindrical. There is no ideal way to print theshafts to handle both of these cases. In the case of Dmitri, thetorsional load is minimal and may then be printed verticallyto result in the best geometry. To help with any unforeseentorsional loads, each shaft is printed so that a bolt maybe installed axially. This applies compression to the shaft,greatly strengthening the part.

Even though this is the best orientation for producinga correctly shaped shaft, another artifact of 3D printingbecomes apparent. When a layer is printed, all perimetersare drawn with a few lines of plastic. In the second passof the layer, all interiors are quickly filled in. Because eachperimeter needs to have a start and stop point for layingdown plastic, a small bump or divot appears. This couldbe accounted for using correct accounting for tolerance,however accounting for a larger tolerance means that therest of the shaft is incorrectly accounted for. For Dmitri, eachprinted shaft was inspected for the bump and was lightly fileddown. The Catalyst software used to operate the Dimensionprinter fortunately places the start/stop points usually at thesame place, so filing down the nub was very quick and easy.

Initially shafts for gears were inserted into fixture holesthat were also directly 3D printed. Because of small im-perfections, a break-in time was necessary to give the headmechanism smooth operation. Break-in programs were cre-ated to be run for a span of 12 hours, moving the head toeach each of its extremes in all 3DOF. Though the break-in procedure was highly effective, the teeth would naturallyalso show signs of wear. To help reduce time to produce thehexapod and slightly increase the lifetime of the gears, allshafts were transitioned to use steel ball bearings.

III. SOFTWARE

Various behaviors have been implemented using a customC++ based hexapod library. Such behaviors involve machine

learning, mapping, or animatronic behaviors. Current ownersof the Dmitri design sought to implement their own custombehaviors, but the owners may not have been programmingsavvy. Likewise, others are programming experts and wantto have low level control using the libraries. Through theuse of domain specific modeling, users may design theirown behaviors using a graphical programming interface. Theresulting behavior generator should be useful for people witha wide range of experiences.

A. Metamodeling

By using this well understood domain for users to im-plement their own behaviors, a metamodel of the behavioralmodel may be created. The Generic Modeling Environment(GME) is a DSM tool implementing UML style diagrams[8]. A modeling language may be designed in the GME GUIusing a set of components typically found in class diagrams.Once a language is designed, an interpreter in GME may beused to automatically generate the modeling language fromthe metamodel. GME is then able to load and implement thegenerated modeling language. Similarly, GME is also ableto generate an interpreter template as a Visual Studio projectfor the new modeling language. The template may be thenfilled in to read the elements of the project created in themodeling language. With the known elements in the usersproject, the interpreter may be used to generate a solutionthat fits in the domain.

B. Behavior Generation

Typical behavior implementation involves the use of thehexapod libraries. These libraries perform functions to op-erate the motors and camera while also providing usefulfunctions for basic hexapedal locomotion. Each behavior hasa set of threads, and each thread has a set of componentsthat pass messages to each other. Threads may also sendmessages to other threads. With this knowledge, a model ofbehaviors may be designed, as shown in figure 3 on the right.

Figure 3 on the left shows the resulting metamodel designfor the hexapod behavior. Each users behavior contains a setof set of threads. Each thread contains a set of functions tobe executed, which pass messages through the use of ports.With this design in GME, the interpreted modeling languageis shown on the right in figure 3, as well as an interpretertemplate for the model.

For Dmitri, the interpreter template of the modeling lan-guage was used to generate C++ code to correctly operatethe hexapod library in the manner that the user had defined.The code that is generated has a focus on commenting tohelp the user understand the flow. The interpreter benefitsall users of Dmitri:

High level users may design their own simple behaviorsfor custom control, such as operating the hexapod usingthe Sixaxis controller.

Medium level users may implement the User Functionwhere they are able to inject their own C code.

Low level users may use the tool to generate basic C++templates implementing the library, from which theymay implement more advanced control using C++.

An example of generated code from the behavior generatoris shown:

/ / u s e r F u n c t i o n s . cpp/ // / T h i s f i l e was a u t o m a t i c a l l y g e n e r a t e d by t h e/ / Hexapod B e h a v i o r Genera tor u s i n g MetaGME

# i n c l u d e u s e r F u n c t i o n s . h

/ User F u n c t i o n s /

/ / g l o b a l / / B v e c t o r b o d y v e l o c i t y g e n e r a t o r ( )/ // / D e s c r i p t i o n :/ / / // / Outpu t / / B v e c t o r b o d y V e l o c i t y D e s c r i p t i o n :/ // /

B v e c t o r b o d y v e l o c i t y g e n e r a t o r ( ){

/ / User d e f i n e d o u t p u t v a r i a b l e :B v e c t o r b o d y V e l o c i t y ( 6 ) ;

/ / User d e f i n e d a t t r i b u t e :b o d y V e l o c i t y ( 1 ) = 4 0 ;

re turn b o d y V e l o c i t y ;}

IV. CONCLUSIONS

The use of 3D printing is a crucial part to the developmentof Dmitri. The ease of use and fast turnaround time greatlyenhanced the design over time. Though nearly any geometricshape may be printed, there is still a large consideration ofthe printing orientation and the tolerances in each compo-nent.

Modeling the behavioral components for Dmitri is anexceptional tool for users to create their own programs. Notonly does this work for users new to programming, butexperienced users may take advantage of the same tool togenerate behavior templates.

ACKNOWLEDGMENT

Jonathan Sprinkles efforts related to this work are sup-ported by the National Science Foundation under awardsCNS-1253334 and CNS-0930919.

REFERENCES

[1] Lewis, M. Anthony, et al. Toward ultra high speed locomotors: Designand test of a cheetah robot hind limb. Robotics and Automation(ICRA), 2011 IEEE International Conference on. IEEE, 2011.

[2] Fussell, B. K., R. B. Jerard, and J. G. Hemmett. Robust feedrateselection for 3-axis NC machining using discrete models. Journal ofmanufacturing science and engineering 123.2 (2001): 214-224.

[3] Espenschied, Kenneth S., et al. Biologically based distributed controland local reflexes improve rough terrain locomotion in a hexapodrobot. Robotics and autonomous systems 18.1 (1996): 59-64.

[4] Kimura, Hiroshi, Yasuhiro Fukuoka, and Avis H. Cohen. Adaptivedynamic walking of a quadruped robot on natural ground based onbiological concepts. The International Journal of Robotics Research26.5 (2007): 475-490.

[5] Bak, David. Rapid prototyping or rapid production? 3D printingprocesses move industry towards the latter. Assembly Automation23.4 (2003): 340-345.

[6] Gray, Jeff, et al. Domain-specific modeling. Handbook of DynamicSystem Modeling (2007): 7-1.

[7] Kelly, Steven, and Juha-Pekka Tolvanen. Domain-specific modeling:enabling full code generation. John Wiley & Sons, 2008.

[8] Ledeczi, Akos, et al. The generic modeling environment. Workshopon Intelligent Signal Processing, Budapest, Hungary. Vol. 17. 2001.

Fig. 3. Left: The hexapod behavior metamodel. right: An example behavior created using the models.