co-design of azimut, a multi-modal robotic platform

1 Copyright © 2003 by ASME

Proceedings of DETC’03ASME 2003 Design Engineering Technical Conferences and

Computers and Information in Engineering ConferenceChicago, Illinois USA, September 2-6, 2003

DETC2003-CIE48268

CO-DESIGN OF AZIMUT, A MULTI-MODAL ROBOTIC PLATFORM

François MichaudDepartment of Electrical Eng. and Computer Eng.

2500 boul. UniversitéUniversité de Sherbrooke

Sherbrooke, Québec Canada J1K 2R1Email: [email protected]

Martin Arsenault, Yann Bergeron, Richard Cadrin,Frédéric Gagnon, Marc-Antoine Legault, Mathieu

Millette, Jean-François Paré, Marie-Christine TremblayDepartment of Mechanical Engineering

Université de SherbrookeSherbrooke, Québec Canada

Dominic Létourneau, Pierre Lepage, Yan Morin, Serge Caron, Jonathan BissonDepartment of Electrical Engineering and Computer Engineering

Université de SherbrookeSherbrooke, Québec Canada

ABSTRACTAZIMUT is a mobile robotic platform that combines

wheels, legs and tracks to move in three-dimensionalenvironments. Its design is the result of an interdisciplinaryeffort combining expertise in mechanical engineering, electricalengineering, computer engineering and industrial design. Afterpresenting AZIMUT, this paper describes the challenges ofdesigning such a robot, outlining the interdependenciesbetween the disciplines and the difficult compromises that haveto be made during the iterative design process of a mobilerobotic platform. Modularity at the structural, hardware andembedded software levels, all considered concurrently in aniterative design process, reveals to be key in the design ofsophisticated mobile robotic platforms.

INTRODUCTIONRobotics is a great domain to address interdisciplinary

design. It involves a mechanical structure that is capable ofmoving using various types of actuators that need to becontrolled and powered. Such considerations are even morechallenging in the case of mobile robots, i.e., robots that have tomove in the real world. Compared to a robotic manipulator, amobile robot has to carry its own power source. It also has towork in environments that are much more opened than thewell-defined operating area of an assembly line for instance.Depending on the tasks it is assigned to do, a mobile robot mayoperate on flat surfaces or rough terrain, indoors or outdoors,move slowly or rapidly, with or without the presence of moving

objects (living or not), and potentially have to deal withhazardous conditions such as stairs, holes, etc.

The most common locomotion method to make a mobilerobot move is to use two-wheel drive with differential steeringand a rear balancing caster. Controlling the two motorsindependently makes the robot holonomic in its motion. Suchrobots can work well indoors on flat surfaces and inenvironments adapted for wheelchairs. However, their use isquickly limited by stairs or other obstacles. This is one reasonthat justifies the development of robots with two, four or sixlegs. A robot with legs is capable of changing its height whenrequired and potentially moving over obstacles. However,legged robots have their disadvantages too. For instance, theycannot move as fast as wheeled robots on flat surfaces, and theyhave to move carefully to keep their balance (and in doing sothey require more energy and more complex controlalgorithms).

Combining multiple modes of locomotion on the sameplatform would allow a robot to exploit the most appropriatelocomotion mechanism for the prevailing operating conditions.This is kind of a natural solution since humans, being leggedcreatures, have built various types of machines like cars,bicycles, snowmobiles, etc., to assist them in traveling moreefficiently and to compensate for the limitations of legs. Thedifference with a robot is that the added locomotionmechanisms can be directly assembled on the robot. In doingso, it is important to follow a modular approach in the design ofthe robot so that various types of locomotion mechanisms andcapabilities can be added to the platform. For humans,


modularity is ensured as long as the interfaces are compliantwith the human body (usually using feet and hands).

This paper describes our design of a new multi-modalrobotic platform that we have named AZIMUT. AZIMUT ismade of four leg-track-wheel articulations and can handle awide variety of movements. For instance, it is capable ofholonomic and omnidirectional motion, climb or move overobstacles, go up and down stairs (even rotating ones).Modularity is preserved at the structural level by putting theelectrical and embedded systems inside the body of the robot,and by placing the actuators on the locomotion parts (i.e., theleg-track-wheel articulations) so that they can easily bereplaced. Each controllable part of the robot is equipped withits own driver and microcontroller, distributing the control overthe different subsystems of the robot. All of these subsystemsexchange information through shared data buses. Modularity istherefore also present at the embedded system level. To achieveall of this, it is necessary to adopt a co-design approach,combining the expertise of people in mechanical engineering,electrical engineering, computer engineering and industrialdesign. Since technological advances directly affect the designof mobile robots, following a modular approach is important tofacilitating continuous improvements of the platform over time.We started this project with small experience in highlysophisticated mobile robotic platforms. One objective of thispaper is to present what we have learned by outlining thechallenges faced and the considerations that reveal to beimportant during the design of this first prototype of AZIMUT.The experience gained and the design tools that we proposewill be helpful in future design iterations of AZIMUT or othermobile robotic platforms.

