280 likes | 428 Views
ECE Capstone Fall 2007. Team RIDE. Team RIDE. Group Members: Brennan Dayberry Adam Marrapode James McGlynn Ben Sufit Chris Taylor. R ealistic I nteractive D riving E xperience. 3D Visual Model. The Design. “Realistic Interactive Driving Experience” - Cockpit
E N D
ECE Capstone Fall 2007 Team RIDE
Team RIDE Group Members: Brennan Dayberry Adam Marrapode James McGlynn Ben Sufit Chris Taylor Realistic Interactive Driving Experience
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
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 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 Game-Interaction Details
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
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