Modular Robot

Biologically-Inspired Robotics

University of Southampton School of Electronics and Computer Science

18 May 2012

Team B

Authors: Nikhil Banerjee

John Charlesworth Michael Hodgson

Max Lotz Will Neep

Romel Torres

Project Supervisor: Klaus-Peter Zauner

ii

Abstract

Modular robotic systems are inspired from similar analogous systems in nature. A modular system is comprised of multiple copies of a single module. This is inspired by the most fundamental form of life, the cell. Hence a modular robot will be an entity which can form a system greater than the sum of the parts. Modular robotics is branch of robotics that has been around for just over two decades but the full potential of the applications yet to be fully realised [1]. The main purpose of a modular robot is to replace bespoke robotic systems with a generalised, universal platform. However, due to the high complexity and cost it is difficult for development in this field. Our implementation mimics one of the most developed systems, M-TRAN, but at reduced cost and manufacturing complexity. With this as our goal, we explore an alternative design for similar modular robot systems in the attempt to increase accessibility to the modular robot field by lowering the cost and complexity, and thus the barrier of entry.

iii

Contents

ABSTRACT ............................................................................................................................................................................................. II

1 INTRODUCTION ........................................................................................................................................................................ 1

1.1 BIOLOGICAL INSPIRATION ............................................................................................................................................................................ 1 1.2 EXISTING TECHNOLOGIES ............................................................................................................................................................................ 1

1.2.1 M-TRAN III ....................................................................................................................................................................................... 1 1.2.2 Molecubes ......................................................................................................................................................................................... 2

1.3 PROJECT SPECIFICATION .............................................................................................................................................................................. 2

2 SYSTEM OVERVIEW ................................................................................................................................................................. 3

3 ELECTROMECHANICAL DESIGN .......................................................................................................................................... 4

3.1 PRELIMINARY PROTOTYPE .......................................................................................................................................................................... 4 3.2 ACTUATION ..................................................................................................................................................................................................... 4

3.2.1 Background Research .................................................................................................................................................................. 4 3.2.2 Servomechanism Mechanics ..................................................................................................................................................... 5

3.3 DIMENSIONAL CONSTRAINTS AND SPACE ALLOTMENT .......................................................................................................................... 5 3.4 INTER-MODULE CONFIGURATIONS .............................................................................................................................................................. 5 3.5 CHASSIS MATERIAL ....................................................................................................................................................................................... 6 3.6 CHOICE OF PIVOT ........................................................................................................................................................................................... 6 3.7 ELECTRICAL CONNECTIONS ......................................................................................................................................................................... 7

4 MODULE ELECTRONICS DESIGN ......................................................................................................................................... 8

4.1 COMMUNICATION .......................................................................................................................................................................................... 8 4.1.1 Communications Overview ........................................................................................................................................................ 8 4.1.2 Physical Layer ................................................................................................................................................................................. 8 4.1.3 Neighbour to Neighbour Packet Layer ................................................................................................................................. 9 4.1.4 Network Layer .............................................................................................................................................................................. 10 4.1.5 Application Layer ........................................................................................................................................................................ 12

4.2 SENSORS ....................................................................................................................................................................................................... 12 4.2.1 Sensor Overview ........................................................................................................................................................................... 12 4.2.2 Design............................................................................................................................................................................................... 13 4.2.3 Integration ..................................................................................................................................................................................... 13

4.3 PCB DESIGN ................................................................................................................................................................................................ 13 4.3.1 Advantages of PCB Design ....................................................................................................................................................... 13 4.3.2 Constraints ..................................................................................................................................................................................... 13 4.3.3 Design............................................................................................................................................................................................... 14

4.4 ELECTRONICS PROTOTYPING AND IMPLEMENTATION ......................................................................................................................... 15 4.5 DISCUSSION.................................................................................................................................................................................................. 15

5 SIMULATION ........................................................................................................................................................................... 17

5.1 OVERVIEW ................................................................................................................................................................................................... 17 5.2 MODELLING ................................................................................................................................................................................................. 17 5.3 MOVEMENT ................................................................................................................................................................................................. 17 5.4 COMMUNICATION ....................................................................................................................................................................................... 17 5.5 GAITS ............................................................................................................................................................................................................ 18 5.6 DISCUSSION.................................................................................................................................................................................................. 19

6 RESULTS ................................................................................................................................................................................... 20

7 PROJECT MANAGEMENT .................................................................................................................................................... 21

7.1 TEAM MANAGEMENT ................................................................................................................................................................................. 21 7.1.1 Nikhil Banerjee: Electromechanical Engineer ................................................................................................................. 21 7.1.2 John Charlesworth: Electronic Engineer ............................................................................................................................ 21 7.1.3 Michael Hodgson: Electronic Engineer ............................................................................................................................... 21 7.1.4 Max Lotz: Electromechanical Engineer .............................................................................................................................. 21 7.1.5 Will Neep: Electronic Engineer .............................................................................................................................................. 21 7.1.6 Romel Torres: Embedded Computing System Engineer ............................................................................................... 21

iv

7.2 SUBVERSION CONTROL .............................................................................................................................................................................. 21

8 DISCUSSION AND CONCLUSION ........................................................................................................................................ 22

9 FURTHER WORK ................................................................................................................................................................... 23

REFERENCES ...................................................................................................................................................................................... 24

10 APPENDIX A. PROJECT MANAGEMENT DETAILS ....................................................................................................... 25

10.1 EXAMPLE OF MINUTES......................................................................................................................................................................... 25 10.2 BUDGET .................................................................................................................................................................................................. 26

10.2.1 Project Costs Breakdown .................................................................................................................................................... 26 10.2.2 Price of a Single Modular Robot ...................................................................................................................................... 27

10.3 GANTT CHARTS ..................................................................................................................................................................................... 28

11 APPENDIX B. HARDWARE DESIGN DIAGRAMS........................................................................................................... 30

12 APPENDIX C: ADDITIONAL PHOTOS OF FINAL PROTOTYPE ................................................................................ 32

13 APPENDIX D: LABELLED DIAGRAM OF CONNECTION HARDWARE .................................................................... 34

1 Introduction

The advancement of technology has aided the development of advanced robotic systems. The constant miniaturisation and optimisation

of electrical technology has driven large robotic systems to new areas for progression. One of these areas is modular robotics. Modular

robotics is the notion of harnessing smaller robots which can join together to produce a functioning, collaborative, robotic system

greater than the sum of the parts. This is similar to swarm robotics, but modular robots are capable of physically attaching themselves

to form one functioning system. Each module will consist of a fully functioning robot with the ability to interact with other similar

robots. The robots will be able to communicate with each other and physically combine their efforts to fulfil a given task. This is the

core concept of modularity, the ability to work as one system comprised of many smaller systems.

The other concept is decentralised control. Our robots will consist of identical modules which will all run the same program. In order

for the system to work, distribution of tasks must be able to be decided among the modules. Decentralised control also gives added

robustness to the device; such as if one system were to fail, the other system could carry out the failed systems’ tasks.

1.1 Biological Inspiration The concept of modularity is embedded in nature. Single celled organisms are among the most basic forms of life. These cells can form

giant unicellular organisms such as Xenophyophores. These are found throughout the world’s oceans and feed on deposits and

sediments on the sea floor. Each module of the robot is analogous to a cell and the collaborative system the modules form is analogous

to the structure the organism forms in order to feed.

Many other ideas for modularity are rooted in nature, most notably swarm behaviour. For instance, a shoal functions as a system

comprised of individual fish. Fish, can function individually, or as part of a larger collaborative system comprised of the same fish. The

school behaviour helps the fish survive by confusing predators and improving hydrodynamic efficiency [2].

Both these ideas share the concept of forming a system greater than the sum of their parts which mutually benefits all modules of the

system.

1.2 Existing Technologies Robotics is an expansive field which is limited by technology and cost. The integration of robots into everyday life is a process still in

