Odyssey. Build and Test Plan

Transcription

1 Build and Test Plan The construction and programming of this autonomous ground vehicle requires careful planning and project management to ensure that all tasks are completed appropriately in due time. The following paper details the goals for the build and test phases of the project. Team Members: Anshul Tandon Brandon Nasion Brian Aidoo Eric Leefe Ivan Bolanos Donald Lee Hardee Wilfredo Caceres Advisors: Mr. Bryan Audiffred Dr. Michael C. Murphy January 26,

2 Table of Contents Odyssey Build and Test Plan... 1 Resource Division... 4 Task List & Gantt Chart... 5 Build Plan... 7 Batteries... 7 Monitoring System... 7 Wiring/Fuses... 7 Battery Placement... 8 Battery Life... 8 Battery Charging... 8 Voltage Regulation... 8 Motor Interface... 8 Low Battery Protocol... 9 Vision Sensors - Hardware... 9 Vision Algorithm - Software... 9 GPS & Compass - Hardware GPS & Compass Software Emergency Stop Software Test Plan Batteries Monitoring System Wiring/Fuses Battery Placement Battery Life Battery Charging Voltage Regulation Motor Interface Low Battery Protocol Camera Orientation Camera Image Gather Rate Rangefinder Orientation

3 Rangefinder Image Gather Rate Image processing detecting lanes Image processing detecting potholes Image processing detecting obstacles GPS Compass Motor Controls & Encoders Steering Algorithm Emergency Stop

4 Build and Test Plan Resource Division The resources that will be required for the construction and testing of the vehicle have been demarcated into different categories based upon areas of expertise. Globally, the team is divided into two sections, the group of Electrical and Computer Engineering, in charge of the electrical and software aspects of the vehicle, and the Mechanical Engineers, in charge of the hardware and mechanical aspects of the vehicle. The Mechanical engineers would undertake the tasks of construction and assembly of the chassis along with manufacturing and fitting specific components to the vehicle. They will also undertake the hardware testing and overall construction of the vehicle. The Electrical and Computer Engineers would undertake the tasks of software programming and the assembly and test of the sensors and electrical equipment such as the battery and charging units. Within these specific groups, the people who are the area owners will be the key resource in the construction and test of their areas. The area owners are the designers of their features and have a better conceptual idea and vision of their features. They will be responsible for ensuring that their areas are working appropriately once the vehicle is built and completed. 4

5 Task List & Gantt Chart Odyssey During the course of the project, we will have several milestones that would help us manage the progress of the project and keep us on track towards our final ultimate objective. The milestones have been spread throughout the timeline and are based upon the current desired completed status of the project. Milestone Date Description M1 Feb 15, Finalize Software Interfacing Details M2 Feb 28. Finish General Assembly + Individual Component Testing Beta1 Mar 07, Finish consolidating software stage 1 Beta2 Mar 22, Finish consolidating software stage 2 Beta2TR Apr 06, Finish all individual software components, start overall test Release Candidate Apr 23, Ensure overall vehicle ready, triage any required changes Release to Competition May 01, Odyssey ready for demo and competition The following Gantt chart displays the above task list in a graphical fashion. 5

6 6

