High End Force Feedback On The Way...

Well, we always wondered if the hardcore controller companies would go FF. Looks like Ball Racing is gonna be doing Force Feedback albeit rather expensively from what I've read <g> We knew it would be though, didn't we? I found this link at High Gear: http://www.f1simulator.com/ - for the entire article click here: http://dynamic2.gamespy.com/~hg/news.php?day=21&month=1&year=02#1316 - David Cook

"David L. Cook" <[email hidden]> wrote: > Well, we always wondered if the hardcore controller companies would go FF. > Looks like Ball Racing is gonna be doing Force Feedback albeit rather > expensively from what I've read <g> We knew it would be though, didn'twe? > I found this link at High Gear: > http://www.f1simulator.com/ - for the entire article click here: > http://dynamic2.gamespy.com/~hg/news.php?day=21&month=1&year=02#1316 Interesting. Here's a copy of the response from one of the developers about this product: http://dynamic2.gamespy.com/~hg/forums/showthread.php?threadid=33590 [qoute] Dear sim racers, I have had many inquiries after prizes and availability on the Reaction Force Feedback system. Therefor I thought it might be useful to give some more information on the system in this forum. The wheel is already available but it is designed for professional use now (racing teams, drivers, shows, arcades). The prize is now circa Euro 5000, depending on the exact type and options included. We are planning to develop a product for home users too but this will take some time as we have to bring the prize down substancially, we have to find less expensive parts and a more basic set up with a simple USB interface to the game. We do not want to bring the quality and the force feel down. Also very important however is the quality of the torque data output coming from the game to the FFB wheel. The wheel can be fantastic, if the vehicle dynamics model in the game is bad, the result is still not good enough. Various race simulations are now improving their physics model for and with us. Because our system runs directly on the vehicle dynamics model of the simulation software (e.g. GP3, F12001), the quality of this physics model is very important and also very well noticed by the driver.. The most important consequence is that simulation software developers are motivated to improve their vehicle dynamics models and thus their torque output data. The quality of the games will improve even more. On the pictures you see an extra computer. This is our own computer with our own characteristic for the force feel of the steering unit. As long as the torque data coming from the game is not good enough, we add our own data to reach a good result. In the future we will leave our own computer out of the loop. I hope this information gives some answers to questions you have. If there are more questions about racing simulation and motion hardware please visit our site; www.f1simulator.com kind regards, Robert Hoevers, Reaction Force Feedback [/qoute] I woudn't be interested if it wasn't affordable. But will it still be good once they've made it affordable? Ice D

Thanks for posting this here. > Because our system runs directly on the vehicle dynamics model of the > simulation software (e.g. GP3, F12001), the quality of this physics model is All the games I've been involved with, Atari Hard Drivin', Race Drivin' and Nascar Silicon Speedway have had the steering wheel and FF motor control tightly integrated with the vehicle (physics) model -- no API or other "glue/interface" code was used. Command torque went direct from the model to the D-A converter that drove the motor. Even with the slightly noisy/buzzy digital (switching) motor drive that was used in HD and RD, the steering is still among the best I've tried. Better still was a HD development version that used an audio/analog power amp to run the DC torque motor, pure silk (with a tiny amount of friction from carbon motor brushes.) It's nice that someone else has figured this out too. Separating the application software from the hardware makes it tough to do realtime control... -- Doug Milliken http://www.millikenresearch.com On Tue, 22 Jan 2002, Ice D wrote:

Quoted text (63 lines)

> Interesting. Here's a copy of the response from one of the developers about > this product: > > http://dynamic2.gamespy.com/~hg/forums/showthread.php?threadid=33590 > > [qoute] > > Dear sim racers, > > I have had many inquiries after prizes and availability on the Reaction > Force Feedback system. Therefor I thought it might be useful to give some > more information on the system in this forum. > > The wheel is already available but it is designed for professional use now > (racing teams, drivers, shows, arcades). The prize is now circa Euro 5000, > depending on the exact type and options included. > > We are planning to develop a product for home users too but this will take > some time as we have to bring the prize down substancially, we have to find > less expensive parts and a more basic set up with a simple USB interface to > the game. We do not want to bring the quality and the force feel down. > > Also very important however is the quality of the torque data output coming > from the game to the FFB wheel. The wheel can be fantastic, if the vehicle > dynamics model in the game is bad, the result is still not good enough. > Various race simulations are now improving their physics model for and with > us. > > Because our system runs directly on the vehicle dynamics model of the > simulation software (e.g. GP3, F12001), the quality of this physics model is > very important and also very well noticed by the driver.. > > The most important consequence is that simulation software developers are > motivated to improve their vehicle dynamics models and thus their torque > output data. The quality of the games will improve even more. > > On the pictures you see an extra computer. This is our own computer with our > own characteristic for the force feel of the steering unit. As long as the > torque data coming from the game is not good enough, we add our own data to > reach a good result. In the future we will leave our own computer out of the > loop. > > I hope this information gives some answers to questions you have. If there > are more questions about racing simulation and motion hardware please visit > our site; www.f1simulator.com > > kind regards, Robert Hoevers, Reaction Force Feedback > > [/qoute] > > > I woudn't be interested if it wasn't affordable. But will it still be good > once they've made it affordable? > > Ice D > > > > > > > >