The paper is organized as follows. First, the paper reviewsmulti-modal robotic platforms, and follows with a descriptionof AZIMUT and its characteristics. The paper then describesthe challenges of designing sophisticated mobile robots such asAZIMUT, outlining the interdependencies between thedisciplines and the difficult compromises that have to be madeduring the iterative design process of sophisticated mobilerobotic platforms such as AZIMUT.

MULTI-MODAL ROBOTIC PLATFORMSFor this brief overview of multi-modal robotic platforms,

we only address robots assembled as one integral structure, inopposition to reconfigurable robots made of an assemblage ofhomogeneous building blocks (e.g., Shen, Salemi and Will,2002). Also, we focus on robots that combine wheels, legs ortracks for locomotion.

The most popular combination is to add leg-like motion towheeled robots. King, Shackelord and Kahl (1991) propose arobot equipped with two sets of three wheels that can flip overand climb on obstacles. NASA’s Nomad1 robot, used in 1997 tosearch for meteorites in the Antartic, has a transforming chassiscapable of deploying the four wheels. It enables skid steering aswell as explicit steering and increased stability. Compacting orstowing the wheels allows Nomad to fit within a 1.8 metersquare to a 2.4 meters square footprint. However, the wheels

1 http://www.frc.ri.cmu.edu/projects/meteorobot/Nomad/Nomad.html.

always remain on the ground. This is not the case for the robotnamed WorkPartner (Ylönen and Halme, 2002; Halme,Leppänen and Salmi ,1999), made from the Hybtor roboticplatform. This design differs by putting wheels at the end offour legs (for 12 degrees of freedom). Using its wheels, therobot can reach a speed of 7 km/h. The robot has a hybridpower system, which consists of a 3 kW combustion engine andbatteries, and so it would be mainly used for outdoorapplications. The platform is around 1.2 meters long, 1 meterhigh, weighs about 160 kg and the possible payload is 60 kg.Each leg has its own Siemens 167 microcontroller, and thecomputer system is distributed around a CAN bus protocol. Therobot’s locomotion is made of three modes: the wheeled drivingmode (with active balancing and active suspension), thewalking mode (as for a four-legged robot) and a hybridlocomotion mode that allows the robot to walk by keeping thewheels on the ground.

Rocky 7 (Volpe, Balaram, Ohm and Ivlev, 1997), Shrimp(Estier et al., 2000) and Octopus (Lauria, Piguet and Siegwart,2002) are three other robots that fit in the category of legged-wheeled robots. But these robots are much smaller and lighterthan the previous two. Rocky 7 is an improved version ofSojourner, the robot platform that landed on Mars. It has sixwheels, six degrees of freedom and weighs 11.5 kg. It is 61 cmlong, 49 cm wide and 31 cm high. It only uses one onboardmicrocontroller. The Shrimp has six motorized wheels, using1.75 W DC motors. The robot weighs 3.1 kg (which includes600 g for the batteries) and is 60 cm long, 35 cm wide and 23cm high. It has a steering wheel in the front and the rear, andtwo wheels arranged on a bogie on each side. The front wheelhas a spring suspension. The robot is able to passivelyovercome obstacles of up to two times its wheel diameter andcan climb stairs with steps of over 20 cm (as long as the robotis correctly aligned with the stair). Octopus is the “active”counterpart of the Shrimp. It uses eight motorized wheels, fouron each side, and has a total of 15 degrees of freedom (14 aremotorized). The robot is 43 cm long, 42 cm wide and 23 cmhigh, and weighs 10 kg. It can support a payload of 5 kg. Eachmotor has a local PIC processor arranged in a master-slaveconfiguration and exchanging information using standard I2Cprotocol. Using information provided by its tactile wheels, thegeometric angles of the articulations and the direction of thegravity field, the robot has to figure out how to control itsmotors to move over an obstacle. Finally, there is also the workof Steeves, Buelher and Penzes (2002) that fits in this category,but at the level of conceptual design. They have studied insimulation the dynamic behavior or a robotic platform equippedwith legs (sprung prismatic legs) and wheels.

The other popular combination consists of using tracks onarticulated parts. The Urban robot made by iRobot inc. is themost well known example (Matthies et al., 2000). This robothas two side-tracks of 68.6 cm in length on each side, with twoarticulated tracks in the front that can do continuous 360 degreerotation and enable crossing curbs, climbing stairs andscrambling over rubble. When the articulations are stretchedout, the robot measures 88 cm in length. It is 40 cm wide and18 cm high. It weighs 20 kg, with 3 kg of batteries. It can go asfast as 80 cm/s on flat surfaces. The onboard controller is a68332 Motorola microcontroller. There is also Chen and Hsieh


(2000) who designed a robot equipped with four wheels andfour tracks, two of each on each side, and that can be used incombination to create different motion patterns.

