Home

Team 1 - Simultaneous Localization and Mapping Robot (SLAM)

1. WORKS WITH Which Logitech HD Windows XP SP2 or higher Windows Vista and Windows 7 or 32 bit or 64 bit Webcam is Right for You For HD 1080p video recording Find even more at logitech com e 2 4 GHz Intel Core 2 Duo processor HD WEBCAM HD WEBCAM HD PRO WEBCAM ies RAP Meis C310 C615 C920 Hard drive space for recorded videos USB 2 0 port GOOD BETTER BEST For full HD 1080p and 720p video calling ihal io ipok tor u High definition HD video HD 720p Full HD 1080p Full HD 1080p with H 264 Minimum upload and download at least a 1 Mbps i connection for 720p video calling and 2 Mbps AA SE EE DMF for 1080p Always e 20 step p Focus type Gate Autofocus Autofocus Requirements for H 264 and MJPEG formats vary Builin holse cancallina mie Single Single PEDES Visit SOME preferred video calling provider 3 Auto light correction Premium Premium Premium website for information on video calling software EES E 1 CIICK video upioa O FaceDook requirements YouTube and Twitter HD 720p Full HD 1080p Full HD 1080p Video Effects Standard Premium Premium WHAT S IN THE BOX 360 degree full motion camera rotation o ET Fold and go webcam Mbs rote Portability EE Tripod ready base Vid HD for PC l Windows XP Windows Vista Windows 7 o o o E Scena Mac OS X 10 5 or higher e Tripod ready base 40 cm and beyond 10 cm and beyond Twitter uploading requires software download on the C920 To download
2. Product Name HP EliteBook 840 G1 Notebook PC Operating systems Preinstalled Windows 8 Pro 64 Windows 7 Professional 64 available through downgrade rights from Windows 8 Pro 64 Windows 7 Professional 32 available through downgrade rights from Windows 8 Pro 64 Windows 8 64 Windows 7 Professional 64 Windows 7 Professional 32 Windows 7 Home Premium 64 Windows 7 Home Premium 32 SUSE Linux FreeDOS Processor Intel Core i7 processor Intel Core i5 processor Intel Core i3 processor Chipset Chipset integrated with processor Memory DDR3L SDRAM 1600 MHz two slots supporting dual channel memory up to 16 GB total Internal Storage 320 500 GB 1 TB 5400 rpm HDD 320 500 GB 7 200 rpm HDD 500 GB 7200 rpm SED Self Encrypting Drive 500 GB 5400 rpm FIPS SED 128 180 240 GB SSD 256 GB SED SSD HP 3D DriveGuard 120 GB M 2 NGFF SSD planned to be available 402013 If selected any of the HDDs and SSDs can be configured as secondary storage Flash Cache 32 GB M 2 NGFF Expansion Slot 1 Media Card Reader Display 14 diagonal LED backlit HD anti glare 1366 x 768 14 diagonal LED backlit FHD anti glare slim 1920 x 1080 14 diagonal LED backlit HD anti glare 1600 x 900 14 diagonal LED backlit HD anti glare touch 1600 x 900 Graphics Integrated Intel HD Graphics 4400 Discrete AMD Radeon HD 8750M with 1 GB dedicated GDDR5 video memory Audio Visual HD audio wit
3. EDUCATION B S Electronics Engineering CSU Sacramento IN PROGRESS MAY 2015 EXPECTED GRADUATION Completed Courses Machine Vision Digital Control Systems Robotics Linear Systems Analysis Feedback Systems CMOS amp VLSI Electromechanical Systems Signals amp Systems Microprocessors Communication Systems Probability of Random Signals Solid State Electronics l l HONORS City of Roseville Above amp Beyond Award Fes 2011 Pride of Roseville Award 2011 Thomas Hayward OBJECTIVE A position leading to a career in Software Engineering EDUCATION Bachelor of Science Electrical and Electronic Engineering California State University Sacramento GPA 3 20 Expected December 2015 STRENGTHS Teamwork Over 11 years of team building experience while serving in the United States Navy Problem Solver Skilled troubleshooter who can resolve errors quickly System Development Fully capable of creating innovative solutions to complex problems in C Python RISC Assembly Octave Matlab and PSPICE Communication Routinely provides informal and formal training to small and large groups regarding regulations and professional knowledge Experience in drafting meticulous documents while working as a paralegal Office Computing Proficient with PowerPoint Project Excel Word Access and SharePoint RELATED PROJECTS Simultaneous Localization and Mapping Robot Project is inspired and sponsored by Schillings Robotics FMC Technologie
4. Basic configurations such as username and pass word are left to interpretation The only major requirement is that the system is installed onto LVM software to be discussed in a later section Once the OS is installed it may be wise to perform a bit wise backup of the system using cloning imaging software such as Clonezilla or for more experienced users Unix s dd command For this project a base image was produced using Clonezilla directly after the Ubuntu 14 04 installation procedure User Management To simplify user management 1t is proposed that we have one login to the laptop This complicates some things primarily for those who develop on the laptop itself While running a git push there will be no sufficient blame history if everyone s pushes come from team 1 To assist with this massive design issue I have set the git global config user name to teaml This at least gives a little better blame history File and Software Management Considerations Considering there will be four developers main taining code that will likely be ran from one laptop there will often be need of a way to distribute the code Github was chosen as our distribution platform and git was chosen for our revision control system In terms of outside software stuff that we did not develop ourselves it is wise to keep this out of our github repository Any software that you borrow should be added to the gitignore file and docu
5. Covariance GUI for adjusting Covariance Recieve user defined covariance or send default Transform information into robot reference frame Convert data type and append to Covariance Send data to EKF EKF recieves data Fig 20 VO Signal Path is the backbone of other SLAM algorithms and has a long history of proven success One of the biggest factors in determining whether or not to utilize this particular software was that it 1s heavily documented It is designed to take inputs from VO wheel odometry and IMU input It will then fuse this data and publish the outputs The first step in setting up to utilize the filter node was to figure out the particular data types and topic names in subscribes to By using the inputs as our starting point it allowed us to figure out what pre processing and conversion needed to be performed on the individual data sets prior to publishing them to the filter It was during this initial step that we discovered that we were going to need to capture all data sources and append our estimate of the covariance to it We created a C class that captures the output of the kinematic calculations and VO subsystem The kinematic calculations occur inside of the same class and do not need to come from external input The output is stored in the previously discussed vectors where it waits until time to be published to the robot pose ekf node The slower input is the VO so when the output
6. 1 square pieces and then snap them together into 4 sets as shown in Figure 12a Peel off one side of the adhesive on each of the four sets and stick them to the underside of your laptop Then remove the protective film from the four sets and carefully place your laptop onto the upper deck If properly applied you should be able to remove your laptop and re attach it as required Your Robot should now resemble that shown in Figure 12b Using the 5 zip ties bundle excess lengths of wire so that all conductor routing is clean and organized This completes Eddie s hardware assembly Congratulations Additional Specifications 17 8 45 1 cm diameter circle Ground Clearance 0 88 2 23 cm Wheel Center to center Distance 15 4 39 0cm Operating Temperature 32 to 158 F 0 to 70 C 1 Maximum cargo capacity is the suggested maximum cargo weight for typical operation The robot may be able to carry additional weight but this is not guaranteed and may result in diminished performance or mechanical failure 2 Runtime is approximate and depends on many factors 3 Ground clearance is limited by the screws to mount the battery support tray Minimum ground clearance is directly between the two main drive wheels Clearance in other areas is greater 4 Eddie is designed to be operated indoors Additional Resources and Downloads Visit www parallax com eddie for additional information and the latest product documentatio
7. In order to compensate for the massive amount of wheel slippage on their robots NASA used VO 2 The results of using VO were highly effective and even compensated for the imprecise odometry data coming from the encoders Stereo based VO implementations are more ac curate and typically produce better results as shown in 3 The main reason for this 1s due to the scale ambiguity problem a monocular system cannot determine the scale of the odometry that it produces 4 Our goal is to make our system platform in dependent If we require our system to be a stereo implementation there are many complex calibration steps that need to be run in order to produce valid data By avoiding stereo 1mplementations we are able to skip the complex extrinsic calibration steps This will simplify the calibration which will then allow our system to run on most platforms Because we are only using one camera for our implementa tion we will have to focus on a monocular solution to VO Various implementations of monocular SLAM currently exist and most of these require fixed cam era heights in order to attach a scale to the odometry output such as 5 and 3 We will attempt to avoid these assumptions in order to make our system platform independent If it is decided that we need scale output from our VO system we must be able to assign the camera height of the system by assigning it as a variable at run time 3 Ranging Computing the output from
8. This should greatly increase our tuning and debugging time of the filter The GUI allows us to monitor the output of our data sources as well as update our estimate of the covariance The overall design was intended to be functional and not for presentation during our end of project presentation The node that contains this GUI is written in python QT4 This same node also allows the user to update a text file that 1s read 2T Input dialog Data odm x 0 0000 vo x 0 0000 ekf_x 0 0000 alv x 0 0000 vo y odm y 0 0000 ekf y 0 0000 alv y 0 0000 VO Z 0 0000 odm z 0 0000 ekf z 0 0000 alv z 0 0000 vo thx 0 0000 odm_th_x 0 0000 ekf th x 0 0000 alv th x 0 0000 vo th y 0 0000 odm_th y 0 0000 ekf th y 0 0000 alv th y 0 0000 vo th z 0 0000 odm th _z 0 0000 ekf z 0 0000 alv z 0 0000 vo th w 0 0000 odm th w 0 0000 ekf w 0 0000 alv w 0 0000 Update VO Covariance Cov Update Fig 21 Covariance Adjustment GUI during run time that contains the default covariance values for all data sources The file is updated each time the user sends a new covariance update The current EKF C code doesn t access this file directly it subscribes to the covariance updates via ROS topics This allows a user three options to adjust the default covariance adjust in the C pre filter code adjust the text file or dynamically change the value in the GUI We feel that we are
9. accuracy of the III AIb Section delivers an es timate of the robots position within 30 when compared to ground truth when performing simple b Testing amp Debugging of Visual Odometry We have to verify that this system works by itself before we include it into the main project In this stage we will attempt to estimate any errors and limitations associated with this feature This test ing and debugging stage involves attempting to fix errors and bugs produced by improperly calibrated sensors or software issues In the case that an error or bug cannot be fixed it is to be documented for later tweaking e Estimated Time e Estimated Cost 0 00 e Assignee Curtis amp Francisco e unDeliverable A software object that can gen erate odometry data from a moving camera c Testing amp Debugging of Filtering We have to verify that this system works by itself before we include it into the main project In this stage we will attempt to estimate any errors and limitations associated with this feature This testing and de bugging stage involves attempting to fix errors and bugs produced by improperly calibrated sensors or software issues In the case that an error or bug cannot be fixed it is to be documented for later tweaking e Estimated Research Time 5 e Estimated Implementation Time 65 e Estimated Cost 0 00 e Assignee Chris e Deliverable A set of tests that ensure that the filter is performing as expected to
10. as shown in Figure 3c The IR cables are polarized Line up the tab on the cable and insert it into the receptacle Be sure to fully insert them they should click into place Set these assemblies aside for now Copyright O Parallax Inc Eddie Robot Platform 28990 amp 28992 v1 1 1 16 2013 Page 5 of 17 65 Step 4 Battery Shelf Preparation Figure 4a As shown in Figure 4a the Battery Shelf components consist of a Delrin shelf 6 1 2 tall round aluminum standoffs and 6 4 40 x 5 8 screws The physical sizes of SLA batteries differ depending on brand and capacity Figure 4b shows typical locations for standoff placements for the batteries that come with the Eddie platform Mount the standoffs in hole locations that provide the tightest fit for the batteries that you re using Place the Delrin shelf so that the Parallax Logo is face down and attach the standoffs as depicted in Figure 4b Figure 4b Set the Battery Shelf Assembly aside for now Copyright O Parallax Inc Eddie Robot Platform 28990 amp 28992 v1 1 1 16 2013 Page 6 of 17 66 Step 5 Main Base Assembly Place the two pre assembled Casters and Motor Mounts a shown in Figure 5a Orient the Base Plate so that the two sets of three holes in a triangular pattern are visible face up as shown in Figure 5a These are blind holes they do not go all the way through The Caster assemblies are attached from the bottom of the Base with
11. draw on that image creating the display we needed This node is built into a parent node that contains the kinematic model and pre filter functions This design choice was made because it allows all three of these sections to have access to the same data storage containers The data storage containers we chose to use are the C standard vectors This design choice was made because they are easy to use and highly documented They allow much faster processing time than using standard C arrays and take care of dynamic memory processing much easier than doing 1t manually The use of standard vectors minimizes the chance of memory leaks when compared to implementing data storage alone A vector is created for the outputs of the kinematic model visual odometry and EKF The map then has access of this information so it can plot the location The first step when creating the map was to decide on how much space the image should take up Originally we went with a smaller window but this greatly decreased the ability to get precise visual information from the display We then set 1t up to maximize upon opening Now that we knew the working environment of our display we set out to actually create our display We elected to assume that our environment in square for the display purposes If 1t turns out to be another shape it will still fit inside of a square with minimal rescaling We split the display into two regions one containing the square
12. iii 22 22 33 I DESIGN OVERVIEW A Introduction People who work within hazardous environments inherently put themselves at risk for injury Rescuers entering a collapsed mine a structural engineer evaluating a building after an earthquake or a doctor providing treatment to an infectious patient are all occupations that carry an inherent risk of injury to the person performing their task The risk is great due to the fact that the person needs to physically enter or operate within the hazardous environment One solution to this problem is to have an autonomous robotic platform perform these same tasks thus removing the individual from the risky environment altogether However in order to have a truly autonomous robotic platform the platform must be able to discern its location at any given time In the field of robotics this unique problem is better known as the Where am I problem This 1s a fundamental robotics issue One method to solve the Where am I question is to implement Simultaneous Localization and Mapping better known as SLAM SLAM allows the robotic platform to take in sensory data from its environment using cameras IR sen sors Ping Sensors gyroscopes or accelerometers and then fuse this data with wheel encoder data to create an accurate map of its surroundings Ideally a SLAM algorithm can be modified to adapt to any robot platform and be used to maintain a fixed position or localization in an unknown env
13. ADC ADC SchDoc 12V 5V IIN E Aux A NB AUR Aux SW SchDoc SE Bes ES o m o m m o m E J12 J13 J14 J15 AUX A Aux_B 5V ea Aux_SW SchDoc C48 22uF AUX B 5V VBAT Spare GPIO 1 P12 R40 O0 ohm 1 Aux C P Ri bad VBAT Aux Aux SW SchDoc MTGI potim BS DNI Digital I O li db J16 AUX C MTG2 Es Fan Optional Note For possible cooling fan see MTG3 Digikey 259 1463 ND i EN Board 1 Q5 MTG4 D e 1 Sheet n Size Encoders x System Integration SchDoc Letter ES m iis Description Top level system integration schematic aw 5 z Za L Project Eddie Control Board Part 5590 28990 Rev A 300 28990 ge e TM 599 Menlo Drive Date 10 10 2011 PAAl X Z Rockin CA 95765 Sheet of FI www parallax com Drawn By K McCullough 1 2 3 4 54 Design Note TXD and RXD must be buffered to prevent back flow through the I O pin into the power net of the IC which can weakly power on the device USB 3V3 Es Hi luF USB VCCIO FT232RL 74LVC1G126 R47 270 R48 270 USB_3V3 R44 10k C50 0 luF Only populate this resistor if USB_3V3 doesn t decay to ground fast enough after USB is removed USB VECIO Sheet Le USB to Serial SchDoc Letter Description USB to Serial interface Project Eddie Control Board Part genge REV A ZC TM 599 Menlo Dri Date 10 10 2011 PARAI X Z Rockin CA 95765 Sheet of FI
14. Kinect such that the Cam Hooks go into the rectangular holes The Cam Hooks will not come all the way through they ll be just below the surface of the acrylic Now place washers onto the 4 40 x 4 long black pan head Phillips screws and screw them into the tapped holes in the bottom of the Kinect Cam Hooks as shown in Figure 11e Figure 11e Step 12 Kinect Mounting and Cable Connections Slide the rectangular Screen Clip down onto one of the 12 long standoffs as shown in Figure 12a Using two 14 20 x 34 black button head screws attach the Kinect Plate assembly to the top of the two 12 long aluminum standoffs Route the Kinect cable alongside the remaining 12 standoff attach it with the 4 cable clips and pass the cable down through the large thru hole in the Top Plate Attach the Kinect Cable to the Kinect Cable Adapter and then plug the two pin power jack on the Kinect Cable Adapter into the Kinect Power plug on the Eddie Control Board Connect a USB mini B cable to the USB connector on the Control Board and route it up through the cable hole on the Top Plate Figure 12a Figure 12b Copyright O Parallax Inc Eddie Robot Platform 28990 amp 28992 v1 1 1 16 2013 Page 16 of 17 A strip of self adhesive Velcro like material is included if you wish to mount your laptop computer onto Eddie s Second Deck Although you can attach your laptop anyway you choose a convenient way to do so is to cut the strip into 8
15. Parallax Robot Platform USB ra IMU 3 Additional Ping IR Sensors Microcontroller Laptop Breadboards Miscellaneous Connectors Wire Environment Setup Unexpected expenses Custom PCB for external sensors 2 850 III WORK BREAKDOWN STRUCTURE This project is going to be developed by a group of four individuals To manage the work breakdown of this project careful consideration was taken with the background of each person in mind and was therefore assigned specific tasks to complete A Outline of WBS As described in our design idea contract this project involves designing building and imple menting a software algorithm for use on mobile robots that work inside of hazardous environments With an aggressive nine month time line the work breakdown is as follows 1 Kinematic Model This feature should include software that gathers angular velocity information from the navigation path planning software or en coders and uses this angular velocity information to create a kinematic model of the robot for local ization purposes The same kinematic model should be the mathematical basis for use by the navigation and path planning model to perform the inverse operation a Capture Angular Velocity Information A fundamental feature of our system will be the need to interface with a robotic platform and software to convert raw data to useful information The angular velocity information provided should distinguish between the lef
16. Sheet of 599 Menlo Drive PASA NZ Z Rocklin CA 95765 Y N V1 www parallax com Drawn By K McCullough 4 50 3 3V 1A Regulator APITI7D33L 13 CI C12 C13 10uF 10uF Oink is b Circuit Details Minimum 10uF cap 0 150hm lt ESR lt 20ohm must be connected on output Input Voltage Requirement For proper operation VIN should be greater than 4 7V Guaranteed max dropout is 1 4V at full 1A load Component Details Component is rated for up to 1A output and thermally protects at 150 degC For TO252 3L package Thermal Resistance Junc to Amb is 73 degC W Therefore derate below 1A for temperatures above about 25 degC when VIN is at 5 0V Sheet Le Power_3V3 SchDoc Letter Description 3 3v linear regulator Project Eddie Control Board Part 550 28990 R A N 5 TV 599 Menlo Drive Date 10 10 2011 PAAl A A Z Rocklin CA 95765 Sheet of PY wu paren com Drawn By K McCullough 2 3 4 51 5 0V 3A Regulator Circuit Details Connect the EN pin to VIN to automatically turn on the regulator when power is available Pull this pin low to disable shut down the regulator reduces supply current to less than 3uA A DNI This is an alternate part 501 10008 D4 RB751S40TIG BOOT Circuit Details nee aes DA
17. at run time One of the inherent problems with the libviso2 library is the fact that it cannot handle data from the camera 1f the data gathered was a result of pure rotation about its non fixed axis If pure rotation data is inputted then the fundamental matrix cannot be trusted This is due to a common problem in fun damental matrices known as matrix degeneration This can happen when the fundamental matrix fails to find a unique solution to the epipolar transform between image frames 12 While implementing the library was incredibly fast and easy thanks to pre written ROS nodes found online this library has consumed a lot of time in testing and debugging Initial tests seemed like the library was producing usable results but we needed a way to view the data Once our visual display was implemented we noticed that the data was far from perfect A lot of testing and research went into tweaking the many parameters of our system to optimize for the VO data While the incoming data has improved over the past few weeks the continued use of libviso2 1s putting many difficult constraints on our overall system We are actively trying to refine the VO system and find the constraints of libviso2 so that we can implement path planning methods that can work around them H Probabilistic Filtering The overall purpose of this sub system is to minimize the effects of noise or error in the sensor readings and fuse the data from multiple sourc
18. compensate for imprecision s on wheel encoder systems When working with wheel encoders on mobile robotics there is no guarantee that the robot traveled the distance that the wheel encoders measured If the wheel spun out or slipped the encoders still counted motion which makes the robot think that its platform has traveled when it actually hasn t VO is used to help fix this localization problem While the VO sampling rate is often much slower than the wheel encoder sam pling rate it can help alleviate the wheel slippage problem When 100 wheel slippage occurs in a visual odometry system no motion is measured by the camera because the camera did not see any change Because of this there is no motion output from the odometry system which drastically helps overall control systems in compensating for robots that operate in these high slippage environments Our robotic platform needs to be able to carry around a camera that will be used to perform VO The specific system is unimportant our design needs to be able to have a module for VO to be plugged into This modularity is important to our project as it will allow us to replace any given set of VO libraries for another One goal is given enough time be able to test out several VO libraries chose the best option for our system and produce recommendations for future robotics groups FMC Technologies Schillings Robotics requested that we implement a monocular VO system which has
19. feature e The ability of the PC Software to prevent collisions 6 Serial Communication The Serial Commu nication model will be used to send data to and from the robots chassis control board and the laptop The data being transmitted will be converted in the is node to allow decimal communication instead of hex as the board requires The feature will be realized in the laptop as C code and hardware connection will be with a standard USB cable For the purposes of this section input will refer to data coming from the robot control board into the laptop and output will refer to data being sent from the laptop to the robot control board This feature involves event triggered programming techniques so we will be testing in 2 number of phases a Phase One A key element of the feature is its ability to convert data Specifically the Robot Control Board requires that numerical values be transmitted in signed Hex stored in a standard C string This is not a standard form of numerical notation and is very hard for a human or C program to interpret the data This feature will handle bidirectional conversion between the decimal and hex c strings This Phase will test the following elements of our system e The reliability and accuracy of our conversion algorithm b Phase Two The second stage of testing for this feature will be reliability of the overall connection between the two devices This test will involve sending data from a
20. from the image must be processed using computer vision techniques In the case of a high resolu tion cameras each frame can be comprised of an enormous amount of data making this processing very challenging Because cameras produce so much data and to work with them requires very com plex linear algebra standard microprocessors do not have sufficient processing power to satisfy our requirements Vision processing must be done with a computer using heavily optimized visual tools To help assist in optimization we need the ability to run processes in parallel with each other Having the ability to process our vision data separately from our other processes will greatly improve our overall system performance 2 Visual Odometry The robotic platform must be able to discern locomotion through visual stimuli In order to satisfy this requirement we are to implement a system to perform VO This concept is relatively new having only been around for about a decade and exists in both monocular and stereo forms The overall process revolves around gathering motion data by processing sequences of frames that are on a moving platform Most im plementations follow the models presented in early VO research such as analyzing the optical flow as shown in 1 One of the first usages of this tech nology was on the Mars rovers In high wheel slip environments such as those found on extraterrestrial bodies wheel encoder data becomes almost useless
21. handling or error checking prior to sending data to this node D Filtering 1 Non Linear Filters can be difficult to tune properly Very High Medium 2 We are using open source software to perform our filtering tasks and they might not be fully functional High High Steps Taken to address risks 1 We have started implementing testing and debugging protocols to make sure that we eliminate as many environmental variables as possible during tuning 2 We have heavily researched Non Linear filters and linear algebra libraries to ensure that if the software fails we can implement a filter with minimal time delay E Collision Avoidance Ultrasonic Sensors cant see all materials or objects Our robots workspace is small so collision avoidance is difficult and we might crash without perfect sensor data Medium Medium Steps Taken to address risks 1 We have IR sensors that can be brought into the system to allow a total of 10 close prox imity sensors F Communication with Robot Chassis 1 Serial Communication can be prone to error Medium High Steps Taken to address risks 1 We have allocated a lot of testing time to ensure that this module 1s tested thoroughly G Visual Odometry Interface 1 We are using open source software and we are unaware if it has been tested on an au tonomous mobile robotics Very High Very High 2 Current implementation does not implement error checking and a
22. hugger method Item 6 Collision Avoidance is an integral part of our system it is needed to successfully avoid obstacles within the unknown environment The Fall semester saw a prototype implementation of this feature The spring semester oversaw the implementation of path planning facial recognition and refined visual odometry filtering interface After these fea tures were initially implemented we spent our time fine tuning the system in full feature system testing refining the usability of our platform as we contin ued to test and fixing issues that we encountered along the way Now all of our features have been implemented and integrated into a working system B Project History Near the end of the Spring 2014 semester FMC Technologies Schillings Robotics approached Sacra mento State University to look for a team to take on a project for them during upcoming senior design year They were looking for a team that would be interested in designing and building a visual based SLAM robot It was this pitch that interested and rallied four young students to come together as Team One After some paper work and the signing of several non disclosure agreements Team one was officially sponsored by FMC Tech nologies Schillings Robotics Team one composed of Chris Laney Thomas Hayward Curtis Muntz amp Francisco Rojas Each student brings a unique background to this project A brief summary of each student is provided in the secti
23. in a strong position to finish the filter tuning in a timely manner The initial testing of the overall system seems to deliver within the required accuracy of 30 and we are on track to completing this feature We spent many hours teaching us the fundamentals of the EKF as well as understanding the implementation and limitations of the robot_pose_ekf node IX MECHANICAL DRAWINGS AND DOCUMENTATION The mechanical portion of this project is limited to the robot chassis The robot structure consists of a top and bottom deck pair and an undercarriage for holding the batteries This undercarriage serves to prevent any acid spray should a battery burst and also isolates the batteries from electronic compo nents on the decks above The robot was assembled per the instructions in Parallax s assembly documentation These instruc tions have been included in the Appendix X TEST PLAN FOR HARDWARE The majority of hardware we are using 1s com mercially available off the shelf hardware Due to the nature of the software requirements we elected to spend very little time on hardware testing If the hardware fails during software testing we elected to diagnose those errors on the spot We had originally hoped that by purchasing an expensive turn key robot that we would avoid the majority of issues that could arise from such a complicated piece of hardware This turned out to be a very flawed plan The fact 1s that the one of the single b
24. in software development that resulted in a cost savings of 1 169 200 e Awarded Navy Achievement Medal for initiating engineering investigations relating to faulty test set hardware while working as an automated support system technician 78 79 Christopher Laney Summary of Qualifications Electronics Technician with comprehensive experience in both civilian and military small and large scale communication systems RADAR commercial electrical wiring including generators and a multitude of electronic and computer systems Extensive experience at board level discrete component repair Effective at training technicians and laypersons Industry Certifications e CompTIA A and Network Plus Certified e NFPA Certified Electrical Safety Compliance Professional CESCP Accomplishments v Engineered electronics communication interface between newer large scale multi user system and existing peripheral communication devices Y Increased propgation characteristic parameters of communication trasmission stations by improving ground plane characteristics designing filter modifications and recalculating A spacing height adjustments for improved lobing patterns Professional Experience Defense Companies 1997 Present e Maintain and repair electronics equipment e Troubleshoot and design solutions to equipment problems Technical Skills Test Equipment Oscilloscope Spectrum Analyzer Vector Volt Meter Network Analyzers RF generators and mos
25. lot of event triggered functions so testing the input and output is essential to ensure proper display This phase will test the following elements of this feature e The ability of the program to reliably receive data from multiple sources e The ability of the program to convert received data into a visual map b Phase Two This phase of testing will be to help gauge the accuracy and precision of the visual display A program will be created to drive the robot for a preset distance After the robot has travelled that distance we will measure the ground truth distance travelled and compare it to the visual display As this will involve using a floating point scale to assign a distance to each pixel we will need to be cautious of rounding error as our environment grows We well be testing the visual display from distances between 0 to 6 meters for accuracy We require that the map be at least 10 This phase will test the following elements of this feature e The ability of the visual display to produce accurate map data 4 Filtering The Filtering feature 1s a combi nation of third party and custom a C program The overall structure of the filtering feature is to capture data from the vision feature as well as the kinematic model We will then convert this data to an appropriate data type and when ready publish the data to the third party EKF The actual EKF is 3rd party software and will need to be tested thoroughly We will t
26. most industry test equipment Hardware Discrete component and IC chip project design using various chips types FPGA s Parallax Propellor IC MicroChip IC s etc Education A S Degrees in Mathematics Physics Engineering Electronics Technology
27. obstacles will have a circumference between 12 30 cm and a height between 12 cm 30 cm This will ensure that the collision avoidance feature can see the objects The robot will be placed at a predetermined starting point and an explore command will be sent from the control GUI The path planning node will be required to navigate throughout the room until it has explored all spaces without colliding with any obstacles or getting stuck in corners This Phase will test the following elements of our system e The ability of the path planning node to control wheel velocities e The ability of the feature to navigate and ex plore its environment b Phase Two This phase of testing will be to ensure that the path planning feature can collect data from the collision avoidance feature as well as the goal detection feature The path planning feature should be able to successfully interpret that data and store it This test will be performed by broadcasting messages from the collision avoidance feature as well as the goal detection feature Testing if the path planning node is receiving the data can be performed by printing the received data from the data structure in which it is stored This Phase will test the following elements of our system e The ability of the feature to store values from collision avoidance and goal detection c Phase Three This phase will test the ability of the path planning node to go to two predeter mined goal
28. requirement of any robotics system is to use the sensor data and an estimate of the error associated with that data to increase the accuracy of the system There are many types of filters used in robotics to perform this task These filters are based upon using probability to increase the likelihood of gathering viable data from multiple sources In essence they are the fundamental building blocks of sensor fusion required in SLAM They usually are derived in some form of Gaussian or Markov filters They each have their own advantages and disadvantages A complex description of all possible filters is beyond the scope of this paper The two most common filters used in autonomous mobile robotics SLAM systems are a particle filter or a Kalman filter that has been extend to function on non linear systems Systems based upon particle filters are often referred to as FAST SLAM systems The general concept of the particle filter 1s to track as many key points via the primary sensor as possible and form a mathematical relationship between those points to gather information about the systems location and pose They track many more features for mapping than an Extended Kalman Filter EKF Particle Filters have proven to be highly effective but are still experimental A disadvantage of the FAST SLAM approach is that it is so new that using it as a solution to our system will be difficult Another difficulty is our system will be need to incorporate loc
29. robotic platform are wheel encoders As each wheel spins the sensor will gather data about the angular position change of the wheel Once the encoder input has been captured it must be converted to linear velocity and used by a robotic kinematic model to create an estimate of the distance traveled and possible error There are many ways of creating this model The mathematical model of the robot platform routinely becomes more complex as the number of drive wheels are increased An example of just how com plex these mathematical models are can be found in 8 However the most common and heavily documented robotic platform is the differential drive robot 5 Differential Drive Robotic Platform There are many advantages to designing our system to in terface with a differential drive robot Do to 1ts pop ularity there are many differential drive platforms available for use It provides a superior amount of maneuverability in confined spaces It is also used as the basis for modeling more complex robotic drive systems that have similar drive characteristics The differential drive kinematic model easy to compute because it has forward velocity and its lateral ve locity can be set to zero in calculations It is well documented and by using a well researched model we can get a strong estimate of our robots location from the velocity information collected from the encoders 6 Filtering There 1s an inherent amount of error in any sensor A
30. scale and test for limitations d Testing amp Debugging of the Visual Display We have to verify that this system works by itself before we include it into the main project In this stage we will attempt to estimate any errors and limitations associated with this feature This test ing and debugging stage involves attempting to fix errors and bugs produced by improperly calibrated sensors or software issues In the case that an error or bug cannot be fixed it is to be documented for later tweaking e Estimated Research Time 5 e Estimated Implementation Time 25 e Estimated Cost 0 00 e Assignee Chris e Deliverable A set of tests that ensure that the map is to scale and test for limitations e Testing amp Debugging of Path Planning We have to verify that this system works by itself before we include it into the main project In this stage we will attempt to estimate any errors and limitations associated with this feature This test ing and debugging stage involves attempting to fix errors and bugs produced by improperly calibrated sensors or software issues In the case that an error or bug cannot be fixed it is to be documented for later tweaking e Estimated Research Time 5 e Estimated Implementation Time 30 e Estimated Cost 0 00 e Assignee Chris e Deliverable A set of tests that ensure that the accuracy of the III A2 Section delivers an es timate of the robots position within 30 when compared to ground
31. short screws that do not mar the finish of the top side Figure 5a Use the 7 64 ball end Allen wrench to screw in the 3 3 8 long socket head cap screws to attach each of the Caster Wheel assemblies to the Base as shown in Figure 5b Make them snug but do not over tighten Before you mount the drive wheels to the Base verify that the ID jumpers A and B on the Position Controller for the left motor are set to 1 both jumpers installed and that the ID jumpers on the right Position Controller are set to 2 A installed B removed See Motor Mount and Wheel Kit for additional information Copyright O Parallax Inc Eddie Robot Platform 28990 amp 28992 v1 1 1 16 2013 Page 7 of 17 67 Figure 5b Flip the Base over as shown in Figure 5c and attach each pre assembled drive motor unit to the Base using 2 x 20 button head screws for each motor as shown Tighten using a 5 32 Allen wrench Connect 2 long three pin servo extension cables to each of the Quadrature Encoder Boards Be sure to observe proper polarity as noted on the Encoder board silk screen Connect each of the other ends of the cables to the Control Board when it s installed It is recommended that the cables are routed across the top side of the robot platform Figure 5c Copyright O Parallax Inc Eddie Robot Platform 28990 amp 28992 v1 1 1 16 2013 Page 8 of 17 68 Step 6 Control Standoff Assembly Insert 8 4 40
32. suo 6I v ecu Soi sele comio y cine So ssd e eloIgHE Le ra ero deraulrts sucio neren Et cq e esla cc Memeo mma i dcconrv setquis sudo su P0 Swe eel teur restart ssh Listing 7 SSH Configuration Script Pre compiled ROS installations There are two main nodes that need to be installed for our software to work correctly The first 1s the camera driver uve camera Next for serial communication it is wise for us to use pre existing drivers provided through rosserial These are installed using the commands in Listing 8 Y de lada sudo ope ger Install ros Indigo yc camera sudo apt get install ros indigo rosserial roscd rosserial sudo apt get install ros indigo rosserial NO sudo apt get install ros indigo ar crack aare Listing 8 ROS Third Party Software Installation Script Configuring Arduino IDE Dailout and rosserial arduino Because the arduino is used in some of our nodes we have to configure some backend options First the Arduino IDE should have been installed by our very first script Launch the IDE from Ubuntu s menu The permission prompt shown in Figure 23 is how we enable dialout for our system Dialout 1s required any time the Ubuntu system wants to talk over teletype tty Click the add button and give the system the sudo password Arduino Permission Checker You need to be added to the dialout group to upload code to an Arduino microcontroller over the USB or seria
33. the spacers on each assembly n each case make sure the labeled or etched sides of the Stands are on the opposite side from the sensor assemblies For the IR module insert two 5 8 long black machine screws through the mounting holes from the backside of the module Place 1 of the 1 8 long spacers and 1 of the 14 long spacers on each of the machine screws as shown in Figure 3b Carefully align this assembly onto the backside of the acrylic IR stand and gently tighten each of the machine screws until they re snug Nuts are not required The machine screws will cut their own threads as you screw them into the acrylic Do not over tighten Assemble the Ping module by sliding a 1 16 thick nylon spacer onto each of the two 5 8 long black machine screws Insert these screws with the 1 16 washers through the Ping s PCB mounting holes Copyright O Parallax Inc Eddie Robot Platform 28990 amp 28992 v1 1 1 16 2013 Page 4 of 17 63 64 Place two Y4 long spacers onto the screws and align the screws to the self tapping mounting holes on the acrylic stand The screws will cut their own threads Screw them all the way in but do not over tighten Figure 3b You should now have assemblies that look like those shown in Figure 3c Repeat these steps for the remaining Ping and IR Sensor assemblies Figure 3c Connect the appropriate cables to each of the sensors Be sure to observe proper polarity on the Ping cables
34. these point in time snapshots The scripts that we use for local backups and then scripts for offloading local back ups using snapshot technologies can be seen in the later sections labeled Backups and Restores respectively To continue with the install we have to customize our LVM install a little bit We need to make space for a new logical volume where we can dump our backups onto for a primary backup solution To accomplish these tasks reboot into a LiveOS like Ubuntu click try and open a terminal Type the commands shown in Listing 1 sudo su lyreduce resizes slze 50G cey USAS oT Listing 1 LVM configurations Next reboot the computer and load into the native install of Ubuntu in order to finish the LVM configurations Type in the commands shown in Listing 2 In this stage we create logical volumes on top of our newly free space for a backup mount point and add this to auto mount during startup using fstab suco su lvcreate name backups size 40G ubuntu vg mice cesa de AINT eus Uta ly e S d mkdir backups 41 Inoue de mapper bs Bier cups beckups des mappe ubuneu vo backups b acku ups e tA deme IR yy cic E Sie SO Listing 2 LVM Finalizations Verify that the automount works by rebooting the OS and checking if dev ubuntu vg backups 1s mounted In our project after these configurations were made the backup scripts shown in the Back ups section of this paper w
35. to Carl Zeiss optics and 9 point autofocus And you ll get two mics positioned for natural stereo audio Plus you ll enjoy faster smoother HD video uploads thanks to the H 264 video standard 50 word description Logitech HD Pro Webcam C920 Full HD 1080p video that s faster smoother and works on more computers Your loved ones can see you in more clarity and detail than ever with HD 720p video calling available No time to talk Send the people you care about a Full HD 1080p video clip Or upload it to Facebook Twitter or YouTube with just one click 25 word description Logitech HD Pro Webcam C920 Full HD 1080p video calling and recording that s faster smoother and works on more computers thanks to H 264 encoding 2011 Logitech Logitech the Logitech logo and other Logitech marks are owned by Logitech and may be registered All other trademarks are the property of their respective owners Windows Windows Vista and the Windows logo are trademarks of the Microsoft group of companies Mac and the Mac logo are trademarks of Apple Inc registered in the U S and other countries 57 Data sheet HP EliteBook 840 Notebook PC Ultra productive in and out of the office thanks to security performance and management features Now employees can hit the road with a travel pro The HP EliteBook 840 G1 industry leading Ultrabook is ultra GY productive in and out of the EliteBook 840 office Work with confid
36. to contain the map of our environment and a second region to contain the map key and other data T his makes understanding the meaning of the map intuitive and easy to learn To ensure proper scaling of features in the map there was some basic steps we had to perform The first region the map square has a predefined pixel width that is allocated at the top At compile time the user adjusts the estimated physical size of the room From this data the node creates a pixel scale by dividing the physical width of the room by the number of pixels This attaches a meter scale to each pixel This scale is important because it 1s used as the scaling factor to ensure everything in the map is plotted to scale The mapping updates at the request of the parent program which controls the thread and thereby the frequency of the map update The flowchart explains the detailed principle of operation We have verified that the scale is accurate enough for us to use for initial testing an debugging pur poses We have utilized the display in presentations 20 to our sponsors from FMC Technologies Schillings Robotics and it has been well received Our current design satisfies our original design goal We are still in search of a program that will allow us to display 3D data during our final demonstration Currently we are exploring the ROS Rviz package and are hoping to have 1t ready for demo day The reason that we are hoping to use Rviz is that it is
37. turned out to be one of the main limitations of our project This greatly limits our options in the open source VO implementations and in gen eral complicates the system Unless mathematical assumptions are made it is impossible to gather scale from a monocular system This can be a very massive issue as the system can tell you that you ve driven in a direction but not how far in that direction While still usable plugging this data into control loops results in generally poor control systems The current library we have chosen for our VO is libviso2 written by Andreas Geiger The algorithm in this section is abstracted from his paper 3 Lib viso2 was written primarily for use on autonomous vehicles There are two separate implementations the monocular and stereo cases The stereo case has no limitations while the monocular algorithm has many The monocular library assigns a scale to the odometry data but it does so by making some mathematical assumptions First it assumes that the camera is at a fixed height and angle and that the camera never deviates from these initial parameters Knowing these values allows us to attach a scale to the output data The algorithm performs the following steps 3 1 Using random sampling techniques estimate the F fundamental matrix through an 8 point 25 algorithm 2 Compute the E essential matrix using cali bration data 3 Compute 3D points and rotation and transla tion 4
38. wheels in Automation Quality and Testing Robotics 2014 IEEE International Conference on May 2014 pp 1 6 J Marck A Mohamoud E v d Houwen and R van Heijster Indoor radar slam a radar application for vision and gps denied environments in Microwave Conference EuMC 2013 European Oct 2013 pp 1783 1786 B Williams and I Reid On combining visual slam and visual odometry in Robotics and Automation ICRA 2010 IEEE International Conference on May 2010 pp 3494 3500 S Cousins Exponential growth of ros ros topics Robotics Automation Magazine IEEE vol 18 no 1 pp 19 20 March 2011 G Lucas 2001 A tutorial and elementary trajectory model for the differential steering system of robot wheel actuators Online Available http rossum sourceforge net papers DiffSteer P Torr A Zisserman and S Maybank Robust detection of degenerate configurations for the fundamental matrix in Computer Vision 1995 Proceedings Fifth International Con ference on Jun 1995 pp 1037 1042 Online Available http docs opencv org doc tutorials introduction linux_install linux_install html Arduino ide setup for rosserial Online Avail able http wiki ros org rosserial_arduino Tutorials Arduino 20IDE 20Setup GLOSSARY EKF The Extended Kalman Filter is a proba bilistic filter used to help remove noise from data 4 8 20 22 25 27 FPS The rate at which frames are displayed
39. wu paren com Drawn By K McCullough 2 3 4 55 Logitech HD PRO VVEBCAM C920 Hi Def Yourself Full HD 1080p video that s faster smoother and works on more computers D Logitech Say it bigger Say it better Full HD 1080p calls and clips in widescreen let friends and family see you in the sharpest smoothest video quality available Video call vblog and share your videos with ease Plus it works seamlessly with your favorite applications The term webcam doesn t quite do it justice FEATURE AT A GLANCE Full HD 1080p widescreen video calls on Skype e Sharpest video call picture available Easy HD 720p video calls on free Logitech Vid Yahoo Messenger and most other IM clients Focus on the details that matter Ultra smooth 20 step autofocus Premium Carl Zeiss optics for richly detailed video and stills Advanced auto light correction for dim and harsh lighting Dual noise cancelling mics you re heard in crystal clear HD quality stereo sound HD your Facebook Full HD 1080p video recording SF Logitech Fluid Crystal Technology e 1 click HD video uploads in Facebook bw Gives you smoother video motion sharper YouTube and Twitter ua A video richer colors and clearer sound H 264 compression for faster smoother fluid crystal video uploads technology e Snap and share brilliant 15MP photos
40. y copy pingi thru pings ta weighted pimg dist array Cover radians lo degrees disp theta ping displacement theta PI 180 WES Teich requested 07 gw ni m 1 E Tesi to ensure 180 lt disp theta 120 turn angle disp theta robot theta elch requested 1 oF Za h 17 5 E a dali path onos zen auto get goals 17 Test to ensure 180 tum angle 180 copy populated gridit build goal path arrayi drive to goal collision avoidance ralculate path once D Fig 18 Read Ping Distance Flowchart build goal path array l store waypoints x1 2 3 4 to final drivacord x store waypoints v1 2 3 5 To final drivecard y Start goal coord value x face location xii goal coord value y z face cati n yii test neighbor cw test neighbor opt imst neighbor cw test neighbor cw121 mystack 1 sizer thru lest neighber cows mystackda sizer s OT test neighbor ccwb test neighbor cowbl lest neighbor ccw12 local variables previous vector size 0 previous vector size 0 previous vector sited 0 check sum 0 Print NO PATA FOUND Loop tori i 0 i 4 i meet eafickent path array array element copy populated gri IF test to asign value lo best_path O if smallest stack size Cal 1 if smallest stack size cw 2 if smallest stack size Gap 3 if smallest stack size cw12 d if smallest stack size CNA 4 if smallest stack s
41. 16 fundamental matrix The fundamental matrix contains the data corresponding to the epipolar geometry between two image frames 25 IMU An Inertial Measurement Unit is a sensor device that measures current pose data It 1s often configured by sensor fusion of a gyroscope and an accelerometer 5 7 8 26 odometry A representation of a robot s position based upon measured or calculated linear ROS SLAM VO 33 and angular positions and velocities 3 6 9 20 25 33 The Robotic Operating System was cre ated by Willow Garage and 1s a software framework for use in robotic development 6 13 17 18 20 23 26 28 Simultaneous Localization and Mapping is the process of producing a map using vis ible landmarks and localizing with respect to that map at the same time 2 4 26 32 Visual Odometry VO is a process that generates odometry data through careful analysis of image sequences generated by a moving camera iii 3 5 6 8 10 23 27 34 start int maln intarge argv Listen Tor TOPICS T pr2 base odomelry odom 2 ping collision 3 distance 2 person prz base ndometry exploring fetch edem ping collision uu ance 2 person read ekf pathi read ping disti explore deaired i fetch desired dataready AS explere requested 1 7 publish wheel Speeds onTopic eddie do Fig 16 Path Planning System Flowchart 35 void read ekf path const g
42. CSU SACRAMENTO SENIOR DESIGN PROJECT SLAM BOT End of Project Documentation Authors Instructor Chris LANEY Professor TATRO Thomas HAYWARD Curtis MUNTZ Francisco ROJAS In Collaboration With FMC TECHNOLOGIES SCHILLING ROBOTICS Tw Senior Design Team One 1s completing a project which will attempt to mitigate the risk of injury to people who work within hazardous environments Simultaneous Localization and Mapping better known as SLAM 1s the method that team one chose to accomplish this This paper explains the design process for the project from its inception to the completion of the Deployable Prototype It will describe how the project was chosen a work breakdown structure and the technical details of the subsystems required to make our SLAM bot work Documentation 1s provided that will enable sufficiently prepared teams to reproduce the project Keywords Extended Kalman Filter Machine Vision Path Planning Robotics SLAM Visual Odometry II DU CONTENTS Design Overview l I A Ihaieroreii fora 5 of 4 as oe Ss GO C I I B il ue uo cvi Der Oa d eg de Xie terae ee 9s 979 979 9 Da SA 2 I B1 Team Member Summary i 2 I C Detailed Description xus ae ree re ee Ee VE Ee OE UE dede RU de 2 I Cl VISION ASA SCNSOF x x ye denger AE eee e X de e ee e 2 I C2 Visual ECH uou A E A d end ee Renee doge X a 3 I C3 np 3 I C4 A A ee ee Bee oe a EEN 3 I C5 Diffe
43. E I A sw VIN supply voltage required by IC is i 8 SS E FB RIS C21 25 C23 C24 4 5V to 23V for proper operation C17 ed 49 9k 0 luF 22uF 22uF 100uF required operating conditions 4 MA E SH E 0 1uF CEJ GND a COMP i E avus R16 owever capacitors are only rated to RT8250 R14 11 3k 25V so suggest VIN stays below about 47k DNI a 16V C20 d Circuit Details C18 x Output voltage is set by voltage divider on feedback pin S 6nF FB Feedback reference voltage is 0 925V typ Vout Vfb 1 R1 R2 MPORTANT NOTE E o not power cycle this part too rapidly and repeatedly apid power cycling causes excessive stress on the IC and ay cause it to fail and damage the board and connected ccessories Therefore after switching main board power ff wait at least 5 seconds before switching power back on ZN DO NOT INSTALL SEE BOM FOR COMPONENT PLACEMENT Sheet Size Power_5V SchDoc Letter Description 5V buck regulator Project Eddie Control Board Part 550 28990 Rev A N Sc TV 599 Menlo Drive Date 10 10 2011 PASA A A Z Rocklin CA 95765 Sheet of FI www parallax com Drawn By K McCullough 1 2 3 4 52 2 4 3 3V C43 C44 C45 C47 luF tuF tur tuF 6 7 gt YI 28 1 2 29 5MHz i po 41 MAN 19 P16 P1 42 e 20 P17 po 13 21 PIS Pada Kees EH EC 4 P2 7 Pons E P9 10 32 P25 P10 DE z 3 P26
44. Estimate ground plane in 3D points 5 Use known camera height and pitch to scale rotation and translation 6 Capture new frame Because libviso2 is a drop in solution to the visual odometry subsystem we are mainly concerned on how it fits into our system rather than the intricate implementation The overall flow chart for the VO signal path can be seen in Figure 20 As shown the VO interfaces directly with the Camera and the EKF The EKF that our system uses is VO library independent Any library that can produce a ROS odometry message type can be used This library allows us the unique luxury of get ting scaled data Other monocular implementations do not necessarily give us this luxury However because this library allows us to gather scaled data trough only camera frames some mathematical assumptions have to be made Because of these assumptions we assume values for 3 degrees of freedom corresponding to the camera pose This limits our ability to only be able to extract 3 degrees of freedom data from our camera system In order to ensure the system provides proper output these mathematical assumptions become physical measurements and mounting requirements of the camera s position These measurements provide the vertical distance from ground and the pitch of the cameras viewing angle The third physical require ment is that the camera can not have any play to roll The measurements are stored in a file that 1s loaded into libviso2
45. K EZ a backups ToDo dee gz umount mnt snapshots lvremove dev ubuntu vg rootsnapshot Listing 14 Primary Backup Script Secondary Backups The file system is backed up to the backups mountpoint so that a backup is freely available at any point in time on the actual system should they be needed There is still a single point of failure here if the hard drive crashes Secondary backups should be performed by copy ing the backups directory off onto an external HDD Restores If 1n the case we lose our root partition we can restore simply by booting into a Linux LiveUSB opening a terminal and running the following set of commands STODAY date F Cun ane ew Sacks gt EE Eeer Our SY loe Ss y Goo Listing 15 Restore Commands Microsoft Lifecam Fixes Due to the fact that the Lifecam has serious issues we have to implement the fixes seen in 16 autospawn no gt config pulse client ER pulseaudio sudo modprobe uvcvideo quirks 0x80 Listing 16 Lifecam Fixes 45 46 AN C6 1uF Hi I 5 0 1uF C E u Battery Sense Voltage Divider 0 16V shifted to 0 5V 1 LSB 15 625mV 280k Size sheet ADC SchDoc SE Description Analog to digital converter Project Eddie Control Board Part 550 28990 RSV A Sc TV 599 Menlo Drive Date 10 10 2011 PAAl l X Z Rocklin CA 95765 Sheet of www paral
46. Microsoft Security Essentials Windows 7 amp Microsoft Defender Windows 8 HP SpareKey requires initial user setup Absolute Data Protect TPM Embedded Security Chip 1 2 security lock slot Dimensions 13 35x 9 33 x 0 83 in 33 89 x 23 7 x 2 10 cm at front Dm xdxh 13 35x 9 33 x 0 89 in 33 89 x 23 7 x 2 25 cm touchscreen Weight Starting at 3 48 lb 1 58 kg weight will vary by configuration Power Primary battery 3 cell 24 WHr HP Long Life 3 cell 50 WHr HP Long Life Secondary Battery 6 cell 60 WHr HP Long Life slice optional Integrated 45W Smart AC adapter 65W Smart AC adapter Discrete 65W Smart AC adapter Expansion Solutions HP 2013 UltraSlim Docking Station optional Warranty Limited 3 year and 1 year warranty options available depending on country 3 year limited warranty on HP Long Life Battery only available with 3 year platform warranty Optional HP Care Pack Services are extended service contracts which go beyond your standard warranties For more details visit hp com go cpc 58 Data sheet HP EliteBook 840 Notebook PC 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 HP Tools partition with HP BIOS required for automatic recovery 29 30 31 32 59 HP recommends Windows Not all features are available in all editions of Windows 8 Systems may require upgraded and or separately purchased hardware drivers and o
47. P11 12 d 34 P27 P12 13 BS P13 bse I KES P14 15 P gt PIS 16 Ps Pl KES M24512 RDW6TP jN Note EEPROM is twice as large to provide extra CEN ea data variable space R26 E J4 DNI DNI Jumper can be installed to DIS able writing to the EEPROM Sheet Size Propeller SchDoc Letter Description Propeller microcontroller and related circuitry Project Eddie Control Board Part 550 28990 RSV A TV 599 Menlo Drive Date 10 10 2011 PAAl l X Z Rocklin CA 95765 Sheet of www parallax com Drawn By K McCullough 4 53 VBAT Motors EN Motors Power Input Port 12V_Reg Power_12V SchDoc EN Motors 5V Right Motor Xx mz i H Bridge Driver SchDoc 2 2H Kinect 12V EN Motors l wel UIIB m 5V Reg 3 32V Reg P23 3 spes 4 PE Power_5V SchDoc Power_3V3 SchDoc ES l E l J18 2 EN Motors j v UI2A B SE Main PWR 5A eric R Motor gt Power mode Select SW R33 e li 3 Board Motors 1M T 2 Board eft Motor 1 OFF H Bridge Driver SchDoc a EN Motors Ul2B P21 3 gt 3 3V EN Motors Prop USB EN Motors USB to Serial SchDoc Propeller schDoe UA NES P20 1 6 R38 R39 gt ui i p a L Motor D7 D8 EN Motors Green T Green TM UI3B P19 3 gt B dp M 2 i al oar wr Otors R P S2 eset Switch Enabled Enabled
48. SIHODIE e 3o cg e oed oe E oie AAA E A AA A ee e oe 3 o2 MOR ENCOUE S sir RADAR a HOUR o ee SS SS 4 Troubleshooting 32 tick encoders n noa a a a 5 Motors with 144 tick encoders non dro Bok Pn x on eR rom p ade a Z Eddie Robot Chasis gt aire HER REIR rie a odd eh Ed Eu xeu sete 6 Andy amp Chris amp Thomas at Paralax 7 Microsoft LatecamyStudiOus a used mede aaa AAA LEDS BHO 8 Cortech A EEN 9 Microcontroller w Pings and Camera to Laptop 10 Robot Hardware Flowchart 4 xoxo o Rowe Rote Ete a ic ee a Rx A 12 Mual DISPLAY a i onu ir cmo qox iue e A ww Ede MA oe Roe SEEDS A dea 11 Serial Sinak Pali sarita dd be ee dr Ad RR uu 13 Vistial Display Eos lotte tr de cae Gad Aer eei oo oS Bo A P MEN NA IS E O AN 15 Pine Sensor Flowchart diga dl dl ee ea a a prend 20 Visual Odometry VO Signal Path 2l Covariance Adjustment GUI le oe tec Bee Few He oen Be adi ey d 16 Path Planning System Flowchart 22s 17 Robot Position amp Create Map Flowchart 2n 18 Read Ping Distance Flowchart ee 19 Path Planning Algorithm Flowchart 22 EA A E bs dea d M itl dub aint pr A 23 Arduino IDE Dialout Permission Request 2 les LIST OF TABLES I Mar HOU e Loir urne ea A nre din e eB doe de 26 e de 26 e de e Se a T VAT n ee Lb i e II Estimated Budet seg ox uy x X ddl roo RC debe PR EE COND doe Il Manm QUES a a ee ae ira ara ar added da a as
49. Software Required les V C Remote Mode 2 ada Gd CS ge hd dd roti See e dup ae nk Design Documentation Breakdown of Hardware Subsystems VI A Encoders NIR Camera VIC Atmega 328 Development Board Breakdown of Software Subsystems VILA Robot Communication oao a a s VLB 2Vistial Display lt lt o a Bee A at e dtp twr A VIIC Kinematic Model s r seer cds At de ec ve ped ll ch bd eie Be re e redet ia VIII D Collision Avoidance o VIII E Gyroscope amp Accelerometer VIF Path PIanmi e uds cad de 3 A A E dd x d Y n d ii a sd VIII G Visual Odometry Interface llle VIII H Probabilistic Filtering 2e Mechanical Drawings and Documentation Test plan for Hardware Test plan for Software XI A XI B Feature Testis Pla ao don doe doe dede d dede mode a D w XI AI Kinematic Model i s saini atch aak bt d RC d Deed oe d ee XI A2 Path A mede ee REUS ee 8 XI A3 Visual DISDIdy see ah chs e he ee io cr Bt nce Y err Re ecu e Docs ds c e co XI A4 ELISTAS errar a ds e EM We We tee pe e XI A5 Collision ee Te 2 4 244822402 Re PRED a BRS XI A6 Serial Communication 22e L XI A7 Visual Odometry Interface 2 lll System Level ee e taaa daa he e AS XI Bl Software Testing Results 2 14 15 15 15 16 17 17 18 20 23 23 24 26 21 28 XII Conclusion References Glossary LIST OF FIGURES l Risk ASSES
50. a much more professional looking product that delivers a high degree of polish and refinement to the visual display We will continue exploring Rviz until we decide that implementation will require more time or skill than we currently have C Kinematic Model Each individual robot has a to have a mathe matical model so that odometry information can be generated from the on board sensors In our case we are going to use data from our wheel encoders to generate localization data regarding our robots position in the global environment This localization information is referred to as odometry and will refer to it as wheel odometry We attempted to find existing software solutions to generate this data but we were unable to find a suitable model Having exhausted our search options we began brainstorming on how we were going to implement our own node to perform these kinematic calculations to generate wheel odometry data We decided that speed precision and data storage were the essential design characteristics we needed to achieve We elected to begin developing in C because it 1s well suited for speed and had the ability to interact well with the previously discussed nodes The actual kinematic calculations became part of a larger parent C class that the visual display and pre processing for the EKF are part of This allowed for a more rapid creation of the node and a more cohesive code flow By creating the nodes using common data
51. a vision system can take considerable time Therefore sen sors that are less versatile are often used to provide faster ranging data for collision avoidance Exam ples of these sensors are ultrasonic infrared laser or small scale radar Using lasers to gather range and distance information has proven successfully in applications described in 6 Use of small scale radar systems has recently shown to be promising 7 for gathering range data Both lasers and radar provide ranging information than can be used to for obstacle avoidance but converting the input for immediate use for obstacle avoidance can be computationally intensive Our proposed solution is to use a microcontroller to gather data from multiple ultrasonic and infrared sensors In order to lessen the amount of processing required by our primary hardware we will off load the data acquisition from the ultrasonic and infrared sensors to a microcontroller This will also afford us the ability to make our system more modular Whether this system is implemented by infrared or ultrasonic sensors the main control loop will still be able to use the data By applyinh a threshold to the incoming range data we can make informed control decisions and implement path planning to avoid obstacles This data can also be used in conjunction with the VO feature to aide in producing a map of the robots environment 4 Encoders Another common sensor used to help provide localization input to a
52. alization data from multiple sources and this task will be more difficult if all data must be converted into a particle filter based SLAM algorithm The Extended Kalman Filter has been explored in robotics systems for a number of years and is considered to be well suited to the task of a visual SLAM system 9 The EKF also has the ability to be adapted to accept data from localization and ranging sensors and incorporate this data in its output The concept of accepting localization and ranging data into the same EKF filtering algorithm is commonly referred to as EKF SLAM It is also considered to be a viable solution to the full SLAM problem of autonomous navigation in an undefined environment D Feature Details The previous section discussed various existing research and implementations while simultaneously describing our proposed solution This section ex plains the specific hardware that we plan to use an estimated number of man hours needed to imple ment and other required features of our product 1 Kinematic Model A fundamental feature of our system will be the need to interface with a robotic platform and software to convert raw data to useful information This feature should include soft ware that gathers angular velocity information from the navigation path planning software or encoders and use this angular velocity information to create a kinematic model of the robot for localization purposes The same kinematic model s
53. and Accelerometer In the fall semester we focused on completing the essential aspects of our feature set Specifically items 1 2 3 4 and 6 Item 1 Robot Communica tion was integral to the completion of this project If we were unable to communicate with our robotic platform then we would have been unable to move forward with our project Fortunately we were able to complete this feature early on Item 2 the Kine matic Model was very important to the complete this project because it is how we calculate the robots position in the global environment Initially we started the Fall semester utilizing a differential drive kinematic model based on wheel encoder data However towards the end of the semester we learned that certain assumptions we made were incorrect and we adjusted our kinematic model Item 3 Visual Display was first deemed to have less importance than the other items since at the time the only use of the visual display would be towards the end of the project for the display of the 2 D map However we quickly learned that we desperately needed a method to display the data that we were gathering So we quickly created the visual display to aid us in our debugging Item 4 Path Planning is crucial since a key aspect of this project to deliver an autonomous platform which cannot be completed without the use of a path planning algorithm The Fall semester saw the implementation of a quick exploration algorithm using a wall
54. asurements were accurate to three centimeters This was attributed to possible power fluctuations from the microcontroller power supply due to the increase of the sensors Figure 14 shows how ping testing was conducted For our prototype implementation we have averaged the distance that the pings record with respect to every other ping sensor in order to return more accurate data Once the ping data 1s collected it placed into an array and sent to ROS node path planning via the microcontroller created topic collision avoidance It is here that the actual collision avoidance takes place The path planning node reads in the data and makes decisions based on how far away potential objects are Path planning takes the read in data and decides how fast and how much to turn the robot depending on the its distance to the obstacle The flowchart for the pings sensors is show in Figure 15 ED ve AR Pb nde 4 DUE dixi Fig 14 Ping Testing E Gyroscope amp Accelerometer During our initial system development we were unsure of the type of vision system we would be using We initially expected to be using a ranging solution or something to that effect The gyro and and accelerometer where a design input from a faculty adviser in order to assist gathering odometry information The Gyroscope amp Accelerometer were to help gather information regarding the angular velocities and angular position of our robot platform The Gy roscope amp A
55. ata to the kine matic model c Phase Three The third Phase will involve live testing of the feature inside the desired system It is critical that the Serial Communication and Visual Display features are tested prior to beginning this phase of testing This phase will involve sending commands to the robots chassis and comparing the output of this feature to the physical ground truth of the chassis This Phase will test the following elements of our system e The physical accuracy of our kinematic calcu lations e The features physical ability to communicate with other features via ROS e The reliability of the feature when used with other independent features 2 Path Planning The path planning node is software written in C It accepts the outputs from the EKF collision avoidance and goal detection software It will incorporate local data to create a map of it working environment The path planning feature will need to have two distinct tasks The first task will be to explore its environment When it believes it has explored its environment its next task will be to navigate to various detected goals throughout the room a Phase One The first phase of testing will be to ensure that the path planning feature has the ability to completely explore its environment This test will be performed by placing the robot in a safe workspace The workspace should be between 3 5 meters Three obstacles will be placed in the room The
56. bot Operating System ROS Our teams introduction to this amazing program allowed us to fully integrate all of our hardware and software in an environment that performed parallel processing based on event driven programming We finally had all of the necessary building blocks to begin our SLAM robot project The system documentation below is intended to provide a summary of the hardware and software used in this project First the hardware section will describe all of the main hardware components in cluding interconnection diagrams and a system con nection overview depicting the relationship between our hardware features and ROS Second each type of software program being used will be covered This includes an overview of the external programs interfacing with ROS and associated flowcharts and an in depth look at the relationship of each ROS node used and the topics associated with each node It must be mentioned that there are aspects of ROS which we do not fully understand due to its complexity ROS is an open source program that has tutorials that enable the user to implement the code without being bogged down with the program s details Therefore processes happening internal to ROS will not be covered VII BREAKDOWN OF HARDWARE SUBSYSTEMS Our core hardware is comprised of A laptop a Parallax Eddie robot an Atmega 328 microcon troller five ping IR sensors and a camera Eddie is a differential drive robot comprised of a m
57. bot stopped or rotated on its axis Initially the original exploration algorithm was im plemented inside the path planing program How ever during the evolution of the visual odometry system an alternate VO approach was used that relied on pure rotation and forward movement only This resulted in a separate new exploration program that runs as its own node This external program is automatically disabled when the path planning process is triggered and then the driving algorithm takes place inside the path planing program The path planning program receives data from 4 primary sources Robot x y theta position data ping sensor distance data facial recognition x y who data and an explore flag for the SLAM process to begin See Figure 16 16 for a system flowchart including incoming data The path planning pro gram uses the robot s estimated position data and uses scaling to convert the distance the robot has moved in meters in the x and y axis directions to a grid map that keeps track of where the robot is and where it has been along with unexplored area Figure 17 17 shows the process for receiving and storing position data as well as map generation The testing environment was predetermined not to exceed 6 meters and the desired size of each grid is 0 2 meters This was decided based on the robot chassis being 0 43 meters across The map created also utilizes the ping sensor distance data to project free unobstructed space away
58. ccelerometer are well suited to perform this task when initial filtering is performed via a complementary filter Due to our design choice of implementing a VO system we have began researching the side effects of removal of this feature from our system The output of the Gyro amp Accelerometer sub system is the same as the output of the Kinematic Model and VO sub systems This means that we have three sources that all provide estimates of the same information By keeping the Gyroscope amp Accelerometer in our 23 Read Ping sensors 1 thru 5 Formulate C string from data pass data via serial cable to ros node publisher Publish ROS node Fig 15 Ping Sensor Flowchart sub system we add an increased level of complexity and don t expect to see much gain Unless com pelling reasons can be find we intend to request removal of this sub system via change order to be submitted 1n February F Path Planning The path planning program has gone through several revisions through its development cycle Ini tially the visual odometry program had very specific non holonomic limitations of how the robot could move without corrupting the visual odometry data During testing there were certain driving conditions that caused the visual odometry to rapidly interpret bad map data This originally included when the robot performed a hard fast angular turn when the forward velocity dropped below a certain threshold or when the ro
59. cess to a map that contains information such as the current and previous locations of the robot and the locations of known obstacles This feature can be considered finished when it has the ability to navigate a defined space between 3 to 6 meters that contains two obstacles without contacting the obstacles The navigation goal can be set by another feature or manually through a software interface such as a computer terminal with a physical user 3 Visual Display A key requirement for our system will be to provide an end user with data about the robot s location and the physical envi ronment it has explored Our proposed feature to address this issue is to provide the end user with a map displaying known obstacles and the robots path traveled This feature does not have to be real time but the system should be able to replay the robots path as it explored its unknown environment or display the systems end estimate of the unknown environment This feature can be considered finished when it has the ability to display the robots estimated path and detected obstacles goals on a 2 dimensional bird s eye map This map should display all data to an appropriate scale so that further debugging or data can be collected from the end user 4 Filtering An essential requirement to incor porate multiple sensors into a design such as our system will be a probabilistic filtering scheme to perform sensor fusion Our system will accomplish this task b
60. d a simple catkin make should build the appropriate nodes Rapid Prototyping Software While not strictly needed to run any of the project s production fea tures the Octave environment was used to rapid pro totype many nodes ranging from object isolation and motor PID control analysis It can be installed on Ubuntu by typing sudo apt get install octave into the terminal Running all the ROS nodes Because we have set the ROS environment up to optimize for processing power on the laptop we have shifted some of the processing to other computers 44 For simplicity consider the two computers Mas ter and Remote Master will be the main control guy performing all mapping and data aggre gation as well as some remote controls Remote will be the remote computer that will be gathering the data To launch the nodes required by these two com puters first we need to set up the environments If these computers are configured with static IP addresses on a c Backups The following scripts will perform primary back ups via snapshots Post processing copies them to the backups directory Tertiary backups are also implemented Primary Backups lyeressate 11 06 e EMISIT Lilo Patel iG moco moune de Witte t mos E unl oS Mme Sas tems 9TODAY dace FE mkdir backups STODAY ter ez Da kup SODIO cool ee ene ova y mae HOME AE MOO SEL SIDE dd mnt ubuntu vg rootsnapshot conv SO nodo es SAN
61. de pendent sensor collision status via USB cable to the path planning feature for path adjustments The workload for this feature should be 150 hours This allows 30 hours to research the inter face requirements for the two sensor types to the microcontroller The implementation and testing of the microcontroller software with the two types of sensors should take about 50 hours The time re quirement to integrate the collision avoidance output into the path planning feature should take 50 hours The remainder of time will be used for debugging and physical testing of the feature 6 Gyro amp Accelerometer An essential require ment is to incorporate both a gyroscope and an accelerometer sensor Our system will accomplish this task by fusing a 3 axis gyroscope and a 3 axis accelerometer to provide x y and z orientation data This feature can be considered completed when the microcontroller can communicate with both the gyroscope and the accelerometer sensors and pro vide the fused sensor data to the control system feature using serial communication 7 Communication With a Robot Chassis The system will be required to communicate with a robotic platform Our feature set to perform this task will be to utilize a Serial Communication software solution The software for this feature needs to be extremely modular to allow it to be modified to work on various robotic platforms This feature will be software based and will essentially be a
62. ds to be more robust than a simple wall hugging robot a Path Planning This feature will be re quired to plan a path to a predetermined location This location can come from another feature or from a sub module If the plan path is blocked this section needs to find a method to navigate around the obstacle e Estimated Research Time 55 e Estimated Implementation Time 90 e Estimated Cost 0 00 e Assignee Chris e Deliverable A software object of function that has the ability to navigate a defined space between 3 to 6 meters that contains two ob stacles without contacting the obstacles The navigation goal can be set by another feature sets or manually through a software interface such as a computer terminal with a physical user 3 Visual Display We need to provide the end user with a map displaying known obstacles and the robots path traveled This feature doesn t have to be real time but the system should be able to replay the robots path as it explored its unknown environment or display the systems end estimate of the unknown environment a Map Display The map should consist of a two dimensional top down representation of the robots workspace This map can be made from pre existing software or generated by the group e Estimated Research Time 50 e Estimated Implementation Time 90 e Estimated Cost 0 00 e Assignee Thomas e Deliverable A software object or function that has the ability to display the robots
63. e Figure 5 shows the new encoders Thanks to Paral lax s help we were able to get our project back on track Figure 6 shows the team after troubleshooting the encoder issues with Parallax Fig 5 Motors with 144 tick encoders B Camera In order to process the vision data we need a vision sensor Because webcams are cheap readily available and easy to interface it was decided to use one for this project s vision sensor After looking at recommended options the team decided on the Microsoft Lifecam Studio as seen in 7 a Eddie Front ddie Rear Fig 2 Eddie Robot Chasis Fig 6 Andy amp Chris amp Thomas at Parallax This camera is capable of producing our desired 640x480 pixel image at 30 frames per second FPS Unfortunately during the use of the Lifecam it became apparent that it would not work for our project The Lifecam has a numerous issues during use on the Linux environment We attempted to implement some fixes onto our system see the appendix but we eventually deemed the camera too unstable to move forward with in the project We did some research and physically tested various readily available webcams before arriving with our current choice the Logitech C920 seen in Figure 8 This camera produces the same 640x480 at 30 FPS video and in testing is a lot more stable within our software environment than the Lifecam C Atmega 328 Development Board An Atmega 328 microcontroller d
64. e determined locations across the front of the platform The ultrasonic sensors will detect semi rigid and solid objects while the infrared sensor can detect loose fabric material The two sensors provide redundancy and provide an optimal setup for proximity and object detection The combination of these sensor types will also detect fabrics and glass These sensors will be programmed to work with a microcontroller using C and C e Estimated Research Time 50 e Estimated Implementation Time 100 e Estimated Cost 250 00 e Assignee Francisco e Deliverable A software object or function that will prevent the robot from crashing into walls 6 Gyroscope amp Accelerometer An essential re quirement is to incorporate both a gyroscope and an accelerometer sensor The feature our system will use to accomplish this task will be a 3 axis gyroscope to provide yaw pitch and roll data as well as a 3 axis accelerometer to provide x y and Z axis acceleration data This data will be fused together using a complementary filter to resolve angular pose e Estimated Research Time 40 e Estimated Implementation Time 120 e Estimated Cost 30 00 e Assignee Chris amp Francisco e Deliverable A software object or function that will read the data from IMUs and filter 7 Communication With a Robot Chassis The system will be required to communicate with a robotic platform Our feature set to perform this task will be to utilize a serial c
65. e requests There will be small amounts of time fluctuations between the samples but nothing in our system requires this feature to be deterministic We can adjust the amount of samples per second by simply adjusting the variable that controls this This sub system has about two hundred hours of functional testing and seems to be functioning properly Due to the critical nature of this sub system we are considering adding additional run time error checking procedures that would allow our system to perform dynamic communication estab lishing if the system is unplugged This sub system is in debugging phase B Visual Display Visualization of data from multiple sources is critical to provide feedback for debugging and rapidly displaying the systems current status The information that we needed to display consisted of the outputs from the Visual Odometry Kinematic Model and the output of the filtered data The display needed to provide a top down two dimensional map of the robots environment and path ROS has some built in utilities such as RViz which allow mapping The interface with these utilities was complex and the time to implement them would have been considerable Due to the time crunch it was decided that we would implement our own mapping node that would display the required features Fig 12 Visual Display Initially we decided on some of the key design features of this node Since this feature is needed for assistin
66. e set forth in the express warranty statements accompanying such products and services Nothing herein should be construed as constituting an additional warranty HP shall not be liable for technical or editorial errors or omissions contained herein AMD is a trademark of Advanced Micro Devices Inc Bluetooth is a trademark of its proprietor and used by Hewlett Packard Company under license Intel the Intel logo Intel Core and Core Inside are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries All other trademarks are the property of their respective owners 4AA4 8335ENUC September 2013 Web Site www parallax com Office 916 624 8333 NY L Forums forums parallax com Fax 916 624 8003 LN l1 Sales sales parallax com Sales 888 512 1024 Technical support parallax com Tech Support 888 997 8267 Eddie Robot Platform Assembled 28990 Unassembled 28992 Eddie is a mobile robotics development platform designed to foster creativity innovation and experimentation Compatible with Microsoft s Robotics Developer Studio Eddie can roam autonomously see in 3D using the power of the Microsoft Kinect and be driven remotely using a wireless controller sold separately Eddie s Control Board uses the Propeller multicore microcontroller to directly control two high torque 12 V motors and collect data from multiple sensors mounted on the robot Eddie is controlled o
67. easure of success A Robot Communication With the selection of a robotics platform and a the laptop properly configured it was now time to establish communication between the robot control board and our programs that would need communi cation in ROS This software will be the pathway that conveys and receives data between two of our major hardware components We elected to go with a standard USB hardware connection with a ROS node to interact with the serial connection There was minimal hardware design requirements due to using existing communication standards With the hardware requirements met we now began researching to find a serial driver that would provide the software communication between the ROS nodes and the control board We initially investigated using a previously established ROS node that was written specifically for our specific robotics platform This node would have provided the serial communication requirements with little to no alterations While attempting to implement this existing code we ran into compatibility issues regarding specific software dependencies We spent about a 80 combined ours attempting to get this software to work but every path turned out to be a dead end We no existing software available to meet our needs we began development on our own ROS node to accomplish the requirements The most import aspect when designing this software was to ensure that high reliability could be achieved from this A
68. ed outside this sheet 13 li block 14 Ess lt Note The Current Sense feature is currently not used R12 Truth table in normal operating conditions Size Kaka Rocklin CA 95765 www parallax com Sheet of Drawn By K McCullough 4 49 Circuit Details Vout 12 0V 12 0V 2 2A Regulator Vin min 6 75V set by under voltage lockout Vin max 16V absolute max 25V set by capacitors Tout Max 22A Tout Min for CCM 400mA Freq 283kHz C25 C26 C27 029 22uF 22uF luF luF Circuit Details U5 C32 luF 16 Connect the EN pin to VIN to automatically 18 DMG E 6SSS turn on the regulator when power is available R17 Pull this pin to GND to disable shut down the 47k C35 regulator reduces supply current to less than 0 luF SS8P3L M3 86A 10uA 19 i i D6 RIS C28 F 10k 0 47uF C31 20 15uH 0 luF D nea R20 0 ohm SS8P3L M3 86A oag Under Voltage LockOut UVLO is currently R23 Q3 set to approx 6 78V R21 0 ohm 0 025 3W DMG4496SSS 19 6k C30 300pF R22 10k C34 N 4700pF 2200pF fae C39 C37 cag C40 ca Zou R24 zur 22ur MF D 1000F Tour oir 4 02k R25 464 nee Power 12V SchDoc Size Letter Description 12V buck boost regulator Project Eddie Control Board Part 4 550 28990 Rev A Date 10 10 2011
69. ematics e Schematics for the circuits on the Eddie control board Logitech C920 Data Sheet e Datasheet for the project s camera of choice HP Elitebook 840 Data Sheet e Data sheet for the project s laptop of choice Eddie Robot Platform Assembly Instructions e Assembly instructions for the Eddie Robot platform Project Member Resumes e The resumes of all project members are included VENDOR CONTACTS Vendor Contacts Parallax Inc 599 Menlo Drive Suite 100 Rocklin CA 95765 USA Daniel Harris dharris parallax com Andy Lindsay alindsay parallax com FMC Technologies Schillings Robotics Administrative Offices 260 Cousteau Place Davis California 95618 U S A Adwait Gandhe Adwait Gandhe Q fmcti com 39 40 Project Setup Guide This section should outline the layout and imple mentation of all software choices and configurations performed on our project laptop If you follow this document and run all the specified commands on your own laptop you will be able to run our project Operating System Because our project will be running on top of a software development platform known as ROS the operating system we selected was Ubuntu 14 04 and the following steps were taken to install Ubuntu 1 Download Ubuntu 14 04 64 bit from https www ubuntu com download 2 Burn the iso file onto a DVD or a bootable LiveUSB 3 Restart computer booting into the bootable DVD or the LiveUSB 4 Install Ubuntu on top of LVM
70. ence thanks to proven enterprise technologies and enterprise security performance and management features that will meet all your business needs HP recommends Windows Sleek and sturdy e t s time for an upgrade to the dramatically thin light design of the HP EliteBook 840 G1 Ultrabooks with a luxurious soft touch finish e Join forces with the latest generation Intel architecture operate at peak performance levels with Intel Smart Response Technology for disk cache and expand total storage options with an additional mini card SSD e Dock up for an enterprise desktop experience using the optional UltraSlim Docking Station with a convenient side connector and dual DisplayPorts for multiple display support It s all about the connections e Exercise full control over your wireless connections through a single user interface with support for most networks including optional new 4G WWAN 9 using HP Connection Manager e Easily share your internet connection with up to five devices with HP Wireless Hotspot Help colleagues get online and improve productivity e Take productivity to a whole new level with innovative software like HP ePrint and HP PageLift on the HP EliteBook 840 G1 e Bridge distances on the HP EliteBook 800 series optimized for communication with Microsoft Lync premium audio video and optional full HD display 9 Solid security HP Sure Start restores productivity and reduces IT hel
71. eometry msgs PoseWihtCovanancestamped ConsiPtr msg Bloe pose x pose y robol theta No OF b now x now y robot theta felch requested store grid daba store grid dala Start COnverimcw Xx ncow y to grid coordinates current grid guara dr Save current grid square as 1 current grid square dd Mo display 107 save projected a 2 in a grid quares as 1 E acer ee ee increment display save projected Al grid quares as 1 ei Lin e hata 1107 Beretta j 160 lt theta lt 1607 Se Yes m in d Fig 17 Robot Position amp Create Map Flowchart 36 void read ping dist const std msgs String ConstiPtr msg ping vector Start ping displacement x ping displacement y disp x 0 Glas disp y 0 disp theta D store ping numeric string character to local variable fatis 015 i ping displacement x ping displacamant siniping theta i weighted_ping_disifi store local variable lo ping dist array fatis 015 ie ping displacement y ping displacamant y sinjping theta i weighted ping dist i Create local variables lo point to array siring values disp k now peg displacement x disp y now y peg displacement y siore last 5 ping values of gach sensor and average cave average value as pag thru pings ping displacement theta alanZ disp x disp
72. er Standoff 12 1 Diameter Servo extension Cable 14 Length Screw Cap SKT 6 32x1 2 eme 6 Seenen msomo 6 sarmona emn S 4 40 x Y2 F F Hex Standoff Screw Button Head SS 1x20 x 1 2 7140 00032 pe Soen Cap SS 6 32 x 3 8 Screw Flat Head Black 14 20 x 5 8 Screw Pan Head Black 4 40 x 1 2 Screw Button Head 4 20 x 5 8 Screw Button Head Blk 20 x 34 Washer 2 dia 060 Delrin 7143 00001 6 Standoff 4 40 x 5 8 F F Round Standoff 4 40 x 1 5 F F Hex Copyright O Parallax Inc Eddie Robot Platform 28990 amp 28992 v1 1 1 16 2013 Page 3 of 17 62 Step 3 Ping and IR Sensor Module assembly Figure 3a shows the components for each sensor assembly You will need a small Phillips screwdriver to assemble each sensor module Figure 3a Each Ping assembly consists of Each IR sensor assembly consists of Ping sensor 28015 Cable servo extension 805 00002 4 40 x 5 8 black machine screws 700 00028 1 16 thick nylon spacers 22713 00015 Ya thick nylon spacers 22713 00005 Acrylic Ping stand 725 32008 1 IR sensor 28995 1 IR Sensor to servo cable 32805 28995 2 4 40 x 5 8 blk mach screws 22710 00035 2 1 8 thick nylon spacers 22713 00013 2 Ya thick nylon spacers 22713 00005 1 1 1 2 2 2 1 Acrylic IR Stand 725 28995 p gt SS mum M Refer to Figure 3b and note the different locations of
73. ere ran Software Installs This section provides installation procedures for all software used by our project whether by apt get or by compiling software from scratch The code listings in the following section list all software to be installed and a brief explanation of their purpose Update Existing Software and set up Appropriate PPAs We begin with a basic software update after adding a prerequisite PPA that we will use later in the installation process OpenCV install requires ffmpeg Type the commands from Listing 3 sudo add apt repository Ppa on severinsson ffmpeg sudo apt get update amp amp apt get upgrade Listing 3 Update Existing Software and Set up Appropriate PPAs Install Leveraged Software Next third party software 1s installed Type the commands in Listing 4 Git is required to interface with our github repos itory Remote access is required so a ssh server is installed These will need further configurations that will be shown in the software configuration section Libarmadillo dev is a linear algebra library for use within cpp programming guvcview 1s a dy namic parameter adjuster for camera to test various settings like autofoucs etc System config lvm is a GUI for LVM management and while it is not strictly needed it is helpful for visualization pur poses Slick suec ers AO As See Sonia gt lvm libarmadillo dev guvcview openssh server arduino Listing 4 Install Leveraged Software I
74. es into a single output In the field robotics there are many options when considering using a complex filter to fuse sensor data from multiple sources The two main types can be categorized as particle filters and Gaussian based filters An in depth explanation of the differences 1s beyond the scope of this paper Instead we will focus on the filter we chose and why we chose it as well as the implementation of our filter choice We spent considerable time researching filters during our initial system development We elected to utilize a probabilistic filter based upon the EKF The main reasons we chose to utilize an EKF was that it has a proven history of being successfully implemented in systems that are similar to the one we are attempting to build The EKF also has many open source implementations and many detailed explanations that allow utilizing an EKF to be much easier than some of the existing systems There are fancier forms of the Kalman filter such as the unscented variety but they are newer and more difficult to implement We elected to find a existing EKF instead of programming one from scratch This will allow us to focus on the usage of the filter and not the complex mathematics that make it work The particular versions we found to was the EKF from the robot pose ekf from the ROS open source libraries This particular realization of the EKF Shttp wiki ros org viso2_ros 26 Driver Image Rectifier Perform VO
75. est this feature in two phases a Phase One The first phase of testing will be to test the pre filter software that we have written This software 1s designed to accept data from the previously listed sources and the convert it to the required data type that the EKF allows This 1s imperative so that there is no data type mismatches during run time The software involves multiple event triggered call back functions so testing to ensure that each thread processes properly is es sential to the reliability of the overall system To perform this test data from the various sources will be published and the pre filter software will have to capture convert and publish correct output By populating the incoming data type with preset values we can observe that the output of the conversion al gorithm correctly converts it to the appropriate data type This Phase will test the following elements of our system e The ability of the pre filter to reliably accept data from multiple sources e The reliability of the data conversion algo rithms b Phase Two During the second phase of testing we will be testing the third party EKF software This test will be performed by using post processed data to ensure that it is as close to real situations as possible We will run the robot in a circle and record the output of the Visual Odometry and Kinematic features The accuracy of the two sources isn t really an issue as long as they are being published
76. estimated path and detected obstacles This map should display all data to an appropriate scale so that further debugging or data can be collected from the end user The map should display data from top down and be two dimensional 4 Filtering An essential requirement to incor porate multiple sensors into a design such as our system will be the need to use a complex filter to perform sensor fusion The feature our system will use to accomplish this task will be a Gaussian filter that has been extended to work on a non linear system Examples of filters that satisfy this requirement are the EKF Unscented Kalman Filter or Sparse Extended Information Filter e Estimated Research Time 80 e Estimated Implementation Time 80 e Estimated Cost 0 00 e Assignee Thomas amp Chris e Deliverable This feature can be considered accomplished when it can accept input from the VO Kinematic Model and IMU features and provide meaningful output about the robots location in relation to its surroundings The output of the filter needs to be more accurate than the least accurate sensor input that is provided to it when compared to ground truth 5 Collision Avoidance Another essential re quirement is to incorporate two different types of collision avoidance sensors The feature our system will use to accomplish this task will be to install five ultrasonic and five infrared distance sensors One sensor of each type will be placed in five pr
77. etermine IP address of the remote laptop and record e ifconfig 7 Manually set the IP address of the remote laptop XXx xxx xx xx 11311 e export ROS MASTER URI http remote ip address 11311 e export ROS IP hostname P 8 Launch ROS SLAM program e roslauch production remote launch Finally to drive the robot around 1 Use same precautions describe above in man ual mode driving instructions e Option 1 Type roslaunch production master launch and use sliders and com mands on control script to move robot e Option 2 Press the Explore button VI DESIGN DOCUMENTATION The hardware and software requirements to im plement a SLAM robot may not appear very chal lenging at first get a robot load some software plug in a few sensors and the system should work right The short answer No not even close Our experience in choosing a commercially available robot and implementing the proper software was anything but straight forward and included hundreds of hours of research and extensive hardware and software troubleshooting Our team researched sev eral manufacturer s of differential drive robots rang ing from Vex iRobot Dagu and finally decided on the Parallax Eddie robot Once the robot platform was decided on our team struggled with a means to integrate all of the software programs that must run simultaneously into a single control program structure It was around this time we learned about the Ro
78. evelopment board is used on this project for rapid protoyping a solution in order to offload some of the ping data processing that would normally be calculated on the Eddie control board This move is made to isolate Fig 7 Microsoft Lifecam Studio Fig 8 Logitech C920 16 the Eddie control board to only worry about wheel encoder data and drive commands USB cable Logitech C90 camera Fig 9 Microcontroller w Pings and Camera to Laptop The overall hardware system flowchart can be see in Figure 10 Right Wiel Encoder Pin A Pin B Left Mator Right Motor Fig 10 Robot Hardware Flowchart VIII BREAKDOWN OF SOFTWARE SUBSYSTEMS The software descriptions contained in the sec tion are intended to provide an introduction to our overall software subsystems Every program that we have developed or are using are developed to be utilized within the ROS environment Unless specifically stated each section is running on it s own node and it s inputs and outputs are passed via topic through the ROS processing abstraction layer The programs are designed to be implemented as standalone nodes which allows them to be worked 17 on independently and improved or replaced as needed Please note that although individual nodes are designed to be launched as standalone programs they will not perform their intended task unless launched as a whole as their collective collaboration is required to achieve any m
79. from the robot up to 0 6 meters Figure 18 18 shows the flowchart for incoming ping distance data processing This allows for more squares of the of the environment to acknowledged as free space that has been explored without the robot physically driving it Finally the facial recognition data is triggered by the camera software program seeing the face and predicting the x y distances from the robots current position It is assumed that if the camera can clearly see the detected face then there are no obstructions between the robot and the goal In this situation depending on the angular orientation of the robot all of the squares between the goal and the robot are filled in on the map The path planning algorithm shown in Figure 19 19 is based on a depth first search pattern During testing a single search using a clockwise pattern starting at the 12 o clock position plotted a very inefficient path to the detected object This led to using 8 different variants of depth first search to calculate the most efficient path from point to point 24 The grid squares of the route of each independent goal to goal are stored separately and in the end combined into the final driving path of the entire Journey In addition an acceptable measure of what constitutes a successful robot has arrived at goal point must be established This goal was set to 40 centimeters or 1 robot width This ensures the collision avoidance system can still prope
80. g Block Secure the Battery Tray with 4 14 20 x Y long button head screws as shown in Figure 7c Figure 7c Step 8 Switch Plate and 5 Upper Deck Supports I nstallation Place the assembly on its side as shown in Figure 8a Attach 4 diameter by 5 long machined aluminum standoffs with 14 20 x 5 8 long button head screws as shown Connect the Switch Plate to the 4 1 5 tall standoffs with 4 4 40 x long black Phillips head screws as shown in Figure 8a as well Figure 8a Copyright O Parallax Inc Eddie Robot Platform 28990 amp 28992 v1 1 1 16 2013 Page 11 of 17 71 Attach the Ping and IR Sensors to the Base as shown in Figure 8b Place the 46 32 x Y socket head cap screw through the holes in each of the stands and then carefully screw them down evenly into the Base Take it slow and easy Make a few turns on one screw and then a few turns on the other gently bringing the assembly down into full contact with the Base Make them snug but do not over tighten Figure 8b Step 9 Eddie Control Board Installation Orient the Control Board as shown in Figure 9a and use 4 4 40 x 1 4 machine screws to attach it to the 4 hex standoffs in the center of the platform Be certain that the switches are in their Off positions the switches light up when they re ON Connect each of the motor drive connectors to their respective receptacles on the Control Board Connect the Main Power connector c
81. g in debugging and troubleshooting of the system we needed to ensure that this data is accurate and to scale We also decided that ensuring that this map could be rescaled to various environment sizes Open Serial Communication Port and Establish Delay for Robot Control Board to Start Up Is eddie do published Send DIST to robot control board Transmission Done Convert data from signed hex c string to signed decimal c string Publish string to topic 19 Get Desired Command from eddie_do Is it a new command Convert data from signed hex c string to signed decimal c string Create formatted string command Send Command to Robot Chassis End thread return to main loop Fig 11 Serial Signal Path was a priority Additionally the map needed to be threaded to ensure that it limited the amount of pro cessing the PC had to do Graphics representation can be very processor intensive We elected to implement this node in C be cause of the possibility of needing large amounts of data storage which means that the if we used a slower language we would increase the processing load of our PC We decided on using the OpenCV library because it is highly documented and has many code examples It is known for having a large amount of drawing functions and has many back end accelerators built into the it In OpenCV an image becomes a matrix and it is easy to manipulate or
82. go to logitech com support downloads 2 year limited hardware warranty For HD video calling on other video calling software please check for availability Requires installation of QuickTime QuickTime and the QuickTime logo are trademarks or registered trademarks of Apple Inc used under license 2011 Logitech Logitech the Logitech logo and other Logitech marks are owned by Logitech and may be registered All other trademarks are the property of their respective owners Windows Windows Vista and the Windows logo are trademarks of the Microsoft group of companies Mac and the Mac logo are trademarks of Apple Inc registered in the U S and other countries 56 Logitech HD PRO VVEBCAM C920 PACKAGE SPECIFICATIONS Single Case Pack Part 960 000764 N A UPC 097855074355 10097855074352 Weight 16 75 OZ 4 41 lb Width 7 52 in 7 95 in Depth 2 83 in 6 30 in Height 8 94 in 9 49 in Cube 0 101 ft 0 275 ft Case Pack Count N A 2 single units Pallet Count 370 units 185 case packs Product description 100 word description Logitech HD Pro Webcam C920 Full HD 1080p video that s faster smoother and works on more computers Your loved ones can see you in more clarity and detail than ever with HD 720p video calling No time to talk Send the people you care about a Full HD 1080p video clip Or upload it to Facebook Twitter or YouTube with just one click You ll enjoy amazing clarity and detail thanks
83. h DTS Studio Sound integrated dual microphone array 2 integrated stereo speakers Wireless Support WLAN Intel Dual Band Wireless AC 7260 802 1 1ac 2x2 WiFi and Bluetooth 4 0 Combo Intel Dual Band Wireless N 7260AN 802 1 1a b g n 2x2 WiFi and Bluetooth 4 0 Combo Intel Dual Band Wireless N 7260NB 802 11a b g n 2x2 WiFi Broadcom 802 1 1a b g n 2x2 and Bluetooth 4 0 Combo WWAN HP hs3110 HSPA Mobile Broadband HP 1t4111 LTE EV DO HSPA Mobile Broadband Communications Intel 1218 LM Gigabit Network Connection 10 100 1000 NIC Ports and Connectors 3 USB 3 0 1 USB 3 0 charging 1 DisplayPort 1 2 1 VGA 1 combo stereo headphone mic jack 1 AC power 1 RJ 45 1 side docking connector Input Device and Camera Full sized spill resistant keyboard with drain optional backlit dual point touchpad with scroll zone and point stick 2 discrete buttons WLAN on off speaker mute 720p HD webcam optional Software Buy Office HP 3D DriveGuard HP Connection Manager Windows 7 HP Wireless Hotspot HP PageLift Windows 8 only HP Recovery Manager HP Windows OS only Support Assistant HP ePrint Security HP Client Security Suite requires Windows includes HP Credential Manager HP Password Manager HP File Sanitizer and HP Device Access Manager with Just in Time Authentication HP BIOS with self healing HP Drive Encryption HP Secure Erase HP Trust Circles
84. he Atmega 328 Propeller Microchip and Altera FPGAs all within the last year C Detailed Descriptions In order for a robotics platform to replace a human in environments like those mentioned pre viously it must be able to enter an environment produce a map of the environment plot where objects are located and remember its history within the environment This process is called simulta neous localization and mapping or Simultaneous Localization and Mapping SLAM Our design idea 1s to create a SLAM algorithm that has the capability of producing a 2 D map of a pre defined environment with a pre defined set of objects that can be applied to commercially available robotic platforms The following sections describe some existing algorithms and platforms along with our design choices 1 Vision as a Sensor In terms of the human sensory organs the vision system is arguably the most powerful sensor Likewise in terms of elec tronic sensors few devices can outperform a camera in the types of data that can be extracted to form output information In recent years the cost of cameras has been decreasing significantly Because of this cameras are replacing traditional sensors in applications such as automation security and robotics Our system will be comprised of a vision system utilizing cameras as our primary form of sensor information Camera data 1s inherently complex because the only output is an image Any information gained
85. he proximity of Parallax and their guarantee that if we should run into problems they will support us K Battery Risks 1 Battery case cracks and leaks acid Low Low Steps Taken to address risks 1 The batteries sit in a dedicated battery housing under the lower Eddie platform deck They are secured in place by hardware standoffs and the batteries lie between two thick plastic plates There is very minimal risk of a battery case cracking to due to vibration or shock V USER MANUAL This project requires very specific hardware and software in order to operate It 1s assumed that the user 1s familiar with the ROS Linux terminal commands both Sketch and Spin IDE s as well as C C and Python programming The system is designed to be operated either locally all commands typed on the laptop mounted on the robot or remotely using an additional laptop and router to remotely control the robot mounted laptop A Room Requirements Eddie must be operated on a flat smooth hard surface 1 e cement asphalt un waxed tile or hard wood flooring etc in an area no less than 3 x 3 me ters and ideally 5 x 5 meters The room walls must be either a solid material wood brick steel or made of a thick covering such as 12mil polypropylene or heavier The floor and wall surfaces must contain a scattering of small flat items such as leaves stick ers or alvar tags in order for the visual odometry to properly function The room env
86. hould be the mathematical basis for use by the navigation and path planning model to perform the inverse operation The angular velocity information provided should distinguish between the left and right drive compo nents of the robotics platform This data 1s expected to be gathered from wheel or shaft encoders After this feature has gathered the angular velocity of the robot it will convert it to linear distance traveled The accuracy of this measurement needs to be within 30 of ground truth The large allowance of accuracy is due to the nature of the filtering methods that are going to be used and the error that wheel encoders produce in high slip environments An estimate of the error of this data will be plugged into the filter prior to final localization estimate 2 Path Planning A key feature in almost any mobile robotics system 1s the ability to use available sensor data and create a path to a desired point Path planning is the term typically used to describe this process There are many models currently available for path planning This feature will be required to plan a path to a predetermined location form the current location This location can come from another feature or from a submodule This path planning feature must account for the physical dimensions of the robotics platform sur rounding area and sensor data The path planning section will incorporate data from the collision avoidance feature It will also have ac
87. hould be monitored but if possible allow the robot to attempt its mission By allowing the robot to run a little longer after the first error is seen we can see how the error has effected other elements of the system or if other non related errors have occurred By carefully documenting the errors during this time we can gauge if the overall test is working properly This testing should occur in the robots environment that it will be tested on during end of semester demonstration day e Phase Two During Phase two we will be working on fine tuning the system Items such as tweaking the EKF VO and path planning nodes will be performed during this phase By taking time to thoroughly tune our system we can develop a stronger understanding of the overall system The tester should get enough data to make a decision as to 1f major overhaul of a feature is required or not This phase of testing shouldn t be consid ered completed until every goal in the design idea contract is satisfied After phase three it will be time to qualitatively evaluate the system as a whole The key elements are how accurate each of the Kinematic Model VO IMU and EKF outputs are compared to ground truth This data is essential to gauging if the overall project is a success 32 f Phase Three The main focus during Phase three will be to test the system exactly as it will be on demonstration day Every effort should be made to test at the actual site and at the sa
88. icro controller containing an integrated PID two optical wheel encoders two PWM driven motors and two lead acid batteries Eddie is programmed to directly interface with the ping IR sensors however our SLAM algorithm could ideally interface with any robot platform that was differential drive Keeping this in mind we chose to use an Atmega328 mi crocontroller to control the ping IR sensors which allowed ROS to communicate only encoder data with Eddie The assembled Laboratory Prototype hardware can be seen in Figure 2 A Encoders Initially Eddie was driven by a GO command which uses a set velocity for travel but does not give feedback as to how far the robot has traveled or in which direction When we tried to use the GO SPD command which uses the wheel encoders for movement it did not work We contacted Parallax and with some factory support we managed to get an alternate set of less accurate 32 tick encoders to work without learning why our original encoders failed Figure 3 shows the replacement encoders and Figure 4 shows Francisco hard at work debugging encoder data As our project progressed we needed to use the original wheel encoders for their accuracy so 15 T Fig 3 32 tick encoders Y E Ss Fig 4 Troubleshooting 32 tick encoders after a second trip to Parallax and some extensive troubleshooting we found that one of our original encoders was bad which caused the original issu
89. iggest issues we have had to overcome is our robotic chassis It has failed for us repeatedly and we have had to replace three sets of wheel encoders XI TEST PLAN FOR SOFTWARE Our design is largely software and our testing philosophy will be to test each individual feature s software independently of the other sections After all features have been verified our objectives will be to test the entire system as a whole In this document we will present the testing plans for our specific features in Section XI A and the testing plan for our system integration in Section XI B A Feature Testing Plan Our project consists of seven features These fea tures are the Kinematic Model Path Planning Vi sual Display Filtering Collision Avoidance Serial Communication and the Visual Odometry Interface Each feature has its own unique testing plan as described below These feature testing plans are slightly different than you d see in normal system testing as we are dealing primarily with custom written event driven software which leads to dy namic errors With event driven software the amount of time and amount of start stop cycles are critical to detect run time errors The longer we test the more likely unplanned run time errors will surface 1 Kinematic Model The Kinematic Model fea ture is software that gathers information from the robots wheel encoders and uses that data to calculate an estimate of the robots position This featu
90. ile devices require internet connection and email capability May require wireless access point Separately purchased data plans or usage fees may apply Print times and connection speeds may vary Some HP LaserJet printers may require firmware upgrades Service levels and response times for HP Care Packs may vary depending on your geographic location Service starts on date of hardware purchase Restrictions and limitations apply For details visit hp com go cpc Multi Core is designed to improve performance of certain software products Not all customers or software applications will necessarily benefit from use of this technology 64 bit computing on Intel architecture requires a computer system with a processor chipset BIOS operating system device drivers and applications enabled for Intel 64 architecture Processors will not operate including 32 bit operation without an Intel 64 architecture enabled BIOS Performance will vary depending on your hardware and software configurations Intel s numbering is not a measurement of higher performance WWAN is an optional feature sold separately or as an add on feature WWAN connection requires wireless data service contract and network support and is not available in all areas Contact service provider to determine the coverage area and availability Connection speeds will vary due to location environment network conditions and other factors Requires Internet Explorer IE8 or IE9 Some websites and a
91. ion of each fea ture we will write specific documentation of said feature in order to allow others to replicate our final product G Resource Estimates The features that were described in the previous sections all require many hours of research and development A estimated summary of the amount of hours per task is shown in Table I along with who will be assigned to what task TABLE I Man Hours Estimated Hours Assigned to Kinematic Model Chris Path Planning Chris amp Thomas Visual Display Curtis amp Thomas Filtering Chris amp Thomas Collision Avoidance Francisco Chris amp Francisco Thomas Curtis Curtis amp Francisco Curtis amp Francisco Everyone Everyone 2130 hours All Team Members Gyro amp Accelerometer Robot Communication Linux Maintenance VO Goal Detection Robot Repairs Room fabrication II FUNDING PROPOSALS This project was fully funded by our corporate sponsor FMC Technologies Schillings Robotics During our initial meetings with our sponsor we es timated a budget that included the robot additional hardware and sensors a laptop and miscellaneous expenses This budget also includes the materials cost to fabricate a testing environment that can be broken down and transported in a vehicle Our proposed budget for the entire project was 3 000 Our estimated costs can be seen in Table II Actual project invoices can be found in the appendix TABLE II Estimated Budget Estimated Cost
92. ional displays Additional cables required DisplayPort with multi stream through integrated graphics is planned to be available in fall 2013 as an integrated feature and as a web update in late summer 2013 HP Connection Manager available on Windows 7 only Requires Microsoft Windows 8 Microsoft Lync software sold separately Requires optional webcam and internet access sold separately HP Sure Start is available only on HP EliteBook 800 and HP Workstation ZBook series products HP Client Security requires Windows 4G LTE not available on all products in all regions and only available on products featuring Intel processors MIL STD testing is pending and is not intended to demonstrate fitness for U S Department of Defense contract requirements or for military use Test results are not a guarantee of future performance under these test conditions Wireless access point and internet access required Availability of public wireless access points limited The specifications for the 802 11ac WLAN are draft specifications and are not final If the final specifications differ from the draft specifications it may affect the ability of the notebook to communicate with other 802 11ac WLAN devices For more information visit e mR hp com Share with colleagues Rate this document O 2013 Hewlett Packard Development Company L P The information contained herein is subject to change without notice The only warranties for HP products and services ar
93. iron ment It is this application of SLAM that interested FMC Technologies Schillings Robotics to offer this project challenge to students at CSUS Our team accepted the challenge of creating a SLAM robot that could perform the specific criteria set by FMC Technologies Schillings Robotics and they offered to fully fund the project The objective of this project is to focus on a way to mitigate the risk of injury to people who work within hazardous environments It is our hope that our efforts will have a positive effect on society as a whole We intend to accomplish this by developing a SLAM algorithm that could be applied to a robotic platform By the end of this two semester project our robotic platform will be able to be placed into an unknown environment for which it has no prior knowledge and automatically explore the room and provide a 2 dimensional map birds eye view of that room along with specific object of interest within 1t Once the room has been mapped it will be capable of navigating to a specific object within the room In order to accomplish this we have identified key features that must be completed for our system to work as envisioned These features are what we based our design idea contract on each feature will be covered in depth later on in this report 1 Robot Communication 2 Kinematic Model 3 Visual Display 4 Path Planning 5 Visual Odometry Interface 6 Collision Avoidance 7 Filtering 8 Gyroscope
94. ironment must have fairly uniform incandescent or fluorescent lighting and be free of ground debris such as small rocks sticks twigs or any object that will cause the motors to draw excess current to overcome Caution The drive motor fuses are severely un derrated for the amount of current the motors draw and the fuses will blow 1f any additional resistance is added to the path of travel including an incline or debris If Eddie 1s about to crash into something immediately turn off the drive motor power switch on the distribution board B Local Mode To operate this project as a standalone system with no external control 1 Hardware Required e Laptop with at minimum an Intel 13 processor 1600Mhz DDR3 RAM 4Gb wireless adapter 3 USB 2 0 ports e Parallax Eddie robot platform w Eddie Con trol Board e Ultrasonic Ping IR sensors e Logitech C920 USB HD Pro Web Camera http www parallax com product 28992 http www parallax com product 725 28998 2 Laptop Software Required e Ubuntu 14 04 e ROS Indigo e Python PyQT4 e Sketch IDE e Simple IDE for Linux To start the system up 1 2 3 4 5 6 1 8 Turn on laptop and wait for system to fully boot up Place the faces around the environment Turn on the Eddie Control board power switch right switch located on the power dis tribution unit Next turn on drive motor power left switch on power distribution board Pl
95. ity of the features ability to produce data on the appropriate axis c Phase Three The third phase of testing will be to test the ability of this feature to produce data that can be used by the control algorithms We are currently unsure of how the control system will produce data Testing for this phase will be re evaluated upon completion of Phase Two of this section We believe that it 1s critical to perform small scale control testing of the data produced by this node prior to beginning system level testing B System Level Testing After completion of all feature testing 1t will be time to begin testing the system as a whole This will mean that each feature is fully ready to be in tegrated into our overall control algorithm It is our hope that by thoroughly testing and understanding our software prior to entire system testing that we will better understand our overall system and have be able to troubleshoot it d Phase One During this phase of testing we will attempt to launch all programs and be especially attentive to run time errors Our goal for this testing is course debugging of how the software interacts with each other as a hole We need to ensure that the proper data is being published at the proper time During this phase of testing our path planning EKF and VO will probably not be tuned properly During this initial phase of testing we need to ensure the proper data is being published to each program If errors s
96. ize cows amp if smallest stack size GM 7 if smallast stack size ccw12 amp witehibest path lest to assign value lo waypeint vector size O stacksize cw3 1 stacksiza cw now x face location x i 1 2 7 stacksize_cw9 3 stacksize cw12 now y face location v i 1 4 5stacksize ccw3 l stacksize cows amp stacksize ccwH 7 stacksize ccw12 face location sieft A face lacalion vllt 7 size waypoint vector size loop counter 07 i size waypoint vector size loop counter 17 AAA 2 loop _counter loop counter 27 sized waypoint vector size n laop counter 37 amp witch hest path IF test loop counter 0 waypoints x y stack solution pop and store Shacks bo veclors leap counter 1 waypoints x y amp sEackssalutlant loop counter 2 waypoints x y slack snlutinnz loop counter 3 waypoints x y stack solutlon3 size waypoint vector size Fig 19 Path Planning Algorithm Flowchart store stack size values to smallest most efficiant path 37 38 APPENDIX Appendix The remainder of pages in this document is supplied as supporting documentation for our project 1 2 3 4 5 6 1 Vendor Contacts e The industry vendor contacts are listed Project Setup Guide e The base implementation of the system on top of a Linux environment is documented Parallax System Sch
97. jor assumption that the robot chassis will diligently executed and maintain this velocity Equations 1 through 6 show how from just the left and right wheel velocities we can generate the required positional and velocity changes for the robot platform Ule T Uri Lin cd cos On 11 1 U e as Uri y Yi cd x sin On 1 2 2 f ST 0 Lk ms Tik Ar 4 Yik Upk i Vk Ar 5 Gu Ox On Ar 6 The previously discussed method has proven to work well In depth detailed comparison hasn t been established yet During physical testing of our robot platform it was discovered that we could improve our encoder resolution from 32 ticks per revolution to 144 ticks per revolution This is a considerable increase In order to capitalize on this increase we elected to create a second kinematic model based upon the amount of distance traveled This 1s beneficial because it allows us to create two separate models and choose which one we feel gives more reliable results We used a different approach based upon distance traveled and not just the commands The following equations are derived from 11 and implemented in our C code Ae ft oe gt right Ar Di a T e 4 cos Bn A 7 8 gt 9 Ule Uri Uright t Ule ft Or HA 11 A radius 2 Se E E x Lin zd 12 wien v Ae ft Posh i Ae ft 13 2 radius 2 e Lik X k 1 Rx cos w O
98. l ports Click Add below to be added You must log out and log in again before any group changes will take effect Fig 23 Arduino IDE Dialout Permission Request Now that we have dialout permissions and Ar duino IDE has been ran once we can configure our rosserial settings to work with the Arduino IDE by following the documentation found on ROS org 14 In this we rosrun a command to copy the libraries into the Arduino IDE s folder Type the commands shown in Listing 9 sketchbook libraries ii 3545 idos Lillo rosrun rosserilial arduino make libraries PY Listing 9 rosserial Configuration Script 43 Cloning Project Repository Assuming you have been granted access to the github page it is now time to clone the repository down for local use Before we clone the system it is important to give git a couple of settings These settings can be seen in Listing 10 It is very important to set up these fields with correct names and email addresses Failing to do so will result in improper blame histories and can make debugging a nightmare git config global Weer name git config global user email johndoe example com Listing 10 Configure git Type the commands in Listing 11 to clone the master branch onto the local system mele EE aaa epa uba cibi emo te eco EE lemas Ee s Com May mena NG Senor De sali iim fale quieren El git pull origin master Listing 11 github Clone Script If typing in you
99. lax com Drawn By K McCullough 2 3 4 47 AUX Power Ql DMG4496SSS Absolute Max Vds 30V Rds on 22mOhm typ 29mOhm max See the datasheet for the MOSFET for additional drive characteristics sheet Aux SW SchDoc Size Letter Description Auxilliary switched power port Project Eddie Control Board Part 550 28990 Rev A PAMLAX 2 TM 599 Menlo Drive Rocklin CA 95765 www parallax com Date 10 10 2011 Sheet of Drawn By K McCullough 4 48 Table 12 INA INg DIAGA ENA DIAGg ENg OUT cs Operating mode ESCHER i Sheet Isense lour K pict id H Bridge Driver Sch Doc Letter 4 Counterclockwise CCW Description Full H bridge Motor Driver L High Imp Brake to GND Project Eddie Control Board Part 550 28990 Dora gt 599 Menlo Drive Date 10 10 2011 Circuit Details VIN Battery voltage can be 5 5V to 16V Device will under voltage or over voltage shutdown if TC outside this range 22uF i 100uF Circuit Details To disable motor drive output pull EN low and disable the buffered inputs to INA INB R11 lt D2 E FAULT 3 Red SCH Rs RUE Se Emp PWM Frequency can be 0 up to 20kHz Max 1k 77 PWM Minimum OFF time is 6us R9 BE ik 9 IMPORTANT All logic requires 5V levels For design re use lk 12 level shifters should be us
100. lll 9 IL Ai Testing Debugging and Specific Documentation 9 II B Resource Estimate Summary lll ssl 10 WE Project DImie Hle ce e i ee doge e dr gt ge o a N 10 ULC Milestone 1 Visual Control of a Robot 10 III C2 Milestone 2 All Features Implemented 10 III C3 Milestone 3 Filtering Odometry Models 11 III C4 Milestone 4 Mapping and Path Planning 11 III C5 Milestone 5 Project Completed 11 IV VI VII VIII IX XI Risk Assessment amp Mitigation IV A Kinematic Model udo bone a Abt de Bos Boss Bode ue Ee debug ded IV B E x gers ig teat pesca cas Ge Betas Bee dr e hid e Hir be dr hes Cet E es des IV C EE aa ee n da E KNEES Res NED SINC ereere ee Xeno Fre EE ELE HR qM dete dex dun dde iode eto IV E Collision Avoidance isis neo Teese d un Bh me Bw dox ede ut ege IV F Communication with Robot Chassis IV G Visual Odometry Interface o s r uoo ic ERE be Rex xS ESO ER IVA Laptop BASES 2 23120 Wc Wege nen rr pn AA IV I Camera RISKS d dede dee ded wide A O a dial in Ryu ub Wen de eet IV J Eadie RISKS x Le da dde e GOA Tele de fede Pe ea redi e d d bib e etr d VK Battery RISKS ace ok esteem be he Re eI en dt dl nen Ye ecu e IC Ne DOW ee ie ao User Manual V A Room Requirements uoo 4644442 GF euer espe Ew aue e V B Local Mode Lr V BI Hardware Required ue dr Ro Ebo da Ao Mea es V B2 Laptop
101. llows data to degenerate Very High High Steps Taken to address risks 1 We have allocated a lot of testing time to ensure that this module is tested thoroughly 2 Known issues will be worked around in our other systems H Laptop Risks 1 Complete Laptop failure due to hardware or software complications Low High 2 Complete data loss Low Very High Steps Taken to address risks 1 We continually backup the complete hard drive image to an external 1 TB drive Which allows for recovery in case of hard drive fail ure In addition the majority of the code that has been written 1s stored on Github which allows for recovery if we need to reinstall ROS 2 Because our system is modular we can effec tively swap the production laptop for one of our own personal laptops giving us a total a 4 backup laptops which will be able to run the complete system with minimal setup I Camera Risks 1 Complete camera failure due to hardware or driver support Medium Very High Steps Taken to address risks 1 We have purchased a total of three cameras in case we ever have the primary camera fail J Eddie Risks 1 Eddie board failure High Very High 2 Eddie not as advertised High Low Steps Taken to address risks 1 All of the power inputs on the Eddie board have been fused for over current protection 2 Beside the fact that the Arlo platform is labeled as a turnkey robotic solution we chose it because of t
102. low 200mS for the robot to come to a complete stop C Remote Mode To run the system in remote mode where it can be controlled from a WiFi connected workstation additional hardware 1s required e A second laptop with at minimum an Intel 13 processor 1600Mhz DDR3 RAM 4Gb loaded the with same software and ROS Production file as the robot s laptop e Linksys WRI 110 wireless router router settings DHCP no firewall restric tions no throttling To set up the wireless router Enable wireless access 2 Enable SSID broadcast 3 Enable DHCP 4 Disable all firewall restrictions 5 Disable throttling Run the following on the robot laptop 1 Perform the above instructions until you reach roslaunch production master launch DO NOT execute this command 2 Verify the robot Laptop is connected to the correct wireless network 3 Determine robot IP address of robot laptop and record Sifconfig 4 Manually set IP address and port number of robot laptop xxx xxx xx xx 11311 e Sexport ROS MASTER URI http robot 1p address from above 11311 e Sexport ROS IP hostname I Run the following on the remote control laptop 1 Turn on remote laptop and open a Terminal window 2 Connect to the correct Wi fi network 3 Enter the ROS directory e cd curtkin 4 Connect to the robot laptop using SSH e ssh l teaml robot ip address from step 8 11311 5 Enter password to login to the robot laptop 6 D
103. me time of day By repeatably testing on sight in the same environment we should be able to get an idea of the reliability of the overall robotics system If Phase two has passed then there shouldn t be any major changes made If any changes are made they need to be carefully documented and all members of the team need to be aware 1 Software Testing Results Feature require ments successfully tested and meet the requirement of the Design Idea Contract All features success fully integrated together and passed all phases of testing XII CONCLUSION This document has described our development towards an autonomous mobile robotics system that can localize based upon external sensor data to be used in hazardous environments This robotics system implemented on a suitable robotics platform could be used to help reduce risk of injury to members of our society who put themselves in harms way on a routine basis As members of the engineering community it is our responsibility to use our skills and knowledge to better society and we feel that our system can help advance research towards that goal By developing a concrete and reliable SLAM algorithm it allows a robotics system to be utilized in dangerous situations with the desired goal of replacing humans in harms way with machines REFERENCES 1 K Nagatani S Tachibana M Sofne and Y Tanaka Improve ment of odometry for omnidirectional vehicle using optical flow information i
104. mented on the installation process up to but not necessarily including a script to perform the software install Detailed instructions on how to install the soft ware required for this project are shown in the later sections of this paper Wireless and Proprietary Drivers Internet access is required in order to complete the remainder of the installs It was determined that since our laptop is not guaranteed to be plugged into wired etherent that we should enable wireless Because our HP laptop uses a Broadcom radio wireless only works if we use a proprietary driver We are using Broadcom 802 11 Linux STA wireless driver source from bcmwl kernel source propri etary This was enabled in the third party drivers utility on Ubuntu To perform this install the laptop must be plugged into Ethernet After the driver was enabled a wireless network was joined Specific network choice is left as an exercise to the reader Use of LVM Because we will be developing software to run on a computer we need to prepare the system for easy re imaging in case of hard disk failure As such the OS was installed on top of a Logical Volume Manager LVM A graphic of the underlying LVM system is shown in Figure 22 The main benefit of LVM technology is the ability to snapshot the underlying operating system and Volume Group ubuntu vg Fig 22 LVM Layout data drives for instantaneous backups as well as the ability to be able to revert to
105. n Intelligent Robots and Systems 2000 IROS 2000 Proceedings 2000 IEEE RSJ International Conference on vol 1 2000 pp 468 473 vol 1 2 D Helmick Y Cheng D Clouse L Matthies and S Roume liotis Path following using visual odometry for a mars rover in high slip environments in Aerospace Conference 2004 Proceedings 2004 IEEE vol 2 March 2004 pp 772 789 Vol 2 3 A Geiger J Ziegler and C Stiller Stereoscan Dense 3d reconstruction in real time in Intelligent Vehicles Symposium IV 2011 4 S Choi J Park and W Yu Resolving scale ambiguity for monocular visual odometry in Ubiquitous Robots and Ambient Intelligence URAI 2013 10th International Conference on Oct 2013 pp 604 608 5 7 9 10 11 12 13 14 J Campbell R Sukthankar I Nourbakhsh and A Pahwa A robust visual odometry and precipice detection system using consumer grade monocular vision in Robotics and Au tomation 2005 ICRA 2005 Proceedings of the 2005 IEEE International Conference on April 2005 pp 3421 3427 M Liu S Huang and G Dissanayake Feature based slam using laser sensor data with maximized information usage in Robotics and Automation ICRA 2011 IEEE International Conference on May 2011 pp 1811 1816 M Tatar C Popovici D Mandru I Ardelean and A Plesa Design and development of an autonomous omni directional mobile robot with mecanum
106. n and downloads including e Eddie product documentation this document e Eddie Control Board product documentation provides details and specifications about the control board hardware Revision History 1 0 Initial document release 1 1 Picture references updated 1 2 Changes to Bill of Materials 1 3 Updated to include assembly instructions for Quadrature encoder Copyright Parallax Inc Eddie Robot Platform 28990 amp 28992 v1 1 1 16 2013 Page 17 of 17 76 T1 Curtis Muntz Objective To obtain a position where can apply my passion for robotics computer vision and control systems QUALIFICATIONS Experience in Computer vision algorithms using OpenCV and Matlab Monocular and stereo machine vision projects Sensor fusion via probabilistic filters System integration and debugging using Robot Operating System ROS Algorithm development and simulations using Matlab and Python Circuit simulations using PSpice and Simulink Windows and Linux systems administration VMware administration PID control system projects Programming and Misc Languages C Python Matlab Octave Bash ATEX ENGINEERING PROJECTS Senior Project SLAM Robot Implementing a Simultaneous Localization and Mapping algorithm on an autonomous robotics platform The robot is able to autonomously navigate around a room without prior knowledge of the environment using an Extended Kalman Filter to fuse wheel encoder odometry and monocula
107. nstall OpenCV Since ROS Indigo OpenCV is not released from ROS infrastructure Its ROS interface package vision_opencv depends on stan dalone libopencv packages The following script was modified from the code taken from Ubuntu s help center 13 Type the commands in Listing 5 Desktop git clone https github com y e eco Install Opencvy gi Tasta O peas UXOR e UL chmod x OPency latest s SE EE EE vVersLon pos 9 LOS le Listing 5 OpenC V Installation Script Install ROS Base Software This project requires ROS Indigo ros org Type the commands in Listing 6 Note that this script should be supplied creden tials before 1t 1s ran This can be done by running a sudo apt get update before running the script SUdO Se gt etc cuo sous liso coc die Se dla e wget https raw githubusercontent com mos OS cis 2 o ma een aos ae m m sudo opere c sudo apt get update sudo apt get install ros indigo desktop LL sudo rosdep Init rosdep update Ee 42 soa slaiee Listing 6 ROS Installation Script Finalize Software Installs and Other OS Configura tions SSH Configurations First we will configure our SSH server as cur rently it is a security risk We want to modify it so that only one user is allowed access to the server To do this we have to modify the server daemon file and add the line AllowUsers team This process can be done manually or with the commands seen in Listing 7
108. of that system occurs it sets a Boolean variable that then causes the VO and kinematic odometry information to have the covariance attached to it and published to the EKF The covariance adjustment for all of our odometry models is critical to the overall output of the filter If the covariance values are incorrect then the output from the filter can be completely incorrect For the duration When the robot pose ekf node 1s done process ing the data the same C class subscribes to the topic and stores the filter output for usage by the other nodes The process happens rather quickly compared to the VO processing time The output is then plotted on our visual display for visual comparison to the other sources We have currently fused the two kinematic mod els and have successfully implemented filtering of VO and wheel encoder data Our sponsors have indicated that they would like to be able to have the vision sensor be the dominant sensor but we have been unable to tune our filter for this This 1s mostly due to the current status of our VO node We are aware of the difficulty that tuning an EKF and are ready for the task During our initial testing we were forced to recompile our nodes every time we adjusted the covariance This was time consuming and created a very slow tuning environment As a way to help us expedite our tuning we have created Graphical User Interfaces in python to help us tune the covariance of the inputs during run time
109. oming from the Switch Plate to the large power connector on the Control Board Figure 9a Copyright O Parallax Inc Eddie Robot Platform 28990 amp 28992 v1 1 1 16 2013 Page 12 of 17 12 Viewing Eddie from the front as in Figure 9a connect the left most IR Sensor cable to ADI the center IR sensor to AD2 and the right most IR Sensor to AD3 Connect the left most Ping to 1 0 1 and the right most Ping to 1 0 2 on the Eddie Control Board Be sure to observe proper polarity the black wires ground should be attached to the outer most pins of the 3 pin headers Connect the left most towards the outer edge of the deck three pin cable from the left Encoder to header pin 9 on the I O section of the Control Board The black wire should be on the outer most pin of the three pin header Now connect the other Encoder cable to header pin 10 on the Control board Connect the right side motor s innermost cable into header pin 11 on the Control Board and then the final Encoder cable to header pin 12 Be certain that all the black wires are oriented towards the outside edge of the Board Locate the power enable switch on the Control Board near the USB connector Slide the Motors Board Off switch to the Motors position all the way closest to the USB connector This switch will leave board power and motor power enabled since they are switched externally using the high current red and blue power switches Step 10 Sec
110. ommunication software solution The software for this feature needs to be extremely modular to allow it to be modified to work on various robotic platforms This feature will be software based and will essentially be a wrapper program for complex libraries It is preferred that the feature be programmed in C but Python 1s acceptable The feature should use a well docu mented software library to interface between the operating system and the USB port By utilizing well documented libraries it will prevent possible communication errors e Estimated Research Time 50 e Estimated Implementation Time 90 e Estimated Cost 0 00 e Assignee Thomas e Deliverable A software object that can pass instructions from our main system to the robot using serial communication with a minimum of 95 success rate for data transmission The feature must be able to sustain serial commu nication for over 45 minutes without causing system errors 8 Visual Odometry Interface The VO system must be able to predict the motion of the camera through careful processing of image frames When completed the VO system must be able to measure the odometry of the camera with measurable error with respect to ground truth Whether this system is implemented in house or we use third party examples it has to be able to fit within our main system and therefore comply with our messaging requirements a Implementation To publish the required odometry data we mu
111. on below 1 Team Member Summary All group members are students studying at CSU Sacramento working toward degrees in Electrical and Electronics En gineering The teams resumes are attached in the Appendix Curtis Muntz Curtis has focused most of his classes on control theory and has a solid back ground in machine vision He will be focusing his efforts on the machine vision problems in this project Curtis has a background in Linux systems administration which will be helpful in maintaining a software platform on top of Linux Francisco Rojas Francisco has a strong interest in Digital Signal Processing and as such he will be focusing his efforts on the filtering aspects of this project He is also interested in working with the various sensors of the project Thomas Hayward Thomas has a strong back ground in troubleshooting and debugging hardware software interfaces He has experience in developing software designed to automate testing of complex systems such as radar He has focused most of his out of classroom education on the implementation of software to satisfy embedded system design requirements Chris Laney Chris has an extensive background in hardware applications communication systems and career experience in the Defense industry work ing with a multitude of different systems He is new to programming and has had to learn C and C programming languages as well as learn how to program microcontrollers such as t
112. on the same scale the EKF should be able to filter out the error and produce some type of usable data Tuning of the EKF filter will be done via our Covariance adjust GUI This phase will test the following elements of this feature This Phase will test the following elements of our system e The ability of the third party EKF software to accept data at our transmission rate e The ability of the covariance GUI to adjust the covariance of multiple data sources 5 Collision Avoidance The Collision Avoid ance software consists of ultra sonic sensors micro controller and software serial data transfer and software on the PC to interpret the data to prevent collisions The Path Planning feature should provide 30 guidance based upon this features data but this feature should contain a procedure that stops the robot if a collision is imminent a Phase One The first phase will be to test the data coming out of the ultra sonic sensors This test will also test the ability of the micro controller to interpret data that 1s received by the sensors The test will be to place an object in front of each sensor and see the distance measured by the sensors This distance needs to be less than 3cm per meter unless the distance is less than a meter in which case 3 cm is within acceptable standards This Phase will test the following elements of our system e The accuracy of the sensors e The ability for the micro controller to interpret
113. ond Deck I nstallation The Second Deck s top side is indicated by the 4 counter sunk holes that line up with the 4 5 long aluminum standoffs The counter sink is the top Attach the two 12 long standoffs to the Second Deck by inserting 2 4 20 x 5 8 button head screws from the bottom side of the Second Deck Place the Second Deck onto the 5 standoffs as shown in Figure 10 and fasten with 4 1 4 20 Flat head Black Screws Figure 10 Copyright O Parallax Inc Eddie Robot Platform 28990 amp 28992 v1 1 1 16 2013 Page 13 of 17 73 Step 11 Kinect Plate Assembly The Kinect is attached to Eddie in a non destructive manner That is there are no modifications necessary to the Kinect unit itself The bottom of the Kinect unit has two rectangular holes as shown in Figure 11a Note the orientation of the Kinect Cam Hooks below the device Figure 11a Place a Cam Hook into one of the rectangular slots as shown in Figure 11b Figure 11b Copyright O Parallax Inc Eddie Robot Platform 28990 amp 28992 v1 1 1 16 2013 Page 14 of 17 Rotate or cam the hook into the slot as shown in Figure 11c Figure 11c Do the same with the remaining cam hook in the other slot The assembly should now look like the one shown in Figure 11d Figure 11d Copyright O Parallax Inc Eddie Robot Platform 28990 28992 v1 1 1 16 2013 Page 15 of 17 74 75 Place the Mounting Plate onto the bottom of the
114. orange soccer ball This was a very important milestone as it demonstrated the base functionality of many subsystems For this proof of concept to work we needed to be able to demonstrate an assembled robot functioning communication with the robot chassis functional processing of image sequences and basic robotic control through path planning While most subsystems were in very rudi mentary stages of implementation their implemen tation demonstrated that we are prepared to meet our project goals and milestones 2 Milestone 2 All Features Implemented After we have demonstrated visual control of our robot we are to set to work on implementing all the features listed in the feature set When all of these features have been implemented Milestone 2 is considered complete The primary focus of this milestone is to get functioning data coming from the encoder odometry as well as the VO These odometry models are to be used in tandem for producing better usable datas than each odometry model is capable of producing itself Achieving this milestone begins a long and involved testing and debugging phase of our project 3 Milestone 3 Filtering Odometry Models After the odometry models have been verified to produce usable data within a certain percent error from ground truth data we are to begin fusing the two data sources by using an extended kalman filter This probabilistic filtering approach will enable us to tune our system for more
115. p desk calls in the event of a BIOS attack or corruption Exclusively from HP HP Sure Start helps reduce downtime for users and IT e Keep sensitive information in safe hands HP Trust Circles helps protect your data by ensuring that only assigned contacts can access critical files e Stay up and running HP BIOS Protection offers enhanced protection against virus attacks to the BIOS and other security threats and is designed to help prevent data loss and reduce downtime e Safeguard data devices and identities with HP s hassle free Client Security portfolio including HP Drive Encryption HP Device Access Manager with Just In Time Authentication and HP Secure Erase e Ensure smooth sailing with stable and consistent images managed lifecycle transitions and Global Series support you can rely on Data sheet HP EliteBook 840 Notebook PC Road ready e Never fear accidental bumps and minor spills HP EliteBooks undergo challenging tests so you don t have to During the HP Total Test Process PCs experience 115 000 hours of performance trials to ensure they can withstand rigorous work environments Designed to be travel tough the HP EliteBook thin and light notebooks feature a new soft touch finish and are designed to undergo MIL STD 810G testing e Enjoy the intuitive control of the tough Corning Gorilla Glass touchscreen that lets you make the most of Windows 8 Hardware specifications HP recommends Windows
116. pplications may not be supported For the use cases outlined in the DOD 5220 22 M Supplement Does not support Solid State Drives SSDs Initial setup required Web history deleted only in Internet Explorer and Firefox browsers and must be user enabled Requires Windows Data is protected prior to Drive Encryption login Turning the PC off or into hibernate logs out of Drive Encryption and prevents data access 2013 Desktops are planned to support drive encryption in October 2013 For the methods outlined in the National Institute of Standards and Technology Special Publication 800 88 HP Trust Circles Standard when included allows up to 5 Trust Circles with up to 5 contacts in each Trust Circle Optional Trust Circles Professional required for unrestricted number of Trust Circles Not all configurations will be classified as Ultrabooks Requires a compatible Intel Core processor enabled chipset Intel Rapid Storage technology software and non SED HDD optional mSATA SSD flash cache module Intel Smart Response Technology is only available on select 2013 HP systems Depending on system configuration results may vary mSATA SSD is planned to be available in August 2013 Support for external displays as a standard feature through integrated processor based graphics is dependent upon the particular PC platform form factor the actual number of displays supported will vary An optional discrete graphics solution will be required for the support of addit
117. precise odometry infor mation The testing and debugging phase involved in this will be extensive but once the models are filtered our system will be ready for the next face 4 Milestone 4 Mapping and Path Planning After our odometry models have been fused by using the EKF our next focus is on the mapping and path planning milestone This milestone will take our fused known good data and bring it into a mapping application It will also use this collected map data to form a path to known goals 5 Milestone 5 Project Completed Once all subsystems are reporting to the mapping applica tion we have another system testing and debugging phase When this phase is completed the overall project can be said to be completed This is an ticipated for completion at the end of the Spring semester IV RISK ASSESSMENT amp MITIGATION Part of any design 1s to perform a risk assessment and provide mitigation plan for the items that were discovered to have a risk of negatively impacting the project The following section will address the critical risk factors and measures we have taken to address those risks For each risk an associated value of Low Medium High or Very High is assigned depending on the overall impact this will have on our project Our estimated probability of this event occurring is assigned using the same scale This allows us to focus on which risks need the majority of our attention in order to mitigate them The follo
118. r software to take full advantage of Windows 8 functionality See microsoft com for details This system is preinstalled with Windows 7 Pro software and also comes with a license and media for Windows 8 Pro software You may only use one version of the Windows software at a time Switching between versions will require you to uninstall one version and install the other version You must back up all data files photos etc before uninstalling and installing operating systems to avoid loss of your data This system may require upgraded and or separately purchased hardware to take full advantage of Windows 7 functionality Not all features are available in all editions of Windows 7 See windows microsoft com en us windows7 products home for details Maximum memory capacities assume Windows 64 bit operating systems or Linux With Windows 32 bit operating systems memory above 3 GB may not all be available due to system resource requirements For hard drives and solid state drives GB 1 billion bytes TB 1 trillion bytes Actual formatted capacity is less Up to 16 GB for Windows 7 of system and up to 36 GB for Windows 8 disk is reserved for system recovery software Absolute Data Protect agent is shipped turned off and must be activated by customers Service may be limited check with Absolute for availability outside the U S The optional subscription service of Absolute Recovery Guarantee is a limited warranty Certain conditions apply For full de
119. r ul Rx Yik Du Rx sin w 0 11 Rx sin Op a 15 Oik Ori ar 16 The major difference between the two kinematic models is the is that one is based upon calculating velocity information for each wheel and the other is based upon assuming that the robot executes its previously given command We expect that the velocity command based model has more accurate twist information and that the encoder output based model has more accurate positional information We are actively monitoring which seems to pro duce better results Due to the modular design of our system switching back and forth between the two sources is easily accomplished by just chang ing a few lines of code An alternate but more complicated solution is to use the two models and filter them to get the best results possible prior to plugging them into the EKF 22 D Collision Avoidance Due to the fact that we ultimately envision our system to run autonomously some type of collision avoidance algorithm must be implemented Luckly as part of the Eddie Bot turn key solution we received from Parallax five dual Ping IR combo sensors were included with our purchase The term combo basically refers to a fancy mount that holds both a Ping ultrasonic distance sensor and a Sharp IR sensor This setup is designed to be dropped into our Eddie board Since the Eddie board has slots for all five of the dual combo sensors we originally decided to use them as desc
120. r credentials to github is too wearing on your fingers you can set up git to cache credentials by typing in the command in Listing 12 Verify that the system compiles all required software gat config global credential hNhelper cache Listing 12 Cache Credentials Verify that your project builds by running a catkin_make now There should be no compiling or linking errors Modify bashrc Now we can modify our bash configuration file to include a couple of important configuration changes Run the commands in Listing 13 to finish up con figuring the bashrc file UI SIS ES whoami gt eon SUSHR oasis home U ER Da e Listing 13 bashrc configurations Special compiled ROS Software Installations Interfaced libraries e viso2 ros mono odometer borrowed from Andreas Geiger 3 e robot pose ekf part of the navigation stack borrowed from willow garage s Navigation stack To install viso2 ros mono odometer go to the projects github page https github com srv viso2 and download the repository extracting into your catkin_ws src directory After this is extracted a simple catkin make should build the appropriate nodes To install robot pose ekf we need to install the BFL library install via sudo apt get ros indigo bfl Once this is installed we download the project from https github com ros planning navigation and ex tract the robot pose ekf to your catkin_ws src di rectory After this is extracte
121. r visual odometry data 6 DOF Robotic Manipulator Developed software for controlling a 6 degree of freedom robotic manipulator Created debugging GUI in PYQT4 to expedite calibration and algorithm development Inverse kinematics were performed numerically by using Monte Carlo simulations Stereo Vision Object Tracking Object detection with real world position and velocity estimation using stereoscopic camera correspondence Servo Motor Custom servo built using PID position control of a brushed DC motor gear reduction and an IMU as a feedback sensor Reconfigured system to use a webcam as a feedback sensor to track objects and keep them in frame Camera Gimbal Implemented a two axis gimbal system in order to maintain a constant attitude of a camera through the control of two servo motors PC used to interface a digital gyroscope and accelerometer sensor fusion performed using a digital filter SELECTED WORK EXPERIENCE S City of Roseville Information Technology JUN 2008 May 2015 Junior Systems Administrator Managed over 300 enterprise class servers across two data centers Experienced in nearly every area of systems administration including VMware Linux Windows storage backups antivirus and compliance Extensive experience in virtualization products such as VMware vSphere and Citrix Xenapp Intel Corp JUN 2006 Dec 2006 Testing Intern Assembled computers and tested Intel s RAID drivers on pre release hardware and software
122. ra e Philips cross head screwdriver e Scissors e 5 32 Allen wrench e Microsoft RDS software e A Keen Imagination Important Precautions e After switching main board power off wait at least 5 seconds before switching power back on Rapid and repetitive power cycling of the board and motor power supplies causes significant stress on electronic components and may damage the board and or connected electronic accessories e Use caution when handling the drive motors or Control Board as some components may become hot after prolonged operation e Asin most electronic devices Eddie contains components which are sensitive to static discharge Exercise proper grounding practices prior to touching or working on the robot Assembly Instructions Note For pre assembled Eddie 28992 go to Step 10 Step 1 Motor Mount and Wheel Kits Pre assemble the Motor Mount and Wheel Kit and the Caster Wheel Kits by following the instructions that came with each of those products Set them aside for now Step 2 Parts Inventory After you have completed the assembly of the Motor Mount and Wheel Kit and the Caster Wheel Kits carefully unpack the remaining components and sort them into their respective groups You should have the items listed in the Bill of Materials table below Copyright Parallax Inc Eddie Robot Platform 28990 amp 28992 v1 3 1 16 2013 Page 2 of 17 61 Bill of Materials ar Bam Delon OOo Standoff 5 2 Diamet
123. re 1s realized in C and as such we need to test this feature by utilizing its existing infrastructure As this feature 1s dependent upon other features we will be testing this feature in three separate phases 28 a Phase One This phase will be to run simulations by creating a node that simulates the data that is published from the wheel encoders via the Serial Communication feature By using known velocity controls we can precisely calculate where our robot should be and verify the output of the feature 1s correct This Phase will test the following elements of our system e The mathematical accuracy of our kinematic calculations e The features theoretical ability to communicate with other features via ROS b Phase Two This phase will be to test the accuracy of the wheel encoders which are the inputs to the wheel encoders Although wheel encoder data isn t specifically mentioned in the feature descrip tion it 1s essential to have a gauge of the accuracy of the data being inputted into the feature during actual run time The testing method will be very simple We will send commands to the robots chassis to have its wheels spin one complete rotation By measuring the wheels distance move and comparing it the output of the wheel encoders we can gauge if there are errors in the wheel encoder inputs This Phase will test the following elements of our system e Verify the precision of our encoders e Verify accuracy of incoming d
124. rential Drive Robotic Platform 3 I C6 lg lt td daa dd ee ee BE 4 I D Ecatire Detalle aaa dl Se de e Node do Se We i agen 4 I D1 Kinematic Model assi ar ce a we te acy Ge dehy ie ose Sh ce Sap led 4 I D2 Path Planning PT 4 I D3 Visual DISMAY a urs do aee d ente dh aes dh cele Be ei Se ente ue t An HRD 5 I D4 gia APT a a a A ole Be ae Se setas da Gee Ba Be ZS 5 I D5 Collision Avoidance 42 x4 xo doe dad 3S 3m ee 5 I D6 Gyro amp Accelerometer a s aie qox e deem ag eo d rent De diee den 5 I D7 Communication With a Robot Chassis 5 I D8 Visual Odometry Requirements 00004 6 FE Computer and Hardware Requirements le 6 EF Testing Debugging and Specific Documentation 6 I G Resource Estimates iii a dca dro Abtei ACCES RS ORC doe e CECI OUR se c ht 6 Funding Proposals 6 Work Breakdown Structure 7 HIA dOutline OE WBS 4 onde d eds wee d et dl ede E A A 7 IL A Kinematic Model ae a d doas mcm pes t a le da le a T a de le a 7 III A2 Path Plannin racer e indie e Ue 16 Un a X da Sal r Nee abe Sov ugeet 7 III A3 ViSWaL DISPLAY a ud oor a e BOR rd ted a ome tne iS SE ee oL GI 8 III A4 laci A T E 8 III A5 Collision Avoidance cm eumd s mem e deed xm ome RE e KA Se 8 III A6 Gyroscope amp Accelerometer c r 8 III A7 Communication With a Robot Chassis 8 IL AS Visual Odometry Interface
125. ribed from factory However during development we discov ered that the IR sensors have a non linear output and are subject to various environmental factors For example the reading that our IR sensors output are different depending on the color of the object This difference can be as much as 10 which makes utilizing the IR sensors for Collision Avoidance a very dangerous proposal This is why we chose not to include the use of the IR sensors in our final design For the previously discussed reason we have chosen to only use the five ultrasonic ping sensors furthermore we discovered that the on board pro cessing power could not simultaneously sample five ping sensors while sending and receiving serial drive commands This created unwanted lag in our system so we opted to have an external controller dedicated to just the ping sensors this is how we arrived to the solution of a dedicated Atmega 328 microcontroller to control the ping sensors To ensure the validity of our ping data we setup a small test bench were we performed two tests For the first we placed the ping sensor 12 inches away from a book for the second we moved the book to 28 inches We then directly compared the result of each ping sensor to the actual measured distance We did this for all five sensors and found that they were were accurate to 5 centimeters After the individual testing we tested again with all the sensors connected and found that this time the sensor me
126. rly function while getting goals in case the environment has any unexpected changes The path planning program must be programmed with a few commands to determine the type of oper ation First there must be an explore mode where the robot automatically roams around the room with a preset path plan and performs collision avoidance during travel Next there must be a find object command that allows the user to choose an object at a known set of coordinates and have the robot go to that object still performing collision avoidance and obeying the non holonomic constraints of the system as to not cause a software failure during goal seeking And finally there must be a remote stop command to terminate the program There is an explore button on the control script that begins the SLAM program The path planning program can be preset to start after detecting 1 to 4 faces before automatically performing the path planning process or the fetch button on the control script can be pressed any time to begin the process With no goals detected the robot simply goes to the starting home point G Visual Odometry Interface One of the main design requirements of our project was to be able to control a mobile robot by using a camera as a sensor Cameras can be used to control robots in a multitude of ways We chose to implement a system that utilizes the camera to produce localization data This is commonly known as VO VO is often used to
127. s This test will ensure that the path planning node has the ability to navigate to various preset destinations This test can be accomplished by using the goal detection feature or by publishing artificial goals When the GOTO button is pressed on the control GUI the path planning node should begin to navigate towards the first goal and then the second goal The path doesn t need to be the 20 optimal path but the robot should not need to re explore the environment to find that location This Phase will test the following elements of our system e The ability of the feature to allow the robot to navigate to a specific desired locations 3 Visual Display The visual Display captures data from the kinematic model IMU EKF and Visual Odometry features It then displays this data for a user This feature will be implemented in C The accuracy of the visual display 1s important because it will be used in debugging of the system In particular if there are scaling issues it could result in improper tuning of the EKF which will result in a deviation from desired result Testing of this feature will be in two phases a Phase One Phase one will be to test the ability of this features software to capture data from all sources and display it as it changes on the display To perform this phase of testing a separate program will be written to publish data on the specific topic that each input will use This program will be interfacing with a
128. s this sub system communicates the control systems desired velocity information to be implemented by the robots firmware board If this communication were to break it could result in undefined behav ior of the robotic chassis and catastrophic system failure With the design priority of reliability set we began researching existing C libraries that allow for the establishing serial communication via the USB connection on the PC There were multiple implementations that were found but in the end we chose to find a solution based upon the boost libraries because they are open source and highly documented We were able to find a light weight open source wrapper of these libraries that allowed easy integration into our existing software develop ment environment Once we had proven that we could establish com munication between the robotic chassis and the PC via the USB cable we then began focusing on how we are going to integrate our software into the Robot Operating System environment The modifications to our existing serial program involved allowing it to capture published messages from other nodes and relaying these messages to the robotic chassis This allows multiple nodes to pass or receive messages at the same time During development we discovered that robotic chassis communicates with signed hex represen tation saved into standard c string format This proved problematic due to the inherent nature of humans to desire visual di
129. s to develop a control algorithm for use on an autonomous robotics platform Specific contributions involve creating the system integration plan a visual display multiple GUI s an Unscented Kalman Filter and a serial driver in C and Python Specific libraries utilized Boost ASIO OpenCV PYQTA Scipy and ROS Embedded Controller Design Designed and implemented a control system utilizing an ARM based single board computer loaded with Debian The system challenges involved integrating a machine vision algorithm a GUI a PID Controller a serial driver and thread manager utilizing C Specific libraries utilized OpenCV Atomic Boost Thread and QT4 WORK EXPERIENCE Administrative Leading Petty Officer June 2008 Current Legalman Operational Support Unit United States Navy Reserves Support JAG Attorneys in generating presentations while performing duties as a paralegal Technician John s Incredible Pizza Company Roseville CA September 2008 June 2012 Perform maintenance and repairs of small amusement rides computers network equipment commercial appliances and arcade games Consolidated Automated Support System Technician Aviation Electronics Technician United States Navy March 2003 June 2008 Utilize manual and automated test equipment to troubleshoot and repair complex avionics systems HONORS e Received Letter of Commendation from Commander Naval Air Force Pacific Fleet for technical insight that was instrumental
130. splays of signed decimal numbers even when stored in c strings The existing standard libraries that exist for performing this type of conversion did not perform to our expectations Once this conversion had been established at began initial testing of this subsystem For initial testing we developed a small program that essential allowed us have a basic terminal interface with the robot chassis The testing program was it s own node that communicated with the our serial driver via publishing a ROS topic called eddie do This essential simulated our control system providing commands for our robot chassis to implement Initial testing proved that our implementation was sound and we began adding additional features to our serial driver node One of the tasks that the serial node 1s responsible for 1s retrieving the values of the encoder ticks from the robot control board This is accomplished by sending the command DIST to the robot control board and waiting for it to provide the amount of encoder ticks that have passed from the last sample time We had originally attempted to utilize standard threading to achieve the a desired delay between sample times to allow the robot firmware to execute other task The addition of a stand thread delay resulted in the serial node being unavailable for time critical functions such as sending stop commands We then implemented a standard time work around that allows us to control the frequency 18 of th
131. st implement a system that receives camera information and images and pro cesses them to output odometry data This will be accomplished through the 8 pt algorithm e Estimated Research Time 100 e Estimated Implementation Time 50 e Estimated Cost 0 00 e Assignee Curtis amp Francisco e Deliverable A software object that can gener ate odometry data from a moving camera 9 Testing Debugging and Specific Documenta tion In order to increase modular development and the lifespan of the system we need to test each module to make sure it works Debugging will occur in parallel to testing to insure proper fine tuning of the system After the successful implementation of each fea ture we will write specific documentation of said feature in order to allow others to replicate our final product a Testing amp Debugging of the Kinematic Model We have to verify that this system works by itself before we include it into the main project In this stage we will attempt to estimate any errors and limitations associated with this feature This test ing and debugging stage involves attempting to fix errors and bugs produced by improperly calibrated sensors or software issues In the case that an error or bug cannot be fixed it 1s to be documented for later tweaking e Estimated Research Time 5 e Estimated Implementation Time 35 e Estimated Cost 0 00 e Assignee Chris e Deliverable A set of tests that ensure that the
132. storage techniques it allows our program to be faster and easily improved We initially started looking into the various types of models that can be created for a differential drive robot Because we are interested in tracking the location of the robot throughout its run we focused on forward based kinematic modeling This simply means that we are going to use a system of equations to get the required data that we need Draw image requested Create Blank image Create display window Calculate value of pixel in meters Draw vector data on image Draw grid lines to scale on image Write map scale on image Yes Display image to user Put process to sleep to conserve CPU Sleep time over NO Fig 13 Visual Display Flowchart 21 During creation of our first kinematic model we discovered that our wheel encoders didn t have the precision that we originally thought We discovered that we had expected 64 encoder ticks per revolu tion but were actually achieving 32 This means that any direct reading of the encoders could be off as much as 25 inch every reading This error would ac cumulate over time and could cause significant error over time Instead of attempting to directly read the wheel encoders we decided to capture the velocity commands being sent to the robot chassis and store a time stamp We will then use this command and the time stamp to generate odometry information This method makes a ma
133. t and right drive components of the robotics platform This data is expected to be gathered from wheel or shaft encoders e Estimated Research Time 5 e Estimated Implementation Time 20 e Estimated Cost 0 00 e Assignee Chris e Deliverable A software object or function that can gather angular velocity commands from encoder data b Convert Angular Velocity to Linear Pose After this feature has gathered the angular velocity of the robot it will convert it to linear distance traveled It needs to attach a scale to the data e Estimated Research Time 20 e Estimated Implementation Time 40 e Estimated Cost 0 00 e Assignee Thomas e Deliverable A software model that can deliver a measurement of the distance the robot has traveled c Estimate Covariance The data generated by the model needs to have a covariance associated with it in order for it to be plugged into the kinematic model e Estimated Research Time 20 e Estimated Implementation Time 25 e Estimated Cost 0 00 e Assignee Chris e Deliverable A software object or function that can provide an estimate of the error of the data associated with subsection IMI A1b 2 Path Planning A key feature in almost any mobile robotics system is the ability to use available sensor data and find a path to a desired point Path Planning is the term typically used to describe this process There are many models currently available for Path Planning Our system nee
134. t industry test equipment Hardware Discrete component and IC chip project design using various chips types FPGA s Parallax Propellor IC MicroChip IC s etc Education A S Degrees in Mathematics Physics Engineering Electronics Technology 80 Christopher Laney Summary of Qualifications Electronics Technician with comprehensive experience in both civilian and military small and large scale communication systems RADAR commercial electrical wiring including generators and a multitude of electronic and computer systems Extensive experience at board level discrete component repair Effective at training technicians and laypersons Industry Certifications e CompTIA A and Network Plus Certified e NFPA Certified Electrical Safety Compliance Professional CESCP Accomplishments v Engineered electronics communication interface between newer large scale multi user system and existing peripheral communication devices Y Increased propgation characteristic parameters of communication trasmission stations by improving ground plane characteristics designing filter modifications and recalculating A spacing height adjustments for improved lobing patterns Professional Experience Defense Companies 1997 Present e Maintain and repair electronics equipment e Troubleshoot and design solutions to equipment problems Technical Skills Test Equipment Oscilloscope Spectrum Analyzer Vector Volt Meter Network Analyzers RF generators and
135. t is estimated that our system will require further optimizations to increase performance and get more accurate data For optimization purposes we require the ability to process separate tasks in parallel with one an other One existing technology known as the Robot Operating Software or Robot Operating System ROS will be chosen to help us accomplish parallel processing ROS is a technology that was initially developed by Willow Garage and is heavily used in robotic research and development 10 Because ROS is currently only supported on Ubuntu Linux environments our laptop computer must be able to run Ubuntu Linux This Linux system must be maintained properly to ensure a stable computing environment The type of camera needed for this project first and foremost needs to be compatible for use within a Linux environment It also needs to have a min imum resolution of 640x480 We also need to be able to control many parameters of the camera itself including resolution white balance auto focus brightness and sharpness Being able to fix these parameters to known values allows for a more consistent and controllable testing environment F Testing Debugging and Specific Documentation In order to increase modular development and the lifespan of the system we need to test each module to make sure it works Debugging will occur in parallel to testing to insure proper fine tuning of the system After the successful implementat
136. tails visit absolute com company legal agreements computrace agreement If Data Delete is utilized the Recovery Guarantee payment is null and void In order to use the Data Delete service customers must first sign a Pre Authorization Agreement and either create a PIN or purchase one or more RSA SecurlD tokens from Absolute Software Some functionality of this technology such as Intel Active management technology and Intel Virtualization technology requires additionalthird party software in order to run Availability of future virtual appliances applications for Intel vPro technology is dependent on third party software providers Microsoft Windows required HD content required to view HD images Wireless access point and internet service is required and is not included Availability of public wireless access points limited Sold separately or as an optional feature The wireless hotspot application requires an active internet connection and separately purchased data plan While HP Wireless Hotspot is active on device applications will continue to work and will use the same data plan as the wireless hotspot Wireless hotspot data usage may incur additional charges Check with your service provider for plan details Requires Windows 8 Requires an internet connection to HP web enabled printer and HP ePrint account registration for a list of eligible printers supported documents and image types and other HP ePrint details see hpconnected com Mob
137. testing node and having the serial communication software transmit it via the USB to the robot control board The program should close the serial connection and reopen it at least 500 times to verify that the connection can be re established without error This phase should also have a time test that tests leaving the communication on for a very long time such as 3 hours This Phase will test the following elements of our system e The reliability of the connection and interface e The repeatability of the connection and inter face 7 Visual Odometry Interface The visual odom etry feature will accept images process them and output odometry data The feature will be imple mented in C or third party software It is im portant that a precise measure of this feature is understood as our sponsors are very interested in this feature The environment which these tests will be performed needs to be controlled and stale as the 3 VO calculations will assume that only the camera is moving This feature will be tested in three phases a Phase One The first stage of testing will be this features ability to accept an image and output unscaled Rotation and Translation matrix This is the first stage of processing for the visual odometry system and it 1s imperative that this first step is understood and tested thoroughly It 1s specific to note that during this phase of testing that run time errors are understood such as segmentation faul
138. the data being provided by the sensors b Phase Two The second Phase will be to test the ability of the micro controller to provide data to the software in the PC This will involve third party software for the serial communication and not the robot serial communication feature For this phase of testing we will use the same type of test as phase one except that we will be broadcasting the data to the software in the PC The PC software only needs to display the output from the micro controller If the accuracy of the sensors 1s the same as the value measured in phase one then it 1s a safe assumption that there isn t any data corruption due to the third party software This Phase will test the following elements of our system e The accuracy of the data after serial transmis Sion e The reliability for the micro controller to inter pret the data being provided by the sensors e The reliability of the third party serial connec tion software c Phase Three The third phase will be to create PC software to use the data that 1s being transmitted to stop the robot We are going to send velocity commands to the robot that will set 1t on a path to collide with a wall The PC software that implements the collision avoidance must stop the robot from crashing into the wall There must be little to no lag between when the stop point of 30 cm is passed and when the robot begins deceleration This phase will test the following elements of this
139. truth when performing simple B Resource Estimate Summary The features that were described in the previous sections all require hours of research and develop ment An estimate of the amount of hours per task is shown in Table III along with who will be assigned to what task C Project Timeline This project is intended to span two semesters and the tasks and work breakdown structure for the duration of the project was initially estimated at the beginning of the Fall semester As this project has 10 TABLE III Man Hours Estimated Hours Assigned to Kinematic Model Chris Path Planning Chris amp Thomas Visual Display Curtis amp Thomas Filtering Chris amp Thomas Collision Avoidance Francisco Chris amp Francisco Thomas Curtis Curtis amp Francisco Curtis amp Francisco Gyro amp Accelerometer Robot Communication Linux Maintenance VO Goal Detection progressed through the Fall semester the timeline was updated to reflect the upcoming tasks goals and challenges that lie ahead to produce the final product 1 Milestone 1 Visual Control of a Robot Be cause our robot project is designed to use cameras as a sensor to be used on a mobile robot it was determined that as a proof of concept we should attempt to demonstrate that we can control our robot through mainly using machine vision As a bread board proof of our system we demonstrated visual control of our robot by making it locate and drive to an
140. ts When errors are found the specific run time error should be repaired and then the testing cycle should start again completely For example if 300 hours of testing are to be performed for the phase of testing to be completed and an error occurs at hour 290 the timer must be reset To perform testing for this phase start the VO node and observe the output of the system for a certain number of time By varying the cameras location new images will be produced which will help identify run time errors By moving the camera left and right the tester should observe that the Rotation and Translation matrix change with the movement The tester should keep in mind that the data 1s unscaled and will be dependent on the cameras current environment This Phase will test the following elements of our system e The reliability of the features ability to accept and process images e The ability of the feature to produce consistent data b Phase Two The second stage is to correlate the data into real world coordinate axis This can be accomplished via external calibration standards such as an IMU The goal of this test 1s to ensure that when the translation matrix states that camera has moved forward in a specific direction that the robot has actually moved in that specific direction By ensuring proper coordinate axis configuration we can help prevent scaling and debugging errors This Phase will test the following elements of our system e The abil
141. ug the Eddie control board USB cable into the laptop NOTE This MUST be the First usb device connected Plug in the Atmega328 microcontroller de velopment board and verify that all 5 ping sensors are flashing green lights If not open the Sketch IDE and re load the col lision avoidance ino file Verify all 5 ping sensors are flashing before proceeding Plug in the USB camera Open a Terminal window Launch the production SLAM program from a bash terminal e roslaunch production master launch e On the control panel press the explore softkey and the program will begin e The map on the terminal will continu ously update the explored area and will also place a number 4 thru 7 based on the face When the pre set number of faces has been identified the robot will automatically perform path planning from its current location to the starting point go to each of the faces detected then return home and stop To drive the robot around 1 Place Eddie at least 50cm from any walls or objects 2 Option 1 Perform above instruction including typing roslaunch production master launch http releases ubuntu com 14 04 http wiki ros org indigo http wiki python org moin PyQt4 Shttp arduino cc en main software http learn parallax com propeller c set simpleide e Use sliders and commands on control script to move robot forward backward or turn 3 To STOP robot press stop button on con trol script Al
142. ver a simple USB connection and a convenient open source command interface Features Key Specifications Compatible with Microsoft Robotics Developer Studio RDS4 Two tiered design provides plenty of room for electronics as well as convenient laptop mounting for un tethered autonomous navigation High torque 12 VDC gear motors Durable 6 diameter pneumatic rubber tires traverse various types of surfaces and terrain Three Infra red distance sensors and two ultrasonic distance sensors for object detection and collision avoidance Integrated control board handles all low level hardware operations to control motors and collect sensor data Twin high capacity 12V 7 5 Ah sealed lead acid SLA batteries provide significant run time between charges USB connectivity Built in charging jack charger included Application Ideas T e Autonomous navigation and mapping Communication Interface Serial commands over USB interface e Development and testing of machine l vision systems Operating temperature 32 to 158 F 0 to 70 C Tele presence robots Dimensions 21 75 55 25 cm high e Voice activated personal assistant robots 17 8 45 2 cm Diameter e Security and surveillance robots Robot Weight 25 3 Ibs 11 5 kg e Crowd interaction and advertising Copyright Parallax Inc Eddie Robot Platform 28990 amp 28992 v1 3 1 16 2013 Page 1 of 17 60 Additional Items Required e Laptop Computer e Kinect Came
143. wing risk assessment chart outlines the risks and likelihood of failure of our feature set as perceived by our team Note Risk assessment is in the following format Likelihood Impact A Kinematic Model There is a chance that the wheel encoders introduce as much as 2 5 inches of error second Low Medium Impact Low Medium High Very High Very High O S High Uv x Medium Low Fig 1 Risk Assessment 2 All kinematic models have constraints that must be addressed in the software and com plex programming can cause considerable risk to a projects success Very High Low Steps Taken to address risks 1 We have researched how to update the en coders and possibly the firmware associated with those sensors 2 We will test our model thoroughly prior to demo b Path Planning There are some considerable constraints placed on our implementation of Path Plan ning caused by the VO nodes requirements and this may lead to a much longer develop ment time than expected High Medium Steps Taken to address risks 1 We have started research Path Planning mod els that are well suited for controlling differ ential drive robots that have the ability assist in working around constraints C Visual Display 1 Event driven display software is highly sus ceptible to runtime errors Medium Low Steps Taken to address risks 1 We will have to use some type of exception
144. wrapper program for complex libraries It is preferred that the feature be programmed in C but Python 1s acceptable The feature should use a well docu mented software library to interface between the operating system and the USB port By utilizing well documented libraries it will prevent possible communication errors This feature can be considered accomplished when it can accept input from the Path Planning feature and communicate this data to the robotic platform via USB cable The feature will have a minimum 93 success rate for data transmission The feature must be able to sustain serial commu nication for over 45 minutes without causing system errors 8 Visual Odometry Requirements The VO sys tem must be able to accept an image for processing and output odometry or equivalent data About 90 hours of this will be performing research with 100 hours of implementation and the remainder of the time should be for debugging physical testing of the feature E Computer and Hardware Requirements Due to the fact that the vision system will be our most computationally intensive part of the project To technically implement this we will require our system to be able to run on a modern computer with a multi core CPU processing speed of no less than 1 3 GHz Because the desired platform is a robotic system this computer needs to be portable This implies that we must use a laptop for a portable computing environment Even still i
145. x 5 8 Black oxide screws from the underside of the Base and fasten to the two sets of 4 of standoffs as shown in Figure 6a The long standoffs are for the Eddie Control Board and the 1 5 standoffs are for the Wiring Harness Switch Plate assembly Figure 6a Place but do not attach the Wiring Harness Switch Plate assembly onto the Base as shown in Figure 6b Carefully thread the Red and Black wires through the hole that s between the set of short standoffs Double check to make certain that the Power Switches are both off as shown in Figure 6b Figure 6b Copyright O Parallax Inc Eddie Robot Platform 28990 amp 28992 v1 1 1 16 2013 Page 9 of 17 69 Step 7 Battery Shelf Installation Flip the Base over place the two Sealed Lead Acid batteries on the bottom of the Base and connect the Red and Black wires to the corresponding colored terminals as shown in Figure 7a Figure 7a Refer to Figure 7b Carefully rotate the batteries and gently place them between the two drive motor assemblies This should be a nice tight fit Be careful to not short the terminals of the batteries against the frames of the motor assemblies See Figure 7b Figure 7b Copyright O Parallax Inc Eddie Robot Platform 28990 amp 28992 v1 1 1 16 2013 Page 10 of 17 70 Place the pre assembled Battery Shelf over the cells and slide it into alignment so that the the thru holes line up with the tapped holes in the Motor Bearin
146. y using a Gaussian filter that has been extended to work on a non linear system Examples of such filters are the Extended Kalman Filter Un scented Kalman Filter or Sparse Extended Informa tion Filter This filter will need to be implemented in software preferably writtin in C The filter can be a programmed by the team or open source third party software can be used if available This feature can be considered accomplished when it can accept input from the VO kinematic model and Inertial Measurement Unit IMU fea tures and provide meaningful output about the robots location in relation to its surroundings The output of the filter needs to be more accurate than the least accurate sensor input that 1s provided to it when compared to ground truth 5 Collision Avoidance Another essential re quirement is to incorporate two different types of collision avoidance sensors Our system will use five ultrasonic and five infrared distance sensors One sensor of each type will be placed in five pre determined locations across the front of the platform The ultrasonic sensors will detect semi rigid and solid objects while the infrared sensor can detect loose fabric material The two sensors provide redundancy and provide an optimal setup for proximity and object detection These sensors will be programmed to work with a microcontroller using C and C This feature can be considered accomplished when the microcontroller can communicate in

Team 1 - Simultaneous Localization and Mapping Robot (SLAM)

Contents

Download Pdf Manuals

Related Search

Related Contents