"Ice D" <[email hidden]> writes: > Interesting. Here's a copy of the response from one of the developers about > this product: > > http://dynamic2.gamespy.com/~hg/forums/showthread.php?threadid=33590 I don't get it. how is all this different from "we've made a FF wheel with a spanking big motah"? and what the hell does "a reality feel of around 90%" mean? > The wheel is already available but it is designed for professional use now > (racing teams, drivers, shows, arcades). The prize is now circa Euro 5000, > depending on the exact type and options included. wish I had that kind of money to spend on gaming hardware... :( > We are planning to develop a product for home users too but this will take > some time as we have to bring the prize down substancially, we have to find > less expensive parts and a more basic set up with a simple USB interface to > the game. We do not want to bring the quality and the force feel > down. I don't get this either. if the quality and the force feel is equal; what's different? > Because our system runs directly on the vehicle dynamics model of the > simulation software (e.g. GP3, F12001), the quality of this physics model is > very important and also very well noticed by the driver.. and I DON'T GET IT! name one FF-wheel for which this statement doesn't hold true? I'm not really pissed off, I just think it just sounds like suit speak from computerworld. the wheel looks cool, though, but I can't find any shots of the pedals. or any info on them, for that matter. -- Gunnar #31 SUCKS#015 Tupperware MC#002 DoD#0x1B DoDRT#003 DoD:CT#4,8 Kibo�: 2 DE RECTIS NON TOLERANDUM EST

I'm sorry, but did he say five-THOUSAND Euros? And people think a HyperStimulator is expensive. TB

Quoted text (78 lines)

> From: "Ice D" <[email hidden]> > Organization: EuroNet Internet > Newsgroups: rec.autos.simulators > Date: Tue, 22 Jan 2002 14:19:47 GMT > Subject: Re: High End Force Feedback On The Way... > > > "David L. Cook" <[email hidden]> wrote: > >> Well, we always wondered if the hardcore controller companies would go FF. >> Looks like Ball Racing is gonna be doing Force Feedback albeit rather >> expensively from what I've read <g> We knew it would be though, didn't > we? >> I found this link at High Gear: >> http://www.f1simulator.com/ - for the entire article click here: >> http://dynamic2.gamespy.com/~hg/news.php?day=21&month=1&year=02#1316 > > Interesting. Here's a copy of the response from one of the developers about > this product: > > http://dynamic2.gamespy.com/~hg/forums/showthread.php?threadid=33590 > > [qoute] > > Dear sim racers, > > I have had many inquiries after prizes and availability on the Reaction > Force Feedback system. Therefor I thought it might be useful to give some > more information on the system in this forum. > > The wheel is already available but it is designed for professional use now > (racing teams, drivers, shows, arcades). The prize is now circa Euro 5000, > depending on the exact type and options included. > > We are planning to develop a product for home users too but this will take > some time as we have to bring the prize down substancially, we have to find > less expensive parts and a more basic set up with a simple USB interface to > the game. We do not want to bring the quality and the force feel down. > > Also very important however is the quality of the torque data output coming > from the game to the FFB wheel. The wheel can be fantastic, if the vehicle > dynamics model in the game is bad, the result is still not good enough. > Various race simulations are now improving their physics model for and with > us. > > Because our system runs directly on the vehicle dynamics model of the > simulation software (e.g. GP3, F12001), the quality of this physics model is > very important and also very well noticed by the driver.. > > The most important consequence is that simulation software developers are > motivated to improve their vehicle dynamics models and thus their torque > output data. The quality of the games will improve even more. > > On the pictures you see an extra computer. This is our own computer with our > own characteristic for the force feel of the steering unit. As long as the > torque data coming from the game is not good enough, we add our own data to > reach a good result. In the future we will leave our own computer out of the > loop. > > I hope this information gives some answers to questions you have. If there > are more questions about racing simulation and motion hardware please visit > our site; www.f1simulator.com > > kind regards, Robert Hoevers, Reaction Force Feedback > > [/qoute] > > > I woudn't be interested if it wasn't affordable. But will it still be good > once they've made it affordable? > > Ice D > > > > > >

Looks a like a fantastic concept and implementation - PC FF needs this type of R & D.. I think my major concern is the proprietry design and that PC Game developers would have to program to their API instead/including the standard DirectX. I would rather see them develop an open API with Microsoft to expand the capabilities of DirectX DirectInput. This way, game developers can send out this torque data via DirectInput API meaning that any wheel manufacturer could use this data to build a FF wheel. "David L. Cook" <[email hidden]> wrote in message news:JL338.1713$[email hidden]... > Well, we always wondered if the hardcore controller companies would go FF. > Looks like Ball Racing is gonna be doing Force Feedback albeit rather > expensively from what I've read <g> We knew it would be though, didn'twe?

Quoted text (7 lines)

> I found this link at High Gear: > http://www.f1simulator.com/ - for the entire article click here: > http://dynamic2.gamespy.com/~hg/news.php?day=21&month=1&year=02#1316 > > - David Cook > >

Hard Drivin' and Race Drivin' Now THERE's two I'd like to have sitting in my living room :) These things were great then, and would still be great now. -Larry "Doug Milliken" <[email hidden]> wrote in message news:[email hidden]... > > Thanks for posting this here. > > > Because our system runs directly on the vehicle dynamics model of the > > simulation software (e.g. GP3, F12001), the quality of this physicsmodel is > > All the games I've been involved with, Atari Hard Drivin', Race Drivin'and > Nascar Silicon Speedway have had the steering wheel and FF motor control > tightly integrated with the vehicle (physics) model -- no API or other > "glue/interface" code was used. Command torque went direct from the model > to the D-A converter that drove the motor. > > Even with the slightly noisy/buzzy digital (switching) motor drive thatwas > used in HD and RD, the steering is still among the best I've tried.Better

Quoted text (17 lines)

> still was a HD development version that used an audio/analog power amp to > run the DC torque motor, pure silk (with a tiny amount of friction from > carbon motor brushes.) > > It's nice that someone else has figured this out too. Separating the > application software from the hardware makes it tough to do realtime > control... > > -- Doug Milliken > http://www.millikenresearch.com > > > > > On Tue, 22 Jan 2002, Ice D wrote: > > > Interesting. Here's a copy of the response from one of the developers

about

Quoted text (10 lines)

> > this product: > > > > http://dynamic2.gamespy.com/~hg/forums/showthread.php?threadid=33590 > > > > [qoute] > > > > Dear sim racers, > > > > I have had many inquiries after prizes and availability on the Reaction > > Force Feedback system. Therefor I thought it might be useful to give

some > > more information on the system in this forum. > > > > The wheel is already available but it is designed for professional usenow > > (racing teams, drivers, shows, arcades). The prize is now circa Euro5000, > > depending on the exact type and options included. > > > > We are planning to develop a product for home users too but this willtake > > some time as we have to bring the prize down substancially, we have tofind > > less expensive parts and a more basic set up with a simple USB interfaceto > > the game. We do not want to bring the quality and the force feel down. > > > > Also very important however is the quality of the torque data outputcoming > > from the game to the FFB wheel. The wheel can be fantastic, if thevehicle > > dynamics model in the game is bad, the result is still not good enough. > > Various race simulations are now improving their physics model for andwith > > us. > > > > Because our system runs directly on the vehicle dynamics model of the > > simulation software (e.g. GP3, F12001), the quality of this physicsmodel is > > very important and also very well noticed by the driver.. > > > > The most important consequence is that simulation software developersare > > motivated to improve their vehicle dynamics models and thus their torque > > output data. The quality of the games will improve even more. > > > > On the pictures you see an extra computer. This is our own computer withour > > own characteristic for the force feel of the steering unit. As long asthe > > torque data coming from the game is not good enough, we add our own datato > > reach a good result. In the future we will leave our own computer out ofthe > > loop. > > > > I hope this information gives some answers to questions you have. Ifthere > > are more questions about racing simulation and motion hardware pleasevisit

Quoted text (8 lines)

> > our site; www.f1simulator.com > > > > kind regards, Robert Hoevers, Reaction Force Feedback > > > > [/qoute] > > > > > > I woudn't be interested if it wasn't affordable. But will it still be

good

Quoted text (12 lines)

> > once they've made it affordable? > > > > Ice D > > > > > > > > > > > > > > > > >