its early stages. The formation of a generalised robot which can cope with multiple tasks is usually not feasible due to cost and

technological constraints. However, this has led the way for cheaper, smaller scale robots which can perform novel tasks; and as

technology advances, so does the complexity of the robot system which drives the constant change in this field of electronics. This

means that there has been a plethora of work done with novel small scale robotics systems which often either draw parallels with nature

or try to mimic creatures that exist in nature. Modularity is no exception. The main purpose for a modular robot is to form a

generalised, universal, low cost alternative to specialised machines with fixed body structure and bespoke functions. However, even

after two decades of research and development, most researchers agree that the advantages of modular robots have yet to be fully

realised [1].

1.2.1 M-TRAN III M-TRAN III (modular transformer, third revision) is a self-reconfigurable modular robot, developed by the National Institute of

Advanced Industrial Science and Technology (AIST) and Tokyo-Tech since 1998 [3]. M-TRAN is a great example of a highly

adaptable modular robot. Each module is comprised of a male and female half which can connect to each corresponding half, see Fig. 1

below. Each module section has two degrees of freedom, rotation between +90° and – 90°. When combined with a several other

modules the robot is capable of changing its 3D structure in order to negotiate terrain. This can include morphing into different profiles

to avoid obstacles or completely reassembling itself, shown in more detail in Fig. 2.

Fig. 1. Photograph of Single M-TRAN III module [3]

2

1.2.2 Molecubes Molecubes [4] is another example of a universal modular robot. Unlike M-TRAN III, it cannot self-assemble and has only one degree

of freedom, however, the servos are not rotation limited, and so it is possible to use rotating modules as rudimentary wheels. There are

several different types of Molecube blocks, each offer a different way to augment the system; for example WiFi connectivity or a

grabbing hand, shown in Fig. 3.

1.3 Project Specification Our design will consist of a modular robotics platform, similar to M-TRAN III, but for significantly lower cost. It will adopt a

decentralised control framework which will allow an ‘n’ scalable network of modules which can be attached. Thus the robot chassis

will have to allow additional modules to be mechanically attached and detached, and allow the adjacent components to interact. This

design will incorporate rotation of the chassis end caps, using actuators, to allow for this movement. As this system is aimed to be low

cost, it will also be easier to manufacture than similar designs in the field.

Fig. 2. Different types of terrain M-TRAN III can negotiate [3]

Fig. 4. Photograph of the first

prototype design. The design mimics

M-TRAN III’s structure, with two servos moving the two end caps with

capable motion from -90° to +90°

Fig. 3. Photograph of a Molecube System with augmented grabbing blocks

3

2 System Overview

The Modular robot developed is comprised of three parts, two end caps and a centre body. The two end caps can rotate between -90° to

+90°, giving us 180° of motion with two degrees of freedom. The inter-module connections are comprised of magnets with north and

south ends, allowing multiple connections in parallel and perpendicular orientations. The electronics for the system are housed in the

central body. As the system is modular it adopts decentralised control and is scalable for ‘n’ amount of modules. The module is able to

attach to these other modules and derive movement, however, our system will not self-assemble. The core electronics are contained on

a single PCB. The module is capable of connecting neighbour to neighbour to all six ports and to non-neighbour modules via multi-hop

network communication. The core framework of the electronics was built with scalability in mind; with an I2C bus, multiple ADCs and

serials ports for expansion and augmentation. Currently the system has not been tested with battery power due to lack of time. A

photograph of the second prototype is shown in Fig. 5; more photographs are available in appendix B.

Fig. 5. Photograph of prototype Module. The power is provided over a modified Ethernet cable.

4

3 Electromechanical Design

The mechanical design is largely based on the most developed existing modular robots technology; M-TRAN III. However, the main

objective of this project was to reduce the cost of existing designs, so the first task was minimising the materials of the design. The size

of the chassis is proportional to the size of the actuator, so by finding the smallest suitable actuators the overall size of the module can

be reduced.

3.1 Preliminary Prototype At the beginning of the design process a rudimentary prototype was created to test the feasibility of the robot. A small aluminium

frame was created to house two 1.5kgcm rated torque micro-servos. These were then controlled from a very basic circuit and a program

from a laptop to see if the robot could achieve a reasonable gait as well as be robust enough. This test was successful; however, the

robot was not holding a battery or any circuitry. There were also no axles on the other side of the servo to connect the main body to the

end caps, but it worked for the purpose of the test. It was clear that much stronger actuators would be needed if several modules were

to be connected together with additional components.

3.2 Actuation A modular robot should be a universal platform able to fulfil any generalised task. A major limitation of the robots capabilities lies

within the strength of actuation. In the ideal case a servo would need maximum torque with minimum weight and size; but they are

proportionally linked. Thus the challenges faced in this section are a balancing between the power/speed of the servos and the weight,

dimensions and most importantly the cost.

3.2.1 Background Research By observing videos of similar robots, it was made clear that in order for the robot to operate in most given situations, each servo

would need to be able to lift the weight of one and a half modules as a minimum. As well as cost, this was the main constraint.

3.2.1.1 Stepper Motors

Stepper motors were initially an attractive idea due to their low profile. This would mean two stepper motors could be faced in opposite

directions at each side of the module to double the power allowing more to be lifted. It would also potentially allow one stepper motor

to be fixed onto one end of each module; the idea being that when the opposite side of a module is attached; this stepper motor could

rotate it to any orientation. Unfortunately they were very low torque and only had discrete orientations; we were looking for a

continuous range of orientations.

3.2.1.2 Electric Motors with Gearing

Another cheaper alternative to stepper motors are standard hobby motors/gearbox combinations which are available at most hobby

shops. However, any that were appropriate in terms of torque were either too large or required a gearbox to scale the speed down to a

practical level. Gearboxes also added unwanted complexity, weight and cost.

3.2.1.3 Servomechanism

Servos, which are effectively the same as electric motors with gearing, were another option considered. Servos are comprised of an

electrical motor with in-built gearing and an accurate position control system. This position control is extremely useful to reduce the

programming complexity for the software design. Another advantage is space. Although servos are generally quite large, the gearing is

optimised to fit the servo form factor, which results with the overall gearing and motor to be smaller than a system comprised of both

the parts individually. However, servos are generally much more expensive than the other two alternatives.

3.2.1.4 Discussion

A servo is in essence a strong motor/gearbox combo with position control packed into the minimal space. This is exactly what was

needed for the robot. However, in order to achieve the specified torque figures, the size and the cost or the servo would be a lot higher

than previously prototyped. A standard electrical motor was contemplated; by experimenting with the gear ratios a higher torque could

be achieved by sacrificing rotational speed. However, an external gearbox would not have been ideal due to space constraints. Another

alternative would involve modifying the inside of a cheaper servo and implement the system with different gears to further reduce the

speed; as speed of movement was not an essential factor in the design. This would involve the use of a rapid prototyping machine to

print gears so we could have a custom gear ratio. However, this is less feasible as plastic gears would be less robust and more prone to

failure. Nevertheless both of these ideas are made redundant as the range of movement of the servos is predefined, and by increasing

the torque we decrease the range of movement; meaning the servo would only be able to turn a few degrees. A potential solution was to

mount a potentiometer on the end of the other servo shaft and have a 1:1 gear ratio so that it would retain its original sensitivity.

However, this would require a lot of highly precise construction as well as the need to extend axles and massively modify the servo

which would likely result in some form of mechanical failure as well as increasing the size and complexity of the design. A qualitative

comparison is shown by

5

3.2.1.5 Conclusion

After preliminary research and testing it was concluded that an unmodified servo would provide the most desirable result. Since all

servos within a certain torque range have almost identical dimensions a chassis design could be made. This would allow us to calculate

the weight distribution of one module (servos, batteries, electronics and casing).

3.2.2 Servomechanism Mechanics We calculated that to lift 1.5 modules on servo would need a stall torque of at least 7kgcm. The servos used approximately double this

