A Preliminary Design Plan for an Open Architecture Robot Kit Intended for Learning Purposes

Total Page:16

File Type:pdf, Size:1020Kb

A Preliminary Design Plan for an Open Architecture Robot Kit Intended for Learning Purposes

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 ii Figure 13: Distributed Processing Block Diagram...... 22

Figure 14: PC/104 Single Board Computer...... 23

iii 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

2 others. (Eija, 2006, p 2) Increasing retention and quality of students will increase the department’s prestige and image in the professional world.

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 low- speed 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.

3 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 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 Reloader Winding Catapult Assembly Motor Linear Actuator Arm

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.

The main 5x7 plate, seen in Figure 3, is used as the main backboard to mount the electronics, 6 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

10 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.

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

11 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 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)

12 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 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.

13 Figure 9: A square wave pulse width (Pulse-width, 2008)

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.

14 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 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.

15 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.

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

16 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

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

19 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.

 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 20  USB Interface

 1.8 – 5.5V Power

 10-bit A/D-Converter (Atmel, 2008)

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 In-

Circuit 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. 21 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 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

22 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.

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 23  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)

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.

24 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 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

25 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 Boe-

Bot 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 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

26 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

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 27 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.

28 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= +Karna-Lin%2C+E.%3B++Pihlainen-Bednarik%2C+K.%3B++Sutinen%2C+E.%3B+ +Virnes%2C+M

29 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/en- US/default.aspx

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

30 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 #include int main(void){

DDRD = 0xf0; // Configuration of port D // f = output, 0 = input

PORTD |= (1<<0); // Set pull-up resistor while (1){ // Read PORTD pin 0 if( !(PIND & 0x01) | 0x00 ){ // If sensor sees black PORTD = 0xF0; //Set high nibble of PORTD high } else{ // If sensor sees white PORTD = 0x00; //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.

A 1 /* Some definitions to make life easier */ #define SETUPNIB PORTB |= (1<<7) | (1<<6) | (1<<5) | (1<<4); #define RESETUPNIB PORTB |= (0<<7) | (0<<6) | (0<<5) | (0<<4); #define RESETLOWNIB PORTB |= (0<<3) | (0<<2) | (0<<1) | (0<<0); #define INVERTPORTD PORTD = ~PORTD; /* Necessary includes */ #include #include #include #include /* 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.

A 2 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; // PortB as output port DDRC = 0x01; // PortC0 for wave output DDRD = 0xff; }

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.

A 3 ISR(TIMER0_OVF_vect){ cli(); // Disable interrupts to avoid share data problems count--; if (ticks == 11){ // Check if a second (or around) has passed ticks = 0; if (count == 0x00){ RESETLOWNIB; count = 0x0f; } else{ PORTB = (PORTB & 0xf0) | (count & 0x0f); } tone++; tone = tone % 32; // Tone will go from 0 to 32 to select next sound } else{ ticks++; } sei(); }

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 5 6 7 Tone E | F | G | G | Bar 1 8 9 10 11 12 13 14 15 Tone E = 329.6 Hz E | F | G# | G | Bar 2 F = 349.24 Hz 16 17 18 19 20 21 22 23 Tone G = 392.00 Hz E | F | 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; finterrupt = 31250 Hz;

Te = 31250 / 329.6 Hz = 94.81; Etck = 94.81 / 2 = 47.4 => 47;

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.

A 4 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

A 5 #define SETUPNIB PORTB |= (1<<7) | (1<<6) | (1<<5) | (1<<4); #define RESETUPNIB PORTB |= (0<<7) | (0<<6) | (0<<5) | (0<<4); #define RESETLOWNIB PORTB |= (0<<3) | (0<<2) | (0<<1) | (0<<0); #define INVERTPORTD PORTD = ~PORTD; #include #include #include #include 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 } sei(); A 6 } 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; // PortB as output port DDRC = 0x01; // PortC0 for wave output DDRD = 0xff; } 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

A 7 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.

A 8 #define STOP_TIMER TCCR0 &= 0xF8; #define START_TIMER TCCR0 |= 0x05; #define SETUP_TIMER1A TCCR1A |= 0x00; #define SETUP_TIMER1B TCCR1B |= 0x09; #define SETUPNIB PORTB |= (1<<7) | (1<<6) | (1<<5) | (1<<4); #define RESETUPNIB PORTB |= (0<<7) | (0<<6) | (0<<5) | (0<<4); #define RESETLOWNIB PORTB |= (0<<3) | (0<<2) | (0<<1) | (0<<0); #define INVERTPORTD PORTD = ~PORTD; #include #include #include #include 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{ ticks++; A 9 } 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; // PortB as output port DDRC = 0x01; // PortC0 for wave output DDRD = 0xff; } 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 LMB0 16 // This is time high for Left Motor moving Backwards #define LMB1 74 // This is time low for Left Motor moving Backwards #define RMB0 74 #define RMB1 16 #define LMF0 74 #define LMF1 16 #define RMF0 16 #define RMF1 74 #define INVERTPORTD PORTD = ~PORTD; #define INVPD0 PORTD = (~PORTD & 0x01) | (PORTD & 0xfe); // Invert port D pin 0 #define INVPC0 PORTD = (~PORTD & 0x01) | (PORTD & 0xfe); #define INVPC1 PORTD = (~PORTD & 0x02) | (PORTD & 0xfd); #define INVPD7 PORTD = (~PORTD & 0x80) | (PORTD & 0x7f); #define INVPD6 PORTD = (~PORTD & 0x40) | (PORTD & 0xbf);

#include #include #include #include uint8_t timeout; uint8_t tone; uint8_t ticks; uint8_t dirhl; uint8_t dirll; uint8_t dirhr; uint8_t 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){ //time low if(tck == dirll){ tck = 0; INVPC0; INVPD7; A 11 turn = 0; } else{ 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; // 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 */ DDRD = 0xf0; DDRC = 0x03; } int main(void){ /* Initialize the system */ iniconf(); /* Initialize goblal variables */ tone = 0; ticks = 0; while(1){ //delay(0); //Check sensor if( (PIND & 0x03) == 0x00 ){ //If both black, movr forward A 12 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.

B 1 B 2 B 3 B 4 B 5 B 6

Recommended publications