That would be great Doug, but the way I read it, they still intend to use DirectX or I-force or whatever to control the wheel. I think he's just pointing out that some sims do a better job of simulating a car than others, and the resulting FF effects are better. -- Pat Dotson Doug Milliken wrote: > > Thanks for posting this here. > > > Because our system runs directly on the vehicle dynamics model of the > > simulation software (e.g. GP3, F12001), the quality of this physics model is > > All the games I've been involved with, Atari Hard Drivin', Race Drivin' and > Nascar Silicon Speedway have had the steering wheel and FF motor control > tightly integrated with the vehicle (physics) model -- no API or other > "glue/interface" code was used. Command torque went direct from the model > to the D-A converter that drove the motor. > > Even with the slightly noisy/buzzy digital (switching) motor drive that was > used in HD and RD, the steering is still among the best I've tried. Better > still was a HD development version that used an audio/analog power amp to > run the DC torque motor, pure silk (with a tiny amount of friction from > carbon motor brushes.) > > It's nice that someone else has figured this out too. Separating the > application software from the hardware makes it tough to do realtime > control...

Yup, a good friend and I will soon have two (linked) at his house. His had a hard life (over 100K plays -- count the quarters!!), and only cost $150, it needs a new monitor and some other things fixed, but all the other expensive bits seem to be fine. I can confirm that RD is still fun to play<grin>. -- Doug On Tue, 22 Jan 2002, Larry (The Other Larry) wrote:

Quoted text (36 lines)

> Hard Drivin' and Race Drivin' Now THERE's two I'd like to have sitting in > my living room :) These things were great then, and would still be great > now. > > -Larry > > "Doug Milliken" <[email hidden]> wrote in message > news:[email hidden]... > > > > Thanks for posting this here. > > > > > Because our system runs directly on the vehicle dynamics model of the > > > simulation software (e.g. GP3, F12001), the quality of this physics > model is > > > > All the games I've been involved with, Atari Hard Drivin', Race Drivin' > and > > Nascar Silicon Speedway have had the steering wheel and FF motor control > > tightly integrated with the vehicle (physics) model -- no API or other > > "glue/interface" code was used. Command torque went direct from the model > > to the D-A converter that drove the motor. > > > > Even with the slightly noisy/buzzy digital (switching) motor drive that > was > > used in HD and RD, the steering is still among the best I've tried. > Better > > still was a HD development version that used an audio/analog power amp to > > run the DC torque motor, pure silk (with a tiny amount of friction from > > carbon motor brushes.) > > > > It's nice that someone else has figured this out too. Separating the > > application software from the hardware makes it tough to do realtime > > control... > > > > -- Doug Milliken > > http://www.millikenresearch.com

Oh well, the way I read it, it seemed that they were going to figure out some way to get around the win-doze interfaces. -- Doug On Tue, 22 Jan 2002, Pat Dotson wrote:

Quoted text (32 lines)

> That would be great Doug, but the way I read it, they still > intend to use DirectX or I-force or whatever to control the > wheel. I think he's just pointing out that some sims do a > better job of simulating a car than others, and the > resulting FF effects are better. > -- > Pat Dotson > > Doug Milliken wrote: > > > > Thanks for posting this here. > > > > > Because our system runs directly on the vehicle dynamics model of the > > > simulation software (e.g. GP3, F12001), the quality of this physics model is > > > > All the games I've been involved with, Atari Hard Drivin', Race Drivin' and > > Nascar Silicon Speedway have had the steering wheel and FF motor control > > tightly integrated with the vehicle (physics) model -- no API or other > > "glue/interface" code was used. Command torque went direct from the model > > to the D-A converter that drove the motor. > > > > Even with the slightly noisy/buzzy digital (switching) motor drive that was > > used in HD and RD, the steering is still among the best I've tried. Better > > still was a HD development version that used an audio/analog power amp to > > run the DC torque motor, pure silk (with a tiny amount of friction from > > carbon motor brushes.) > > > > It's nice that someone else has figured this out too. Separating the > > application software from the hardware makes it tough to do realtime > > control... > >

Since we're on the subject, I thought I'd throw in a quote from MGI's Dave Pollatsek that caught my eye a while back in a non-FF-related thread. Might be of interest here... SB "My current proposal for advancing force feedback--do what MS and nVidia did to Direct3D8 with programmable vertex shaders to DirectInput--create a simple DSP-like byte code that could be compiled into microprograms that the wheels could run in hardware, so the wheels could do prediction code without having to USB back to the computer, wait for the next physics frame, USB back to the wheel and from there to the motor--I think you could achieve a really "tight" and responsive feel with this method and reduce or eliminate the spiking and self-oscillation problems that are currently endemic to any "non-canned" force feedback implementation, and a 30-cent CPU should be powerful enough to implement this." "Doug Milliken" <[email hidden]> wrote in message news:[email hidden]...

Quoted text (42 lines)

> > Oh well, the way I read it, it seemed that they were going to figure out > some way to get around the win-doze interfaces. > > -- Doug > > > On Tue, 22 Jan 2002, Pat Dotson wrote: > > > That would be great Doug, but the way I read it, they still > > intend to use DirectX or I-force or whatever to control the > > wheel. I think he's just pointing out that some sims do a > > better job of simulating a car than others, and the > > resulting FF effects are better. > > -- > > Pat Dotson > > > > Doug Milliken wrote: > > > > > > Thanks for posting this here. > > > > > > > Because our system runs directly on the vehicle dynamics model of the > > > > simulation software (e.g. GP3, F12001), the quality of this physics model is > > > > > > All the games I've been involved with, Atari Hard Drivin', Race Drivin' and > > > Nascar Silicon Speedway have had the steering wheel and FF motor control > > > tightly integrated with the vehicle (physics) model -- no API or other > > > "glue/interface" code was used. Command torque went direct from the model > > > to the D-A converter that drove the motor. > > > > > > Even with the slightly noisy/buzzy digital (switching) motor drive that was > > > used in HD and RD, the steering is still among the best I've tried. Better > > > still was a HD development version that used an audio/analog power amp to > > > run the DC torque motor, pure silk (with a tiny amount of friction from > > > carbon motor brushes.) > > > > > > It's nice that someone else has figured this out too. Separating the > > > application software from the hardware makes it tough to do realtime > > > control... > > > > >

This is obscene -- a patch on a patch, on a patch. It's so simple when the model talks directly to the hardware... I mean, while you are at it, why not have the steering wheel run the car physics and tell the PC what viewpoint to display? -- Doug Milliken On Wed, 23 Jan 2002, Steve Blankenship wrote:

Quoted text (61 lines)

