A Preliminary Design Plan for an Open Architecture
Robot Kit Intended for Learning Purposes
Matt Huff
Sarah Oman
Mark Albiston
Damian Sanchez
Cory Brighton
College of Engineering
University of Idaho
April 29, 2008
Abstract
This report gives a preliminary plan to develope an open architecture robot unique to the
University of Idaho’s Electrical and Computer engineering department. The Boe-Bot by
Parallax and the Mindstorm by Lego’s, are two basic robot kits which were studied, each with
strengths and weaknesses. A sensor board was designed by this year’s senior design team for the
Boe-Bot. The design process of the sensor board helped the team to understand how to develop
a PCB from scratch, how sensors can integrate with existing robot kits, and how to fabricate
multi-use mechanical parts. Using this information, a preliminary plan with areas of
development for future design teams in, software, hardware, Smart Sensors using IEEE 1451
standardization, documentation, and testing were discussed. By following the plan given in this
report, and doing further research and development in the areas listed, a robot kit, meeting all the
requirements and more, can and will become a realization.
Table of Contents
Executive Summary ........................................................................................................................ 1
Introduction ..................................................................................................................................... 2
Problem Definition.......................................................................................................................... 4
Current Mechanical Design ............................................................................................................ 5
A.
Plates ................................................................................................................................ 6
B.
Bars................................................................................................................................... 7
C.
Brackets ............................................................................................................................ 8
D.
Wheels .............................................................................................................................. 9
Current Electrical Design ................................................................................................................ 9
A.
Overview .......................................................................................................................... 9
B.
Sensors ........................................................................................................................... 10
C.
Memory .......................................................................................................................... 13
D.
Motors/Actuators ............................................................................................................ 13
E.
User Programming Interface .......................................................................................... 14
F. Power Sources .................................................................................................................... 14
G.
Wrap Up ......................................................................................................................... 15
Future Work .................................................................................................................................. 15
A.
Overview ........................................................................................................................ 15
1.
Basic Kit ..................................................................................................................... 16
2.
Advanced Kit .............................................................................................................. 16
B.
Areas of Development .................................................................................................... 17
1.
Software ...................................................................................................................... 17
2.
Hardware .................................................................................................................... 19
i
IEEE 1451 Standard .............................................................................................................. 24
Documentation ...................................................................................................................... 25
Testing................................................................................................................................... 26
Conclusion .................................................................................................................................... 27
References ..................................................................................................................................... 28
Appendix A .................................................................................................................................. A1
Appendix B ................................................................................................................................... B1
List of Figures
Figure 1: First Year Assembly ............................................................................................ 5
Figure 2: Catapult Assembly .............................................................................................. 6
Figure 3: 5x7 inch Plate
.................................................................................................. 7
Figure 4: A 6.5-inch Bar ..................................................................................................... 8
Figure 5: 5-Hole Flat Bracket ............................................................................................. 8
Figure 6: Picture of the Boe-Bot robot ............................................................................... 9
Figure 7: IR sensor board for the Robot ............................................................................. 10
Figure 8: Black line intersection and sensor orientation ..................................................... 12
Figure 9: A square wave pulse width .................................................................................. 13
Figure 10: Lego Mindstorm Programming Software.......................................................... 18
Figure 11: Single Board Processing Block Diagram .......................................................... 19
Figure 12: Arduino NG ....................................................................................................... 21
Figure 13: Distributed Processing Block Diagram ............................................................. 22
Figure 14: PC/104 Single Board Computer ........................................................................ 23
ii
Executive Summary
This report gives a preliminary plan to developing an open architecture robot unique to
the University of Idaho’s Electrical and Computer Eeeengineering department. The robot kit
will help teach students, from high school through college, about robotic engineering
practices. The department needs a robot kit for learning purposes to stay competitive as a
college.
This report explains what this year’s senior design team has uncovered and researched
into developing a robot kit unique to the university. The Boe-Bot by Parallax and the Mindstorm
by Lego’s, are two basic robot kits currently in production which were studied, each with
strengths and weaknesses, which are the Boe-Bot’s open PCB and dynamic structure and the
software of the Mindstorm robot. Both have one large weakness, the ability to go beyond what
they were initially designed for. A robot kit that can teach a beginner in engineering, and still
prove to be useful for learning to a senior in college, is what the department needs. To do this a
decision was made to build two different kits: one, a basic kit using single board processing, and
two, an advanced kit using distributed processing and other advanced topics learned in upper
division courses in the electrical and computer engineering department.
Because of the breadth and ambiguity of this project, it is impractical to
accomplish with only two semesters of senior design. To accommodate for this, a preliminary
plan for future development in software, hardware, Smart Sensors using IEEE 1451
standardization, documentation, and testing work was developed. The list is only meant to give a
starting point and direction to future senior design groups. By using the knowledge given in this
1
report, and doing further development in the areas listed, a robot kit, meeting all the requirements
and more, can and will become a realization.
Introduction
The Electrical and Computer Engineering department would like a robot kit that is
affordable and extremely user friendly. The robot kit will help teach students, from high school
through college, about robotic engineering practices. The department needs a robot kit to stay
competitive as a college. As of now, the majority of the robotic kits available to purchase
through manufacturers or online are either limited in usefulness or are too expensive. It is
difficult to find a robot kit suited to the needs of a class learning environment in the ways the
department of electrical and computer engineering professors would like. Also, many colleges
and universities already have built robot kits which they use for learning.
Current marketed robotics kits have many limitations. There are few robot kits geared
for both novice and advanced users. A new engineering student needs to focus on concepts such
as linear motion and Ohm’s Law while more advanced students will need to focus on areas like
distributed processing, control systems, fluid dynamics, and artificial intelligence. A robot kit,
both easy to use out of the box, but has the complexity for more advanced use, is needed.
Studying the field of robotics can teach engineering students a large variety of lessons
from gear ratios to circuits, electromagnetic to fluid dynamics. Research shows that students
learn much more than technology when taking part in these sorts of activities. Using robotics in
class has been shown to increase a student’s tendency to ask questions and share ideas with
others. (Eija, 2006, p 2) Increasing retention and quality of students will increase the
department’s prestige and image in the professional world.
2
In order to develop a new robot kit, there must be consideration to both the mechanical
and electrical/computer aspects. This paper will focus on the electrical/computer interface and
mechanical structure of the robot kit to create an autonomous robot. It will also plan for further
development, and give some details on these areas. In order to perform autonomous tasks many
sensors, servos, actuators and motors must be used. The robot kit needs to provide such sensors,
motors, actuators, servos, and mechanical parts, but also have the ability to use others which are
not included in the kit. Using the IEEE 1451 standard will increase the dynamic and
upgradeability of the robot. This standard will be introduced but not discussed in detail.
There are many important features to consider when choosing a microprocessor. One
such example is pulse width modulation (PWM), used for controlling servo motors and DC
motor speed control, among other things. Other networking options must also be considered
such as Inter-Integrated Circuit (I2C), a multi-master serial computer bus used to attach lowspeed components to embedded systems. (I2C, February 2008) In order to perform distributed
processing, a master controller will use I2C to talk to other slave controllers on the robot. Some
sort of wireless networking function must also be considered to provide the robot the ability to
talk to other robots and act in a community of robots to accomplish more complex tasks.
Examples of wireless connectivity are Wi-Fi, Bluetooth, RF etc.
Developing software for human interface is also important. For novice users a Graphic
User Interface (GUI) needs to be developed to provide easy to understand programming. This
could provide the user the option of using pictures and arrows to create closed loop controls.
The robot must also program using text based code such as BASIC, C, or C++. Also, an array of
mechanical parts and materials need to be developed to be used for whatever task the user
3
decides. Things like gears, arms, bars, plates, and other mechanical structures will be developed.
Some of these parts have already been fabricated for a proof of concept on the mechanical side.
Problem Definition
The goal of the Open Architecture Robot senior design team is to design and produce an
affordable robotics kit that allows not only college students, but also high school students to
learn the fundamentals through more advanced techniques of robotic, electrical, mechanical, and
computer engineering. The kit will be reprogrammable and versatile in order to accommodate
many different educational lessons. Building a kit that is both very easy to use, as well as being
very comprehensive and involved, is one of the most important tasks. There must be well
defined manuals and help guides to create basic robots from the kit, as well as leaving the door
open to further development and design by the user.
4
Current Mechanical Design
Figure 1: First Year Assembly
The first year design of the Open Architecture Robot, seen in Figure 1, functions as a
catapult device for small round objects such as racquetballs or bouncy balls. The design includes
a self-reloading assembly that releases the catapult arm with a linear actuator and winds it back
into position with a simple rotary motor. A closer look at the catapult arm and re-loader can be
seen in Figure 2.
5
Winding
Motor
Linear
Actuator
Catapult
Arm
Reloader
Assembly
Figure 2: Catapult Assembly
The design of the mechanical assembly is comprised of several basic part designs that
include polycarbonate plastic plates, square aluminum bars, mounting brackets, and various
mechanical devices such as motors, gear sets, and springs. The final assembly can be seen in
Figure 1 above (Note: the battery pack and electronics are not pictured. The individual parts
making up the structure in Figure 1 are listed below. The final drawing package for all of the
manufactured parts is provided in the Appendix.
A. Plates
The polycarbonate plastic plates are ¼ inch thick and range in size to include 2x2, 2x4,
and 5x7 inches. The holes are standard #8 diameter, ½ inch apart and ½ inch from each edge.
6
The main 5x7 plate, seen in Figure 3, is used as the main backboard to mount the electronics,
battery pack, main catapult assembly, and re-loader assembly. The two smaller sized plates are
used in the re-loader assembly.
Figure 3: 5x7 inch Plate
B. Bars
The bars are made of ½ inch square aluminum and run in lengths of 2.5, 4.5, 6.5, and 8.5
inches as seen in Figure 4. The ends have one-inch-deep tapped holes, while the sides have
tapped holes through the entire bar spaced one inch apart and starting ¼ inch from the end or ¾
inch from the end. The holes are sized to fit standard #8 course thread bolts in order to use Allen
head bolts in the assembly. By using Allen head bolts with other fasteners such as nuts, the kit
can include a small Allen wrench so that no extra tools are needed for assembly. These fasteners
will work for the short term; however, nuts are difficult to maneuver in tight spaces and present a
need for a snap fit to make quick and easy connection. These snap fittings will have to be made
by a second iteration team.
7
Figure 4: 6.5-inch Bar
C. Brackets
The kit uses standard sized “L” brackets that are purchased from any hardware store or
online parts database. For flat connections in the assembly, the kit also includes two sizes of
machined flat brackets made from 1/16-inch thick aluminum as seen in Figure 5. One bracket
has three holes, ½ inch apart and ¼ inch from the ends and sides of the bracket. The second
bracket has five holes spaced ½ inch apart from center to center and ¼ inch from the sides and
ends.
Figure 5: 5-Hole Flat Bracket
8
D. Wheels
This year’s kit uses the 4-inch wheels taken from a remote control car in order to simplify
the design. The wheels are driven by one electrical motor and steered by a second motor. The
system is similar to a common automobile. These wheels give us a pre-designed platform to the
show the ability of the open architecture to be integrated with an outside system.
Current Electrical Design
A. Overview
The current electrical design of the robot uses a central processing scheme. This means
that all sensors, motors/actuators, input/output (I/O) devices, and memory are all directly
controlled by one single processor. Figure 6 shows a picture of the robot kit being used, known
as the Boe-Bot, which is not the senior design team’s design; however was used for the
development of the sensor board. It is also being used as a learning tool to further understand
developing a new robot kit.
Figure 6: Picture of the Boe-Bot robot (Boe-Bot, 2008)
9
B. Sensors
The current design uses infrared (IR) as its main sensor. Figure 7, seen below, shows the
infrared sensor board designed for the robot. It consists of four CNY70 IR sensor/transmitter
units, each house transmitter and a receiver: the IR emitter diode, and the IR photo-transistor,
respectively. While these sensors can distinguish small distances, this board is set up to only
differentiate between black and white. A signal inverter, which acts as an analog to digital
converter, transmits the signal to the microprocessor. In this way, the robot can follow a black
line made from electrical tape placed on a white or light colored surface.
Figure 7: IR sensor board for the Robot.
The sensor board mounts underneath the robot in Figure 6 using the mounting posts seen
in Figure 7, with the intention to get the IR sensor within a few millimeters of the surface of the
tape. If the sensors are not close enough to the tape and the white surface it is applied to, the
sensors will not distinguish between white and black. In fact, the sensors will always read as if
they were seeing black, indicated by a logical zero output to the microprocessor.
10
Using four of the IR sensors gives the robot the ability to manage intersections in the
black line. The board uses the sensors in pairs, the inner two and the outer two. The inner pair is
aligned to have a distance between them less than the width of the tape. So, when the robot goes
straight and the black line underneath does not curve away, both of the inner sensors will see
black. Once the black line curves one direction or the other, one of the sensors will then pass
over the black line onto the white surface. The sensor, now no longer over the black line, will
send a digital-1 to the microprocessor through the signal inverter, which will then correct the
trajectory of the robot, keeping the two inner sensors over the black line. In essence, the inner
sensors want to see black, and will send an “alter course” signal to the processor, telling the
robot to correct its trajectory. Using the inner pair of sensors, in this way, is the most basic and
straight forward approach to programming the robot to follow a black line autonomously.
The outer pair of sensors works in much the same way as the inner pair, just opposite.
These sensors are aligned to have a distance between them some distance greater than the width
of the tape. So, each outer sensor, keeping with the analogy from before, wants to see white
instead of black. So, instead of correcting course when the sensors see white, the robot will
correct its course when the two outer sensors see black. The code for following a line using the
outer two sensors is almost as simple as the inner sensors.
There is, however, one catch to using the outer sensors without the assistance of the inner
sensors. In practice, the robot can successfully follow a straight black line with no intersections
only using the outer pair. But, as Figure 8 shows, if the robot encounters an intersection while
using only the outer sensors it will see black on both sensors and will not be able to navigate
through it without the robot making some sort of assumption. Using only the inner sensors when
11
an intersection is arrived upon causes a different problem. The inner sensors might not even
realize an intersection passed, making the robot unable to make a turn if it needed to.
Figure 8: Black line intersection and sensor orientation.
Using both pairs of sensors give the robot an upper hand when dealing with intersections.
By using Boolean algebra, a binary equation, seen in Equation 1, was developed to tell the robot
exactly when it encountered an intersection. From left to right, the sensors were given the names
A, B, C, and D. When A detects white, a logical 1 is written, denoted as ‘A’. When A sees
black a logical-0 is written, denoted as ‘~A’, or ‘A-not’. The same method was also used for B,
C, and D. Equation 1, along with the outputs from each sensor, indicates to the robot it has
encountered an intersection.
  
B C A  D


1
(Equation 1)
Once the robot has detected an intersection, the next step is simply deciding which way to turn.
Each intersection will need to be programmed into the robot specifically which way to turn if the
user has a specific course the robot should take. More advanced programming methods can be
12
used to further automate the processor. However, this particular robot has limited memory
making more advanced programs to accomplish such a task out of reach.
C. Memory
The microprocessor on the Boe-Bot has a meager 2 Kilo-bytes of memory and 32 bytes
of random access memory (RAM). This is just enough memory to allow for 6 I/O’s with 26
variables (meaning 26 I/O pins), and a program size with about 500 instructions (BASIC, 2008).
Five-hundred instructions may seem like a lot, but the number of instructions it takes just to
follow a line and navigate an intersection can use 50 or more instructions. Furthermore,
variations in the code can greatly vary the number of commands used. Also, only having 26 I/O
pins does not allow for many interfaces to be applied to the robot such as sensors and actuators.
D. Motors/Actuators
The Boe-Bot consists of two continuous motion servo motors. Based on a PWM, as seen
in Figure 9, the servo motors will increase, or decrease, their rotational velocity.
Figure 9: A square wave pulse width (Pulse-width, 2008)
13
This uses a square wave with a pulse width of D.T and period T. One cycle of an entire pulse
width signal is from 0 to T, then from T to 2T, then 2T to 3T, and so on. As the value of D.T
increases, the average value under the curve also increases. The servo motor knows how fast to
spin its rotor based on this information. The larger the pulse width, the faster the motor spins;
the smaller the pulse width, the slower it will spin. By using a continuous servo motor, there is
no need for DC motor controllers, which would perform the same speed control but for DC
motor. When dealing with small sized robots where low torque motors are practical, continuous
servo motors are an easy way to have a variable speed, continuous motion motor, because the
speed control is taken care of entirely by the continuous servo motor.
E. User Programming Interface
The Boe-Bot uses two types of interfaces, either a USB connection or a serial connection,
both of which are very quick and easy to use with the Boe-Bot (Boe-Bot, 2008). The program
for the robot downloads using a USB or serial connection and then stores it in memory. The
ability to program the processor using a USB connection does have one significant advantage.
Many of today’s computers, such as laptops and even desktops, do not have serial ports anymore,
but, have a plethora of USB ports available. Because of this, the ability to program the robot
using a USB connection greatly increases the usability of the robot kit.
F. Power Sources
The Boe-Bot uses a very simple AA battery pack for its energy. By using six AA
batteries in series, a voltage of 9-volts can be attained, with a 400-900 milliamp-hour capacity.
However, the BASIC processor needs an input power voltage of around 5-volts. In order to
14
convert the 9V power from the batteries to the 5V needed by the processor, a BUCK converter is
used. This does a DC to DC conversion, switching the 9V source from the battery, to 5V source
used by the processor. By using a higher voltage source, more energy can be stored for the
robot. And, by using BUCK converters, this energy is then easily converted to something usable
by the processor.
G. Wrap Up
The initial plans of this project were to build a robot kit from scratch; however, by
studying the Boe-Bot, many areas of interest became much more apparent. By first
understanding a well designed robot kit, the practicality of designing a new and improved robot
kit with a wider range of use became an even more practical and attainable goal. The next step is
moving from the central based processing platform, such as the Boe-Bot, into a distributed
processing network. From here the dynamic and upgradeable aspect of the robot kit will start to
become more of a realization than an idea.
Future Work
A. Overview
What was accomplished during this year’s design project consisted mostly of intellectual
progress. Working with, and studying, the Boe-Bot and other robot kits gave much insight into
the areas needed for further development. Using this knowledge, a preliminary plan was
developed. One of the main goals of this robot kit was to provide a product with an extremely
versatile and upgradable nature. Because of this, two different architectures in the electronic
layout have been decided upon.
15
1. Basic Kit
The basic kit will provide an easy to understand robotic design. When considering the
electrical design, this kit will focus on elementary electrical and computer engineering
practices. Concepts such as Ohms law, and circuit analysis, closed loop control, and
elementary coding are some of the skills the basic kit will cultivate. It will use single board
processing, GUI and/or easy code for programming, simple sensors and actuators, and limited
memory. Classes like Circuits I, and II, C++, and other introduction to engineering and/or
computer science courses will use this kit for the student to gain practical experience.
2. Advanced Kit
The advanced kit will begin to uncover more complicated concepts by building on the
knowledge the basic kit helped to develop. It will use, but will not be limited to, distributed
processing, advanced coding, smart sensors using the IEEE1451 standardization, actuators, and
as much memory as needed. This robot kit will provide the ability to develop smarter and
more human like robots. By providing a basic architecture to build from, many different
microprocessors with a wide range of processing power can be used. In this way, the
processing power of the robot will grow as technology continues to advance. In the end, the
advanced kit will provide the building blocks for the robot while the engineer provides the
innovation to put it all together.
Both kits have certain areas needing further development when dealing with the
electrical and computer aspect such as: software, hardware, Smart Sensors using IEEE 1451
standardization, documentation, and testing. The two types of kits stated above are effectively
16
the same; the advanced kit simply expands on what the basic kit offers. Because of this,
development in most of these areas will overlap for both kits.
B. Areas of Development
1. Software
Both the advance and basic robot kits will have a software bundle. The Lego
Mindstorm, a robot kit which will be similar to the basic kit’s design, uses software with a GUI
interface. By dragging pictures and connecting them with arrows, closed loop controls can be
made. Figure 10 shows an example flow diagram a user can create to program the Lego
Mindstorm. Using pictures which have a certain meaning, and linking them together, a series
of control loops are made. For example, one picture can represent a specific sensor, and
another picture can represent wheels. By putting them together and specifying the action taken
based on what the sensor see, the robot will move forward or stop. This type of programming
is done with the GUI, and not with written code, and is much easier for novice users to begin
learning the basics of robot control.
17
Figure 10: Lego Mindstorm Programming Software (Mindstorm)
In the same way, the software developed for the basic kit will use a GUI interface along with
flow diagrams, creating closed loop controls, to program the robot.
For the advanced kit, one main difference stands out: instead of using GUI as the only
means of programming the robot, written code will also take place. Depending on how the
user wants to program his or her robot, a combination of picture blocks and flow diagrams can,
along with written code, take place. The user could even create picture blocks from scratch or
alter existing ones, which the Mindstorm robot kit does not allow, and is one of its main
limitations. The Mindstorm kit only has a given set of picture blocks to build from which
cannot be altered. However, at some point the creators of the software for the Mindstorm robot
coded what each block represented, and how the robot will act at each block. By taking this
idea, and allowing the user to become the creator of the picture blocks, it will enhance the
overall goal of the robot kit: to be as expandable and dynamic as possible.
18
2. Hardware
The robot’s hardware needs to have the same dynamic properties of the software, if not
more so. Other than sensors, actuators, and motors, the main difference between the basic and
advanced kit is seen in the processing. The basic processor will only consist of one
microprocessor, which will control all appendages of the robot. Figure 11 shows the
information path the layout of the basic kit.
Figure 11: Single Board Processing Block Diagram
All information will flow in and out of this processor or microcontroller unit (MCU) as
depicted in Figure 11. The Boe-Bot is a perfect example of what the basic kit’s single board
processing layout will look like for the following reasons.
19

The microprocessor is very small, simple, and easy to use.

It has the ability to drive servo motors, small DC motors, actuators, and receive
both analog and digital signals from sensors, essential to building a basic robot.

It has an onboard breadboard (seen in Figure 6) used to create simple circuits for,
LED’s, sensors, transducer etc.

It has an open printed circuit board (PCB) layout (also seen in Figure 6) so users
can see and understand the layout and follow traces.
All of these areas which Boe-Bot excels (as far as the electrical/computer aspects are
concerned) will fuse into the design for the basic and advanced robot kit. The basic kit will
feature the microprocessor, and PCB layout seen in Figure 12. This layout uses the
Atmega168, an 8-bit microprocessor. The following list includes some of the features the
board and microprocessor have:
 131 Instructions per cycle
 32x8 general purpose working registers
 Up to 512 Bytes of EEPROM
 16KBytes Internal SRAM
 6 PWM Channels
 Master/Slave SPI Serial Interface
 23 Programmable I/O Lines
 USB Interface
 1.8 – 5.5V Power
 10-bit A/D-Converter
(Atmel, 2008)
20
Figure 12: Arduino NG (Arduino, 2008)
This microprocessor and PCB layout have the necessary options available to use in the
basic robot kit. It is compact, and easy to understand. It also uses an open source design so
there is no need to worry about copyright violations. The ATmega168 on the Arduino
Diecimila comes pre-burned with a boot loader which allows the board to be uploaded with
code without using an external hardware programmer. It communicates using the original
STK500 protocol and is also possible to bypass the boot loader and program through the InCircuit Serial Programming (ICSP) header. This board can also be used as a target board for
an RTOS (Real Time Operating System). It could be the processor of many embedded
systems.
One final positive mark of this microprocessor is its ability to program using a wide
range of languages, the most important of which is BASIC. For novice users who have little to
no coding experience, BASIC is one of the most straight forward coding languages. One of the
21
stipulations, by lead professor Dr. Law, on the electrical/computer design, was for the basic kit
to have the ability to program using BASIC.
The advanced kit takes the basic kit and expands on it. The main difference between
the two kits is distributed processing as seen in Figure 13. Distributed processing is more
difficult and involved to develop. It requires networking and a Master-Slave environment. A
slave controller will control each sensor and actuator, which will communicate to the master
controller via a network such as I2C, or CAN.
Figure 13: Distributed Processing Block Diagram
The central, master processor will have a much larger range of processing power. Its
microprocessor will be the Samsung S3C2410A with the ARM920T core on the EM104v1
PC/104 single computer board (SBC), seen in Figure 14, or something similar to it.
22
Figure 14: EM104V1 PC/104 Single Board Computer (EM104V1 PC, 2008)
This ARM processor core, when compared to the Atmega168, is exceptionally
powerful. Using this processor, along with the SBC layout, enables the use of OS’s like Linux,
and some versions of Windows. Some key features of this setup are:
 200MHz CPU speed
 63Mbytes SDRAM
 64MByte Nand Flash
 128Kbye SRAM
 3 RS232 serial ports
 4 PWM channels
 4 ADC
 2 channel CAN bus
 2 channel SPI
 2 10/100M Ethernet interface
 I2C bus
 LCD support
 Keyboard support
 40 programmable I/O pins
(EM104V1 PC, 2008)
23
This list shows that the SBC does not lack in processing power and connectivity. This
ensures the master processor has all the resources it needs to handle a wide range of tasks the
advanced user can throw at it. The SBC has an I2C bus, which the network of slaves and mater
processors will use to communicate. In the advanced kit, the Arduino board used in the basic
kit will become the slave processor in most cases, unless a more powerful slave processor is
needed. Many different types of processors can communicate on the I2C bus. This leaves the
electrical architecture open and upgradeable.
There are many mechanical parts that need to be made for a full robotics kit with
enough complexity for college curriculum. For any new part, the array of holes should be
followed like the plates that have already been made (which were shown above in the current
design section). Using a similar hole pattern will give the users the choice to attach the parts
where they want. Some of the more critical parts that need to be designed are the motor mounts
and connections.
The connections are the most important part of the robot’s mechanical design. The
simpler the connection is, the faster a new idea can be made and attached on the robot’s
mechanical frame. Using spring-loaded fasteners, similar to a telescoping boar gage, would
make connections simpler than any threaded fastener. A spring-loaded fastener would have a
distinct advantage over a bolt in small areas, because the user would not have to find a way to
hold the bolt in place while a nut is tightened onto it.
3. IEEE 1451 Standard
The IEEE 1451 standard is currently under development for what is known as “smart
sensors”. In a way, this is another aspect of distributed processing. A transducer or sensor of
24
some kind will directly connect to a microcontroller which will then communicate using
network-independent interfaces. IEEE 1451 eliminates the need to create custom protocols for
sensors in different contexts. (Lee, 2005) Much like many USB devices are plug-and-play, a
smart sensor using the IEEE 1451 interface will be a sort of plug-and-play. This will enhance
the dynamic properties of the robot kit, and increase the ease of developing different robots
using many different parts and sensors. There will no longer be any need to specifically code
each sensor into the software. The smart transducer contains all of the necessary information
to describe itself to the control software, which will then automatically determine what the
sensor is, how it works, what kind of information it will transmit, and how to interpret that
information. (Lee, 2005)
4. Documentation
Documentation is important throughout the development of the robot kit for many
reasons. This report, along with a binder of notes, and other documentation will be passed on
to next year’s senior design team.
The other side of documentation is for the users. There is need for documentation on
the hardware and software. Educational manuals need to be written for the users to learn how
the robot kit is put together. Troubleshooting documentation must also be written for the user
to debug the program he or she wrote and find problems with the code or hardware. The BoeBot contained an educational manual which went step by step through the building process of a
simple robot and how to use the sensors, servo motors, and other peripherals. This book
started at a very simple level, then keeps building on previous ideas, expanding the skills of the
25
user. This same technique will be used for both kits, but specifically the basic kit. Text books
for both will need to be written starting at the most simple elements, expanding until the user
has the necessary skills required to innovate new and original ideas. The documentation must
be written in with learning mechanical, electrical, computer, and software engineering in mind.
There will also be a website with all of the above documentation for the user, and more.
Sources will be given so the user can see other technologies the user may want to apply to the
robot kit. There will be links to online stores to purchase extra parts. Discussion boards and
blogs will be made available so users can communicate and talk about their designs, ask
questions, and build off of each others ideas.
Because all of the parts and peripherals of the robot will be interchangeable, the
intellectual information given in the documentation created for the robot will be an important
aspect. In effect, the documentation for the robot kit will be a living text. It will change and
evolve with technology.
5. Testing
Testing will also take place throughout development of the robot kit. However, final
testing will take place close to the end of development. In order to properly test this product, it
will need to be used in the environment it was designed for, the classroom. The department
professors will use the basic robot kit in their introduction to engineering courses. In this
environment the professors will be able to see the strengths and weaknesses of the robot kit.
They will determine where improvements need to be made on all aspects of the robot kit,
especially the educational documentation. The advanced kit will be tested with advanced
26
courses of engineering, where the student’s thoughts and opinions will most likely be as
valuable as the professor’s.
The testing of this product is an area needing more thought and consideration. When
nearing the final production of this robot kit, the senior design student’s working on the robot
kit will need to consider, in depth, the correct, and most exhaustive, procedure to test this
product. Even after release of a final product, there will still be many aspects of the robot kit
needing fine tuning and correction. For this reason, testing and development will be an
ongoing process as long as the robot kit, both basic and advanced, are used.
Conclusion
This project is a start in developing an open architecture robot unique to the University of
Idaho’s Electrical and Computer Engineering department. The Boe-Bot by Parallax and the
Mindstorm by Lego’s, are two basic robot kits which were studied, each has strengths and
weaknesses. A sensor board and some mechanical parts were designed by the senior design
team. The mechanical parts were designed with the open architecture concept in mind, creating
“Lego” like parts. Using the research done during the year, a preliminary plan with areas of
development for future design team was listed. By using following the plan given in this report,
and doing further development in the areas listed, a robot kit, meeting all the requirements and
more, can and will become a realization.
27
References
Arduino. In Arduino, Retrieved 7:17PM, April 23, 2008 from http://www.arduino.cc/
Atmega168, in Atmel, Retrived 7:40PM, April 23, 2008 from
http://www.atmel.com/dyn/products/product_card.asp?part_id=3303
BASIC Stamp 2 Module. In Parallax INC, Retrieved 11:35AM, April 3, 2008 from
http://www.parallax.com/Store/Microcontrollers/BASICStampModules/tabid/134/Catego
ryID/9/List/0/SortField/0/Level/a/ProductID/1/Default.aspx
Boe-Bot Robot Kit. In Parallax INC, Retrieved 12:03PM, April 3, 2008 from
http://www.parallax.com/Store/Robots/RollingRobots/tabid/128/CategoryID/3/List/0/Sort
Field/0/Level/a/ProductID/296/Default.aspx
Dr. Law. (2008, Januray 27). Professor of Electrical Engineering, University of Idaho, Interview.
Dr. Wall. (2008, February 8). Professor of Electrical Engineering, University of Idaho.
Interview.
Eija Karna-Lin, Kaisa Pihlainen-Bednarik, Erkki Suitnen, and marjo VirnesCan (2006). Robots
Teach? Preliminary Results on Educational Robotics in Special Education.
Page. Retrieved March 3, 2008 from
http://ieeexplore.ieee.org/iel5/10997/34637/01652433.pdf?isnumber=34637&prod=CNF
&arnumber=1652433&arSt=+319&ared=+321&arAuthor=+KarnaLin%2C+E.%3B++PihlainenBednarik%2C+K.%3B++Sutinen%2C+E.%3B++Virnes%2C+M
EM104V1 PC/104, in Embest, Retrived 8:58PM, April 23, 2008 from
http://www.armkits.com/product/em104v1.asp
I2C. (February 23,2008). In Wikipedia, The Free Encyclopedia. Retrieved 20:41, March 5, 2008
from http://en.wikipedia.org/wiki/I%C2%B2C
Lee, Kang (June 7, 2005). Synopsis of IEEE 1451, Sensors Conference/Expo 2005. Chicago, IL.
Mindstorm Robot Kit. In Lego, Retrieved 4:18PM, April 23, 2008 from http://www.lego.com/enUS/default.aspx
28
Pulse-width modulation (April 1, 2008). In Wikipedia, The Free Encyclopedia. Retrieved
11:55AM, April 3, 2008 from http://en.wikipedia.org/wiki/Pulse-width_modulation
29
Appendix A
Example code explanations. Code listings.
This first code is a simple example on how to read the port that the sensor board writes.
#include <inttypes.h>
#include <avr/pgmspace.h>
int main(void){
DDRD = 0xf0;
// Configuration of port D
// f = output, 0 = input
PORTD |= (1<<0);
// Set pull-up resistor
while (1){
if( !(PIND & 0x01) | 0x00 ){
}
else{
}
}
// Read PORTD pin 0
PORTD = 0xF0;
// If sensor sees black
//Set high nibble of PORTD high
PORTD = 0x00;
// If sensor sees white
//Set low nibble of PORTD low
}
// END main
Listing 1: Program that uses the O.A.R. sensor board.
The next few listings belong to a program that creates a rough approximation to the song “Smoke
on the Water“. The tones are created using interruptions. Note that the microcontroller can only
generate a square signal, thus the sound it is far from being pure.
A1
/* Some
#define
#define
#define
#define
definitions to make life easier
SETUPNIB
PORTB |= (1<<7) | (1<<6) | (1<<5) | (1<<4);
RESETUPNIB
PORTB |= (0<<7) | (0<<6) | (0<<5) | (0<<4);
RESETLOWNIB
PORTB |= (0<<3) | (0<<2) | (0<<1) | (0<<0);
INVERTPORTD
PORTD = ~PORTD;
*/
/* Necessary includes
#include <avr/io.h>
#include <avr/interrupt.h>
#include <inttypes.h>
#include <avr/pgmspace.h>
*/
/* Global variables
uint8_t count;
uint8_t tone;
uint8_t timeout;
int ticks;
*/
/* Delay function that create a 1 ms delay. It is optimized for a 16 Mhz clock
* clock cycle. Do not forget that it is only a software delay function
void delay_ms(void){
int i;
for(i=880u; i != 0; i--);
}
/* Function to create bigger delays. Uses delay_ms as the basic function
void delay(uint8_t tms){
uint8_t i;
for(i = tms; i != 0; i--){
delay_ms();
}
}
*/
*/
Listing 2: Software delay functions.
The next code is part of the “music” generator program. In this part both, timer 1
and timer 0 are configured. Timer 0 will interrupt when an overflow of the count happens. Timer
1, however, will interrupt when the value of the count corresponds with the value in OCR1A.
Timer 1 is programmed to Clear Timer on Compare (CTC). Timer 0 is programmed to in the
common way and the clock is slowed down by an amount of 1024.
A2
void iniconf(void){
cli();
// Disable interrupts
/* Program timer0
*/
TCNT0 = 0x00;
// Reset timer count
TCCR0A |= 0x00;
// Normal functioning, clk_io/1024
TCCR0B |= 0x05;
TIMSK0 |= _BV(TOIE0); // Enable interrupts when overflow
/* Program timer1
*/
TCNT1H = 0x00;
// Reset timer count
TCNT1L = 0x00;
OCR1AH = 0x01;
// Set output compare value
OCR1AL = 0xFF;
TCCR1A |= 0x00;
// Clear timer on compare CTC, clk_io
TCCR1B |= 0x09;
TIMSK1 |= _BV(OCIE1A); // Enable interrupts when overflow
sei();
// Enable interrupts
/* Program the ports
DDRB = 0xff;
DDRC = 0x01;
DDRD = 0xff;
*/
// PortB as output port
// PortC0 for wave output
}
Listing 3: System, interrupts and ports initialization example code.
The next piece of code is a simple example of how a main function ought to be. It calls
the initialization function, later it initializes the global variables, that could also be initialized in
iniconf(), and it has the loop while(1){...}.
int main(void){
/* Initialize the system
iniconf();
*/
/* Initialize goblal variables
count = 0;
ticks = 0;
tone = 0;
}
*/
while(1){
delay(50);
PORTB = (PORTB & 0x0f) | 0xf0; //SETUPNIB;
delay(50);
PORTB = (PORTB & 0x0f);
//RESETUPNIB;
}
Listing 4: Main function example.
The next listing shows what the Interrupt Service Routine (ISR) does when it is called,
i.e. when the interrupt occurs. The word ISR is a macro defined in the avr-gcc compiler. What is
found within parenthesis is the interrupt vector.
A3
ISR(TIMER0_OVF_vect){
cli();
//
count--;
if (ticks == 11){
//
ticks = 0;
if (count == 0x00){
RESETLOWNIB;
count = 0x0f;
}
else{
PORTB = (PORTB & 0xf0) |
}
tone++;
tone = tone % 32;
//
}
else{
ticks++;
}
sei();
}
Disable interrupts to avoid share data problems
Check if a second (or around) has passed
(count & 0x0f);
Tone will go from 0 to 32 to select next sound
Listing 5: Code for a Timer 0 configuration example.
The last code listing shows the timer 1 ISR. Depending on the “tone” selected by the
timer 0 ISR this code will generate one tone or another one. The program inverts the value of the
port D output at the correct frequency.
The song tones are as follows:
0
1
2
3
4
E
| F
|
G
8
9 10 11 12 13 14 15 Tone
E = 329.6 Hz
E
| F
| Bar 2
F = 349.24 Hz
16 17 18 19 20 21 22 23 Tone
G = 392.00 Hz
E
| F
| G#
|
G
5
6
7 Tone
| G
| Bar 1
| G
| G
| Bar 3
G# = 415.32 Hz
24 25 26 27 28 29 30 31 Tone
F
| E
|
E
| E
| Bar 4
Table 1: Smoke on the Water and tone frequencies.
fclk_io = 16 Mhz;
OCR1A = 512;
Te = 31250 / 329.6 Hz = 94.81;
Etck = 94.81 / 2 = 47.4 => 47;
finterrupt = 31250 Hz;
We need tck = 47 in order to create a square signal with a frequency of 329.6 Hz.
There is an error after rounding. The final tone frequency is 31250 * 47 * 2 = 332.45 Hz.
A4
ISR(TIMER1_COMPA_vect){
static uint8_t tck = 0;
cli();
//the following code works as a multiplexer
if (tone == 0 | tone == 8 | tone == 16 | tone > 26){
// to choose the right signal in Hz
if(tck == 47){
tck = 0;
// reset count to create a signal in Hz
INVERTPORTD;
// create a square signal
}
else{
tck++;
// increment the count
}
}
else if(tone == 2 | tone == 10 | tone == 18 | tone == 24){
// to choose Hz
if(tck == 45){
tck = 0;
INVERTPORTD;
}
else{
tck++;
}
}
else if(tone == 4 | tone == 5| tone == 6 | tone == 14 | tone == 20 | tone == 22){
// Hz
if(tck == 39){
tck = 0;
INVERTPORTD;
}
else{
tck++;
}
}
else if(tone == 12){
// Hz
if(tck == 38){
tck = 0;
INVERTPORTD;
}
else{
tck++;
}
}
else if(tone % 2 != 0 && tone != 5){ //odd = silence
PORTD = 0x00;//Silence
}
else{
//In case for error reset tone
tone = 0;
// make sure we have it within its limits
tck = 0;
// avoid overflow if error
}
sei();
}
Listing 6: Timer 1 configuration example for creation of music tones
A5
#define
#define
#define
#define
#include
#include
#include
#include
SETUPNIB
RESETUPNIB
RESETLOWNIB
INVERTPORTD
PORTB |= (1<<7) | (1<<6) | (1<<5) | (1<<4);
PORTB |= (0<<7) | (0<<6) | (0<<5) | (0<<4);
PORTB |= (0<<3) | (0<<2) | (0<<1) | (0<<0);
PORTD = ~PORTD;
<avr/io.h>
<avr/interrupt.h>
<inttypes.h>
<avr/pgmspace.h>
uint8_t count;
uint8_t tone;
uint8_t timeout;
int ticks;
void delay_ms(void){
int i;
for(i=880u; i != 0; i--);
}
void delay(uint8_t tms){
uint8_t i;
for(i = tms; i != 0; i--){
delay_ms();
}
}
ISR(TIMER1_COMPA_vect){
static uint8_t tck = 0;
cli();
//the following code works as a multiplexer
if (tone == 0 | tone == 8 | tone == 16 | tone > 26){
// to choose Hz singal
if(tck == 47){
tck = 0;
// reset count to create a 277 Hz signal
INVERTPORTD;
// create a squeare signal
}
else{
tck++;
// increment the count
}
}
else if(tone == 2 | tone == 10 | tone == 18 | tone == 24){
// to choose Hz
if(tck == 45){
tck = 0;
INVERTPORTD;
}
else{
tck++;
}
}
else if(tone == 4 | tone == 5| tone == 6 | tone == 14 | tone == 20 | tone == 22){
// Hz
if(tck == 39){
tck = 0;
INVERTPORTD;
}
else{
tck++;
}
}
else if(tone == 12){
// Hz
if(tck == 38){
tck = 0;
INVERTPORTD;
}
else{
tck++;
}
}
else if(tone % 2 != 0 && tone != 5){ //odd = silence
PORTD = 0x00;//Silence
}
else{
//In case for error reset tone
tone = 0;
// make sure we have it within its limits
tck = 0;
// avoid overflow if error
}
A6
sei();
}
ISR(TIMER0_OVF_vect){
cli();
count--;
if (ticks == 11){
ticks = 0;
if (count == 0x00){
RESETLOWNIB;
count = 0x0f;
}
else{
PORTB = (PORTB & 0xf0) | (count & 0x0f);
}
tone++;
tone = tone % 32;
// tone will go from 0 to 3
}
else{
ticks++;
}
sei();
}
void iniconf(void){
cli();
// Disable interrupts
/* Program timer0
*/
TCNT0 = 0x00;
// Reset timer count
TCCR0A |= 0x00;
// Normal functioning, clk_io/1024
TCCR0B |= 0x05;
TIMSK0 |= _BV(TOIE0); // Enable interrupts when overflow
/* Program timer1
*/
TCNT1H = 0x00;
// Reset timer count
TCNT1L = 0x00;
OCR1AH = 0x01;
// Set output compare value
OCR1AL = 0xFF;
TCCR1A |= 0x00;
// Normal functioning, clk_io
TCCR1B |= 0x09;
TIMSK1 |= _BV(OCIE1A); // Enable interrupts when overflow
sei();
// Enable interrupts
/* Program the ports
DDRB = 0xff;
DDRC = 0x01;
DDRD = 0xff;
*/
// PortB as output port
// PortC0 for wave output
}
int main(void){
/* Initialize the system
iniconf();
*/
/* Initialize goblal variables
count = 0;
ticks = 0;
tone = 0;
}
*/
while(1){
delay(50);
PORTB = (PORTB & 0x0f) | 0xf0; //SETUPNIB;
delay(50);
PORTB = (PORTB & 0x0f); //RESETUPNIB;
}
Listing 7: sound.c
The last code listed is a software digital servo motor control. Most of the code looks
exactly like the solution for generating the tones. The fact is that the servo motors that has been
A7
used for this project, need a frequency of 350 Hz, which is around the frequencies of the tones
used for the little piece of music generated.
Servo motors' speed depend on the duty cycle of the signal sent to them. The square
signals that the motors need have been implemented in software. In the code can be found:
if (turn == 0){
if(tck == 36){
tck = 0;
turn = 1;
INVERTPORTD;
}
else{
tck++;
}
}
else if(turn == 1){
if(tck == 54){
tck = 0;
INVERTPORTD;
turn = 0;
}
else{
tck++;
}
}
Drawing 1: Left: Listing of code to create the PWM signal.
Right: Oscilloscope signal of PORTD output.
turn == 0 implements the high level of the square signal and turn == 1 implements the
low level of the square signal. By making tck equal for both cases we create a 50 % duty cycle
signal. By making tck different from one case to the other we achieve a signal with a duty cycle.
In this example the signal has a 36 / (36 + 54) * 100 = 40 % duty cycle.
Note that the Atmega168, the controller that has been selected for this design, has several
PWM (Pulse Width Modulation) outputs, that could, a priori, be used to control the servos.
A8
#define
#define
#define
#define
#define
#define
#define
#define
STOP_TIMER
START_TIMER
SETUP_TIMER1A
SETUP_TIMER1B
SETUPNIB
RESETUPNIB
RESETLOWNIB
INVERTPORTD
#include
#include
#include
#include
TCCR0 &= 0xF8;
TCCR0 |= 0x05;
TCCR1A |= 0x00;
TCCR1B |= 0x09;
PORTB |= (1<<7) | (1<<6) | (1<<5) | (1<<4);
PORTB |= (0<<7) | (0<<6) | (0<<5) | (0<<4);
PORTB |= (0<<3) | (0<<2) | (0<<1) | (0<<0);
PORTD = ~PORTD;
<avr/io.h>
<avr/interrupt.h>
<inttypes.h>
<avr/pgmspace.h>
uint8_t count;
uint8_t tone;
uint8_t timeout;
int ticks;
void delay_ms(void){
int i;
for(i=880u; i != 0; i--);
}
void delay(uint8_t tms){
uint8_t i;
for(i = tms; i != 0; i--){
delay_ms();
}
}
ISR(TIMER1_COMPA_vect){
static uint8_t tck = 0;
static uint8_t turn = 0;
}
cli();
//the following code works as a multiplexer
if (turn == 0){
if(tck == 36){
tck = 0;
turn = 1;
INVERTPORTD;
}
else{
tck++;
// increment the count
}
}
else if(turn == 1){
if(tck == 54){
tck = 0;
INVERTPORTD;
turn = 0;
}
else{
tck++;
}
}
else{
turn = 0;
tck = 0;
// avoid overflow if error
}
sei();
ISR(TIMER0_OVF_vect){
cli();
count--;
if (ticks == 11){
ticks = 0;
if (count == 0x00){
RESETLOWNIB;
count = 0x0f;
}
else{
PORTB = (PORTB & 0xf0) | (count & 0x0f);
}
}
else{
A9
ticks++;
}
sei();
}
void iniconf(void){
cli();
// Disable interrupts
/* Program timer0
*/
TCNT0 = 0x00;
// Reset timer count
TCCR0A |= 0x00;
// Normal functioning, clk_io/1024
TCCR0B |= 0x05;
TIMSK0 |= _BV(TOIE0); // Enable interrupts when overflow
/* Program timer1
*/
TCNT1H = 0x00;
// Reset timer count
TCNT1L = 0x00;
OCR1AH = 0x01;
// Set output compare value
OCR1AL = 0xFF;
TCCR1A |= 0x00;
// Normal functioning, clk_io
TCCR1B |= 0x09;
TIMSK1 |= _BV(OCIE1A); // Enable interrupts when overflow
}
sei();
// Enable interrupts
/* Program the ports
DDRB = 0xff;
DDRC = 0x01;
DDRD = 0xff;
*/
// PortB as output port
// PortC0 for wave output
int main(void){
/* Initialize the system
iniconf();
*/
/* Initialize goblal variables
count = 0;
ticks = 0;
tone = 0;
*/
while(1){
delay(50);
PORTB = (PORTB & 0x0f) | 0xf0; //SETUPNIB;
delay(50);
PORTB = (PORTB & 0x0f); //RESETUPNIB;
}
}
Listing 8: motor.c
A 10
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
LMB0
LMB1
RMB0
RMB1
LMF0
LMF1
RMF0
RMF1
INVERTPORTD
INVPD0
INVPC0
INVPC1
INVPD7
INVPD6
#include
#include
#include
#include
uint8_t
uint8_t
uint8_t
uint8_t
uint8_t
uint8_t
uint8_t
16
// This is
74
// This is
74
16
74
16
16
74
PORTD = ~PORTD;
PORTD = (~PORTD &
PORTD = (~PORTD &
PORTD = (~PORTD &
PORTD = (~PORTD &
PORTD = (~PORTD &
time high for Left Motor moving Backwards
time low for Left Motor moving Backwards
0x01)
0x01)
0x02)
0x80)
0x40)
|
|
|
|
|
(PORTD
(PORTD
(PORTD
(PORTD
(PORTD
&
&
&
&
&
0xfe);
0xfe);
0xfd);
0x7f);
0xbf);
// Invert port D pin 0
<avr/io.h>
<avr/interrupt.h>
<inttypes.h>
<avr/pgmspace.h>
timeout;
tone;
ticks;
dirhl;
dirll;
dirhr;
dirlr;
void delay_ms(void){
int i;
for(i=880u; i != 0; i--);
}
void delay(uint8_t tms){
uint8_t i;
for(i = tms; i != 0; i--){
delay_ms();
}
}
ISR(TIMER1_COMPA_vect){
static uint8_t tck = 0;
static uint8_t tck2 = 0;
static uint8_t turn = 0;
static uint8_t turn2 = 0;
//static uint8_t ticks = 0;
//static uint16_t sec = 0;
cli();
//the following code works as a multiplexer
if (turn == 0){
//time high
if(tck == dirhl){
tck = 0;
turn = 1;
INVPC0;
INVPD7;
}
else{
tck++;
// increment the count
}
if(tck2 == dirhr){
tck2 = 0;
turn2 = 1;
INVPC1;
INVPD6;
}
else{
tck2++;
// increment the count
}
}
else if(turn == 1){
if(tck == dirll){
tck = 0;
INVPC0;
//time low
A 11
}
else{
INVPD7;
turn = 0;
tck++;
}
if(tck2 == dirlr){
tck2 = 0;
INVPC1;
INVPD6;
turn2 = 0;
}
else{
tck2++;
}
}
else{
turn2 = 0;
tck2 = 0;
turn = 0;
tck = 0;
// avoid overflow if error
}
sei();
}
ISR(TIMER0_OVF_vect){
cli();
if (ticks == 11){
tone = ~tone;
//tone++;
//tone = tone % 2;
}
else{
ticks++;
}
sei();
// tone will go from 0 to 3
}
void iniconf(void){
cli();
// Disable interrupts
/* Program timer0
*/
TCNT0 = 0x00;
// Reset timer count
TCCR0A |= 0x00;
// Normal functioning, clk_io/1024
TCCR0B |= 0x05;
TIMSK0 |= _BV(TOIE0); // Enable interrupts when overflow
/* Program timer1
*/
TCNT1H = 0x00;
// Reset timer count
TCNT1L = 0x00;
OCR1AH = 0x01;
// Set output compare value
OCR1AL = 0xFF;
TCCR1A |= 0x00;
// Normal functioning, clk_io
TCCR1B |= 0x09;
TIMSK1 |= _BV(OCIE1A); // Enable interrupts when overflow
sei();
// Enable interrupts
/* Program the ports
DDRD = 0xf0;
DDRC = 0x03;
*/
}
int main(void){
/* Initialize the system
iniconf();
*/
/* Initialize goblal variables
tone = 0;
ticks = 0;
*/
while(1){
//delay(0);
//Check sensor
A 12
if( (PIND & 0x03) == 0x00 ){
//If both black, movr forward
dirhl = LMF0;
dirll = LMF1;
dirhr = RMF0;
dirlr = RMF1;
}
else if( (PIND & 0x03) == 0x02 ){
//if left white; turn right
dirhl = LMB0;
dirll = LMB1;
dirhr = RMB0;
dirlr = RMB1;
/*dirhl = LMB0;
dirll = LMB1;
dirhr = RMF0;
dirlr = RMF1;*/
}
else if( (PIND & 0x03) == 0x01 ){
//if right white; turn left
dirhl = LMF0;
dirll = LMF1;
dirhr = RMB0;
dirlr = RMB1;
}
else if ( (PIND & 0x03) == 0x03 ){
//if both white, move backwards
/*dirhl = LMB0;
dirll = LMB1;
dirhr = RMF0;
dirlr = RMF1;*/
dirhl = LMB0;
dirll = LMB1;
dirhr = RMB0;
dirlr = RMB1;
}
}
}
Listing 9: oar3.c
A 13
Appendix B
The following is a series of screen shots of the Gantt chart for this semester.
B1
B2
B3
B4
B5
B6