OD1 Be able to automatically detect objects to a distance up to 45ft. Standard to battlebot competition. OD2 To be able to automatically detect and highlight three different targets with a 51% accuracy rate. Standard to battlebot competition. OD3 Must be able to automatically determine the distance of three targets up to 50ft. Simulating various targets at different ranges. OD4 Be able to detect moving target with a movement speed range of 1 to 3 m/s. Utilizing a sample robot for target acquisition. Table 2.2: Object Detection Requirements 2.3.3. Power There are two power requirements, seen in Table 2.3, to ensure the robot stays working and can supply enough power to the robot. The table below will identify the requirement number, give a brief description and list the way to verify. Requirement ID Description Verification P1 Power supply must be able to last a minimum of 25 minutes. Using the system for two 10 minute rounds. P2 To be able to operate at 12V and draw a maximum of 3A. Based on total power consumption of the system Table 2.3: Power Requirements 2.3.4. Mobility There are two requirements specifications on what kind of movement this robot will be allotted to have. These requirements are listed in Table 2.4. Requirement ID Description Verification
Eq(4): Rα = Δsl Eq(5): Lα = (Δsr - Rα)/2 = Δsr /2 – Δsl /2 Substituting Eq(4) and Eq(5) into Eq(3) we represent Δs as a function of Δsl and Δsr. Δs = (R+L)α = R α + L= Δsl + Δsr /2 – Δsl /2 = Δsl /2 + Δsr /2 Δs = (Δsl + Δsr) /2 To calculate the change of the angle of the robot’s orientation Δθ, is equal to the circular arc’s center point as seen in Figure 3.22. Δθ = α Figure 3.27: Odometry p2- Example relating circular α to the orientation (Permission Requested from Princeton) Then solve for α by equating α from Eq(1) and Eq(2). Δθ = (Δsr - Δsl ) /2L With Δθ and Δs we are able to calculate the position change in real world coordinates. Using trigonometry to model the Δx and Δy as functions of Δd. Δx = Δd cos(θ + Δθ/2) Δy = Δd sin(θ + Δθ/2) As seen in Figure 3.23 the paths Δd ≈ Δs are slightly different. The measurements will be made fast enough to approximate that Δd ≈ Δs. Δx = Δs cos(θ + Δθ/2) Δy = Δs sin(θ + Δθ/2) Figure 3.28: Odometry p3- Example denoting difference of Δd and Δs (Permission Requested from Princeton) Using the above model, we will be able to approximate our robots location on the field. The coordinates will not be exact because of the assumptions that were made. Also there will be noise from the encoders that will impact the calculations. Other causes of inaccuracy to the model can arise from the wheels slipping, hitting a bump, or driving on carpet. 3.16.3. Wireless Data Transfer
Establishing communication between the Raspberry Pi and the ATMega328p is essential for the entire implementation of the proposed system. Every component in the proposed system will either be connected to the ATMega328p or the Raspberry Pi. In order to transmit data wirelessly, the Raspberry Pi will be used; therefore, data from the ATMega328p will be transferred to the Pi so it can reach the laptop. (ex. Manual Navigation data) Raspberry Pi receiving output from from the Logitech HD Pro Webcam This is essential to allow for the Computer Science team to start on their algorithm for autonomous detection. ATMega328p receiving output from the Lidar Lite 3 Rangefinder Again, this is essential so that the Computer Science team is able to start with their contribution to the project Programming Stepper Motors to rotate Nerf-Blasters, Camera, and Rangefinder This is an important part of the overall development of the proposed system’s design. This step is key to complete as soon as the connection has been established with the camera and rangefinder, since once an object has been detected, the system will aim and fire at that object. Programming the Nerf-Blasters to fire with a button from the laptop This will immensely assist with the Computer Science team’s plan to eventually autonomously aim and fire with the system. This feature is essential for further testing with the proposed system. Programming the DC Motors to rotate appropriately for manual navigation of the robot Manual navigation is a key feature that will be very important to the overall design of the proposed system. However, manual navigation will not be possible until we can obtain the necessary components from the Mechanical Engineering team. Although testing and preliminary models can be designed to practice establishing manual navigation, it is not as pressing as other features that must be implemented first. 8. Prototype Testing This chapter covers all the prototype testing for both hardware and software designs that will be taken place with strategic procedures to ensure all components are connected properly and integrated correctly. Testing will be an essential part of the overall development life cycle of the system. If either a software or a hardware design component does not pass a certain test, it will be tested again in order to figure out the possible problem. If a certain hardware component seems to be malfunctioning, a new component will be ordered in its place. If
[30] ElectronicsTutorials, MOSFET as a switch [31] RobotShop, (2011), Controlling Your Robot [32] CircuitDigest, WiFi Controlled Robot [33] Sending data from Arduino to Raspberry Pi [34] All about agile, (2011) [35] digi, Zigbee Wireless Standard [36] Our every day life, Blue-Tooth vs Wifi Power Consumption Appendix D - Figures and Tables Appendix D contains a list of all the figures and tables used in this document. Table of Figures All figures referenced in the document and their descriptions and request status for permission of use are seen listed below in Tables A-E. 2. Project Description No. Description Source Permission Status 2.1 Example of the playing field Project Supplied - Table A 3. Research
No. Description Source Permission Status 3.1 Outline of the SLAM Process SLAM for Dummies Request Pending 3.2 Intricate SLAM Map showing spikes and edges SLAM for Dummies Request Pending 3.3 C.RAY Benchmark Photonix Granted 3.4 John The Ripper Benchmark Photonix Granted 3.5 Smallpt Benchmark Photonix Granted 3.6 Performance Per Dollar Benchmark Photonix Granted 3.7 An example of a 128x128 pixel image Team Designed - 3.8 Benchmark of different vision libraries O’Reily Requested 3.9 Original low contrast image OpenCV Requested 3.10 Shows Histogram Equalized Output OpenCV Requested 3.11 Front View of Chassis Team Designed Granted 3.12 Bottom View of Chassis Team Designed - 3.13 Front view of chassis Team Designed - 3.14 Side view of chassis Team Designed - 3.15 Front View of Robot Team Designed - 3.16 Bottom View of Robot Team Designed - 3.17 Side View of Robot Team Designed - 3.18 Completely Assembled Robot Team Designed - 3.19 Nerf Rival Zeus MXV-1200 Hasbro Requested 3.20 CS-18 N-Strike Elite Hasbro Requested 3.21 Insides of Rapidstrike CS-18 Team Designed -
3.22 Insides of Rival Zues MXV-1200 Team Designed - 3.23 Rival Zues MXV-1200 Modification Team Designed - Table B 3. Research No. Description Source Permission Status 3.24 Rival Khaos MXVI-400 Hasbro Requested 3.25 Insides of Rival Khaos MXVI-400 - - 3.26 Odometry p1- Example showing the relations of variables Princeton Requested 3.27 Odometry p2- Example relating circular α to the orientation Princeton Requested 3.28 Odometry p3- Example denoting difference of Δd and Δs Princeton Requested 3.29 Logitech HD Pro Webcam C920 Logitech Granted 3.30 LIDAR-Lite 3 Laser Range Finder RobotShop Granted 3.31 Raspberry Pi 3 Model B RobotShop Granted 3.32 ATmega328p oomlout Requested 3.33 10 A 5-25V Dual Channel DC Motor Driver RobotShop Granted 3.34 Futaba S3004 Standard Servo Motor RobotShop Granted Table B-2: Continuation of Table B 5. Hardware Design No. Description Source Permission Status 5.1 Power Flow diagram Team Designed -