I am with Bernhard on this one. Since I do not actually have a force
feedback wheel
I cannot really test it. But I can help you with the implementation if
you want.
for now I am constraining myself to maintaining small bits to which I
have already
contributed (simu, sound, olethros-bot) and this is already much...
Bernhard Wymann wrote:
> Hi Jean-Philippe
>
>
>>>> Currently working on force feedback integration in Torcs,
>>>> I am very close to the moment when I'm able to inject some effects
>>>> into my wheel.
>>>>
>>> Since we already use the Pacejka formula, adding the aligning force is
>>> trivial. I hope that it works correctly.
>>>
>>> I guess I can export a couple of variables in some structure..
>>> How about
>>> struct SteeringFeedback {
>>> float align; // magnitude of the horizontal force
>>> float bump; // magnitude of the vertical force
>>> float bump_frequency; // in case the force updates are too slow
>>> };
>>>
>>> Now, there bumps may be a bit tricky. The simulation's dt is currently
>>> 0.002 if I remember correctly. I think that the control feedback is set
>>> to 0.01, though I could be wrong. In that case, you wouldn't need a
>>> bump_frequency, just a magnitude for the vertical forces and then how
>>> that is handled would depend on the actual feedback wheel used.
>>>
>> If I understand correctly (raceengine::ReUpdate/ReOneStep), the physics engine
>> call period can't be lower than 0.002s (RCM_MAX_DT_SIMU), and the human input
>> device read period can't be lower than 0.02 (RCM_MAX_DT_ROBOTS).
>> As I want to update feedback force in the device each time Torcs reads it
>> (it's easy to implement), this means that we can't render a vibration
>> due to a run on a -say - 0.5 m period kerb, if the speed of the car
>> is higher than 45 km/h (if Shannon is right ;-)
>> (2 * car speed (m/s) / bump period (m) < feedback force update frequency)
>>
>> Or 1m period kerb at 90 km/h ...
>>
>> It'a a bit poor I think (if I am correct).
>>
>> On the other hand, it seems that my wheel can't render periodic forces
>> under 50 or 40 ms period ... so, it may be poor, but the device can't do better.
>>
>> And of course the final question is : what a real car mechanical steering chain
>> can render, as far as high frequency vibrations are concerned ?
>> I don't know that ...
>>
>
> It does actually not matter, this is the wrong question, IMHO. The question is
> how far can human perception distinguish between right and wrong feedback, and
> how realistic is force feedback at all (I would guess you have no such or just
> little feedback on the steering wheel, what really gets the vibration is your
> whole back/body.
>
>
>> After some researches about force feedback over other racing cars simulation
>> games, I tried rFactor (and found it a dangerous competitor against Torcs (;-).
>> In rFactor, the aligning force injected to the steering wheel decreases
>> as the grip on the front wheels loose the grip (with some mysterious damping
>> formula) ... I don't know if this "effect" will already be in the "Magnitude
>> of the horizontal force" you would export from Torcs physics engine ...
>> but if not, it would also be very interesting to export some kind of grip value
>> on the front (=steering) wheels.
>>
>>
>>> I think I'll add the structure in interfaces/car.h and
>>> add it to the tPrivCar structure.
>>>
>> I can imagine you are very very very busy with family, work and many passions
>> (this is interesting life ;-) ... but could you give us an idea
>> of when you could be able to release such a patch ?
>> Or if not, could you find some time to give us enough tips about simuV2/V3
>> to enable us to try and achieve it ourselves ?
>>
>
> Ok, to keep it short, I am not interested at all in force feedback for TORCS
> currently, I think somebody would first better invest time to integrate a
> portable force feedback API into SDL (look at the README for "my" priorities).
> Here quickly the reasons:
> - If you want "this" kind of simulation go to the shop and buy RFactor, Race07,
> GTR XX or whatever.
> - The "unique selling proposition" of TORCS is its simplicity, portability,
> performance and stability. Because it is small a developer can quickly dig into
> the sources and achieve its customization (e.g. for a certain type of research,
> just for fun, whatever).
> - I have seen lots of people which hooked in an left, so the TORCS core has to
> stay small to be maintained over the long run, almost nobody is able or willing
> to do the "dirty work" (e.g. look at Trigger, it is nice but nobody takes
> currently care of it, IIRC).
> - Regarding force feedback: I bet the ordinary TORCS user has no steering wheel
> at all, so the feature is mainly a mainteinance burden with almost no benefit.
>
> If you do not agree with this, you are of course free to create/distribute your
> own fork/patch of TORCS.
>
> Bernhard
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Torcs-devel mailing list
> Torcs-devel@...
> https://lists.sourceforge.net/lists/listinfo/torcs-devel
>
|