1 / 41

13 : Omni-Directional Robot Design Review

This review discusses the incomplete design of a robot, outlining the missing features and necessary improvements for implementation. It also addresses the need for an analog I/O board, a working IMU, battery protection and monitoring, and an updated operating system. The review emphasizes the importance of documentation and provides recommendations for mitigating risks and improving the current system setup.

kdanforth
Download Presentation

13 : Omni-Directional Robot Design Review

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. 13 : Omni-Directional RobotDesign Review Ben Wolf Brent Cornelius Ed Cramer John Grabner James Grabner Advisor & Client: Dr. Nicola Elia

  2. Problem Statement • The robot designed in 2010 is incomplete • Semester One: • implement the missing features • Semester Two: • Continuation of implementation • Document and test the robot for future team use • Secondary options: • Create multiple robots • Design robots

  3. Current design needs the following: • Analog I/O board • A working IMU • Battery protection and Monitoring • Other features to be worked on • operating system • Documentation • Chassis reorganization

  4. Conceptual Diagram

  5. Functional Requirements • I/O board: • Needs to have at least 4 inputs • 12 bit resolution at 1kHz • IMU: • Asses purchased Pololu CHR-6d • Find alternatives if necessary • IMU must be mounted on robot and functioning • Operating System: • Must boot in 30 seconds or less • Must be tolerant of unexpected power loss • Must be compatible with existing hardware

  6. Functional Requirements • Chassis: • Must have outer shell for use with visualization system • Undercarriage wiring must be organized • Use PCBs where possible to simplify manufacture and assembly of robot • Batteryprotection: • Must have automatic disconnect to prevent battery module damage • Battery voltages must be available to OS/AI

  7. Non-Functional Requirements • Maintain function of “legacy” system • Provide documentation for all systems • Characterize robot performance

  8. Risks / Mitigations Risks • Matt Griffith, project maintainer, has moved away • Unclear project definition • Very little documentation • Two robot platforms to support • Preferred robot for future development is non-functional Mitigations • Ask Matt as many questions as possible while he was around • Contact previous team members for additional information • Avoid new features, fix the existing system first • Good documentation practices

  9. Documentation • Documentation for all systems must be created or found • Currently, documentation is unorganized and multiple copies litter computer systems • Should have physical sets of documents • Filing system • Filing cabinet • 3-ring binder with dividers

  10. Documentation • Documentation should include the following • User instructions for robots, visualization system and main server. • Should include FAQ/troubleshooting section • Physical, electrical and software assembly directions for the robot • Datasheet, schematic, and PCB libraries • Correspondences with companies • E-mail logs, invoices, and contact info • Development notes, test procedures and results

  11. Documentation • Must update documentation on current system setup • Currently there is no specific document that says what current setup is. • Go through systems end to end • Set up control server • Calibrate visualization system • Set up ARM development tool chain

  12. I/O Board Research • Re-evaluate the TSADC-16 purchased in 2010 • Manufacturer only supports the board on their hardware • Only operates on 100MHz bus • Development of our own driver would take too long • Alternatives • Purchase new PC/104 board • Use Mesa 4i68 to interface with ADCs • Use RS-232 or parallel port I/O setup

  13. I/O Research • Decided to go with a new PC/104 board based on price and also development time • Considered the following models

  14. I/O Board • After looking over possible choices we went with the WinSystems PCM-MIO-G • Less expensive than other options • We were able to test some of the software and driver before purchase • Has more GPIO pins than other boards • Still has problems with stack configuration

  15. I/O Initial Testing • Driver installed on the robot • Sample programs tested successfully • Accurate to .001 V • Sample rate measurements • A/D conversion process 13-15uS • Transfer data to main memory 75-78uS

  16. I/O Integration • Sample rate is high, reading data is slow • Driver wastes CPU time when used without interrupts • Try to minimize “wait” time and context switches • Group frequently sample channels • Motor driver should be modified to use the interface directly

  17. Operating System Research • Original OS (Ubuntu 10.10) is not appropriate • Existing embedded systems • Familiar Linux (Korebot OS) • Emdebian Linux • RTLinux • Linux from Scratch

  18. Operating System Research • Robot isn't an "embedded" system • Hardware behaves like a desktop PC • Shifted focus towards light weight desktop OS • Some favor towards ease of setup • MicroCore Linux • Emdebian Linux

  19. Operating System Design • Built a kernel for our hardware • Merged the kernel with a Debian installer • The “Development OS” • Installed on a 2.5” hard disk • Used to test TSADC-16 and PCM-MIO-G • Easy to change and modify

  20. Operating System Design • The “Embedded OS” • Delete all unnecessary files • Compress file system into a ramdisk • Install image on compact flash card • Testing • First run with 220MB version during Veisha • OS must be as small as possible to conserve memory

  21. Operating System Testing • Test the effects of various kernel parameters • System timer • Process scheduler • Preemptive thread management • Compiler optimizations • Make sure the OS can handle “hard” shutdowns • OS must boot in 30 seconds or less

  22. Battery Protection and Monitoring(BPAM) • Current system does not have battery protection • Original plan was to have a system that communicated cell voltages to Eris and warn users when voltage was too low • Decided that active battery protection was needed

  23. BPAM Requirements • Functional Requirements -Cell voltages will be reported to Eris with serial communication -BPAM will cut power to Eris if any cell drops to around 3 Volts -BPAM will be able to work with 2 cell and 3 cell battery packs

  24. BPAM Requirements (cont.) • Non-Functional Requirements -BPAM must have low power consumption. If battery packs are shut off at 10% capacity, the battery pack should last for at least 3 months before cells are ruined

  25. Battery Protection Design

  26. BPAM Research • There are many commercially available battery protection circuits -Not all meet are requirements -Most are designed to protect a fix number of cells -Multi cell devices only had overvoltage protection • Communication will be done with a microcontroller

  27. BPAM Solutions #1 Purchase separate 2 cell and 3 cell protection • Advantages -Tested product -Inexpensive $1~$3 • Disadvantages -Need two different circuits -Not very flexible • Example is the S-8242BBA-I8T1x for 2 cell protection

  28. Selected BPAM –Solution#2 • Microcontroller that is used for monitoring and communication could be used for active battery protection • ADCs available to read cell voltages • Output pins could be used to control shutoff MOSFET • Jumper used to tell microcontroller how many cells the battery pack contains

  29. Solution #2 (cont.) • Advantages -Sensing and communication tasks are combined into one part -Completely adjustable thresholds and fault conditions gives the system more flexibility • Disadvantages -More components -Untested design

  30. BPAM Schematic

  31. IMU Research • IMU • CHR-6d Digital Inertial Measurement Unit previous purchased by last team was destroyed. • Purchased another one to see if it is applicable • Requires testing of output to see if the sampling rate is fast enough to record data that Eris well used for positioning. • Another option is to purchase gyros and accelerometers and build our own system tailored to our own needs.

  32. IMU / Positioning • An IMU is needed to improve accuracy of motion • Additional high speed gyro may be required • Use localization system to estimate robot performance

  33. IMU Testing • Testing lateral accerleration • Use visualization system to record movement of robot • Analyze visual data frame by frame to determine acceleration of robot • Compare to data from IMU • Test Rotational Speed • Use visualization system determine how far and fast robot rotated and compare to data from IMU

  34. Chassis Optimization • Designing a new lid/cover for Eris with camera recognizable design • Addition of power switches • Reorganization of Chassis • Improve wire routing • Use PCBs instead of wires when possible • New wheel design (related project) • Provide test suites and feedback

  35. Adapter Board • Possible solution to hardware stack problem on robot • Will pass through PCI and PC/104 PIN headers • Available space on board to help optimize lower chassis

  36. Adapter Board

  37. Adapter Board

  38. Spring Schedule

  39. Fall Schedule

  40. Questions?

More Related