ece capstone fall 2007 team ride. realistic interactive driving experience group members: brennan...

28
ECE Capstone Fall 2007 Team RIDE

Upload: betty-oneal

Post on 24-Dec-2015

216 views

Category:

Documents


2 download

TRANSCRIPT

ECE Capstone Fall 2007

Team RIDE

Team RIDERealistic Interactive Driving Experience

Group Members:

Brennan Dayberry

Adam Marrapode

James McGlynn

Ben Sufit

Chris Taylor

3D Visual Model

The Design“Realistic Interactive Driving Experience”

- Cockpit- Linear/hydraulic actuated motion base- Multi-directional Force Feedback

- Driving Simulator- rFactor- Provides recorded real life physical forces

acting on car into “realistic” simulation forces (signals sent to driving simulation hardware is known as force feedback)

Goals- Realistic real-time cockpit movement based on

simulated forces experienced during game play- Motion-based system

- 3 degrees of freedom via 3 linear/hydraulic actuators and a center of mass ball pivot joint

- Control system to implement force feedback signal into motion base

- Extract and translate game telemetry data into physical movement of cockpit

- Immerse the user in a wide range of realistic driving experiences through simulation- Driving etiquettes

- Formula 1, Formula 2, Indy Car, Stock car, Rally, GT1/ GT2/GT3 Sports Car Class, Le Mans

- HD track simulations- Simulated driving on tracks such as, Nuremburg Ring/ European

Grand Prix in Germany, Canadian Grand Prix in Montreal, USA Grand Prix in Indiana, and 100’s of others

Features

- 3 degrees of freedom to enhance pitch, roll and yaw of driving experience

- Full scale cockpit with real racing components- Logitech G25 steering wheel, pedals (clutch, brake and

gas), and 6-speed shifter assembly- Sparco racing seat- 5 point harness seatbelt system for safety

- Selective force feedback strength (driver preference, e.g. Miss Daisy or James Bond)

Outline of Approach

• Modularize components to improve reliability and ensure complete and accurate operation

• Design, build, and test modules independently and in parallel

• Provide contingency and risk-aversion by ensuring individual modules function as desired so that we have something that works

Block Diagram

Sub-systems

• Controller and Logic

• Telemetry PC Driver

• Communications

• Actuators/Hydraulics

• Analog/Digital signal processing

• Power

Spartan 3 FPGA Controller

• Converts commands from Telemetry Plugin to actuator control

• Use MicroBlaze soft-core to run actuator control feedback loop

• Initially use development board, then custom PCB

Telemetry PC Plugin• Rfactor racing plug-in exposes internal

simulation data to 3rd-party developers– Velocity, Acceleration, Motion Matrix, Car

Status, Terrain*

• Extract game data, process using software filter (convert to controller commands), send to controller– RS-232 interface, original command protocol

• Two different original modules involved in design– Testing module and actual implementation

module

Testing Module• Written in C

• Sends commands to controller board via serial port (RS-232)

• Uses set testing routines (standard functionality) and real-time user control (boundary conditions)– Tests all “action profiles”

• Logs all sent data in a standard file format– Separate analysis model for error isolation

• 1-way communication with controller board

Plugin Module• Extract all data from game using plugin

class structures

• Send game data to filter module

• Filter module sifts data, reduces and converts to controller format, sends data to controller– Implements decision scheme for “relevancy”

• Relevancy = major changes in motion, “action data”

– Simple sampling scheme

• Module sends over RS-232 at set frequency

Game-Interaction DetailsGame Telemetry built into struct of plugin:struct TelemInfo

{...

World position in meters (possible terrain data)

Velocity of local vehicle

Acceleration of local vehicle

Rotational accleration

Pitch, Yaw, Roll

Engine RPM

...

}

Telemetry information selected for update in game plugin, can be sent directly to filtering module

Communications Protocol• Simple vs. “Profile” movement

– Simple movements include one direction• Up, down, right, left

– Profile movements are superposition of simple movements along with a force

• Example: Profile 1 = (Up + Left) * Force• Force value based on conditions (acceleration, angle)

– Simple movements converted to profile movements on PC. Only profile movements sent to controller

• Controller must decide if profile can be used– Receive movement -> check actuator status ->

movement decision -> send/reject movement

Communications Protocol, cont.

• Profile actions continuously sent at regular intervals

• “Special” action profiles for no movement, different crashes, bumps, stall, startup

• Actual action rate determined through testing– Base rate prediction: 3 Actions/Second– Subject to change based on actual actuator

speed and recovery

Actuator/Hydraulics Ideal Specs.

• 6 to 9 inch stroke

• At least 8 inches per second stroke speed

• Weight support greater than100 lbs. each

• Pillar at center of mass with ball joint to support weight

• Each hinge joint on actuators must have ball joint for freedom of motion to avoid buckling

Power

• PC and LCD display powered by 110 VAC

• Most hardware like FPGA and logic components powered by low voltage DC

• Actuators powered by low voltage variable DC, or single-phase AC

• Power needs will be relatively simple and easy to design

Division of Labor  Brennan Chris James Adam Ben

Mechanical Design X X X   X 

Mechanical Assembly X X X X X

Actuator Control X X X X X

Actuator Feedback X X X X X

Programming PC Driver X X X  

Programming Controller X X   X X

FPGA/CPLD and Logic X X   X X

Circuits/Filters X   X X X

Communications X X X X  

Development Board   X X X X

PCB Layout   X   X X

Power X   X   X

User Interface X X X X X

Budget     X X  

Key TasksMechanical assembly,

actuatorsTwo weeks

Signal processing, FPGA, PC code,

power requirements

CDR

Actuator feedback, communications, user

interface

Milestone 1

PCB layout, movement algorithms

Milestone 2

Complete dynamic interaction

Expo

Risks and contingency plan

Timing

• Risk: Will the controller and actuators be able to keep up with the game?

• Contingency plan: Move most of the intensive code to PC Telemetry Plugin to maximize speed. Use actuators with relatively high stroke speed

Time• Risk: Do we have enough time to build

this?

• Contingency plan: Order parts far ahead of time. Know mechanical engineers. Make wise “Build/Buy” decisions. A lot of coffee.

Cost and Use of Actuators

• Risk: None of us have used actuators extensively before, and the cost is potentially high. Also most electric actuators are slow

• Contingency Plan: Try to get donations and use simple actuators. Use levers or similar system to speed up actuators

Failure to achieve control

• Risk: It is possible that feedback loops will be hard to stabilize, or that the number of control signals we are managing will be too overwhelming

• Contingency Plan: Allow for slower movement to slow down loops, only try to have a few very simple profiles for movements

Possible extensions

• Tachometer and gauges exported to cockpit

• Gyroscopic cup-holder

• Make soup

Any Questions?