Institut for Elektroniske Systemer
Datateknik
Fredrik Bajers Vej 7, 9220 Aalborg, Danmark
Telefone 99 40 86 00
http://es.aau.dk
Title: Warehouse Robot
Theme: Embedded Systems
Project period:
P3, fall 2008
Project group:
350
Participants:
Anders Tornvig Christensen
Andri Óskarsson
Henrik Holbaek Pedersen
Martin Bűnger
Mikkel Jensen
Supervisor:
Morten Bisgaard
Issue count: 7
Page count: 106
Finish date: 16.12.08
Synopsis:
Purpose of this project was to create a
prototype of an automated warehouse
robot, capable for picking up packages in
a warehouse while navigating by itself and
then delivering the packages.
The prototype was created with building
blocks, electrical motors and light sensors
from the LEGO NXT robot kit. These
components along with the MSP430 from
Texas Instruments and a few elctrical
components were the key elements of the
project.
Software was created in C using IAR
Workbench.
This report covers all aspects of the prototype from a problem description to design, implementation and test and concludes with an acceptance test and a conclusion.
Contents
Contents
1
1 Introduction
3
2 Design decisions
5
2.1
Steering implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2
Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.3
Package pickup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.4
Goods layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.5
Multi-threading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.6
Signaling motors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3 Requirement specification
11
3.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2
System description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3
Requirements for development process . . . . . . . . . . . . . . . . . . . . . 13
3.4
Functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5
Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.6
External Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4 Acceptance test specification
25
4.1
Configuration Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2
Warehouse mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5 System overview
27
5.1
System functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2
Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.3
System architecture
5.4
MSP430 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6 Hardware design
6.1
37
Hardware overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
1
2
CONTENTS
6.2
Power supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.3
Motor driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.4
Light sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.5
Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.6
Hardware layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.7
MSP430 pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.8
Chassis construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7 Software design
59
7.1
User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.2
Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.3
Tower . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.4
Module specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
8 Implementation
67
8.1
Main . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
8.2
Initialization
8.3
User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
8.4
Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
9 Acceptance test
9.1
89
Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
10 Future of the system
91
11 Conclusion
93
11.1 Project status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
11.2 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
11.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
11.4 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
11.5 Future of the system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
11.6 Final words . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
List of Figures
95
List of Tables
96
Bibliography
99
A CD-ROM Index
101
B Code structure
103
Chapter
Introduction
This report presents a project made in the fall of 2008 by third semester datateknik group
350 at Aalborg Universitet. In this semester it is required to write software for embedded
hardware. Specifically, students are provided a MSP430 micro controller to build hardware
of their choice around - that is motors, sensors, etc. for interaction with surroundings. For
construction of the chassis the group was given the option of using Lego Mindstorms NXT.
To meet the requirements, this project concerns the building of a robot to drive around
in a warehouse - controlled by the MSP430, chassis built in Lego. Within the warehouse the
robot must be able to perform certain tasks like gathering/delivering goods and navigate.
Ideally, the robot will be able to function in the warehouse without any human interaction.
Concerning the structure of the project phases and partly this report, a requirement
specification is made first. Thereafter based on a complete requirements specification,
design of both hardware and software modules as interfaces between them is planned. This
design is hereafter implemented and eventually tested - also following test specifications.
3
1
Chapter
Design decisions
This chapter details design decisions made during the brainstorming and idea development
process.
2.1
Steering implementation
Turning on a warehouse floor was presented with primarily two steering design options
(see figure 2.1)(as explained in Building Lego Robots [Building Lego Robots]). Inwards
turning or so called ’differential drive’ when the vehicle is able to do ’zero turn radius’ turns,
such as in tanks when both wheels can be used in opposite direction to make sharp turns.
The other implementation is outwards turning or so called ’ackermann steering’ [Ackerman
steering principle], where the vehicle has a ’turning radius’. The ’turning radius’ will make
the robot able to turn while moving forward like automobiles. Since automobiles have
unlocked wheels it can turn, just by moving the wheels, this is hard to implement, so the
robot will turn by rotating faster on one wheel. For the warehouse robot a steering which
is similar to differential driving was chosen. Similar in the way that the motors cannot turn
like they do in an ackermann steering, but are locked in position. But unlike the description
of differential steering, the wheels on the robot cannot drive separate directions. This was
done because a zero turning radius and due to the simplicity of the implementation.
2.2
Navigation
Three navigation methods were considered; following lines on the floor, using ultrasound to find the position of the robot and then navigate by coordinates, or using dead
reckoning.
Following line
To use the follow line method, there are some basic requirements. The warehouse needs
to have lines on the floor, that indicates where the robot should drive. The method needs
one or more light sensors to work. Depending on the implementation, the robot can swing
from side to side to search for the line. In that case, when it is instructed to stop, the
5
2
6
CHAPTER 2. DESIGN DECISIONS
Figure 2.1: Ackerman, differential drive and the robots way of turn.
system will not know if it is positioned oddly on the line. This challenges the fact that
the robot is required to make exact turns - for instance to move away from the line and
collect a specific package.
To find the right package, the warehouse needs more than one type of lines, so it can find
out where it is. This can be done by placing a mark in front of every shelf and another
mark where the package is. In this way the robot can count the lines and then find the
package.
Ultrasound
The other option for navigation in the warehouse is ultrasound. The overall concept of
this method is to map the entire warehouse in a system of co-ordinates - routes, shelves,
goods, obstacles, etc. - and position the robot using ultrasonic senders and receivers.
Knowing the characteristics of the warehouse as well as the position of the robot, it is
possible to navigate, handle packages, calculate shortest route to specific package destinations, etc.
For computing the position of the robot, triangulation can be used, and this math sets
up various requirements to the hardware. First, it is crucial to the accuracy of the positioning that a system with a synchronized clock is handling the corner sensors, because
it has to calculate the differences between the sensors’ individual time of arrival (TOA).
When the pulses from the senders travel at the speed of sound, and the distances between
senders and receivers never will become very long in the defined warehouse (section 3.1),
the synchronized system also has to have a relatively high time resolution to even measure
a difference in TOA.
Moreover, to gain accuracy it is worth considering having more receivers. This will generate more results of the triangulation for comparison and optionally calculation of an
average result. Filters could also be designed to filter out other frequencies than the one
2.3. PACKAGE PICKUP
7
of the pulse/tone.
Among the advantages of this system is flexibility. Without even taking notice of the
starting point, the robot can function in a warehouse as long as it has a preloaded map.
Lines will not be necessary, and algorithms for e.g. turning in curves instead of corners to
save time, can be implemented.
Among the disadvantages of the system is its relatively complex implementation to
get an acceptable accuracy. There is also the fact that the shelves in an inconvenient
warehouse layout can block the signal and thereby the connection between senders and
receivers.
Dead reckoning
Another option for navigation is using dead reckoning, the concept of this method is
using a previously known position, direction and the speed to calculate the current position
of the robot. Using that method renders navigation method unnecessary, since the robot
will know the complete and precise layout of the warehouse and then be able to calculate its
position. A problem with dead reckoning is that the sensor input, speed and position have
to be precise. If they are just slightly off, the position calculated will become increasingly
inaccurate the longer the robot is driving. A way to overcome this problem could be to
add a tachometer to the motors and that way be sure exactly how much the wheels have
turned since the last measurement. However, it would make using the robot in another
warehouse a non-trivial task as the layout of the given warehouse must be known in order
to use dead reckoning, and if the texture of the floor the robot has to drive on is different
than the original warehouse the wheels might slip more and thus the calculations would
have to be adjusted.
Conclusion
The complex implementation exclude ultrasound even though it possesses attractive
features. Still, accuracy and reliability in the position of the robot is important for the
system to work. Dead reckoning alone is problematic in fulfilling those requirements, but
combined with follow line it becomes ideal. From this point in the report, the following of
a line is combined with the dead reckoning method is considered the method for navigation
the robot around in the warehouse. For reliability in staying on the line, the follow line
method is used.
2.3
Package pickup
In this section, two methods for lifting goods will be considered, tower and a grappler
arm, in order to decide which one to use. Based on this decision, the physical layout of
8
CHAPTER 2. DESIGN DECISIONS
the goods will also be decided.
Tower
Tower is normally used lifting method on forklift trucks which lift pallets. In the
construction of towers, there needs to be a tower that can lower and raise the forks in a
chain. That way only one motor is required to operate it. A problem is that the holes in
the pallets, where the forks are going, can be rather small depending on their design. This
establishes a requirement for precision to load the pallets on the tower.
Grappler arm
Grappler arm is normally used method to lift single items with various shapes. Concerning the construction of a grappler arm, a motor ensures the ability to open and close
two arms around an item. Depending on the design, the same motor or another one can
then lift the grappler arm. One problem with using a grappler arm is that it requires a
rather strict definition of shape of the goods lifted. They cannot be too fragile, they can
only be lifted one at a time and they are required to have certain size and firmness.
Conclusion
The decision whether to use a tower or a grappler arm comes down to what kind
of goods the forklift is lifting. Forks lift pallets and a grappler arm lifts single items.
Because the pallets offer consistency in the goods layout, the forklift has to deal with at
any destination, these will be most convenient to use. The forklift will never have to deal
with what is actually on the pallets, while the grappler arm on the other hand will have
to know if it is boxes, rugs or candy - each of which would require a different grappler
arm design. The flexibility in the shape of the goods is preferred, which is why the lifting
device will be designed as a tower.
2.4
Goods layout
Since a tower is used to lift goods, the layout of them will be pallets. The goods loaded
on them can be anything, which basically means that they are uninteresting to the design
of the robot. Maximum weight of the goods is not determined at this time due to the fact
that our prototype is made of relatively light plastic, instead of steel, for example.
2.5
Multi-threading
A way to possibly speed up the implementation process and raise the level of abstraction would be to make use of threads instead of interrupts. This could be done in several
ways, either by implementing a kernel specifically for this system or using one of the several already available for the MSP430 microcontroller, that offers everything needed for a
multithreading implementation.
To use threads there are a few things that must be taken into consideration. To take full
2.6. SIGNALING MOTORS
9
advantage of threads, the individual threads have to be able to share information between
each other using a container. To avoid corrupting the data stored in the container, two
(or more) threads may never be able to access the data at the same time. For that purpose a semaphore is used, for example a mutex. Simply put, a mutex (mutually exclusive
semaphore) can be locked whenever a thread is reading or writing data to the container
which makes sure no other thread can access the data before the mutex has been unlocked
again.
While threads may allow us to perform tasks more simultaneously than by use of interrupts directly the overhead of running a complete kernel on top of the platform is too great.
Instead we decided to control our interrupts manually and avoid blocking the program.
2.6
Signaling motors
In the project, three NXT motors are required, and as it will be described later, they
are controlled by PWM signals. Also, to enable/disable and control the direction of the
motors, the PWM signals need to go through H-bridges. This leaves different methods to
control the motors. Two of them are briefly described here.
The first method uses one PWM signal which it sends through three S/R latches. Without getting too much into details, these latches will require four steering (enable/disable)
signals to control all three motors with one PWM signal. An advantage of this method is
the fact that only one PWM signal is needed and that simple H/L signals intuitively are
easier to control in software. Unfortunately, this also means that it is only possible to drive
at one pace when two motors are active at the same time. This ultimately means that it
will not be possible to make ”smooth” turns (drive forward with two different speeds on
the drive motors).
The other method relies on six independent PWM signals and one global enable signal
to all motors. The different motors are then steered accordingly to which pins on the
MSP430 output is sent. The method will probably be heavier to implement in software
but certainly lighter in hardware. It also offer greater flexibility in the steering. Direction
and speed are completely independent.
The second method was chosen as it offers more flexibility with turning and motor
controls.
Chapter
Requirement specification
3.1
3.1.1
Introduction
Purpose
This requirement specification specifies the complete implementation of a warehouse
robot. The system is to be implemented using a MSP430 microcontroller. Development
of the system is to be done using elements of the agile development model SPU [SPU].
3.1.2
Reading guide
In order to best describe the system requirements the starting point is the ’Problem
Description’ that have been used as a question in order to create the ’Use cases’. Before
these, the ”Functional requirements” they are to fulfill are specified. After the use cases, a
description of the user interface and the hardware interfaces is given.
Activity diagrams are used throughout the design phase and help define activities in
detail. They start with a black circle, end with a black double circle and contain ’activities’
represented in a rounded rectangle and decisions in the shape of a diamond.
The terms ’system’ and ’robot’ are used for the entire system; including the MSP430,
all hardware attached to the system and all software.
3.2
System description
The purpose of this project is to make warehouse operations more smooth on a day to
day basis. By automating delivery of packages, money and time can be saved. Goods are
generally stored on marked shelves.
These considerations lead to this following problem which describes the basis as well
as the overall goal for this project.
11
3
12
CHAPTER 3. REQUIREMENT SPECIFICATION
Problem description:
”How would one design a prototype of an autonomous robot that can drive
around a warehouse, find and deliver user chosen goods while being able to
navigate itself with help of lines on the warehouse floor?”
Warehouse layout
The system is developed for a warehouse with the layout in figure 3.1. The tape is
Figure 3.1: Warehouse layout
really white and the floor grey. The prototype layout (as seen in figure 3.1) of a warehouse
consists of 3 racks where each rack has a shelf with room for 3 packages or a subtotal of
9 package locations. There is one color of line to drive on, another one to mark the racks
and shelves. The line between the racks is placed ten centimeters from the shelves. At the
destination where the robot starts and where the packages are supposed to be delivered
to, there is also a line which is the same color as the rack lines which is used to indicate
that the robot has reached the destination. These colored lines will be used by the robot
to navigate.
System influences
With the problem and warehouse description in mind, figure 3.2 shows an abstract
overview of main components in the system and the influences it must be able to process
and act upon. On figure 3.2 the arrows show the direction of interaction between the
components. For a user to be able to instruct the robot by placing orders, an user interface
3.3. REQUIREMENTS FOR DEVELOPMENT PROCESS
13
Figure 3.2: System influences
has to be present in the system. The PC handles that by getting input through a keyboard
and by responding through a display. Orders are sent to the robot through an interface. It
will navigate to/from packages with help of lines and also lift/lower them when necessary.
3.3
Requirements for development process
The software will be programmed in IAR workbench, which can be used for programming and debugging and the software will be written in C.
3.4
Functional requirements
The functional requirements are represented in the following use cases. Using the Use
Case models makes it much easier to split the system into smaller parts which makes a
structured iterative development process possible.
Use case 1
Requirement 1.0: Locate package
System should be able to capture and store package orders from the configuration interface
and process them in warehouse mode.
Requirement 1.1: System modes
System should be able to access both configuration- and warehouse mode by use of the
mode switch
Requirement 1.2: Serial interface
System should be able to communicate with a computer on through a R232 connection.
14
CHAPTER 3. REQUIREMENT SPECIFICATION
Use case 2
Requirement 2.0: Navigate line
System should be able to navigate the lines on the warehouse floor. Straight lines as well
as turns.
Requirement 2.1: Light sensor
System should be able to read brightness values from the navigation lines on the warehouse
floor.
Requirement 2.2: Drive motors
System should be able to run both drive motors according to the system’s position on the
line.
Requirement 2.3: Recognize different line colours
Different line colours need to be recognized by the system.
Use case 3
Requirement 3.0: Pick up package
Use dead reckoning to drive towards the rack and pick up the package using the lift.
Requirement 3.1: Take a precise 90 degree turn
At the line, take a precise 90 degree turn.
Requirement 3.2: Drive distance
Drive a precise distance forwards, using both motors.
Requirement 3.3: Lift Package
Lift the package (using lift motors) and drive backwards a specific distance.
Use case 4
Requirement 4.0: Deliver package
Find its way to the drop off point and lower the package.
Requirement 4.1: Navigate back to base
Follow the navigation lines back to base
Requirement 4.2: Lower package
Lower package with the lift and drive backwards until forklift has cleared the package.
3.4.1
Actor-context-diagram
Actors:(See figure 3.3)
• User
• Technician
• Light sensor
3.4. FUNCTIONAL REQUIREMENTS
15
Figure 3.3: Actor context diagram
• Distance sensor
• Tower
• Drive motors
• Mode switch
3.4.2
Actor descriptions
The following section will describe the actors involved in the system together with a
definition of their type. The different types of actors are:
• Primary actor - Has one or more goals which must be fulfilled by the system
• Secondary actor - Is a part of one or more Use Cases, needed to fulfill a primary
actors goal.
In some cases an actor can be both primary and secondary.
Actors
• User
– Type: Primary
– Description: The user uses a PC to select the package which is to be picked up
by the robot.
• Technician
– Type: Primary
– Description: The technician will solve any critical errors the system might encounter.
• Light sensor
– Type: Secondary
– Description: Enables the robot to follow lines on the warehouse floor.
• Tower
– Type: Secondary
– Description: Used to pick up and carry packages.
16
CHAPTER 3. REQUIREMENT SPECIFICATION
• Drive motors
– Type: Secondary
– Description: Used for navigation.
• Mode switch
– Type: Secondary
– Description: Used to switch between configuration mode and warehouse mode.
3.5. USE CASES
3.5
17
Use cases
Description of Use Case diagram
Figure 3.4: Use case diagram
The use case diagram 3.4 shows an overview of which Use Cases the warehouse robot
consists of. The actors are listed on the edge of the diagram while the Use Cases are listed
inside the square box. Each Use Case is connected with a line to the actors involved in
the given Use Case.
Use case 1: Locate package
Goal: Determine which package should be collected by the warehouse robot, and where it
is located in the warehouse.
Initiation: The user enters on the PC which package he wants.
Actors:
Primary: User
Secondary: PC
Start conditions: The robot is in configuration mode.
Successful result: The PC instructs the robot where to find the package.
Result after an exception: The robot is not told where to get a new package, and the user
is given a warning.
Normal scenario 1:
1. User enters a package placement
[ User enters an invalid command ]
18
CHAPTER 3. REQUIREMENT SPECIFICATION
2. The PC sends the location of the package to the robot.
3. The user uses the switch on the robot to switch into warehouse mode
4. The robot enters warehouse mode
Exceptions:
1a [ User enters an invalid command ]
Warning about invalid command is displayed on the computer.
3.5. USE CASES
19
Use case 2: Follow line
Goal: Follows the line on the floor of the towards a specific rack number stop when a
vertical line is detected.
Initiation: The system starts this Use Case.
Actors:
Primary: None
Secondary: Drive Motor, light sensor.
Starting conditions: The robot is positioned on the line it is supposed to follow.
Successful result: The robot follows the line until rack number is reached, follows until
shelf number is reached, then stops
Result after an exception: No exceptions.
Normal scenario 1:
1. Robot tries to locate the line it is supposed to follow.
2. The robot will continuously adjust its position on the line using light sensors.
3. The robot will follow line until rack number is reached, then turn.
4. The robot will follow line until shelf number is reached, then stops.
Exceptions: None.
20
CHAPTER 3. REQUIREMENT SPECIFICATION
Use case 3: Pick up package
Goal: Navigate from the line to the package and pick up the package.
Initiation: The robot has arrived at the location of the package.
Actors:
Primary: None
Secondary: Distance sensor, tower
Start conditions: The robot is in warehouse mode and at a desired package destination.
Successful result: The robot has the package on the tower and is back on the line.
Result after an exception: None
Normal scenario 1:
1. The robot leaves the line and use dead reckoning to position itself in front of the
package.
2. The robot lifts up the package.
3. The robot returns to the line with the package on the tower.
Exceptions: None
3.5. USE CASES
Use case 4: Deliver
Goal: To deliver the package to the base.
Initiation: The system starts this Use Case
Actors:
Primary: None
Secondary: Tower
Start conditions: The robot has picked up a package.
Successful result: The robot deliver the package.
Result after an exception: None
Normal scenario 1:
1. The robot drives to the destination using the Use Case Follow line.
2. The robot delivers the package at the base.
Exceptions: None
21
22
3.5.1
CHAPTER 3. REQUIREMENT SPECIFICATION
System limits
• System currently only operable in a pre-defined warehouse.
• System currently only supports RS232 interface for user commands.
• System can only pick up and deliver package to a pre-defined base.
• Packages can not be moved between shelf destinations.
3.5.2
User profile
System such as this will primarily used by warehouse workers and on a daily basis.
The users will be required to be familiar with the daily operations of the robot. Although
the users will not require any special education, they will need a small course in modifying
the package queue.
3.6. EXTERNAL INTERFACES
3.6
3.6.1
23
External Interfaces
User Interfaces
Interfacing with the system will be facilitated with a RS232 (serial) interface. Communication is done by use of a terminal emulation program (such as Hyperterminal or
Minicom) on a computer, connected to the system. Commands can then be sent to the
system through the serial interface and the system responds back when a command has
been acknowledged/rejected.
Therefore, the complete functionality of the deployed robot consists of two modes.
’Configuration Mode’ is when the robot is at its base station, connected to a computer. In this mode the system can be configured with new coordinates, coordinates can
be changed or removed.
’Warehouse Mode’ is when the robot has been disconnected from its base station, placed
at the starting point and the ’Start’ button is pressed.
3.6.2
Hardware Interfaces
While the brain of the system is the MSP430 microcontroller there are other interfaces
that interface with the system. Light sensors are used to identify the lines on the floor for
guidance around the warehouse. Electrical motors are used to drive the system and for
lifting the forklift up and down. The MSP430 microcontroller is required to regulate the
voltage on the motors, reading values from the sensors and write it to memory so it can
be read by the program.
The ’Mode switch’ is responsible for interrupting the system while running and to start
it when it’s running in ’Configuration Mode’. The button is like other sensors connected
directly to the MSP430.
Chapter
Acceptance test specification
In order to see if the final product is acceptable to our specifications these test specifications
can be used to determine which requirements are met and which are not. The test is
performed as a black box method, as the user is not familiar with any of the inner workings
of the system when performing the tests.
4.1
Configuration Mode
Steps to determine if the unit can be configured before going into warehouse mode.
Will determine if configuration mode is accessible and if the robot is able to store and
execute package orders.
Environment:
System is connected with a serial (RS232) cable to a computer, then accessed with a
terminal emulation program. Satisfies requirement 1.0-1.2.
Expected result:
1. Coordinates are entered and acknowledged.
2. Package queue should list all coordinates in queue.
User guide:
1. Place the robot next to a computer, equipped with a serial interface (RS232).
2. To access the ’configuration mode’ flip the ’mode switch’.
3. Turn on the robot.
4. Start a terminal emulation program and set it to: Speed 19200 baud, no flow control,
8 data bits, 1 stop bit. Connect to the serial interface.
5. Enter new package order: pkg 2 1
6. List package orders: list
7. Done entering package orders: done
8. Flip the mode switch (robot then enters warehouse mode).
25
4
26
4.2
CHAPTER 4. ACCEPTANCE TEST SPECIFICATION
Warehouse mode
Determines if the system can navigate the warehouse, pick up packages and deliver
them without user interaction.
Environment:
System is on a simulated warehouse floor with lines according to the warehouse specification, see section 3.2. Package should be at located at rack x, shelf y; as well as already
configured from configuration mode (see "Configuration mode" 4.1). Should satisfy requirements 2-4.
Expected result:
1. Robot should be able to follow the lines and adjust motors according to light sensor
inputs.
2. Robot should be able to navigate the floor towards a specific rack and shelf space.
3. Robot should make a 90 degree turn, use dead reckoning towards the shelf space and
pick up the package using the tower lift.
4. Robot should be able to navigate itself back to base, with the package and offload it.
User guide:
1. Robot has been configured and is turned on.
2. Robot is placed on a line.
3. User flips the mode switch, triggering the warehouse mode.
4. Robot starts processing package orders, picks up and delivers packages.
Implementations of these specifications are covered in section 9.
Chapter
System overview
In the following sections the entire system is designed and divided into modules that can
be implemented directly. This specific chapter seeks to sum up the design outlined in the
requirement specification and its use cases. It does this by establishing the overall design
of the system, including both hardware and software.
5.1
System functionality
With respect to the use cases, the complete functionality of the system is illustrated
on figure 5.1. Notice that the robot cannot move packages between destinations. From
Figure 5.1: Flowchart showing system functionality based on use cases
27
5
28
CHAPTER 5. SYSTEM OVERVIEW
this flowchart, three main states (tasks) are identified. The ’User Interface’, responsible
for interacting with the user, depends on a serial communication with a computer. The
navigation depends on light sensors, drive motors and tachometers in order to be able to
navigate the warehouse. The tower uses a single motor with a tachometer.
The states (eclipses) represent so-called processes in the system.
The term is used to describe the system in smaller parts, making the abstraction level
higher and the overview of the system easier. A process can contain one or more modules,
and the processes is used to fulfill functional requirements.
Modules are used to split processes into even smaller parts, lowering the abstraction level
and bringing the design documentation closer to the implementation. The actual modules
will be introduced later.
5.2
Modes
The three different processes depend on the situation and are therefore only used in
certain contexts, for instance the user will not be able to access the Tower process directly
from the User Interface. Hence, they are furthermore encapsulated by two other states,
the modes briefly described in the requirement specification, see section 3.4. The division
is shown in figure 5.2. The two boxes within the "system" box represent modes, the three
tower
user interface
configuration mode
navigation
warehouse mode
system
Figure 5.2: Overview of modes and processes
eclipses represent processes and the circle represent the user, and how the user can interact
with the system. The system consists of two modes, configuration mode and warehouse
mode, which the user can toggle between using a switch placed on the robot.
Configuration mode consists of the user interface through which the user and the robot
interact. This functionality is covered by one process, the User Interface process. To enter
the mode, the RS232 cable must be plugged in and the mode switch toggled correctly.
5.3. SYSTEM ARCHITECTURE
29
When the user has instructed the robot and toggled the mode button, warehouse mode
takes over. Warehouse mode is responsible for the actual package retrieval which include
driving to the right package destination, picking up the package, driving back to the base
and eventually delivering the package, also in correspondence with the use cases, see section
3.5.
5.3
System architecture
The considerations about processes and modes suggest the following system architecture on software level.
main()
init
Mode switch
ui
nav
Figure 5.3: System architecture flowchart
As shown in figure 5.3 the main function of the program will initialize the hardware
(motors, ports, timers, sensors, etc) then loop forever while checking the status of the mode
switch. If the mode switch is on, the ware house mode is called, otherwise the configuration
mode is called. The UI function (configuration mode) is then responsible for modifying
the package queue before it is read by the nav function (warehouse mode).
30
5.4
CHAPTER 5. SYSTEM OVERVIEW
MSP430
The system is built on top of a MSP430 and this section will detail the parts of the
microcontroller used in the system. The primary source of information about the MSP430
is from the [MSP430 User Guide] and the [MSP430 Datasheet].
The MSP430 from Texas Instruments is a ultra-low power microcontroller, and it has a 16-
Figure 5.4: Block diagram of the MSP430
bit RISC CPU which is used to control the warehouse robot. The MSP430 microcontroller
offers many features seen in 5.4 of which the following is used to realize the warehouse
robot:
5.4.1
Basic Clock
On the MSP430 there are 3 different clock generators to choose from. A low frequency
clock generator, LFXT1. A high frequency clock generator, XT2, running at 7.3728 MHz.
Last option is to use the low frequency digitally-controlled generator, DCO. The warehouse
robot will be using the XT2 clock generator. The frequency of the XT2 is 7.3728MHz.
After at clock generator is selected, three signals will be generated:
• Auxiliary clock, ACLK, can be used for peripheral modules
• Sub-main clock, SMCLK, can be used for peripheral modules
• Master clock, MCLK, used by the CPU.
All the signals generated can be divided by either 1, 2, 4 or 8.
The Basic Clock module is used for serial communication in the USART module and
for timers, used for the PWM signals.
5.4. MSP430
5.4.2
31
Watchdog
The watchdog is a system which is supposed to avoid lockups of a system. When
implemented, the program needs to reset it over and over while the program is running.
If the watchdog registers that it has not been reset before its timeout, it will reboot the
system. This is especially a useful feature if it is not possible to physically reach the
hardware, in case it needs a reboot. The watchdog timer is not in this system.
5.4.3
Interrupts
Whenever an interrupt occurs the microcontroller will stop normal program execution and instead run an interrupt service routine, ISR. When the ISR has completed, the
program will continue where it was before the interrupt. The process of leaving normal
program execution to run an ISR is done in the following steps:
1. Any currently executing instruction is completed.
2. The PC, which points to the next instruction, is pushed onto the stack.
3. The SR is pushed onto the stack.
4. The interrupt with the highest priority is selected if multiple interrupts occurred
during the last instruction and are pending for service.
5. The interrupt request flag resets automatically on single-source flags. Multiple source
flags remain set for servicing by software.
6. The SR is cleared with the exception of SCG0, which is left unchanged. This terminates any low-power mode. Because the GIE bit is cleared, further interrupts are
disabled.
7. The content of the interrupt vector is loaded into the PC: the program continues
with the interrupt service routine at that address.
See [MSP430 User Guide]
Explanation of abbreviations:
PC : Program counter. This register is what keeps track of which instruction is to be
executed next.
SR : Status register. This register is used to control if the CPU and Oscillator is turned
on. Also it is used in calculations, where it has bits that indicates if a calculation turned
32
CHAPTER 5. SYSTEM OVERVIEW
out negative, zero or if the calculation produced a carry.
The process of terminating normal program execution and running an ISR takes 6 CPU
cycles without counting the cycles it takes to run the ISR itself.
When the ISR has completed the microcontroller will return to normal program execution with the following steps:
1. The SR with all previous settings pops from the stack. All previous settings of GIE,
CPUOFF, etc. are now in effect, regardless of the settings used during the interrupt
service routine.
2. The PC pops from the stack and begins execution at the point where it was interrupted.
See [MSP430 User Guide]
These steps take 5 CPU cycles, which make the whole process of handling an interrupt
take 11 CPU cycles when not counting the cycles used in the ISR.
In our system interrupts are used when a part of the hardware needs to trigger an event
in software. For example interrupts are used to indicate that we have received a character in serial communication and to generate PWM signal for the drive motors from a timer.
5.4.4
USART
Universal Synchronous/Asynchronous Receiver/Transmitter or USART is used for communication. In asynchronous mode the packages are sent with a start and a stop bit, while
in a synchronous transmission both the sender and receiver will be synchronized using for
example a common clock. Since the warehouse robot is communicating with a PC over a
RS232 connection the USART is set in UART (asynchronous) mode for serial transmission.
In a serial transmission bits are send one after another through a single wire, while they in
parallel transmission are sent concurrently over several wires. Using serial transmission can
be advantage especially over long distances since the risk of encountering problems with
synchronization in a synchronous transmission increases as the distance becomes bigger.
5.4.5
Timers
The timers are used to generate a PWM signal (pulse width modulation), which is used
to operate the 3 motors on the robot - The two drive motors and the tower motor. The
5.4. MSP430
33
timer has several modes in which it can be used.
• Up-mode (shown in fig: 5.5): The timer counts to the value stored in the capturecompare-register 0 (TACCR0/TBCCR0 depending on whether timer A or timer B
is used). When it reaches the value the timer is set back to 0, and the interrupt flag
for the timer is set.
Figure 5.5: The timer in upmode
• Continuous mode (shown in fig. 5.6): The timer starts at 0 and counts to 65535
(0FFFF in hexadecimal). When the maximum value is reached the timer is set to
0. The capture-compare-registers decide when an interrupt flag is set. Since there
are several capture-compare-registers it is possible to have multiple interrupts during
the time of which the timer is counting from 0 to 65535.
Figure 5.6: The timer in continuous mode
• Up/down mode (shown in fig. 5.7): This mode is similar to up-mode in the sense
that the timer counts to the same capture-compare-register. But unlike up-mode,
when the timer reaches the value the timer is not set to 0 instead it starts counting
downwards to 0. Like continuous mode several interrupts can be generated using the
different capture-compare-registers.
5.4.6
PWM signals
In this project PWM signals (see figure 5.8) are used to control motors. A PWM signal
is an alternating signal of high and low that is interpreted into ones and zeroes. Unlike
for example a sinus signal which gradually goes from 0 to 1 a PWM signal ideally changes
34
CHAPTER 5. SYSTEM OVERVIEW
Figure 5.7: The timer in up/down mode
momentarily making the signal either 1 or 0, not any of the values in between. Using the
timer it is possible to tailor the signal exactly for the purpose, modifying the duty cycle
(how long the signal is set to "1" compared to how long it is set to "0") and the frequency.
The duty cycle could be altered by changing the value of the capture-compare-register
which causes the interrupts in up/down mode. If it is set to a low value the interrupt
would occur quickly in the timers period of going from 0 to 65535 and take a long time
to reach again when counting down. That would result in a high duty cycle where the
opposite could be achieved setting the capture-compare-register to a high value. Likewise
the frequency can be adjusted by setting the capture-compare-register which controls how
far the timer counts before resetting/starts counting downwards.
Figure 5.8: Picture of a pwm signal
The motors that the signals are passed on to work like inductors. Inductors cannot
discharge instantly which is why the motors are not constantly put to a halt whenever the
PWM signal is low.
5.4.7
ADC
The ADC is hardware that is is able to convert analog signals to digital. On the MSP430
the ADC can be using either 10-bit or 12-bit, which both use successive approximation
(SAR) to convert the signal. SAR works using a "Sample and hold" process where it
samples an analog input and holds it while it is converting it to digital. The way the
input is converted is by guessing on what the value might be (usually the first guess is
the highest possible value the input can be) and then compares it with the actual input
using a comparator. If the input is lower than the guess, the next guess will be half of
the previous guess. Similar if the guess was too low, the next guess will take half of the
previous guess and add it to the next guess and so on until the ADC has found the input.
5.4. MSP430
35
The process is shown in figure 5.9 along with a circuit diagram of the SAR which uses the
MSP430. Note that the SAR in figure 5.10 is only a 4-bit SAR. In this project the ADC is
used to pull and sample the voltages given by the light sensor, then translated to numbers
that then are used by the program.
Figure 5.9: Block diagram of the SAR in the MSP430
Figure 5.10: Example of a SAR ADC conversion.
5.4.8
I/O ports
On the MSP430 there is 6 ports each which are 8 bit where port 1 and 2 supports
interrupts. The ports are binary which means that 5V is interpreted as 1 and 0V is
interpreted as 0.
Chapter
Hardware design
6.1
Hardware overview
This chapter details the hardware used in the system. Sensors, motors, LEDs, switches,
etc. are required to fulfill the requirement specification. Therefore they have to interface
with the MSP430. Based on the actor-context-diagram in the requirement specification
(see section 3.4.1) and the system architecture diagram (see section 5.3) the block diagram,
6.1 shows an overview of the hardware used in the system.
As described, the MSP430 is the main part of the system. It is the only programmable
component in the system, and all other components therefore depend on it either directly
or indirectly.
The power supply in the system consists of two 10.8V battery packs, but since other
voltages are required in the system, the power supply also include three voltage regulators.
Furthermore, the MSP430 has to steer three Lego motors with PWM signals. To do
this, three H-bridges (there is two in each L298 chip) are used. The Lego motors return
tachometer outputs. Outputs from two motors (right drive motor and tower motor) are
sent back to the MSP430 for it to determine distance driven (dead reckoning).
The two light sensors which are used to follow a line interface with the ADC implemented on the MSP430.
Finally, the system has to communicate with a PC. It does this through an RS232 cable,
which interfaces with the UART on the MSP430 through a MAX232 chip.
The bold words represent the headlines of the following sections describing each socalled hardware module. Each hardware module will be described with a requirements,
design and test subsection. These descriptions concern one of each module, e.g. one motor
and not all three. The requirements establish specifically what the robot has to do with
e.g. a motor. The design explains how that functionality can be and is implemented,
including which external components the module uses - for a motor that would be e.g. an
H-bridge. A block/circuit diagram shows technicalities and interfaces to other modules
37
6
38
CHAPTER 6. HARDWARE DESIGN
Figure 6.1: Block diagram: Hardware overview
through input/output specifications. Input is on the left, output on the right side of the
diagrams. The test section shows what the module is capable of, and more importantly
makes sure that the requirements are fulfilled.
6.2. POWER SUPPLY
6.2
39
Power supply
Requirements
The power supply must deliver 3.3V, 4.3V, 5V and 10.8V. Furthermore the system
should have a power switch and a power LED, that signals if the robot is turned on.
Design
The requirements can be fulfilled with the circuit shown on diagram 6.2. The actual
Figure 6.2: Circuit diagram: Power supply
power supply consists of two 10.8V rechargeable battery stacks connected in parallel. This
fulfills the 10.8V requirement. For the rest of the desired voltages, three different voltage
regulators are used. These are also connected in parallel and thereby split up the supplied
10.8V. To get 3.3V, the component LE33CZ (see data sheet [LE33]) is used. For 5V,
LM78L05 (see data sheet [LM78L]) is used and for 4.3V, the adjustable voltage regulator LM317T (see data sheet [LM317]) is used. The supporting circuits for LE33CZ and
LM78L05 is quite simple and based on the ”Applications hints” in the corresponding data
sheets.
The adjustable LM317T for 4.3V has a slightly more complex setup. Two resistances
R1 and R2 in the supporting circuit has to be calculated to achieve the right voltage.
The Iadj comes from the current that runs over the R2 resistance, the value can be found
in the data sheet [LM317]. Furthermore, the Iadj is very small, so it can be set to zero,
when calculating the resistances. The 1.25V is the internal reference voltage, which get
40
CHAPTER 6. HARDWARE DESIGN
multiplied by the voltage over the R1 (chosen to 240Ω) resistor.
As figure 6.3 indicates, the resistance needs to be 585.6Ω. However, a 590Ω resistor is
Vout = 1.25V · (1 + R2
R1 ) + Iadj(R2)
·
240Ω
R2 = 4.3−1.25V
1.25V
R2 = 585.6Ω
Figure 6.3: Resistor calculations for the LM317T
used. Testing if desired voltage is achieved according to these resistors in done in figure
6.4. As described, when these three components and their individual supporting circuits
R1 = 240Ω, R2 = 590Ω, Iadj = 100µA
Vout = 1.25V · (1 + R2
R1 ) + Iadj(R2)
590Ω
Vout = 1.25V · (1 + 240Ω
) + 100µA · 590Ω
Vout = 4.32V
Figure 6.4: Voltage calculations for the LM317T
are connected in parallel to the 10.8V battery packs, access to approximately 3.3V, 4.3V,
5.0V and 10.8V is provided.
Test: Voltage regulators
Testing of the voltage regulators is done by connecting the external power supply of
10.8V to the regulators and measuring the voltage after each regulator with a voltage
meter.
Results
Measuring the voltage from different voltage regulators resulted in the expected voltage.
Test: System power usage
In order to determine system power usage, current measurements are made before and
after each component. As the voltage regulators are linear, the amp values can be used to
estimate how long the robot has power despite the different voltage.
Results
Figure 6.1 shows the power usage of each component as well as the subtotal. This
subtotal is then used to calculate the estimated system runtime before it runs out of power
(as shown in figure 6.2) if we assume the robot is fully charged (3200mA).
6.2. POWER SUPPLY
Component
MSP430
Warning LED
Power supply LED
2x H-bridge
2x Light sensors
3x motor
3x tachometers
System board
MAX232+RS232
Total
41
Idle
6mA
0mA
10mA
45mA
40mA
0 mA
30mA
8mA
1mA
140mA
Load
12mA
10mA
10mA
45mA
40mA
750mA
30mA
8mA
1mA
907mA
Voltage
3.3V
4.3V
4.3 V
5V
4.3V
10.8V
4.3V
10.8V
3.3V
-
Idle power
0.019W
0W
0.043W
0.225W
0.172W
0W
0.129W
0.086W
0.003W
0.677W
Table 6.1: System power usage
Idle
Load
3200mAh
140mA = 22, 85h
3200mAh
907mA = 3, 5h
Table 6.2: Estimated system running time
Load power
0.039W
0.043W
0.043W
0.225W
0.172W
8.1W
0.129W
0.086W
0.003W
8.84W
42
6.3
CHAPTER 6. HARDWARE DESIGN
Motor driver
Requirements
The motor drive must be responsible for controlling the direction and speed of the
motors as well as reading the output of the built-in tachometer and returning it to the
system. The motor used must be a DC motor that can handle PWM signal.
Specifications
Specifications for the motor operations are from the LEGO Hardware Developer Kit [1]
and from tests made by Philippe Hurbain [2] This information along with our own testing
of the motor by sending different voltages to it resulted in the final specifications displayed
in table 6.3.
Pin
Pin 1
Pin 2
Pin 3
Pin 4
Pin 5
Pin 6
Color
White
Brown
Green
Yellow
Grey
Pink
Value
0V/10.8V
0V/10.8V
GND
4.3V
0.0-3.2V
N/A
Purpose
PWM signal from the MSP430
PWM signal from the MSP430
Ground for pin 5
Used to power the motor
Tachometer output
Unused
Table 6.3: LEGO motor pin specifications
Figure 6.5: The pwm signal and the current in an inductor.
Design
The requirements can be fulfilled with the circuit shown in figure 6.6.
A L298N component [L298N] is used. This component contains two identical H-bridges,
only one is shown on this diagram.
The H-Bridge provides the functionality of controlling direction of the current sent to the
motor. It achieves this by enabling two of the four transistors diagonally at any given
6.3. MOTOR DRIVER
43
Figure 6.6: Circuit diagram: Motor driver
time.
When a 3.3V PWM signal is sent to the H-Bridge the AND-gates within, the bridge ensures
that the two transistors are diagonally opened. Then the 3.3V PWM signal is amplified
to 10.8V, that is then passed to the motor. The direction in which the current is running
through the H-Bridge determines the direction of the motor, therefore fulfilling the first
requirement of the motor driver.
The Lego motors have a built-in tachometer that returns the speed of the motor to a
specific pin on the MSP430.
Test: Direction
To test clockwise rotation on the motor the H-Bridge receives a high signal on the
PWM1 pin while getting a low signal on the PWM2 pin. In order to achieve counterclockwise rotation the signal is reversed, sending high to PWM1 and low to PWM2.
Results
The duty cycle on the PWM signal sent to the test motor is 0.5. When this signal is
sent to PWM1, the motor drives in the opposite direction of when the signal is sent to
PWM.
Test: Speed
In order to match duty cycles of the PWM signal to the actual speed of the driving
motors the robot is made to drive a length of exactly 1 meter with different duty cycles.
The speed of the tower motor is measured by measuring the time it takes to move from
full bottom position to full upward position while sending different PWM signals.
Results
The measurements are shown in table 6.4 and depicted in figure 6.7.
To briefly analyse these results, once the motors get enough power to accelerate the
robot from 0m/s, it will rise until the maximum velocity is reached. The PWM signals
44
CHAPTER 6. HARDWARE DESIGN
Duty cycle (%)
Speed (m/s)
0.0
0
0.1
0
0.2
0.10
0.3
0.21
0.4
0.27
0.5
0.31
0.6
0.33
0.7
0.35
0.8
0.36
0.9
0.37
1.0
0.37
Table 6.4: Duty cycles and actual motor speed
Figure 6.7: Circuit diagram: Motor driver
works by letting in a signal, which tells the motor to drive in a period of time, afterwards
it will pause for a bit and then send another signals. That will result in a constant velocity,
if the period which the signals is off is decreasing, there will be lesser time for the velocity
to decrease, which will lead to a velocity closer to each other for the higher duty cycles.
More about PWM signals can be found in 5.4.6.
Test: Tachometers
The tachometer in the motor are according to specifications [2], slits which pass a sensor when the motor rotates. There is 180 of these around the edge inside the wheel, which
means that the sensor will return 180 high signals when the wheel is turned 360 degrees.
These high signals are measured to be 4.3V. This signal is to high for the I/O port to take,
so to correct this voltage division is used with two resistors for each signal, 1k Ω and 3k Ω
as shown on figure 6.8, with this, the voltage is lowered to 3.2V using the calculation.
3k
3k+1k
· 4.3V = 3.2V
For this test the tachometer is connected to an I/O port on the MSP430. In the software, the port is set up to interrupt when a high is received. Inside the interrupt service
routine a counter is increased by one.
When this is set up and the software is running on the MSP430, the wheel is turned as
close to 360 degrees as humanly possible. Using the ”watch” options in the IAR Embedded Workbench IDE on the counter variable, the number of high signals returned to the
MSP430 in one turn can be observed. This procedure is repeated three times.
6.3. MOTOR DRIVER
45
Figure 6.8: Diagram with the voltage division for the tachometer
The results are as expected 180 high signals for 180 degrees.
Results
Three tests were performed on the tachometers and the results were ’178’, ’179’ and
’178’ while expecting the result of ’180’. Considering sources of error such as human inability to turn the wheel exactly 360 degrees, it is fair to assume that the tachometers
return 180 high signals per rotation as specified.
46
6.4
CHAPTER 6. HARDWARE DESIGN
Light sensor
Requirements
The system needs to be able to detect three different surfaces by use of the light sensors
in order to identify different types of lines on the warehouse floor.
Specifications
While the LEGO developers kit documentation [1] provided us with the core definition
of each pin of the LEGO connector cable it did not give enough information to use the
LEGO light sensors with our system. In order to replicate the functionality of the NXT
system, we connected the NXT to the light sensor and measured the voltages being sent
from the NXT to the sensor. This provided us with the specifications shown in table 6.5
with the exception of an added resistor for pin 1, that was found by going through the
circuit diagrams included in the LEGO hardware development documentation [1].
Pin
Pin 1
Pin 2
Pin 3
Pin 4
Pin 5
Pin 6
Color
White
Brown
Green
Yellow
Grey
Pink
Value
3.3V
GND
GND
5.0V
3.3V
N/A
Purpose
3.3V input, output varies depending on surface reflection
Ground for pin 4
Ground for pin 5
Used to power the sensor
Used turn on the IR led
Unused
Table 6.5: LEGO light sensor pin specifications
Design
Figure 6.9: Circuit with the most essential of the light sensor
The diagram (6.9) shows the basic of the light sensor and its interface to the rest of
the system. Where only the crucial parts of the internals are treated in this report.
The sensor is built with an infrared transmitter and receiver. The voltage returned by
the sensor depends on the brightness of the light reflected to the receiver. In theory the
6.4. LIGHT SENSOR
47
transmitter/receiver components work as an adjustable resistance, which makes the output
voltage from the light sensor as a whole vary.
Specifically, it does this with an open collector shown on figure 6.10 - another main part of
the system. To make the light sensor work, the open collector has 3.3V. As the receiver and
Figure 6.10: Open collector
thereby the Circuit input current varies, the amount of current running from the pull-up
to GND varies as well. This is due to the transistor, which eventually changes the voltage
division over the two resistances. Since the output voltage is pulled out between the two
resistances, it will make the open collector output to the ADC vary.
Test
To test the light sensor, it is connected to a power supply, giving the specified (see
table 6.5) voltages for it to have the infrared LED turned on.
When the light sensor has been supplied with the necessary voltages, it is held 3 millimeters
from the three different coloured surfaces the robot has to tell apart, and the returned
voltages are written down. Each surface may return more than one voltages. In this case,
intervals are written down.
After this, the ADC on the MSP430 is set up as described later to return digital values
for the voltages. The light sensors are tested in the same way as before, but this time the
integer values are noted.
Finally, the mathematical relationship between voltages and integer values are specified in
the MSP430 data sheet [MSP430 Datasheet].
The ADC converts voltages as described here (and shown in figure 6.11): The ADC is
using a reference voltage to find the digital value. The reference voltage is the 3.3V which
is the one powering the MSP430.
The relationship is linear with a slope on 1240 and the results from the tests are held up
against this.
48
CHAPTER 6. HARDWARE DESIGN
NADC
NADC
NADC
NADC
V
−V
IN
R−
= 4095 · VR+
−VR−
= 4095
VR+ · VIN
4095
· VIN
= 3.3V
= 1240 · VIN
Figure 6.11: Reference voltage used by the ADC
Results
The results (shown in table 6.6) show that it will be possible for the robot to separate
the three different surfaces, and thereby fulfill the requirements.
Table 6.6: Light sensor test results
Surface
White tape
Group room floor
Black tape
Voltage
0.25V - .50V
0.8V - 0.95V
1.3V - 1.5V
Digital
355 1015 1633 -
Value
465
1192
1766
To test the slope, the results are plotted on a (V,N)-graph where the limits of the
intervals correspond to each other. The graph and the regression line are showed in figure
6.12. The linear regression gives a slop on 1214 which fits nicely to the 1240 specified in
Figure 6.12: Voltage and ADC output graph
the data sheet. To conclude, the ADC gives acceptable and the expected values.
6.5. COMMUNICATION
6.5
49
Communication
Requirements
A computer is required to connect to the system with a terminal emulation software
(such as Hyper Terminal) though a RS232 connection.
Design
The requirements can be fulfilled with the circuit shown on diagram 6.13.
Both sides of diagram 6.13 contain input and output pins, because it is a communication
Figure 6.13: Circuit diagram: Serial communication
module. The left side is connected to the MSP430 and the right side is connected to the
computer through a RS232 connector. What makes the two-way communication possible
is the MAX232 chip.
The computer and the MSP430 have different perceptions of what voltages correspond to
ones and zeroes. These perceptions can be seen in table 6.7. When the RS232 and MSP430
Table 6.7: Voltage levels and binary values
RS232
RS232
RS232
MSP430
MSP430
MSP430
Voltage level
-15V - -3V
-3V - 3V
3V - 15V
VSS - VSS + 0.6V = 0V - 0.6V
0.6V - 2.64V
0.8 · VCC - VCC = 2.64V - 3.3V
Binary value
0
undefined
1
0
undefined
1
are connected to the transfer/receive pins on the MAX232 chip. The chip is responsible
for lowering the voltages coming from the computer as they are too high for the MSP430
50
CHAPTER 6. HARDWARE DESIGN
to handle. It also amplifies the signal coming from the MSP430 towards the computer.
Furthermore, it is worth mentioning that RS232 sends one byte at a time, least significant
bit first. Specifically, it sends a start bit, then 7 bits of data, a parity bit (even or odd
number of bits sent) and finally a stop bit when sending a byte.
Further software design using the communication module is covered in section 7.1 and later
implemented in section 8.3.
6.5.1
Test
Testing the communication module. In this test we expect the system to receive input
from the terminal emulation software, then repeat the input for us.
User Guide
1. Connect the system with a serial cable to a computer equipped with a serial port.
2. Open a terminal emulation software on the computer (Hyperterminal for example).
3. Set the terminal emulation software to 19200 baud, 8 databits, no flow control and
1 separate bit.
4. Establish the connection
5. Write ’test’ and observe if the system displays the text you write.
Results
The system was able to successfully read the input and send it back to the terminal
without any problems and by that fulfills the functional requirement 1.2 (see section 3.4).
6.6. HARDWARE LAYOUT
6.6
51
Hardware layout
In this section, the hardware modules are implemented into two hardware boards, one
with the power supply and the battery stack, the other board with the MSP430, H-bridges
and with the connections to the motors, sensors and the PC.
Figure 6.14 shows how the components are placed on the main board. The MSP430
on the top with wires from the different pins to the components. The motor module’s
three H-bridges is placed in the center of the board, with all the connection ports for the
MSP430 around it. The connection ports for the motors is placed below the H-bridges,
where the 6-pin wires from the motor is connected.
Figure 6.14: Hardware overview (part one)
The figure 6.15 shows the red Warning LED, the Mode switch to force switch which
mode the robot is in. The light sensor setup to connect the light sensors and the two
resistors for the open collector. The communication module is placed at the lower left part
of the board, with the MAX232 chip and the RS232 port.
52
CHAPTER 6. HARDWARE DESIGN
Figure 6.15: Hardware overview (part two)
6.7. MSP430 PINS
6.7
53
MSP430 pins
The MSP430 [MSP430 Datasheet] has 64 pins available as shown in figure 6.16, each
for different purposes. Pin usage is further covered in table 6.8.
Testing
Testing of individuals pins is executed by setting the pins to high or low and measure
the voltages with a voltage meter. During the course of the project the occasional pin has
failed and a new MSP430 chip was tried instead.
Figure 6.16: Overview of the pins on the MSP. The marked pins are used in the system.
54
CHAPTER 6. HARDWARE DESIGN
Pin
Pin 64
Pin 62
Pin 13
Pin 14
Pin 20
Pin 32
Pin 33
Pin 37
Pin 38
Pin 39
Pin 40
Pin 41
Pin 42
Pin 59
Pin 60
Pin name
AVCC
AVSS
P1.1/TA0
P1.2/TA1
P2.0/ACLK
P3.4/UTXD0
P3.5/URXD0
P4.1/TB1
P4.2/TB2
P4.3/TB3
P4.4/TB4
P4.5/TB5
P4.6/TB6
P6.0/A0
P6.1/A1
Description
3.3V from power supply
GND
Tachometer input from right drive motor
Tachometer input from tower motor
Switch for toggling between modes
UART transfer
UART receive
Left motor forward (0x02)
Left motor reverse (0x04)
Right motor forward (0x08)
Right motor reverse (0x10)
Tower motor up (0x20)
Tower motor down (0x30)
ADC input from left light sensor
ADC input from right light sensor
Table 6.8: MSP430 pin usage
6.8. CHASSIS CONSTRUCTION
6.8
55
Chassis construction
The robots chassis is constructed of Lego from the NXT mindstorm set. The overall
design idea is to make it look like a forklift truck. The main purpose of the chassis is to
be solid and flexible, so it is easy to integrate the hardware modules. In this section the
wheel construction, tower construction, light sensors, motors and the hardwareboard is
described.
Wheel construction
The robot is constructed with four wheels; two steering wheels and two "swing wheels",
as seen on figure 6.17. The two steering wheels are placed in the front and controlled by
two motors. The large distance between the two steering wheels should help stabilizing
the forklift, when lifting a package. The two - as opposed to one - "swing wheels" are also
used for stabilizing when carrying a package.
Figure 6.17: The robot from the side.
Tower construction
The tower is constructed as the tower on a forklift truck, see section 2.3. The tower
is controlled by one motor, which is placed in the center of the chassis. The tower can be
seen on figure 6.18
56
CHAPTER 6. HARDWARE DESIGN
Figure 6.18: The tower on the robot
6.8. CHASSIS CONSTRUCTION
57
Light sensors
The robot has two light sensors, seen on figure 6.19, in the front, pointing downwards.
Since the robot uses ’differential drive’, it will not be effective to place the light sensors
in the center of the robot, since the robot needs to turn many degrees to find the line.
Therefore the light sensors are placed in front of the wheels, and are placed with a certain
space, so they fit with the duct tape. The sensors are placed three millimeters from the
surface.
Figure 6.19: The robot seen from below, where the light sensors and the motors are showed.
Motors
The three motors are the main weight of the robot, and that is why the position of
them is important. The motors are placed in the center of the chassis and as close to the
surface as possible, this will make the robot more stable and will make it easier for the
robot to balance. The two motors, which controls the wheels are showed on figure 6.19.
Hardware board
The hardware board is where the power supply, MSP and the other hardware elements
are placed. It is important that it is easy to change something or work on it. Therefore the
board is placed on the bed of the robot, this will also give the robot some counterweight,
58
CHAPTER 6. HARDWARE DESIGN
when the tower is in work. The board’s position is showed on figure 6.17. The figure also
shows the battery pack, which is placed on both sides of the robot.
Chapter
Software design
In the following sections, design of each process (specified in System overview chapter 5)
is described. Design descriptions of the processes include purpose, modularization and
an activity diagram showing the order and interface between the modules. Furthermore,
design of each underlying module is specified with purpose, input/output, hardware use
and, depending on the complexity, an activity diagram showing logic and functions used.
If a module is reused within or between processes and thereby previously described, a
reference with a short description of modifications, if any, is considered sufficient.
7.1
7.1.1
User interface
Purpose
This process is derived from Use Case 1 (see section 3.5), and makes up the configuration mode of the system. It is responsible for configuring the robot, inserting packaging
coordinates and interacting with the user.
Figure 7.1 illustrates the user interface process and the modules within the process.
warehouse mode
mode switch
configuration mode
add package
command_input
cmd_pkg
process command
list queue
cmd_list
Figure 7.1: Activity diagram: User interface process
The interface is done through a terminal emulation software and the user’s computer is
connected through a RS232 interface.
59
7
60
7.1.2
CHAPTER 7. SOFTWARE DESIGN
Variables
RXbuffer: FIFO (first in, first out) buffer containing received characters from the USART
interrupt handler. The buffer has a write index and a read index. When a new
character is inserted the write index is read, then used to insert the new character.
Then the index is incremented.
LNBuffer: FIFO buffer containing a single line, terminated with a null character. This
buffer is then parsed for commands and arguments. Follows the same principals as
the RXBuffer in terms of reading and writing.
pkgQueue: The package queue is a FIFO buffer that holds all package coordinates that
system needs to pick process. The information is stored in a 2 dimensional integer
array. The first array holds the package index and the second array holds rack (0) and
shelf (1) coordinates. As an example would ’pkgQueue[2][0] = 2’ and ’pkgQueue[2][1]
= 3’ signify the 3rd package order with the rack number 2 and shelf number 3. When
a new entry is created the index is incremented until the queue is full. When the
queue is processed, the processed entry is removed.
7.1.3
Module design
Input
Purpose: Manages user input from a serial connection, processes it for newlines and
spaces; then calls the relevant command modules.
Input: Character input from a serial connection, triggered by an RX interrupt.
Output: Calls the relevant command functions.
Hardware: Uses the USART RX interrupt within the MSP430 to receive characters sent
through the RS232 connection.
Command: Add to queue
Purpose: Will add the coordinates specified into the package queue.
Input: Two integers, x (rack number) and y (shelf number).
Output: Acknowledges the command, inserts the coordinates into a global array containing the package queue.
Hardware: None.
Command: List queue
Purpose: Display the current package queue from the PkgQueue variable.
Input: Reads the PkgQueue
Output: Prints the PkgQueue entries to the serial interface.
Hardware: None.
7.2. NAVIGATION
7.2
7.2.1
61
Navigation
Purpose
By following lines, the purpose of this process is to navigate from the base, to the
package location and back again. Figure 7.2 illustrates the user interface process and the
modules within the process.
follow line
no
rack reached?
yes
turn_90
follow line
no
shelf reached?
yes
Figure 7.2: Activity diagram: Navigation process
7.2.2
Module design
Follow line
Purpose:
The purpose of this module is to follow the line on the floor, using the light
sensors to continuously correct the direction of the robot to keep it on the line. The module
will proceed until the light sensors registers a different colored line.
Input: Values given by the light sensors is used to determine if the robot is still on the
line.
Output: Two PWM signals to each of the driving-motors.
Hardware: Two light sensors.
Description / Class diagram:
For the robot to be able to follow the line the two
light sensors will be positioned in such a way, that the line will be in between them with
neither of them being on top of it. Then the robot can continuously correct its direction
by measuring if any of the light sensors are on the line. If only one is, the robot will turn
in the direction of that sensor.
Turn 90
Purpose: The purpose of this module is to turn the robot 90 degrees.
Input: Two light sensors.
Output: Two PWM signals to each of the driving-motors.
Hardware: Two light sensors.
Description / Class diagram:
Initially one of the motors will be turned on in order
to turn the robot in the desired direction using dead reckoning. Then, since the robot will
most likely not always be positioned precisely on the line, it will drive a small distance
forward to make sure the two light sensors are not on the line. When the light sensors are
clear of the line, the robot will be put in reverse until either of the sensors is back on the
line. Then the motors will be used to put the other sensor on the line as well. Doing that
will ensure that the robot has turned 90 degrees away from the line.
62
CHAPTER 7. SOFTWARE DESIGN
7.3
Tower
7.3.1
Purpose
Using dead reckoning, this process is responsible for driving from the line to the destination/package, lift up the package and drive back to the line with it. The diagram 7.3
turn 90
forward
lift_pkg
reverse
turn 90
Figure 7.3: Activity diagram: Tower process
shows the modules and the order of them within the process.
7.3.2
Module design
Turn 90
See section 7.2.2.
Drive
Purpose: To drive the robot a predefined distance forward or backwards.
Input: None.
Output: PWM signals to operate the two drive motors.
Hardware: The module operates two motors.
Description: This module can make the robot drive 10 centimeters either forward or
backwards using dead reckoning. This is used whenever a package is about to be picked
up. When the robot has to leave the line to get close to the package, it will have to drive
forward after turning 90 degrees. After the package has been picked up, the robot will
have to get back to the line and will therefore be put into reverse.
Lift package
Purpose: This module purpose is to control the tower.
Input: None.
Output: PWM signal to the motor, to lift the packet.
Hardware: This module handles the tower, which is controlled by one motor.
Description: The tower will move up or down depending on if the robot is delivering or
gathering packages.
7.4. MODULE SPECIFICATION
7.4
63
Module specification
In correspondence with the sequence diagram in the description of the User Interface
process, sequence diagrams for the modules in the Navigation and Tower process are drawn.
This will lower their abstraction levels sufficiently to actually implement them.
7.4.1
Sequence diagrams
The context in which the following modules are used can be seen in the Logical view,
see section 7. Furthermore, there is a few more underlying functions in each module. These
are however considered too specific or small to be included here. Read the Implementation
(see chapter 8) for further specification.
Follow line
Figure 7.4: Follow line sequence diagram
The main functionality of the follow line module is found in the followLine function(see
figure 7.4). This function sends instructions to the motors (see section 7.4.2) based on input
from light sensors. In this module it starts by initializing the two drive motors and then set
them to drive straight forward until it hits another surface. After this, it will enter a loop
state where it continuously reads input from the light sensors, evaluates it and instruct the
pwmMotor function to control the motors in such a way that the robot follows the line.
Turn90
This module introduces another function(see figure 7.5, tacho, short for the tachometers. When the tacho function is called, the tachometer on the drive motor counter is set
to zero. After this, based on interrupts occurring when a slit in the wheel is passed, the
counter counts the number of interrupts. Because this number of interrupts/splits correspond to the length that has been driven since the tachometer was set to zero, turn90 can
64
CHAPTER 7. SOFTWARE DESIGN
Figure 7.5: Turn90 sequence diagram
use it to instruct pwmMotor. turn90 correspond to the previously described followLine and
continuously reads input from the right drive motor tachometer, evaluates it and instruct
pwmMotor to keep the right motor driving until it hits whatever number corresponding
to 90 degrees.
As briefly described in the module design, see section 7.2.2, Turn90 also has to correct the
robot’s position on the line. Using the tachometer, the robot will always turn 90 degrees
from its starting point. But when it comes from the follow line module, the robot might
not be exactly where it is supposed to be. If the starting point is not perfectly aligned with
the line, the turn will not be perfect either and it will not necessarily be possible to drive
from the line to the package correctly. That is why adjusting is required after turning 90
degrees. Even if the turn may not have been exactly 90 degrees, it should have been fairly
close which means the adjustment can be handled by the follow line module as the lines
on the warehouse floor should be wide enough for either of the light sensors to detect it
after a turn.
7.4. MODULE SPECIFICATION
65
Figure 7.6 shows how the adjusting is done. Dots 1 and 2 are light sensors. The black
Figure 7.6: Shows the placement of the light sensors when turning 90 degree, and adjusting back to
the line.
box is the package to be picked up, the thin line the one that indicates that the robot is
at a package and the thick line is the one it just followed. Assuming that the robot will
always be in front of the line after turning 90 degrees, it reuses the principle of following
a line to adjust itself. By backing up wheel by wheel until each hits the line behind it, it
will be perfectly adjusted.
7.4.2
Drive
Figure 7.7: Forward/reverse sequence diagram
By initializing taco and pwmMotor to operate on the two drive motors(see figure 7.7),
”drive” continuously reads the distance driven and instructs the drive motors to keep
driving for a specified distance. For package retrieval that distance is for instance 10 cm.
7.4.3
Tower
Functions as (figure 7.8)the drive module except here the robot initializes taco and
pwmMotor to the tower motor rather than the drive motors.
66
CHAPTER 7. SOFTWARE DESIGN
Figure 7.8: Lift/lower sequence diagram
Chapter
Implementation
In this chapter, the software implementation of the previously described modules are described into detail. Furthermore, descriptions of crucial or seemingly more complex parts
of the code are supported with examples. The modules are tested too.
Even though the implementation is presented as top-down, the actual implementation
happened bottom-up due to an iterative process of development.
8.1
Main
The functionality of the robot starts in the main function (see listing 8.1). The main
function holds the structure of the program, and is entirely based on the structure planned
in the System architecture (section 5.3).
Listing 8.1: Main function
1
#define MODE_PORT PORT
2
3
int pkgQueue[][]; /* Array of packages to be collected */
4
5
void init() {
/* Initialization functions */
6
7
}
8
9
10
int mode()
{
if(MODE_PORT) { /* Mode switch toggled? */
11
return 1;
12
} else {
13
return 0;
14
}
15
16
}
17
18
void ui()
19
{
/* UART communication writing pkgList */
20
21
}
22
23
void nav()
67
8
68
24
CHAPTER 8. IMPLEMENTATION
{
/* Navigation functions reading pkgList */
25
26
}
27
28
int main()
29
{
init();
30
31
while(1) {
32
switch(mode()) {
33
34
case 0: /* Configuration mode */
35
36
37
ui();
38
break;
39
case 1: /* Warehouse mode */
40
41
42
nav();
43
break;
44
}
45
}
46
47
return 0;
48
49
}
First, the hardware modules are initialized, that is the basic clock module, the serial
communication, I/O ports, the ADC and the PWM signal. After this, the robot enters the
infinite while loop which constantly checks if it should be in configuration or warehouse
mode. This is done in mode() that listens on the port the switch is connected to. The
loop ensures that the robot has to finish the procedures specified within the modes before
it can actually change mode.
In the next sections, the implementation of the procedures within the modes are described.
Test
The main structure of the system relies on the mode() function. This function is tested
with the mode switch and the built-in debugging LED.
The mode() function returns either 0 or 1 depending on how the switch is toggled. This
toggling causes the switch to enter either ui() or nav().
Therefore to test mode(), the debugging LED is turned on when in warehouse mode, and
off if in configuration mode.
Results
As expected, the mode is turned on and off when the mode switch is toggled.
8.2. INITIALIZATION
8.2
8.2.1
69
Initialization
Basic Clock Initialization
Listing 8.2: Basic Clock is set to use the XT2 oscillator, fault flag also cleared
1
void basic_clock_init(void)
2
{
3
int i;
4
WDTCTL = WDTPW + WDTHOLD;
// Stop watchdog timer
5
BCSCTL2 |=0x08;
// SMCLK = XT2
6
do{
7
IFG1 &= 0x0FD;
8
for (i = 0xFFFF; i > 0; i--); // Time for flag to set
}while ((IFG1 & OFIFG) != 0); // OSCFault flag still set?
9
BCSCTL2 |= 0x80;
10
11
// Clear OSCFault flag
// MCLK = XT2
}
This initialization code (in listing 8.2) is used to select which clock generators (see
5.4.1) should be used in the system. In theory it should be possible to set the master clock
and submainclock directly in the BCSCTL2 register without the Oscillator Fault Flag,
OSCFault flag, being set, but in practice this flag is sometimes incorrectly being set. The
way to work around this, is the dowhile loop that continues to clear the OSCFault flag
until it is not being set anymore. When that happens, the oscillator is ready for use, and
the masterclock can be set.
8.2.2
Tachometers
Listing 8.3: Tachometer init code
1
void tacoInit( void )
2
{
P1DIR = 0x00;
3
P1IE = 0x06;
4
5
}
The tachometer on the drive motor is connected to port 1.1. The tachometer on the tower
motor is connected to port 1.2. The motor returns a high/low signal to the MSP430, which
is why the direction on the port is selected to be input. P1IE enables interrupts on port
1.1 and 1.2 with the hex value 0x06, selecting bit 2 and 3 (LSB). Thus the MSP430 will
run the PORT1 ISR each time a high signal from the tachometers are received.
8.2.3
Mode switch
Listing 8.4: Mode switch init code
1
void modeInit( void )
2
{
P2IE = 0x01;
3
4
}
70
CHAPTER 8. IMPLEMENTATION
The mode switch is connected to port 2.0 which is why interrupts are enabled on this with
the corresponding hex value 0x01.
8.2.4
Serial communication
Using the initialization code, the MSP430 prepares the UART interface (see 5.4.4) for
serial communication with the user’s computer, used in the configuration mode.
Listing 8.5: Set ’bit-rate’ calculations, used to set the USART
1
unsigned int br;
2
unsigned char br1,br0;
3
br = (unsigned int)(XT2/19200);
4
br0=(unsigned char)(br & 0x00FF);
5
br1=(unsigned char)(br >> 8);
In listing 8.5 bit rate variables are pre-set and later used to define the baudrate.
Listing 8.6: Reset and set the USART interface on the MSP430
1
U0CTL &=~ SWRST;
2
U0CTL
// software reset UCTL0.0:=0
3
U0TCTL = 0x30;
// use SMCLK
4
U0BR0
= br0;
// SMCLK/baud=XT2/19200
5
U0BR1
= br1;
6
U0MCTL = 0x00;
= 0x50;
// 8 data bit, 1 stop bit no parity check
//
-"-
// no modulation
In listing 8.6 the communication protocol is set to asynchronous serial connection at
the rate of 19200 baud with 8 data bits, 1 stop bit, no flow control and no parity check.
Listing 8.7: Reset the buffer indexes
1
ucRXWriteIndex = ucRXReadIndex = ucRXCharCount = 0;
2
ucLNWriteIndex = ucLNReadIndex = ucLNCharCount = 0;
In listing 8.7 the buffer indexes used by the configuration mode are reset.
Listing 8.8: Enable the USART interface and receive interrupts on the MSP430
1
ME1
2
P3SEL |= BIT4+BIT5;
|= UTXE0+URXE0;
3
P3DIR |= BIT4;
// Pin P3.4 is output
4
IE1
// enable receive interrupts
|= URXIE0;
// enable USART transmit/receive
// Pin P3.4/P3.5 USART TXD/RXD
In listing 8.8 we specify which pins to use and enable the interrupt for receiving data.
As soon as we enable the receive interrupt and the interrupts are enabled we can expect
the program to be interrupted at any time.
8.2.5
ADC
Listing 8.9: Initialization of the ADC12 control registers
1
P6SEL = 0x0F;
8.2. INITIALIZATION
2
ADC12CTL0 = ADC12ON+MSC+SHT0_0;
3
ADC12CTL1 = ADC12SSEL_2+SHP+CONSEQ_3;
4
ADC12IE = 0xFFFF;
71
The code displayed in 8.9 shows the initial initialization of the ADC12 (see 5.4.7) on
the MSP430.
In the first register the ADC12 is turned on by setting the ADC12ON bit. The MSC
bit makes the ADC continuously convert input once the ADC has been started. The last
bit which is being set, SHT0x, selects the sample-and-hold time. The sample-and-hold
time decides how many clock cycles the input which has been sampled should be hold for
conversion, in this case 4 clock cycles.
ADC12SSEL is used to select which clock should be used by the ADC. In this case it is
set to use the Master clock, MCLK. SHP is set to make the ADC do a conversion every time
it receives a clock signal from the sampling timer which was set using ADC12SSEL. Since
input from two different pins are needed, the ADC is set to convert at sequence of channels. That is, the ADC will convert each of the pins after each other. The sequence may
or may not be in order, which means there is no way to know which input is converted first.
Having values from the light sensors as fast as possible is important for the follow line
module to function properly, which is why the ADC12IE register is set in order to enable
interrupts. The interrupt service routine is described in details in 8.20.
Listing 8.10: Initialization of the ADC12 memory control registers
1
ADC12MCTL0 = INCH_O;
2
ADC12MCTL1 = INCH_1+EOS;
3
ADC12CTL0 |= ENC+ADC12SC;
In listing 8.10 the memory control registers are configured. They are used to select
which pins should be used for inputs by setting the INCH_x bits. In this case pin A0 and
A1 is selected. The EOS, end of sequence, bit tells the ADC that no more conversions are
to be done after this.
Finally the conversion is enabled and started by the last line which sets the ENC and
ADC12SC bits.
8.2.6
Timers and PWM
Timers (see 5.4.5) are used by the system to regulate the PWM signals. In this section
we initialize the timers used in the system. The corresponding function is pwmInit.
72
CHAPTER 8. IMPLEMENTATION
Listing 8.11: Initialization of Timer_B control register
1
TBCTL=0x02D2;
2
// TBIFCFG: 0 - No interrupt pending
3
// TBIE: 1 - Interrupt enabled
4
// TBCLR: 0 - Clear
5
// MCx: 01 - Time mode: Up
6
// IDx: 11 - Input divider: /8
7
// TBSSELX: 10 - Clock source: SMCLK
8
// CNTLX: 00 - Counter length: 16bit
9
// TBCLGRP: 00 TBCL group: Each latch independent
The Timer_B control register is used to configure how the timer is used. In this section
(see listing 8.11) the interrupts are enabled in order to generate at PWM signal, the clock
source set to the XT2, input divider is set to 8, the counter length is set to 16 bit and the
timer mode is set to up-mode( see 5.4.5 ), and the TBCL bits are configured for each latch
to independent mode. For each of the capture-compare-registers there is a latch connected
to the input in order to ensure a valid input for the comparator which compares the value
from the latch with the value from the timer. Source: MSP430 User Guide [MSP430 User
Guide].
Listing 8.12: Initialization of Timer_B register
1
TBCCTL1=0x00D0;
2
TBCCTL2=0x00D0;
3
TBCCTL3=0x00D0;
4
TBCCTL4=0x00D0;
5
TBCCTL5=0x00D0;
6
TBCCTL6=0x00D0;
7
8
P4SEL|=0xFF;
9
P4DIR|=0xFF;
In listing 8.13, the output mode is set using the OUTMODx bits. In this case it is set to
"toggle/set" which is needed to generate a PWM signal. Since the most precise duty cycle
is desired in order to have a constant speed on the motors, interrupts are enabled for the
timer. The P4-registers are used to select which pins the PWM output should be.
Concerning the duty cycle calculations, the basis for these are also done in the initialization. The pwmFrequency is defined to be 100.0 Hz as a global variable. The period of
one cycle (TBCCR0=pwmPeriod) is calculated with this formula.
Listing 8.13: Initialization of Timer_B register
1
void pwmInit( void )
2
{
3
pwmPeriod=(1/pwmFrequency)*(XT2/8.0);
4
TBCCR0=pwmPeriod;
5
/* .... */
8.2. INITIALIZATION
73
6
1
pwmP eriod = 100
· 7.3728·10
= 9216clocksperinterrupt
8
7.3728·106
= 800interruptspersecond
9216
800 · 11 = 8800clocksusedf orinterruptspersecond
8800
· 100 = 0.12%CP U load
7.3728·106
Figure 8.1: Calculation of CPU load from the TimerB interrupts
6
TBCCR1=transDuty(0.0);
7
/* .... */
8
}
9
int transDuty(float oDuty)
10
{
11
int pwmDuty;
12
pwmDuty=(unsigned int)(oDuty*pwmPeriod);
return pwmDuty;
13
14
}
The pwmPeriod indicates how many CPU clock cycles one PWM period is with a given
frequency. This is provided as TBCCR0 (when timer B overflows).
To generate PWM signals with different duty cycles, the other TBCCRx registers are used.
These registers can be set directly with the function transDuty. This function converts a
given percentage duty cycle to the corresponding number clock cycles.
The duty cycle for the motors are updated whenever the timer reaches the value stored
in TBCCR0. The interrupt service routine is shown in 8.14.
Listing 8.14: The interrupt service routine for Timber B
1
#pragma vector=TIMERB1_VECTOR
2
__interrupt void Timer_B1(void)
3
{
4
TBCCR1=Ld;
5
TBCCR2=Lrd;
6
TBCCR3=Rd;
7
TBCCR4=Rrd;
8
TBCCR5=Td;
TBCCR6=Tdd;
9
10
}
The variables used for setting the capture compare registers have been set by the pwmMotor function (see 8.4.1). Since the ISR will only be run whenever the timer reaches the
value stored in TBCCR0, the load this interrupt puts on the CPU can be calculated as
follows in 8.1:
The first step of calculating the CPU load is to find the value the timer counts to,
before generating an interrupt. The next is to find how many interrupts are generated in
74
CHAPTER 8. IMPLEMENTATION
a second. In section 5.4.3 it was found that entering and leaving an ISR took 11 clock
cycles which is used to find how many clock cycles are used for this in a second. Lastly
the amount of clock cycles is compared to the total amount of clock cycles available in a
second in order to find the CPU load which turns out to be 0.12%. This is a fairly small
load which means it should not be the cause of any problems even if the calculation does
not take the clock cycles needed for running the code within the ISR into account.
The way the PWM signal is generated is shown in figure 8.2.
Figure 8.2: The figure shows how the PWM signal is generated from the timer and also when the
interrupt is triggered. Note: The figure shows TAIFG where in the warehouse robot
TBIFG is set since timber B is used. See [MSP430 User Guide].
8.3. USER INTERFACE
8.3
75
User interface
The configuration mode is implemented by use of serial communication, specifically
through a RS232 port to a computer, running a terminal emulation program (such as Hyperterminal).
This is implemented in software by monitoring the UART interface on the MSP.
In order to receive all the information coming from the computer we use an interrupt
driven buffer, RXbuffer (previously covered in section 7.1.2) to store the characters until
they are read by the program.
When a line break is detected, the buffer is copied, flushed and then the copy is sent
to a line processing function.
The line processing function then creates an argument list from the space separated
command string. Arguments are then parsed and appropriate command functions are
called.
Two command functions are currently supported.
Listing 8.15: Adds package coordinates to the package queue
1
/** cmd_pkg
2
/* Adds a package to queue
3
**/
4
int cmd_pkg (unsigned int x, unsigned int y);
Listing 8.16: Prints the contents of the package queue to the terminal
1
/** cmd_list
2
/* Prints the package queue to the terminal
3
**/
4
int cmd_list (void)
76
CHAPTER 8. IMPLEMENTATION
8.4
Navigation
8.4.1
PWM motor
As described in the module specification (see 7.4.1), this function is used by all modules
in the navigation process. It uses timer B to control the duty cycles on the PWM signals
sent to the motors. Calling the function looks like this.
Listing 8.17: Call of function pwmMotor
1
pwmMotor(duty cycle on left motor, duty cycle on right motor, duty cycle on tower motor, direction
of the motor);
The duty cycles are float values between 0.0 and 1.0, and the direction can be either 0 or
1 which is reverse and forward respectively.
With an if statement, the function ensures that the tower motor can not drive at the
same time as the drive motors. The function is also designed so that the drive motors can
not drive in opposite directions. Neither of these operations are necessary to fulfill the
requirement specification.
Test
See section 6.3 for the test.
8.4.2
Follow line
The follow line module consists of several if-sentences which checks where the light
sensors are positioned. It does so by reading the results made by the ADC (see section
5.4.7), which is connected to the light sensors and comparing those results with treshold
values for the warehouse floor (see section 6.4). The ADC is handled with an ISR.
Listing 8.18: ADC ISR
1
#pragma vector=ADC_VECTOR
2
__interrupt void ADC12ISR (void)
3
{
leftLightSensor = ADC12MEM0;
4
rightLightSensor = ADC12MEM1;
5
6
}
ADC12MEM0 and ADC12MEM1 holds hex values describing the brightness returned to
the light sensors. Thus leftLightSensor and rightLightSensor are two globally declared
variables which the ADC ISR writes to each time it has made a conversion. These values
are then used in the followLine function.
One conversion takes 12 clock cycles for the conversion itself + 1 clock cycle for storing the result in the memory register + the sample-hold-time which is set to 4 (See 8.9
and [MSP430 User Guide]). This makes the total time for doing one conversion to 17 clock
cycles. When the 11 clock cycles it takes to enter and leave an ISR (see 5.4.3), the CPU
8.4. NAVIGATION
77
load can be calculated (see 8.3).
7.3728·106 clk/s
17clockperinterrupts = 433694conversions(interrupts)persecond
433694interruptspersecond·11clk/int
· 100% = 64.7%CP U load
7.3728∗106 clockspersecond
Figure 8.3: Calculation of CPU load from the ADC interrupts
The calculation shows that a large amount of CPU cycles are spent on the ADC interrupts, especially considering the calculation does not take the ISR itself into consideration.
It only calculates how many cycles are spent on entering and leaving the ISR. While this
could cause problems in terms of the MSP430 not being able to run other parts of t he
program fast enough, the ADC results are such important variables for the navigation of
the robot that they are needed as fast as possible.
Once the position is found with the ADC, the robot will use its drive motors in order to
bring itself closer to the line on the floor. Due to the layout of the warehouse (see section
3.2) the focus of follow line will be to enable the robot to follow a straight line instead of
curves or bends.
The robot is adjusting itself by putting out a 20% duty cycle PWM signal to one of the
motors, and a 60% duty cycle signal to the other motor. In the code, these are defines in
the nav.c file, called motorDutySlow and motorDutyFast.
Figure 8.4: Only one light sensor is placed on the line.
The situation where one of the light sensors are outside the white line, see figure 8.4.
If the right light sensor is on the line, the robot will speed up the right motor untill the
right sensor is back on the line, and likewise if the left sensor is outside the line.
Figure 8.5 shows the situation where both light sensors are positioned on the white
line. This means that the robot was just turned on, and have not yet been outside the
line with either of the sensors. This will result in the robot driving straight forward untill
it no longer has both light sensors on the line. This situation can also occur whenever the
robot have had one of the light sensors outside the line and have adjusted the speed of the
78
CHAPTER 8. IMPLEMENTATION
Figure 8.5: Both light sensors are on the line.
motors in order to bring it back on the line. When that happens, the robot registers if it
was either the left or the right light sensor which was outside the line, and speeds up the
opposite motor. This is done to make the robot align itself on the line more closely than
would otherwise be possible.
Figure 8.6: Both Light sensors are outside the line.
In the case that both sensors are outside the white line, see figure 8.6, the robot will
maintain its previous motor speeds. Since the situation shown in 8.4 will have occurred
before both sensors leave the line, the robot will continue to turn in the direction that will
bring it back to the line.
8.4. NAVIGATION
79
Test: Speed and corrections
This test will specify how fast the robot can follow a line with the algorithm explained
above. It will also give an indication of how well it follows the line at that speed. The
actual purpose of the test is to determine the optimal duty cycles when following a straight
line.
Speed / number of corrections (turns): Software that follows the line and stops at
the first black mark it meets is loaded on the robot. The robot is placed on a
straight line (1 meter) with a black stop mark at the end. The robot is started and
the number of corrections on the line is counted. The time it takes for the robot to
reach the black mark is noted also. The test is repeated with all possible duty cycle
combinations between 0.0 and 1.0(see table 8.4).
Given the algorithm explained above, these are the results The duty cycle combinations
Duty cycle (low/high)
0.0/0.3
0.0/0.4
0.0/0.5
0.1/0.3
0.1/0.4
0.1/0.5
0.1/0.6
0.2/0.4
0.2/0.5
0.2/0.6
0.2/0.7
0.2/0.8
0.3/0.7
0.3/0.8
0.3/0.9
Correction count
15
11
10.5
14
11
9
9
3
5
4.5
6.5
7
4
5
4.5
Lap time
12.9
10.2
9.7
11.7
10.5
9.3
10.1
5.1
6.0
4.7
4.6
4.2
3.8
3.9
4.1
Meters/Sec
0.078
0.098
0.10
0.085
0.095
0.11
0.099
0.20
0.17
0.21
0.22
0.24
0.26
0.26
0.24
Table 8.1: Test of followLine with different duty cycles.
that are not shown in the table were deemed unusable during the test. Either because they
were not able to accelerate the robot from 0 m/s, because they made too big correction or
because it consequently missed the line after a few corrections.
The first measurements with combinations including 0.0 and 0.1 on motorDutySlow gives
high reliability in staying on the line, but it also gives relatively rough driving as consequence of the constant turning on and off and thereby hard corrections.
The measurements with combinations that include 0.3 were considered too fast and unstable. A high duty cycle also gives more interrupts on the tachometers for the MSP430 to
handle. Ideally, the tachometers should be turned of during followLine, but due to lack of
80
CHAPTER 8. IMPLEMENTATION
necessary time, this has not been done. They were able to follow the line though, which
is why they are included in the table.
These considerations leave combinations including 0.2. When choosing from these, the
fact that 0.2/0.4 adjusts too weak and 0.2/0.8 too rough excludes them. There is no big
difference between the last two, 0.2/0.5 and 0.2/0.6. The last mentioned is used in the final
implementation of the follow line algorithm. Even though there is no actual requirement
for speed, this combination gives a relatively good one. It is not desired to be too fast
because the packages the robot is carrying may fall off and get damaged. Therefore a
reasonable compromise between speed and safety of the packages have been used.
This combination is able to adjust itself nearly every time when placed crooked on the
white line. A video of the final implementation is included on the CD.
A side note worth mentioning for this test is that sending the same PWM signal to both
motors does not produce the result that might be expected which would be the motors
running same speed with the same PWM signal. This is not the case, one of the motors
drives slightly faster than the other. That makes it impossible for the robot to follow
the line when the difference in duty cycles is too low, since it is unable to turn both left
and right, as the small difference in duty cycle will make the robot drive straight forward
instead of actually turning.
Test: Turns
This test will give an indication of how sharp line turns it can follow.
Angle of turns (with sharp edges): This test(see table 8.2) has the same setup as the
previous one, only with turns in different angles on the middle of the line to follow.
The optimal duty cycle 0.2/0.6 for following a straight line also found in the previous
test is used. The robot is placed on the track before the turn and started. If it makes
it to the black mark after the turn the first three times, the specific turn is marked
as a success. The test is repeated with turns on angles 10, 20, 30, 40, 50, 60, 70, 80
and 90 degrees.
Given the algorithm explained above, these are the results. ”s” is for success, ”n” is
for no success. From this test, the robot can be expected to always make turns up to
30 degrees. After this, the robot starts using too much distance to adjust itself back to
drive right on the white like. The degree is likely higher if the turns have round edges.
Either way, the algorithm is not optimized for turns since they are not a requirement. The
observation of a success at 70 degrees can be interpreted as luck.
8.4. NAVIGATION
Angles / degrees
First try (s/n)
Second try (s/n)
Third try (s/n)
81
10
s
s
s
20
s
s
s
30
s
s
s
40
s
n
s
50
n
n
s
60
n
n
n
70
s
n
n
80
n
n
n
Table 8.2: Test of followLine with different duty cycles.
90
n
n
n
82
CHAPTER 8. IMPLEMENTATION
Turn90 make use of the tachometer on the right motor in order to drive a specific
distance. The robot keeps track of the inputs from the tachometers by setting the pin
on which the tachometer is connected to make use of interrupts. Then a global variable
is incremented in the interrupt service routine each time a pulse from the tachometer is
received (see 8.20).
Listing 8.19: The implementation of the turn90 module
1
void turn90( void )
2
{
3
tacoCounter = 0;
4
while( tacoCounter <= taco90 )
5
{
pwmMotor( 0.0 , motorDutyFast , 0.0 , 1 );
6
}
7
8
}
Since the tachometer counter is continuously being incremented by the ISR the tachometer counter must be set to 0, before the while loop that makes the right motor drive the
distance defined in "taco90" is run.
8.4.3
Turn90
Listing 8.20: The interrupt service routine, ISR, for the tachometer connected to port1
1
#pragma vector=PORT1_VECTOR
2
__interrupt void port1 (void)
3
{
tacoCounter++;
4
P1IFG = 0x00;
5
6
}
In order to find the amount of interrupts generated by the tachometer a test was
done. The test was done by letting the right motor run for approximately 36.5 seconds
while having a variable in the ISR which would count one up each time an interrupt was
generated. The test produced the following results:
Time (seconds)
36.8
36.8
36.6
36.5
Interrupt count
12068
12068
12068
12069
The test shows that 36.7 seconds of running the motor with a 60% duty cycle generates
12068 interrupts. This will be used in the calculation of the CPU load in 8.7
To find the CPU load the amount of interrupts per second must be found. This is done
using the results from the test as it shows how many interrupts are being generated in
8.4. NAVIGATION
83
12068
36.7
= 328.8interruptspersecond
328.8 · 11 = 3617cyclespersecond
3617
7.3728e6 · 100 = 0.05%CP U load
Figure 8.7: Calculation of the CPU load from the tachometer
36.7 seconds. As shown in section 5.4.3, entering and leaving an ISR takes 11 clock cycles.
Using that it is possible to find the amount of clock cycles used per second. When this
result is compared to the amount of available clock cycles in total, the calculation shows
that the tachometer interrupts have a CPU load of 0.05%. This is without the clock cycle
is needed to execute the instructions within the ISR, but at 0.05% CPU load it should not
cause much interference with the rest of the program execution.
84
CHAPTER 8. IMPLEMENTATION
Test
The test of this module will determine if it is able to turn the robot 90 degrees. In
the motor test (see section 6.3) the results show that there is 180 slits in a wheel rotation.
When that result is combined with the rotation of the wheel which is 14cm (as seen in
figure 8.8), and the distance between the center of the wheels is 18cm, it is possible to
calculate how many slits equals a 90 degree turn.
The robot turns by keeping one motor still and moving the other, the next step is to
Figure 8.8: Turning radius of the robot
calculate the rotation of the turning radius as shown in figures 8.9.
Circumf erence = 2 · π · radius
Circumf erence = 2 · π · 18
Circumf erence = 36 · π ≈ 113, 1cm
As the robot should turn only 90 degrees it only needs to drive 41 of
the circumference distance.
18·π
36·π
4 = 2 ≈ 28, 3cm
7
The tachometer test shows that 1slit = 90
cm (see section 6.3). Now it is
possible to find how many slits equals a 90 degree turn.
18 · π
2 ≈ 363slits
7
90
Figure 8.9: Turning radius calculations
8.4. NAVIGATION
85
Testing of the turn90 module (see table 8.3) was done by placing the robot on a line
and then running the turn90 function four times in a row. If the robot ends up being at
the same position it started at, the test was successful. A video of this is included on the
CD (see appendix A). The accuracy is measured by the distance it is from returning to
the line. The test is done with the measured amount of slits and then tested for the best
amount of slits.
Results
Test
1
2
3
4
5
Average
263
2cm
3cm
1cm
2cm
3cm
2.2cm
255
-1cm
0cm
1cm
0cm
1cm
1.0cm
250
-2cm
-1cm
0cm
-3cm
-2cm
1.6cm
Table 8.3: Turn90 tachometer test
The results shows that the best amount of slits to use, when turning 90 degrees is 255,
with lower or higher amount of slits it may sometimes end on the line but the average of
the 255 slits is best.
86
8.4.4
CHAPTER 8. IMPLEMENTATION
driveDistance
The function driveDistance implements the two modules "forward" and "reverse", by
taking an argument which decide whether the robot should drive forward of if it should
be drive backwards. It does this similar to turn90, by resetting the taco counter to 0 and
then driving a specific distance, which is defined in "tacoDistance".
Listing 8.21: The implementation of the forward and reverse modules
1
#define tacoDistance 400 /* 10 cm */
2
3
void driveDistance( int dir )
4
{
5
tacoCounter = 0;
6
while( tacoCounter <= tacoDistance )
7
{
8
if( dir == 1 )
9
{
pwmMotor( motorDutySlow , motorDutySlow , 0.0 , 1 );
10
11
}
12
else if( dir == 0 )
13
{
pwmMotor( motorDutySlow , motorDutySlow , 0.0 , 0 );
14
}
15
}
16
17
}
This code(see listing 8.21 makes the robot drive ”tacoDistance” forward or backward using the one tachometer on the right motor that has been implemented. As explained in the
following test 8.4.4, tachometers on both motors would with minor software adjustments
prevent it from driving crooked.
Test
The test of this module will determine if the robot is able to drive 10cm. In the test of
the motors (see section 6.3) the results show there is 180 slits on a wheel rotation. When
that result is combined with the circumference of the wheel which is 14cm, it is possible
to calculate the number of slits needed to drive 10 cm. The test will be done with one
tachometer on the right motor, and assume that the motors drive the same distance with
the same duty.
10cm
14cm
· 180slits = 128slits
The test(see table 8.4 is done with two lines with 10cm between, placing the wheels on
the line and driving from one line to the other. The accuracy is measured by the distance
it is from ending on the second line, the crookedness of the wheel without tachometer is
not measured, as long as it is within 2cm of the result from the wheel with tachometer.
The test is done with the measured amount of slits and then tested for the best amount
of slits.
8.4. NAVIGATION
87
Test
1
2
3
4
5
Average
128
0.5cm
0cm
-0.5cm
0.5cm
0cm
0.3cm
135
1cm
1.5cm
0.5cm
0cm
1cm
0.8cm
120
-1cm
-0.5cm
-1.5cm
-2cm
-1cm
1.2cm
Table 8.4: driveDistance tachometer test
Results
The results shows that the best amount of slits to use, when driving 10cm is 128, with
lower or higher amount of slits it may sometimes end on the line but the average of the
128 slits is best. A video of the robot driving 10 cm and back again is included on the CD.
Chapter
Acceptance test
This chapter details the project acceptance test according to our specifications (see section
4). The test is executed to determine if the project fulfills our functional requirements (see
section 3.4 and is performed as a black box test.
Figure 9.1: Acceptance test: Warehouse layout
9.1
Implementation
Implementing the acceptance test was done in phases, labeled in numbers as seen in
figure 9.1. In the results we list each phase with each expected result and the actual result.
89
9
90
9.1.1
CHAPTER 9. ACCEPTANCE TEST
Phase 1: Configuration mode at base
Robot was connected to a computer with a serial interface and package coordinates
were entered while setting the mode switch to configuration mode. The system responded
as expected by acknowledging the command. Afterwards the ’list’ command was issued and
it resulted in the system printing the package queue to the terminal and the configuration
mode was ended by entering ’done’. This test satisfied functional requirements 1.0, 1.1,
1.2 and 1.3.
9.1.2
Phase 2: Navigating the line
Robot was switched to ’warehouse mode’ and started on line. It was able to recognize different surfaces on the floor and follow the line according to light sensor values by
adjusting the drive motors. Requirements 2.0, 2.1, 2.2, 2.3 are hereby satisfied.
9.1.3
Phase 3: Drive towards the package location
After detecting the correct rack space the robot was able to turn, find the line again
and then stop at the correct shelf space.
9.1.4
Phase 4: Pick up package
After finding the correct shelf on the warehouse floor the robot drove towards the
package and raised the tower. Turning however was not precise enough to hit the package
correctly. In this phase; requirements 3.1 and 3.2 were satisfied. Requirement 3.0 was
not satisfied due to the fact that the robot was unable to lift the package. Requirement
3.3 is considered partly satisfied as the tower functioned as expected.
9.1.5
Phase 5: Drive to base and lower tower
After raising the tower, the robot was able to find the line again. After finding the
lane the robot was unable to navigate back to base without assistance as it swung too
much to be able to make precise turns. When the robot reached the final line; the tower
was lowered. Although no package was on the lift at that time, requirements 4.0, 4.1 are
considered satisfied. Requirement 4.2 is considered partly satisfied as the robot is only
able to process the first package in the package queue. Also, it was not possible to change
between the modes once configuration mode was ended, and warehouse mode was enabled.
Chapter
Future of the system
Wireless interface: Implement a wireless connection to the robot so the robot does not
have to return to base for reconfiguration. Although protocols like IR or bluetooth are
possible, the best probable solution would be to use 802.11 WLAN connection as it
offers features like roaming and a wide range. In addition the terminal interface could
be replaced with a web interface although that would require an implementation of
an IP stack.
Multiple robots: In a big warehouse it would be a great advantage to be able to run
multiple robots simultaneously on the warehouse floor. A server could coordinate the
robots through a wireless connection so the closest robot always handles the package
request and. Algorithms could be implemented in order to find the fastest delivery
possible and in order to avoid collides of other robots or obstacles.
User interface: Currently there is some learning curve in order to use the system. This
can be reduced by creating a front end for the warehouse workers, ideally using a
wireless connection to administer the robots while they operate the warehouse.
Collision detection: Detecting moving and stationary obstacles on the warehouse floor
could prevent the robot from hitting them, causing harm to cargo or people.
Package piling: In order to save space on the warehouse floor it would be a nice feature
to be able to pile packages on delivery.
Warehouse efficiency: In order to make more efficient use of the warehouse it would
be possible to have several layers of packages on each shelf. In order for the system
handle that, more precision would have to be added to the lifting mechanism as it
should know exactly how far it is between each layer.
Flexible delivery: Current design assumes that all packages are to be delivered to base.
An improvement would be making it possible to move packages between warehouse
91
10
92
CHAPTER 10. FUTURE OF THE SYSTEM
locations as well as multiple delivery positions. Restocking the warehouse from a
loading bay would also be a nice feature.
Turning: Implement inwards turning on the software level. Will make the robot more
space efficient when navigating around racks and shelves.
Integration: Integrate the system’s package queue to an existing warehouse system so
item status can be modified on the fly.
Item verification: Integrate an IR barcode scanner on the robot, so it can check if the
item moved is actually the correct one.
Implement flash memory: Currently all information is stored in RAM. This means that
if the robot is reset while in warehouse mode, the queue is lost and the robot needs
to be reconfigured. Storing configuration (package queue, light sensor calibration,
etc) and error logs to a flash chip would be a good idea.
Log entries: In every system, some errors occur, implementing a system log would make
it easier to identify and solve any problems the system might have.
Improve line following: Line navigation can be improved in ways such as the robot
will detect when the light sensor values are decreasing and adjust motor controls
accordingly instead of only only reacting when the values are at certain limits.
Power optimizations: The system could be improved by turning off components when
they are not being used as well as utilize the ultra-low-power functions within the
MSP430.
Chapter
Conclusion
11.1
Project status
The problem description which was the basis for the system is as follows:
”How would one design a prototype of an autonomous robot that can drive
around a warehouse, find and deliver user chosen goods while being able to
navigate itself with help of lines on the warehouse floor?”
As previously covered in acceptance test (see section 9), the robot can (according to
functional requirements in section 3.4) read package coordinates, recognize surfaces with
light sensors, navigate on a line, raise and lower the tower and communicate with a computer through a serial interface.
Precise turning proved to be a challenge and resulted in failure to pick up the package
correctly, and also thus failing the acceptance test.
11.2
Design
In the beginning of the project it was decided upon on a top-down design where we
started with the structure and move downwards. However during the course of the project
we came to realize that a bottom-up approach would have been a better decision due to the
fact that most of us were unfamiliar with the hardware elements as well as implementing
the basic software procedures.
11.3
Implementation
During the implementation phase (see section 8) of this project numerous challenges
were encountered on both the hardware and the software levels. Working with electrical
components as well as getting them to work with the system was difficult as well as reverse
engineering the LEGO components. Software design was almost implemented as planned
though some low level functions were modified to better work with the hardware.
93
11
94
11.4
CHAPTER 11. CONCLUSION
Testing
During functional testing, (further covered under hardware design in section 6) each
module was tested. All implemented hardware modules were tested successfully.
11.5
Future of the system
During our brainstorm sessions the group was able to come up with many future ideas
for the robot that could prove very useful in order to improve the system. Future ideas
are covered in detail in section 10.
A better warehouse robot would be able to navigate itself around a warehouse floor
without human interaction, automatically update stock, recognize packages as well as
coordinate multiple robots for the fastest possible delivery and have the option of being
configured remotely while avoiding mobile and stationary obstacles.
11.6
Final words
During the course of this project the group has had a chance to work with many new
subjects; such as micro-controllers, electrical components, embedded programming and
logical computing. This has given us an insight into how embedded systems work as well
as a better general understanding of computer systems.
List of Figures
2.1
Ackerman, differential drive and the robots way of turn. . . . . . . . . . . . . .
6
3.1
Warehouse layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2
System influences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3
Actor context diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4
Use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1
Flowchart showing system functionality based on use cases . . . . . . . . . . . . 27
5.2
Overview of modes and processes . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.3
System architecture flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.4
Block diagram of the MSP430 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.5
The timer in upmode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.6
The timer in continuous mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.7
The timer in up/down mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.8
Picture of a pwm signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.9
Block diagram of the SAR in the MSP430 . . . . . . . . . . . . . . . . . . . . . 35
5.10 Example of a SAR ADC conversion. . . . . . . . . . . . . . . . . . . . . . . . . 35
6.1
Block diagram: Hardware overview . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.2
Circuit diagram: Power supply . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.3
Resistor calculations for the LM317T . . . . . . . . . . . . . . . . . . . . . . . . 40
6.4
Voltage calculations for the LM317T . . . . . . . . . . . . . . . . . . . . . . . . 40
6.5
The pwm signal and the current in an inductor. . . . . . . . . . . . . . . . . . . 42
6.6
Circuit diagram: Motor driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.7
Circuit diagram: Motor driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.8
Diagram with the voltage division for the tachometer . . . . . . . . . . . . . . . 45
6.9
Circuit with the most essential of the light sensor . . . . . . . . . . . . . . . . . 46
6.10 Open collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.11 Reference voltage used by the ADC . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.12 Voltage and ADC output graph . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.13 Circuit diagram: Serial communication . . . . . . . . . . . . . . . . . . . . . . . 49
95
6.14 Hardware overview (part one) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.15 Hardware overview (part two) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.16 Overview of the pins on the MSP. The marked pins are used in the system. . . 53
6.17 The robot from the side. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.18 The tower on the robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.19 The robot seen from below, where the light sensors and the motors are showed.
57
7.1
Activity diagram: User interface process . . . . . . . . . . . . . . . . . . . . . . 59
7.2
Activity diagram: Navigation process . . . . . . . . . . . . . . . . . . . . . . . . 61
7.3
Activity diagram: Tower process . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.4
Follow line sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.5
Turn90 sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.6
Shows the placement of the light sensors when turning 90 degree, and adjusting back to the line. 65
7.7
Forward/reverse sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.8
Lift/lower sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
8.1
Calculation of CPU load from the TimerB interrupts . . . . . . . . . . . . . . . 73
8.2
The figure shows how the PWM signal is generated from the timer and also when the interrupt is trigg
8.3
Calculation of CPU load from the ADC interrupts . . . . . . . . . . . . . . . . 77
8.4
Only one light sensor is placed on the line. . . . . . . . . . . . . . . . . . . . . . 77
8.5
Both light sensors are on the line. . . . . . . . . . . . . . . . . . . . . . . . . . . 78
8.6
Both Light sensors are outside the line.
8.7
Calculation of the CPU load from the tachometer . . . . . . . . . . . . . . . . . 83
8.8
Turning radius of the robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
8.9
Turning radius calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
9.1
Acceptance test: Warehouse layout . . . . . . . . . . . . . . . . . . . . . . . . . 89
. . . . . . . . . . . . . . . . . . . . . . 78
List of Tables
6.1
System power usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.2
Estimated system running time . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.3
LEGO motor pin specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.4
Duty cycles and actual motor speed . . . . . . . . . . . . . . . . . . . . . . . . 44
96
List of Tables
97
6.5
LEGO light sensor pin specifications . . . . . . . . . . . . . . . . . . . . . . . . 46
6.6
Light sensor test results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.7
Voltage levels and binary values . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.8
MSP430 pin usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
8.1
Test of followLine with different duty cycles. . . . . . . . . . . . . . . . . . . . . 79
8.2
Test of followLine with different duty cycles. . . . . . . . . . . . . . . . . . . . . 81
8.3
Turn90 tachometer test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
8.4
driveDistance tachometer test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Bibliography
[Embedded Systems] James K. Peckol, Nyt Teknisk Forlag, Embedded Systems, 1988.
[SPU] Nyt Teknisk Forlag, Struktureret Programudvikling, 1988.
[Building Lego Robots] Syngress, Building Robots with LEGO Mindstorm, 2001, Chapter
8.
[MSP430 Datasheet] Texas Instruments, MSP430x1xx Datasheet, 2000, Can be found on
CD-rom or at http://www.control.aau.dk/%7Ebisgaard/teaching/d3/dap/dap-litterature/databl
[MSP430 User Guide] Texas
ily
User
Guide,
MSP430x1xx
Instruments,
2004,
Can
be
found
on
Fam-
CD-rom
or
at
http://www.control.aau.dk/%7Ebisgaard/teaching/d3/dap/dap-litterature/users-guide.pdf.
[LE33] ST Micro Electronics, LE33 Datasheet, Can be found on CD-rom or at
http://www.datasheetcatalog.com/datasheets_pdf/L/E/3/3/LE33CZ.shtml.
[LM78L] National Semiconductor, LM78LXX Datasheet, Can be found on CD-rom or at
http://www.datasheetcatalog.com/datasheets_pdf/L/M/7/8/LM78L05.shtml.
[LM317] National Semiconductor, LM313 Datasheet, Can be found on CD-rom or at
http://www.datasheetcatalog.com/datasheets_pdf/L/M/3/1/LM317.shtml.
[L298N] ST Micro Electronics, L298N Datasheet Can be found on CD-rom or at
http://www.datasheetcatalog.com/datasheets_pdf/L/2/9/8/L298N.shtml.
[1] The LEGO Group, LEGO Mindstorms NXT Hardware Developer Kit. 2006
[2] Philippe Hurbain, NXT motor internals, http://www.philohome.com/nxtmotor/nxtmotor.htm.
[Ackerman steering principle] RC
&
resources
for
the
TEK,
Model
Car
RC
Racer,
TEK
Can
-
Information
be
found
at
http://www.rctek.com/technical/handling/ackerman_steering_principle.html.
99
Appendix
CD-ROM Index
List of the items on the CD-ROM attached to the report.
• Movies
– whrobot-followLine1m.mp4
– whrobot-fourTimesTurn90.mp4
– whrobot-driveDistance10cm.mp4
– whrobot-tower2cm.mp4
– whrobot-accepttest.mp4
• Code
– final.eww
– final.ewp
– final.ewd
– robot.dep
– main.c
– nav.c
– nav.h
– pwm.c
– pwm.h
– ui.c
– ui.h
– lightSensor.c
– lightSensor.h
– basic_clock_module.c
– basic_clock_module.h
– common.h
• Datasheet
– LE33
101
A
102
APPENDIX A. CD-ROM INDEX
– LM78L
– LM317
– L298N
– MSP430 User Guide
– MSP430 Datasheet
Appendix
Code structure
• main.c
– modeInit()
– init()
– mode()
– ui()
– nav()
– main()
• nav.c
– tacoInit()
– turn90()
– driveDistance(int dir)
– tower(int dir)
– followLine(int blackLineTurns)
• pwm.c
– transDuty(float oDuty)
– pwmInit()
– pwmMotor(float L, float R, float T, int D)
• ui.c
– serialInit()
– putchar(int c)
– _interrupt void uart0_rx()
– KeyHit()
– _interrupt void uart0_rx()
– char ui_GetChar()
– print_uart (unsigned char *str)
103
B
104
APPENDIX B. CODE STRUCTURE
• lightSensor.c
– adcInit()
• basic_clock_module.c
– basicClockInit(void)