WAY N E S TAT E U N I V E R S I T Y
BASIC ENGINEERING
J U N K B OT R E P O RT
M AT T H E W K A B L E
NASSER ALRAHBI
AY U S H I J H A R I A
Z AK ARY B ON DY
GOAL
For our final project we were asked to design a bot with the objectives to:
 Stay within the domain of a white board for the entire test
 to detect cans and remove them from the domain
 to move randomly while hunting for the cans
 to completely remove ten cans within three minutes
CONCEPT
MECHANICAL DESIGN
The design of the bot remained the same since our original tribot assembly. Our first thought was to
create a “plow” that would simply push the cans out of the domain set by our instructor. We used three
sensors in total:
 one sensor ( the down sensor) was pointed down in the center of our bot
o this sensor dealt with line detection to remain in the domain
 two sensors (can sensors) were pointed horizontally to detect cans
o we used two for can detection as were required to signal when we detected cans
We wanted to make the plow a bit narrow as to avoid knocking over any cans. This design worked quite
well as we completed the course with a time of 2:06.
CONTROL SYSTEM
The control system was created using four tasks and three sensors.
Configuring Sensors
To configure the sensors we first had to find the thresh levels for the cans and the black line. To find our
thresh levels, we monitored the down sensor (for line detection) as it crossed from white to black and
back again for accurate if and until statements. This was extremely important because if our bot
misread the line our bot may exit the arena and never return. This was the first objective of our group
to master.
For the can sensors, we analyzed both sensors as we took our cans and slowly edged them toward their
LED’s. The thresh was revised a lot as we realized that the bot might read the can again if it did not push
the can far enough away at the edge of the arena. This was as critical as the reading the line because
the bot would just read the can again and leave the arena. We ended up choosing a thresh level for the
can that corresponded to a distance of about two-three inches from our sensors.
Problems. The problems with these configurations dealt mostly with the externalities of the room and
board. The board’s black line had many different thresh levels due to tape reflections, board creases,
and inconsistencies in room lighting. Problems with the can were that the bot would read the cans even
as it reached the end of the board causing it to leave the arena.
Global Variables
We created two global variables, dir and can, where dir relates to the line and can relates to the cans.
Inline voids
We created the inline functions for all movements for a clean and easily readable code. They are as
follows:



Move: random motion (hunting)
Remove: movement to remove cans
Line: maneuver to stay within the domain
Task Creation
We ended up using four tasks to complete our objectives. They are as follows:




task feedback: to monitor the down sensor
task movement: randomly moves hunting for cans
task detect: to monitor the can sensors
task domain: maneuvers to stay within the arena
Task feedback was to monitor only the down sensor. Whatever the sensor was reading corresponded to
a variable, defined as a global variable (dir), relating to it being over white (in bounds), or being over
black (the domain restriction). When the sensor read white, dir=0, and when the sensor read black,
dir=1. This allowed our bot to recognize where it was and either continue hunting for cans, or to
perform a maneuver to stay within the bounds of the domain.
Task detect was to monitor both can sensors. The global variable corresponding to can detection was
designated “can.” When either sensor detected a can the thresh was met and our sensors read can=1,
signaling that there was a can in its plow and it is time to remove that can.
Task movement involved commands to make the bot run randomly around the white board. This was
considered a hunt task because it moved around the board searching for cans, or can=1. This task was
controlled by the sensors as their threshes were crossed they stopped this command to perform the
correct maneuver.
Task domain was the series of commands we gave to remove the can while staying within the domain.
When the variable can=1 was read the bot would stop task movement, start the inline function remove,
and start task movement again when dir=1, or the boundary was reached. We were able to stop the bot
when we created “if (dir == 1)” we would stop task movement and detect so the bot would do nothing
but notice the line and avoid it.
THE DOMAIN
THE DESIGN
THE CODE
#define THRESH_1 40
#define THRESH_2 45
#define REYE SENSOR_1
#define LEYE SENSOR_2
#define DOWN SENSOR_4
#define LEFT OUT_A
#define RIGHT OUT_B
int can=0;
int dir=0;
inline void Move()
{
OnFwd (OUT_A, 85);
OnFwd (OUT_B, 75);
Wait (1000 +
(Random(2000)));
if (Random (2) == 1)
Off (OUT_B);
else
{
Off(OUT_A);
}
Wait (Random(1000));
}
inline void Line()
{
OnRev (OUT_A, 85);
OnRev (OUT_B, 75);
Wait (500);
OnRev(OUT_A, 85);
OnFwd(OUT_B, 75);
Wait (500);
}
inline void Remove()
{
OnFwd (OUT_A, 100);
OnFwd (OUT_B, 100);
}
task feedback()
{
while (true)
{
if (Sensor(IN_4) <=
THRESH_1)
{
dir=1;
}
if (Sensor(IN_4) >
THRESH_1)
{
dir=0;
}
}
}
task detect()
{
while (true)
{
if ((Sensor(IN_1) >=
THRESH_2) ||
(Sensor(IN_2) >=
THRESH_2))
{
can=1;
}
}
}
task movement()
{
while (true)
{
if (dir == 0)
{
Move();
}
}
}
task domain()
{
while (true)
{
if (can == 1)
{
StopTask (movement);
PlayToneEx (300, 200, 4, FALSE);
Wait (100);
PlayToneEx (400, 200, 4, FALSE);
Wait (100);
PlayToneEx (500, 200, 4, FALSE);
Wait (100);
Remove();
until(dir==1);
can=0;
StartTask (movement);
}
if (dir == 1)
{
StopTask (movement);
StopTask (detect);
Line();
StartTask (movement);
StartTask (detect);
}
}
}
task main()
{
SetSensorLight (IN_1);
SetSensorLight (IN_2);
SetSensorLight (IN_4);
StartTask (movement);
StartTask (feedback);
StartTask (domain);
StartTask (detect);
}
We input our preprocessor directives first. We defined the
sensors, thresh levels, and created two global variables. One
global variables was dir (black line sensing) and can (can
detecting). Then we made three inline functions: Move,
Remove, and Line to handle all strictly motion functions.
Move handled random motion as the bot hunted, Remove
handled can removal, and Line kept the bot in bounds at all
times.
We then created task detect which monitored the two can
sensors and when they read a can the variable equaled one.
A fairly simple task to write.
Then came task movement, which handled all hunting motion
(random OnFwd and turns) and remained hunting as long as
the bot was on the white board. If the bot reached a black
line, this task was overridden, as well as when the bot sensed
a can where the task would be stopped as well.
Task domain dealt with removing the can. Once a can was
read, we stopped task movement, called for the bot to play
tones, and then perform the inline function Remove which
put both motors at 100% power in the forward direction till
the bot reached the line (where tasks movement and detect
were stopped if the bot read the line, performed the inline
function Line to avoid the line and return to hunting). To
make sure the bot didn’t keep reading the can, we set can=0
for when the bot reached the line. This ensured our bot
would “reset” and not read the can and leave the domain.
Task feedback simply monitored the down sensor and kept
the bot in the arena. The bot read dir=0 for being in bounds
and dir=1 when it read the line. When dir read 0, the bot
hunted, when it read 1, the bot performed the inline function
Line which brought it back in bounds.
Task main sets the sensors and runs all the tasks.
RETROSPECT
The problems really dealt with externalities such as the room,
lighting, extra tape, cans being different, etc. These were our
biggest problems. The next big problem would have been
setting the can=0 after it reached the line. Once it read one
can it read it forever. Once we solved that we were fine. I
think we may have developed a better plow as well to read
cans that were tipped over as well, a small design issue.
Engineering Log
 talks about design
o we are using a pusher/plow
o using one sensor down, one sensor up
 Problem maybe detecting cans?
o deciding on two sensors up for can detection and one down for line
o make the plow past the sensor so the can is out of the domain before the bot exits
 talks about control system
o defines
 3 light sensors
 2 for cans
o according to thresh of can
 1 for line
o according to thresh of line
 global variable dir
 calls from thresh levels
o inline voids
 random movement
 can removing
 line evasion (domain restriction)
o linefollow
 sensor reads black
 backs up for some time
 makes turn (one directional) then continues random movement
o movement
 makes random movement
 same turn?
 right or left but only this turn
o can removing
 Wait
 make a sound
 when the thresh is met by the can
 moves on FWD until it reaches black line
 then continues linefollow
 So can detection
 stop task movement
 audio file
 OnFwd
 still follows linefollow
 so once interesection is reached
 back up
 start movement

o
feedback
 monitors thresh levels
 two for cans
 one for line


 dir variable
Development
o Making plow a little bit smaller to reduce cans we hit
o Removing top bar
Coding
o Line evading isn’t good
 Made it to make a tighter turn, looks good
o Need to make motion more random
o Adding random turns
o Thresh levels are varying a lot
o Reads the crease in the board
o Got good thresh levels
o Once the can is read the bot always is reading the can
o Set can=0 if dir == 1
 This resets the variable after the can has reached the line
 Then we stoptasks to ensure it doesn’t read and returns to arena
o Seems to work well
o Passed with 2:06