Objectives

1. Objectives • Customers in the Computer Science department identified a number of critical features for a research and teaching robot: • The robot must have an equivalent level of maneuverability as an adult human (2 degrees of linear freedom, 1 degree of angular freedom, speed of 1.5 m/s) without incurring undue mechanical complexity. • The robot must be capable of carrying a meaningful payload (~10 kg) and supporting it with the necessary power, data connections, and processing power. • The robot must provide an accessible software platform that is both accessible and powerful, posing only limited obstacles to use for novice student users without limiting the capabilities available to more advanced users. • The robot must be as inexpensive and flexible as possible, using off-the-shelf components whenever possible to limit costs and ease fabrication. In addition, it must be easy to modify without the need of special tools. Senior Project – Computer Engineering - 2012Advanced Educational RobotCalder Phillips-Grafflin and Erik Skorina (ME)Advisors – Prof. John Spinelli and David Hodgson (ME) Performance Mechanical Design • The robot largely meets or exceeds the project objectives: • Software design is simple and lightweight while maintaining complete user-level abstraction of the mechanical and electrical characteristics of the robot. • ROS driver provides a simple interface to all robot actuators and sensors following standard ROS conventions and accepted practices. • Robot achieves maneuverability goals with minimal mechanical complexity • (complexity is handled in software, not hardware). • Vehicle design is mechanically simple, straightforward to assemble, and cost-effective (less than $3500) in comparison to similar robotics platforms (such as the Pioneer 3). • The mechanical design of the robot achieves maximum maneuverability with minimal mechanical complexity through the use of mecanum wheels that provide holonomic drive without the need for steering axles. • All parts can be easily fabricated with the tools available in a college machine shop. • Complete assembly of the robot can be completed in less than a day. andymark.com System Design Problems • The control system of the robot is designed to maintain complete abstraction of the inherent performance complexities of the mecanum wheel platform. It achieves this through a 3-tier system: • The individual motors are controlled by serial-connected motor controllers that provide braking, over-current monitoring, and fault detection. • The motor controllers are commanded by an ARM Cortex-M3 microcontroller that converts float speed commands to byte control commands, automatic stopping (1 second timeout), and speed calculation via Hall-effect encoders. • The microcontroller is commanded over a USB serial link by an ROS driver running on the onboard computer (a 64-bit Linux PC). • During the construction of our robot, we encountered a number of problems due to the unexpected operating characteristics of the mecanum wheels and the complexity of the control system: • Wheel slippage is the primary cause of performance problems • (not driving in a straight line, inability to maintain a constant-radius curve) • Wheel slippage is almost always caused by irregularities and differences in the floor • (the robot behaves very differently on concrete than it does on carpet) • Consumer-grade accelerometers and gyroscopes are not accurate enough to allow active correction of vehicle motion (<10°/s course deviation at 1.5 m/s) • Feedback from wheel encoders is enough to identify wheel slip but not enough to correct for it Future Work Software Design • Further improvements on the robot itself are almost entirely focused on the drive system and vehicle sensors: • Design and implement a suspension system • (this should address the main causes of wheel slippage) • Implement an inertial measurement system for self-contained indoor navigation • Implement a closed-loop motion control system • The ROS driver provides three basic software configurations for users: • A core driver that provides sensor interfacing, drive control, and battery monitoring. The driver responds to the standard ROS “cmd_vel” velocity command messages. • (Run with “./DriverCore.sh”) • A standard teleoperation driver that provides all features of the core driver combined with user control via a USB game controller. • (Run with “./Teleop.sh”) • A stripped-down teleoperation driver that provides the minimum functionality needed to control the vehicle in the event of software failure. • (Run with “./Rescue.sh”) Acknowledgements John Spinelli David Hodgson John Rieffel Nick Webb Stan Gorski Rhonda Becker Lisa Bremigen Paul Tompkins