Realisation of an energy-efficient walking robot

University of Twente

EEMCS / Electrical Engineering

Control Engineering

Realisation of an energy-efficient walking

robot

Edwin Dertien

M.Sc. Thesis

Supervisors

dr.ir. S. Stramigioli ir. V. Duindam prof.dr.ir. J. van Amerongen

June 2005 Report nr. 022CE2005 Control Engineering

EE-Math-CS University of Twente

At the Control Engineering department of the University of Twente a number of simulation models of ’passive dynamic’ walking robots have been developed in the recent years. These models need validation with a ’Real world’ example. The goal of this Master‘s project is to realize a working walking robot. The assignment comprises the modeling, design and construction of the necessary mechanics, actuators, sensors, controllers and embedded electronic infrastructure.

Previous research has shown that efficiency of a walking robot can be increased by adding (nonlinear) springs. These springs store the energy used for deceleration of the swing leg, which is normally supplied by a braking motor.Instead of using real springs, the hardware setup enables the use of virtual or ’emulated’ springs in order to determine the possible gain in efficiency.

A detailed 20-sim model was made of the entire robot, including actuation, control and interaction with the environment. The mechanical setup was designed using CAD tool packages and built with custom made aluminium parts.

A number of electronic systems such as controller boards, motor amplifiers and sensor interface circuits were design and built. All electronics are connected using a TWI bus system with a custom communi-cation protocol.

Since 1997 I have been studying Electrical Engineering, and this project is in a number of ways the ‘Grand Finale’ I was hoping for. Not in the least part because I have been bragging for a long time that I wouldn’t finish my studies, unless my Master‘s project’s subject would be able to reach the presentation room on its own power.

I would like to thank Stefano Stramigioli and Vincent Duindam for their input in the project, for the useful discussions and their support and enthusiasm.

The construction of the biped would have not been possible without the effort of a lot of people. I would like to thank prof. Hermans Soemers for his useful advice and Niels Beekman for the pleasant cooper-ation on the design. The people at TCO, in particular Theo P ¨unt have done a great job on all the robot hardware. I would also like to thank all employees and students of the CE laboratory under supervi-sion of prof. J. van Amerongen for making this project a pleasant time. The good work-atmosfere was absolutely there, thanks to the cooperation with Gijs van Oort. I think we owe a sincere apology to the rest of the people at CE for needless singing and humming, consuming a lot of Lab space, late lunching, taking up a lot of space, time and machine-contents in the coffee room and other misbehaving.

Furthermore I would like to thank my parents, friends, ‘de Parkweg 87 meubelstukken en uitpandige inboedel’, family, and especially my wife Daphne, for their support allowing me to finish this project.

Enschede, June 2005

1 Introduction 1

1.1 Introduction . . . 1

1.2 Report overview . . . 2

2 Analysis 3 2.1 State of the art overview . . . 3

2.2 Proposed design . . . 4

2.3 Energy consumption . . . 4

2.3.1 Elasticity . . . 5

2.3.2 Hardware implementation . . . 5

2.3.3 Elastic Adaptive Tuning . . . 5

2.3.4 Emulation by Control . . . 7

2.3.5 Conclusion . . . 8

2.4 Modeling . . . 8

2.4.1 Parameter estimation . . . 8

2.4.2 Simple leg model . . . 9

2.4.3 Model of complete system . . . 11

2.4.4 Power consumption . . . 15

2.4.5 Specific Cost of Transport . . . 16

2.4.6 Conclusion . . . 16

2.5 Requirements . . . 17

2.5.1 Introduction . . . 17

2.5.2 Mechanics . . . 17

2.5.3 Actuator . . . 18

2.5.4 Control . . . 18

2.5.5 Sensors . . . 19

2.5.6 Electronics architecture . . . 23

2.5.7 Conclusion . . . 25

3 Design and construction 27 3.1 Electronics . . . 27

3.1.1 Field bus . . . 27

3.1.2 Microcontroller . . . 29

3.1.3 Motor amplifier . . . 30

3.1.4 Joint interface . . . 39

3.1.5 Torque sensor interfacing . . . 42

3.1.6 Main controller board . . . 43

3.1.7 Power supply . . . 47

4 Results 53

4.1 Motor test setup . . . 53

4.1.1 Setup description . . . 53

4.1.2 Results . . . 54

4.2 Joint interface test setup . . . 55

4.2.1 Setup description . . . 55

4.2.2 Results . . . 56

4.3 Leg test setup . . . 56

4.3.1 Setup description . . . 56

4.3.2 Results . . . 57

4.4 Complete walker test . . . 57

4.4.1 Setup description . . . 57

4.4.2 Power Consumption . . . 57

4.4.3 Results . . . 60

5 Conclusions 61 5.1 Conclusions . . . 61

5.2 Recommendations . . . 62

A 20-sim models and code 65

B Motor amplifier schematic 69

C Encoder interface schematic 73

D Torque sensor interface schematic 75

E Main controller schematic 77

F PCB layouts 81

G Command syntax summary 85

Introduction

1.1 Introduction

In the field of Robotics there has always been a desire to build a general-purpose humanoid (humani-form) Robot. Apart from the search for the ‘Frankesteinian’ grail or the desire to build a Golem (broader discussions on this topic can be found in a lot of recent and more dated Science Fiction literature) build-ing humaniform robots has quite a logical goal. Human society is built by humans, or humaniform beings, typically bipedal organisms of on average 1.70m high. When one wants to design robots that are able to operate in the same society or the same environment as humans do, it is a logical decision to design robots that have roughly the same size and configuration as humans do, in order to make them able to function in their environment.

Thresholds, doors and staircases are common elements in a human environment. For mobile robots on wheels they however prove to be obstacles which are hard to tackle. In order to ensure mobility of an artificial structure in a human environment, legged propulsion, more specifically bipedal legged propulsion seems a logical solution.

This is the reason for ambitious research projects in the last decades. Universities and private R&D companies designed and build numerous walking structures. Large companies like Honda achieved world-fame by their ‘Asimo’ robot programme. ‘Asimo’ has the size of a child and is able to walk, grasp objects, follow people around, etc.

Figure 1.1: Honda’s ASIMO and P3 robot

The energy-consumption of a robot like ‘Asimo’ however is tremendous, in the order of magnitude of hundreds of Watts. It needs to carry around several kilograms of batteries for a short time of au-tonomous operation. To be precise, according to [21], Asimo uses a 10 [Ah] 38.4 [V] battery for 30 min-utes of operation. Some researchers are gradually abandoning the standard design paradigms yielding the ‘Asimo’ and alike projects. From an industrial point of perspective on robotics, the accuracy and speed of the positioning of a robot actuator are the most important design criteria. Links between actu-ators are designed to be as stiff as possible, so that the machines can operate in a bandwidth as large as possible. This bandwidth is limited by the eigenfrequencies of the system.

behaviour of a system and use it to their advantage.

For design and construction of walking robots, two design paradigms exist with on the one hand the ‘industrial’ approach, and on the other hand the so-called ‘passive dynamic walking’ approach. The latter was brought under attention by the works of McGeer [16]. Key of this approach is a bottom-up method for designing walkers. Starting from a very simple (mathematical) walker, consisting of two legs and one hinge-point (the simplest walker model) a bottom up construction of walking bipedal structures is derived which eventually will lead to a complete functioning biped.