> Since we're on the subject, I thought I'd throw in a quote from MGI's Dave Pollatsek that caught my eye a while back in a > non-FF-related thread. Might be of interest here... > > SB > > "My current proposal for advancing force feedback--do what MS and nVidia did to Direct3D8 with programmable vertex shaders to > DirectInput--create a simple DSP-like byte code that could be compiled into microprograms that the wheels could run in hardware, so > the wheels could do prediction code without > having to USB back to the computer, wait for the next physics frame, USB back to the wheel and from there to the motor--I think you > could achieve a really "tight" and responsive feel with this method and reduce or eliminate the spiking and self-oscillation > problems that are currently endemic to any "non-canned" force feedback implementation, and a 30-cent CPU should be powerful enough > to implement this." > > > "Doug Milliken" <[email hidden]> wrote in message news:[email hidden]... > > > > Oh well, the way I read it, it seemed that they were going to figure out > > some way to get around the win-doze interfaces. > > > > -- Doug > > > > > > On Tue, 22 Jan 2002, Pat Dotson wrote: > > > > > That would be great Doug, but the way I read it, they still > > > intend to use DirectX or I-force or whatever to control the > > > wheel. I think he's just pointing out that some sims do a > > > better job of simulating a car than others, and the > > > resulting FF effects are better. > > > -- > > > Pat Dotson > > > > > > Doug Milliken wrote: > > > > > > > > Thanks for posting this here. > > > > > > > > > Because our system runs directly on the vehicle dynamics model of the > > > > > simulation software (e.g. GP3, F12001), the quality of this physics model is > > > > > > > > All the games I've been involved with, Atari Hard Drivin', Race Drivin' and > > > > Nascar Silicon Speedway have had the steering wheel and FF motor control > > > > tightly integrated with the vehicle (physics) model -- no API or other > > > > "glue/interface" code was used. Command torque went direct from the model > > > > to the D-A converter that drove the motor. > > > > > > > > Even with the slightly noisy/buzzy digital (switching) motor drive that was > > > > used in HD and RD, the steering is still among the best I've tried. Better > > > > still was a HD development version that used an audio/analog power amp to > > > > run the DC torque motor, pure silk (with a tiny amount of friction from > > > > carbon motor brushes.) > > > > > > > > It's nice that someone else has figured this out too. Separating the > > > > application software from the hardware makes it tough to do realtime > > > > control... > > > > > > > > > > > >

