shoulder buttons as axis on PS3 controller

[anomaly]

Hi,

I noticed some people talking about putting the yaw axis on the trigger buttons and the .json config to do so - however I can't seem to get this working. I'm using the latest pc client from the mercurial tip, xf86-input-joystick v1.6.2, latest firmware and kernel 3.7.10. Everything else seems to work fine however I can't get the triggers doing anything as analogue axes (as digital buttons OK, but not useful for yaw since they toggle). Within KDE's input control panel I can actually see the analogue events from the trigger buttons and they are working, just for whatever reason the pc client is doing nothing with them ("type": "Input.AXIS","ids": [12,13] in the json config).

Anyone have any thoughts on how to fix this? Is this a known problem at the moment? I also tried phiamo's fork of the client to check out hover mode but had the same problem with being unable to assign anything involving 'combined axes' or buttons as analogue inputs in general.

[marcus]

Hi,

I've been trying the pull-request (for the UI) and I haven't been able to get it to work fully. I haven't been able to get the reading code for the split axis to work either. I can read the buttons and configure them but the reading is wrong. Anyone tried this on Windows? Is there any difference?

/Marcus

[anomaly]

Thanks for getting back to me Marcus. On windows I achieved this using betterds3 and emulating the xbox360 controller and manually mapping them to an axis. Obviously with this setup though the betterds3 mapping is doing all the hard work.

I tried dumping controller events picked up by pygame on linux and saw that it is only seeing the digital boolean button events not the analogue events on the triggers. Since KDE's input control panel is showing both kinds of event when triggers are pressed, my guess is xf86-input-joystick and the hid-sony kernel module are both OK but pygame itself is dropping the analogue events. I'll do some tinkering with pygame when I have time to see if it can be told to acknowledge the analogue events (or even both simultaneously). My knowledge of pygame is very limited though and doesn't include input handling.

Also it should be noted that the main reason I can't just settle on using the Windows approach for this is because I found the radio drops out far, far too often. Like once every 60 seconds, causing the client to d/c and the crazyflie to drop out of the air. On Linux though I can keep it flying for a full battery charge without a single disconnect

[marcus]

I haven't had time to look at this further but from what I remember I found two problems:

First the axis for the L2/R2 buttons are in the range +1 to -1. So this would need special compensation since not pressing the button gives +1 and pressing it fully gives -1 (or maybe it was the other way around...). Using only the scale wouldn't work.

Secondly the current implementation will read one event, find out what "high-level" axis (roll/pitch/yaw/thrust) it maps to and calculate a new value (not taking the previous value into consideration). So if you map two ids (L2/R2) to the same "high-level" axis there will be a problem when reading events from both at the same time. So if your R2 button has id=13 and L2 has id=12 then if R2 is a bit glitchy it will always overwrite the yaw value when it sends an event.

But maybe I'm missing something since Philipp (that did the changes) has gotten it to work.

The latest pull-request for the UI configuration: The UI works really well, it's just the reading that I can't get to work
The initial split axis commit

Also it should be noted that the main reason I can't just settle on using the Windows approach for this is because I found the radio drops out far, far too often. Like once every 60 seconds, causing the client to d/c and the crazyflie to drop out of the air. On Linux though I can keep it flying for a full battery charge without a single disconnect

Do you get the message "Too many packets lost" or does the thrust just go to zero all of a sudden?

/Marcus

[anomaly]

First the axis for the L2/R2 buttons are in the range +1 to -1. So this would need special compensation since not pressing the button gives +1 and pressing it fully gives -1 (or maybe it was the other way around...). Using only the scale wouldn't work.

In the KDE control panel I see values between -32768 to +32767 in the 'analogue' section when applying pressure to the trigger buttons, same as the sticks. If the app is only receiving +/-1 I think this is pygame only passing the 'digital' event.

Do you get the message "Too many packets lost" or does the thrust just go to zero all of a sudden?

I get 'too many packets lost' and the client disconnects. Doesn't happen under Linux though when using the same channel (same channels for wifi in use too on the same hardware)

[marcus]

In the KDE control panel I see values between -32768 to +32767 in the 'analogue' section when applying pressure to the trigger buttons, same as the sticks. If the app is only receiving +/-1 I think this is pygame only passing the 'digital' event.

I think that SDL normalizes the values so all analog axis coming out from PyGame (that uses SDL) are in the range +1 to -1.

I get 'too many packets lost' and the client disconnects. Doesn't happen under Linux though when using the same channel (same channels for wifi in use too on the same hardware)

Hmm, this should be investigated. I've created a new issue for it.

[anomaly]

I think that SDL normalizes the values so all analog axis coming out from PyGame (that uses SDL) are in the range +1 to -1.

Ah ok. I should have the weekend free to investigate. I was hoping to have time tonight but I got kept back at the office for some after-hours server hardware upgrades.

Hmm, this should be investigated. I've created a new issue for it.

Cool, thanks. Let me know what I need to do to get some useful information for you on this. I'll sign up for a bitbucket account so I can comment on the ticket