The goal of the research on walkers at the CE group is to take a position somewhere between the two design paradigms (Passive Dynamic vs. Full Control), by incorporating the usage of natural dynamics of a walker, combined with more advanced actuation and control. At the CE laboratory S. Stramigioli has started research on walking robots using Port-Hamiltonian based modeling techniques. by PhD student V. Duindam a number of simulation models of dynamic walking biped robots have been de-veloped in the recent year. These models need validation with a ’Real world’ example. MSc student N.Beekman started in 2004 on the design of a walking robot. The starting point for this MSc project is the design of a biped robot which has been discussed by N. Beekman [4]. In this thesis there will be a lot of references to his project, mainly because there has been an overlap in time between the two projects. V. Duindam [8], lead by S. Stramigioli, has made models in 20sim of controlled and uncontrolled biped robots which have been used by [4].

The goal of this MSc. project is to build and control a physical 2D walking bipedal robot. This implies modeling and design of actuators, sensors and processing electronics capable of emulating various experimental set-ups.

1.2 Report overview

In Chapter 2 an analysis will be given of the criteria and requirements for the walking robot leading to the design as discussed in Chapter 3. In Chapter 4 the results of intermediary and final tests will be given. Conclusions and recommendations are discussed in Chapter 5.

Although the robot is not a living being, due to its close similarities with walking animals the words ‘knee’, ‘hip’, ‘ankle’ and ‘foot’ will be used to indicate the joints and several body parts.

Acknowledgements

Analysis

In this chapter the models and calculations leading to the requirements for the walker will be discussed. These discussions are based on the design and simulations done by [4], models made by V. Duindam and S.Stramigioli [8] and previous research done at the Delft Biorobotics LAB [27].

First in Section 2.1 a short overview of the current state-of-the-art will be given. The following Section 2.2 discusses briefly the design as proposed in the MSc thesis of N. Beekman [4]. Section 2.3 discusses the mechanical adaptations necessary for minimizing energy consumption. Section 2.4 de-scribes the 20-sim models used for verification of controller settings and tests whether the robot can walk. The last Section 2.5 summarises the requirements for the rest of the design.

2.1 State of the art overview

McGeer [16] built entire passive slope-walking constructions, which were verified and tested again by Ruina et al. at Cornell University [17]. Wisse [27], van der Linde [25] et al. at Delft Technical University designed and build a number of air muscle powered walkers, based on the principles of ‘passive dy-namic walking’. Their latest model is shown in figure 2.1.‘Denise’ can walk on two legs, maintaining 3D stability by a lean-to-yaw coupling mechanism (as can be found in bicycles and skateboards) in the feet. All of their models use relatively simple control systems and are able to walk in a straight line. In the previous theses on the modeling and design the basic outlines for the design of the walker were given. This MSc project has as main goal the realisation of the mechanics, actuation, electronics and control system.

2.2 Proposed design

A tubular construction was chosen as base for the robot hip, for its good rotational accuracy, and be-cause tubes have a very good stiffness-to-weight ratio. The legs are designed in a modular way, consist-ing of tubes and separate foot and ankle modules. In [4] an actuator is mentioned, its selection based on his simulation results. The robot has four legs. Similar to experimental models from [27] these four legs guarantee stability in the sideways direction so the robot can only fall forward or backward. This ensures that getting a stable walking gate is now a 2D problem instead of a 3D problem. This also means that the robot can only walk in a straight line.

The hip is the only actuated joint. The feet and knees are free-swinging unactuated joints. The knees have a locking mechanism, to prevent the robot from falling when that knees have to support the robots weight. This occurs when the legs become the ‘stance legs’ of the robot.The desire to put all necessary electronics, actuator and power supply inside this tube of 6 [cm] diameter, 60 [cm] long, poses together with the goal of autonomous mobility large constraints on the electronics design.

Figure 2.2: SolidWorks drawing of the proposed design

2.3 Energy consumption

As Wisse stated in his phd dissertation [27], walking is nothing more or less than a continuous falling motion, where the robot prevents hitting the floor by moving its swing-leg fast enough forward so it can become the next stance-leg. This holds in a 2D situation and has been proven by analytical models and simulation. G. van Oort [26] proves that the same principle will work in a 3D situation too, with an analytical model with massless (so infinite fast placeable) legs. In a real robot however the legs are not massless, and it will take energy to move them forward. For an autonomous moving robot, energy consumption is a big issue. As stated in the introduction, key of the ’passive dynamic’ approach is to minimise energy consumption to ensure autonomous mobility.

As mentioned in [4], Chapter 4, during certain points of the swing-phase of a leg energy needs to be dissipated in order to get the leg into the right position for becoming the new stance-leg. In order to do so in a straightforward design, normally energy is dissipated by the motor by actively braking the current movement.

A more energy-efficient approach would be the use of an elastic element or a spring, specially de-signed for storing the superfluous mechanical energy during the swing forward, and releasing this energy when the new swing phase starts. In his thesis Niels discussed the design of a non-linear spring for this purpose. A 6th order polynomial curve fitting was performed in order to get model which can be used in 20-sim.

This section will discuss the design of an elastic element for saving energy during swing phase of the robot leg.

2.3.1 Elasticity

Although [4] used polynomial curve fitting for determining the desired nonlinear profile, The basic shape that was required according to the model was nothing more spectacular than a normal linear spring with a large backlash (see [4] page 22, fig 4.3). In future simulations with realistic parameters could come up with different nonlinear behaviour. In that case a mechanical realisation of a nonlinear spring will be necessary.

2.3.2 Hardware implementation

In this section a mechanical outline is proposed for building this non-linear spring physically, by means of a special designed cam structure. This method allows mapping of the desired spring behaviour to the cam profile.

A normal linear spring can be given a non-lineair behaviour by connecting it to a cam structure which has the desired profile. The linear plot of the spring-curve could be converted to polar coordi-nates and then be directly mapped to the cam profile. This setup is displayed in figure 2.3.

A point of attention with this setup is that it is only possible to build monotonous rising curves. If a certain dead zone is necessary, it is not possible to include that the same structure, because it would require an infinite thin shaft. It is however possible to give the tendon connected to the spring a certain slack. This slack would determine the dead-zone in the spring curve. The minimal spring constant is given by the minimal shaft thickness. The spring constant of this structure is determined by the constant of the used spring and the radius of used cam profile.

2.3.3 Elastic Adaptive Tuning

A simple realisation of a dynamically adjustable spring is a McKibben muscle or Air-muscle. It allows both pressure and position control, being compliant devices in themselves. According to [25], pg 599-604, the formula for their behaviour is given by:

F= b2P0

2πn2_L

0∆L (2.1)

where

F muscle force

b length of weave threads

P0 relative muscle pressure

n number of turns in a weave thread

L0 muscle rest length

∆L relative muscle extension

The principle behaviour of the muscle can be described as a linear spring with a spring constant propor-tional to the muscle pressure. By varying the pressure depending on the actuators position, a non-linear elastic behaviour can be generated. The use of McKibben muscles however has a number of practical implications which are described in for example [28]. When only the elastic behaviour is desired, and

TorqueT = ∆xKs

Fx=Ksx φ

r r

Figure 2.3: Cam structure

needs to be tuned to an exact profile, a passive construction is more desirable.

The cam structure as presented in the previous section has a behaviour given by

˙

x=φ˙r(φ)

∆x=

Z _φ

0 r(φ)dφ

Fcam(φ) =Ks∆x (2.2)

where

F the elastic force

φ the rotation angle of the cam

r(φ) the profile imposed on the cam

ks the spring constant of the linear spring