If we consider the designs described in the previousparagraphs, using articulated tracks offers the advantage of notrequiring complex control mechanisms for preserving thestability and minimizing the vibration of the robot as it climbsstairs or moves over obstacles. The robot is able to keep a goodcontact with the ground, preserving its stability. However, thetracks must be deployed, which may make it hard for the robotto turn while climbing a circular staircase for instance. In thefollowing section we describe how AZIMUT is capable oftaking such constraints into consideration.

AZIMUTThe underlying objectives for the design of this new

robotic platform are to provide a wide variety of movements in3-D space like moving forward and backward, turning, rotatingon itself, lifting itself up, moving over obstacles, going up anddown stairs, and moving in all directions (omnidirectional). Thedesign must also be modular, allowing to add and to changeparts easily at the structural, hardware and software embeddedlevels.

Figure 1. SCHEMATIC OF AZIMUT

Figure 2. PROPULSION MECHANISM OF ANARTICULATION

Table 1. LOCOMOTION MODES

Mode DescriptionArticulations Up Facing ForwardIn this mode, the robot moves on itswheels. It can turn using differentialdrive.

Articulations Up Facing SidewaysThe robot can move from side to side inrelation to the direction it is facing.

Articulations Up in DiagonalThe robot can move in angle in relationto the direction it is facing.

Articulations Up RotationThis mode allows the robot to changeits orientation by turning on itself withminimum friction.

Articulations Up Steering DriveOne pair of articulations can be used forpropulsion while the other is used forsteering.

Articulations StretchedIn this mode, the tracks are used forpropulsion. This would be useful forstairs or to climb over obstacles.

Articulations DownThe robot can move on top of its legs,making it lift itself to change itsperception of the world or pass overobjects.

The design we came up with is shown in Figure 1.AZIMUT is symmetric and has four articulated parts attachedto the corners of a square frame. Each articulated part combinesa leg, a track and a wheel, and has three degrees of freedom.Each articulation is independent, and so the robot uses 12motors for its locomotion. The leg can rotate 360 degreesaround the y axis and 180 degrees around the z axis. Once anarticulation is placed at the right position, the system isdesigned to keep it in position without requiring any energyfrom the motors. When the articulations are stretched, the robotcan move by making the tracks rotate around the legs. As thearticulations move upward toward the orientation of the z axis,the point of contact of the leg with the ground moves from thetracks to the rubber strips fixed outbound of the attachment axleof the articulations (on the left of the track in Figure 2). This

z

yx

1


rubber strip creates a very narrow wheel that allows the robot tochange the direction of an articulation with minimum friction.

The robot also offers nice features such as:• two retractable side-handles to lift the robot;• an accessory-fixing plate on the top of the chassis;• a PDA interface for debugging the onboard embedded

systems of the robot;• two control panels allowing easy interface with the

onboard systems of the robot;• a sliding compartment for the onboard PC/104

computer, making computer upgrade and maintenanceeasier;

• aesthetic bodywork attached to the chassis using easilyaccessible fixtures.

Possible Modes of LocomotionBy placing the articulations in different positions,

AZIMUT can adopt various locomotion modes like the onesshown and described in Table 1. And since each articulation isindependent, the robot can create much more sophisticatedmodes. For instance, in can turn while climbing a staircase bychanging the direction of the front articulations and the backarticulations. The robot can move with its front articulationsstretched at 45 degrees in relation to the horizontal axis, whichwill allow the robot to climb over obstacles. The robot cancross its articulations and lift itself up when it gets stuck overan obstacle. The first five modes are also possible with therobot’s articulations down. Being omnidirectional, it would alsobe possible for a group of AZIMUT robots to change directionin a coordinated fashion to transport together a commonpayload or large objects. Many other configurations can beimagined, and the 12 degrees of freedom on AZIMUT give therobot great flexibility and versatility in its motion capabilities.

Hardware DescriptionThe usual approach for designing a mobile robot is to have

a central microcontroller board to interface all of the sensorsand actuators of the platform. This board has to be designedwith all of the possible extensions (in terms of I/O and in theprocessing capabilities of the microcontroller) in mind. Anotherapproach is a modular one: the robot hardware is made ofdifferent subsystems that communicate with each other toexchange information and to coordinate their actions. Eachsubsystem has its own microcontroller, selected according tothe processing requirements for the particular subsystems. ForAZIMUT, this approach is the most appropriate one because itallows to easily add functionality to the robot and to increase itsrobustness by distributing control over its components.

Figure 3 represents the robot’s subsystems. Eacharticulation has its own Local Control subsystem (controllingits three motors using PID controllers) and Local Perceptionsubsystem. The other subsystems are associated to the platformitself: the Power subsystem distributes and monitors energycoming from batteries or an external power source to all of theother subsystems; the User Interface subsystem is there tointerface the PDA with the other subsystems of the robot; theInclinometer subsystem measures the inclination of the body ofthe robot; the Remote Control subsystem allows to send