amount of stall torque, 17kgcm, to ensure it would be able to lift the weight of a module and a small additional amount of weight with

ease. This was done to avoid the servos operating at maximum capacity during normal operation. Each servo weighs 60g, each battery

weighs 85g and the electronics weigh approximately 30g. Aluminium has a density of 2.7g/cm3. Since the weight of these components

was approximately equally distributed it is assumed that their centre of mass is in the centre of the module. As the size of the centre

body is dependent on the servo, we can extrapolate the module dimensions and calculate an approximate weight; which turns out to be

about 112.2g. Factoring in addition weight for PCB and interconnections the servo used should be able to manage the task with relative

ease.

3.3 Dimensional Constraints and Space Allotment As previously stated one of the design priorities was to minimize space. For stability and symmetry when connecting additional

modules the end caps were to be square. This dimension was limited only by the width of the servo, its head and the bearings used for

rotation. This distance was 57mm. The battery and the electronics would be held on top of or underneath the servo. This meant that

they would have to have a width no larger than 35mm. The height of the servo was 20mm and it was fixed directly in the centre of the

centre body meaning there was a clearance of 20mm either side. The final dimensional constraint for components fixed onto the servo

was its length. This was determined by the distance from the end of the rounded edge on one side of the central plate to the other. This

distance was approximately 135mm (depending on height as well). For more information see diagrams in Appendix B.

The Kingmax 1000mAh 7.4 battery dimensions were 75mm x 35mm x 18mm and the circuit board was 120mm x 35mm (height

unknown, but less than 20mm) giving just enough space for all components. The sides of the end cap (next to the semicircle) were also

square meaning that modules could be fitted 2 ways to each side.

Initially it was thought that since headers are relatively small they could easily be manipulated and fitted into the crosshair shaped

holes without interfering with or obstructing the centre body. However they were not as flexible as thought and a 5mm section had to

be removed around the outside of the semi-circle section of the centre body.

3.4 Inter-module configurations As the goal of this project is to achieve modularity in a robotic system, one of the most important criteria to consider while creating the

mechanical design was inter module connectivity. A few designs that had been implemented in existing modular robotic systems were

studied.

Sproewitz et al. [5] shows a robust physical latching mechanism actuated with DC motors which provided initial inspiration. Zykov et

al. [6] demonstrate the use of electromagnets which can be switched between states of “north”, “south” and “off”. Also the open

source modular robotic project “Molecubes” [3] uses snap on plastic connectors to manually connect two modules together.

The scope of this project does not involve self-assembly, the goal was to create a mechanism to attach and detach the modules

physically. Factors such as the number of connection locations per module and the type of connection mechanism would depend

heavily on the physical structure of the module, thus a basic design was conceptualised. Based on the rough outline of the physical

structure the decision was made to have six total contact locations per module, thus all six faces of the module would have the option

of connecting to the face of another module.

Modified servo Stepper motor Motor with gearbox Servo

Size Large Small Large Medium

Cost Medium High Medium Medium

Robustness Low High Medium High

Range 180° +360°(in steps) +360° 180°

Complexity Medium Low High Low

Table 1 A qualitative comparison of possible actuators for the robot design

6

The engineering problem thus was to construct a connection mechanism with the following aims:

1. Rigid connection points, strong enough to handle shear forces due to sudden movements of the modules

2. Connectable in upright and sideways orientations

3. Ease of attachment and detachment

4. Low cost method that is easy to implement due to time constraints

Connectors were conceptualized to be male and female type and a variety of solutions were discussed. Existing connector types used in

other modular robot designs were investigated. A possible solution was to create an interlocking mechanism with the male end being

covered with deformable rubber. The idea was to enable the male end slipping into its female slot but with the rubber still being hard

enough to hold the module in place. Another idea was to use a plug for the male end that would plug into its female pair and also be

strong enough to grip the module in place. Both these designs were decided against as magnets were deemed to be a simpler and more

robust method of connection.

All of the above mentioned criteria were satisfied by using magnets as connectors. Thus it was decided that one end cap with its three

faces would be made completely male and the other end cap with its corresponding faces completely female. Magnets were categorized

as male and female by changing the polarity on opposite end caps. There were problems faced with gluing the magnets onto the metal

surfaces. Metal to metal glue was procured which seemed like a satisfying option at first but turned out to be weaker than the magnetic

force between two magnets. This resulted in the magnets coming off the surfaces whenever the modules were detached. After trying

two other types of glue, one that offered sufficient holding strength was finally found.

3.5 Chassis Material The material choice was made on the basis of mechanical strength, ease of which it could be manipulated into a desired shape, low

weight and cost. Also the structure would need to be resilient enough to be drilled into and not brittle.

Initially acrylic was the material of choice for chassis construction due to its low weight and cost. After procuring a bit of acrylic for

testing purposes we found that it could be bent into desired shapes but a few issues started coming up. Firstly, the only method to bend

acrylic without it breaking is to heat it up at the bending location which softens it allowing it to be bent. A heat gun was used for

heating bend locations, but to achieve a U-shaped structure a fixture would be required with the exact dimensions of the U-shaped end

caps of our structure. Also, crack formation was observed while drilling through the acrylic. These reasons led resulted in abandoning

acrylic as a material choice.

Aluminium was next considered and had a number of mechanical properties that made it very desirable for our structure, these were:

1. Light weight

2. Malleability

3. Sufficient mechanical strength

Other factors such as low cost and ease of availability of the material further increased the suitability of our time constrained project.

Also all the necessary facilities needed to manipulate the material into shape were already present in the mechanical laboratory.

3.6 Choice of pivot An important issue to be addressed in the overall mechanical design of the modules was finding a pivot mechanism for connecting the

central body to the free rotating end caps. The servos were housed by the central body and the drive axle of the servo would directly be

connected to one of the inner sides of the end caps. The other inner side was problematic as a pivot mechanism was needed to enable a

free rotating joint.

A few options were discussed, the most obvious one being an axle between the central body and the end caps, perfectly in-line with the

drive shaft of the servo. There were a couple of problems with this simplistic approach, one being that the distance between the central

body and the inner cap was to be minimised, which was constrained by the length of the servo drive shaft combined with the connector

used to attach it to the end cap. This distance would then be used as the length of the axle which was connected on the opposite side,

the distance was around 6mm. Creating a 6mm axle with the appropriate rigidity to support the weight of the central body was

problematic as finding the appropriate material and cutting it accurately to an appropriate length would be difficult. Additionally the

contact points of the axle would partially need to support the weight of the central body creating a lot of friction. Another problem was

that making a hole the exact same size as the diameter of the axle would be difficult; the inaccuracy would result in gaps which would

cause the central body to be unstable. Moreover, the axle would need to be fixed to the servo which would involve drilling a hole into

the servo which was not possible due to the motor inside the servo obstructing it.

The next option considered was a ball bearing. The purpose of a ball bearing is to reduce rotational friction while supporting radial and

axial loads, which was the exact purpose that needed to be satisfied. Thus after some research a normal ball bearing and a thrust ball

bearing were procured. Even though the purpose of the thrust ball bearing is to support axial loads mostly, they still offer a certain

amount of support for radial loads. It was a suitable choice as a thrust ball bearing has two flat sides separated with the central plate

which houses the support balls. These separate flat sides made gluing them to the central body and the end caps easier. However, on

testing the thrust bearings we found that the radial load applied by the central body housing the servos was too little and resulted in the

central bearings slipping out.

7

3.7 Electrical Connections There were a total of six electrical connections required between the modules, the incoming RX (receiving), TX (transmitting) and

ground and the outgoing RX, TX and ground in the female and male side of the module respectively. Electrical connections were to be

enabled for all six faces of the module, three faces on the male side and three on female side. Another important consideration was to

enable electrical connection in upright and sideways orientations. A number of solutions were devised to solve this for all of the criteria

mentioned above.

The first preliminary design is described in Fig. 6 it was decided the connections were to be arranged in this way so that the male side

