Technical

Programming
Overview
The coding process is done on the last 4 days of the training and it involves an
iterative process of writing the code necessary for the robot to achieve the given
task and debugging the previous command in case it doesnt work. The coding is
done using the jEdit program and written in assembly language. The program is
then assembled on command prompt and installed onto the 8051 microprocessor
using the flashmagic application. This part of the report explains the basic strategy
and division of cases used to accomplish the task. The exact procedure and code
used can be viewed in the appendix section, titled SUCCESS1
The route
The figure below shows the path that the robot will take from the start point to pass
through all 10 checkpoints. The chosen route is symmetrical, does not require the
robot to take the long path at the bottom of the game field, and all the intersection
points can be classified as one of the 8 different cases.

Finis

Star

The route that the robot takes to pass through all 10 checkpoints.
The four sensors
Four sensors are placed on the front part of the robot to detect the color of the
ground below it in order to detect its location and follow the given route. The four
sensors are placed symmetrically along the right plane. The two inner sensors are

called the tracking sensors. They are placed 46mm apart and are used for straight
line tracking as well as turning commands such as stopping a right turn when the
right tracking sensor moves out of the white line. The two outer sensors are called
the crossing sensors. They are placed 110mm apart and are used to detect
intersections as well as turning commands such as differentiating a 135 degree
intersection and a T-intersection by using an offset turning value which will be
discussed later.
The assembly language
Here, we list the basic commands that we use in the assembly language to achieve
the given task.
We define the motor movements as follow:
FORWARD MOTOR 1 FORWARD CONTROL BYTE ROBOT MOVES FORWARD
BACKWARD MOTOR 1 BACKWARD CONTROL BYTE ROBOT MOVES BACKWARD
ROT_L MOTOR 2 ROTATE LEFT CONTROL BYTE ROBOT ROTATES ANTI-CLOCKWISE
ROT_R MOTOR 2 ROTATE RIGHT CONTROL BYTE ROBOT ROTATES CLOCKWISE
STOPPED MOTORS STOPPED CONTROL BYTE ROBOT STOPS ALL MOTION
We define the sensors as follow:
FB_SEN SENSOR FOR MOTOR 1 CONTROL
LC_SEN SENSOR FOR LEFT CROSSING LINE SENSING
LT_SEN SENSOR FOR LEFT TRACK SENSING
RT_SEN SENSOR FOR RIGHT TRACK SENSING
RC_SEN SENSOR FOR RIGHT CROSSING LINE SENSING
There are also some syntax which is part of the assembly language:
JNB if not bit when the sensor value is low when the sensor is on white line
JB if bit when the sensor value is high when the sensor is not on the white line
$ - loop the previous command if the given condition is met.
Line tracking
The line tracking capability of the robot is enabled by the two inner sensors called
the tracking sensors. The width of the white line is 38mm so the distance of the two
inner sensors are kept at 46mm, not too small that both sensors will detect the line
and not too wide that the accuracy of the line tracking is compromised. The
mechanism of the program is really simple. When the right tracking sensor detects
the white line, the robot will turn right until the right tracking sensor moves out of
the white line. Inversely, when the left tracking sensor detects the white line, the
robot will turn left until the left tracking sensor moves out of the white line.

The code is written from the template given in LAB03, and consists of two
subroutines, TUNE_L and TUNE_R. For TUNE_L, the robot rotates anti-clockwise until
left track sensor moves out of white track, then loop back to rfor. For TUNE_R, the
robot rotates anti-clockwise until right track sensor moves out of white track, then
loop back to rfor. These subroutines are called upon only when the robot moves in a
straight line and does not pass intersections, which means the values of the LC_SEN
and RC_SEN is high. If value of LT_SEN is low, TUNE_L is called; if value of RT_SEN is
low, TUNE_R is called.
The intersections and following the prescribed route
Our robot uses a semi-random strategy to finish the track. This means that the
robot does not follow a sequence of turns whenever it comes to an intersection.
Instead, it can detect the type of intersection anywhere on the game field and turn
accordingly to finish all checkpoints. One of the advantages of this strategy is that
the robot can start anywhere on the game field and get to the finish line, as long as
it is facing the correct direction. This is useful during testing as we can test the
robot for any intersection without the need for the robot to successfully finish all the
turns from the start point in order to test a single turn on an n th intersection. A
disadvantage is that the coding becomes more tedious as we would rely more on
the sensors to detect the types of intersections, and we would have 8 different
cases, each with its own series of command once it is initiated.
The left crossing sensor and right crossing sensor is used to detect when the robot
comes upon a turn or an intersection. At all times, one of these 4 cases will occur:
LC_SEN
HIGH
HIGH
LOW
LOW