commands to the robot using a wireless remote control; theGeneral Control subsystem manages positioning of thearticulations when modes are changed to avoid interference,and monitors the states of the subsystems to insure safety of theplatform; the Computing subsystem consists of the onboardcomputer used for high-level decision making (e.g., visionprocessing for a camera that would be used by the robot). All ofthe subsystems exchange information using the CoordinationBus. The Synchronization Bus is also used to synchronize thecontrol of the articulations (e.g., to make the robot go straightforward).

Figure 3. AZIMUT’S EMBEDDED SUBSYSTEMS

The Local Perception subsystem of each articulation ismade of one long-range ultrasonic sensor, two short-rangeultrasonic sensors and five infrared range sensors, to detectobjects and surfaces around the articulation. Figure 4 shows theperceptual zones using these sensors.

Figure 4. ONBOARD SENSORS


Software DescriptionThere are two levels of software for AZIMUT: software

for the subsystems and software designed for the overall controlof the robot. At the subsystem level, each subsystem follows ageneral procedure that allows it to examine conditions andrequests posted on the bus, to complete a self-diagnostic test, toprocess a command or a request addressed to it, to get the datafrom its sensors, to process them, to give commands to itsactuators and to transmit back its status on the bus. Eachsubsystem is designed to be implicitly safe: when not activated,a subsystem is in a state that will not put the robot in adangerous condition. The General Control subsystem has theresponsibility of activating the appropriate subsystems.

The Coordination Bus and the Synchronization Bus areimplemented using CAN 2.0B protocol, a 2-wire interface witha communication rate of 1 Mb/s. The CAN interface uses anasynchronous transmission scheme employing serial binaryinterchange. Information is passed from transmitters toreceivers in a data frame. The data frame is composed of anarbitration field of 29 bits, a control field of 6 bits, a data fieldof 0 to 8 bytes, a 16 bits CRC field, a 2 bits ACK field. Theframe begins with a 'Start of frame' of 1 bit, and ends with an'End of frame' space of 7 bits. We configured the arbitrationfield and the data field specifically for our robot designs. Thearbitration field is composed of four parts that allow toprioritize and to characterize a message on the bus: threepriority bits (0 being the highest priority); eight mask bits forthe type of message (like emergency, high priority actuators orsensors, etc.); 9 bits (with the two most significant ones set to1) to specify commands or requests to subsystems; 8 bits toaddress directly a subsystem using its hardware address (theaddress 255 is reserved for broadcast messages).

Figure 5. INTERFACE ON THE PDA

For the overall control of the robot, two types of softwareare used. The first is for testing and monitoring the states of therobot, using two different devices. One is implemented on aPDA, and Figure 5 shows a typical interface window. The PDAis a nice device for such purposes since it allows to usegraphical representations of the status of the robot (which

would not be possible using LCD displays as most mobilerobots use). A second interface is implemented on a remotecomputer connected to the General Control subsystem via aRS-232 serial link. This interface allows independent control ofthe motors and monitoring of the states of motor encoders, thecontrol loops and the data exchanged on the bus. Figure 6shows one window of this interface. The middle picture is a topview of the robot. The four parts of the picture correspond tothe robot’s articulations. The user just has to select thearticulations to monitor their states or to control their motors.Scripts of high-level commands can also be made forsimultaneous control of the articulations.

Figure 6. TESTING INTERFACE ON A REMOTECOMPUTER

The second type of software developed for the overallcontrol of the robot is a simulator. The simulator makes itpossible to imagine control scenarios without having to use theactual prototype. Such scenarios can be the transitions made bythe articulations to move from one locomotion mode to another,the position of the articulations as the robot goes up or downstairs, the possible interference between the articulations, etc.Figure 7 illustrates the simulated environment created usingOpenGL.

Figure 7. SIMULATOR


First PrototypeFigure 8 shows pictures of the first prototype of AZIMUT,

completed in December 2002. The robot is made of more than2500 parts. Twenty-three persons were involved in the designprocess, cumulating around 17000 work hours on the project.The characteristics of this first prototype are summarized inTable 2.

Figure 8. PHOTOS OF AZIMUT

Table 2. AZIMUT’S SPECIFICATIONSCharacteristics Measures

Length 70.5 cm (articulations up or down)119.4 cm (articulations stretched)

Width 70.5 cmHeight 38.9 cm (articulations stretched)

66 cm (articulations down)Body clearance 8.4 cm (articulations stretched)Weight 63.5 kgMaterial Aluminum 6061-T6, steel 01, steel

4340, steel 1020Maximal speed 1,2 m/s (4.3 km/h) (on flat surface)Battery Two packs of 24V Ni-MH cellsMicrocontrollers nanoMODUL-164 from Phytec for the

Local Control and General Controlsubsystems;PIC 16F877 for the other subsystems

Track Diamond profile conveyor belt (rubber)Motors Ferrite ServoDisc motors and standard