of an attaching module could be connected in an upright or sideways manner. The design was quickly revised to the design described

in Fig. 7; this ensured a lesser number of cables to be used and also ensured the upright/sideways arrangement. The male side had three

electrical connectors in a row.

For the connections themselves, male and female headers of the appropriate length were used. The requirement for the length of the

male connectors needed to be greater than twice the thickness of the magnets to overcome the distance between two connecting

modules. Now, the headers come manufactured in linear chains attached to each other with breakable plastic joints. To create the

crosshair shape of the female headers individual headers were broken and glued on to the top and bottom of a chain of three headers.

While wiring the headers it was observed that for connection to the PCB an important factor to consider was the length of the wires

used. The wires needed to be long enough so that the connections would not break off when the end caps of the modules would be at

their 90o extents. Thus appropriate wire lengths were used to ensure the above. However, with our wiring layout a total of fifteen wires

from the female end (three faces with five connectors each) and a total of nine from the male end (three faces with three connectors

each) were needed and this caused issues. When the end caps of the modules were in motion the wires started getting caught up with

each other. Also due to time constraints all of the wires could not be soldered to the PCB. Thus the modules were connected with

external wires and the headers could not be used.

Fig. 6. The first preliminary configuration for the female electrical interconnections

Fig. 7. The final ‘crosshair’ design configuration for female

electrical interconnections

8

4 Module Electronics Design

4.1 Communication

4.1.1 Communications Overview When designing the communication system for this project we had a number of specifications we wished to meet, summarized below:

Reliable neighbour to neighbour data transmission between connected modules [High priority].

Modules should be able to communicate between modules connected to all six connection ports [High priority].

Modules should be capable of choosing which data is sent to which connection ports - i.e. they should be able to direct their

data transmission and not just broadcast it [High priority].

Master-less operation should be possible - no module should need to be designated as a ‘master’ node - the system should

work if all modules are identical [High priority].

Full duplex operation should be possible - modules should be able to send data as they are receiving [Medium priority].

Modules should be able to determine which connection port data is sent from, to enable inference of the physical structure of

the modular robot system [Medium priority].

The communications system should be scalable with the number of connected robots and

capable of supporting a reasonably large sized communications network [Medium priority].

In order to simplify design, implementation and understanding of this system it has been split into a number of ‘layers’ which build

upon each other to create a working communication stack. A diagram representing this stack can be seen in Fig. 8. We begin with the

bottommost layer: the physical layer, which is responsible for transmitting and receiving raw bytes to and from the connection ports,

and contains the physical hardware used to do this. We then move on to the neighbour to neighbour packet layer, building on the

physical layer which handles reliable communications between connected devices. The next layer: the network layer then builds

directly on the neighbour to neighbour packet layer, and is responsible for transmitting packets across a network of connected modules.

Finally the application layer uses both the neighbour to neighbour and network layers, and is the layer responsible for utilizing the

communications system and doing useful work.

4.1.2 Physical Layer

The physical layer has a simple responsibility: transmitting and receiving bytes of data to and from each of the six connection ports,

according to the specification detailed above.

The first step in designing the physical layer was choosing a bus technology to build it on. Initially I2C was seen as a possible method

for communication, with the many microcontroller chips incorporating I2C controllers, meaning implementing a bus would be trivial.

However, although I2C is specifically designed for communicating between large numbers of connected components, implementing a

master-less system with identical modules would not be easy. One problem is I2C’s requirement that a single pair of pull-up resistors be

Fig. 8. Representation of the communications stack designed and implemented for this project. The higher layers utilize the lower layers

to produce a useful communications system

9

added to the bus. In order to fulfil this requirement and keep all modules identical pull-ups would need to be added to every device.

This would affect scalability, since a large number modules connected together would place a large number of pull-ups in parallel,

degrading performance and possibly stopping the system working at all. Additionally, I2C would not allow any form of inference of

physical structure, since all devices are connected to a single bus. This means that there is no simple way of determining which

connection port incoming messages are being received from, or indeed any way of sending messages specifically to one connection

port and not others.

After much research and preliminary design work it was decided to use the simple UART (Universal Asynchronous

Receiver/Transmitter) available on many microcontrollers for communication. Due to the reasonably unusual requirements of this

project, i.e. the requirement that six modules be communicated with separately, it was not possible to find any suitable off-the-shelf

solutions - for example, the ideal setup would be to use 6 USART ports - one for each of the connection ports - but no suitable

hardware within our budget range existed to allow this.

Instead a multiplexer and decoder are used to connect the 6 connection ports to one serial port. A 3 bit control bus connected to both

multiplexer and decoder selects the connection port to receive/transmit from/to, while the multiplexer then routes incoming data from

the selected connection port to the microcontroller UART, ignoring the other connection port inputs. The decoder is used to selectively

send data from the microcontroller UART to the selected connection port. In this way it is possible to send and receive data to and from

different connection ports selectively.

However, using this scheme alone it is impossible for the microcontroller to determine when data is being transmitted to it from a

connection port that is not being selected by the multiplexer – meaning the microcontroller does not know what port to listen to and

when. Various methods for handling this problem were investigated, such as scanning over the connection ports one by one and

listening for transmissions. Eventually however a simple but effective scheme was designed: by connecting six pins on the

microcontroller to the connection port receive lines it is possible for the microcontroller to ‘eavesdrop’ on the incoming data and switch

the multiplexer and decoder to the correct connection port when incoming data is detected.

Since each module may be connected to another module in two orientations (horizontally and vertically) it was decided that an

additional 6 pins on the microcontroller be used to detect which orientation the module is connected in. By connecting the Rx wires for

both orientations together and using a set of diodes to isolate the orientation detection pins from the horizontal Rx connection port

wires it is possible to detect which orientation a module is connected. When connected in the vertical orientation the orientation

detection pins will see no incoming data, but when connected horizontally these orientation pins will see the same signals as the

eavesdropping pins.

Please see appendix D for a labelled diagram of the connection hardware.

4.1.3 Neighbour to Neighbour Packet Layer

The neighbour to neighbour packet layer builds upon the physical layer to enable the reliable transmission and reception of ‘packets’ of

data over the connection ports. It is designed to simplify the development of higher layers such as the application layer and network

layer by allowing them to send and receive data in convenient packet sized chunks. This layer is implemented in software on-board the

microcontroller - a state machine representation of the receive logic for this layer can be seen in Fig. 9 and the transmit logic in Fig. 10.

Interrupts and the on-board timers of the ATMega644P have been used in the C++ implementation of this logic to make the system as

responsive as possible.

Fig. 9: State machine representation of the neighbour to neighbour packet layer receiving logic. Transition text is

formatted as “condition / action'”.

10

Fig. 10: State machine representation of the neighbour to neighbour packet layer transmitting logic. Transition text is

formatted as “condition / action”.

The unit of transmission in the neighbour to neighbour packet layer is the packet - the basic packet structure can be seen in Fig. 11.

Fig. 11: Neighbour to neighbour packet layer packet structure. Each box represents a single byte.

The packet is split into two parts: the first two bytes (length and flags) are used by the neighbour to neighbour packet layer, while the

remainder are for use by other layers such as the application layer. The length byte holds the number of bytes in the remainder of the

packet (including the flags, command and data bytes), while the flags byte is used for neighbour to neighbour and network layer

specific packet information. Details of the bits in the flags byte can be seen below:

Bit 0: Is the packet a network packet.

Bit 1: Does this packet require an acknowledgment to be sent back to the sending module.

Bit 2: Does this packet require a `global' network acknowledgment to be sent back to the sending module

Bit 3: Is this packet an acknowledgment.

Bit 4: Is this packet a `global' acknowledgment.

Reliable transmission is one of the responsibilities of the neighbour to neighbour packet layer, and to achieve this an acknowledgment

and resend scheme is used. This scheme is described as part of the state machines previously mentioned Fig. 9 and Fig. 10 and is used