RC_SEN
HIGH
LOW
HIGH
LOW

TYPE OF INTERSECTION
NO INTERSECTION
WHITE LINE ON RIGHT
WHITE LINE ON LEFT
WHITE LINE ON BOTH
SIDES

In the first type where both sensors are high, the code will resume as normal and
the line tracking command will be run if either of the tracking sensor is low,
otherwise the robot will continue to move forward. In the second type where there is
a white line on the right hand side, there will be three possible cases for the given
route, namely case 3, case 4, and case 7. On the other hand, for the third type
where there is a white line on the left hand side, there will be three possible cases
for the given route, namely case 1, case 2, and case 8. For the last type of
intersection, there are only two possible cases: case 5 and case 6. These cases will
be defined and discussed in later in the section The 8 cases.
The subroutines
In addition to the TUNE_L and TUNE_R subroutines provided in LAB03, we have
made 11 new subroutines, which consists of 3 global commands and the 8 different
cases which depends on the types of intersections. The 3 global commands are
FORCONT, FORCONT1 and DELAY1S

The FORCONT command is created because the sensor is located in front of the
robot which is not the axis of rotation of the robot. By using the FORCONT
command, every time the robot detects an intersection, the first command within
the sequence is to continue moving forward two steps so that the axis of rotation
will land on the intersection, before turning the robot in either direction. The FB_SEN
is used to detect one turn of the climbing leg. One turn would mean that we need to
run the forward command as long as FB_SEN is low and then as long as FB_SEN is
high. So for FORCONT, we have 4 rows of loop command.
FORCONT1 basically serves the same function as FORCONT but only moves the
robot forward by 1 step. It is initiated directly after TUNE_L or TUNE_R is complete to
prevent the robot from alternating between clockwise and anticlockwise movement
when the white line is wide. This mechanism will be discussed further in the failsafe
methods.
DELAY1S is useful for debugging and is added after the robot completes a rotation.
After rotating until the desired position, P0, #STOPPED is issued and then DELAY1S
so that the robot stops moving for one second before the next command is issued.
DELAY1S is also used to differentiate between case 1&8 with case 2, and between
case 3&4 with case 7.
The 8 cases
The 3 types of intersections are further divided into 8 cases which consists of all the
intersections in the given route. The 8 cases are as follow:
White line on left (Case 128)

Case 1

Case 2

Case 8

Case 4

Case 7

White line on right (Case 347)

Case 3
White line on left and right (Case 56)

Case 5

Case 6

If we review the route followed by the robot, the sequence of cases is simply:
Start-1-4-5-4-3-4-6-8-8-8-6-4-3-2-1-4-Finish
Differentiating the 3 different types of intersection is a simple task, but
differentiating the cases within each type of intersection is not as straightforward.
However, we have several choice of sensors to detect the number of rotation, and
hence we can combine the cases if we choose the appropriate sensor.
For example, for case 1 and case 8, the left tracking sensor passes the white line
once as the robot rotates anti-clockwise and hence they can have the same
sequence of commands. The same applies for case 3 and case 4 where the right
sensor passes the white line three times as the robot rotates clockwise. For case 5
and 6, the robot can stop rotating anti-clockwise as the right tracking sensor
touches the white line, followed by the TUNE_R which is automatically initiated.
Hence, now the only problem is to distinguish between case 1 & 8 with case 2, and
between case 3 & 4 with case 7. To solve this problem, we use a certain amount of
DELAY1S subroutine after the tracking sensor passes the white line to add an offset
in the rotation. After the added rotation, the motors are stopped to stop the rotation.
In this position, either the crossing or tracking sensor will be on the white line for
case 2 and case 7, but it will be out of the white line on the other 4 cases. Based on
this information, we can know which series of command to initiate and therefore the
robot will turn to the correct direction.
Failsafe methods
Based on the results of several test runs, there are some problems encountered due
to variation in the step length as well as the rotation angle. As a result, the robot fail
to identify the correct case or may loop over the same pair of opposite commands.
When the robot is approaching a cross intersection, the intersection should fall as
either case 5 or case 6. However, if the robot is slightly tilted, and the forward step
barely touches the intersection, it is possible that only the LC_SEN or RC_SEN
detects the white line, but not both. To address this problem, once either crossing
sensor detects a white line, the FORCONT1 command is called, and if the opposite
crossing sensor detects the white line, then it falls into either case 5 or 6, and not
the other 6 cases.
Another problem encountered was when the robot is not oriented parallel to the
white line. Here, the width of the line may exceed 38 mm and even 46 mm. As a
result, the LT_SEN detect the white line and initiates the TUNE_L command. But this