brush motorsBus CAN 2.0B 1 Mbps

For the four Local Control subsystems and the GeneralControl subsystem, AZIMUT uses five nanoMODUL164 fromPhytec, based on a Infineon C164CI 20 MHz microcontroller.This microcontroller provides sufficient processing power to

implement three PID control loops, one for each of the threemotors of an articulation, with each motor having a 1024 pulsesper revolution encoder. The General Control subsystem alsohas to manage critical tasks such as coordination ofarticulations. But for other subsystems, less processingcapabilities are required: the processes mostly involveinterfacing sensors or actuators to the CAN bus without toomuch calculations. For such tasks we designed a board that wenamed the PICoMODUL, shown in Figure 9. It is made of aPIC 16F877, running at 20 MHz. Both the nanoMODUL andthe PICoMODUL are designed to be stacked on other boardsdesigned specifically for the robot, like a 100 Amp motor drivefor an articulation, a sensor board for the Local Perceptionsubsystem, a board that monitors the energy consumption andrecharges of the batteries, a board for the RF remote control,etc.

Figure 9. PICoMODUL board

The first prototype of AZIMUT demonstrates thecapabilities of the robot in changing the orientation of itsarticulations for omnidirectional movements. The robot is alsocapable of moving with its articulations down and goingthrough doors. However, because of time and cost constraints,the chassis of the robot had to be made using aluminum andsteel parts. This made the platform heavier than expected. Thisfirst prototype is not yet capable of lifting itself up. But theimplementation allowed to pinpoint critical components thatcan be improved to make a second prototype completelyfunctional.

COMPARISON OF AZIMUT WITH OTHER MULTI-MODAL ROBOTIC PLATFORMS

Even though we came up with many solutions on our own,a lot of ideas from other multi-modal robotic platforms exist inAZIMUT. AZIMUT is capable of changing the orientation ofits articulations, as for the Nomad robot. WorkPartner has thesame degrees of freedom, which also uses a CAN bus andSiemens microcontrollers distributed as the robot’s subsystems.However, AZIMUT provides a much diverse set of locomotion


modes. While AZIMUT is much smaller than the Nomad andthe WorkPartner robots, it is heavier and more complex tocontrol than the Rocky III, the Shrimp or the Urban robots. Thecost in weight might be compensated by the versatility of thelocomotion modes. As for the Octopus robot, AZIMUT alsouses PIC to distribute processing across the robot’s subsystems.

The concept closest to AZIMUT is the High UtilityRobotics (HUR) Badger, elaborated by Digney and Penzes(2002). The HUR-Badger concept is derived from an analysisof what kind of locomotion capabilities a mobile roboticplatform would need to follow a human soldier in an urbancombat scenario. The design they came up with is made of twopairs of tracked units connected to a common body usingrotational joints. The tracked units are sized such that they canbe rotated through each other. By simulating the operationalmodes of the robot using Working Model2 simulator, they wereable to demonstrate how the platform could be used in variousconfigurations that would be necessary in real operationalconditions. This outlines another important point to consider inthe design process of mobile robotic platforms: the presence ofexperts in the operating environments of the robot. ForAZIMUT, the target was for indoor environments like homesand offices. But to adapt AZIMUT for outdoor uses, thisbecomes an additional key element. The expertise gained whilemaking AZIMUT could be mostly beneficial to making a realfirst prototype of the HUR-Badger.

DESIGN PROCESS OF COMPLEX MOBILE ROBOTICPLATFORMS

Designing such a sophisticated mobile robot platform isnot an easy task, but it is a necessary one if we want mobilerobots to eventually become useful and efficient agents in ourworld. If we assume mobile robots are going to be used only insmooth surfaces, then perception is probably the most limitingfactor to make them autonomous in their decisions. But sincewe live in a 3D world, sophisticated moving capabilities arerequired. By facing the challenges of designing and buildingthe first prototype of AZIMUT, we learned a lot on thedifferent considerations that must be addressed, and theobjective of this section is to report the observations made fromthis experience.

As described in the previous sections, the design of amobile robot such as AZIMUT involves many dimensions andtools, all required to successfully building a robot. Nointegrated tools or detailed methodologies exist to assist in thedesign process of a mobile robotic platform. For designingAZIMUT we have used SolidWorks for technical drawing,Nastran for mechanical simulation, C compilers for PIC andnanoMODUL programming, a compiler for PDAprogramming, and other tools we had to design ourselves (likethe simulator). Having described the design of one suchplatform, it is hard to imagine overcoming the complexengineering issues without following a detailed and structureddesign process, or without involving a team of people withvarious expertise and backgrounds.

2 http://www.krev.com/index.html.

The design process followed is based on concurrentengineering principles (Ulrich and Eppinger, 2000). Theseprinciples call for a strong requirement analysis over the entirelife cycle of the product. This assures that the majority of therequirements and constraints are addressed early in the designprocess in order to minimize reengineering of the design lateron. The methodology has six general phases:• REQUIREMENT ANALYSIS. This phase is the most

