Junior Design Project MineDetecting Robot Team...

Junior Design Project MineDetecting Robot

Team 11

Charles Miller (CoE) Maxime Maurice (EE) David Zeng (EE) Daniel Picone (EE)

Submitted on May 16th, 2016

1

Abstract

Within this project, there were several different components that constituted this autonomous robot. Specified in the project description presented by the professors, the robot was required to move around a constructed arena in which several obstacles would be planted that the robot must then work around. Within this arena are four metal washers that the robot must also be able to detect within a timespan of three minutes. This meant that the robot had to cover most of the surface area within the walls in order to search for and detect these mines. In order for the robot to properly move around within the arena, we decided to design the Rover with a combination of C/C++ programming using the Arduino platform (without actually using the Arduino hardware for this aspect) and the AVR programming that allowed the robot to perform the basic functions of going forward, backward, and turning. The AVR also handled the algorithm in which the robot would avoid obstacles and prevent it from crashing into the walls and corners of the arena. With a combination of, what is essentially, a programmed map of the layout of the tiles and the pair of ultrasonic sensors placed at the very front face of the robot, the robot was able to determine its next move accurately. The Rover 5’s code is primarily designed to allow it to move in a rectangular spiral within the arena, which is mapped to specific numbered nodes within the C program. Allowing the robot to cover as much ground as possible eases the eventual metal detecting processes of the circuit. Its object avoidance is only secondary to its baseline code of completing that spiral to the center of the arena. Within the code is programmed that if an obstacle is present, the robot must work its way around it while still record what nodes it is moving around in the mapped spiral, in order for it to account for its trajectory once the obstacle is completely avoided. Along with maneuvering around the obstaclefilled arena, the robot must also detect the four mines placed at various locations within the arena. This is where the metal detecting circuit comes into play. Built on a separate breadboard, the metal detector circuit consists of a 9V battery that powers a square wave generator whose output is sent through an inductor. Because this inductor, along with the second inductor, is placed at the base of the robot, the Rover must go over the mine in order to detect it. Once a mine is present, the first inductor will induce voltage across the second inductor. The voltage received by this second inductor then passes through an amplifying circuit in order for the voltage to be augmented to a level at which the Arduino Uno can detect the spike in voltage and display the information of a detected mine on a series of LEDs in series with resistors in order to prevent them from burning out.

2

Table of Contents I Title Page.............................................................................................................................1 II Abstract................................................................................................................................2 III Table of Contents.................................................................................................................3 III Project Overview..................................................................................................................4 IV Block Diagram.....................................................................................................................5 V Requirements ......................................................................................................................6 VI Verification of Each Requirement........................................................................................7

i) Metal Detection Requirements.............................................................................7 ii) Robotic Platform Requirements .......................................................................11 iii) Program Requirements.....................................................................................13

VII Technical Description........................................................................................................14 i) Picture of Final Product......................................................................................14 ii) Part Descriptions...............................................................................................15

a) SquareWave Generator............................................................................ 15 b) Metal

Detector............................................................................................16 c) Arduino Uno............................................................................................. 17 d) AVR............................................................................................................1

7 e) Ultrasonic Sensors.....................................................................................18 f) DRV8833 HBridge...................................................................................19 g) Motor Adapter Board.................................................................................20 h) IR Sensor/Remote......................................................................................21 i) Dagu 5 Rover.............................................................................................21

VIII Design Integration..............................................................................................................23 IX Power Management...........................................................................................................26 X Software.............................................................................................................................27

i) Metal Detection..................................................................................................27 ii) Navigation.........................................................................................................28

XI Appendices.........................................................................................................................35 i) Bill of Materials..................................................................................................35 ii) Power Budget....................................................................................................37 iii) Source Code.....................................................................................................38

a) AVR Code..................................................................................................38 i) Movement.h...................................................................................38 ii) Movement.c...................................................................................39 iii) Navigation.h...................................................................................46 iv) Navigation.c...................................................................................47 v) Main.c............................................................................................65

b) Metal Detection Code................................................................................68

3

Project Overview This Junior Design project required the use of recently acquired knowledge of how metal detectors work and the effects of alternating specific parameters within its circuit design, as well as previously taught principles regarding AVRprogramming. A group of one computer engineering major and three electrical engineering majors was tasked with designing an obstacleavoiding system that could also detect metal via the Rover 5 Robot system. This modified Rover would maneuver through an arena outlined with a specific number of obstacles in search for various metal washers placed within the setup. The first component built for this system was the metal detector. This metal detecting system was designed through the combination of various circuits completed in lab throughout the system. Its design can be broken down into three different components: the squarewave generator, the metal detecting inductors, and finally the noninverting amplifier. The metal detecting circuit had to be powered by a pulsating square wave modified from a 9V DC battery source. This square wave was then used to send current through the first inductor, which would induce a voltage across the second, smaller inductor if a metal washer were present. This induced voltage read by the second inductor would then be sent through an amplifying circuit used to greatly accentuate the signal received from detecting a metal washer. The second component designed for this system was the object avoidance robot. As the Rover 5 has been used several times in several labs and used throughout several semester, the team was knowledgeable of basic programming that allowed the robot to move forward/backward for specific distances and turn at specific angles. Because the robot would be placed into a 6x6 arena, our team thought it to be effective if the robot was programmed to read each tiles within the arena as a node that connected to several other numbered nodes that would direct its trajectory around its walls. Each of the thirty six tiles were numbered 1 through 35, spiraling into the center of the arena. The robot would move into a specific node and then slowly increment through each node numerically until it reached node 35, being in the center of the arena. However, this part of the project proved to be relatively difficult as it did not compensate for the various obstacles that would be set in place within these walls. The robot already reads the walls of the arena as NULL nodes, where it would simply continue to the next largest numbered node. So the presence of obstacles was managed by two ultrasonic sensors powered and programmed

4

by the AVR chip that would bounce sound waves off of whatever was in front of the sensor and read it back to the AVR as either an obstacle or a wall. Upon reaching an obstacle, the robot would then maneuver itself around it and continue on its spiral trajectory until reaching completion.

Block Diagram

Figure 1: Block diagram of entire system

The system consists of two mostly isolated subsystems. The first component is the metal detection subsystem. A 9V battery is used to power the signal generator, the metal detection circuitry and the Arduino. The signal generator sends a square wave at a 20% duty cycle to the MOSFET, acting as a switch in the metal detection circuitry. The output is then fed into the Arduino to process the voltage signals in a meaningful way. The Arduino also outputs a signal to an LED indicator whenever metal is detected. The second component is the robot control subsystem. A 7.2V battery pack powers the AVR board adapter. This adapter connects the AVR to the Dagu 5 Rover through the quadrature encoders to control the motors. The AVR itself is powered by the 3.3V source output of the Arduino to ensure a regulated voltage, otherwise the AVR operates unpredictably. The AVR also communicates with the Ultrasonic wall sensors through a trigger signal. When a wall or obstacle is detected, the sensors send an altered ECHO signal back to the AVR. The AVR can then run

5

the necessary procedures. A start and stop signal is also sent to the AVR by an IR sensor which responds to a remote.

6

Requirements Metal Detector

1. The metal detection circuit shall detect flat metal objects (mines) that are randomly placed on the field.

