HID device calibration - how to override mapping?

HID device calibration - how to override mapping?

[Enrico Mattea]

Hello all,

I have a HID device (racing pedals) and a problem with it.

In short, one of the three axes of the device (the clutch pedal) sends 
raw values differently from the other two; in the sense that gas and 
brake pedal return +32767 to 0 to -32767 (from released to halfway to 
fully pressed), while the clutch pedal sends 0 to -32767 to +32767 to 0 
(from released (0) to halfway (-32767), then the value jumps to +32767, 
then decreases again to 0 when fully pressed).

This obviously makes it impossible to properly calibrate the axis for 
anything, because of the "jump" at halfway and of the equality of min 
and max returned values.

As nobody seems to be complaining about this anywhere, I think that the 
(windows only) pedals' driver acts on the clutch value in some way at 
kernel level, "interpreting" it correctly.

So please, is there a way to do something similar - what I'm thinking 
about is remapping the values (at HID kernel driver level) - so that the 
values are interpreted correctly by the kernel?

Thank you very much in advance,
Ocirne

Re: HID device calibration - how to override mapping?

[el es]

Enrico Mattea <ocirne94 <at> gmail.com> writes:
(sorry for excessive trimmings, but gmane web i/f made me do it)

> 
> Hello all,
> [...]

> [...] while the clutch pedal sends 0 to -32767 to +32767 to 0 
> (from released (0) to halfway (-32767), then the value jumps to +32767, 
> then decreases again to 0 when fully pressed).

released - halfway - pressed
0 - (-32767) <-> (32767) - 0
but does it happen in reverse order when releasing pedal ?

seems the interpretation of this is up to the application really,
but /if/ the -32767 to 32767 change happens all around the 'halfway'
spot, maybe it is (in the app. engine) interpreted as 'change'
and it's effect applied to 'car engine' not directly, but integrated 
(time-integral function applied) first ? 
(or if it is the /change/ here that matters , it actually
is a /time-derivative/ that actually applies to the simulation?)

> 
> This obviously makes it impossible to properly calibrate the axis for 
> anything, because of the "jump" at halfway and of the equality of min 
> and max returned values.

I'd say, for the clutch simulation it's the /change-in-time/ that 
matters, not the /exact/ value; so no 'static' calibration is
ever going to be relevant (bar maybe the device telling us when the
pedal is fully pressed or fully released - in case app is not tracking
it)

> 
[...]
> Thank you very much in advance,
> Ocirne
> 
el es

Re: HID device calibration - how to override mapping?

[Enrico Mattea]

[-- Attachment #1: Type: text/plain, Size: 1522 bytes --]

Hi el es, thank you for your answer.

Il 13/01/2012 18:09, el es ha scritto:
>
> released - halfway - pressed
> 0 - (-32767)<->  (32767) - 0
> but does it happen in reverse order when releasing pedal ?

Yes, it does - perfect reverse order.
> seems the interpretation of this is up to the application really,
> but /if/ the -32767 to 32767 change happens all around the 'halfway'
> spot, maybe it is (in the app. engine) interpreted as 'change'
> and it's effect applied to 'car engine' not directly, but integrated
> (time-integral function applied) first ?
I don't think that the change is interpreted, because the clutch value 
seems to be computed directly, i.e. applying the app. calibration value 
on the the axis value received from the kernel;
even if I'm not completely familiar with the app.'s code, the attached 
code snippet is the interested part of the clutch handler of the app, 
and it doesn't seem to have any other function applied.
> I'd say, for the clutch simulation it's the /change-in-time/ that
> matters, not the /exact/ value; so no 'static' calibration is
> ever going to be relevant (bar maybe the device telling us when the
> pedal is fully pressed or fully released - in case app is not tracking
> it)
I agree, but trying to calibrate the axis produces the 'jump' effect 
also on the clutch value, so that either the first half of the axis 
isn't taken into account, or it produces full clutch already at halfway, 
and then value 0 after the halfway spot.

Thank you for your support,
Ocirne

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: clutch.cpp --]
[-- Type: text/x-c++src; name="clutch.cpp", Size: 431 bytes --]

		case GFCTRL_TYPE_JOY_AXIS:
			clutch = joyInfo->ax[cmd[CMD_CLUTCH].val];
			if (clutch > cmd[CMD_CLUTCH].max) {
				clutch = cmd[CMD_CLUTCH].max;
			} else if (clutch < cmd[CMD_CLUTCH].min) {
				clutch = cmd[CMD_CLUTCH].min;
			}
			car->_clutchCmd = fabs(cmd[CMD_CLUTCH].pow *
						pow(fabs((clutch - cmd[CMD_CLUTCH].minVal) /
							(cmd[CMD_CLUTCH].max - cmd[CMD_CLUTCH].min)),
						1.0f / cmd[CMD_CLUTCH].sens));
			break;

Re: HID device calibration - how to override mapping?

[Tigran]

Enrico Mattea <ocirne94 <at> gmail.com> writes:

> 
> Hi el es, thank you for your answer.
> 
> Il 13/01/2012 18:09, el es ha scritto:
> >
> > released - halfway - pressed
> > 0 - (-32767)<->  (32767) - 0
> > but does it happen in reverse order when releasing pedal ?
> 
> Yes, it does - perfect reverse order.
> > seems the interpretation of this is up to the application really,
> > but /if/ the -32767 to 32767 change happens all around the 'halfway'
> > spot, maybe it is (in the app. engine) interpreted as 'change'
> > and it's effect applied to 'car engine' not directly, but integrated
> > (time-integral function applied) first ?
> I don't think that the change is interpreted, because the clutch value 
> seems to be computed directly, i.e. applying the app. calibration value 
> on the the axis value received from the kernel;
> even if I'm not completely familiar with the app.'s code, the attached 
> code snippet is the interested part of the clutch handler of the app, 
> and it doesn't seem to have any other function applied.
> > I'd say, for the clutch simulation it's the /change-in-time/ that
> > matters, not the /exact/ value; so no 'static' calibration is
> > ever going to be relevant (bar maybe the device telling us when the
> > pedal is fully pressed or fully released - in case app is not tracking
> > it)
> I agree, but trying to calibrate the axis produces the 'jump' effect 
> also on the clutch value, so that either the first half of the axis 
> isn't taken into account, or it produces full clutch already at halfway, 
> and then value 0 after the halfway spot.
> 
> Thank you for your support,
> Ocirne
> 
> Attachment (clutch.cpp): text/x-c++src, 431 bytes

Hi, 

Do you try to make work your pedal with torcs or speed dreams?
Looks like yes... 
I had the same issue with fanatec porche 911 gt2.

I contacted HID driver maintainer, but since for now we don't have a proper
solution (i.e. fixing HID driver), I had to do a dirty thing in the source code.

Replace the fragment you attached in drivers/human/human.cpp with

        switch (cmd[CMD_CLUTCH].type) {
                case GFCTRL_TYPE_JOY_AXIS:
                        clutch = joyInfo->ax[cmd[CMD_CLUTCH].val];

                        // dirty stuff, sorry
                        if (clutch  <= 0) clutch = -clutch;
                        else clutch = 2.0 - clutch;
                        clutch /= 2.0;
                        car->_clutchCmd = fabs(cmd[CMD_CLUTCH].pow *
                                                pow(fabs(clutch),
                                                1.0f / cmd[CMD_CLUTCH].sens));
                        break;

and it should work... without calibration

Regards,
Tigran