results in the RT_SEN to fall into the white line which initiates the TUNE_R command,
and this, in turn, results in the LT_SEN to fall into the white line, causing an infinite
loop of TUNE_L and TUNE_R. To tackle this problem, we add the FORCONT1
subroutine after either tuning subroutine which forces the robot to move forward by
1 step right after moving the tracking sensor out of the white line, even though this
motion cause the other tracking sensor to fall into the white line. This strategy has
successfully removed the possibility of the infinite loop which causes the robot to
stay in the same position and unable to finish the task.

Please put this in the appendix section

Appendix - SUCCESS1
FORWARD
EQU
00000001B
;MOTOR 1 FORWARD CONTROL BYTE
BACKWARD EQU
00000010B
;MOTOR 1 BACKWARD CONTROL BYTE
ROT_L
EQU 00000100B
;MOTOR 2 ROTATE LEFT CONTROL BYTE
ROT_R
EQU 00001000B
;MOTOR 2 ROTATE RIGHT CONTROL
BYTE
STOPPED
EQU 00000000B
;MOTORS STOPPED CONTROL BYTE
;SENSORS BITS
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
FB_SEN
BIT
P2.0
;SENSOR FOR MOTOR 1 CONTROL
LC_SEN
BIT
P2.1
;SENSOR FOR LEFT CROSSING LINE
SENSING
LT_SEN
BIT
P2.2
;SENSOR FOR LEFT TRACK SENSING
RT_SEN
BIT
P2.3
;SENSOR FOR RIGHT TRACK SENSING
RC_SEN
BIT
P2.4
;SENSOR FOR RIGHT CROSSING LINE
SENSING
ORG
ADDRESS
START:
STOP:
DEBUG

00H

ACALL RFOR
AJMP STOP

;00H DECLARED AS PROGRAM START

;CALL RFOR SUBROUTINE
;PROGRAM STOPPED, USEFUL FOR PROGRAM

;ROBOT MOVES FORWARD ALONG WHITE TRACK SUBROUTINE

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
RFOR:
MOV P0, #FORWARD
;MOVES THE ROBOT FORWARD
JB
FB_SEN, $
;LOOP BACK TO ITSELF IF FB_SEN IS HIGH
JNB
LC_SEN, CASE12856
;LEFT CROSS SENSOR
LOW, JUMP TO TURN_L45
JNB
RC_SEN, CASE34756
;RIGHT CROSS SENSOR LOW, JUMP TO
TURN_R45
JNB
JNB

LT_SEN, TUNE_L
RT_SEN, TUNE_R

;LEFT TRACK SENSOR LOW, JUMP TO TUNE_L

;RIGHT TRACK SENSOR LOW, JUMP TO

TUNE_R
EXIT:

AJMP RFOR

;LOOP BACK TO RFOR

MOV P0, #STOPPED

RET

;STOP ALL MOTORS

;ROBOT FORWARD SUBROUTINE ENDED

;TURN ROBOT LEFT FOR KEEPING ON MOVING ALONG WHITE TRACK BRANCH
TUNE_L:
MOV P0, #ROT_L
;ROTATE ROBOT LEFT
JNB
LT_SEN, $
;UNTIL LEFT TRACK SENSOR MOVES OUT
WHITE TRACK

ACALL FORCONT1
AJMP RFOR
;LOOP BACK TO RFOR
;TURN ROBOT RIGHT FOR KEEPING ON MOVING ALONG WHITE TRACK BRANCH
TUNE_R:

