Submission Format for IMS2004 (Title in 18-point Times font)



Inexpensive Robot with Interior MappingAlvaro Montoya, Hung Le, Ibrahim Shofiquel, Jaime Quintero Dept. of Electrical Engineering and Computer Science, University of Central Florida, Orlando, Florida, 32816-2450 Abstract — IRIM also known as Inexpensive Robot with Interior Mapping consists of a four wheeled platform large enough to accommodate its main sensor the Xbox 360 Kinect and the circuit boards which makes the mapping and navigation of the robot possible. The navigation of the robot is semi-autonomous and the mapping is created through the use of the Robot Operating System, also known as, ROS. The software and hardware design details that compose the mapping robot are discussed. Index Terms — Circuits, Microcontrollers, Mapping.I. IntroductionWhile the robot has been used in the industry for over a decade, unmanned robot are being develop for military purpose and autonomous vehicle are on the roll, there is however little development for domestic purposes. The main reason for such a slow development is usually the price for developing a robot. However, as the rise of technology, where faster processors being develop, sensors technology become affordable, the possibilities of a robot becoming a common sight are high. Building a robot is a complex process, this covers tasks such as locomotion of the robot, navigate within a given environment, or building a map for the environment the robot is navigating. The process of building a robot often requires extensive knowledge wide range topic of mechanical design, electrical system, and software programming. The online instructions are often complex or detailed specifically for certain type of reader, thus building the robot can become time consuming, costly, and frustrating.Unfortunately, modern engineers often focus on one single aspect of the robot thus making the task building a functional robot even more discouraging. Usually, software engineers would buy an expensive mobile platform and try to work their software with it, while electrical engineers would attempt to build their own platform and often struggle to get the software to function with their custom made robot. The project Inexpensive Robot with Interior Mapping (IRIM) is expected to address this issue by providing a simple mobile platform, which allows software engineers to spend less time and money for the robot and focus on the software aspect of the system. On the electrical part the electrical engineers would spend their time in developing the robot platform and with minimal knowledge about software they can realize the whole system. II. SYSTEM COMPONENTSThe design of a mapping robot consists of different parts in hardware and software to realize the entire system. Most of the parts were chosen with the inexpensive principal in mind. Some other parts in the hardware side of the system were chosen based on previous experience working with them. A. Microcontrollers For IRIM uses two different microcontrollers. The Texas Instruments’ MSP430F5529 is being used for motor control and accelerometer data forwarding. Also, the ODROID XU3 for streaming of Kinect data. The MSP430F5529 was chosen because it has the right amount of memory, pins, and power consumption. The MSP430F5529 has 128KB flash memory and 8KB RAM. This is more than enough memory to work with in this project. Currently, the code to control the autonomous movement of IRIM is only 25KB. With no further changes planned, it is obvious to see that the 128KB that MSP430F5529 offers is more than enough for this project. The MSP430F5529 has 40 usable pins available to the developer. There are 18 GPIO pins 5 of which are PWM capable. This was an extremely important factor in choosing a microcontroller because to drive the wheels of IRIM it required 4 PWM signals. Since IRIM requires the use of the CC3100 and MPU9150 it was important to use a microcontroller that was capable I2C and SPI on independent lines. Both I2C and SPI are need simultaneously. The MSP430F5529 has two sets of pins that are capable of using these protocols. The MSP430 line of processors are ultra-low power consumption. The MSP430F5529 with all clocks active takes up 290?A/MHz at 8 MHz and runs with 3.3V-1.8V. This is a great feature to have for mobile power considerations because most mobile platforms are battery powered.The ODROID XU3 is a very powerful embedded Linux board. We sought this board out because of its capability to handle the Kinect data which has caused previous boards to freeze up. For example, IRIM was originally going to use the Beagle Bone Black. When the Kinect was plugged into the Beagle Bone, the Beagle Bone was rendered useless. Also, the ODROID needed to be able to run ROS. (Robot 63502397125Figure 2a: The L293D circuit and all its components. This is how we would connect it on the motor control board.Figure 2a: The L293D circuit and all its components. This is how we would connect it on the motor control board.6350000Operating System) this requires memory and processing speed. But with great power comes great power consumption. The ODRIOD XU3 requires 5V at 4A. This amounts to 20 Watts per hour! This will make it require its own power source.B. Integrated Circuits (ICs)IRIM does not require the use of many integrated circuits only two: voltage regulators, and H-bridges. These ICs help facilitate the design of the board by performing functions otherwise difficult to reproduce from scratch.Voltage regulators output a predetermined magnitude that remains the same regardless of changes to the input or load conditions. There are two kinds of voltage regulators: linear or switching regulators. Switching regulators differ from linear regulators because while linear regulators act as an adjustable resistor switching regulators act more, as the name implies, a switch. Switching regulators periodically store energy in the magnetic field of an inductor, then discharges the energy into the load. The time the switch remains closed between switches varies to maintain a constant output voltage. For IRIM, switching regulators were chosen because of their efficiency. Specifically, IRIM utilizes the LM2576-ADJ, which is a 3.0A 15V step-down switching regulator. This part was chosen because of its flexibility. The LM2576-ADJ is adjustable by changing the values for R1 and R2. The circuit is illustrated by figure 2a. This allowed us to use this regulator for the motors, MSP430F5529, and the logic voltage for the H-bridges. Vout is calculated using formula (1) and (2).Vout = Vref (1 + R2R1) (1)R2 = R1 (VoutVref - 1) (2)Where Vref = 1.23V, 1K < R1 > 5K H-bridges are extremely useful for motor control. They provide two functionalities that are imperative to the movement of IRIM. IRIM uses the L293D quadruple half H-bridge from Texas Instruments. Since it is a quadruple H-bridge this mean that it can drive two motors per IC. One of the functionalities the L293D offers is that you can drive the motor forward and backward by simply sending HI and LOW signals to the right pins. This makes going in reverse an easily attainable goal. For an autonomous robot this is imperative for object avoidance. Another functionality the L294D offers is making the motors PWM controllable. Controlling the motors with pulse-width-modulation is of upmost importance because without it we could not turn IRIM easily. PWM allows us to control the speed of the motors by cutting the voltage to the motors on and off to simulate lower voltages. Running motors at different voltage individually make turning possible by moving one side of IRIM slower than the other. IRIM can also turn in place by running the motors on one side in the opposite direction of the motors on the other side. This would not be a simple task whatsoever without the L293D. [3][4][15]C. LocomotionTracking of an object is important in mapping applications. A feedback system is required in determining if an object has reached the desired location. It is also necessary in determining where the object is within the space-time continuum. The choice of feedback systems primarily fell between GPS units or IMU. GPS was not considered due possible interference and low precision, 1 meter when the object needs to travel a distance of 1 meter, the alternative, the Inertia Measurement Unit (IMU), was not that much better in low speed situations but more appropriate than the GPS. The IMU of choice is the MPU9150, which is classified as a Microelectromechanical systems MEMS device. The IMU will provide 3-axis acceleration, 3-axis gyroscope, and 3axis magnetometer. Of the three, the Accelerometer and Gyroscope will be useful for the navigation stack. The Gyroscope provides angular velocity and the Accelerometer provides acceleration values, which can be converted to velocity values with a single integration over a specific period. However since the accelerometer is noisy it is not ideal to constantly sample the acceleration rather it is more accurate to take an instantaneous sample and reasonably assume the object will continue to travel at that velocity. The same can be said about the angular velocity. The constant integration of acceleration will compound the error known as sensor drift that is common in IMU’s. Although the Gyroscope yields angular velocity without the need for integration, it poses a second issue. The rotation in place actually causes the object to rotate in a jerky manner contrary to the assumption of a smooth rotation. The friction of the tires causes this. Since the wheels cannot rotate in an angular motion, due to their fixed positioning, they have to rotate around an axis, the center of the axle, however since each axle has its own axis of rotation this causes the two axes to fight for rotational supremacy rather than rotational harmony. Whenever the motors are able to overcome the friction a sudden acceleration occurs causing jumpy angular velocity values. Secondly, since there is a delay in propagating that data over Wi-Fi, the preferred communication, a better alternative would be to spoof the velocities and trick the navigation stack into sending itself the velocity. This will give the navigation stack the required data without having to worry about delay. The question now is how can one determine the time and duration of said sudden acceleration known as “jerk”? The MPU9150 is capable of detecting such instantaneous accelerations via the motion detection feature that sets a “jerk” flag. The acceleration that causes this jerk must have been sampled for at least 1ms. These two pieces of information gives us the time and acceleration needed for our integration where initial velocity is zero because the object will always come to a complete rest once it arrives at a goal.D. Power SupplyIRIM will have three power supplies. One power supply will power the MSP430F5529, a CC3100, a MPU9150, four 3-12VDC motors, and two L293D. The next power supply will power the ODROID XU3. The ODROID XU3 will receive its own power supply because it needs to be supplied with 5V at 4A. This is a lot of amperage! This is the max limit both the battery pack and the regulators can push out. If the power to the ODROID comes from the same source the motor control board is powered by there will not be enough amperage to go around. The last power supply will power supply will power the Kinect for Windows. The Kinect requires 12V at 1.5A. This is a lot to ask for from one supply so it was decided to give the Kinect its own supply. [5][6][7] E. CommunicationThe communication of the system is based on Wi-Fi. The embedded Linux board called Odroid XU3 interfaced with the Kinect contains a processor in charge of initializing, gathering, and making the transmission of the Kinect stream over Wi-Fi possible to the main computer by connecting a Wi-Fi dongle in the Odroid, which is where all the point cloud processing and 2D and 3D mapping is taking place. The other part of the communication of the system takes place between the accelerometer and the computer, in order to realize it, the use of sockets was employed for the transmission of data specifically the jerks happening when the robot starts and stops. This information is essential to create the appropriate commands for the navigation of the robot. III. Hardware Design DetailsThe hardware design was modeled in such a way to make space for all the parts mainly the Kinect sensor and the main board in the tiers of the platform.J BotIRIM’s mobile platform is the J-Bot v2.0. The J-Bot v2.0 is a four wheel drive, two tier rover robot. Each tire on the J-Bot is driven by four 3-12VDC high quality micro-speed motors. The dimensions of the J-Bot are 200mm x 170mm x 105mm. The base is a hollow case to house the four motors and a five-battery holder. The tiers are separated by spacers to allow space for batteries, micro-controllers, boards, etc. The height of the second tier can be customized by adding extenders to the spacers. Both tiers have holes of different size and shape to fasten attachments on to the plates as needed. The J-Bot v2.0 speed is listed as 90 cm/s, to put this in value in a better unit the J-Bot reaches speeds of 2.95 ft/s. This is a great speed compared to the other platforms considered for the project.The J-Bot v2.0 was chosen for this project because of its basic design that met all of our requirements for the rover. The requirements were that the robot rover should have a basic chassis design as to not over complicate the motor control. Also, having a basic design usually translates to a cheaper price for the robot. Price is important because as the title of the project suggests the rover should be ‘inexpensive’. The next requirement is that the robot should be big enough to allow space for everything needed to be put on the rover, most importantly the Microsoft Kinect. The Microsoft Kinect is most important because, not only is it what we will use to create a point cloud, but it will be the largest device on the robot rover. The Kinect is about 11 inches at its widest point which is the top piece, but the base is about 4 inches wide. It was decided that the chosen platform should be customizable, not just with space, but with parts as well. This will allow us to test different vantage points for the Kinect to see which works best. Also, the motors can be changed for other motors if more power is required. Another factor that worked in the J-Bot’s favor is the size and material of the wheels. The wheels are about 1.5 inches wide and the plastic rim is wrapped by a rubber tire. These tires are a lot better than the tires of other platforms considered. [2]B. Motor Control BoardThe motor control board was designed from scratch. The board incorporates the MSP430F5529, the CC3100, the MPU9150, both L293Ds, and all the LM2576-ADJs. The 7.4V battery pack will power this board. Power will be distributed to a few regulators that will make the 7.4V be stepped down to 3.3.V for the MSP430F5529, CC3100, and the MPU9150. 5V will be provided for the logic of both the L293D. Lastly, 7.4V will be taken in directly into the L293D’s V-motor pin. The voltage to this pin is the voltage that gets fed into the motors. This will be controlled by the PWM. When the PWM is at full duty cycle the motors will receive the full 7.4V at all times.Almost everything else will be attached to the MSP430F5529. The four PWM signals required for the motors and the enable HI/LOW signals will come from pins on the MSP430. Through code the PWM duty cycle can be controlled, thus controlling the voltage going through to the motors.Power DesignPowering IRIM will be achieved by lithium ion batteries in 3.7V AA cells. These cells can be recharged and supply 2200mAh. The batteries will be held by a PCB controlled battery holder. A few different battery packs will be used for IRIM. For the motor control board a two cell 7.4V battery pack that can supply up to 5A. The same battery pack will be used for the ODROID because it can supply everything the XU3 needs. Finally the Kinect will use a PCB controlled battery pack that holds 4 battery cells providing 14.8V at a maximum of 4ACC3100With many possible choices for communication available (Bluetooth, RF, and ZigBee), choices were not scarce. However, whether the application of any one of these available communications will be appropriate for IRIM was a serious design consideration. The result was to choose Wi-Fi as the preferred communication protocol. It posed no restriction in range due to the availability of Wi-Fi access throughout the university. There was no need to develop a communication protocol, communication stack, or data structures. With these major components, which are necessary for proper and robust communication between systems, already available and at our disposal more time was allotted for development of code and control structures as well as overall debugging of the system. The CC3100 by Texas Instruments was the communication module chosen for the robot. CC3100 is a low power module capable of interfacing with other low power MCU’s. It comes with an on board Arm MCU to offload Wi-Fi and internet protocols from the external MCU. It also comes with a driver preinstalled into the ROM. It is capable of 802.11 b/g/n. It complies with industry standard BSD Socket API. It can allow up to eight TCP or UDP sockets to be connected simultaneously as we as allow up to two TLS or SSL socket connections simultaneously. Since it is able to handle TLS and SSL connections, it comes with its own Powerful Crypto Engine for connections with 256-bit AES encryption. It is able to support up to WPA2 Personal and Enterprise Security. It is able to max out TCP throughput at 12 Mbps. It also has a low memory footprint on the host MCU as low as 7kB of code memory and 700 B or RAM. The power consumptions are very low. At idle the CC3100 consumes 690uA. When receiving data it consumes 53mA and when transmitting, it consumes 223 mA. For our battery-powered application, this chip is ideal. [13]IV. Software Design DetailsAutomationCommunication between the rover and the computer utilizes the Wi-Fi library that is available with Energia. The connection is a Server and Client structure. The CC3100 is the server and the computer is the client. The reason for this relationship is that the CC3100 will only provide data, acceleration and angular velocity, and do certain actions when told to. This is the definition of what a server does and accomplishes. The client, the computer, is the one making the requests and commands. Thus, the client and server relationship is justified. The CC3100 will constantly listen for a connection in the “waiting for connection” loop. Once it connects, it enters a second loop that listens for a command, hereby known as the “waiting for command” loop. Based on the command, which is either a simple F, L or R (for forward, left, and right respectively), it will enter a loop in which the robot will move in accordance to the command and will continue to keep moving until it receives a stop, denoted with an S, command. This command will cause the motor to stop and initialize any necessary variables. Once stopped it will break out of that command loop and return into the “waiting for command” loop. During the each of the command loop the MCU will send the raw acceleration and gyroscope data over the Wi-Fi once using the CC3100 and utilizing the I2C lines to extract the said values from the MPU9150. ?If for some reason the connection breaks between server and client, the code breaks from the “waiting form command” loop and jumps back into the “waiting for connection” loop.-2190752191385Figure 4a – Navigation Stack IO diagram00Figure 4a – Navigation Stack IO diagramWhen the client requires IRIM to perform actions such as going forward, backward, and turn in any direction instructions will be sent via Wi-Fi. These instructions will be simple in nature and will only be characters. For example, the character ‘F’ will be sent instructing IRIM to move forward. Any instruction given to IRIM will continue to be executed until a new instruction comes in. If IRIM is instructed to move forward it will do so until the stop command ‘S’. This achieved in Energia by simply setting the duty cycle of the PWM, and setting the logic bits to the direction desired for all four motors. PWM is set using the analogWrite() function on a PWM enabled pin. setting the logic of the motor direction is achieved using the digitalWrite() function. all this function requires is a pin and the desire behavior described by the enums HI or LOW.Socket ProgrammingIn order to realize the communication between the CC3100 and the computer the use of sockets were employed. Sockets are generally used for transmission of data and for this case the usage of stream sockets was the most appropriate, since the data meant to be transmitted back and forth must be accurate for the robot navigation to happen, this includes the order in which the data was sent and receive.The program to realize the communication between the computer and the CC3100 could have been written in Python or C++, since both of these two programming languages are supported by the operating system of the robot called robot operating system. The decision of working with python rather than C++ was the simplified syntax and therefore, ease of understanding when analyzing the code and preventing less hassle when troubleshooting. Another factor for the choice was the simplicity of running a script rather than compiling a program and running it. Python contains a module exclusively for sockets where all the functions are describe in detail. [1]C. Robot Operating Systems (ROS)Robot operating system is a set of open source libraries that help speed up the process of building a functional robot. ROS abstract the process of threading thus letting different modules of the robot such as image processing and motion control to function independently from each other. At the same time ROS also provide an interface where modules can share the same resources with each other. [8]D. Navigation SystemFor this project, we are using the ROS navigation stack. It is a ROS package which provides various combinations of navigation system. The figure 4a is the general setup of the navigation stack. The navigation stack input consisted of a goal provided by user or other package, the robot odometry data provided by motor encoders, the range data provided by range sensors such as Kinect, and optionally map data built by other package such as gmapping, a package for mapping using Simultaneous-Localization-And-Mapping (SLAM). With proper configuration, the navigation stack provides various services, mainly obstacle avoidance and path planning from the robot’s current position to the goal. The output from navigation stack is the directional velocity that the robot should move, which has the format of three values for linear velocity and three values for angular velocity. [9]Localization and Mapping For the robot to mapping the environment, we use ROS package Gmapping. Gmapping is a SLAM implemented package that utilizes robot’s position coordinates and laser-scan (range data) to create a 2D occupancy grid map. As the robot explores the environment, the Gmapping builds a map of the world and at the same time constantly attempt to correct the robot’s position within the map. The figure 4b is the map built by Gmapping package in the simulation environment Gazebo. [10]Figure 4b Map Built by GmappingExploration For the robot to autonomously explore the environment, we are using the ROS frontier exploration package. The frontier exploration take in the map data provided by mapping package such as Gmapping and determine the unexplored area. The output of frontier exploration is a goal in which the navigation stack can use to guide the robot. In this project, the frontier exploration will have a set of boundary where the robot is limited to explore. [11]3D Mapping In this project, we are using Kinect sensor which provide 3D data of point cloud. To fully utilize the advantage, we decided to use ROS package Octomap. The Octomap uses 3D occupancy grid approach to map the range data into 3D map (Figure 4c), which provides a much more detail about the environment compared to 2D map (Figure 4b). The Octomap require the sensor coordinate in relative to the static environment (the map) to function properly. In our project, we use the Gmapping localization capability to help the Octomap produce a more accurate map. [12]337502514795500Figure 4c – 3D Map built by OctomapCC3100 Code Communication between the rover and the computer utilizes the Wi-Fi library that is available with Energia. The connection is a Server and Client structure. The CC3100 is the server and the computer is the client. The reason for this relationship is that the CC3100 will only provide data, acceleration and angular velocity, and do certain actions when told to. This is the definition of what a server does and accomplishes. The client, the computer, is the one making the requests and commands. Thus, the client and server relationship is justified. The CC3100 will constantly listen for a connection in the “waiting for connection” loop. Once it connects, it enters a second loop that listens for a command, hereby known as the “waiting for command” loop. Based on the command, which is either a simple F, L or R (for forward, left, and right respectively), it will enter a loop in which the robot will move in accordance to the command and will continue to keep moving until it receives a stop, denoted with an S, command. This command will cause the motor to stop and initialize any necessary variables. Once stopped it will break out of that command loop and return into the “waiting for command” loop. If for some reason the connection breaks between server and client, the code breaks from the “waiting form command” loop and jumps back into the “waiting for connection” loop.MPU9150 Code The acceleration is acquired from the MPU9150 via the I2C lines. In order to achieve this a variation of the Wire library in Energia is used. The “variation” is the added functionality of using the second set of I2C lines on the MSP430F5529. The Wire enables the coder to access data on the I2C lines via the beginTransmission(), write(), endTransmission(), requestFrom(), read(), and available() methods. The beginTransmission() method takes in an address of the slave device as a parameter and begins a transmission to the I2C slave device. Subsequently the write() function queues bytes of data for transmission by taking a memory location as a parameter to be put in the TX buffer and then ?transmits it by the endTransmission() function. The write() method can also be used to write a value to the register by adding a write() call, with a number as a parameter, after the initial write() call. The argument specifies the value that will be written to the memory address specified by the previous write() call. The requestFrom() call places the number of bytes form the memory address specified in its arguments. These bytes can then be read one by one using the available() method that returns the whether the next byte is to be read and the read() method returns a byte of data from the buffer. With every command call within the main loop the Wire library is used and the raw acceleration and gyroscope values in the MPU9150 registers are read by the MCU.V. Conclusion Through completing this project, we have gained valuable experience and knowledge that will no doubt assist us in the future. Our original vision of a robot has changed in many ways. For some of the members in the team this was the first time working designing a robot. The project was challenging and our knowledge gained throughout the college career and many resources from UCF made the project a reality. The experience working as a team has prepared each member of the group to behave as professionals in the real world. Collaborating is one of the main factors employers look for in a recent graduate and this project has taught us besides the knowledge to become more efficient when interacting among team members share ideas and make progress by following deadlines created by the group. Engineering is definitely a process. This has been proven many time through the design and redesign of IRIM. Not everything has gone according to plan, but we have learned value lessons in the time we have spent on IRIM. Problem solving is the bread and butter of an engineer and it is evident why.VI. Biography-8255038481000 Ibrahim Shofiquel is a senior at the University of Central Florida. He plans to graduate with his Bachelors of Science in Computer Engineering in May of 2015. After graduation, he wants to start a career in the Orlando area working as a software developer.127004826000Hung Le is a student major in Computer Engineering at University of Central Florida. His philosophy is "Good engineer are those who work hard to be lazy." His dream is to make a robot that can free people from trivial chores or dangerous task, so we as a human can focus our mind toward better goals. Thus that naturally leads him to artificial intelligence, machine learning, and robotics.left12890500Alvaro Montoya is a senior at the University of Central Florida. He plans to graduate with his Bachelors of Science in Computer Engineering in May of 2015. Currently, he is an internship the DiSTI Corporation and has accepted a full time position there after graduation. After gaining some experience as a software developer he will pursue a Master’s degree in computer engineering.left34544000Jaime Quintero is a senior at the University of Central Florida. He is graduating with a Bachelor’s of Science in Computer Engineering. He has accepted an offer to work as a software engineer for Tata Consultancy Services in Miami FL. VII. REFERENCES[1] Socket Programming[2] J-Bot v2.0 [3] H-Bridge Info[4] L293D Info[5] Power Design Info[6] Lithium Ion Battery Info[7] Battery Holder Info[8] ROS[9] Navigation System[10] Localization and Mapping[11] Exploration[12] 3D Mapping[13] CC3100[14] MPU9150 ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download