ece capstone fall 2007 team ride. realistic interactive driving experience group members: brennan...
TRANSCRIPT
Team RIDERealistic Interactive Driving Experience
Group Members:
Brennan Dayberry
Adam Marrapode
James McGlynn
Ben Sufit
Chris Taylor
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-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
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