Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
G.U.N.D.A.M. II. DESIGN A. Motor Microcontroller Didier Lessage, Gabriel Rodriguez, Blake Simonini School of Electrical Engineering and Computer Science, University of Central Florida, Orlando, Florida 32816-2450 Abstract — The GUNDAM is a maze solving robot using primarily the wall following method of maze solving to find the exit of a wooden maze. The robot uses a combination of IR and ultrasonic sensors to detect walls and turns. The robot will also transmit this information to a laptop to draw out the layout of the maze and give a visual representation of the area for the user. I. INTRODUCTION The GUNDAM’s main mode of transportation will be two motors controlling the left and right side wheels of the chassis. A voltage regulator will be built to control the flow of power to the different physical components of the robot. One ultrasonic sensor will be used to detect any obstacles in of the robot. Two IR sensors will be used to detect distance between the sides of the robot and the walls to its left and right. The motivation for this project was to provide a method of exploration of areas unable to be safely entered by humans safely such as caves and areas with small paths and openings. The robot’s ability to detect walls will have the dual purpose of object avoidance and a basic understanding of the layout of the area. For the purpose of this project, the goals have been scaled down to simply be the successful navigation of a maze and transmitting enough information for software to translate it into a 2D layout for the user. The software will also give the user the ability to give the robot parts of a solved maze to travel to. This project was also chosen to feed into the strengths of each of the group members. With two electrical engineers, a heavy focus on the actual hardware was chosen to play to their strengths. A final computer engineer led to the decision of a software side to the design, the maze drawing and pathfinding portion of the GUNDAM. This allowed for each member to give a significant contribution to the project. In order to control the 6VDC motors that we have on our chassis, an H-bridge is needed. Instead of making an H-bridge with individual parts, we decided to buy one that was already made and well documented – the L298N. We also opted to get a diode bridge to protect the H-bridge from counter-EMF produced by the high inductance of the motors. Then in order to control our H-bridge, we conjoined that with the MSP430 (g2231) MCU. And since the L298N uses transistors for switching and the motors were designed to consume somewhere around 2 Amps when running continuously, we needed to make sure that our motor voltage and amperage was high enough to account for the voltage drops (and energy waste) across the transistors (VSS needed to be about 10.6 volts). We also needed to supply voltage for the TTL logic that controls the transistors (5 volts), as well as supply a high enough voltage for the MSP430 in order to get the maximum clock speed out of it (3.5 volts), while remembering to put in decoupling capacitors for all of our voltage supply inputs. The following represents the design for one motor on the H-bridge. Fig 1. Half H-Bridge for one motor Input 1 0v 5v Input 2 5v 0v Motor1Output1 5v GND Motor1Output2 GND 5v Results Clockwise Counterclockwise Fig 2. Gate Input Table for Each Motor 5v 5v 0v 0v Off EnableA and EnableB need to be high to enable each half H-bridge to make the full H-bridge that controls both motors. And for protecting the motors from back-EMF, the L6210 Schottky Diode bridge is used. It can handle up to 4 amps across a diode and has a low turn on voltage. The following is the design for connecting it to the H- It’s also worth noting that the motor microcontroller will handle positioning itself in the direction of new corridors once it is commanded to go down a particular corridor. This is done by placing the sensors towards the back of the chassis, so that as soon as a new corridor is detected by those sensors, the robot will already be accurately centered in that corridor and will only have to rotate a certain angle in order to position itself for navigating down that corridor. bridge. Fig 3. Diode Bridge for both motors The MSP430 MCU that we used runs at a clock speed of 1Mhz; its function is to balance the motors, use routines to turn the motors so that the robot moves forward, backward, clockwise, and counterclockwise using Pulse Width Modulation for the distance it is commanded, keep the robot centered in a path as it moves down a corridor, and know what possible decisions it can make based on what data the sensors are giving to it. The actual decision handling though will be partly done by an outside controller and the MSP430 will mostly accept commands in this regard. The decisions that will be implemented into this controller are explained in the following. Decision Explanation Decision 1 Corridor ends with no openings Corridor ends with one opening Decision 2 Decision 3 Decision 4 Corridor ends with two openings Corridor ends with three openings Fig 4. Robot Decision Making What Can Be Done Turn Around Wait for command: Might be in a loop Wait for Command: Might be in a loop and doesn’t know which path should be taken Wait for Command: Might be in a loop and doesn’t know which path should be taken B. Chassis Layout The chassis we used has the ability to mount PCBs on it with the capability to stack them on top of each other. The motors came fitted to the chassis, while the battery holder for the three AA batteries does not supply enough voltage and current to be of any use. We also needed a way to mount the sensors, motor microcontroller, PSU, and RF controller so that everything could hook up to each other and there would be no interfering of parts. C. Power Supply and Battery The power supply consists of four different voltage regulators for delivering our power needs. Regulator Switching – 10.6 volts – 5 amps Linear – 5 volts – 1.5 amps Linear – 3.5 volts – 1.5 amps Linear – 2.5 volts – 1.5 amps Function Power to the motors Power to the TTL logic of the H-bridge, as well as the IR and Ultrasonic Sensors Powers the MSP430 in a high power mode Powers the MSP430 in a low power mode Fig 5. Voltage Regulators There are also lots of pins attached to each voltage source for modularity. This allows us to add components later as we need them and gives us a greater ability for laying out our parts on the chassis as we require it. For a battery we have two lithium ion batteries at 7 volts that we have in series. This will give use 14 volts, which is sufficient to account for the dropout voltage across the 10.6 volt switching regulator. Also, the switching regulator is technically adjusted from 5 volts to 10.6 volts and each voltage input in our circuits have decoupling capacitors to keep any circuits from dropping out as the power demands on the regulators drop and rise too quickly. For testing purposes, we didn’t use a battery, but used a laptop power supply rated at 19 volts and 4 amps, which has a built-in transformer and plugs easily into the power connector on the Power Supply on our board. For the battery we had to connect a power connector so that we could plug it into the Power Supply on our board. III. COMMUNICATION SYSTEM A. Communication Subsystem The design of the G.U.N.D.A.M.’s communication subsystem will be centered on a microcontroller that can process the signals transmitted from the computer, which requires demodulation and decryption. In addition, to transmit to the computer the microcontroller will be required to encrypt the data, which will be the path taken or other information about the maze, from the main microcontroller and modulate for transmission. The microcontroller in charge of taking the bits received from the transceiver will be an MSP430G2xx. Since the MSP430G2xx has the ability to convert analog-todigital signals a simple AM or FM transceiver can be used for transmissions, but the microcontroller can also accept digital input so using a digital RF transceiver via an SPI interface, which will carry an advantage in reducing the amount of processing the MSP430 has to do. The microcontroller will also be in charge of implementing a simple wireless protocol including AES-128 encryption to communicate with the computer and visa versa. To accomplish this, the code written on the microcontroller will be split into two main parts. One for the purpose of taking data from the main microcontroller in charge of controlling the robot itself and transmitting that data to the computer. In the process of transmitting that data the microcontroller will encrypt it using AES-128 encryption algorithm. The second for the purpose of establishing an initial connection and manage this connection with the device on the computer. The MSP430G2553 microcontroller has the capability of communicating with several devices simultaneously through the use of two-channel serial communication interface, namely USCI_A and USCI_B blocks. The MCU on the computer dongle has to be able to communicate with the RF transceiver through an SPI interface and simultaneously send that data to the computer through an UART interface. Luckily, the MSP430 MCU has the capability to meet both of these application needs. The device that will be on the computer has the same functions as the one on the G.U.N.D.A.M., however; the demodulated and decrypted data will be sent to the computer through a USB interface. The MSP430 has a serial interface to communicate with a computer but this would not work with all computers since many don't have serial ports and it would be ideal to be able to communicate with any computer that has a USB port and can run the software. To combat this problem a CP2102 chip will be used to convert UART to USB, which will allow the MSP430 to send and receive data from the computer. The CP2102, manufactured by Silicon Labs, is a single chip USB to UART Bridge. The computer will recognize this device as a virtual COM port, which in turn can be used by the GUI running on the computer to draw out the map of the maze. The bridge in turn will be connected through TXD and RXD pins, to an MSP430’s UART interface, which is the USCI_A channel. The CP2102 has baud rates up to 921.6kbps so it can handle the transmission speed on the RF transceiver and MCU. It also has a 512 byte transmit and receive buffer, which is over the 64-byte TX and RX FIFO of the RF transceiver, although the MCU will be the middleman between the RF transceiver and the CP2101. B. Interfacing RF Transceivers with MCU All the modulation and demodulation schemes explored are able to accomplish the task of sending and receiving data between the G.U.N.D.A.M. and a computer, however; some schemes provide better features for our application. Frequency and phase modulation provide the ability to transmit a signal with minimal noise and inference, which is ideal in our environment. Phase modulation, in contrast with frequency modulation, in particular provides a way to more easily detect if the signal is lost and give the ability to retransmit any data that is lost. Phase shift keying is a digital modulation scheme that is ideal for the G.U.N.D.A.M.’s communication subsystem not only for the reasons previously discussed, but because the data transmitted will be binary data. However, even with the increase spectral efficiency and data rate the frequency modulation techniques over amplitude modulation techniques have higher power consumption. To implement this design an RF transceiver of low-cost and low-power consumption will be used on the G.U.N.D.A.M. and the computer communication device. This transceiver will be the low power IC chip from Hope Microelectronics, RFM12B that has the ability to modulate and demodulate a binary signal using multi-channel FSK. This RF transceiver is very versatile and has many programmable features, such as frequency, power output, channel filter bandwidth, and Carrier Sense indictor among many others. The RFM12B RF transceiver module has very low power consumption at 14mA in TX mode operating at 433MHz. The RF transceiver module will transmit and receive at different frequencies to increase efficiency and decrease interference during communication between the G.UN.D.A.M.’s module and the computer’s. In the MCU will be connected to the RF transceiver through the pins on Digital Interface. The RFM12B is configured with this SPI interface, which is also used to transmit and receive data. Meaning the MCU will be in charge of programming the different modes available on the RFM12B and transmitting and receiving data through the same interface. The RF module has two 8bit TX data registers and one 16-bit RX data FIFO. Depending on how the R/W bit is set when interfacing through the SPI, the FIFO can be accessed through a single address. As stated before the MCU will use four I/O pins for the SPI configuration interface, namely SDI, SCK, nSEL, SDO, nIRQ. The MCU can be programmed to generate interrupts based on the status pins’ output. One of the most useful programmable features on the RFM12B is the data rate, which can be configured through the configuration registers mentioned above. Yet another important programmable feature is the output power of the RF transceiver. The output power chosen will determine the typical current consumption, which will affect the range. During the testing phase an output power can be chosen based on a reliable effective range determined to be sufficient. There is a possibility of a problem arising with using a frequency range of 433MHz for transmitting and receiving data, that is there can be other communication systems operating at these frequencies in our testing environment. Thus to reduce interference a lower frequency band which is not as commonly used by most modern wireless systems in our likely testing environment was chosen. The length of the antenna depends on the frequency the RF transceiver will operate at. The frequency band chosen for the RF transceiver is 433MHz, meaning that this RF transceiver will require an antenna that is a quarter of the smallest wavelength utilized to keep a reasonable size and performance, which turns out to be approximately 23.8cm. C. Wireless Protocol The main features required from the protocol is the ability to sense the presence of another transmitting device and send acknowledgements so the device goes into listening mode. A secondary but important feature to the protocol will be an implementation of the AES128 encryption algorithm. This encryption algorithm has gained popularity due to its susceptibility to bruteforce and other attacks. The implementation of AES128 encryption algorithm will require the sender to encrypt the data using a public key and the receiver to decrypt the data using a private key. Both the G.U.N.D.A.M. and the computer device will share a public key to send data to each other but each will have their own private key to decrypt the data they receive. The first requirement of the wireless protocol, which will be implemented by the MCU, will be to handle transmission between two nodes in a manner that they don't talk over each other, in other words, neither of the two nodes must transmit or receive data at the same time. To accomplish this there will be a routine in the MCU that will periodically check whether the device is transmitting or receiving data. This will be important in determining the next step because initially both the G.U.N.D.A.M. and the computer module will be in listening/receive mode that will wait for new transmission. Data transmission will begin when the G.U.N.D.A.M. has information it needs to transmit to the computer. In this case, the G.U.N.D.A.M.’s MCU will encode the data in AES-128 and pass it to the RF transceiver to be sent to the computer. The computer will initially be in listening mode to be able to receive the encoded information, which it will then decode and pass it on to the computer. In this application, the G.U.N.D.A.M. will be the only device sending data and the computer will only be receiving data. However, the design allows for two-way communication between the G.U.N.D.A.M. and the computer for scalability purposes. Although the G.U.N.D.A.M. and the computer dongle will only implement one-way transmission they will each use acknowledgements to ensure that data was received without errors and no retransmission is needed. To accomplish this error-checking test, the G.U.N.D.A.M.’s RF transceiver will need to switch to listening mode to receive a packet of acknowledgement from the computer dongle. Similarly, the computer dongle will switch to transmitting mode for a short period of time to send the packet acknowledgement. This coordination will be accomplished by routines in the MCU and a timer to ensure that there is no collision or loss of data. The second requirement of the wireless protocol will involve the MCU having the capability to also handle the encryption of data before it is transmitted over-theair to either the G.U.N.D.A.M. or the computer. To reduce latency and errors, the acknowledgement packets will not be encrypted since they don’t contain any relevant data to what the G.U.N.D.A.M. is communicating to the computer. A separate routine on the G.U.N.D.A.M. and computer’s MCU will handle which packets will be encrypted and which won’t. For the packets that are encrypted the MCUs will have an encryption and decryption routine. The function will take plain text data from the main microcontroller on the G.U.N.D.A.M. or the computer on the receiving dongle and encrypt it using the AES-128 encryption technique. To encrypt the plain text the MCU on the G.U.N.D.A.M. will use a pre-programmed key to encrypt the data and the MCU on the computer dongle will use the same pre-programmed key to decrypt the data and send it to the computer so the GUI interface on the computer can use the data to draw out the maze. Although not needed, the G.U.N.D.A.M. and the computer dongle will both have the capability of encrypting and decrypting plaintext for scalability reasons. Fig 6. Function of Sharp GP2D120 infrared range finder. This particular IR range finder has a minimum and maximum detection range from 4cm to 30cm. It has an operating voltage and current of 4.5V to 5.5V, 33 to 50mA. The response time is 30ms with an analog output. The voltages can simply be converted to a useful distance for the microcontroller using the chart below. IV. Range Finder System The G.U.N.D.A.M. will have two ultrasonic sensors on the front and back of the robot to detect longer distances in the narrow paths of the maze. It will also have two infrared sensors on the sides to detect smaller distances. Most ultrasonic sensors have a minimum distance of 2cm and infrared sensors have a minimum distance of 4cm. To combat inaccuracies in distance measurements the robot’s main microcontroller will be required to keep the robot centered within the minimum distances that the sensors can measure. Infrared sensors have simple circuits but accurate infrared sensors are difficult to manufacture without the proper tools. Below is a figure of the Sharp GP2D120 infrared range finder functioning on a flat surface obstacle. Fig 7. Voltage output vs. Distance of GP2D120 IR range finder. Ultrasonic sensors on the other hand are less susceptible to inaccurate measurements due to the wider emitting beam. Building an ultrasonic sensor with individual parts and a circuit schematic can prove to be more cost efficient than purchasing a pre-built sensor. Since ultrasonic sensor output will be an analog signal there will have to be calculations done to determine the distance measurements based on the frequency of the transmitted beam and the time the beam takes to reflect back and be detected. Below is circuit schematic of an ultrasonic distance measurement circuit, however; the PIC12C508 will be replaced with the main microcontroller. The range finder sensors will be mounted on the robot chassis itself and will interface with the main microcontroller, which will take its values and store them to calculate the distances and path traversed through the maze. The two infrared sensors mounted on the sides of the robot will be as close to the ground as possible and they will be housed in a shield to prevent interference from the indoor lighting at the receiving end of the sensor. The ultrasonic sensors on the front and back of the G.U.N.D.A.M. will be mounted further from the ground to reduce the possibility of the sound absorption from the carpet floor that could possibly be a part of the G.U.N.D.A.M.’s testing environment. Both the ultrasonic and infrared sensor will be at the midsection of the horizontal axis in the robots dimensions to increase the accuracy when calculating the position and location in the maze. V. LAPTOP SOFTWARE A. Maze Solving Algorithm The primary method of maze solving for our software will be the classic solution of wall following. Wall following works by choosing a side relative to the robot (left or right), and choosing to stick with that direction when coming to an intersection or turn. The robot will choose to follow the left side at all times to find the exit to the maze being built. For our particular project, the robot will choose to follow the left side of the wall in order to reach the exit. Wall follower will fail in two cases. If the entrance to the maze does not lie on the outer wall of the maze, then wall follower is not guaranteed to find an exit. The mazes constructed for our project will, fortunately, not have interior entrances. A second fail state is if a wall is not connected to the outer wall in one straight line. If this case occurs, the robot will turn in circles indefinitely. Our project will also not feature mazes of this type to avoid these two fail states for wall follower. While wall follower may seem unintelligent when given an aerial view of the maze, this method of maze solving always results in a found exit. Also, because our mazes will be built to a 6’ x 6’ dimension, the amount of time to solve such a maze will not be an issue. B. Maze Drawing The maze drawing software will be written using Java in the Eclipse IDE. Several classes are necessary to accomplish this including classes to store the location of all the walls, a class to store the state and direction of the robot, and a class to store the location of nodes. Nodes will be placed at every intersection and turn of our maze. These nodes will contain their location on the maze, whether or not their four compass directions are an opening or a wall, and any neighboring nodes that may have been discovered by the robot. The existence of nodes is important for the utilization of the pathfinding algorithm, A*. The paths will be represented by a known connection of two neighboring nodes. If a node has a known opening but no discovered node in that direction, then the direction will be labeled automatically with a value of -1. The neighbors will be stored as an integer that represents the array location of the neighbor within an array created in a NodeManager class. This class’ main task is to keep a reference to every node within the map to allow for easy lookups when finding a path within the maze as well as whenever the maze needs to be redrawn. Walls will be stored within a list similar to the nodes. Each wall will contain the two corners that make up the ends of the walls. Wall thickness will not be taken into consideration for this particular project. A WallManager class is also utilized to store an array keeping information on every wall within our maze. This is to allow for the redrawing of our maze without losing any information once our canvas has been cleared. The robot class will contain information on the compass direction it is facing (north, south, east, west) and its current location. This information will be used to determine what direction any openings it finds are as well as help in translating what exactly a left turn means in relation to its direction. This also helps us determine where exactly a new node should be placed within our maze. The maze itself will be drawn on a canvas with simple lines to represent each of the walls and circles to represent the nodes at each intersection. Our maze has a uniform length of one foot for each section of wall. This was done to help the maze drawing algorithm. Before moving forward, the software will receive data on the distance the GUNDAM measures between the wall straight ahead and its current location. The software will receive another distance value upon reaching a node. There is the possibility that the sensor will return a value that is not equal to foot sections. This is to be expected. To account for this, some assumptions will be made. For instance, if the sensors first send a distance of 50 inches and upon reaching a node they send a distance of 28 inches, this results in a distance of 22 inches. Because of our one foot sections, we know that this cannot be the case for our maze drawing algorithm. To correct this, the software will assume a distance of 24 inches, or 2 feet. With all of this information, the software simply feeds in the information on how far the GUNDAM has traveled before reaching the next intersection or dead end and draws out two lines one foot apart from each other. This represents the path just traveled by our robot. The next block of information grabbed from the robot will be the values of the three sensors. If the value is below a foot, we can assume that a wall most likely lies in that direction. If the value is greater than a foot, we know that a path lies in that direction. With this information, the software decides whether to draw a wall or leave the space open with a one foot entry to represent the path available to the GUNDAM. Once the maze has been solved, the user will be presented with a 2D representation of our maze along with circles representing the nodes placed at each intersection. cursor and every node present in our maze allows us to decide which node the user most likely wished to select. With these classes, the pathfinding algorithm then needs to be chosen. For this project, A* pathfinding (pronounced A Star) will be used in order to find the shortest path within the maze in the shortest amount of time. A* pathfinding works by first grabbing the location of the GUNDAM and determining the closest neighboring node to its location. These neighbors were determined during the maze drawing portion of our software. Whenever a node is reached by our GUNDAM, the software does a search for the node that matches the location of our previous node. The neighbors are then applied accordingly. For instance, if we are traveling west and come upon a node, then the node that was left previously serves as the current node’s eastern neighbor. The current node will also serve as the previous node’s western neighbor. The distance from the neighbor to the destination is then taken. This is simply a rough calculation and does not take into account walls and other potential obstacles. Because of this, a neighboring node is never counted out of the possibilities for a path. Fig. 8. 2D Maze Example C. Path Finding Algorithm The robot’s secondary feature is the ability to select a location for the robot to travel to once the maze has been solved. In order to accomplish this, we must utilize the nodes class as well as the robot class. The robot class will provide information on the GUNDAM’s current location within the maze. The Node class and as the NodeManager class are necessary to determine which nodes can be used for the path to the destination chosen by the user. The user must select a node to serve as the destination of our GUNDAM. This node will change in color to give the user some feedback on which node they have selected. A simple distance formula applied to the Fig 9. Completed A* Path Once the source is reached, we are usually guaranteed to have found the shortest and quickest way to the destination. Unfortunately, this does not guarantee the most natural looking path to a destination in most cases, but because our environment is a maze, this is not an issue for our design. Once the path has been created, the software on the laptop side will create a list of instructions that will result in the GUNDAM finishing at the destination chosen by the user. These instructions simply consist of directions to take once the GUNDAM has reached each node along the path. These directions will be kept in an array to make for a natural transition between each instruction and to properly keep them in order. The user will be presented with a drawn out line connecting each node within the A* path. This will correlate to the path the GUNDAM takes within the physical maze. VI. PHYSICAL MAZE The maze itself will simply be built from wooden 2 x 6 boards cut into one foot sections for the interior walls and 6 foot sections for the exterior. Two of the 6 foot sections contain a 1 foot entrance cut in the center of the board. The 1 foot sections allow for a customizable maze for our robot to traverse. This serves to benefit the presentation by allowing for much more example cases. The uniform 1 foot sections also helps to account for any error within the sensors when measuring the length of a path. VII. CONCLUSION This project helped each group member gain experience within their respective fields of Electrical and Computer Engineering. It also gave insight on the inner workings of a project environment that will no doubt translate well into the real work force. The project itself provided hands-on experience with circuitry, hardware, and communication between subsystems that will no doubt apply to the real world in both our careers and in any research we may delve into in the future. Our project as a whole has gone through many changes throughout the semesters. Some accounted for and others happened upon during the development process. In the end, a robot with a basic maze solving ability and wireless communication was successfully completed meeting the goal of our initial proposal two semesters ago. ACKNOWLEDGEMENT We would like to acknowledge and thank our review committee for taking the time to judge and observe our senior design project. We would also like to thank Dr. Samuel Richie for his assistance throughout the two semesters. We would like to thank the machine shop staff for allowing us the use of their equipment when creating our physical maze for both our presentation and testing. We would like to thank our families for providing morale support throughout these two semesters. Finally, we would like to thank each other for assistance on our parts and the work put into our projects. PROJECT ENGINEERS Didier Lessage is a senior at the University of Central Florida. He is graduating with a degree in Computer Engineering on August 4, 2012. His fields of interest include Artificial Intelligence and Robot Vision. He plans to enter the work force for a few years before returning to school for a Masters degree in his field. Gabriel Rodriguez is a senior at the University of Central Florida. His interests are in embedded systems, analog and digital circuit design, and wireless communication. He is graduating with a degree in Electrical Engineering on August 4, 2012. Blake Simonini is a senior at the University of Central Florida. He is graduating with a degree in Electrical Engineering on August 4, 2012. He is interested in robotics and power systems and is looking to find a job out of state.