HID device calibration - how to override mapping?

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

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

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?)

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)

[...]

el es

Hi el es, thank you for your answer.

Il 13/01/2012 18:09, el es ha scritto:

Yes, it does - perfect reverse order.

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 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

		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;

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