to ensure a packet is sent successfully from device to device. This is achieved by repeatedly resending packets until an appropriate

acknowledgement is received from the recipient device or a timeout period has elapsed.

4.1.4 Network Layer The network layer works on top of the neighbour to neighbour layer and implements transmission of packets across a network of

connected modules. The network packet structure is shown in the Fig. 12 where the first byte indicates the length of the packet, the

second is used for communication dependent flags as described earlier, the packet ID byte is a unique ID for each packet, the Source

ID byte refers to the ID of the module sending the message, the Dest ID byte is used to identify the ID of the module where the packet

should been sent to, the Command byte is the command (passed to the application layer) which the destined module will do and finally

the Data[0] … Data[n] bytes are bytes associated to the command.

11

Fig. 12. Diagram of network packet structure

If a module wants to send a message to another module, it first constructs the packet, setting the appropriate flags and structure, then it

broadcasts the message to every module attached to it using the neighbour to neighbour packet layer and the waits for a ‘global’

acknowledgment back from the module it sent the message to. If no acknowledgment is received it tries a fixed (configurable) amount

of times to send the message. The send will then be classed a failure if it still does not receive any acknowledgment back. Fig. 13

shows the algorithm for sending a network message.

Fig. 13 Basic Sending Algorithm flow chart.

Each module has a queue that stores the Packet ID, Source ID and Destination ID of the last N (configurable) network messages

received in the module. When a module receives a network packet (identified for a flag in the flags byte) it first checks if the packet is

repeated (the packet is present in the aforementioned queue) and if it is will discard the packet; otherwise it will check if the

Destination ID byte matches the ID of the module. If the packet is not for the module that received the message the packet will be

broadcasted to all attached modules (except for the module that passed the message). However, if the packet is intended for the current

module a global acknowledgment packet is constructed and broadcast back to the source module (identified by the source ID byte in

the incoming packet). This global acknowledgement is also sent using the neighbour to neighbour packet layer and will be routed back

though the network in a similar way to the incoming packet. Finally after the acknowledgment has been sent the incoming packet is

sent to the application layer. Fig. 14 exemplifies the receiving network message described.

12

Fig. 14 Basic receiving algorithm flow chart

4.1.5 Application Layer The Application layer is a conceptual layer which utilises communication stack to do useful work. Developers using this platform can

implement their own system using neighbour to neighbour packet layer and network layer. We have implemented a selection of

commands for debugging and demo purposes. The commands that each module can perform are listed below Table 2.

Table 2 Application Commands

The request_id command asks to an attached module to return its ID. The return_id command returns the ID of the current module to

an attached module (that has previously sent a request_id command); whenever a return_id command is received the module saves the

returned ID in a routing table that stores what module is connected to what port. The request_routing command asks to an attached

module to return its routing table. The return_routing command returns the routing table of the current module to an attached module

(that has previously sent a request_routing command). The network_acknowledge command returns an acknowledgment packet to a

specified module (through its ID) on the network. The move_top_servo and move_bottom_servo commands move the top or the bottom

servomotors in the module to the specified position.

4.2 Sensors

4.2.1 Sensor Overview

4.2.1.1 Accelerometers

Accelerometers measure acceleration relative to a free-falling mass. A standard accelerometer consists of a transducer which is

essentially a mass on a spring; the displacement of this mass due to acceleration is then converted into an electrical signal. Because the

acceleration is measured relative to a free-falling mass a level, stable accelerometer will give a reading of one gravity upwards.

4.2.1.2 Ambient Light Sensors

Ambient Light Sensors are a variety of simple optical sensor which output a signal proportional to the level of ambient light in an

environment such as photoresistors or photodiodes.

13

4.2.1.3 Magnetometers

Magnetometers measure magnetic fields and can be used in conjunction with accelerometers and gyroscopes to form electronic

compasses.

4.2.1.4 IR Proximity Sensors

IR proximity sensors use the strength of the reflected IR light in order to infer the distance of the reflecting object; these systems are

often modulated in order to filter out ambient light levels.

4.2.2 Design

4.2.2.1 Accelerometers

Accelerometers can be used to measure acceleration on an object; velocity and displacement can be inferred from this with a certain

loss of accuracy. Three axis accelerometers can also be used to measure the tilt of an object relative to the earth’s gravity. This could

potentially allow the orientation of the robot, and any bumps, to be detected.

Some work was carried out early on in the project using a pre-mounted 3 axis accelerometer with an analogue output for each axis.

These outputs were monitored using an Arduino and the values then sent into MATLAB to be displayed on a graph. Using this setup it

was possible to observe changes on the outputs as the sensor was shaken or tilted. It was therefore decided that accelerometers could be

a useful addition to the module for feedback and control purposes.

4.2.2.2 IR Proximity Sensors

IR proximity sensors provide an output proportional to the distance from an object in a direction. This could be used by the module for

obstacle avoidance or other behaviours. Some simple circuits were constructed to test the principle of IR proximity sensors: a circuit

without modulation was built first and then a circuit with modulation was constructed. The circuit without modulation was able to

show a change on the output level with distance from an object at a range of 0-15cm but was very susceptible to ambient light level and

will not perform in direct sunlight.

The circuit with modulation did not suffer from a susceptibility to ambient light, however the output from the sensor required more

interpretation in order to relate it to distance. The ripple on the output of this circuit increases with the proximity of the reflecting object

rather than the level increasing as with the previous circuit. A system based on the Arduino was able to classify an object as being one

of five general distances from close to far based on the difference of consecutive measurements of this output, albeit with an error of a

couple of distances. The systems to use this sensor type need further refinement before they can be properly considered for inclusion in

the module.

4.2.3 Integration Unfortunately the sensor systems didn’t reach a stage whereby they would be suitable for inclusion in the module. Accelerometers,

ambient light sensors and magnetometers were all ordered and a PCB was designed to mount them on. These sensors all interfaced via

I2C so they were more complex to access the outputs from than had they been analogue outputs. I2C allows for up to 256 addresses on a

single bus so there is scope for a lot of sensors to be connected this way. Communication with the three sensors on the PCB was

attempted using the Arduino. This originally failed and after probing with an oscilloscope it was discovered that there was a fault on

the bus so each sensor was separated by cutting tracks on the PCB and communication with the accelerometer only was attempted.

The Arduino “wire” library is not suitable for I2C communication with sensors so the “I2C” library was downloaded. With this library

communication was established with the accelerometer but the outputs were not as expected. Unfortunately due to the limited time for

the project this couldn’t be investigated further.

4.3 PCB Design

4.3.1 Advantages of PCB Design PCB circuit design is more compact and reliable than breadboard or stripboard based circuit. It also allows for the use of surface mount

type components which both allows for further compactness and increases the range of available components that may be used.

Components used in the final circuit design were SOIC type surface mount components as these are small enough to allow for the

proper compactness of the circuit, but can be soldered by hand. This increased the speed at which they could be constructed.

4.3.2 Constraints The PCB was designed to be compatible with the Spirit Circuits Go Naked free prototyping service. This is a service whereby one copy

of a PCB design is constructed for free; this allows a design to be refined before committing it to a production run. The constraints in

place on this service are that the design can only include top and bottom copper layers and a drilling pattern.

14

Other constraints on the design of the PCB come from the size of the physical chassis in which the circuit has to fit. The physical

chassis size is based around the two servos; the space available for the circuit was measured as 120mm x 35mm.

4.3.3 Design The circuit was designed, as part of the earlier work on the communication between modules, in cadence's OrCad software and the

design of the PCB was done in National Instruments Utiliboard. Unfortunately it was not possible to copy the circuit across directly

from one software to the other nor was it possible to copy the circuit into cadence's PCB design software as intermediary software was

not installed on the computers used. Because of this the circuit had to be copied across manually.

The components were first placed, including headers, and then arranged so that components are close to the headers associated with

them but still have enough room around them to route copper properly. Components were then wired together as per the circuit