important in the design process. It consists of an extensivesearch for requirements associated to the robot. Theserequirements come from the user’s needs, the operatingconditions, the production process, the project constraints(time, cost, etc.).

• FUNCTIONAL ANALYSIS. This process transposes allof the requirements into functional terms expressing whatthe robot must do. These functions are then organized andanalyzed.

• SYSTEM DESIGN. Using a variety of creativity tools, thisstep elaborates the global concept that responds to all ofthe identified functions. This concept is then separated intosubsystems.

• PRELIMINARY DESIGN. Again using creativity tools, aconcept is elaborated for each subsystem. The conceptmust address all the functions identified for the givensubsystem.

• DETAILED DESIGN. For each subsystem, calculations,drawings, schematics and technology choices are made toproduce the prototype.

• INTEGRATION AND VALIDATION. In this phase, allthe parts are assembled to build the complete robot. Thevalidation is made using tests that are derived from therequirements and functions.The concurrent engineering approach addresses the

horizontal integration of an engineering project. However, aswe have learned with AZIMUT, a robot design is amultidisciplinary effort that calls for an early integration of avariety of fields of expertise. Other methodologicalconsiderations must be addressed to facilitate the verticalinterdisciplinary integration. To be more specific, the design ofa robotic platform requires the integration of five types ofexpertise:• MECHANICAL. This deals with structural and part

design, mechanical joints, weight estimation, calculation oftorque and forces, assemblage of parts of the robot.

• ELECTRICAL. Aspects such as batteries, powerdistribution, motors, encoders, sensors, wiring, heatdissipation, drives, controllers, circuits and computerboards are of concern.

• COMPUTER. Processing capabilities, communicationprotocol, I/O interfacing, user interface, control ofactuators, decision-making and debugging software areaddressed.

• INDUSTRIAL DESIGN. Aesthetic aspects such as color,bodywork design and construction are studied and built.

• OPERATING CONDITIONS. Considerations of theoperating conditions (which include the environment, theusers, the capabilities required in the field, etc.) influence


directly the choices to be made for efficient usage of therobot to be developed.Obviously, strong ties exist between these five types of

expertise, and they cannot be developed without continuousexchanges between them. To work efficiently, the team musthave specialists for each type and people that can work at thefrontier of these expertise to allow such exchanges to be made.For that they need to understand their working methodologyand their terminology. In our case specialists in mechanical,electrical and computer engineering handled engineeringissues: they shared the same methodology, but theirterminology and concerns had to be understood. The mostdiscrepancies were observed with the specialists in industrialdesign, which followed a more intuitive, practical and lessdocumented design methodology.

Another important challenge in designing a mobile robot isto be able to simultaneously make difficult compromises and tooptimize the design. These are:• Energy Vs Weight Vs Torque. A mobile robot has to carry

its own power source. For a mobile robot powered byelectricity, batteries are an important part of the overallweight of the platform. This influence the torque that themotors must generate to make the platform moves (andlifts it up in the case of AZIMUT). The amount of torqueinfluences the size and the energetic consumption of themotors, closing the loop.

• Size Vs Electronics Vs Heat Dissipation. The size of therobot affects the amount of space available for the onboardcircuitry and wiring of the robot. Minimizing size allowsreducing the weight of the robot, but also decreases theamount of space left for the electronics. This alsocomplicates heat dissipation for the circuits.

• Cost Vs Time Vs Expertise. Normally a limited budget isallocated for the design of a new robot. A schedule is alsodetermined.

MECHANICAL ELECTRICAL

COMPUTER

INDUS. DESIGN

OPERATING CONDITIONS

Figure 10. ITERATIVE DESIGN LOOPS

Following a rigorous design methodology is then veryimportant to assess the risks and to monitor the progress in thedesign. But because a mobile robot is made of so manydifferent components, an iterative design process must befollowed: choices of components must be made, plans must berevised, small prototypes must be developed. The iterative

design loops is represented in Figure 10. All five types ofexpertise must be addressed from the start in the design of arobotic concept. As the concept evolves and the robot isconstructed, the focus shifts from mechanical concerns toelectrical and computer considerations, and design constraints.A full loop between the five domains must be completed ateach phase of the design methodology, before moving into amore detailed phase.

Having historical data on the different elements that affectthese compromises greatly help to optimize the differentcriteria. But since AZIMUT was our first design with suchcomplexity, we did not have access to such data. Eventuallytime runs out and final choices must be made to start theconstruction of the robot. The design team may not always havethe resources or the knowledge (for instance some parts mayhave incomplete specifications) to make the right choice or touse the proper part, and the final design decisions are not easyto make. The overall influences of these decisions can only beseen during the integration phase. Integration of all of thecomponents is the real test to evaluate the design, and its is onlythen that the result of the design can be seen. Duringintegration, the actual use of the robot as controlled by itssoftware elements can give good indications on limits andimprovements of the mechanical and electrical elements. Thevalue of the integration phase and the time allowed to do it areusually underestimated. It should be clear though that theywould be proportional to the number of elements to integrateand their respective complexity.

