1. 13 : Omni-Directional Robot Design 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 ModelGPIO PINSLinux SupportQuality of Documentation Price Diamond MM-16-AT16YesVery Good$430 WinSystems PCM- MIO-G 48YesAverage$350 ADL 104-AIO12E16NoPoor$415 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

38. Cost Estimate HardwareLabor I/O Board$350.00Labor rate$20/hr Compact Flash Card$20.00Average Hours/Wk60 Battery Protection (6)$294.0Project Timeline30 Weeks IMU$125.00Labor Total$36,000 Hardware Total$789.00 Project total:$36,789

39. Spring Schedule

40. Fall Schedule

41. Questions?