diagram. As many of the unused pins as possible were broken out from the microcontroller.

Figure 15 – Final PCB Schematic

In order to maximise the efficiency of the design routing has been mostly done so the horizontal wiring is on the bottom copper layer

and vertical wiring is on the top copper layer and connections between these two are done with vias. At points this wiring scheme is

impossible; for instance the microcontroller has both horizontal and vertical connections on the top copper layer.

Many of the sensors considered for use with the robot are only available in surface mount packages so in order to interface with them

another PCB had to be designed, the particular packages of the sensors mean that they had to be soldered using solder paste and an

oven. Some of the pin layouts for the sensors were non-standard so had to be manually constructed from measurements in the

datasheets for use on the PCB.

Figure 16 - Sensor PCB Design

The sensor board was made separate from the main board in order to keep the main board design as general as possible. At 15mm x

36mm the sensor board was designed to fit into the chassis in either orientation for maximum versatility.

As further copies of the main board were needed for our system (it having been verified as working correctly) as well as the sensor

board these were taken and panelised onto a standard euro card sized board and send off again for another free prototype.

Table 3 - Spirit Circuits Design Constraints

15

4.4 Electronics Prototyping and Implementation The circuits for the robot were prototyped on breadboard and tested and also implemented on strip board (in case that the PCBs did not

arrive on time). The breadboard and strip board prototypes are shown in the Fig. 17.

Fig. 17. Bread board and strip board prototype

One of the biggest problems we faced was the powering of the modules. Only one battery arrived and the charger that we bought could

not charge the batteries properly as we expected. We decided to power the modules straight from a DC power supply and made the

necessary arrangements on the boards to support this. The problem with using a DC power supply is that requires lots of wiring and

long wires between the power supply and the modules. These long wires increase the resistance in the circuit ground and when the

servo moves a strong peak current passes to the circuit ground and goes through the long wire to the power supply ground as shown in

the Fig. 18. The resistance present in this wire can cause the ground in the circuit to be lifted, causing problems with the

microcontroller and associated circuitry. This problem was solved by separating the grounds for the AVR and servos, as well as

increasing the current capacity of the ground wires. With the batteries we would not face this problem because the connection between

the circuit ground and battery ground would be short and so have a low resistance.

Fig. 18. Diagram illustrating the impedance of long wires. A long wire can act as resistor.

Another problem we came across was motor noise from the servos. When the servos moved – especially if they were under strain -

they would induce a significant amount of noise on the circuitry of the PCB. This caused intermittent and difficult to debug faults,

especially when combined with the moving ground problem mentioned above. To try to reduce the effect of noise on the sensitive

circuitry a large electrolytic decoupling capacitor was soldered to the PCB as near to the microcontroller as possible, helping reduce the

effect of noise on the circuit.

4.5 Discussion The electronics section of this project was a substantial undertaking and required a lot of time and effort for both design and

implementation. A communications system was designed and implemented for this modular robot, allowing for transmission of data

between neighbouring modules and across a network of linked modules. This communications system was made as general as possible

to allow for general purpose use and extension – a design choice that helped greatly when implementing and experimenting with the

application layer.

16

The communications system was naturally split into several layers during design. This modularity sped up development and

debugging, and increased the flexibility of the code. For example the general purpose and modular nature of the neighbour to

neighbour packet layer allowed the network layer to be easily built upon it.

A range of sensors were investigated and prototyped for use in this project, including accelerometers, light sensors, magnetometers and

IR proximity sensors. It was clear from this work that accelerometers could be a useful addition to a modular robot since a range of

information can be inferred from their output. Unfortunately, due to time constraints these sensor prototypes were not advanced to a

point at which they could be integrated into the modules, as they were prioritised below other parts of the system.

A PCB for the electronic circuitry developed during the project was designed, produced and tested. PCB design allows for a more

compact and reliable circuit than the other prototyping methods employed, thus improving system robustness and the use of surface

mount components.

Although problems were encountered during the implementation of the electronic subsystems of this project they were overcome with

help from careful testing and time management. The problems that were encountered gave useful experience and lessons to those

involved, allowing us to make better design decisions in the future.

If given more time there are a number of areas which could benefit from further work. Smarter routing strategies in the network layer

could be an interesting area to investigate, using routing tables and associated algorithms rather than a brute force approach. Another

task would be to improve the PCB design by incorporating decoupling capacitors and other protection measures such as a power

polarity protection diode. Incorporating battery charging and power onto the PCB would be another good area for extension work.

An obvious area for future work would be the integration of sensors into the modules along with applications based on the information

provided by such. Feedback systems based on the sensors could be a sensible area for further research as they open up a wide range of

possible behaviours. Fortunately the flexible and modular design of the system allows such extensions to be implemented easily.

17

5 Simulation

In parallel with the hardware design and construction, provisions can be made to prototype the application layer. This will include:

modelling each module, communication of messages and experimenting with movement patterns (gait).

5.1 Overview Currently the simulation system is able to model any number of modules. It was designed and developed in Blender [7] which is a free,

open source software package which integrates with the Bullet Physics library [8]. However due to severe limitations in the physics

software and the coding framework within Blender the simulation does not and will not accurately simulate the system.

5.2 Modelling Blender is an excellent 3D modelling software, which allows the creation of a user defined object with relative ease. However, it was

discovered that the physics game engine does not handle user defined shapes very well. This is because the physics require separate

boundaries for collisions and game simulation mechanics. This means the mesh for the object shape and the how it behaves during

collisions is different. These collision boundaries exist as built-in shapes and are not customisable causing the design contours to be

estimated. With this factored in, the module was designed as an approximation of the final design, as shown by Fig. 19.

Once modelled into a useable shape for the physics engine, the module needs to be connected and constrained in the same way as the

design. This was achieved by using Hinge constraints with maximum rotation between +90° and -90°.

5.3 Movement To establish simple movement in Blender, python script can be used to control the object’s game properties. With each module

deriving all movement from the two servos rotating in each end cap, only object rotation is necessary. Motion for each end cap can be

applied by assigning the objects a python script which applies a rotation when given a certain cue or message when another module

communicates with it.

5.4 Communication The communication between modules, the messages they send and the types of movements were to be prototyped in this section. The

communication properties and implementation would have to mimic the final application layer which built on the physical design’s

communication layers; meaning the underlying infrastructure was kept as close as possible to something which could be ported and

used in C++ for the real application layer. However, this proved difficult as Blender python scripts have no encapsulation which meant

all variables would be in scope to all scripts. These python scripts run in parallel and iterate immediately once per frame which meant

all commands had to be conditional and no variables could be stored within as they would reset. In order to get around this problem,

the main logic and functions for the communication was coded in one file as a class, called ModTemplate. The rest the of modules had

a separate file that was run continuously containing the ID of the module and a line of code which calls a step function within the

ModTemplate class which caused actions to occur based on what message had been. Although this is not an ideal way to simulate

decentralised control, the modules only reference themselves in the class (due to the ID) so the code does run in a modular fashion.

Overall this causes each module to run akin to a state machine. During every frame, the module will be in a state depending on the

logic and message. Once the command is completed, the module will signal the adjacent modules. The module will then look at the

next command in the list. If none, it will idle and until a new message is received, as shown in Fig. 20.

Fig. 19. Single Module approximated shape rendered in Blender. The triangles are added to provide the user with

reference to the current rotation of the end cap

18

Programming movement is limited in the Blender game engine. For instance, in order to get an object to rotate smoothly in the game

engine, the object must be rotated by a fractional amount per frame due to scripts running once per frame. As the script is dependent on

frame by frame iterations, a global reference counter needs to be made. This will give the modules a reference for rotation of the end

caps, which will mimic the servo movements. This was done by creating a global variable which lies outside the runtime of the normal

scripts and can be incremented every frame.

Using these methods, a prototype movement system was created. The next step would be to formulate a movement pattern to make the

system move.

