ECE Capstone Fall 2007
Team RIDE
Team RIDE
Realistic 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 softcore 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 Details
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
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
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
User Interface
X
Budget
X
X
X
X
X
X
X
X
X
Key Tasks
Mechanical assembly,
actuators
Two weeks
Signal processing, FPGA, PC
code, power requirements
CDR
Actuator feedback,
communications, user
interface
PCB layout, movement
algorithms
Milestone 1
Complete dynamic
interaction
Milestone 2
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?