Robotic Vehicle Platform: Background Presentation Steven Rois (ME) Chris Wakeley (ME) Kenneth Smith (ME) Andrew Krall (ME)

Mission Statement "The mission of this family of projects, within the Vehicle Systems Technology Track, is to develop a land-based, scalable, modular open architecture, open source, full instrumented robotic/remote controlled vehicular platform for use in a variety of education, research & development, and outreach applications within and beyond the RIT KGCOE. The family of projects should use an engineering design process to develop modules and subsystems that can be integrated by subsequent senior design teams. Project P07200 serves as the foundation or starting point for a series of senior design projects.” RP Family Page (P07200)

Project Iterations Started RP 10 and RP 100 platform projects were started in Motor modules for RP 10 and RP 100 were started in subsequent quarters in st Generation RP 1 motor modules started nd Generation platform for RP 10 started

Personnel Advisor: Dr. Wayne Walter Primary Customer: Dr. Ed Hensel Resources/Funding: RIT, Gleason Foundation, Dresser-Rand Corporation End Users: KGCOE, RIT student body, faculty research, public, hobbyists/enthusiasts

Robotic Platform RP 10 and RP 100 must be able to carry 10kg and 100 kg payloads Must feature scalable and modular motor modules arranged in a variety of configurations RP 10 must have a range of one floor of bldg 9 RP 100 must have a range of the entire bldg Be able to have skid steering and turn steering (2 wheel drive) RP 10 and RP 100 were started in Battery powered (DC) Size Constraints (RP m 3, RP ft 3 )

RP Platform Progression Lighter body Fewer components Simpler controls Small payload area Issues with stability/handling Containment of sensitive components Fully enclosed structure Mounting area for payload 4 wheels-more stable control/operation More complex controls Inefficient use of space Heavy/bulky Fully enclosed Modular wheel attachments Low ground clearance Component layout may lead to issues Heavy/bulky Inefficient use of space RP wheel RP wheel RP 10

Sensors and Vehicle Data Acquisition System Specifications – PC104 Lynx Board » Processing board running Linux to maintain open- architecture – Input Board w/daughter boards » Designed to provide accurate digital signals to be collected by the PC104. – Output » Designed to have 4 channels in the 0-5 V range and 4 channels in the +/-12 V range : Vehicle Data Acquisition P07301 This student team was assigned to develop a fully functional, scalable sensor module subsystem. The project hardware and software was designed to support mechanical, electrical and applications software projects.

Main Issues Overcome by P07301 Team Output Format: The PC104 could be responsible for converting the binary numbers to ASCII, or the PC104 can send the binary information to the host PC to convert later. Precision of 250 Ohm resistors for current loop output. High precision --> High cost No circuitry to accommodate the output range Not enough current (200mA) to support the PC104 and current output. Current A/D converter does not have anti-aliasing filters or programmable gain. No regulated 12V supply Sensors and Vehicle Data Acquisition Figure 2: Final input board with daughter boards

Motor Modules Self-Contained drive/steering module. Torque necessary to move payload (1-100kg). Top speed of 4.5 m/s. Same module can be driven or idle. Steering angle range of 360°. Support 3, 4, or 6 wheel arrangements.

Motor Modules Safe, enclosed drivetrain Electronics isolated from moving parts Strong & versatile frame RP100 & RP10 Gen 1 Shaft alignment friction High cost & weight Poor manufacturability Time consuming disassembly Belt and gear skip under load Modular gearbox Infinite rotation Robust RP1 Gen 1 No belt tensioner Steering rotates driveshaft No smaller than RP10 Size/weight – 1/10 of gen 1 Easy to manufacture Meets all RP1 specifications RP1 Gen 2 Low quantity production cost is high

Motor Controls The Motor Control subsystem contains the inputs used to actuate the motors, but does not contain the motors or driver circuitry itself. The controls subsystem generates the timing and control signals, which are then fed into the Motor Modules subsystem. Build a control system to command interchangeable motor modules Control system must be: – Open-Source, Open-Architecture – Modular – Scalable, Programmable Control system must be controllable by payload or Windows/Linux PC System must be smaller than previous units

Motor Controls RP10 Gen 2 RP1 Gen 1 Microcontroller did not have the capacity to generate all necessary control signals Stepper motor drivers had non- deterministic behavior, required excessive control signals RP1 Gen 2 Overall well executed, effective design of the motor controls. Future recommendations: Merge power supplies Merge microcontrollers Merge DC Drivers One direction communication with the MM Only set up to work with one MM Ability to turn, drive, and stop based on commands issued by the user Open-source, Java readily available Oversized for application, minimal heat loss, high efficiency Easy to troubleshoot with multiple status LEDs Modular and stackable design Easy to connect all inputs,outputs and power cables Future recommendations: Decrease size of PCB Protect against reversed power connections Add current limiting resistors on all IC output pins to prevent damage to chips due to short circuit conditions.

Questions?