In formula 2.2 the effect of the tendon length and angle is neglected, or supposed of infinite length. According to this formula, the elastic force is linear dependent on the imposed profile.

T(φ)

φ

Figure 2.4: Cam structure with resulted spring curve

This construction would enable the elastic element to be dynamically tuned. The profile could be adapted during the walking motion in order to use the spring as an efficient energy storage facility thus minimising the total required energy by the walker. Apart from the parallel approach (having a spring parallel to the motor output, the motor acting as a effort-source (completely backdriveability is necessary), also a series approach could be promising. The motor can act as a flow source (generating a torque). The spring should be chosen with an order of magnitude matching the necessary eigenfre-quency of the system for a stable walking gate. By adding the output torque of the motor, the output torque of the spring can increased or minimised.

2.3.4 Emulation by Control

In order to investigate the possibilities of energy conservation by use of an adaptive elastic element, for this project emulating approach was chosen. Instead of experimenting with cam shapes or other spring models, the entire spring is simulated within the controller. By isolating this part in the control domain, the possible gain in energy-efficitncy can be calculated. Various spring shapes and profiles can be tested before adding them physically to the robot. This method requires measurement of the output torque in order to feed it back into a model of the ‘virtual’ spring part.

IPC

In [23] a control philosophy called ‘Intrinsically Passive Control’ is being discussed. In an IPC con-trolled system the controller consists of two parts: the IPC part and a supervisory part. Goal of IPC control is to keep the controlled object ‘passive’ when interacting with its environment. This goal how-ever conflicts with the motive of the controller itself: moving a mass (in this case a leg) from pointa

to pointb. Therefore the supervisor part is added, in order to control the IPC model. The IPC ‘adds’ a virtual spring, damper and mass to the system, giving the object that needs to be controlled, in our case the mass of a leg, interacting with the world, an intrinsic passive behaviour. By not controlling the leg mass directly, but by having the supervisor control the virtual mass connected by a virtual spring to the robot, the robot will continue to act passive in contact with the ‘real’ world, but will be able to ’do’ something.

VMC

propulsion. The basic oscillation motion of the walking robot can be described by a mass-spring system with some non-linearities. A non-linear spring could be mapped exactly to the required torque-velocity profile the power source is currently providing. The only energy this power source should have to add is the compensation for the loss in energy due to friction and foot impact.

Emulating springs directly in the hip is a different usage of the same idea in the one-dimensional case. Oscillating modes of the robot can be represented by a mass-spring system. The motor driving this mass-spring system has to emulate a frictionless movement. For the used actuator setup this will require good backdriveability, by compensating for the friction loss in the gearbox. The ’actuator part’ of the actuators output has to compensate for friction losses in the robot and the energy loss on floor impact. The ’mass-spring’ part of the actuator has to emulate the ideal mass-spring system.

2.3.5 Conclusion

A number of mechanical options exist to build a nonlinear elastic element suitable for storing energy during the end of the swing phase of a leg. It can be done by adding a specially designed spring to the existing actuator, or by replacing the actuator by a dynamic adjustable elastic element. In order to keep the design process simple, and to facilitate testing with multiple setups, the choice has been made for a force-controlled actuator, capable of mimicking the behaviour of a spring inside its controller algorithm. This leaves the way of adding a specialised tuned elastic element later, when the desired behaviour has been determined. The used actuator should be equipped with both a position and a torque sensor in order to experiment with different control strategies.

2.4 Modeling

Simulation in 20-sim has been used to find an answer to two questions regarding the design:

• How large is the required output torque of the hip actuator

• Will the robot walk with the expected mass distribution

In this section the used 20-sim models and their results will be discussed. In order to walk, the most important thing the robot has to do is to put one leg in front of the other leg. This has to be done fairly quick. As Wisse defended in his phd thesis [27]: ’By quickly moving the swing leg to a preset forward position, the chance of a fall forward is reduced and can theoretically even be removed completely’. The latter clearly holds when a leg can be put forward instantly, or at an infinite speed.

In the simulations of [4] a maximum torque of 12 [Nm] was required. These models were based on rough estimates of the masses. In the simulations no experiments were done with limitation of the output torque using the several control schemes.

The first goal of the simulations in this theses is to verify the torque necessary to put the non-ideal leg forward fast enough to maintain a steady walking gate and to compensate for the energy-loss on foot impact an other friction in the system.

In order to get enough ground-clearance the legs have knees. The knees will bend if the motor causes a high acceleration in the upper leg part, so the lower leg will linger behind, causing the knee to bend giving the feet some ground-clearance. This will also be tested by simulation. The largest problem with the simulation of the complete walking robot is the role of the contact modeling for feet impact. Upon impact the robot will lose energy to the floor, it is possible that the feet will bounce, or more or less stick to the floor (full non-elastic contact)

2.4.1 Parameter estimation

evenly acros the leg. A rule of thumb for a beam with an evenly distribtued mass [22] is that it can be simplified to a point mass of1₃of the total weight at the same distance. In a simplified model, displayed in figure 2.5 the torque required by the motor to lift a leg is given by 1₃lmgsin(φ)withφ=1/2π[rad], m = 3.0 [kg], l = 1.0[m]. To lift the leg in horizontal position, this would require a torque of 10 [Nm]. To keep the leg in a position of 0.5 [rad] the required torque is 5 [Nm]. These values are consistent with the simulation values of [4].

T orque=1

3mglsin(φ)

φ

mred=13m

F=mg

F=mgsin(φ) l

Figure 2.5: Simple torque calculation

2.4.2 Simple leg model

A simple 20-sim model was made using these mass values modeling the behaviour of a single leg. Goal of this simulation is to determine the ground clearance of a swing leg while passing the stance leg. In figure 2.6 the used 20-sim model is shown. The model consist of a submodel of the mechanics generated by the ‘3D-mechanics editor’. Figure 2.7 shows the 3D animation, viewed from the side. The simulation plots in figure 2.8 and 2.9 show the knee angle, hip angle and groundclearance.

Figure 2.6: 20-sim model of the single leg and control

Groundclearance

Figure 2.8: Simulation results of hip angle, knee angle and groundclearance

Groundclearance

Figure 2.9: groundclearance

In the test a simple controller was used switching the leg back and forth. The knee joint is frictionless and has two end stops. The groundclearance is given by theH0

2.4.3 Model of complete system

Goal of modeling the complete system is to verify whether the robot will walk using the specified motor and given mass distribution. The following components need to be modelled:

• 3D mechanics of hip, legs and joints

• Maxon RE40 motor with gearbox

• Control sequence

• Contact models for interaction with the ground

The 3D mechanics of the robot have been modeled by the ‘3D Mechanics Editor’ of the ‘3D Mechanics Toolbox’ in 20-sim. The 3D scenery is shown in figure 2.13. The mass distribution in the hip was calculated manually and added to the model outside the editor environment.

The Maxon RE40 motor is modeled in great detail by the ‘Servo Motor Editor’ in the ‘Mechatronics Toolbox’. The gearbox was modelled by a non-ideal gearbox component from the IPM set. The com-plete 20-sim model is shown in figure 2.11. The motor and gear IPM model are shown in figure 2.12.

For modeling the contact of the robot feet with the ground a stiff compliant contact has been used, as described by [8]. In figure 2.10 a schematic drawing (made by [8]) is shown. Between two objects the closest points (a) are monitored. When they touch, when length of vector between points is zero(b) instantaneously a spring-damper pair is formed (c). Depending on the momentum on impact and the damping both objects will stay in contact or bounce off.

For modeling the impact of a foot on the ground this model is used, with a very stiff compliance and high damping (critically damped), so the foot does not bounce. This approach does slow down simulation because the small time constants introduced by these stiff springs. The same approach is also used for modeling the end stops in the knees.

Figure 2.10: Schematic drawing of compliant contact

A compliant contact modeled according to the coupled spring-damper as mentioned above has a behaviour described by equation 2.3. This way of modeling a contact has the disadvantage that the contact surfaces tend to ‘stick’ to each other. Upon release of the contact, the damper and spring work in the wrong direction: retracting the objects from each other requires a force, while this is not the case in (intuitive) behaviour of a contact.

Fcontact(x, ˙x) = ½

−Kcx−Dcx˙ ifx≥0

0 ifx<0 (2.3)

where

Kc the contact spring constant

Dc the contact linear damping

x the contact penetration(xground−xf oot) ˙

x contact penetration depth

for small contact areas equation 2.3 becomes

Fcontact(x, ˙x) = ½

−Kcxn−(Dcxn)x˙ ifx≥0

0 ifx<0 (2.4)

where

n dependant on the surface geometry and material, between 1.0 and 1.5

This term was added in the 20-sim model of the floor, withn = 1.0. In 20-sim a multi-dimensional spring-damper construction was used, with the same constants in x, y and z direction. For the Hunt-Crossley term only the z-direction was taken in account, because ‘stick’ in x or y direction will not affect the walking behaviour dramatically, and would probably even prevent the feet from excessive slip. The rotational forces in the foot - floor contact are also assumed to be zero. In the 3D case in 20-sim the contact force is calculated as follows (equation 2.5)

x=



 x_x1₂

x3



_{=xf loor−xf oot}

W=

µ

m f

¶

=

µ

r∧F

F

¶

=

µ 0

Fcontact ¶

,r=0

Fcontact=−Kcx−Dc|x3|x˙ (2.5)

where

x the distance the foot ‘penetrates’ into the floor

W the force (Wrench) on the floor. Only linear forces are taken in account. ˙

x the translation part of the Twist of the foot expressed in the frame of the floor.

The 20-sim code can be found in Appendix A. The floor models were made using equation models connected to a power-port on the foot. The values forKcand Dc were determined by setting a very high value forKcand than increasing Dc until the floor was critically damped. The value forKcis a trade off between simulation speed and ‘genuineness’ of the outcome. The value must be so high that the foot does not settle visibly into the floor (the distance the foot sinks into the floor must not affect the simulation), but not unnecessarily high, otherwise the simulation time will increase too much. In the simulationKcandKdare both set at 10000.

The control sequence is a simple PD-controller which shifts it setpoint on foot-impact. For experiments the initial control values were chosen as follows: As setpoint 0.3 [rad] was chosen. This value was used in many simulations by [4], [8] and [27]. The controller gain was set at 10.

The specifications of the suggested motor with gearbox are listed in table 2.1 and has a torque-to-current (Tcr) ratio of 1,45 [nM/A] as follows from equation 2.6.

Tcr=kmotorηgearboxngearboxηmotor (2.6)

where

kmotor Motor constant = 0.0302[Nm/A] ηgearbox Gearbox efficiency = 72%

ngearbox Gearbox ratio = 1:74 ηmotor Motor efficiency = 90%

Figure 2.11: 20-sim model of the complete walker

Figure 2.12: 20-sim model of the motor

equations

phip = limit (( - khip *( theta [1] - hipsetpoint ) - dhip *( ddt ( theta [1]) ))>> , -8 ,8) ;

if ( contact2 == true and theta [1] >0) then hipsetpoint =- hipsp ;

lock1 =0; lock2 =1; end ;

if ( contact1 == true and theta [1] <0) then hipsetpoint = hipsp ;

lock1 =1; lock2 =0; end ;

The specifications of the motor and gearbox that were selected based on simulation results by [4] are listed in table 2.1. In the controller the current through the motor has been limited to 8 [A]. With the given torque constant and gearbox efficiency this sets the maximum output torque of the motor and gearbox at 72% * 74 * 8 [A] * 0.0302 [Nm/A] = 12.8 [Nm].

Maxon RE40 motor

Nominal Voltage: 24 [V]

Torque constant: 30.2 [mNm/A] Continuous Torque: 181 [mNm] Stall Torque: 2290 [mNm] Starting current: 75.9 [A]

Maxon GP42c gearbox

Ratio: 1:74

Efficiency: 72% Inertia: 15 [gcm2_]

Table 2.1: Motor specifications

Experimental results

The robot walks with a proportional gain of 10 and a setpoint of 0.3 [rad] as can be seen in figure 2.14. In this figure the hip angle, hip torque, motor current and ground clearance are displayed. The peaks in the hip torque are caused by knees hitting their endstops and foot impact an the floor. Multiple-simulation runs were performed with a simple criterion: will the robot reach a stable limit cycle or not. In order to determine that fact simulations were run over a period of 20 [sec]. Simulation results will be displayed in appendix A

With a Controller gain of 10 the robot walks with setpoints varying from 0.15 [rad] to 0.45 [rad]. At 0.15 [rad] the ground clearance is 0.5 [cm] which is very minimal, causing the robot to fall after 13 steps. With a setpoint of 0.5 [rad] the robot will walk too fast, so that the swing legs cannot become stance legs in time and the feet will hit the floor before the legs are fully stretched. With these settings the robot falls after 6 steps. With a setpoint of 0.45 [rad] the robot does not fall (in a simulation run of 20 sec). The current consumption however increases with an increasing setpoint. With a 0.45 [rad] setpoint the current clips to the preset level every step. With a 0.3 [rad] setpoint the current has peaks of only 5 [A].

Figure 2.14: Simulation plot of the robot walking with setpoint 0.3 [rad]

for these controller gain settings. Without a differential gain in the controller the robot walks with a proportional gain varying from 2 to 12. For larger values of the proportional gain the ground clearance increases, but the current consumption also increases. For smaller gains the ground clearance is not sufficient.

2.4.4 Power consumption

The consumed power in the model is calculated byp = |ui|. Negative power is not possible because the motor amplifier that will be used will not have the capabilities of conserving power (i.e. by a four-quadrant amplifier). In figure 2.15 the used model is given.

Figure 2.15: Averaging the absolute electrical power

The desire is to minimise this component by adding tuned springs, as discussed in [4]. Of course this 6 [W] does not include the power needed for control and for the knee-locking mechanism.

Figure 2.16: Power consumption of the walker with a 0.3 rad setpoint and controller gain 10

2.4.5 Specific Cost of Transport

In [21] a comparison in efficiency is made between different walking robots existing today. As criterion for the comparison the ”Specific Cost of Transport”,cet= (used energy)/(weight [N])(distance traveled). A related criterion is the cmt value which takes only the amount of energy used by the actuator in account.

From the simulation plots the following data is derived: 13 steps, covering 4.10 [m] in 8.5 [s]. This results in a step frequency of (13 / 8.5 = ) 1.5 [Hz]. The walking speed is (4.1 [m] / 8.5 [s] = ) 0.48 [m/s]. The robot’s total weight in the simulation is 9.0[kg]. From simulation data only thecmt value can be derived, because no other energy than the motor (+gear and friction losses) have been simulated.

For this simulation thecmt= (6 [W] / 9 [kg] * 9.8 [m/s2] * 0.48 [m/s]) = 0.14

According to the data in [21] the cmt value for the ASIMO robot is 1.6. Thecmt value for T.U.Delft’s ‘Denise’ robot is 0.08. The cmt value for humans is 0.05. From this data can be concluded that the robot in simulation is at least 10 times as energy-efficient as the ASIMO robot, and half as efficient as T.U.Delft’s ‘Denise’.

2.4.6 Conclusion

and 10 will be used. Furthermore a control algorithm switching setpoint on foot impact is a good first choice for testing whether the robot can walk.

The energy efficiency is reasonable for a ‘passive dynamic’ walker, being less than twice as large as Delft’s latest model. With improved control it is very likely that the efficiency can be enlarged, espe-cially when adding energy-based control and elastic elements as discussed in [4]. Also the weight of the batteries has not been included in this calculation, which will increase thecmtvalue.

A brief summary of the resulting specs from simulation:

• Step frequency = 1.5 [Hz]

• Walking speed = 1.7 [km/h]

• Total robot weight = 9.0 [kg]

• Average power consumption = 6 [Watt]

• Mechanical energy efficiencycmt= 0.14

• Setpoint: 0.3 [rad], controller gain 10

2.5 Requirements

2.5.1 Introduction

With the given specifications for output torque of the motor, the tubular design and the demand of mo-bility the main design criteria were given. They place heavy constraints on size and power consumption of the electronics and actuators. The demand is that the electronics will fit inside the tubular construc-tion (e.g. being a tube with a diameter of 6 [cm]) and need to be powered by a mobile power source (e.g. batteries or accumulators). In this section the requirements for the design will be summarised.

2.5.2 Mechanics

Hip

The mechanics of the robot consist of the actuated hip joint, four knee joints with locking mechanisms and four feet. The required torque has been discussed in the previous chapter. This torque has to be transferred from the actuator to the legs. Because the tubes are connected with two ball-bearings adding a third bearing (being the motor shaft) would lead to a static over-defined situation. Therefore an axial decoupling in the form of an Oldham-coupling has to be added. In the same drive line also the torque sensor needs to be fitted.

Feet

The feet of the robot will be simple ’expanded’ point feet. The influence of the shape of the feet needs to be as minimal as possible on the walking behaviour. As McGeer [16] already investigated, a curved foot shape has a very positive influence on stability of the walking gate. It is however the idea for this design to make it as similar to an ideal compass like walker as possible. The feet will have a small footprint, but will be covered with a rough material to prevent slip on the floor. Sensors need to be placed in the ankles to measure the angle of the legs with the floor. A SolidWorks drawing is depicted in figure 2.17

Knees

Figure 2.17: SolidWorks drawing of the foot

Figure 2.18: SolidWorks drawing of the knees

2.5.3 Actuator

From analysis and simulation results a torque requirement for the hip actuator is given: at least 12.0 [Nm] constant torque, pulses of 15 [Nm] should be no problem. The movement range for this actuator is short, the angle between the legs never needs to exceed 1.0 [rad]. Although the actuators that can be suitable for a movement like this can be rotational as well as linear actuators (which can translate their linear movement to the desired rotational by simple leverage) a rotational actuator seems the most obvi-ous choice. Apart from these requirements, the choice of actuator is also limited by mechanical design. The actuator has to fit in the proposed tubular construction,has to be powered by mobile power source. The power requirements should be reasonable low: an operating voltage in a range that can be sup-plied by batteries. Furthermore the actuator needs good controllability, little backlash and no excessive friction, because the system should be as backdrivable as possible. Simulations were performed using a Maxon RE40 type Brusched DC motor on 24V volts with a Maxon GP42C 1:74 Gearbox, meeting the specifications.

2.5.4 Control

Previous research has shown that the robot can walk with very simple control rules. Wisse [27] con-trolled his robots by a simple open-loop position controller. Foot switches determined the time of im-pact, upon which a set of valves would open causing the muscles of the opposite leg to flex. The Valves would open a preset time, causing a position change, however no direct feedback has been used. In the remainder of this report this control mode has been dubbed ‘Wisse Control’.

sim-ulations by [4] and [8] this simple control algorithm proved to be fairly robust. Simsim-ulations of more elaborate (energy based) control schemes as simulated by [4] yielded promising results regarding sta-bility and flexista-bility.

A numerical frequency response of the linearised closed loop controlled model with as input a position setpoint and as output the output angle shows a controllable movement range up to 5 [Hz] (shown in figure 2.19. The -3 [dB] point lies at 4.5 [Hz]. The resonance frequency lies at 2.8 [Hz]. A basic rule of thumb is that the control loop frequency should be a factor 20 higher than the system’s bandwidth [1](page 189). As ‘safe’ frequency for the main control loop 100Hz is chosen. A faster setpoint change will have only a very small influence on the output position.

Figure 2.19: frequency and phase response of actuator output

In [4] several control schemes are discussed. Most of them have a calculation load larger than the capabilities of a small microcontroller. For most of them at least a PC-derivative is necessary. This will be discussed further in Section 2.5.6

2.5.5 Sensors

Torque sensor

In order to make the hip joint completely backdrivable, the motor has to compensate for the loss effect in the gearbox. When only using linear friction, the following holds:

Tmotor=Rgearωmotor+Toutput

At the motor-controller side, the current in the motor is a linear measure for the output torque (Tmotor = kmotor∗I). This could be used as a measure for the total output torque when used with a feed-forward model of the loss in the gearbox (given in the datasheets only by its maximum efficiency: for the used gearbox GP42C, 1:74 this is typical 72% maximum). The current is however in a switching motor control system due to switching noise and EMF not a ‘clean’ value to measure. By adding a torque sensor to the drive-line after the gearbox, the system can be controlled with ‘zero-torque control’ by setting a setpoint for output torque of 0.0 [Nm] which resembles the a ’free turning’ backdrivable state.

Sensor Range Output price

Transducer Techniques TRT-100 11.3 [Nm] 2.0 [mV/V] 675$ Honeywell QWLC-8M 11.3 [Nm] 2.0 [mV/V] 800 $ Futek T5104 12.0 [Nm] 1.5 [mV/V] 1250$ Applied Measurements Ltd DTD-F 10 [Nm] 2.0 [mV/V] 2000$

Table 2.2: Torque sensors

specified maximum torque. Transducer Techniques can also supply interfacing hardware, but unfor-tunately not on the required mobile scale. The torque range (11.3 [Nm]) comes from conversion of the specified range of 100 [in.lbs].

/blankspace A sensor interface circuit needs to be made that can run on the mobile power supply (0-24 [V] DC). The amplification needs to be high. With a 2.0 [mV/V] at 11.3 [Nm] and an excitation voltageVexcitation of 5.0 [V] the signal output is 10.0 [mV] at maximum load. With an ADC with as voltage reference 5.0 [V] this signal needs an amplification of 500 times. With a 10 bits ADC (as can be found in Atmel Microcontrollers) the resolution of this interface circuit will be 11.3 [Nm] / 10 [bits] = 11.3/1024 = 11.0 [mNm/step]. Another option is adding an extra ADC to the circuit with a higher resolution

Position sensors

For position sensing optical incremental encoders are a cost-efficient choice. Resistive angular sensors (potentiometers) tend to be noisy and have drift. Apart from that they introduce a mechanical resistive element. Absolute optical encoders however expensive and three times as large as the non-absolute.

Incremental Encoders

When using non-absolute incremental encoders the robot has either to be started up every time in exact the same position, or the encoders need an extra reference signal for detecting its zero-position. There are optical encoders available which contain an index pulse too, so upon detection of the index pulse the position counter can be set to zero.

/blankspace The proposed encoders [4] are available in a 3-channel 500 [ppr] edition. When using quadrature encoding (every transition of one of the channels will be counted) a resolution of 2000 [cnt] (counts) can be achieved. For the joints in the robot this gives a resolution of 3, 14e−3 [rad/cnt] or 0,18 [◦_{/cnt]. Interface circuitry for these sensors needs to count the pulses using quadrature encoding,}

calculate the position and interface this position to the main controller. There are a number of ways to interface these encoders to the main control system. There exist dedicated interface chips with build-in counters and quadrature logic, such as the HP HCTL2020 series. The HCTL2020 has a 16bit counter and an eight-bit parallel output port. These chips are quite expensive (typical 30$ each). Another option is by using FPGA chips. A quadrature encoder including timers and necessary filtering can be programmed in VLSI and a large number of encoders can be interfaced to one single FPGA. In the Arty robot [11] this approach has been followed. A third option consist of using a microcontroller for quadrature decoding, counting and interfacing the signal.

Velocity data

A number of ways are available to calculate the discrete differential of the encoder position. A trade-off between calculation speed and accuracy has to be found. Because the differential has to be calculated in realtime, only backward differentiation is possible. The one-dimensional first order Euler backward differential is given by

δx

δt =

x(t)−x(t−∆t)

∆t +O(∆t) (2.7)

In this case t has always an error of∆t, so the in case of differentiating the encoder position, the calcu-lated velocity value will always come one time instance too late. In case of the encoders, the differential is used for determining the velocity of the joint,v(t) = _dtdx. In 20-sim [18] an Euler based backward differential with window size 2 is used in the ‘Differentiate-Calculus.em’ block.

v(t) = 2

3

x(t)−x(t−∆t)

∆t +

1 3

x(t−∆t)−x(t−2∆t)

∆t (2.8)

where

t the current time

∆t the discrete time step

In this case t has an error of∆ttoo. This can be solved by using a prediction algorithm using the same data points (x(t),x(t−∆t)andx(t−2∆t)) performing a curve fit through that points. A second order polynomialx_{f it} = at2_{+bt+cshould be found that fits these data points. The first differential of that} polynomial,at+b, can be evaluated to give the desired velocity at time t.

at2+bt+c=x(t)

a(t−∆t)2_{+b(t−∆t) +c=x(t−∆t)}

a(t−2∆t)2+b(t−2∆t) +c=x(t−2∆t)

We only need a and b to get the first order differential of the polynomial because

vf it= _dtd xf it = _dtdat2+bt+c=at+b

a= 1

2

−2x(t−∆t) +x(t) +x(t−2∆t)

(∆t)2

b=−1

2

−4tx(t−∆t) +2tx(t) +2tx(t−2∆t) +4∆tx(t−∆t)−3x(t)∆t−x(t−2∆t)∆t

∆t2

Choosing a convenient value for t, i.e. t=0, which is a logical time to take the sample, using the position (x(t)) value ont=0,t=−∆tandt=−2∆tresults invf it =band after regrouping the variables:

vf it= ₂1_∆t(3x(0)−4x(−∆t) +x(−2∆t)) (2.9)

which is just as the euler differential mentioned above another weighted sum of current and two pre-vious position values. This method however does not introduce an error in t of∆t.

Both of these sums were evaluated by programming them in an AVR controller board [6]. An evaluation encoder was connected to the board. Calculation results were obtained through the serial port by Matlab. This test-setup will be discussed in Chapter 4.2.

In figure 2.20 the two differential methods which have been used on the same dataset are displayed. The dataset was obtained by the evaluation setup. The encoder was connected to a pendulum of 50 [cm] performing a swinging motion of 1.7 [Hz] and sampling frequency of 100 [Hz]. The calculations were performed with integer values to minimise calculation time in the microcontroller. The two plots in figure 2.20 clearly show that the euler differentiation has a smoother response but is always 1 sample instance too late. The predicted version (with the curve fit algorithm as described above) lacks the timing error, but has a less smooth and ’noisier’ response.

Pos[pulses]

Sample[#]

Figure 2.20: Comparison between two differentiation functions

Absolute position

An incremental optical encoder without reference point cannot give an exact absolute position. In the previous section was already mentioned that absolute incremental encoders are no option for this design because of size and price. Therefore three-channel versions of the HEDS encoders will be used which have an index pulse too. When the index pulse is detected (after an initial movement of the joint) the encoder can be verified and set to zero. For the encoders in the knees and feet this index pulse is located close to the straight-angle positions (i.e. the legs fully stretched and the feet making a 90◦angle with the floor).

The encoder in the hip joint is fitted on the motor output shaft, while the legs are connected to the motor through a gearbox. The gearbox has an 1:73 ratio, so for every full rotation of the legs, the encoder turns 73 times, generating 73 index pulses. This makes it impossible to use the index pulse for determining and verifying an absolute zero-position. A number of methods for determining the zero position were brief investigated:

• Indexing and calibrating on existing index pulses

• Using a different sensor for absolute positioning

• Using only encoder-data, using a manually set start position

The first option was tested, but has still the problem that the position between the first index pulses needs to be determined. Later tests showed that a calibrating algorithm takes up too much computing power.

of 1000 [gauss] at 2.2 [mm] and the hall-effect sensor has a sensitivity of 1.3 [mV/Gauss]. However because of the nonlinear field decay of the magnets the maximum reasonably linear range extended only over 2 [cm].

Hall effect sensor

North South

South North

B

x

Figure 2.21: Hall-effect sensor and magnets

The second attempt was using a TSL1401R 128-bit photo diode array sensor. In combination with a high-contrastimage of a slanting line a small system was built and tested. A schematic drawing is shown in figure 2.22 Although the system was susceptible to leak light and dependent on environmen-tal lighting conditions this system appeared promising. There was however no time to develop and test the system any further. So for the time being the third option, using a manually set start position, has been used, because of its simplicity and because of proven results. If a more accurate and definitely absolute position is necessary one of the discussed methods above can be used.

128 point wide sensor array

Figure 2.22: Position sensor with photodiode array

2.5.6 Electronics architecture

The electronics on the robot consist of the controller, sensor interfacing, motor interface and power circuits. The electronics of the walker need to control one motor and four knee locking mechanisms. Sensor input will have to be obtained from nine incremental encoders (one on every joint), four switches and one torque sensor. Everything needs to be powered from a mobile power source, such as a battery or accumulator. The most important design criteria with respect to the electronics are posed by the need for mobility and space constraints.

Control

sensors. Although the power consumption is high for a PC104 system (typically in the range of 15 [W]) they are small and have been used on autonomous mobile platforms such as the ‘Arty’ robot [11]. Due to the desire to build as much of the electronics as possible inside the hip tube, this approach will not be possible. The hip tube has a length of 60 [cm] of which 18 [cm] has been taken by the actuator. For batteries and electronics is only 42 [cm] left. It is not possible to fit a pc or pc derivative in that space, so only smaller controllers are an option. Goal of this project is however to experiment with elaborate and calculation-intensitive forms of control. Therefore a solution with a separate PC performing all calculations, a (wireless) link and a (simple) on-board microcontroller has been chosen. This solves the problem with extra power consumption and space constraints. The more complex control algorithms will be performed in a remote computer on the side. Sensor interfacing will be performed on the robot. By a wireless link all sensor information and setpoint data will be transmitted from and to the remote computer.

The common approach for this system is to use a single microcontroller, large and fast enough to handle the required data-transmission rates, and add the amount of interface electronics necessary for connecting it to the sensors and motors. As discussed in section 2.5.5 dedicated interface chips exist for HEDS-type incremental optical encoders. The system could consist of one large microcontroller with a parallel bus connected to eight interface-chips, and a power amplifier for the motor, as depicted in figure 2.23.

Figure 2.23: System with one parallel bus

The idea in suggested in Section 2.5.5 to use microcontrollers for a custom designed encoder in-terface inspired another idea to use several microcontrollers connected to a field bus system for the robot.

Figure 2.24: System with serial bus

manipulate the encoder data and can even enable small local control loops.

This approach needs a field bus with a dedicated communication protocol. The bus speed should be high enough to accommodate all information transfer back and forth from the main controller to the sensor-units.

Control loop and communication frequency

The important design criteria for this architecture are the necessary number of sensors and variables that need to be transmitted and the required transmission rate which is closely related to the necessary discrete control frequency.

In simulation the robot walks at a maximum speed of two steps/sec. The system’s ground frequency is according to simulation 2.8 [Hz]. Simulation data further shows a system bandwidth of 4.5 [Hz] (See Section 2.5.4). For the main control loop a frequency 20 times higher then the system bandwidth is chosen.

In this control loop of 100Hz the signals of nine position sensors and four switches need to be transmitted to the main controller. One motor setpoint and four knee lock states need to be sent back. If the robot is walking as it should, the positions of the outer knees must be the same as the inner knees (the same applies to the inner knees, and the feet) so actually only five positions (four joints + the hip) are necessary. Sending them all enables the main controller to determine whether the robot is walking as it should. For every position four bytes need to be sent (a float variable).

Considering a ‘worst case’ scenario, at least ten times four bytes position data + two bytes switch and lock data need to be transmitted during one instance of the 100Hz loop. The bus frequency should enable at least 42 byte * 10 bits * 100 [Hz] = 42000 [Bps]. When adding more status and security infor-mation, a reasonable goal is 100000 [Bps], depending on the used communication protocol.

Motor control

The microcontrollers in the knees should handle the control of the knee locking mechanisms, the con-trollers in the feet can interface the floor contact switches as well. The main controller handles the communication between the joint modules and the remote PC and can perform not-too-complicated control of the robot. That leaves one function: control of the motor.

A robust servo amplifier will be needed which can do PID control for position or force. It also should be able to operate in transparent mode, so control could be done in the main controller. In order to minimise the influence of a local control loop on the operation of the central controlled process, the control loop frequency of the local controller (PID, torque or position control) should be an order of magnitude higher. A reasonable goal for this system is 1000 [Hz].

2.5.7 Conclusion

Summarising the requirements and design specifications for the robot:

• A tubular design, made out of aluminium according to the drawing as presented in [4].

• Distributed control system, consisting of one microcontroller in each joint together with a central (communications) controller. Control of the robot should be able from a remote PC through a wireless link, simple control algorithms should be performed by the main controller on the robot itself.

• Control loop frequency of 100 [Hz], local control loops can be faster.

Design and construction

In this chapter the designed electronics, software, mechanics and alterations to the preceding design will be discussed. The final schematics, drawings and code will be given in the appendixes. Each section will start with a short recapitulation of requirements discussed in Chapter 2, followed by a discussion of design criteria and concluded by the final implementation.

3.1 Electronics

In this section the electronic designs and circuits will be discussed. The primary goal for the electronics in this robot is to enable control of the robot. The setup has to allow multiple control strategies, from simple closed loop control or ’Wisse Control’ to more advanced control by a sophisticated controller running on a remote PC. The robot’s electronics will be designed in a modular fashion to ease addition or replacement of components.

3.1.1 Field bus

The electronics are designed in a modular fashion. Every joint has a microcontrollerboard which per-forms the tasks that are locally necessary. For data exchange between the boards a number of commu-nication protocols for field-busses have been investigated: RS232, SPI, I2C, CAN and USB. The criteria for selection are:

• speed

• scalability

• overhead

• availability

• ease of implementation

• maximum distance

• minimal number of wires

need to cover is at least 2.5 [m] (from outer right toe to outer left toe). Because the modules will be wide spread across the robot, the protocol should need as few wires as possible. Therefore parallel bus systems (MicroBus, GPIB, Centronix) will not be discussed here.

Discussion of available protocols

RS232 is a standard communication protocol, available on almost every PC system ever built. The maximum speed is 115 [Kbps] and distance up to tens of meters, so it meets the requirements. RS232 is available on most microcontrollers (with built in UART). It is however designed for point to point communication, so it is not very suitable for a bus system. Only with a couple of tricks designing custom bus-drivers it can be made possible.

SPI has a maximum speed of 1 [Mbps]. It is very suitable for bus communication over short distances. It is also integrated in a large number of available microcontrollers. SPI is designed to have at least one ’Master’ on the bus and a number of slaves. SPI uses at least four wires: a serial clock, data in, data out and for every slave a ‘Slave Select’ line.

I2C, also called TWI (I2Cis the registered trademark by Philips, TWI (Two Wire Interface) is the name for the same protocol as implemented in microcontollers) is a serial 2-wire protocol with a maximum speed of 400 [kbps]. It is very suitable for a system with a large number of modules on a bus, up to 128 in the normal address range. TWI uses 2 wires: a clock and a bidirectional data line. The communication speed is limited by the bus capacitance, which depends on the length of the wires. Still TWI is capable of communication with 100 [kbps] over several meters. TWI is integrated in available microcontrollers, solving a number of communication tasks in chip hardware.

There are microcontrollers in existence with CAN or USB (or both) integrated. CAN and USB are both serial 2-wire protocols capable of datatransfer with speeds above 1 [Mbps]. Because of the amount of overhead in program space and execution time CAN and USB are less suitable options for the robot. The CAN protocol also needs special driver chips.

Conclusion

TWI has been chosen as protocol for the robot because of its small number of wires, small code over-head, scalability and ease of implementation. With no special bus driver components, communication should be able with several units on a bus of a couple of meters. If the capacitance is too high, ei-ther the communication speed can be lowered or special bus driver chips can be added. RS232 will be made available on the boards too, not for communication between the modules, but because of the easy interfacing with PC equipment for debugging purposes.

Implementation

TWI needs two signal wires: a serial clock (SCL) and bidirectional data (SDA). Together with a power (+12V) and a ground (GND) it forms the bus standard used on the robot. Every module can derive its own voltage from the 12 [V] by an on board linear regulator. The modules can be connected parallel on this bus.

For the physical implementation small 4-pin MicroMatchTM connectors were chosen because of easy crimp installation and very small footprint (see figure 3.1). They also have an identification pin on the male-on-wire connector, which makes it impossible to connect the connector the wrong way around. The pinning is given in table 3.1

The only extra hardware the TWI interface uses are two pullup resistors of 4.7 [kΩ] on the SCL and SDA lines. They need to be fitted as close as possible to the bus master. In order to increase flexibility in the design at every board two spaces for these pullup resistors are left. Being SMD 1206 footprints they do not take up much space.

Figure 3.1: 8-pin MicroMatch connector

pin signal

1 12V

2 SCL

3 SDA

4 GND

Table 3.1: TWI pinning

3.1.2 Microcontroller

Requirements

For the implementation of the electronics on the robot a modular setup was chosen. In every joint all control and interfacing tasks will be performed by a dedicated embedded controller. The criteria for selecting the microcontroller are:

• speed

• reliability

• small size

• power efficiency

• presence of ADC, PWM, TWI

• presence of RS232 for debugging

• availability of a good development environment

Several suitable microcontroller families are available. Because of good experience during other projects, availability of a working development environment and superior performance with respect to other standard available microcontrollers, for this embedded controller a microcontroller from the ATMEL AVR series was chosen.

Implementation

The ATMEL ATmega8 [2] is an AVR-Risc microcontroller with 8 [Kb] FLASH program memory, 512 [b] EEPROM and 1 [kb] SRAM memory. The ATmega8 offers the most performance in the smallest (TQFP32) package of the ATMEL mega range. The controller runs at 16 [MHz] capable of performing most in-structions in one clock cycle (16 [MIPS] at 16 [MHz]).

The ATmega8 has on board UART, TWI interface, 10bit ADC, 3 PWM outputs, 3 Timers and 2 external interrupts. Timer1 of the controller is capable of generating phase correct PWM signals with 8 bit resolution up to 31 [kHz].

For the ISP programmer a parallel port dongle is used that came with Kanda’s STK200 development kit for AVRs. Schematics are available in [6]. In order to save space on the PCBs not the standard 10-pin header has been used but a custom 6-pin header for connecting the programmer dongle. The pinning is given in table 3.2.

pin signal

1 GND

2 +5V

3 RESET

4 SCK

5 MISO 6 MOSI

Table 3.2: ISP programmer pinning

The internal signals and hardware of the AVR are denoted in capital letters. TIMER0 denotes the internal timer 0. Output and input pins are denoted by for example PORTB.2 and PINB.2 respectively.

For debug purposes on every board a 4-pin connector is placed for using the RS232 serial port of the microcontroller. This connector can be wired to an RS232 level adapter, which can be connected to the serial port of a PC. This level adapter can be made with for example a MAX232 or ICL232. For convenience the power supply is made available on this connector too, so the level adapter can be connected by a single cable with four wires. The pinning of this connector is given in table 3.3.

pin signal

1 +5V

2 TxD (data sent by microcontroller) 3 RxD (data received by microcontroller)

4 GND

Table 3.3: RS232 debug interface pinning

Software Versions

The version of the software, along with the compile date are programmed into one string in the EEP-ROM of the controller. With the programmer in the CodeVision IDE this string can be read out to determine which is the current software version in a module.

3.1.3 Motor amplifier

Requirements

The motor amplifier has as main task to control direction and output power of the motor. The design is adapted to the used motor, the Maxon RE40 DC brushed motor. The specifications are listed in the previous chapter, in table 2.1. The chosen motor has a maximum supply voltage of 24 [V]. There is a 12 [V] version available from Maxon, but this motor was not part of the standard program. For this 12 [V] version motor the required currents are doubled, and the efficiency is lower. For the 24 [V] ver-sion the nominal current, when used at its maximum continuous torque, is (180 [mNm] / 30 [mNm/A] = ) 6 [A]. The maximum continuous power is 6 [A] * 24 [V] = 144 [Watt]. For the design of this motor amplifier the book ‘Motor Control Electronics Handbook’ [24] has been used extensively.

stage. The microcontroller also acts as controller for position or torque. Other important design aspects are safety considerations and fault diagnostics. The motor amplifier needs to be robust, and should shut down or go into safe mode upon over-current over over-temperature. The design should be shortcut proof. This means that the microcontroller has to be able to measure the motor current and when necessary to shut down the power to the amplifier stage. Furthermore the system needs a temperature warning and protection. The microcontroller needs to be suitable for closed loop position or torque control.

From the Maxon RE40 datasheet [15] the specifications regarding maximum current and power con-sumption can be obtained. They are listed in table 2.1. Together with these motor specifications, the requirements for the motor amplifier can be summarised as follows:

• Voltage range up to 24 [V]

• Continuous current up to 10 [A]

• Peak current up to 80 [A]

• Switching frequency round 30 [kHz]

• Size: fit in a tube with a diameter of 6 [cm] and a maximum length of 20 [cm]

• TWI interface

• Safety measures: short circuit proof, fuses, temperature detection

• Position control, torque control or transparent output mode

The size constraint rules out almost all commercially available motor controllers. Although there are several hybrid modules available, containing for example only the power stage of the motor amplifier, the choice was made to design a motor amplifier specifically for this project. In [4] already the power stage for a motor amplifier was discussed, but this design was rejected because it couldn’t meet the switching-frequency requirements. In figure 3.2 the space is shown where the motor amplifier and batteries will be placed.

Space left for motor amplifier and batteries

Figure 3.2: Crossection of the robot tube

H-bridge design

The most common approach in designing a motor amplifier for DC brushed motors is designing an H-bridge type amplifier. Four switching elements are connected into a square configuration with the motor as ‘bar’ in the center of the H. Transistors are normally used as switching elements.

Choice of transistor

Conventional bipolar transistors tend to dissipate a lot of power because of their large voltage drop (typically 0.7 [V]). For this bridge this would mean 6 [A]*0.7 [V] = 4.2 [W] power dissipation in each transistor which would be unacceptable.

MOSFET transistors have a much lower voltage drop than bipolar transistors. With antagonistic couples of matched P-MOSFET and N-MOSFET transistors it is easy to design and control a bridge: the gates can be connected to the same controlling source. When the source has a high output, the bottom (N-MOSFET) is open. When the source has a low output, the top (P-MOSFET) is open. P-MOSFET transistors however tend to have a larger value for Rdson(the resistance between Source and Drain when the Gate is charged), so it is hard to find exactly matched N-MOSFET - P-MOSFET pairs for large currents.

A solution would be using four of the same N-MOSFETs in the bridge. The problem with using N-MOSFET transistors for the top side of the bridge is that they need a voltage higher than their Drain-Source voltage to turn on. This means that they need a voltage higher than the supply voltage to the bridge. There is however a common ‘trick’ to use a bootstrap capacitor to ‘pump up’ the voltage for turning the high-side transistor on.

With two switching elements between the two power rails the possibility of a bridge shout-through or short-circuit arises. Measures need to be taken to ensure that the high-side and low-side transistor in the same branch of the bridge can never be turned on at the same time. Especially when using MOSFET transistors this requires special measures because of the charge and de-charge times of the gate capacitance.

MOSFET transistors with low values forRdsonhave large values for gate capacitance. When a high switching frequency is required (a frequency in the order of 30 [kHz] is desirable) the MOSFETs need a large current to switch on and off.

MOSFET Bridge driver IC

Special driver ICs exist to ease implementation of the high-power side of the bridge. For this design the IR2110 [20] from International Rectifier was chosen. This IC incorporates all functionality for one half of a bridge, and can control the high-side and low-side MOSFET with currents up to 2 [A]. In total two of these ICs are required in the design. The power stage is designed according to application note AN978 by International Rectifier [19].

The used N-MOSFETS are a trade-off between maximum current,Rdson, gate capacitance and pric-ing. The HUF75333 by ‘Intersil’ can supply 66 [A] at 55 [V], has anRdsonof 0.016 [Ω] and a maximum gate capacitance of 85 [nC]. By using douple pairs of these MOSFETS, the maximum current will be 132 [A] which will be sufficient to cover the peak loads on startup.

According to the application note [19] the bootstrap capacitor can be calculated using the following formula:

Cbootstrap=15

2[2Qg+ Icbs_f +Qls]

Vcc−Vf −VLS (3.1)

where

Qg Gate charge of high side FET = 85 [nC]

Icbs Bootstrap capacitor leakage current (neglec