7 Build Plan Odyssey The construction of the robot will be done in phases. As outlined in the Gantt chart, the assembly and coding sections of the project will be undertaken separately ensuring that all parts connected to the vehicle assembly are functioning appropriately. Batteries Batteries will be periodically inspected for any type of deformation or corrosion developing on any of the cells. If any of these damages are noticed, immediate repair will be necessary before any further testing can be performed. Any battery cell that has become degraded below acceptable standards will be removed and if time and budget permits, another cell will be purchased for replacement. If the battery cell cannot be replaced, we will have to make some alterations to our design to compensate having one less battery to operate the vehicle. Monitoring System The battery monitoring system includes an analog to digital converter, a PIC12C671, and a voltmeter software display acquired data in a user-friendly form. The A/D chip is designed to convert up to a maximum voltage of 5V. Since this particular application requires a measurement of at least 12V, resistors will be used to scale the voltage of the battery to about 5V for the A/D chip to correctly handle the conversion. The PIC12C671 will then be programmed to interpret the various voltages between 0 and 5V as a relative voltage between 0 and 12V. This interface will not be able to obtain voltage measurements of 100% accuracy, but it will be completed to provide real-time readings accurate enough for a user to diagnose any possible electrical malfunctions. This subsystem of the power system will require the most exhaustive testing procedure because it will be relied upon in testing sensor components and other system. Wiring/Fuses The wiring for all components in the vehicle will be organized in a mannerly form to aid in any troubleshooting of faulty connections. All wiring will be color-coded and labeled according to the components it connects. Size is also very important therefore extra attention will be used in making the wires as short as possible. As the vehicle travels the obstacle and navigation course, the wires may be subject to small forces which may loosen or even detach connections from components. Fuses will also be used to protect the components from possible surges in current. All wires will run through an electrical box where the will connect to a fuse rated at the maximum current value of component being supplied the power. Loose wiring and blown fuses are a common point of failure in electrical systems, so thorough testing of these parts will minimize the risk of this hazard. 7

8 Battery Placement Odyssey The placement of the batteries in the vehicle will largely impact the maneuverability of the vehicle. The batteries will be placed in the bottom compartment of the vehicle to have a lower center of mass. The exact placement in this compartment will be determined through trial and error examining which configuration creates the best handling of the vehicle and minimizes damage to the batteries. Battery Life The battery life of the vehicle will depend upon the power dissipated from the two power subsystems in the vehicle. The power for the sensing hardware has a calculated battery life of 2.36 hours and the power for the motors has a calculated battery life of 3 hours. Since theoretical values almost always differ from experimental, extensive testing will be executed to determine the real battery life and will be repeatedly tested until an acceptable value of at least 2 hours for each subsystem is achieved. Battery Charging The battery charging system will consist of a Battery Tender 12V 4-Bank battery charger and a Battery Tender 12V 2-Bank battery charger. Both chargers will be placed on board of the vehicle in the same compartment as the 6 batteries. They will be connected to the batteries while the vehicle is in operation so that whenever a recharge needs to be administered, the cords from the chargers can be plug into an AC wall outlet, and the batteries do not have to be removed from the vehicle. The will also be bolted to the frame to prevent them from damaging any surrounding parts. Voltage Regulation Voltage regulation will be provided by a two 12V Low Dropout Dual Output Regulators with Enable pins and a 24V Single Output Regulator with an Enable pin. These ICs will be soldered to a printed circuit board placed inside of the electrical box where the camera, GPS unit, digital compass, and the laser range finder. A DC to DC converter will be placed inside of the vehicle to provide voltage regulation and power conversion for the on board laptop. This will be placed in the middle compartment of the vehicle near the electrical box. Motor Interface The motor interface will consist of four batteries to power both of the 24V motors and a motor control unit receiving serial commands from the processing unit. The motor control unit will be place above the two motors towards the front the vehicle for close communication with the laptop and motors. The heat generated by the motors during 8

9 operation is a major concern because certainly an excessive amount of heat can cause sensitive electrical components to malfunction. Testing will determine whether our design is enough to prevent the heat from damaging components in the vehicle. Low Battery Protocol The low battery protocol will be implemented using software programming and sending a signal to the Enable pins of the regulators to turn off certain components in the event the batteries begin to wear out during the competition. The software will have a specified voltage programmed into it and if the monitoring system detects the batteries have reached this voltage, a signal will be sent to the software to begin executing the low battery protocol. During the autonomous challenge course, the GPS unit is the least significant component so it will be the first sensor to be turned off. If the voltage drops to a more critical level, then the digital compass will then be turned off. For the navigation challenge, the camera will be the first component to be turned off because the vehicle will not have to detect and follow lane lines. The component to be turned off during this challenge will be the laser range finder. Testing will determine how effective this protocol will be and how much extra runtime can be gained using this protocol. Vision Sensors - Hardware The construction and building for the vision sensors would be done once the parts are tested independently. Once their component and unit testing is complete, they will be integrated in the hardware assembly. Upon attaching these sensors, they will then undergo integration testing to ensure that their meet the requirements for their orientation. The details for the component and integration testing are mentioned later in the testing criteria section. Vision Algorithm - Software Similar to the construction of mechanical parts, the building of the software system that controls the vision hardware will be done independently of the overall system. The software system will first be implemented in Matlab to ensure that the software can gather images from the camera and the rangefinder and render them to produce useful information. Once a working version of the software is complete (in Matlab or in the finally chosen language of implementation), it will be integrated with the overall software system and interfaced with other dependent modules. Then it will be tested to ensure that any integration bugs are removed. Finally, the system will be improved by adding features to provide better software coverage and to add software integrity to the system. Any additions to the software at this point in the system lifecycle would be done only to solve problem initially flagged as 9

