1 / 28

ECE Capstone Fall 2007

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

celestyn
Télécharger la présentation

ECE Capstone Fall 2007

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ECE Capstone Fall 2007 Team RIDE

  2. Team RIDE Group Members: Brennan Dayberry Adam Marrapode James McGlynn Ben Sufit Chris Taylor Realistic Interactive Driving Experience

  3. 3D Visual Model

  4. 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)

  5. 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

  6. 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)

  7. 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

  8. Block Diagram

  9. Sub-systems • Controller and Logic • Telemetry PC Driver • Communications • Actuators/Hydraulics • Analog/Digital signal processing • Power

  10. 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

  11. 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

  12. 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

  13. 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

  14. 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

  15. 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

  16. 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

  17. 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

  18. 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

  19. Division of Labor

  20. Key Tasks

  21. Risks and contingency plan

  22. 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

  23. 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.

  24. 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

  25. 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

  26. Possible extensions • Tachometer and gauges exported to cockpit • Gyroscopic cup-holder • Make soup

  27. Any Questions?

More Related