2. The metal detection circuit shall be powered by a 9V battery. 3. The metal detection circuit shall operate without the use of a signal generator or other lab

equipment. a. The metal detector shall use a portable squarewave generating circuit.

4. The metal detection circuit shall adhere to power consumption limits. Robotic Platform

1. The robot, including all additional hardware, shall not exceed a length or width of 2 feet. 2. The robot shall navigate a 6ft x 6ft field with 2 randomly placed obstacles that will not

exceed 3 feet in length or width and 6 inches in height. a. Robot shall use Ultrasonic sensors to detect and avoid walls and obstacles. b. Robot shall not intentionally interfere with mines or obstacles.

3. The robot shall navigate the field autonomously, with no user input other than a start/stop signal sent by an IR remote (see Program requirement #1).

4. The robot, and all additional components, shall be built using an original design (see also Program requirement #4).

5. The robot shall be able to operate for three minutes. 6. The robot shall be powered by a 7.2V battery pack.

Program

1. The program shall require no user input, except for a start/stop signal. 2. The program shall track the orientation of the robot in the field. 3. The program shall control the AVR and Arduino Uno separately and with different files. 4. The program shall be original in design.

7

Verifications

Metal Detector In order to verify Metal Detector requirement (1), the robot that we designed detects mines using a difference in voltage when a metal object is present. Before placing a mine in the range of detecting, there is a reference voltage, without factoring noise made from the motors. Once there is an increase in voltage, it will be signaled through an LED that there is a metal present. From Figure 2, we can see that the voltage without a mine is about 1.2V. This, however, was not our reference voltage. In order to factor in the spikes in voltages due to the motors moving, we increased the reference voltage to approximately 1.31.4V. This would prevent the metal detector from signaling that there is a metal present when there was not.

Figure 2: Oscilloscope picture of the metal detector voltage without a washer present

Figure 3 is an image of the oscilloscope when there is a washer at the strongest point of detection (the center of the two inductor coils). As a metal object comes into range of the detector the voltage increases to about 6.5V. In our code, once the voltage read is above the 1.31.4V threshold, the metal detector will indicate a metal washer being found. Lowering reference voltage increases the “sensitivity” of detection. This allows the robot to detect metal objects that are below the inductors but not necessarily needing to be in the strongest area of detection.

8

Figure 3: Oscilloscope picture of the metal detector voltage with a washer present

The metal detector that we designed had the highest difference in voltage was the metal object was closer to the center of the two induction coils. If the metal was placed towards the side the amplitude would be around 2 volts opposed to the 6.7 volts if the metal was directly in the center. In order to have the best chance to detect a mine, we placed the inductors as close to the ground as possible without touching the floor and giving just enough room for a washer to pass through. As shown in Figure 4, the LED lit up when the washer was near the center of the two coils. The inductor was also able to detect the metal if it was placed on the sides but because the voltage was around 1.72V sometimes noise would cause the LED to trigger because it would be in the voltage range.

9

Figure 4: Detection is the strongest at the point of intersection between the two coils

To create a Pulse Induction Metal Detector in order to verify Metal Detector requirement (3), a pulse must be passed through the magnetic coupling (the inductors). We had two options when approaching this requirement, creating the pulse through a circuit or creating it using the Arduino functions. Because we decided not to use the Arduino library and in turn using the AVR, we created the pulse generator and square wave through circuits. The pulse generator consisted of various resistors (2k, 47k, 100k), a .1µF capacitor, a 10k potentiometer and an Operational Amplifier (LM324). To adjust the duty cycle of the pulses generated, a potentiometer was used.

Figure 5: Operational Amplifier LM324N

The potentiometer used in the pulse induction circuit is to modify the duty cycles of the pulses. By adjusting the pulses we were able to find out which one functions with the entire circuit as

10

well as yielding the best voltage readings. The figure below (Figure 6) shows a 20% duty cycle for the pulses. It gave an amplitude of 6.7 Volts. During some tests, as we increases the duty cycle certain parts of the circuit began to overheat, so we decided to stay with a 20% duty cycle.

Figure 6: Oscilloscope picture of the square wave generator at 20% duty cycle

Requirements (2) and (4) are verified through Figure 7. When the 9 volt battery is plugged into the metal detection circuit, it allows for the operational amplifiers to operate due to it needing 7.2V. The result of its functionality can be seen in Figures 2 and 3 where the metal detection circuit has an output with and without a washer present.

Figure 7: Metal Detection circuit with 9V battery power source

11

Robotic Platform The Dagu Rover 5 that we used for this project had all components mounted on top. All electrical circuitry was done on two breadboards that were connected with separate voltage sources for the metal detection and the robot itself. The figures below show the dimensions of the robot with all the components mounted on top. From these figures, the robot does not exceed two feet in length, width or height. This complies with the requirements that were given to as in the project description. From Figure 8, we can see that the width of the rover is about 9 inches. Figure 9 shows the length of the rover being about 11 and a half inches and Figure 10 shows the height being about 5 inches. The requirements listed in the project description states that the entire project must not exceed 2 feet in width and length from the furthest point of protrusion. These requirements (1) and (2) are verified in Figures 8 through 10 as it complies with the dimensions.

Figure 8: Width of the Rover

12

Figure 9: The length of the Rover

Figure 10: The height of the Rover with components on top

13

Requirements (3) and (4) can be verified in the program section below. The Rover was also programmed by our team to traverse around the inner perimeter of the established arena. Because the incorporations of washers required the Rover to properly detect metal in a space larger to its relative size, an algorithm was needed so that the Rover was able to cover as much surface area within the arena as possible. After initially moving with the perimeter, the Rover was then programmed to essentially function as a lawnmower for as long as it possibly can, a function that can be found within the Source Code section of this report and that verifies the requirement (5). Requirement (6) can be verified by Figure 7 (above) that the rover utilized a 7.2V battery pack in order to power the robot.

Programming The Rover fulfills requirement (1), “The program shall require no user input, except for a start/stop signal” by being completely autonomous. The robot can determine if there is a wall in front of it using the Ultrasonic sensors, allowing it to avoid obstacles and walls without a user telling it there is one. It knows when to flash the LED for the presence of a mine, using the metal detector and the ADC within the AVR. Requirement (2), “The program shall track the orientation of the robot in the field”, is fulfilled with functions in the AVR’s navigation program. All information about the Rover is tracked in a Car struct within the program. The functions turn_car_right(Car), turn_car_left(Car), turn_car_180(Car) and turn update the orientation of the Rover within the program. All turning within the program uses these functions. Refer to Source CodeAVR CodeNavigation.c for the source code of these functions. Requirement (3), “The program shall control the AVR and Arduino Uno separately and with different files.” is fulfilled by running from more than two different source code files. In fact, the AVR runs from 3 linked source code files. The Arduino is on a separate device completely and runs a program different from that of the AVR. Refer to Software for more details on the organization of the Software. The two components do not depend on oneanother to run Requirement (4), “The program shall be original in design” is fulfilled by the certification of all engineers on this team that the software is indeed original. None of the source code in this report has been pulled from an online source.

14

Technical Description

Figure 11: Front view of the Robot Figure 12: Top view of the Robot

Figure 13: Side view of the Robot

15

Square Wave Generator In order to create a metal detector, a magnetic coupling needs to be made. For our project we decided to create the magnetic coupling using two coils magnetic wires, as it yielded better results compared to using regular hook up wire. Without any pulse going through the induction coils created using the magnet wires they are plain wires, so we created the pulse using circuitry. Although the pulses could be made using the Arduino functions, our team did not decide to use the Arduino functions. The pulses and square wave were made using several operational amplifiers and a potentiometer. This design for the square wave generator was provided to us in Lab 1 in the Junior Design course. The schematic consists of using a LM324, an operational amplifier part with 4 opamp ports, From Figure 14, the first two opamps, a inverting and non inverting amplifier, create a triangle wave. To create a square wave the output of the triangle is fed into another port of the LM324 with a potentiometer in order to create a square wave. The square wave duty cycle can be adjusted using the potentiometer to increase or decrease the voltage. Through some testing we found that using a 20% duty yielded not only the best results in detection but also the best chances of the entire circuit to run for the required time of 3 minutes. Adjusting the duty cycle increases or decreases the amount of pulses that the generate sends through. During one of our testings when we increased the the duty cycle , but in doing so parts of the circuit began heating up so we left our design at 20% duty cycle. The result of the square wave is then fed into a MOSFET for the metal detection circuit.

Figure 14: Schematic of the square wave generator

16

Metal Detection Circuit After the square wave generator was created, and the output was fed into the gate of the MOSFET along with the transceiver coil. The transmitter coil sends the pulse that was generated and is a magnetic coupling with the receiver coil. The receiver coil then outputs the pulse feedback to a second LM324. In the LM324 we followed the circuit of the metal detector that was given to us in Lab 5 and 6. Because the initial readings were extremely small, we amplified the signal with a gain of 100 using 1M ohm and 10k ohm resistors. With the gain being amplified by 100, we were able to see changes on the oscilloscope when there was or wasn't a metal present.

Figure 15: Schematic of the metal detection circuit

17

Arduino An Arduino Uno Genuino was used to program the metal detection software. Using the ATmega328P microcontroller, we were able to process the voltage output of the metal detector in a meaningful way. The board is powered by a 9V battery. This falls within the range of recommended input voltage (7V12V). The minimum input voltage is 6V, so we made sure that the 9V battery was fully charged during testing and the demonstration. There are 6 analog input pins, but only 1 was needed (A5). This took the output of the metal detector. There are also 14 digital I/O pins, but only 1 was needed (P3). An LED is used at the output to light up when the program detects an input voltage above the threshold value (1.2V). The Arduino also has a 3.3V source pin that is used to power the AVR.

Figure 16: An Arduino Uno Genuino

ATmega AVR328 Microprocessor The main navigation control program is put on an AVR 328 microprocessor. The operating voltage of the processor is 3.3V. It has 28 pins, 13 of which are used for Input/Output. The device can be programmed in C and C++ using the avrgcc and avrg++ compiler. These compilers translate machine code generated by the GNU compilers into machine code readable by the AVR. It has 32kB of flash memory and and 2kB of SRAM. Along with that, the processor has an Interrupt feature. With Interrupts, the AVR can halt all operations and execute a special function once a certain condition has been met. The Program Counter has been saved and returns to normal operations when the Interrupt has finished. The condition used in this design is the detection of a rising edge on one of the pins (INT0). The processor also has an Analog to Digital

18

Converter (ADC) with a resolution of 10 bits. All of these features are taken advantage of in this project. The device is 1 inch long and 0.4 inches wide. It fits into the middle of the breadboard, in which all connections are made.

Figure 17: An AVR 328 Microprocessor

HCSR04 Ultrasonic Sensors

Figure 18: An HCSR04 Ultrasonic Sensor

Our design uses two of the sensors shown above. They take 3.3V for normal operation. In order to be used, it must be powered and then “triggered” by sending a 10 microsecond pulse to the TRIG pin. The sensor will then output to the ECHO pin. As illustrated below, the ECHO signal has a waveform dependant on the distance a wall is to the sensor.

19

Figure 19: Ultrasonic sensors with wall vs. without wall detection

When triggered the sensor sends out an ultrasonic wave and listens for the echo from the surfaces of the surrounding area. An echo may be heard sooner with a closer wall. This difference allows the sensor to differentiate close walls to far walls, hence different output waveforms. A closer wall makes the ECHO output stay high for a shorter time. These devices are small two inches long, 1 inch wide, and 0.5 inches in height, and can be placed almost anywhere. DRV8833 HBridge

Figure 20: The inputs/outputs of an HBridge

These devices are used to power the motors directly. As seen in the figure above, they take inputs from the AVR and drives the motors according to the table shown below.

20

Figure 21: HBridge outputs according to inputs

Two of these are used in our design, directly integrated with the Motor Adapter Board. This enabled us to control two motors individually allowing forward, backward, clockwise, and counterclockwise movement of the Rover. It is 1’ by 0.5’ and is very susceptible to burning out. Motor Adapter Board

Figure 22: The two HBridges utilized on the Motor Adapter Board

The Motor Adapter Board provides a convenient interface between a processor and the Rover. It houses two DRV8833 HBridges, which power the motors directly. It takes connects the power from the 7.2V battery pack to the HBridges. The Hbridges are connected to the connectors of the motor. It also connects the HBridge IN pins and quadrature outputs to an array of contiguous male pins on the bottom of the board. The board also features resistor which protect the circuit from reverse current. More details of the board can be found in the Design integration

21

IR Sensor/Remote The Rover was tasked with the ability to physically start and stop within the arena using an infrared remote control. Because this remote would have to control essentially most of the mechanical control of the Rover, the input of the infrared sensors was mapped to a pin within the AVR. This “pause” feature makes use of the interrupt feature of the AVR microprocessor. As discussed in the Technical Description of the AVR328, the feature suspends current operation to go to a special function when a specified condition happens on a specified pin. Connected to the INT0 pin of the processor is an Infrared (IR) Receiver. The output of the receiver is a single bit that is toggled anytime the button on its remote is pressed. The waveform of the output is illustrated below:

Figure 23: Waveform of IR receiver when button is pressed

In our design, the interrupt sequence is configured so that it will trigger on the rising edge of the INT0 pin, and exit on the falling edge. See Software for more details. Dagu Rover 5 The Rover 5 is the robot chassis that our project was revolved around. The robot uses quadrature encoders to indicate when a motor is moving. In order to make sure the Rover 5 maintains a straight path, the quadrature encoders need to be moving at the same time. To correct any changes if one encoder is faster or slower than the other one, code in the AVR is used to stop the faster motor by a small fraction of time in order for the slower one to catch up in encoder counts. Our robot only has 2 motors as 2 of them were removed in Sophomore Design. The motors are

22

controlled by 2 bit binary codes from 00 to 11 indicated where the wheel should hardstop, move forward, move backwards, or a soft stop.

Figure 24 : Picture of the Dagu Rover 5

23

Design Integration

The design of our robot consisted of using a square wave generator circuit, a metal detection circuit, Arduino Uno, ultrasonic sensors (ping sensors), IR receiver/remote, and AVR microprocessor. The square wave generator creates a pulse that goes through the magnetic coupling. The magnetic coupling consists of a transmitter and receiver coil. Once a pulse is created by the generator it is fed into a MOSFET and the signal travels through the magnetic coupling into the metal detection circuit. Because the signal is extremely small and shows barely any noticeable change in voltage, the signal is fed into a second LM324 to amplify the output. The output of the metal detector is fed into the Arduino Uno. The Arduino flashes an LED when a metal has been detected. When a metal object is in the detection range the voltage readings will be greater than ~1.31.4V, and that results in an LED being lit up. The ADC feature of the AVR was used to detect this change. The ping sensors that were placed in the front and the side of the robot are used to detect the walls of the arena and different obstacles. Once triggered by the AVR, the ping sensors sends waves and listens for echoes that bounce off a surface. The difference in the waveform differentiates close walls from far ones. The ping sensor creates a different output accordingly. An echo heard closer in time indicated a wall nearby. The AVR has two sensors attached to it. Refer to Figure 21 below:

Figure 25: Placement of components on Rover

The ping sensor placed on the front of the Rover is used for the main wall detection. When a wall is two inches ahead of the Rover, obstacle handling function of the AVR is triggered under

24

certain circumstances. See software for a detailed explanation. Two inches is chosen because the metal detector is placed two inches out of the Rover. This choice prevents the metal detector from getting damaged by crashing into the wall, while also avoiding noise from the motors when they are enabled... The The other ping sensor is placed at a 45° angle at the front of the Rover. When this sensor detects a wall, the AVR will turn 45° to align itself to the wall. Without this ping sensor, the Rover would crash into the arena and obstacle walls at 45°, since the first ping sensor has a small angle of view (refer to Figure 21 above). The AVR is the heart of the robot. It is powered by the 3.3V Arduino output. It holds the programs for navigation control. It takes inputs from the ping sensors (Ping ECHO), quadrature encoders from the Motor Adapter Board (QUAD), and Infrared Receiver (IR Pause). Its outputs go to the Motor Adapter Board, which houses the DRV8833 Hbridges, which ultimately drive the motors. It also outputs a trigger signal (Ping TRIG) for the ping sensors as well as an LED for debugging purposes. Figure 22 below shows all the pin connections to the AVR:

Figure 26: Pin locations on AVR

25

The QUAD inputs and MOTOR outputs (Right Back, Left Forward etc.) go to the Motor adapter board.

Figure 27: Pin locations relative to encoders, battery sources, etc

Nets LEFT_IN_1, LEFT_IN_2, RIGHT_IN_1, and RIGHT_IN_2 correspond to Left Forward, Left Back, Right Forward, and Right Back respectively. The board also transports the quadrature outputs to the AVR. All 8 of these signals are connected to the array of 8 male pins of the Motor Adapter Board. The Motor Adapter Board is put on a breadboard. The ground for it is next to one of these signals. It is bent so that it does not interfere with that signal. As mentioned in the Technical Description, the DRV8833 HBridges take the outputs of the AVR, and drive the Rover Motors with a different voltage source. This ultimately allows the AVR to control the movement of the motors. The quadrature encoders allow the AVR to see differences in speed of each of the motors. This allows for a correction program that disables a motor that is ahead until

26

they are both caught up. The quadrature encoders are powered by a 3.3V input from the Motor Adapter Board.

27

Power Management

Overall, our robot was powered by two different batteries in order to assure the optimal results from both the mechanical functions of the Rover and the metal detecting circuit, which were built on separate breadboards to encourage easier troubleshooting. A battery pack of 7.2V was used specifically for the robot as the robot has a particular voltage range in which it can be properly powered with without burning it out or not providing enough power to it. A 9V duracell battery powers the Arduino Uno, the squarewave generator which charged the base of the MOSFET used, and finally the metal detecting circuit. However, a 3.3V power source supplied voltage to the AVR chip, which was tasked with managing the C code that controls all basic movement and wall/obstacle avoidance functions of the robot. This 3.3V supply actually comes from the 3.3V regulator output from the Arduino Uno port. This voltage supply was very important to take into consideration as we blew out several AVR chips due to supplying too much power to their VCC pins. Upon several failures due to AVR misusage, our team was informed by a professor that AVRs require a power source of at most 5V. Since the conception of our original robot design, we had been powering the AVR with a voltage supply of 7.2V, straight from the bus connected to the battery source powering the robot. Because the AVR was now being supplied power by this 3.3V source, the two ultrasonic sensors utilized in this project were also powered by the same 3.3V source from the Arduino.Not requiring much power, the IR sensors from the remote control also was supplied 3.3V. The power received through the input of the MOSFET within the metal detecting circuit was variable through the inclusion of a potentiometer within the squarewave generating circuit. This potentiometer enabled our team to alter the duty cycle at which the generated square wave would oscillate. The altering of this duty cycle proved to be extremely dangerous to the rest of the circuit. Setting the duty cycle too high resulted in the constant burning out of one of the 10 ohm resistors utilized in the design. This observation led us to using a 20% duty cycle for the rest of experimentation and eventual implementation as well as increasing that specific resistor value from 10 to 100 ohms. Another issue we had to take into consideration was the power flowing through the LEDs. These LEDs, as stated previously, would indicate whether or not a mine was detected. Originally our team had thought because of our troubleshooting and experimentation with checking the functionality of the metal detecting circuit, the LEDs would burn out from constantly being on. However, this was not the case. The LEDs were connected to the Arduino, which was being supplied a voltage of 9V. It wasn’t until the repeated burning out of LEDs that we realized we

28

needed to add resistors in series with them in order to provide a safe voltage increase for the LEDs to withstand.

Software

Two Atmega AVR328 Microprocessors were used to achieve the goals for this project. One processor was dedicated metal detection while the other was used for navigation of the arena. Metal Detection Software

The microprocessor dealing with the metal detector had a rather simple program that continuously reads the voltage of the pin connected to the output of the metal detector. The program uses the Analog to Digital Conversion feature of the AVR. This feature reads the voltage supplied to the specified pins, and stores the result in two 8bit registers. The feature requires a reference voltage supply for the result. The result follows the equation:

DC 024 A = 1 * V in VREF

The conversion takes 13.5 clock cycles. Given that the processor runs at 20MHz, the latency of the conversion is 675ns. This latency may be ignored. The maximum output of the metal detector is 6.5V and 1.2V with and without metal nearby, respectively. See verification for metal detector output waveforms. The ultimate goal of the software was to compare the conversion of the ADC to a fixed threshold value. When that threshold is surpassed, the program stops converting to flash an LED connected to an I/O pin, indicating the presence of a mine, then returns to normal procedure. The value of the threshold is 800 so as to ignore output spikes from electromagnetic noise from the motors as well as metallic objects underneath the floor of the arena. The flowchart for this program is shown below:

29

Figure 28: Logic procedure for LEDs switching on

Navigation Software The main control AVR processor has a program that accomplishes the challenge of covering the most ground in the least amount of time using the Dagu Rover 5. The software is divided into two major components: Movement.c and Navigation.c. With Movement.c, the Rover may achieve basic movement such as forward traversal of fixed distances and turning fixed distances. This is achieved by setting special registers that are connected to I/O pins of the AVR. The pins are connected to the DRV8833 which ultimately drive the motors (see Design Integration). A macro named MOTORS represents this register in the source code. There exist simple functions that sets this register so that the Rover turns one or more motors on for forward and backward motion. Certain combinations allow the Rover to turn in place and move forward and backwards (see Design Integration). Movement.c has functions that use the quadrature encoders to move forward and turn specified distances. The output of the quadrature encoders allow the AVR to see differences in the motors, and adjusts the accordingly. If a motor is seen to get ahead of the other, that motor is disabled until they have both traveled the same distance. When both motors have reached the goal specified, the motors are then stopped. This procedure is the same for in place turning, only one motor is put in reverse. In Navigation.c the arena is simulated with a graph of a 6x6 grid. Each vertex in the graph represents a 1’ by 1’ tile. A struct to represent a tile has the following members:

uint8_t state

30

uint8_t value tile* north tile* west tile* south tile* east

Each tile has a state and takes on the enumerated values UNCOVERED, COVERED, and WALL. They also have an associated id (value). Both state and value are used in the path finding algorithm. Members north, south, east, and west are pointers to adjacent tiles. If the tile is on an edge of the simulated arena, the respective adjacent tile pointers will be NULL. The figure below demonstrates the setup for tile One.

Figure 29: Node locations relative to “tile” 1

Tile one is on the east side of the arena, so its east member is NULL. The entire arena is constructed in the following way in order to guide the rover in a counterclockwise spiral motion.

31

Figure 30: Numerical mapping of arena according to code

Each tile starts in the state UNCOVERED, since we don’t know where the obstacles will be.The direction and current tile of the Rover are tracked and updated after each traversal to a tile. Once a traversal is complete, the Rover’s current tile state is changed to COVERED, then the Rover’s direction and current tile are updated. When the rover finds an obstacle, the respective tile has its state changed to WALL. Which tile to travel to next is determined the following way:

Examine all tiles adjacent to the current Choose the tile with the lowest value, but higher than the current, and is in state

UNCOVERED If no such tile exists, choose the tile with the lowest value, but higher than the

current, and is not in state WALL If no such tile exists, choose the tile with the highest value, and is not in state

WALL If no such tile exists, the rover is surrounded by walls, and it must stop

In an arena with no obstacles, the rover will travel in a counterclockwise spiral around the arena. The program must also be able to avoid obstacles. Obstacle presence is determined using the HCSR04 Ultrasonic Sensors (ping sensors). During the traversal from one tile to the next, the rover stops every two inches to check for a wall. When stopped the AVR executes the following routine:

32

Hold pins connected the TRIG signal of ping sensors high for 10 microseconds Wait 1.8 milliseconds Check output of ping sensors, ECHO if they are high

As illustrated below, the ECHO signal has a waveform dependant on the distance a wall is to the sensor. As established in the Technical Description of the Ultrasonic Sensors, the ECHO signal goes low early when a wall is detected. The program checks the output for both sensors after 1.8ms (see figure above). This time has been calibrated so that the ECHO signal would go low just before this check when there is a wall 2 inches ahead. 2 inches was chosen because the metal detector placement (see Design Integration). A low ECHO signal at the time of checking means a wall exists. The contrapositive also holds true. From this, the program can determine if there exists a wall in front of the robot. The program must know if the wall it encounters is truly an obstacle, or just the edge of the arena. When the Rover travels to a tile with a wall ahead, it will detect the wall before completing its traversal. Therefore the tile two tiles ahead must be calculated to determine what type of wall the Rover encounters. If that tile exists and a wall was encountered, then an obstacle must be there. That tile then has its state changed to WALL and the obstacle handler is called. If the tile doesn’t exist (I.E NULL), then the wall encountered is an edge of the arena, and normal procedure is continued. The figure below demonstrates both cases for a wall encounter:

Figure 31: Sensing a wall vs. sensing an obstacle

33

When the obstacle handler is called, the Rover does the following actions:

Go to the tile on the Rover’s left Go to the tile on the Rover’s right Go to the tile on the Rover’s front Go to the tile on the Rover’s left Turn left

If a wall is encountered during this routine, then the obstacle must be on a wall, and the Rover will turn left early. The movement is illustrated below:

Figure 32: Maneuvering an obstacle vs. a corner

Due to imprecise movement of the Rover, program could only follow the perimeter of the arena accurately. Continuing operation would cause the program to think an obstacle was present when it really was hitting a wall. To alleviate the problem, the program is made so that it will follow the perimeter until it reaches tile 19. The rover will follow a “Lawnmower Pattern” thereafter. The pattern is as follows:

34

Continue straight until a wall is detected Go to the tile on the Rover’s left Turn left Continue straight until a wall is detected Go to the tile on the Rover’s right Turn right Repeat

This allows coverage of the middle part of the arena. The pattern will continue forever until the 3 minute time limit is up. With this, there is a high probability that the entire arena will be covered by the 3 minutes. So far, all wall detection discussed uses the main ping sensor located in the front of the robot. The other ping sensor is used to correct inaccuracies of the robot’s turning. When a wall is detected with this ping sensor, the robot turns 45 degrees to align itself. The final feature of the navigation program is the Pause feature, using the AVR Interrupt Feature (see Technical Description of the AVR328).The interrupt feature has been configured such that the interrupt sequence triggers on the rising edge of pin INT0 (PD2). When the interrupt is triggered, following sequence is executed:

Save the state of the MOTORS register Halt Movement (set MOTORS to 0) Wait for pin INT0 to go low Restore the state of the motors (restore MOTORS)

After the interrupt sequence is finished, normal operation continues. The operation of the AVR is described in the flowchart below:

35

Figure 33: Flowchart of obstacle maneuvering

36

Appendices

Bill of Materials

Name Part # Manufacturer Supplier Supplier # Quantity

Robot RS0110/2 Dagu Rover 5 Binghamton University

N/A 1

Arduino Uno Genuino A000066 Arduino SparkFun DEV11021 1

MOSFET 2SK4017 TOSHIBA Binghamton University

N/A 1

Operational Amplifier LM324N STMicroelectronics

Binghamton University

N/A 2

Potentiometer P160KNP0EC15B10

K

Texas Instrument Electronics


N/A 1

Capacitor (0.1µF) GRM188R71H104MA

93

Murata Binghamton University

N/A 1

Resistor (100k) MILPRF55342.

State of the Art Inc.


N/A 1




N/A 1




N/A 1




N/A 1

Resistor (2.7k) MILPRF55342.



N/A 1

Resistor (10) MILPRF55342.



N/A 1




N/A 1

Resistor (1M) MILPRF55342.



N/A 1

37

LED COM12062

SparkFun Binghamton University

N/A 1

1.2 V Battery HR3UTHAAMZN

Amazon Basics Amazon HR3UTHAAMZN

6

Magnet Wire 30AWG PRT11363 SparkFun Unicorn Electronics

PRT11363 1

UltraSonic Sensor HCSR04 ElecFreaks SparkFun HCSR04 2

AVR 2503Q–AVR

ATMEL Binghamton University

N/A 1

IR Sensor BANGXECT2780

Atomic Market Amazon B01ACIVP0I 1

IR Remote BANGXECT2780

Atomic Market Amazon B01ACIVP0I 1

38

Power Budget

Power Source Part Expected Current Notes

7.2V Battery Pack Dagu 5 Rover 600mA During movement

HBridge (DRV8833) 500mA x2

9V Duracell Battery SquareWave Generator

LM324 0.9mA OpAmp x3

R1, R2, R3 45nA Resistors

R4 0.5mA Potentiometer

C1 44nA Capacitor

Metal Detection Circuitry

LM324 506nA OpAmp

R5, R6, R7, R8 0.5mA Resistors

M1 0.5mA MOSFET

L1, L2 0.5nA, 72nA Inductor Coils

Arduino Uno 20mA

Arduino 3.3V AVR 6mA Active supply current

Wall Sensor (HCSR04) 15mA x2

IR Sensor 5mA Dynamic current

LED Indicator 50mA

1.198 A Total

39

Source Code AVR Code

Movement.h #ifndef MOVEMENT_H #define MOVEMENT_H //movement.h #include <stdint.h> #ifndef BOOL_TYPE #define BOOL_TYPE typedef enum bool false,true bool; #endif #define MOTORS PORTB #define MOTOR_INFO PINB #define LEDS PORTC #define SENSE PORTD #define SENSE_IN PIND #define LEFT_MOTOR_STATE ((MOTOR_INFO & 0x30)>>4) #define RIGHT_MOTOR_STATE (MOTOR_INFO & 0x03) #define LEFT_MOTOR (MOTORS & 0xC0) #define RIGHT_MOTOR (MOTORS & 0x0C) #define F_CPU 1000000UL #include <util/delay.h> //_delay_ms(); #define tick_factor 23 void Left_fow(); void Right_fow(); void Left_back(); void Right_back(); void Both_fow(); void Both_back(); void Stop(); void Rest();

40

void rot_left(); void rot_right(); void Stop_sec(); void clear_count(); void update(); void rotate(float radians); void rotate_left(float radians); void rotate_right(float radians); void correct(); void back_correct(); void move(signed short distance); void back_move(signed short distance); void mine_detect (); bool wall_init(); void fun(); void report_err(); #endif

Movement.c //Charlie Miller, Daniel Picone, David Zeng, Maxime Maurice //Junior Design //movement.c //Implementation of movement functions #include <stdio.h> #include <stdlib.h> #include <avr/io.h> #include "movement.h" float car_width = 14.3 * tick_factor;

41

//Current distance each motor has traveled uint16_t right_pos = 0; uint16_t left_pos = 0; //states of last seen quadrature encoders uint8_t current_l = 0; uint8_t current_r = 0; //Basic functions for turing motors on and off void Left_fow()

MOTORS = 0X40;

void Right_fow()

MOTORS = 0x04;

void Left_back() MOTORS = 0X80;

void Right_back()

MOTORS = 0x08;

void Both_fow()

MOTORS = 0x44;

void Both_back()

MOTORS = 0X88;

void Stop()

42

MOTORS = 0xCC;

void Rest()

MOTORS = 0;

void rot_left()

MOTORS = 0x84;

void rot_right()

MOTORS = 0x48;

void Stop_sec()

Stop(); _delay_ms(50); Rest(); _delay_ms(10);

//Functions for movement tracking of robot void clear_count()

left_pos = 0; right_pos = 0;

void update()

if(current_r != (MOTOR_INFO & 0x03))

43

current_r = (MOTOR_INFO & 0x03); right_pos++;

if(current_l != (MOTOR_INFO & 0x30))

current_l = (MOTOR_INFO & 0x30); left_pos++;

void rotate(float radians)

//rotate until the goal has been reached clear_count(); Stop_sec(); uint16_t goal = car_width * radians; if(radians > 0)

rot_right(); while( goal >= right_pos)

update();

if(radians < 0)

rot_left(); goal *= 1; while( goal >= left_pos)

update();

Stop_sec();

void rotate_left(float radians)

44

//rotate until the goal has been reached clear_count(); Stop_sec(); uint16_t goal = car_width * radians; rot_left(); while( goal >= left_pos)

update();

Stop_sec();

void rotate_right(float radians)

//rotate until the goal has been reached clear_count(); Stop_sec(); uint16_t goal = car_width * radians; rot_right(); while( goal >= left_pos)

update();

Stop_sec();

void correct()

//Disable the motor that is ahead until they are both equal while(right_pos > left_pos)

Left_fow(); update();

while(right_pos < left_pos) Right_fow(); update();

45

void back_correct()

//Disable the motor that is ahead until they are both equal while(right_pos > left_pos)

Left_back(); update();

while(right_pos < left_pos) Right_back(); update();

void move(signed short distance)

//Enable motors until the goal has been reached, correcting motor inaccurracies along the

way distance *= tick_factor; clear_count(); Both_fow(); while((right_pos < distance) && (left_pos < distance))

Both_fow(); update(); correct();

correct(); Stop_sec();

void back_move(signed short distance)

//Enable motors until the goal has been reached, correcting motor inaccurracies along the

way ... backwards

46

distance *= tick_factor; clear_count(); Both_back(); while((right_pos < distance) && (left_pos < distance))

update(); back_correct();

back_correct(); Stop_sec();

bool wall_init()

//Drive sensors SENSE = 1; _delay_us(10); SENSE = 0;

//Look at output of senor after some time will determine wall presence _delay_us(1800); if((SENSE_IN & 0x08))

//! operator won't work for some reason else

rotate(M_PI *0.5); return true;

if((SENSE_IN & 0x02))

//! operator won't work for some reason else

//Car needs a little repositioning, rotate 45 degrees respectfully rotate_left(M_PI *0.25);

47

return false;

void report_err()

//Stop everything. Something went wrong MOTORS = 0; while(1)

LEDS = 1; _delay_ms(500); LEDS = 0; _delay_ms(500);

Navigation.h #ifndef AI_H #define AI_H #include <stdint.h> typedef enum Directions_type NORTH,EAST,SOUTH,WEST,SELF Direction; typedef enum States_type UNCOVERED,COVERED,WALL State; #ifndef BOOL_TYPE #define BOOL_TYPE typedef enum bool false,true bool; #endif typedef struct tiles_type State state; struct tiles_type* north; struct tiles_type* south; struct tiles_type* west; struct tiles_type* east;

48

uint8_t value; tile; typedef struct Car_type tile* current_tile; Direction current_direction; Car; tile** create_arena(); void free_arena(tile** arena); void change_tile_state(tile* t,Direction d,State s); void turn_car_right(Car* c); void turn_car_left(Car* c); void turn_car_180(Car* c); bool travel_forward(tile* ahead2,Car* c); bool goto_adjacent(tile* end_node,Car* c); void goto_node(tile** arena,tile* start,tile* end); tile* find_next_lower(tile* t); tile* find_next_higher(tile* t); tile* relative_forward(Car* c,tile* t); tile* relative_right(Car* c,tile* t); tile* relative_left(Car* c,tile* t); void handle_wall(Car* c); void goto_waypoint(tile** arena,Car* c,uint8_t end_node_value); void search_arena(tile** arena,Car* c, uint8_t start_node_value); #endif

Navigation.c //Charlie Miller, Daniel Picone, David Zeng, Maxime Maurice //Junior Design //Navigation.c //High level functions for traversing a 6' x 6' arena

49

#include <stdio.h> #include <stdlib.h> #include <math.h> #include <avr/io.h> #include "navigation.h" #include "movement.h" void change_tile_state(tile* t,Direction d,State s)

//Change specified tile or ajacent to specified state switch(d)

case (SELF): if(t>north)

t>north>south>state = s; else

t>south>north>state = s; break;

case (NORTH): t>north>state = s; break;

case (WEST): t>west>state = s; break;

case (SOUTH): t>south>state = s; break;

case (EAST): t>east>state = s; break;

50

void turn_car_right(Car* c)

//rotate car 90 degrees and update car's direction accordingly rotate_right(M_PI * 0.5); if (c>current_direction == WEST)

c>current_direction = NORTH; else

c>current_direction++;

void turn_car_left(Car* c)

//rotate car 90 degrees and update car's direction accordingly rotate_left(M_PI * 0.5); if (c>current_direction == NORTH)

c>current_direction = WEST; else

c>current_direction;

void turn_car_180(Car* c)

//rotate car 180 degrees and update car's direction accordingly rotate_right(M_PI); c>current_direction = (c>current_direction + 2) & 0x03;

bool travel_forward(tile* ahead2,Car* c)

51

//move car 12 inches ahead, stopping every 2 inches //At every 2 inches check for a wall //If a wall exists check if ahead2 is NULL //If it's not, then an obstacle is in the way, handle it //Update arena accordingly uint8_t i; for(i=0;i<6;i++)

if (wall_init())

//Wall found, we end early change_tile_state(c>current_tile,SELF,COVERED); if (ahead2)

//there exists a wall when there shouldn't be obstacle detected change_tile_state(ahead2,SELF,WALL); return true;

else

//We just reached edge of arena instead return false;

move(4); Stop_sec();

change_tile_state(c>current_tile,SELF,COVERED); return false;

bool goto_adjacent(tile* end_node,Car* c)

//Move car to a tile adjacent to its current tile //Turn car and update its position and orientation accordingling //Calculate the tile 2 ahead of where its going to differentiate arena edges from obstacles

Direction next_dir; tile* ahead2;

52

if(c>current_tile>north == end_node)

next_dir = NORTH; ahead2 = c>current_tile>north>north;

else if(c>current_tile>east == end_node)

next_dir = EAST; ahead2 = c>current_tile>east>east;

else if(c>current_tile>south == end_node)

next_dir = SOUTH; ahead2 = c>current_tile>south>south;

else if(c>current_tile>west == end_node)

next_dir = WEST; ahead2 = c>current_tile>west>west;

else

//tile passed in was not adjacent! report_err();

//Turn car to appropriate position and update uint8_t angle_dist = (c>current_direction next_dir) & (0x03); switch(angle_dist)

case (NORTH): //No need to turn the car break;

case (1): //turn car relative west turn_car_left(c); break;

case (SOUTH): //turn car relative south

53

turn_car_180(c); break;

case (3): //turn car relative east turn_car_right(c); break;

bool wall = travel_forward(ahead2,c);

//update car's current position *c>current_tile = *end_node; return wall;

tile* find_next_lower(tile* t)

//Algorithm for path finding find the adjacent tile with the highest value, but lower than the tile in question

tile* next = malloc(sizeof(tile)); //Make cur_diff large positive, 127 will guarantee number less than 36 next>value = t>value 127;

//Examine all adjacent tiles tile* adjacent[4]; adjacent[0] = t>north; adjacent[1] = t>east; adjacent[2] = t>south; adjacent[3] = t>west;

bool match_found = false;

//Strict path finding node must be lower than current and UNCOVERED uint8_t i; for ( i = 0; i < 4; i++)

if(adjacent[i])

int8_t cur_diff = t>value next>value;

54

int8_t proposed_diff = t>value adjacent[i]>value; if ((proposed_diff >= 0) && (proposed_diff < cur_diff) &&

(adjacent[i]>state == UNCOVERED))

next = adjacent[i]; match_found = true;

//Less strict path finding node must be lower than the current and not a wall if(!match_found)

for ( i = 0; i < 4; i++)

if(adjacent[i])

int8_t cur_diff = t>value next>value; int8_t proposed_diff = t>value adjacent[i]>value; if ((proposed_diff >= 0) && (proposed_diff < cur_diff) &&

(adjacent[i]>state != WALL))


//lenient pathfinding node must not be a WALL if (!match_found)

for ( i = 0; i < 4; i++)

if(adjacent[i])

int8_t cur_diff = t>value next>value; int8_t proposed_diff = t>value adjacent[i]>value; if ((proposed_diff < cur_diff) && (adjacent[i]>state != WALL))

55


if(!match_found)

report_err();

return next;

tile* find_next_higher(tile* t)

//Algorithm for path finding find the adjacent tile with the lowest value, but higher than the tile in question

tile* next = malloc(sizeof(tile)); //Make the first current diff large negative number, not 127 bc overflow will make it

small next>value =t>value + 90;

tile* adjacent[4]; adjacent[0] = t>north; adjacent[1] = t>east; adjacent[2] = t>south; adjacent[3] = t>west;

bool match_found = false; //Strict path finding node must be higher than current and UNCOVERED uint8_t i; for ( i = 0; i < 4; i++)

if(adjacent[i])

56

int8_t cur_diff = t>value next>value; int8_t proposed_diff = t>value adjacent[i]>value; if ((proposed_diff < 0) && (proposed_diff > cur_diff) &&

(adjacent[i]>state == UNCOVERED))

match_found = true; next = adjacent[i];

//Less strict path finding node must be higher than current and not WALL if(!match_found)

for ( i = 0; i < 4; i++)

if(adjacent[i])

int8_t cur_diff = t>value next>value; int8_t proposed_diff = t>value adjacent[i]>value; if ((proposed_diff < 0) && (proposed_diff > cur_diff) &&

(adjacent[i]>state != UNCOVERED))


//Lenient path finding node must not be a WALL if(!match_found)

for ( i = 0; i < 4; i++)

if(adjacent[i])

int8_t cur_diff = t>value next>value; int8_t proposed_diff = t>value adjacent[i]>value;

57

if ((proposed_diff > cur_diff) && (adjacent[i]>state != UNCOVERED))


if(!match_found)

//When no match has been found there must be something wrong, or we're surrounded by WALLs

report_err(); return next;

tile* relative_left(Car* c,tile* t)

//Just return a pointer to the tile on the car's left switch(c>current_direction) case NORTH:

return t>west; break;

case EAST: return t>north; break;

case SOUTH: return t>east; break;

case WEST: return t>south; break;

return NULL;

58

tile* relative_right(Car* c,tile* t)

//Just return a pointer to the tile on the car's right switch(c>current_direction) case NORTH:

return t>east; break;

case EAST: return t>south; break;

case SOUTH: return t>west; break;

case WEST: return t>north;

break;

return NULL;

tile* relative_forward(Car* c,tile* t)

//Just return a pointer to the tile in front of the car if its not COVERED, otherwise return NULL

switch(c>current_direction) case NORTH:

if(c>current_tile>north && (c>current_tile>north>state != COVERED)) return t>north;

else return NULL;

break; case EAST:

if(c>current_tile>east && (c>current_tile>east>state != COVERED)) return t>east;

else

59

return NULL; break;

case SOUTH: if(c>current_tile>south && (c>current_tile>south>state != COVERED))

return t>south; else

return NULL; break;

case WEST: if(c>current_tile>west && (c>current_tile>west>state != COVERED))

return t>west; else

return NULL; break;

return NULL; void handle_wall(Car* c)

//Travel around the obstacle in a relative sense tile* next = malloc(sizeof(tile)); next = relative_left(c,c>current_tile); goto_adjacent(next,c); move(2); next = relative_right(c,c>current_tile);

//Only continue wall handling if there isn't a wall here (I.E. obstacle is on corner) if(goto_adjacent(next,c)) next = relative_forward(c,c>current_tile); move(5); goto_adjacent(next,c); next = relative_right(c,c>current_tile); goto_adjacent(next,c); turn_car_left(c);

60

void goto_waypoint(tile** arena,Car* c,uint8_t end_node_value)

//Traverse the spiral until a specified tile is reached, handling walls when necesary tile* next = malloc(sizeof(tile)); while(c>current_tile>value != arena[end_node_value]>value)

if(next = relative_forward(c,c>current_tile))

if(goto_adjacent(next,c)); handle_wall(c);

else

next = relative_left(c,c>current_tile); goto_adjacent(next,c);

free(next);

void search_arena(tile** arena,Car* c, uint8_t start_node_value) //Traverse the spiral starting at specified node //continuing until node 19 is reached //Then perform Lawnmower traversal which makes uturns in a semirandom direction

*c>current_tile = *arena[start_node_value];

//search perimeter goto_waypoint(arena,c,19); turn_car_left(c);

//Lawnmower procedure tile* next = malloc(sizeof(tile)); while(1)

61

move(6); if(wall_init()) *c>current_tile = *arena[35];

if(MOTOR_INFO % 2 == 0)

next = relative_right(c,c>current_tile); goto_adjacent(next,c); turn_car_right(c);

else

next = relative_left(c,c>current_tile); goto_adjacent(next,c); turn_car_left(c);

free(next);

void free_arena(tile** arena)

uint8_t i; for (i = 0; i < 35; i++)

free(arena[i]); free(arena);

tile** create_arena()

//Create the entire arena with all interrelationships //All data is shared on the heap

tile** arena = malloc(sizeof(tile*) * 36);

62

uint8_t i;

//All tiles start in state UNCOVERED for (i = 0; i < 36; i++)

arena[i] = malloc(sizeof(tile)); arena[i]>value = i; arena[i]>state = UNCOVERED;

//All neighboring relationships arena[0]>north = arena[1]; arena[0]>west = arena[19]; arena[0]>south= NULL; arena[0]>east= NULL;

arena[1]>north = arena[2]; arena[1]>west = arena[20]; arena[1]>south= arena[0]; arena[1]>east= NULL;




arena[5]>north = NULL; arena[5]>west = arena[6]; arena[5]>south= arena[4];

63

arena[5]>east= NULL;

arena[6]>north = NULL; arena[6]>west = arena[7]; arena[6]>south= arena[23]; arena[6]>east= arena[5];




arena[10]>north = NULL; arena[10]>west = NULL; arena[10]>south= arena[11]; arena[10]>east= arena[9];

arena[11]>north = arena[10]; arena[11]>west = NULL; arena[11]>south= arena[12]; arena[11]>east= arena[26];


arena[13]>north = arena[12]; arena[13]>west = NULL;

64

arena[13]>south= arena[14]; arena[13]>east= arena[28];


arena[15]>north = arena[14]; arena[15]>west = NULL; arena[15]>south= NULL; arena[15]>east= arena[16];

arena[16]>north = arena[29]; arena[16]>west = arena[15]; arena[16]>south= NULL; arena[16]>east= arena[17];




arena[20]>north = arena[21]; arena[20]>west = arena[31]; arena[20]>south= arena[19]; arena[20]>east= arena[1];

arena[21]>north = arena[22];

65

arena[21]>west = arena[32]; arena[21]>south= arena[20]; arena[21]>east= arena[2];


arena[23]>north = arena[6]; arena[23]>west = arena[24];

arena[23]>south= arena[22]; arena[23]>east= arena[4];






66








return arena;

67

Main.c //Charlie Miller, Daniel Picone, David Zeng, Maxime Maurice //Junior Design //main.c //Execution of entire project #include <stdio.h> #include <stdlib.h> #include <avr/io.h> #include <math.h> #include <avr/interrupt.h> #include "movement.h" #include "navigation.h" void pin_setup()

//Setup of pins I/O polarity DDRB =0xCC; //motors polarity DDRC =0x0F; //LEDS Poloarity DDRD =0x01;//Senors polarity

LEDS = 0x1; MOTORS = 0;

void interrupt_setup()

//Enable all necessary interrupts EIMSK |= 0x01; //Enable INT(0) interrupt EICRA |= 0x03; //Configure interupt triggers to happen on RISING EDGE sei();

int main()

68

//Setup for operation of AVR pin_setup(); interrupt_setup();

//Delay for to show AVR is powered on _delay_ms(500);

LEDS = 0;

//Create the arena and instance of our Car the rover tile** a = create_arena(); Car* rover = malloc(sizeof(Car)); rover>current_tile = malloc(sizeof(tile)); rover>current_direction = NORTH; *rover>current_tile = *a[0];

//Search the arena search_arena(a,rover,0);

//cleanup free_arena(a); free(rover); return 0;

ISR (INT0_vect)

//Interrupt sequence for IR detector //Save the state of the motors, then halt uint8_t motors_state = MOTORS; Stop_sec(); LEDS = 1; //Wait for the interrupt signal to go low while(SENSE_IN & 0x02) LEDS = 0; //Restore motor state.

69

MOTORS = motors_state;

70

Metal Detection Code //Charlie Miller, Daniel Picone, David Zeng, Maxime Maurice //Junior Design //Metal Detection program #include <stdio.h> #include <stdlib.h> #include <avr/io.h> #define SENSE PORTC #define LEDS PORTB #include <util/delay.h> #define THRESHOLD 800 uint8_t mines = 0; void mine_detect () ADCSRA = 0xE3; //Enable ADC,Start converting, Autotrigger, Divison factor = 8 ADCSRB = 0x00;//Enable ADC ADMUX = 0x45;//Vref = AVCC with capacitor,no left adjust on value,choose ADC5(PC5, A5) uint16_t adcValue = 0; uint16_t i = 0; uint8_t mine_present = 0; while(i < 0x6FFF) //Examine value of ADC converter adcValue = ADCL | (ADCH <<8); if(THRESHOLD<adcValue) if(mines == 4) mines = 0; else

71

mines++; mine_present = 1; i++; if(mine_present) LEDS = 1; _delay_ms(100); LEDS = 0; _delay_ms(100); LEDS = 1; _delay_ms(100); LEDS = 0; _delay_ms(100); LEDS = 1; _delay_ms(100); LEDS = 0; _delay_ms(100); LEDS = 1; _delay_ms(100); LEDS = 0; _delay_ms(100); LEDS = 1; _delay_ms(100); LEDS = 0; _delay_ms(100); LEDS = 1; _delay_ms(100); LEDS = 0; _delay_ms(100); LEDS = 1; uint8_t main()

72

//Defining polarity of pins DDRC = 0x0;//Mine in DDRB = 0xFF;//LEDS while(1) //continuously check for mines mine_detect(); return 0;

73

Junior Design Project MineDetecting Robot Team...

Documents

Transcript of Junior Design Project MineDetecting Robot Team...