5.5 Gaits With each module able to receive commands, movement from different movement patterns could be investigated. This required each

module to be constrained in the same fashion as the real interconnections. However, there is a fundamental problem with the physics

engine, which was that all rigid body collisions are elastic to some extent. This is most likely to give the environment stability by

providing all rigid objects a minimum amount of damping. This is what allows objects, if given enough force, to briefly intercept

another rigid body. During this time the object undergoes a repulsive force to separate the objects. This is true for rigid body

constraints, which means when the modules are connected in this manner and given enough force, the constraints separate and allow

elastic movement. The elastic movement of the interconnections is not conformal to a real life scenario. Because of this the simulation

results do not provide an accurate test environment for gait experiments. Fig. 21 shows the problems with the interconnections and the

limitations caused by elastic constraints when two constricted moving objects interact.

Fig. 20. (Left) Flow diagram of a Module. The Module waits for a message, once received it will iterate and

step the (movement) command until it is done.

Once complete it will signal it, and wait for the next

command.

19

5.6 Discussion

Using Blender a prototype system was created. The application layer was prototyped and later adopted into a modified working case in

C++ for the real device. However, it was unsuccessful for establishing gaits and it seems there is no possible way to achieve the desired

result in this particular physics engine. Blender is best suited for 3D modelling and animation, rather than accurately modelling

actuator or motors. This became apparent when two simulated servos moved in conflicting directions, causing the modules to glitch

through one another. A lot of time was invested researching potential solutions to this problem; however, each solution would require

compromising the framework of the script. For instance, one could join the meshes of the objects either side of the interconnection to

create one object consisting of a red and a blue end cap. By doing this it stops the servos from working properly as the objects origin is

used to apply rotation commands, and one object can only have one origin.

The Bullet physics library was first chosen as it was free, open source, popular and the documentation was fairly good. This seemed a

wise choice at the time as other robotic simulation programs required an expensive licence or were extremely hard to use. However, it

can be programmed directly in C++, but there was not enough time to complete the project in this manner.

If given more time it might have been possible to fix this problem by sacrificing all code portability and possibly even using key

frames to animate movement, but as this part of the project was more experimental and not fundamental, it was decided to concentrate

man power more important design sections.

Fig. 21. Image of four modules connected. The arrows on the module model should be aligned. The green circles highlight the types of errors that occur during movement. The far left shows displacement of the constraint. The middle and right circles show object

interception and the constraints being elastically stretched.

20

6 Results

The overall system was tested with some basic movement schemes.

Single module movement

Movement with two modules physically attached without networking

Movement with two modules physically attached and connected via network

Videos of the movements are included in the attached CD.

Fig. 22. Photograph of two modules attached and functioning without networking

Fig. 23. Photograph of two modules attached and functioning with networking

21

7 Project Management

Good management is absolutely crucial to the success of a project. This includes division of labour, based on the appropriate

individual’s skills and making sure task and deadlines are appropriately managed. As our project was quite ambitious, it was

fundamental we started work early and kept a steady pace throughout the allocated 12 week period. The team agreed to set aside a two

days a week for the project with one day of that week to meet up working together and discuss progress. Due to the severe lack of time

and amount of work, plans were made to work through the Easter holidays. However, some team members had already made plans to

leave the country over the Easter break. Therefore, it was paramount to delegate tasks along the critical path to individuals which were

able to work over Easter.

7.1 Team Management Tasks were delegated to each team member with the greatest experience in the field. With a large team with relatively diverse abilities,

tasks were delegated to individual(s) based on knowledge of the field, priority and importance to the critical path. However, as many

tasks where either very large or worked almost in parallel with each other, multiple people were assigned a category, see appendix A

for the Gantt charts listing the tasks.

7.1.1 Nikhil Banerjee: Electromechanical Engineer Nikhil was responsible for developing the mechanical design for the modules and worked in parallel to Max. The tasks in his role were:

procuring an actuation mechanism, chassis design and construction and electrical and mechanical connections. As a side task Nikhil

was also involved in the selection of simulation software and helped Will to troubleshoot problems with the software Blender.

7.1.2 John Charlesworth: Electronic Engineer John put himself forward for the role of treasurer as he had the most experience with the ECS requisition system. This role also

involved monitoring spending throughout the project. John was also responsible for the work done with sensors and for the design of

the PCBs and for most of the soldering done throughout the project.

7.1.3 Michael Hodgson: Electronic Engineer Michael proficient in embedded C++ from other project and was delegated microcontroller and communications. He implemented most

of the neighbour to neighbour packet layer as well as the physical layer; as well as general microcontroller testing and development. He

focused his efforts by collaborating with Romel on the communications part of the project.

7.1.4 Max Lotz: Electromechanical Engineer Due to his knowledge of electromechanical design; Max focused primarily on actuation and chassis constraints and his main tasks

involved construction and maintenance of each module. Max and Nikhil worked in parallel to develop the electromechanical design.

7.1.5 Will Neep: Electronic Engineer Will volunteered to take up the role of project manager. His duties included: division of labour, recording and maintaining meeting

minutes and Gantt charts, managing presentations and reports and was the main link between the group and the customer. This would

also include proof reading and structuring each section of the report. Will’s main technical responsibility was developing the

simulation environment for the system and prototyping the application layer for the final design. This including experimenting with

movement patterns in the simulation space.

7.1.6 Romel Torres: Embedded Computing System Engineer Due to his experience with microcontrollers, Romel focused on working on the servo control system. Romel collaborated with Michael

to develop the code for the module microcontroller. He also worked on testing, debugging and soldering prototypes (stripboard).

7.2 Subversion Control

As with almost all coding projects it necessary to setup a comprehensive subversion control system to keep track of development. This

was done using a combination of GitHub for C++ coding and Forge.ECS for documents and presentations. GitHub is a free distributed

subversion control system which uses the Git Revision control system, this is free service as long as the files are kept open source.

However, it is proven to be more effective for merging coding project. Forge.ECS provides a full subversion repository and is not

public, and hence was used for presentation material, meeting minuets and reports.

22

8 Discussion and Conclusion

Over the course of this project, we have designed, built and tested a general purpose modular robot system. By using a simple and cost

effective mechanical design we created an adaptable robotic platform capable of movement in two degrees of freedom. Mechanical

connections were achieved using magnets which were cheap and effective but awkward to mount and maintain however given our

limited resources and time this proved to be a good design trade-off between ease of manufacture, cost and reliability. Fiddly

Significant effort was invested into researching the optimal torque to weight, size and cost ratio for the module actuators. The chosen

servos allow modules to easily move and lift at least 1.5 times their own weight without operating at their maximum capacity.

A communications framework was devised to allow for both neighbour to neighbour and scalable multi-hop network communications.

This allows easy development of distributed applications in a generalised manner.

A range of sensors were evaluated for possible use in augmenting the module’s capabilities. Unfortunately time constraints meant that

other tasks were prioritised over this.

Prototyping for this project was completed on breadboard and stripboard, allowing for easy debugging and modification. Once the

design was finalised, PCBs were produced for each module, providing a compact and reliable electronics base.

A simulation of the system was produced to prototype the application layer, emulating a model of the physical and electronic elements

of the system. This simulation was used to help design strategies for movement, although due to the limitations the physical model

used this simulation was not as true to life as might have been desired.

This was an ambitious project given the time and resources available, but by employing rigorous management techniques such as

critical path analysis. This analysis was used to delegate time critical tasks to appropriate team members to cope with difficulties such

as short deadlines, timetabling issues and absences over the Easter break.

In conclusion we have designed and developed a general purpose modular robotics system. We have fulfilled all criteria of the

specification as described in section 1.3, building three working prototypes and demonstrating movement with distributed control. The

full potential of modular robotic applications have yet to be realised; with many systems still in the prototyping stages. Our system

provides a platform on which potential applications could be developed at a lower cost than other similar modular robotic systems.

23

9 Further Work

Due to the generic nature of our platform there is a wide scope for further work.