(arguing against Doug for no good reason, especially as he's surely right...) The reason I suggested that was because USB and Windows conspire to give us too much latency to get good feedback without wheelside prediction--I was thinking more of "consumer" wheels, where my change would be quite cheap to implement. A custom interface card would be awesome, though; however, trying to get a slice of CPU time to service it reliably every few milliseconds seems to get harder every year... trying to keep our sound-mixing thread scheduled ahead of the output buffer was hard enough... we need OpenGL for DOS or something. -Dave "Doug Milliken" <[email hidden]> wrote in message news:[email hidden]...

Quoted text (12 lines)

> > This is obscene -- a patch on a patch, on a patch. > It's so simple when the model talks directly to the hardware... > > I mean, while you are at it, why not have the steering wheel run > the car physics and tell the PC what viewpoint to display? > > -- Doug Milliken > > On Wed, 23 Jan 2002, Steve Blankenship wrote: > > > Since we're on the subject, I thought I'd throw in a quote from MGI's

Dave Pollatsek that caught my eye a while back in a > > non-FF-related thread. Might be of interest here... > > > > SB > > > > "My current proposal for advancing force feedback--do what MS and nVidiadid to Direct3D8 with programmable vertex shaders to > > DirectInput--create a simple DSP-like byte code that could be compiledinto microprograms that the wheels could run in hardware, so > > the wheels could do prediction code without > > having to USB back to the computer, wait for the next physics frame, USBback to the wheel and from there to the motor--I think you > > could achieve a really "tight" and responsive feel with this method andreduce or eliminate the spiking and self-oscillation > > problems that are currently endemic to any "non-canned" force feedbackimplementation, and a 30-cent CPU should be powerful enough > > to implement this." > > > > > > "Doug Milliken" <[email hidden]> wrote in messagenews:[email hidden]... > > > > > > Oh well, the way I read it, it seemed that they were going to figureout

Quoted text (20 lines)

> > > some way to get around the win-doze interfaces. > > > > > > -- Doug > > > > > > > > > On Tue, 22 Jan 2002, Pat Dotson wrote: > > > > > > > That would be great Doug, but the way I read it, they still > > > > intend to use DirectX or I-force or whatever to control the > > > > wheel. I think he's just pointing out that some sims do a > > > > better job of simulating a car than others, and the > > > > resulting FF effects are better. > > > > -- > > > > Pat Dotson > > > > > > > > Doug Milliken wrote: > > > > > > > > > > Thanks for posting this here. > > > > > > > > > > > Because our system runs directly on the vehicle dynamics model

of the > > > > > > simulation software (e.g. GP3, F12001), the quality of thisphysics model is > > > > > > > > > > All the games I've been involved with, Atari Hard Drivin', RaceDrivin' and > > > > > Nascar Silicon Speedway have had the steering wheel and FF motorcontrol > > > > > tightly integrated with the vehicle (physics) model -- no API orother > > > > > "glue/interface" code was used. Command torque went direct fromthe model > > > > > to the D-A converter that drove the motor. > > > > > > > > > > Even with the slightly noisy/buzzy digital (switching) motor drivethat was > > > > > used in HD and RD, the steering is still among the best I'vetried. Better > > > > > still was a HD development version that used an audio/analog poweramp to > > > > > run the DC torque motor, pure silk (with a tiny amount of frictionfrom > > > > > carbon motor brushes.) > > > > > > > > > > It's nice that someone else has figured this out too. Separatingthe > > > > > application software from the hardware makes it tough to dorealtime

Quoted text (9 lines)

> > > > > control... > > > > > > > > > > > > > > > > > > > >

It's all about latency for sure. And the standard M$ software doesn't seem to give a damn about latency for game controllers... My comments weren't meant to be a personal attack -- I was really trying to spur someone (some group?) to develop a more elegant way to talk to PC hardware. Seems like all kinds of games would profit from this. But I'm not going to be able to do it, I'm a car guy, not a game programmer. -- Doug On Wed, 23 Jan 2002, Dave Pollatsek wrote:

Quoted text (111 lines)

> (arguing against Doug for no good reason, especially as he's surely > right...) > The reason I suggested that was because USB and Windows conspire to give us > too much latency to get good feedback without wheelside prediction--I was > thinking more of "consumer" wheels, where my change would be quite cheap to > implement. A custom interface card would be awesome, though; however, > trying to get a slice of CPU time to service it reliably every few > milliseconds seems to get harder every year... trying to keep our > sound-mixing thread scheduled ahead of the output buffer was hard enough... > we need OpenGL for DOS or something. > -Dave > > "Doug Milliken" <[email hidden]> wrote in message > news:[email hidden]... > > > > This is obscene -- a patch on a patch, on a patch. > > It's so simple when the model talks directly to the hardware... > > > > I mean, while you are at it, why not have the steering wheel run > > the car physics and tell the PC what viewpoint to display? > > > > -- Doug Milliken > > > > On Wed, 23 Jan 2002, Steve Blankenship wrote: > > > > > Since we're on the subject, I thought I'd throw in a quote from MGI's > Dave Pollatsek that caught my eye a while back in a > > > non-FF-related thread. Might be of interest here... > > > > > > SB > > > > > > "My current proposal for advancing force feedback--do what MS and nVidia > did to Direct3D8 with programmable vertex shaders to > > > DirectInput--create a simple DSP-like byte code that could be compiled > into microprograms that the wheels could run in hardware, so > > > the wheels could do prediction code without > > > having to USB back to the computer, wait for the next physics frame, USB > back to the wheel and from there to the motor--I think you > > > could achieve a really "tight" and responsive feel with this method and > reduce or eliminate the spiking and self-oscillation > > > problems that are currently endemic to any "non-canned" force feedback > implementation, and a 30-cent CPU should be powerful enough > > > to implement this." > > > > > > > > > "Doug Milliken" <[email hidden]> wrote in message > news:[email hidden]... > > > > > > > > Oh well, the way I read it, it seemed that they were going to figure > out > > > > some way to get around the win-doze interfaces. > > > > > > > > -- Doug > > > > > > > > > > > > On Tue, 22 Jan 2002, Pat Dotson wrote: > > > > > > > > > That would be great Doug, but the way I read it, they still > > > > > intend to use DirectX or I-force or whatever to control the > > > > > wheel. I think he's just pointing out that some sims do a > > > > > better job of simulating a car than others, and the > > > > > resulting FF effects are better. > > > > > -- > > > > > Pat Dotson > > > > > > > > > > Doug Milliken wrote: > > > > > > > > > > > > Thanks for posting this here. > > > > > > > > > > > > > Because our system runs directly on the vehicle dynamics model > of the > > > > > > > simulation software (e.g. GP3, F12001), the quality of this > physics model is > > > > > > > > > > > > All the games I've been involved with, Atari Hard Drivin', Race > Drivin' and > > > > > > Nascar Silicon Speedway have had the steering wheel and FF motor > control > > > > > > tightly integrated with the vehicle (physics) model -- no API or > other > > > > > > "glue/interface" code was used. Command torque went direct from > the model > > > > > > to the D-A converter that drove the motor. > > > > > > > > > > > > Even with the slightly noisy/buzzy digital (switching) motor drive > that was > > > > > > used in HD and RD, the steering is still among the best I've > tried. Better > > > > > > still was a HD development version that used an audio/analog power > amp to > > > > > > run the DC torque motor, pure silk (with a tiny amount of friction > from > > > > > > carbon motor brushes.) > > > > > > > > > > > > It's nice that someone else has figured this out too. Separating > the > > > > > > application software from the hardware makes it tough to do > realtime > > > > > > control... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >

Dave - who do you program for? "Dave Pollatsek" <[email hidden]> wrote in message news:3c50ccb4$0$79564$[email hidden]... > I suppose I have a more direct comparison of the "MS" component in the > equation, because the Playstation2 can talk to the Logitech wheels via USB > and Logitech's custom API... our last PS2 game just used pretty much > identical code to our PC FF code (just tweaking the constant force > continuously based on force at the steering linkage); I started working on > my own hacked-together USB driver for other wheels, I'm curious to seewhat > kind of latency you can get sans Windows. Of course you still have to go > from the CPU to the IOP sub-processor to get to the USB via DMA, so it'snot > as good as an ISA card or something.

I suppose I have a more direct comparison of the "MS" component in the equation, because the Playstation2 can talk to the Logitech wheels via USB and Logitech's custom API... our last PS2 game just used pretty much identical code to our PC FF code (just tweaking the constant force continuously based on force at the steering linkage); I started working on my own hacked-together USB driver for other wheels, I'm curious to see what kind of latency you can get sans Windows. Of course you still have to go from the CPU to the IOP sub-processor to get to the USB via DMA, so it's not as good as an ISA card or something. I think the test could be something like send a continuous stream of "zero" force, followed by a stream of "left" force, all the while continously sampling the steering input, and seeing how long before you can read a change in steering input due to the motor... my suspicion is that a lot of the latency will be in the hardware and the USB connection, but if I get some numbers I'll post them here. It'd be great of there was a standard controller latency test, kind of like a Winmark, then the controller guys could compete on latency. -Dave P. "Doug Milliken" <[email hidden]> wrote in message news:[email hidden]... > > It's all about latency for sure. And the standard M$ software doesn'tseem > to give a damn about latency for game controllers... > > My comments weren't meant to be a personal attack -- I was really tryingto

Quoted text (10 lines)

> spur someone (some group?) to develop a more elegant way to talk to PC > hardware. Seems like all kinds of games would profit from this. But I'm > not going to be able to do it, I'm a car guy, not a game programmer. > -- Doug > > On Wed, 23 Jan 2002, Dave Pollatsek wrote: > > > (arguing against Doug for no good reason, especially as he's surely > > right...) > > The reason I suggested that was because USB and Windows conspire to give

us > > too much latency to get good feedback without wheelside prediction--Iwas > > thinking more of "consumer" wheels, where my change would be quite cheapto > > implement. A custom interface card would be awesome, though; however, > > trying to get a slice of CPU time to service it reliably every few > > milliseconds seems to get harder every year... trying to keep our > > sound-mixing thread scheduled ahead of the output buffer was hardenough...

Quoted text (17 lines)

> > we need OpenGL for DOS or something. > > -Dave > > > > "Doug Milliken" <[email hidden]> wrote in message > > news:[email hidden]... > > > > > > This is obscene -- a patch on a patch, on a patch. > > > It's so simple when the model talks directly to the hardware... > > > > > > I mean, while you are at it, why not have the steering wheel run > > > the car physics and tell the PC what viewpoint to display? > > > > > > -- Doug Milliken > > > > > > On Wed, 23 Jan 2002, Steve Blankenship wrote: > > > > > > > Since we're on the subject, I thought I'd throw in a quote from

MGI's > > Dave Pollatsek that caught my eye a while back in a > > > > non-FF-related thread. Might be of interest here... > > > > > > > > SB > > > > > > > > "My current proposal for advancing force feedback--do what MS andnVidia > > did to Direct3D8 with programmable vertex shaders to > > > > DirectInput--create a simple DSP-like byte code that could becompiled > > into microprograms that the wheels could run in hardware, so > > > > the wheels could do prediction code without > > > > having to USB back to the computer, wait for the next physics frame,USB > > back to the wheel and from there to the motor--I think you > > > > could achieve a really "tight" and responsive feel with this methodand > > reduce or eliminate the spiking and self-oscillation > > > > problems that are currently endemic to any "non-canned" forcefeedback

Quoted text (8 lines)

> > implementation, and a 30-cent CPU should be powerful enough > > > > to implement this." > > > > > > > > > > > > "Doug Milliken" <[email hidden]> wrote in message > > news:[email hidden]... > > > > > > > > > > Oh well, the way I read it, it seemed that they were going to

figure

Quoted text (21 lines)

> > out > > > > > some way to get around the win-doze interfaces. > > > > > > > > > > -- Doug > > > > > > > > > > > > > > > On Tue, 22 Jan 2002, Pat Dotson wrote: > > > > > > > > > > > That would be great Doug, but the way I read it, they still > > > > > > intend to use DirectX or I-force or whatever to control the > > > > > > wheel. I think he's just pointing out that some sims do a > > > > > > better job of simulating a car than others, and the > > > > > > resulting FF effects are better. > > > > > > -- > > > > > > Pat Dotson > > > > > > > > > > > > Doug Milliken wrote: > > > > > > > > > > > > > > Thanks for posting this here. > > > > > > > > > > > > > > > Because our system runs directly on the vehicle dynamics

model > > of the > > > > > > > > simulation software (e.g. GP3, F12001), the quality of this > > physics model is > > > > > > > > > > > > > > All the games I've been involved with, Atari Hard Drivin',Race > > Drivin' and > > > > > > > Nascar Silicon Speedway have had the steering wheel and FFmotor > > control > > > > > > > tightly integrated with the vehicle (physics) model -- no APIor > > other > > > > > > > "glue/interface" code was used. Command torque went directfrom > > the model > > > > > > > to the D-A converter that drove the motor. > > > > > > > > > > > > > > Even with the slightly noisy/buzzy digital (switching) motordrive > > that was > > > > > > > used in HD and RD, the steering is still among the best I've > > tried. Better > > > > > > > still was a HD development version that used an audio/analogpower > > amp to > > > > > > > run the DC torque motor, pure silk (with a tiny amount offriction > > from > > > > > > > carbon motor brushes.) > > > > > > > > > > > > > > It's nice that someone else has figured this out too.Separating

Quoted text (17 lines)

> > the > > > > > > > application software from the hardware makes it tough to do > > realtime > > > > > > > control... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >

"Dave Pollatsek" <[email hidden]> wrote in message news:<3c50ccb4$0$79564$[email hidden]>...

Quoted text (8 lines)

> I think the test could be something like send a continuous stream of "zero" > force, followed by a stream of "left" force, all the while continously > sampling the steering input, and seeing how long before you can read a > change in steering input due to the motor... my suspicion is that a lot of > the latency will be in the hardware and the USB connection, but if I get > some numbers I'll post them here. It'd be great of there was a standard > controller latency test, kind of like a Winmark, then the controller guys > could compete on latency.

Dave you're a hero. I asked Act Labs for something like this two years ago but nothing came of it. There's actually two tests I'd do. Start wheel moving right then switch to moving left and measure the time taken until the change reaches the input. That's the total latency. Start it moving left again and measure the time until the signal reaches the input. As the wheel had already been moving left it would have taken up any slack in the mechanism. Subtract that from the total latency figure and you have the slack in the wheel. I'd also try it at different velocities to see if that affects the latency. I'm very interested to see what sort of figures you come up with. I've been convinced for ages that the latency should be measured in tenths rather then 10,000ths of a second. Paul :o)

"David L. Cook" wrote:

Quoted text (16 lines)

> > Dave - who do you program for? > > "Dave Pollatsek" <[email hidden]> wrote in message > news:3c50ccb4$0$79564$[email hidden]... > > I suppose I have a more direct comparison of the "MS" component in the > > equation, because the Playstation2 can talk to the Logitech wheels via USB > > and Logitech's custom API... our last PS2 game just used pretty much > > identical code to our PC FF code (just tweaking the constant force > > continuously based on force at the steering linkage); I started working on > > my own hacked-together USB driver for other wheels, I'm curious to see > what > > kind of latency you can get sans Windows. Of course you still have to go > > from the CPU to the IOP sub-processor to get to the USB via DMA, so it's > not > > as good as an ISA card or something.

Microprose, his real name is Geoff Crammond..... Beers and cheers (uncle) Goy "The Pits" http://www.theuspits.com/ * Spam is for losers who can't get business any other way * "Spamkiller" http://www.spamkiller.com

While you guys are all paying attention, what do you think about... Instead of basing FF effects on steering mechanism forces, simply tie FF to the lateral g-forces acting on the driver? Then you get the seat-of-the-pants feel that is missing from a computer simulation. F1-2001 does it this way, and for my money, it's the best feeling FF currently available in a PC driving sim. -- Pat Dotson

On Fri, 25 Jan 2002, Pat Dotson wrote: > Instead of basing FF effects on steering mechanism forces, simply tie FF > to the lateral g-forces acting on the driver? Then you get the > seat-of-the-pants feel that is missing from a computer simulation. If I understand what you are saying, I think this would add more lag. Steer torque comes from front kingpin torque and this in turn is a function of the lateral force (and tire aligning torque) at the front wheels. The only lag in this system (assuming simple rigid suspension) is the tire lag (relaxation length), because lateral force at the front axle immediately starts to "push" the car into a turn. When you move aft along the wheelbase to the driver position, then the onset of lateral force lags a bit, because the whole car has to rotate. ---------- Re original thread -- I'm looking forward to reading about some latency measurements, could be very interesting. Might even be embarrasing for the original authors of any bottleneck(s)! -- Doug Milliken

On Sat, 26 Jan 2002 08:11:31 GMT, Doug Milliken <[email hidden]> wrote:

Quoted text (8 lines)

> >On Fri, 25 Jan 2002, Pat Dotson wrote: >> Instead of basing FF effects on steering mechanism forces, simply tie FF >> to the lateral g-forces acting on the driver? Then you get the >> seat-of-the-pants feel that is missing from a computer simulation. > > >If I understand what you are saying, I think this would add more lag.

Hm, does indeed look like it. I'll add an option to use this kind of FF (although it will need tweaking, as the influence of lateral acceleration vs. tire grip is probably mostly a matter of personal feel) in Racer. It's not that hard to build in, so that might give a nice testbed. ... >When you move aft along the wheelbase to the driver position, then the >onset of lateral force lags a bit, because the whole car has to rotate. Isn't the lateral acceleration on every part of the car the same? (obviously the lateral velocity isn't, but the acceleration seems untied to a position in the car). That would suggest no more lag than usual, since even though rotational *velocity* might need a buildup, the *acceleration* of the car body doesn't (and that's where you derive the FF from). Ruud van Gaal Free car sim : http://www.marketgraph.nl/gallery/racer/ Pencil art : http://www.marketgraph.nl/gallery/

My god, we are still talking about wheels that shake a bit as you drive, right? Never mind, carry on... ;) Ice D "Ruud van Gaal" <[email hidden]> wrote in message news:[email hidden]... > On Sat, 26 Jan 2002 08:11:31 GMT, Doug Milliken <[email hidden]> wrote: > > > > >On Fri, 25 Jan 2002, Pat Dotson wrote: > >> Instead of basing FF effects on steering mechanism forces, simply tieFF