MOV P0, #ROT_R

JNB
RT_SEN, $
WHITETRACK
ACALL FORCONT1
AJMP RFOR

;ROTATE ROBOT RIGHT

;UNTIL RIGHT TRACK SENSOR MOVES OUT
;LOOP BACK TO RFOR

;CASE12856
CASE12856: JNB
JB

RC_SEN, CASE56
RC_SEN, CASE128562

CASE128562:
JNB
JB

ACALL FORCONT1
RC_SEN, CASE56
RC_SEN, CASE128

;CASE128
CASE128:

ACALL FORCONT1
MOV P0, #ROT_L
JNB
LT_SEN, $
JB
LT_SEN, $
ACALL DELAY1S
JNB
LT_SEN, $
MOV P0, #STOPPED
ACALL DELAY1S
MOV P0, #ROT_L
JB
RT_SEN, $
ACALL DELAY1S
JNB
RT_SEN, $
ACALL DELAY1S
ACALL DELAY1S
ACALL DELAY1S
ACALL DELAY1S
MOV P0, #STOPPED
ACALL DELAY1S
JNB
LC_SEN, CASE2
JNB
LT_SEN, CASE2
AJMP CASE18

CASE34756: ACALL FORCONT1

JNB
LC_SEN, CASE56
JB
LC_SEN, CASE347
CASE18:

MOV P0, #ROT_R

JB
RT_SEN, $
ACALL DELAY1S

JNB
RT_SEN, $
MOV P0, #STOPPED
ACALL DELAY1S
AJMP RFOR
CASE2:

;CASE56
CASE56:

;CASE347
CASE347:

CASE34:

MOV P0, #ROT_L

JB
LT_SEN, $
ACALL DELAY1S
JNB
LT_SEN, $
MOV P0, #STOPPED
ACALL DELAY1S
AJMP RFOR
ACALL FORCONT
ACALL FORCONT1
MOV P0, #ROT_L
JB
RT_SEN, $
MOV P0, #STOPPED
ACALL DELAY1S
AJMP RFOR
ACALL FORCONT1
MOV P0, #ROT_R
JNB
RT_SEN, $
JB
RT_SEN, $
ACALL DELAY1S
JNB
RT_SEN, $
MOV P0, #STOPPED
ACALL DELAY1S
MOV P0, #ROT_R
JB
LT_SEN, $
ACALL DELAY1S
JNB
LT_SEN, $
ACALL DELAY1S
ACALL DELAY1S
ACALL DELAY1S
ACALL DELAY1S
MOV P0, #STOPPED
ACALL DELAY1S
JNB
RC_SEN, CASE7
JNB
RT_SEN, CASE7
AJMP CASE34
MOV P0, #ROT_R
JB
RT_SEN, $
ACALL DELAY1S
JNB
RT_SEN, $
MOV P0, #STOPPED

MOV P0, #ROT_R

JNB
RT_SEN, $
JB
RT_SEN, $
ACALL DELAY1S
JNB
RT_SEN, $
MOV P0, #STOPPED
ACALL DELAY1S
AJMP RFOR
CASE7:

MOV P0, #ROT_R

JB
RT_SEN, $
ACALL DELAY1S
JNB
RT_SEN, $
MOV P0, #STOPPED
ACALL DELAY1S
AJMP RFOR

;ROBOT MOVES FORWARD ONE MORE CYCLE SUBROUTINE

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
FORCONT: MOV P0, #FORWARD
;MOVES THE ROBOT FORWARD
JNB
FB_SEN, $
JB
FB_SEN, $
JNB
FB_SEN, $
JB
FB_SEN, $
MOV P0, #STOPPED
;STOP ALL MOTORS
RET
FORCONT1: MOV
JNB
JB
MOV
RET

P0, #FORWARD
FB_SEN, $
FB_SEN, $
P0, #STOPPED

DELAY1S:
XL1:
XL2:
XL3:

R5,
R6,
R7,
R7,
R6,
R5,

MOV
MOV
MOV
DJNZ
DJNZ
DJNZ
RET
END

#3
#224
#222
XL3
XL2
XL1

;MOVES THE ROBOT FORWARD

;STOP ALL MOTORS