10 non-essential issues. These issues may include performing overall tests and writing additional code to handle exceptions or to simply solving problems that have surfaced in integration and testing. GPS & Compass - Hardware Just as with the vision sensors, the GPS unit and digital compass will be tested individually once they are acquired to ensure the proper requirements (accuracy and precision) are met. Once these characteristics are ascertained, the units will be integrated to the overall assembly. GPS & Compass Software The software functions controlling these items will be constructed using the needs dictated by the overall software platform (how the functions will be called and the format in which the data must be returned). Once the functions are written, they will be tested individually to ensure that they work correctly before they are consolidated into the main program. Emergency Stop The emergency stop will be assembled on a custom printed circuit board. Its components have been selected to ease construction and minimize parts. The receiver has an antennae connected to a 433MHz radio frequency receiver that then sends the signal to a decoder than does error correction and data verification. Once the decoder receives a valid signal it changes its pins to indicate the valid data. This then activates a relay which turns off power to the motors. The transmitter does a similar function but in reverse. It is initiated by a user pressed button that triggers the encoder to send the data to the rf transmitter. Software The software will be created using the C programming language and a Visual Studio project to ease compiling and testing. In order to keep an up to date copy of everyone s code we will be using Subversion to do version control. This will allow everyone to work on their own part and submit it when it s done while allowing others to keep working at the same time. This will help keep us organized and on top of the programming. The application will be built from the ground up and an API will be provided to the other team mates so that they can complete their modules even before all the interface code has been written. 10

11 Test Plan Odyssey Batteries Testing of the batteries will be as follows: 1. Measure the voltage of the battery fully charged to determine their maximum voltage. 2. Examine batteries for any possible leakage. 3. Examine battery terminals for corrosion. 4. Examine batteries for possible short circuits. The batteries will be repeatedly checked for these conditions on a weekly basis to make sure the batteries are at peak performance. Monitoring System Testing of the monitoring system will be as follows: 1. Connect the serial voltmeter with its original configuration to a 5V voltage source to test if the serial voltmeter can correctly measure this value. Adjust the voltage source to various voltages between 0 and 5V and verify the corresponding reading on the voltmeter software is correct. 2. Measure the voltage of a fully charged battery to see the maximum voltage of the battery cell. Then the PIC12C671 will be programmed to interpret a 5V reading as the maximum voltage of the battery cell. 3. Place a large resistance (100kΩ) in series with a fully charged 12V battery and connect it to the A/D converter. Analyze the corresponding reading and adjust the resistance accordingly until the maximum value acquired in the previous step is achieved. 4. Apply various voltages to the A/D converter and compare the corresponding readings with the readings of an analog voltmeter. Acceptable readings for the serial voltmeter must be with half a volt (±0.5V) of the readings taken from the analog voltmeter. About 20 measurements and comparisons of this type will be taken at each 1V increment (From 0 to the maximum voltage). 5. The configuration for the single 12V fully charged battery will then be applied to the rest of the battery cells and the same testing procedure will be executed for each one until satisfactory readings are attained and displayed by the serial voltmeter software. After all calibrations are made to correctly measure the voltage, periodic checks will be made to verify the measurements are still correct. Wiring/Fuses Testing of the wiring/fuses will be as follows: 1. Wires will be periodically inspected for loose ends, potential breaks, and bare wire openings and will be repaired immediately. 11