Quoted text (27 lines)

> >> to the lateral g-forces acting on the driver? Then you get the > >> seat-of-the-pants feel that is missing from a computer simulation. > > > > > >If I understand what you are saying, I think this would add more lag. > > Hm, does indeed look like it. I'll add an option to use this kind of > FF (although it will need tweaking, as the influence of lateral > acceleration vs. tire grip is probably mostly a matter of personal > feel) in Racer. > It's not that hard to build in, so that might give a nice testbed. > > ... > >When you move aft along the wheelbase to the driver position, then the > >onset of lateral force lags a bit, because the whole car has to rotate. > > Isn't the lateral acceleration on every part of the car the same? > (obviously the lateral velocity isn't, but the acceleration seems > untied to a position in the car). > That would suggest no more lag than usual, since even though > rotational *velocity* might need a buildup, the *acceleration* of the > car body doesn't (and that's where you derive the FF from). > > > Ruud van Gaal > Free car sim : http://www.marketgraph.nl/gallery/racer/ > Pencil art : http://www.marketgraph.nl/gallery/

You must own a hyperstimulator :) Ice D wrote:

Quoted text (41 lines)

> > My god, we are still talking about wheels that shake a bit as you drive, > right? Never mind, carry on... ;) > > Ice D > > "Ruud van Gaal" <[email hidden]> wrote in message > news:[email hidden]... > > On Sat, 26 Jan 2002 08:11:31 GMT, Doug Milliken <[email hidden]> wrote: > > > > > > > >On Fri, 25 Jan 2002, Pat Dotson wrote: > > >> Instead of basing FF effects on steering mechanism forces, simply tie > FF > > >> to the lateral g-forces acting on the driver? Then you get the > > >> seat-of-the-pants feel that is missing from a computer simulation. > > > > > > > > >If I understand what you are saying, I think this would add more lag. > > > > Hm, does indeed look like it. I'll add an option to use this kind of > > FF (although it will need tweaking, as the influence of lateral > > acceleration vs. tire grip is probably mostly a matter of personal > > feel) in Racer. > > It's not that hard to build in, so that might give a nice testbed. > > > > ... > > >When you move aft along the wheelbase to the driver position, then the > > >onset of lateral force lags a bit, because the whole car has to rotate. > > > > Isn't the lateral acceleration on every part of the car the same? > > (obviously the lateral velocity isn't, but the acceleration seems > > untied to a position in the car). > > That would suggest no more lag than usual, since even though > > rotational *velocity* might need a buildup, the *acceleration* of the > > car body doesn't (and that's where you derive the FF from). > > > > > > Ruud van Gaal > > Free car sim : http://www.marketgraph.nl/gallery/racer/ > > Pencil art : http://www.marketgraph.nl/gallery/

