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)https://edge.rit.edu/content/P07200/public/Home

Project Iterations

• Started 2006-1• RP 10 and RP 100 platform projects were

started in 2006-2007• Motor modules for RP 10 and RP 100 were

started in subsequent quarters in 2006-2007• 1st Generation RP 1 motor modules started

2007-2• 2nd Generation platform for RP 10 started

2007-1

Personnel

Advisor: Dr. Wayne WalterPrimary Customer: Dr. Ed HenselResources/Funding: RIT, Gleason Foundation,

Dresser-Rand CorporationEnd 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 2006-1• Battery powered (DC)• Size Constraints (RP 100 - 1m3, RP 10 - 1ft3)

RP Platform ProgressionLighter bodyFewer componentsSimpler controls

Small payload areaIssues with stability/handlingContainment of sensitive components

Fully enclosed structureMounting area for payload4 wheels-more stable control/operation

More complex controlsInefficient use of spaceHeavy/bulky

Fully enclosedModular wheel attachments

Low ground clearanceComponent layout may lead to issuesHeavy/bulkyInefficient use of space

RP 100 3 wheel RP 100 4 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

2006-07: 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 ModulesSafe, 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?