Another area of work would be to manufacture more modules, allowing us to investigate more complex behaviours and structures as

well as testing the limits of our platform.

In order to investigate more complex movement patterns, the simulation framework can be improved. This can be improved by

changing the physics engine, such as the AGEIA PhysX engine.

Further work involving augmentation of the modules with such as accelerometer or light sensors which could then be incorporated into

applications to model certain behaviours such as touch activation or light tracking. Different types of modules could be augmented with

speciality sensing or networking capabilities to further enhance the diversity of applications.

There is room for some improvement in the PCB design such as thicker ground and power lines and the inclusion of a decoupling

capacitor.

Costs can be reduced in the next prototyping stage by further investigation into decreasing the manufacturing complexity and materials

cost.

24

References

[1] M. Yim, W. Shen, B. Salemi, D. Rus, M. Moll, H. Lipson, E. Klavins and G. Chirikjian, “Modular Self-Reconfigurable Robot

Systems [Grand Challenges of Robotics],” Robotics & Automation Magazine, IEEE.

[2] D. Hoare, J. Krause, N. Peuhkuri and J. G. J. Godin, “Body size and shoaling in fish,” Journal of Fish Biology, 2005.

[3] National Institute of Advanced Industrial Science and Technology, “What's M-TRAN?,” [Online]. Available:

http://unit.aist.go.jp/is/frrg/dsysd/mtran3/what.htm. [Accessed 18 May 2012].

[4] V. Zykov, “Molecubes For Everyone,” [Online]. Available: http://www.molecubes.org. [Accessed 18 May 2012].

[5] A. Sproewitz, M. Asadpour, Y. Bourquin and A. J. Ijspeert, “An active connection mechanism for modular self-reconfigurable

robotic systems based on physical latching,” in Pasadena, CA, USA, May 19-23, 2008.

[6] V. Zykov, E. Mytilinaios, M. Desnoyer and H. Lipson, “Evolved and Designed Self-Reproducing Modular Robotics,” IEEE, 2008.

[7] “Blender.org,” 2012. [Online]. Available: http://www.blender.org/. [Accessed 15 May 2012].

[8] “Bullet Physics Library - Game Physics Simulation,” [Online]. Available: http://bulletphysics.org/wordpress/. [Accessed 15 May

2012].

25

10 Appendix A. Project Management Details

10.1 Example of Minutes

Date: 10/05/12

Attendants: Michael, Romel, Nikhil, John, Will, Max, Klaus

Agenda

1. Discuss Interconnect problems 2. Discuss Simulation problems 3. Discuss Presentation 4. AOB

Minutes

1. The glue attaching the magnets to the module is not bonding well. The strength of the magnets can in overcome the glue’s strength and cause magnets to become unstuck

a. Quick fix solution was to cover the magnets with a single layer of tape. However, Klaus advises us that Richard will not approve of this method

b. Other techniques to improve adhesion would be to heat the aluminium frame up with a hairdryer to hot air gun. This will cause the glue to cool slower when deposited allowing a stronger bond

c. Or we could drill small holes in the metal to cause a “glue-rivet” which will help secure the glue to the module side.

2. Blender uses bullet physics, but the physics engine causes a lot of objects to intersect, unlike in real life.

a. Klaus suggests this is most likely down to the engine allowing a minimum of flexibility on an object. If the surface of an object has infinite it will cause the physics engine to run unpredictably. There needs to be some form of intrinsic damping for all rigid body interactions.

b. Nikhil suggest a plugin to help cope with blender. (Will email link). c. As with the simulation in the presentation, can show some gaits and images. Keep videos

short and succinct. 3. Klaus suggest we approach the presentation as more of a narrative. Keep it engaging and make sure

it flows, other suggestions: a. ‘Radio Presenter’ style, with a chair moderating from the audience’s point of view. b. Title slide includes a small introduction/possibly some images of the system c. Limit the amount of words on the slides, the presentation is more flexible with images and

diagrams d. Too much material is bad, keep it engaging

4. AOB a. Arrange dates for the demonstration.

26

10.2 Budget

10.2.1 Project Costs Breakdown

Costs Project Spending Item Quantity Price Unit price Subtotal

Aluminium - - - -

16 MHz crystal 3 £ 0.83 £ 0.28 £ 0.83

18pF cap 10 £ 0.38 £ 0.04 £ 1.21

shift register 6 £ 2.88 £ 0.48 £ 4.09

multiplexor 5 £ 3.12 £ 0.62 £ 7.21

74HCT4052 3 £ 1.12 £ 0.37 £ 8.33

644P smt 3 £ 27.83 £ 9.28 £ 36.16

644P dip 3 £ 21.49 £ 7.16 £ 57.65

Decoder SOIC 3 £ 1.48 £ 0.49 £ 59.12

Multiplexor SOIC 3 £ 1.51 £ 0.50 £ 60.64

10kR, 805 100 £ 1.32 £ 0.01 £ 61.96

diode 30 £ 1.51 £ 0.05 £ 63.47

74HCT4053 4 £ 3.36 £ 0.84 £ 66.83

3 axis magnetometer 2 £ 3.74 £ 1.87 £ 70.57

3 axis accelerometer 2 £ 2.35 £ 1.18 £ 72.92

ambient light sensor 2 £ 1.58 £ 0.79 £ 74.51

Li-Poly charger 1 £ 11.66 £ 11.66 £ 86.17

Li-Poly battery 1 £ 6.48 £ 6.48 £ 92.65

servos 7 £ 112.00 £ 16.00 £ 204.65

644pv smt 3 £ 33.08 £ 11.03 £ 237.73

2.5V Zener 9 £ 0.79 £ 0.09 £ 238.52

0.1uF cap 100 £ 0.84 £ 0.01 £ 239.36

4.7uF electro cap 10 £ 1.03 £ 0.10 £ 240.39

1row 40way header 1 £ 0.97 £ 0.97 £ 241.36

Magnet 150 £ 15.00 £ 0.10 £ 256.36

Table 4

Breakdown of all costs spent over the project duration

27

10.2.2 Price of a Single Modular Robot

Price for single module - in a bulk order of 20+

Item Quantity Unit Price Price

Aluminium 1 £ 2.00 £ 2.00

PCB 1 £ 5.00 £ 5.00

16 MHz crystal 1 £ 0.28 £ 0.28

18pF cap 2 £ 0.04 £ 0.08

Microcontroller (644pv smt) 1 £ 11.03 £ 11.03

Decoder soic 1 £ 0.49 £ 0.49

Multiplexor soic 1 £ 0.50 £ 0.50

10kR, 805 12 £ 0.01 £ 0.16

Diode 6 £ 0.05 £ 0.30

3 axis magnetometer 1 £ 1.87 £ 1.87

3 axis accelerometer 1 £ 1.18 £ 1.18

Ambient light sensor 1 £ 0.79 £ 0.79

Li-Poly battery 1 £ 6.48 £ 6.48

Servos 2 £ 16.00 £ 32.00

2.5V Zener 3 £ 0.09 £ 0.26

0.1uF cap 1 £ 0.01 £ 0.01

4.7uF electro cap 1 £ 0.10 £ 0.10

1row 40way header 1 £ 0.97 £ 0.97

Magnets 48 £ 0.10 £ 4.80

Total: £ 68.30

Table 5

Approximate breakdown of costs for a single module given a bulk order of 20 or more PCBs

28

10.3 Gantt Charts

Fig. 24. Gantt chart of planned work

29

Fig. 25. Gantt chart of actual work

30

11 Appendix B. Hardware Design Diagrams

Fig. 26. Dimensional schematic of module end cap

31

Fig. 27. Dimensional schematic of centre body.

32

12 Appendix C: Additional Photos of Final Prototype

Fig. 28. Photograph of single module with servos at opposite maximums

33

Fig. 29. Photograph showing top of view of module

34

13 Appendix D: Labelled Diagram of Connection Hardware