[FYI, I mistakenly replied to Doug through email instead of through RAS. I've forwarded his reply back to RAS - hope you don't mind Doug] More interesting stuff, but confusing. The #1 complaint I hear from people who *should* be interested in PC sims, but arent' (people who race in real life) is that they can't feel what the car is doing. In my opinion, current FF comes pretty close to making up for the SOP feel. But if real drivers don't necessarily use the g-force feedback they get, then what should PC sim FF be based upon? In my real experience, which is 95% go-kart, actual wheel feedback isn't much of a factor in driving. Maybe it should be, but it generally isn't. That's why I like the idea of lateral force-based FF. -- Pat Dotson Doug Milliken wrote: On Sat, 26 Jan 2002, Pat Dotson wrote: > Interesting point Doug. What % of feedback to you estimate > a driver gets from the steering wheel, and what % from > seat of pants (SOP)? I haven't thought too much about > the differences in feedback, and just assumed that SOP > would be more desirable. No idea. People can be very sensitive, I know I can sense .01 g lateral with my eyes closed...on a smooth freeway. But I doubt that I could even tell .1 g difference if I was getting shook in a race car with hard-mounted engine, cornering at 3 g's. Once drivers learn a track (a few laps for most places), I think that they drive from memory with small changes to see if the change will improve things. They must be good at filtering out most of the SOP info coming in because it's huge (body damaging?) vibration in most race cars. > On a side note, are there very many types of dedicated race > cars that use power steering? That would kind of kill any > steer torque feeback, wouldn't it? Winston Cup, Sprint cars, F1, probably others. It's an area ripe for innovation, imo. Why off list?? -- Doug Milliken

F1 2001 FF is based on lateral force at the front wheels. I have a feeling that this implementation actually causes a kind of lag compared to basing it off of force at CG or force at drivers SOP. Here is why: The front wheels can still be gripping, and still be generating lateral force, even when the back wheels have lost traction and are sliding. It will take a moment for the front wheels to also lose traction, whether it's a slide, or a spin or whatever. It seems like a mid-car position would give you a better idea of what the whole car is really doing. This method should give a better feel for when the car is getting loose. It would be great to be able to test this idea in RACER. -- Pat Dotson "Ruud van Gaal" <[email hidden]> wrote in message > >When you move aft along the wheelbase to the driver position, then the > >onset of lateral force lags a bit, because the whole car has to rotate. > > Isn't the lateral acceleration on every part of the car the same? > (obviously the lateral velocity isn't, but the acceleration seems > untied to a position in the car). > That would suggest no more lag than usual, since even though > rotational *velocity* might need a buildup, the *acceleration* of the > car body doesn't (and that's where you derive the FF from).

"David L. Cook" wrote... > Dave - who do you program for? > > "Dave Pollatsek" <[email hidden]> wrote in message<snip> Dave was lead programmer for MGI's Viper Racing and as loyalty seems to be a feature of sim programmers he's probably still there Tony Whitley Lead programmer, mobile phones :-(

Nah, doesn't have an ashtray... Ice D "Pat Dotson" <[email hidden]> wrote

Quoted text (16 lines)

> You must own a hyperstimulator :) > > Ice D wrote: > > > > My god, we are still talking about wheels that shake a bit as you drive, > > right? Never mind, carry on... ;) > > > > Ice D > > > > "Ruud van Gaal" <[email hidden]> wrote in message > > news:[email hidden]... > > > On Sat, 26 Jan 2002 08:11:31 GMT, Doug Milliken <[email hidden]> wrote: > > > > > > > > > > >On Fri, 25 Jan 2002, Pat Dotson wrote: > > > >> Instead of basing FF effects on steering mechanism forces, simply

tie > > FF > > > >> to the lateral g-forces acting on the driver? Then you get the > > > >> seat-of-the-pants feel that is missing from a computer simulation.

"Tony Whitley" <> Dave was lead programmer for MGI's Viper Racing and as loyalty seems to be a > feature of sim programmers he's probably still there > > Tony Whitley > Lead programmer, mobile phones :-( You are correct sir. Dave has been the guy who's pumped out the patches for Nascar Heat and done quite a-bit of troubleshooting too. Thanks sir... ps...any of you seen the mod community springing up around Heat? Really taking off thanks to the patch additions Dave included. dh

On Sat, 26 Jan 2002 23:48:25 -0500, Pat Dotson <[email hidden]> wrote:

Quoted text (10 lines)

>F1 2001 FF is based on lateral force at the front wheels. >I have a feeling that this implementation actually causes >a kind of lag compared to basing it off of force at CG >or force at drivers SOP. > >Here is why: > >The front wheels can still be gripping, and still be >generating lateral force, even when the back wheels >have lost traction and are sliding.

Yes, but the acceleration you get is based on the total grip on all four wheels, so I was going to take the body acceleration (not the lateral forces on just the front wheels). And using the body (linear) acceleration, all 4 wheels are accounted for, so there's no lag then. Ruud van Gaal Free car sim : http://www.marketgraph.nl/gallery/racer/ Pencil art : http://www.marketgraph.nl/gallery/

On Mon, 28 Jan 2002, Ruud van Gaal wrote: > Yes, but the acceleration you get is based on the total grip on all > four wheels, so I was going to take the body acceleration (not the > lateral forces on just the front wheels). > And using the body (linear) acceleration, all 4 wheels are accounted > for, so there's no lag then. Yaw rate does not depend on measurement position, lateral acceleration does. Look at the simple 2-dof equations--this is enough of a hint<grin>.

On Mon, 28 Jan 2002 15:06:47 GMT, Doug Milliken <[email hidden]> wrote:

Quoted text (10 lines)

> >On Mon, 28 Jan 2002, Ruud van Gaal wrote: > >> Yes, but the acceleration you get is based on the total grip on all >> four wheels, so I was going to take the body acceleration (not the >> lateral forces on just the front wheels). >> And using the body (linear) acceleration, all 4 wheels are accounted >> for, so there's no lag then. > >Yaw rate does not depend on measurement position, lateral acceleration does.

Yup; to get lateral acceleration to look the same in every spot, I am going try and leave out the angular acceleration. In that case the lateral acceleration I was talking about can be seen as that of the CG (reduced to just linear acceleration). Perhaps that would be good enough for an FF input. Anyway, implementing this is the only way to get a good feel; I felt a bug in my track spline implementation only when I drove on the track with an FF wheel; little jerks when switching to the next triangle. Hopefully just (lateral) acceleration at the CG will be good enough. Now that I think of it, longitudinal acceleration may be used to change the grip of the wheel (the friction). Perhaps. :) Ruud van Gaal Free car sim : http://www.marketgraph.nl/gallery/racer/ Pencil art : http://www.marketgraph.nl/gallery/

On Mon, 28 Jan 2002, Ruud van Gaal wrote:

Quoted text (7 lines)

> On Mon, 28 Jan 2002 15:06:47 GMT, Doug Milliken <[email hidden]> wrote: > >Yaw rate does not depend on measurement position, lateral acceleration does. > Yup; to get lateral acceleration to look the same in every spot, I am > going try and leave out the angular acceleration. In that case the > lateral acceleration I was talking about can be seen as that of the CG > (reduced to just linear acceleration).

So you will model something (not an ordinary car!) that just translates, without yaw angle, yaw rate, yaw accel. I drove a car with 4 wheel steer that could be set to have equal steer angles front and rear. Impossible to rotate the car because steering input did not create any yaw rate (or yaw acceleration). In fact, if it was calibrated perfectly, the car heading would never change, if it starts out pointing north, it keeps pointing north (although the path can go in different directions.)

Sounds just the ticket for parallel parking in those tight pit lanes! Once rode a bicycle that pivoted at BOTH wheels, and you could do the same thing. Very odd, crabbing around like that... ;-) SB "Doug Milliken" <[email hidden]> wrote...

