1 / 31

13 : Omni-Directional Robot Design Review

13 : Omni-Directional Robot Design Review. Ben Wolf Brent Cornelius Ed Cramer John Grabner James Grabner Advisor & Client: Dr. Nicola Elia. Introduction. What is an Omni-Directional Robot

glynn
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. Introduction • What is an Omni-Directional Robot • A robot that is able to move any direction in the X/Y plane without changing it’s orientation. As well as being able to move in a single direction while freely rotating 360⁰ • In 2010, a team designed a new robot platform but did not complete it, our goal is complete the assembly of the robot and implement any missing features

  3. Problem statement: • Current design needs the following: • Analog I/O board • A working IMU • Battery protection and monitoring • Other features to be worked on • Operating system • Assembly documentation • Chassis reorganization

  4. Functional Requirements • I/O board: • Needs to have at least 4 inputs • 12 bit resolution at 1kHz • IMU: • Assess 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

  5. 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 • Battery protection: • Must have automatic disconnect to prevent battery module damage • Battery voltages must be available to OS/AI

  6. Non-Functional Requirements • Maintain function of “legacy” system • Provide documentation for robot assembly • Characterize robot performance

  7. Design (8 slides)

  8. Operating System • Korebot series robots used Familiar Linux • The previous team used Ubuntu 10.10 to get started quickly • A more efficient replacement was needed • Reduce boot time • Stored on compact flash memory • Read-only file system to prevent corruption and unintentional modifications

  9. Operating System • Researched a variety of embedded and portable systems • MicroCore Linux, Linux From Scratch • Emdebian Linux • We needed a quick start as well • Custom kernel and Debian 6 installed on the robot • Gather information about the hardware • Start testing other components like the I/O board

  10. Analog I/O Board • PCI boards were too expensive • Inadequate resources to develop our own • Chose WinSystems PCM-MIO-G • Linux supported out of the box • Less expensive than other models • Software available for testing before purchase • Issues with Stack Configuration

  11. Battery Protection and Monitoring(BPAM) • BPAM requirements • Must shut off pack when one or more cells reached 3.2-3 volts • Must be able to report cell voltages over a serial line • Must be able to work with 2 or 3 cell batteries • We decided to not use commercially available BPAM • Had overvoltage protection, but no under-voltage protection • Only protected a fixed number of cells • Most did not meet all the requirements • Decided to design and implement our own microcontroller based battery protection system that would shut off power to a robot when cells reached 3.2 volts, be able to be used with 2 or 3 cell battery packs, and would be able to communicate cell voltages over a serial line.

  12. BPAM Schematic

  13. BPAM Design • PIC16F688 microcontroller • Has 8 channel 10 bit ADC, we need three to read cell voltage • Output pins can be used to turn on/off power MOSFET and sense amplifier • Has USART for serial communication • TL084 JFET Quad Op Amp • Input Impedance > 1Tohm • Can drive resistor dividers on sense lines • MC78LC00 Regulator • Provides the microcontroller with 3V for power • Low quiescent current

  14. Chassis Organization • System before our additions • Two Layer System • Needs Switches, Indicator Lights, and Top Shell • Lower chassis wiring needs to be redone

  15. Chassis Organization • When adding I/O board Stack configuration will need to be altered • Computer is PC-104/+ Form factor • Mesa board is PCI-104 • I/O is PC-104 • Solution: • Adapter Board

  16. Adapter board • Pass through PCI Bus • Offset ISA Bus

  17. Adapter Board • Secondary function– Chassis Reorganization The empty board space was not wasted: • Motor drivers • Voltage regulators • Motor connectors • Motor controller interface • New motor current sense circuits • Switches

  18. ImplementationTestingEvaluation

  19. Operating System • There are several versions of the OS today: • Development OS (eris-00.04) • Veisha OS (eris-00.03) • Debian Live (generic) • Fastest boot time is 38 seconds • 18 seconds consumed by POST • CF slot much faster than USB with GRUB • More robust file systems are necessary • Compressed and/or ramdisk is ideal • Move to journaling file system

  20. I/O Board: Accuracy and Sample Rate • A simple how-to program was written for future users • Maximum observed sample rate was 71,428 Hz

  21. I/O Board: Sensor Manager

  22. BPAM • gEDA used to create schematics and PCB layout • Considerations for making PCB by ourselves • Microcontroller Programming • MPLAB IDE v8.76 with Hi Tech C Compiler • PICkit 2 • Main Functions of the Program

  23. BPAM Pictures

  24. BPAM Testing • Microcontroller Functionality • Linearity and Accuracy • Static Load Test • Complex Load Test • Testing with a Robot

  25. Chassis Reorganization • Power Switches • Bumper Guards • Adapter Board

  26. Adapter board • gEDA was once again used to create schematics and PCB layout • Schematic to PCB tool • Board was ordered through Advanced Circuits • Assembly is nearly complete, connectors arriving later today

  27. Adapter Board Pictures

  28. Conclusion • BPAM • Primary Goal Accomplished (batteries are protected) • Do not foresee any major obstacles to complete remaining requirements • Operating System • Boots quickly and is in a usable state

  29. Conclusion • I/O Board • Integrated on robot and performs adequately • Chassis Successfully reorganized • Requires a permanent lid assembly

  30. Lessons Learned • Just because it seems simple doesn’t mean that it will be done quickly (BPAM) • The best robot is useless without proper documentation • Don’t let a project intimidate you, start working and ask for help if you get stuck

  31. Questions

More Related