So, after many iterations and interactions between themechanical, electrical, computer and industrial design groups, afirst prototype of the robot is built. Having outlined the difficultchallenges to overcome when designing a mobile roboticplatform, it is extremely hard to come up with a perfect designwith the first prototype of a complex and new concept of arobotic platform. The main objective of the first prototype is todemonstrate the feasibility of the concept and to outlineintegration issues. There is much value gained in this process.In our case, we evaluate AZIMUT to be functional to 80% ofits capabilities, which is very well considering the complexityof the design and the constraints in time, budget and resources.Modularity at the various design levels is one important aspectthat contributed to such success. Building the first prototypegave the team a very unique expertise in coming up withsolutions to the compromises and optimizations to be made forsuch a robotic platform. This expertise change with the roboticplatform to design and, obviously, starting to build a secondprototype of AZIMUT with a completely new team would notbe as efficient.

The first prototype allowed us to compare desiredspecifications with the real ones from AZIMUT’s firstprototype. Table 3 presents such comparisons. While it waspossible to come close to the desired specifications for thewidth, the height, the body clearance and the articulationblocking torque, the first prototype is heavier than what wasexpected. Also, the articulation lifting torque is lower than whatwe evaluated using the motor specifications and the mechanismdesigned. This, combined with the increased weight, explainwhy the first prototype cannot lift itself up. It can however gofrom its articulations facing down toward the ground. Because


of cost, availability and size issues, we had to select relativewheel encoders instead of absolute encoders. The maximumspeed is also reasonably close to the desired value since in ourtests we limited the power to the motors for safety reasons (wedid not have any replacement motors in case of problems).

Table 3. COMPARISON BETWEEN DESIRED ANDREAL SPECIFICATIONS

Specifications Desired RealWeight 54.4 kg 63.5 kgWidth 68.6 cm 70.5 cmHeight 35.6 cm 38.9 cmBody clearance 7.6 cm 8.4 cmArticulation liftingtorque

96 N.m 26.4 N.m

Articulationblocking torque

96 N.m 88 N.m

Articulationdirection torque

7.5 N.m 25 N.m

Wheel encoders 1024 absolute 1024 relative, withcalibration sensors

Maximum speed 1.5 m/s 1.2 m/s

With all of the different design considerationsmethodology associated with the all of the expertise required ina mobile robot, it is important to come up with tools that willoptimize the iterative design loops necessary in such projects.This is one conclusion reached after completing the firstprototype of AZIMUT. Introducing some tools to the designmethodology, to better take into consideration theinterdisciplinary integration challenges and the expertise gainedby building the first prototype of AZIMUT, would improve theperformance that can be reached in the design. One key elementwould be to derive a Product Architecture (Ulrich andEppinger, 2000), an architecture that includes mechanical,hardware and software considerations, that integrates all typesof expertise. To achieve this goal, the function analysis wouldhave to be built in a functional structure that highlights,between every function, all the flows of matter, energy and datathat are used or transformed on the robotic platform. Groupingthe functions in a fashion that minimizes the flow between themodules would allow determining the subsystems. It is easy toimagine that a Matter flow would be related to the mechanicalcomponents of the robot and the Data flow would be associatedwith algorithmic issues. As for the Energy flow, depending ontechnology choices (e.g., electric or hydraulic), it could beseparated between mechanical or electrical considerations. Theindustrial design sets requirements on the geometricadjustments of the subsystems. Choosing subsystems thatminimize the interfaces (flows) between each other is the key toan optimal modular design. It also considerably reduces thetime needed for the integration phase. This functional structurewould then be a common starting point for all the designers.

During the design process, it is important to keep track ofthe interrelations between the subsystems and their parts. To doso, several graphic tools (flow charts, organization trees, 3Dassembly design) would be elaborated to outline everyinterrelation between the subsystems in terms of flows (matter,energy and data), geometrical layout and control sequences.

The Product Architecture would be updated and detailed tofollow the state of the design at every phase of the process andto include all the robot parts (selected or custom designed) andto follow the evolution of all interrelations. Requirements andspecifications would be identified for each interrelation. Theserequirements and specifications would address mechanical,electrical, computer or industrial design considerationsdepending on which type of flow they are associated with in thefunctional structure. This tool would provide a mean to quicklyidentify conflicts between the subsystems and the compromisesto be made between the different fields of expertise. Byproviding unifying design tools, it will be easier for theoperational experts to better follow the design process at alllevels, to insure that the design meets all of the operationalconditions prevailing in the environment in which the robot willbe used. Our goal is that such tools would reveal to be veryuseful for the design of any types of mobile robots.

CONCLUSIONThe main issue that this paper addresses is that integration