12 2. Small forces comparable to the forces the wires may experience during vehicle operation will be applied to all wires to verify the connections are strong enough to withstand these forces. 3. Each fuse will be connected to a simple circuit containing one resistor. Just enough voltage will be applied to the circuit to produce a current which should blow the particular fuse. Verify that the fuse breaks and current does not continue to flow through the circuit. Battery Placement Testing for battery placement will be as follows: 1. Place batteries in several arrangements and detect the arrangement which incorporates the least amount of force to quickly turn the vehicle in a 360 rotation. This will be done by moving the frame with the batteries placed in it and measuring the exact force. Battery Life Testing the battery life will be as follows: 1. Connect all sensing hardware to four fully charged batteries and simulate course conditions through software to demand the processing unit to dissipate the maximum amount of power required to complete the computations. The total runtime for this system will be recorded until the voltage of the batteries drop below 80% of its maximum voltage (This is when the battery is considered discharged and before becoming in danger of permanent damage from overdischarge). 2. Connect motors to the set of fully charged batteries and send signals to the motors to spin at the rpm that will accelerate the vehicle to 5 mph in about 2 seconds. Continuously decelerate and accelerate the motor at this rate until the batteries have reached the 80% discharge point. This test will give the battery life in a worst case scenario in which the vehicle will be starting and stopping abruptly due to software malfunction. 3. With the entire vehicle assembled, accelerate the vehicle to 5 mph and record time to for the batteries to be discharged to the 80% point. 4. Construct a course similar to the anticipated competition course and allow vehicle to navigate the course. The vehicle must be able to navigate the course at least three times without a recharged needing to be administered. Battery Charging Testing of the battery charging system will be as follows: 1. Discharge each battery until the output voltage is approximately 80% of the maximum voltage. Connect the batteries to the two multibank chargers. 12

13 2. Observe the amount of time it takes for the batteries to output their maximum values again. The amount of time should be no more than 5 hours. 3. Secure chargers in the vehicle along with the battery and apply small forces to the battery charging connectors. Verify that they are able to stay connected to the battery terminals during vehicle operation. After every three recharges, a battery life test will be executed to verify that the batteries are not losing a significant amount of battery life after each recharge cycle. Voltage Regulation Testing of voltage regulation will be as follows: 1. Generate a varying voltage function with an average of 12V and apply function to each of the 12V regulators. Use a dummy resistor that will draw approximately the same amount of current as the component that will use the regulator in this test. 2. Measure the voltage of the resistor with a voltmeter. Verify the voltage is within ±0.5V of the specified voltage of the regulator. 3. Repeat these steps for the 24V regulator. 4. Attach regulators to the actual components and perform the test using the power from the batteries in the vehicle. Motor Interface Testing of the motor interface will be as follows: 1. Connect the motors to the motor control unit and the motor control unit to the batteries. Send serial commands from the processing to accelerate the vehicle at 2 m/s2. 2. Once vehicle speed reaches 5 mph, allow the vehicle to continue traveling at this speed for 5 minutes. 3. Measure the temperature inside each compartment of the vehicle. Verify that none of these temperatures are above the maximum operating temperatures for any of the internal components. If the temperature noticeably impacts the performance of any of the sensing hardware, adjustments to increase ventilation will be made first. If this is not able to resolve the problem, the changes will have to be made to the placement of the components. Low Battery Protocol Testing of the low battery protocol will be as follows: 1. Connect power to each component through the regulators. Execute the software on the processing unit and send the enable bit serially to each regulator. Verify that the components stop operating. 13

