1 / 48

RoboSub System-Level Design

Team #5 - RoboSub. RoboSub System-Level Design . Overview. Jonathan Wong Chong. Mechanical System Electrical and Power System Software System Vision SLAM Task Manager Path Planning Decision Making Motion Control IMU/ Stabilization Budget , Schedule, Risks Questions.

trella
Télécharger la présentation

RoboSub System-Level Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Team #5 - RoboSub RoboSub System-Level Design

  2. Overview Jonathan Wong Chong • Mechanical System • Electrical and Power System • Software System • Vision • SLAM • Task Manager • Path Planning • Decision Making • Motion Control • IMU/ Stabilization • Budget , Schedule, Risks • Questions

  3. Project Management Jonathan Wong Chong • Matthew Neafie • Vision • Object Recognition/ Color Recognition • Path Planning • Mono- simultaneous localization and mapping (SLAM) • Daniel Cifredo • IMU • Data Acquisition for Hydrophones and IMU • Data Storage

  4. Project Management Jonathan Wong Chong • Julius Cobb • Decision Controlling • Motion Controlling • Stabilization • Jonathan Wong Chong • Electrical and Power • Decision Controller/ PID • Torpedo Fire Controller/ Claw

  5. Jonathan Wong Chong -- Team #5 - RoboSub Mechanical System

  6. Mechanical System Jonathan Wong Chong • Reuse the Design from Last Year • Fixed Camera Cases

  7. Jonathan Wong Chong -- Team #5 - RoboSub Power and Electrical

  8. Power Components Jonathan Wong Chong • 14.8V Polymer Li-Ion Batteries • Only powering thrusters • 19v 4Ah Li-Ion External Laptop Battery • Powers main CPU unit • Lasts roughly 2-3 hours • Essentially powers all USB devices as well • 12v Li-Ion 18650 Box Battery • Regulated to power actuation system

  9. Thruster System Jonathan Wong Chong

  10. Final Product Jonathan Wong Chong

  11. Matthew Neafie -- Team #5 - RoboSub Software System Design

  12. Software Overview Matthew Neafie

  13. Vision General Overview Matthew Neafie

  14. Vision Matthew Neafie The vision system is the software module that satisfies all of the necessary image processing needs of the AUV. Modules from this system will be called when needed by the top-level control software. Written using OpenCV and Castle’s SLAM, this module will implement object recognition, a frequently occurring problem in the contest. Color Recognition and Tracking OpenCV Library • #include <cv.h> • #include <highgui.h> Calls SURF class Psuedo steps //capture image from camera //create windows for debugging purposes //cycle through each frame • //smooth the original image using Gaussian kernel • //Convert from BGR to HSV • //Create a binary image with the set color threshold • //smooth and clean image • The AUV will now have a color image which can be used for other purposes.

  15. Vision Matthew Neafie SURF, Speeded Up Robust Features OpenCV Library • #include <features2d.hpp> • #include <highgui.hpp> • #include <imgproc_c.h> Calls SLAM • Psuedo steps //capture image from camera //create windows for debugging purposes //cycle through each frame • //Convert the RGB image obtained from camera into Grayscale • //Define sequence for storing surf keypoints and descriptors • //Extract SURF points by initializing parameters • //draw the keypoints on the captured frame • //compare keypoints from captured image to stored image • The AUV will now have compared the current visual image to that of the competition obstacles.

  16. SLAM Overview Matthew Neafie

  17. SLAM Matthew Neafie • Simultaneous Localization and Mapping • Robert Castle’s PTAMM (Parallel Tracking and Multiple Mapping) software • Libraries needed and why: • 1. TooN - a header library for linear algebra. • 2. libCVD - a library for image handling, video capture and computer vision. • 3. Gvars3 - a runtime configuration/scripting library, this is a subproject of libCVD. • 4. lib3ds - a library for handling 3DS model files. • Stores map into file system for access by other subsystems (Path planning and decision making). • Calls Task manager, Path Planning, and Decision-maker.

  18. SLAM Matthew Neafie • Simultaneous Localization and Mapping • Robert Castle’s PTAMM (Parallel Tracking and Multiple Mapping) software • PTAMM RUNNING 3D Mapping Feature Images from Robert Castle

  19. Task Manager Overview Matthew Neafie

  20. Task Manager Matthew Neafie Stack of Tasks • Recognized by Vision and Mapped • Unrecognized TASKS Gate Parking Torpedo

  21. Task Manager Matthew Neafie Stack of Tasks • Recognized by Vision and Mapped • Unrecognized TASKS Removed Gate Parking Torpedo

  22. Task Manager Matthew Neafie public class StateStack Map<String, IState> mStates = new Map<String, IState>(); List<IState> mStack = List<IState>(); public void Update(float elapsedTime) public void Render() public void Push(String name) public IState Pop()

  23. Path Planning Overview Matthew Neafie

  24. Path Planning Matthew Neafie • The Path Planning algorithm can be viewed as a greedy algorithm because it always chooses the closest vertex in V - S to add to S. • //insert all vertices into priority queue • //Extract-min (first extraction is simply s) • //for each neighbor • //RELAX(u,v,w) • //update label of neighbor, • //decrease-key v.d in priority queue • Fibonacci Heap – O(|V|log|V| + E) time • Uses map from SLAM, Goal from Task Manager, calls decision-maker

  25. DMCS Overview Matthew Neafie

  26. Decision-making Control System Matthew Neafie • What to do and how to do it • Mission Planning • Path Planning • Deployment • Diagnose & Correct • Goal Directed • Obstacle Avoidance • Pose Holding • Depth Holding Weighted Total Output

  27. Julius Cobb -- Team #5 - RoboSub Decision Making Control System - Continued

  28. Decision Making Control System – A PID Julius Cobb • The DMCS module acts as an abstract Proportional Integral Derivative feedback controller • Two systems: Rational Behavior and Perceptual Behavior • One system uses sensory data from other threads to generalize the current behavior of the AUV • Second system uses the above as input to adjust process control parameters • sendDataToMotionControl()

  29. Motion Control - Software Julius Cobb • Interpret commands sent from the DMCS • distributeThrust() – process input to the module and generate low-level commands to thrusters

  30. Motion Control - Hardware Julius Cobb • Arduino Mega 2560 • Single microcontroller that will be used for thruster control • Currently tied to four separate motor controllers as well as the Inertial Measurement Unit • USB port is a power source from the MPU as well as the main UART serial communication port • Baud Rate: 19200 bit/s • Parity: None • Hardware Control Flow: None

  31. Motion Control – Hardware Julius Cobb • L298 H-Bridge Motor Controller • Two different brands, very similar specs • Input voltage from 6 to at least 25V • 4A total drive current (2 x 2A) • Motor direction LEDs • Handles varied output by writing PWM signal to the ENABLE pin

  32. Motion Control - Hardware Julius Cobb • Seabotix BTD-150 Thrusters • Max operating voltage of 19.1V • Max continuous current draw of 4.25A • Utilizing the two graphs, following conclusions can be drawn: • If motor controller running in normal mode, thrusters can achieve max of 1.05 lbs of thrust each (input voltage is 9.58V) • If motor controller running in bridged mode, thrusters can achieve max thrust of 2.01 lbs (input voltage is 14.8V)

  33. Motion Control – Software to Hardware Julius Cobb • Arduino Mega waits for serial data from MPU containing new thrust level • Once the data is available, read the new thrust percentage and write the respective PWM signal to motor controller

  34. Stabilization - Software Julius Cobb • Consists of two generic PID controllers implemented in C++ • One system for minimizing error in pitch • One system for minimizing error roll • For both systems, controller would: • Read state from IMU • Subtract measurement from desired reference to generate an error value • Adjust process inputs (thruster levels) to manage error • (P) proportional term “handles the present” • (I) integral term “recovers from the past” • (D) derivative term “anticipates the future”

  35. Stabilization - Hardware Julius Cobb • IMU – Sparkfun Razor with 9 degrees of freedom • Interfaces directly with the Arduino Mega • Receives 3.3V input voltage from the Arduino’s 3.3V output pin • Establish UART serial communication link by connecting TX and RX pins to TX1 and RX1 on Arduino • Baud Rate MUST BE set at 56200 bit/s on both devices for optimal serial data transmission • Parity: None • Hardware Control Flow: None

  36. Stabilization – Software to Hardware Julius Cobb • Arduino will read data from IMU at set intervals • Upon receiving data from IMU, Arduino then sends the data to MPU to be processed in Stabilization thread • IMU outputs all measurements (xyz gyroscope, xyz accelerometer and xyz magnetometer) so the serial stream will have to be parsed

  37. Daniel Cifredo -- Team #5 - RoboSub Schedule, Budget, Risks

  38. Schedule – Gantt Graph Daniel Cifredo

  39. Schedule – Gantt Graph Daniel Cifredo

  40. Schedule – Gantt Graph Daniel Cifredo

  41. Schedule – Table

  42. Budget Exercise Daniel Cifredo

  43. Daniel Cifredo Budget Exercise

  44. Daniel Cifredo Risk Assessment - Technical

  45. Daniel Cifredo Risk Assessment - Technical

  46. Daniel Cifredo Risk Assessment - Technical

  47. Conclusion Jonathan Wong Chong • Continue Work on Thrusters, IMU, Vision • On Schedule • 1st Testing Demonstration to be completed by Spring • Thank You!

  48. Questions?

More Related