of technologies and expertise is the most fundamental challengewhen designing a sophisticated mobile robotic platform. Thekey factor required to take on this challenge is to be able toestablish strong interrelations between mechanical, electrical,computer, industrial design and operational expertise. Threetypes of compromises and optimization factors must be closelyexamined through the design iterations to come up with the bestpossible choices for the robot. Nevertheless, these choices canonly be validated through the integrated implementation ofcomplete prototypes. This first experience in designingAZIMUT provides interesting clues on integrated design toolsto help in making complex mobile robotic platforms. In futurework we hope to be able to develop and refine such tools.

Technological progress will continue in the future to pushthe limits of sensors, actuators and processing, allowing thecreation of mobile robots that are more and more sophisticated.This trend is confirmed by the high number of new roboticplatforms introduced in the last five years (e.g., Aibo and SDR-4x from Sony, Asimo from Honda, just to name a few). Tobenefit from such advances, we need to adopt a modularapproach at all levels of mobile robot designs so that we can re-exploit and upgrade components easily. We have tried tooutline all of this by describing the design of our AZIMUTplatform, a robot equipped with four independent leg-track-wheel articulations capable of 3D movements. The control ofthe robot is distributed through its onboard subsystems. In thenear future we hope to build a second prototype of AZIMUT,overcoming the limitations identified in the first one. In futurework, we want to come up with a set of mechanical-hardware-software-design components that can be reused in multipletypes of design, robotic or not. We also want to propose adesign methodology that will allow to exploit such modules andto derive new ones, making it possible to maximize theperformance of mobile robot prototypes designed.


ACKNOWLEDGMENTSF. Michaud holds the Canada Research Chair (CRC) in

Mobile Robotics and Autonomous Intelligent Systems. Thisresearch is supported financially by CRC, CFI and the Facultyof Engineering of the Université de Sherbrooke. The authorswant to thank the other participants in the project: M artinDeschambault and Hugues Rissmann from the Department ofIndustrial Design, Université de Montréal; Éric Desjardins,Patrick Faucher, Marc-Antoine Fortin, Hugues Lavoie, FrédéricRivard, Marc-Antoine Ruel, Victor Bao Long Tran from theDepartment of Electrical Engineering and ComputerEngineering, Université de Sherbrooke. Special thanks toFrançois Charron and Patrik Doucet, Department ofMechanical Engineering of the Université de Sherbrooke, fortheir support relating to concurrent engineering methodology.A patent is pending on AZIMUT.

REFERENCESChen, C.T. and Hsieh, Y.A., Mobile Robot, US Patent

6,144,180, November 7, 2000.Digney, B.L. and Penzes, S., “Robotic concepts for urban

operations”, Proceedings SPIE 2002.Estier, T., Crausaz, Y., Merminod, B., Lauria, M., Piguet,

R. and Siegwart, R., "An innovative space rover with extendedclimbing abilities", Proceedings of Space and Robotics,Albuquerque, USA, February 27-March 2, 2000.

Halme, A., Leppänen, I. and Salmi, S., “Development ofWorkPartner-robot – Design of actuating and motion controlsystem”, Proceedings Second International Conference on

Climbing and Walking Robots, Portsmouth, England, 13-15September 1999.

King, E.G., Shackelord, H.H. and Kahl, L.M., StairClimbing Robot, US Patent 4,993,991, February 19, 1991.

Lauria, M., Piguet Y. and Siegwart, R. “Octopus - Anautonomous wheeled climbing robot”, Proceedings 5thInternational Conference on Climbing and Walking Robots,2002.

Matthies, L., Xiong, Y., Hogg, R., Zhu, D., Rankin, A.,Kennedy, B., Hebert, M., Maclachlan, R., Won, C., Frost, T.,Sukhatme, G., McHenry, M. and Goldberg, S., “A portable,autonomous, urban reconnaissance robot”, Proceedings 6thInternational Conference on Intelligent Autonomous Systems,Venice, Italy, July 2000.

Shen, W.-M., Salemi, B. and Will, P., “Hormone-inspiredadaptive communication and distributed control for CONROself-reconfigurable robots”, IEEE Transactions on Roboticsand Automation, 18(5), October 2002.

Steeves, C., Buehler, M. and Penzes, S.G., "Dynamicbehaviors for a hybrid leg-wheel mobile platform",Proceedings SPIE 2002.

Ulrich, K.T. and Eppinger, S.D., Product Design andDevelopment, Prentice Hall, First Edition, November 2000.

Volpe, R., Balaram, J., Ohm, T. and Ivlev, T., “Rocky 7: Anext generation of Mars rover prototype”, Advanced Robotics,vol. 11, no 4, 341-358, 1997.

Ylönen, S.J. and Halme, A.J., “WorkPartner – Centaur likeservice robot”, Proceedings IEEE/RSJ InternationalConference on Intelligent Robots and Systems, Switzerland,October 2002.

co-design of azimut, a multi-modal robotic platform

Documents