14 2. Discharge batteries to the first critical value programmed in the software. Observe the monitoring system to see if the system is able to detect the critical value and notify the processing unit to execute the software. 3. Check components to see if the specified component has stopped its operation. 4. Carefully discharge batteries to the next critical value. Repeat the previous steps to verify if the next component specified in the protocol has stopped its operation. Camera Orientation The camera will be placed on a vertical pole extending from the front of the vehicle. The height and tilt of the camera will be important factors in determining its correct orientation. The ideal position for the camera would yield in a complete view of the course ahead of the vehicle. However, due to hardware constraints such as the focal length and the focal view of the camera, we are aiming to achieve the following: 1. A wide view of the lane such that lanes on both sides of the vehicle can be detected by the camera. In order to achieve this, the camera should be able to see at least 10 feet in width in the closest part of the image. This constraint allows us to view the lanes easily. 2. A long view of the lane such that we can view objects including potholes and lanes up to at least 10 meters (approximately 30 feet) ahead of the vehicle. This number is obtained by calculating the distance the vehicle would travel moving at a target speed in the amount of time it takes to process the image and take decisive actions to turn the vehicle. The orientation of the camera is currently a grey-area which will be exacted once we have the exact parts we will be using. The camera should be placed approximately 5 feet high, tilted at an angle of approximately Following are the test cases that we will be considering: Height (') Tilt Angle ( ) Width - image (') Length - image (') Resolution Acceptable? Success would be measured by the appropriateness of the image resulted if any of these height-angle combinations result in the above two goals. 14

15 If none of the above views provide the desired image, then perhaps, we would have to obtain an objective lens for the camera with a wider field of view. Camera Image Gather Rate The gather rate of the camera would be crucial factor in the image processing and analysis. The processor needs to poll the camera to grab its images and then process them in order to determine the desired direction for the vehicle. The testing for the image gather rate would be done by connecting the camera to the computer and then capturing images from it. The faster the images can be captured from the camera, the better for the vehicle. The computer needs a minimum frame rate of 10 frames per second, in order to avoid missing the lanes traveling at a speed of 5 mph. This is the success rate for the image gather system. If the camera can deliver at least 5 images per second to the computer, the image gather system would be deemed successful. Rangefinder Orientation The rangefinder should be horizontally placed in front of the vehicle at an approximately height of 1 foot. The height of the rangefinder should allow it to detect the obstacles in the path of the vehicle such as the construction barrels, trees, fences, etc. and avoid detecting the inclines. Since the inclines are not obstacles, but simply part of the course, they should not be detected as obstacles. The positioning of the rangefinder should be somewhat less critical, although equally important. Testing for its orientation includes ensuring that the rangefinder can view the 180degree front view of the vehicle without any error and is not tilted in any direction. Rangefinder Image Gather Rate The gather rate for the rangefinder would be significant when trying to determine the obstacles in front of the vehicle. Based on the current technical requirements, the computer should be able to grab an image from the rangefinder every ½ seconds. This means that the rangefinder should be able to perform a sweep of its laser at a speed of 2Hz. Based on the technical specifications of the rangefinder, this is easily achievable by the rangefinder. The testing for this should be done in an experimental setup where the rangefinder is connected to the computer and the computer sends continuous requests to the rangefinder for images every ½ seconds. Success would be measured based upon how fast the rangefinder can return an image to the computer. The rangefinder would meet its desired requirements if it can return at least 2 images within one second. 15

16 Image processing detecting lanes Odyssey The test criteria for detecting lanes should be extensive to ensure that the lanes would be detected by the image processing algorithms in all cases. From the camera s orientation and specifications, the following type of images can be obtained: 1. Two lanes vertically parallel 2. Two lanes turning in some direction 3. One lane vertical 4. One lane horizontal 5. One lane at an angle between 0degree and 90degree to the horizon If no lanes are detected, then the vehicle has moved off course and should not be running. The orientation of the camera should ensure that if the vehicle is on the course, it can always view at least one lane. To test that the algorithm can detect the lanes from the images, the following tests should be performed: 1. Bypass the camera by sending images to the image analysis algorithm and try and detect the lanes. 2. The images used to test the algorithm should consist of a complete set of images: images from each one of the above five categories. 3. Use images that are distorted, that have noise, and that are blurred to ensure that all environmental issues are taken into account. This sort of test would be unit testing where the procedure that detects lanes from images is tested to ensure that it is working appropriately. In addition to its appropriateness, the procedure should also be tested for performance. We need to ensure that the procedure can process the images and detect lanes in less than ½ second to allow time to react. Image processing detecting potholes The test criteria for detecting potholes should also be as extensive as possible to ensure that the potholes would be detected by the image processing algorithms. From the camera s orientation and specifications, the following type of images can be obtained: 1. No potholes at all in the image 2. Simulated pothole image 3. Actual pothole in the image 4. Partial actual pothole in the image 5. Partial simulated pothole in the image 6. Both a simulated as well as an actual pothole in the image If no potholes are in the image, then nothing needs to be done. Images with simulated and actual potholes will need to be treated differently. Simulated potholes can be detected by converting the image to b/w and then detecting a patch of white pixels in the image. 16

17 Actual pothole detection is more challenging: it requires the image to be transformed to detect color differences in the grass. To test that the algorithm can detect the potholes from the images, the following tests should be performed: 1. Bypass the camera by sending images to the image analysis algorithm and try and detect the potholes. 2. The images used to test the algorithm should consist of a complete set of images: images from each one of the above six categories. 3. Use images that are distorted, that have noise, and that are blurred to ensure that all environmental issues are taken into account. This sort of test would be unit testing where the procedure that detects lanes from images is tested to ensure that it is working appropriately. In addition to its appropriateness, the procedure should also be tested for performance. We need to ensure that the procedure can process the images and detect lanes in less than ½ second to allow time to react. Image processing detecting obstacles From the rangefinder s orientation and specifications, the image obtained from the rangefinder would be a 180 degree grid. The following types of images would be obtained from the rangefinder: 1. Nothing in the range of the rangefinder 2. Obstacles approximately in the maximum range 3. Obstacles too close to the rangefinder, within its minimum range 4. Obstacles on the edges, at 0degrees and at 180 degrees 5. Obstacles in detectable range and any combination of the above The obstacle detection should be trivial once the image from rangefinder is obtained: 1. Bypass the rangefinder by sending images to the image analysis algorithm and try and detect the lanes 2. The images used to test the algorithm should consist of a complete set of images: images from each one of the above five categories. This sort of test would be unit testing where the procedure that detects lanes from images is tested to ensure that it is working appropriately. In addition to its appropriateness, the procedure should also be tested for performance. We need to ensure that the procedure can process the images and detect lanes in less than ½ second to allow time to react. GPS The GPS unit itself will be tested using the development software supplied with the product and our own test platform. The development software will be used to ensure proper functionality and to explore features of the unit. The test platform will be used to 17

18 determine the best way to communicate with the device and to show the actual strings being returned from the unit. The accuracy of the heading information will also be tested against the compass to determine if the compass must be used at all. The software the robot will run to communicate with the GPS will be tested using a test platform which will supply fake data from the GPS to ensure that it is working properly. Once this is done, the real GPS unit will be connected and the system tested as a whole. Compass The compass we are using is menu-based with its own set of commands. Each of these commands will be tested to verify that we are using the compass as efficiently and effectively as possible. Extensive hardware testing will also be performed for the alignment (both pan and tilt ) and to make sure that it is located far enough away from any sources of magnetic interference, i.e. motors, not to cause any problems. Motor Controls & Encoders A motor controller with on-board PID functionality has been selected, so the software on the board will perform the direct control of the motors. Once the loops are designed, they can be simulated using Matlab and Simulink. These tools will show us the actual performance of the loops, and the parameters can then be adjusted to achieve the desired operation. Closed loop control requires properly functioning encoders. To test the encoders, the quadrature outputs will be connected to test equipment and the waveform the two channels generate will be viewed. Steering Algorithm The steering algorithm must be tested extensively to make certain our calculations were performed correctly. This is a very important part of the software (the robot would not move without it) and must work correctly. The algorithm can be tested and refined using Matlab scripts before it is put into executable code. Once the motor control loops have been finalized and stored in the controller, a mockup of the robot will be constructed using the actual motors and controllers. The mock robot will be of the same width as the robot to guarantee accurate simulation of the turning radius. The algorithm can then be run on real components and adjusted thereafter. 18

19 Emergency Stop Odyssey The circuit has been tested on a breadboard in the lab already. All pins were verified for their correct net connectivity by using a multi-meter. Once the transmitter button has been pressed the receiver correctly output the valid data and activated the relay. Software The application is built upon modules that interact together to form the working robot. Each module will be divided into as many individual functions that can be tested and then unit tests will be run upon them. A unit test inputs some typical values to the function and then checks the results against what they are know to be. This will ensure that at no time will the code contain errors. If someone changes something that does create an error, you will know by the unit test failing. The measure of success for the software 19