Quoted text (7 lines)

> So you will model something (not an ordinary car!) that just translates, > without yaw angle, yaw rate, yaw accel. I drove a car with 4 wheel steer > that could be set to have equal steer angles front and rear. Impossible to > rotate the car because steering input did not create any yaw rate (or yaw > acceleration). In fact, if it was calibrated perfectly, the car heading > would never change, if it starts out pointing north, it keeps pointing > north (although the path can go in different directions.)

On Mon, 28 Jan 2002 18:06:21 GMT, Doug Milliken <[email hidden]> wrote:

Quoted text (16 lines)

> >On Mon, 28 Jan 2002, Ruud van Gaal wrote: > >> On Mon, 28 Jan 2002 15:06:47 GMT, Doug Milliken <[email hidden]> wrote: >> >Yaw rate does not depend on measurement position, lateral acceleration does. > >> Yup; to get lateral acceleration to look the same in every spot, I am >> going try and leave out the angular acceleration. In that case the >> lateral acceleration I was talking about can be seen as that of the CG >> (reduced to just linear acceleration). > >So you will model something (not an ordinary car!) that just translates, >without yaw angle, yaw rate, yaw accel. I drove a car with 4 wheel steer >that could be set to have equal steer angles front and rear. Impossible to >rotate the car because steering input did not create any yaw rate (or yaw >acceleration).

Lol, so how far did you get? :) But what I meant was that I'd use the translation acceleration for the FF; other than that, the car has 6 DOF (well, 18 or something, if not more). Just plucking out bits of the data often gives good performance advantages; such as not using a full matrix for the wheels etc. Ruud van Gaal Free car sim : http://www.marketgraph.nl/gallery/racer/ Pencil art : http://www.marketgraph.nl/gallery/

Ruud van Gaal wrote: > > Anyway, > implementing this is the only way to get a good feel; I felt a bug in > my track spline implementation only when I drove on the track with an > FF wheel; little jerks when switching to the next triangle. Hopefully > just (lateral) acceleration at the CG will be good enough. Suhweet :) Can't wait to try it! -- Pat Dotson

Actually, Rich Garcia (our fearless leader) was lead p. on Viper and Heat PC; I was just the physics programmer (plus misc other crap, UI, paintkit, etc). I was lead on Heat PS2 (2002 season). -Dave P. "Tony Whitley" <[email hidden]> wrote in message news:a3158v$98h$[email hidden]...

Quoted text (8 lines)

> > "David L. Cook" wrote... > > Dave - who do you program for? > > > > "Dave Pollatsek" <[email hidden]> wrote in message > <snip> > > Dave was lead programmer for MGI's Viper Racing and as loyalty seems to be

a

Quoted text (7 lines)

> feature of sim programmers he's probably still there > > Tony Whitley > Lead programmer, mobile phones :-( > > >

Hehe. I was just playing NH 2002 on my new PS2! Actually my 7 year old wanted me to get it. He also likes GPL. He insists on the hardest tracks - Monaco is his favorite. I set the gas and brake to the paddle shifters because he can't reach the floor with his feet <g>. Of course I put on all the helps. His favorite keyboard command is <Shift><R> - David Cook "Dave Pollatsek" <[email hidden]> wrote in message news:3c5a1b79$0$79558$[email hidden]...

Quoted text (15 lines)

> Actually, Rich Garcia (our fearless leader) was lead p. on Viper and Heat > PC; I was just the physics programmer (plus misc other crap, UI, paintkit, > etc). I was lead on Heat PS2 (2002 season). > -Dave P. > > "Tony Whitley" <[email hidden]> wrote in message > news:a3158v$98h$[email hidden]... > > > > "David L. Cook" wrote... > > > Dave - who do you program for? > > > > > > "Dave Pollatsek" <[email hidden]> wrote in message > > <snip> > > > > Dave was lead programmer for MGI's Viper Racing and as loyalty seems to

be > a feature of sim programmers he's probably still there > > > > Tony Whitley > > Lead programmer, mobile phones :-(