T3.6 USB Host - Bluetooth

Good you got one that works - and pretty color button labels - mine are boring white graphics.

Bummer on the other controllers - and Kurt ordered one - though it may be fixable.
What you see may be what Mine did at first until Kurt relaxed the name test?

With Serial1 Active and connected and DEBUG enabled I see this string when it connects:
Event: handle_hci_remote_name_complete(0)
Remote Name: PLAYSTATION(R)3Conteroller-PANHAI
BluetoothController::find_driver driver 1fff44f8
JoystickController::claim_bluetooth TRUE PS3 hack...
*** Claimed ***
HCI_OP_ACCEPT_CONN_REQ called (09 04 07 25 63 74 b5 39 03 00 )
Control callback (bluetooth): 0 : 9 4 7 25 63 74 b5 39 3 0

On USB it is on/off lower buttons … but on Bt a slow press of the button can print a number less than 255 when rumble activates - so the code is in there - assume it is the printed array list of values - but scrolls too fast when rumbling as that also excites motion detect uless pinned down - this shows the increasing values - and I clipped the end of the reports after the right lower button:
Code:
Rumbling: 0, 150
ffffffff 1ffff:01 00 00 02 00 00 7f 7f 7f 7f 00 00 00 00 00 00 00 00 00 [COLOR="#FF0000"]9a 
[/COLOR]Rumbling: 0, 154
ffffffff 1ffff:01 00 00 02 00 00 7f 7f 7f 7f 00 00 00 00 00 00 00 00 00 [COLOR="#FF0000"]9c 
[/COLOR]Rumbling: 0, 156
ffffffff 1ffff:01 00 00 02 00 00 7f 7f 7f 7f 00 00 00 00 00 00 00 00 00 9f 
Rumbling: 0, 159
ffffffff 1ffff:01 00 00 02 00 00 7f 7f 7f 7f 00 00 00 00 00 00 00 00 00 a2 
Rumbling: 0, 162
ffffffff 1ffff:01 00 00 02 00 00 7f 7f 7f 7f 00 00 00 00 00 00 00 00 00 a5 
Rumbling: 0, 165
ffffffff 1ffff:01 00 00 02 00 00 7f 7f 7f 7f 00 00 00 00 00 00 00 00 00 a8 
Rumbling: 0, 168
ffffffff 1ffff:01 00 00 02 00 00 7f 7f 7f 7f 00 00 00 00 00 00 00 00 00 ac 
Rumbling: 0, 172
ffffffff 1ffff:01 00 00 02 00 00 7f 7f 7f 7f 00 00 00 00 00 00 00 00 00 b1 
Rumbling: 0, 177
ffffffff 1ffff:01 00 00 02 00 00 7f 7f 7f 7f 00 00 00 00 00 00 00 00 00 c7 
Rumbling: 0, 199
ffffffff 1ffff:01 00 00 02 00 00 7f 7f 7f 7f 00 00 00 00 00 00 00 00 00 d7 
Rumbling: 0, 215
ffffffff 1ffff:01 00 00 02 00 00 7f 7f 7f 7f 00 00 00 00 00 00 00 00 00 eb 
Rumbling: 0, 235
ffffffff 1ffff:01 00 00 02 00 00 7f 7f 7f 7f 00 00 00 00 00 00 00 00 00 f1 
Rumbling: 0, 241
ffffffff 1ffff:01 00 00 02 00 00 7f 7f 7f 7f 00 00 00 00 00 00 00 00 00 f6 
Rumbling: 0, 246
ffffffff 1ffff:01 00 00 02 00 00 7f 7f 7f 7f 00 00 00 00 00 00 00 00 00 fa 
Rumbling: 0, 250
ffffffff 1ffff:01 00 00 02 00 00 7f 7f 7f 7f 00 00 00 00 00 00 00 00 00 ff 
Rumbling: 0, 255
ffffffff 1ffff:01 00 00 02 00 00 7f 7f 7f 7f 00 00 00 00 00 00 00 00 00 ff 
ffffffff 1ffff:01 00 00 02 00 00 7f 7f 7f 7f 00 00 00 00 00 00 00 00 00 ff
 
Hi Mike and Tim,

With the PS3 and actually USB connections, the data is process as HID data, and processed very differently.

That is for example the buttons information is encoded into a special way (bit fields), which we process and it DOES Not go into Axis array, but you retrieve by calling:
getButtons() and then the actual axis values are stored... So I/we need to know it is PS3 or like and hopefully just map the appropriate fields into the buttons variable...

And then figure out if all of the Axis data is offset differentllly. I know that the rumble appears to be in the same places, but I don't think everything else is...

More soon. (or maybe another day ;) )
 
Tim - Kurt

I know the data is there just have to dig it out. I was just going through sony.c link driver and the HS2 code but my head is kind of spinning and eyes tired - like you said tomorrow is another day.

Will start taking a look at mapping tomorrow. Have to fix something else up tomorrow on PS4 code side as well. :)

@defragster

Just checked - my controller is now identified just as yours is:
Code:
BT rx_data(1): 0 
    Event: handle_hci_remote_name_complete(0)
    Remote Name: PLAYSTATION(R)3Conteroller-PANHAI
BluetoothController::find_driver  driver 1fff44f8
JoystickController::claim_bluetooth TRUE PS3 hack...
 
Just posted on T4b thread - my ILI9488's work! Touch is busted - going to go look at that next.

Hmmm … FrankB's T3tris on a T4/T_3.6 with Bluetooth Joystick (or keyboard) . . . on ILI9488
 
Hi Mike and Tim,

With the PS3 and actually USB connections, the data is process as HID data, and processed very differently.

That is for example the buttons information is encoded into a special way (bit fields), which we process and it DOES Not go into Axis array, but you retrieve by calling:
getButtons() and then the actual axis values are stored... So I/we need to know it is PS3 or like and hopefully just map the appropriate fields into the buttons variable...

And then figure out if all of the Axis data is offset differentllly. I know that the rumble appears to be in the same places, but I don't think everything else is...

More soon. (or maybe another day ;) )

Not sure you have to call buttons to get the axis data. In the function JoystickController::process_bluetooth_HID_data there is a small block where you are printing a block of 50 bytes, never noticed this before or if you just added it but the watching the data as I press buttons I noticed that each button has it own byte (pressed or not pressed).

Code:
JoystickController::process_bluetooth_HID_data
01 00 00 00 00 00 7f 7f 7f 7f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 04 14 00 00 00 00 23 6d 77 01 1e 01 fc 01 f4 01 7c 02 00 00
 
Good early morning:
I don't know the PS4 data output as well as the PS3... But probably similar stuff:

With the PS3 (and earlier PS2), the buttons shows up as a two byte mask of which button is pressed. But in addition to these, many of the buttons also have an axis associated with them, such that you can semi sense how hard the button is being pressed. When I played with them, you maybe got about 4ish ranges of values for this.

You can find some information about some of this up at different places like ROS:
http://wiki.ros.org/ps3joy
 
PS3 quick update on Data:

Currently with my hacked up code, I have updated the RAW print out, to allow R3 button to be pressed and then goes to only show changed data, which makes it easier to see indexes...

With USB output of PS3: The Axis look sort of like:
0-LH, 1-LV, 2-RH, 5-RV (Yes gap) - Starting at 14 we have: Hat-up, right, down, left, L2, R2, L1, R1, TRI, CIR, X, Square

Note: Gap is probably where buttons was.. Or bug

Actually it is USB HID Joystick encoding funkyness: If you look at: https://www.microchip.com/forums/m989340.aspx Or do a dump of the descriptors using linux, you will see something like:
Code:
0xA1,0x00,              //  COLLECTION (Physical)
          0x15,0x00,            //  LOGICAL_MINIMUM(0)
          0x26,0xFF,0XFF,       //  LOGICAL_MAXIMUM(1023) , 0x25 + size value
          0x35,0x00,              //  PHYSICAL_MINIMUM(0)
          0x46,0xFF,0xFF,       //  PHYSICAL_MAXIMUM(1023)
          0x09,0x30,            //  USAGE(AN1)X
          0x09,0x31,            //  USAGE(AN2)Y
          0x09,0x32,            //  USAGE(AN3)Z
          0x09,0x33,            //  USAGE(AN4)Rx
          0x09,0x34,            //  USAGE(AN4)Ry
        0x09,0x35,            //  USAGE(AN4)Rz
Note the IDs in the 0x30 range are the important ones. And PS3 and probably PS4...
Have X -> LH, Y->LV, Z->RH We don't have Rx or rY, LV ->Rz So the gap...


Now with Bluetooth Somewhat similar except:
0 is always 1
2-3: are the buttons.

6-LH, 7-LV, 8-RH, 9-RV And then the pressures >=14 match the USB data.

EDIT: Forgot to mention that lots more details about the USB Hid descriptors and the like, can be found in the USB specs like:
https://www.usb.org/sites/default/files/documents/hut1_12v2.pdf

From that document:
Code:
30                         X                         DV                         4.2  
31                         Y                         DV                         4.2  
32                         Z                         DV                         4.2  
33                         Rx                         DV                         4.2  
34                         Ry                         DV                         4.2  
35                         Rz                         DV                         4.2  
36                         Slider                         DV                         4.3  
37                         Dial                         DV                         4.3  
38                         Wheel                         DV                         4.3  
39                         Hat                         switch                         DV                         4.3
Question is should the BT data match same order?
 
Last edited:
Good early morning:
I don't know the PS4 data output as well as the PS3... But probably similar stuff:

With the PS3 (and earlier PS2), the buttons shows up as a two byte mask of which button is pressed. But in addition to these, many of the buttons also have an axis associated with them, such that you can semi sense how hard the button is being pressed. When I played with them, you maybe got about 4ish ranges of values for this.

You can find some information about some of this up at different places like ROS:
http://wiki.ros.org/ps3joy

Morning Kurt
Sorry for not getting back to you sooner. Had to go out and shovel. We had about 4-5inches of snow last night and expecting another tonight. Argh.

Just going through both posts now and probably will play later. Have a couple more things to do now - I hate shoveling :)
 
@KurtE and @defragster

Kind of did my own mapping of buttons (hats are exactly where you got them so I did document that one) Here is what I got:
Code:
index 14 - up button, 10 in index 2 
index 15 pressed - right button, 20 in index 2
index 16 pressed  - down button, 40 in index 2
index 17 pressed - left button, 80 in index 2
NE - 30 in index 2
SE - 60 in index 2
SW - c0 in index 2
NW - 90 in index 


trig - val in index 3 (10), pressed index 22
Circ - 20 in index 3, pressed index 23
X    - 40 in index 3, pressed index 24
Sqr - 80 in index 3, pressed index 25

L1 - 04 in index 3, pressed variable val index 20
R1 - 08 in index 3, pressed varialble val index 21

L2 - 1 in index 3, val in index 18
R2 - 2 in index 3, val in index 19

Select - 1 in index 2
Start  - 8 in index 2
 
Hi again...

As I mentioned a lot of the details on what is where was done by how the data was encoded to match the HID data standards...

When I get a new device I often try to see what data is described for it, using some linux tools;
Example I did this for the previous PS4 controller, in the thread: https://forum.pjrc.com/threads/45740-USB-Host-Mouse-Driver?p=152935&viewfull=1#post152935

Where part of the information looks like:
Code:
kurt@kurt-UP-CHT01:~$ sudo usbhid-dump  -i0 | grep -v : | xxd -r -p | hidrd-convert -o spec
Usage Page (Desktop),               ; Generic desktop controls (01h)
Usage (Gamepad),                    ; Gamepad (05h, application collection)
Collection (Application),
    Report ID (1),
[COLOR="#FF0000"]    Usage (X),                      ; X (30h, dynamic value)
    Usage (Y),                      ; Y (31h, dynamic value)
    Usage (Z),                      ; Z (32h, dynamic value)
    Usage (Rz),                     ; Rz (35h, dynamic value)
    Logical Minimum (0),
    Logical Maximum (255),
    Report Size (8),
    Report Count (4),
    Input (Variable),[/COLOR]
    Usage (Hat Switch),             ; Hat switch (39h, dynamic value)
    Logical Minimum (0),
    Logical Maximum (7),
    Physical Minimum (0),
    Physical Maximum (315),
    Unit (Degrees),
    Report Size (4),
    Report Count (1),
    Input (Variable, Null State),
    Unit,
[COLOR="#006400"]    Usage Page (Button),            ; Button (09h)
    Usage Minimum (01h),
    Usage Maximum (0Eh),
    Logical Minimum (0),
    Logical Maximum (1),
    Report Size (1),
    Report Count (14),
    Input (Variable),[/COLOR]
    Usage Page (FF00h),             ; FF00h, vendor-defined
    Usage (20h),
    Report Size (6),
    Report Count (1),
    Logical Minimum (0),
    Logical Maximum (127),
    Input (Variable),
    Usage Page (Desktop),           ; Generic desktop controls (01h)
    Usage (Rx),                     ; Rx (33h, dynamic value)
    Usage (Ry),                     ; Ry (34h, dynamic value)
    Logical Minimum (0),
    Logical Maximum (255),
    Report Size (8),
    Report Count (2),
    Input (Variable),
    Usage Page (FF00h),             ; FF00h, vendor-defined
    Usage (21h),
    Report Count (54),
    Input (Variable),

Where the first part in RED shows those main standard 4 axis, 8 bit values.
The part in Green shows there are 14 buttons each 1 bit...

Also for what it is worth, if you configure a Teensy as a simple joystick, it's definition looks similar:
Code:
#if JOYSTICK_SIZE == 12
static uint8_t joystick_report_desc[] = {
        0x05, 0x01,                     // Usage Page (Generic Desktop)
        0x09, 0x04,                     // Usage (Joystick)
        0xA1, 0x01,                     // Collection (Application)
        0x15, 0x00,                     //   Logical Minimum (0)
        0x25, 0x01,                     //   Logical Maximum (1)
        0x75, 0x01,                     //   Report Size (1)
        0x95, 0x20,                     //   Report Count (32)
        0x05, 0x09,                     //   Usage Page (Button)
        0x19, 0x01,                     //   Usage Minimum (Button #1)
        0x29, 0x20,                     //   Usage Maximum (Button #32)
        0x81, 0x02,                     //   Input (variable,absolute)
        0x15, 0x00,                     //   Logical Minimum (0)
        0x25, 0x07,                     //   Logical Maximum (7)
        0x35, 0x00,                     //   Physical Minimum (0)
        0x46, 0x3B, 0x01,               //   Physical Maximum (315)
        0x75, 0x04,                     //   Report Size (4)
        0x95, 0x01,                     //   Report Count (1)
        0x65, 0x14,                     //   Unit (20)
        0x05, 0x01,                     //   Usage Page (Generic Desktop)
        0x09, 0x39,                     //   Usage (Hat switch)
        0x81, 0x42,                     //   Input (variable,absolute,null_state)
        0x05, 0x01,                     //   Usage Page (Generic Desktop)
        0x09, 0x01,                     //   Usage (Pointer)
        0xA1, 0x00,                     //   Collection ()
        0x15, 0x00,                     //     Logical Minimum (0)
        0x26, 0xFF, 0x03,               //     Logical Maximum (1023)
        0x75, 0x0A,                     //     Report Size (10)
        0x95, 0x04,                     //     Report Count (4)
        0x09, 0x30,                     //     Usage (X)
        0x09, 0x31,                     //     Usage (Y)
        0x09, 0x32,                     //     Usage (Z)
        0x09, 0x35,                     //     Usage (Rz)
        0x81, 0x02,                     //     Input (variable,absolute)
        0xC0,                           //   End Collection
        0x15, 0x00,                     //   Logical Minimum (0)
        0x26, 0xFF, 0x03,               //   Logical Maximum (1023)
        0x75, 0x0A,                     //   Report Size (10)
        0x95, 0x02,                     //   Report Count (2)
        0x09, 0x36,                     //   Usage (Slider)
        0x09, 0x36,                     //   Usage (Slider)
        0x81, 0x02,                     //   Input (variable,absolute)
        0xC0                            // End Collection
};
#elif JOYSTICK_SIZE == 64
 
@KurtE

Cool - thanks for the references - have to go through this thread again and make a list of them all so I can find them again :)

I saw all the usage tables all over but didn't know where they came from - figured it was for usb since they didn't seem to get called with the PS3 when I was watching the debug stream. All I was seeing was what I mentioned in post #309 and #305. The way I found it was by trying to trace where the data for the axis came from. I did notice that most of what you mentioned seemed to be associated with the XBOX controllers.

Anyway I mapped the PS3 to the same axis as the PS4 now. I am attaching your modified sketch and the modified joystick.cpp file where I did the mapping. Give it a try and let me know if you are seeing the same as I am. Beginning to wonder if different controllers are presenting themselves differently:
View attachment JoystickBTPS3.zip

View attachment joystick.zip

Now to go and take a few more advils. :)
 
Hi @mjs513 (and others),

Right now I am sort of torn on using part of your changes and part of mine...

That is with the Standard Axis (As defined by the Bluetooth HID stuff), things like I mentioned, that 0, 1, 2, 5 are the two joysticks, The buttons are not part of the axis data, That is for PS3, most if not all of the buttons are defined as bits in the current axis, that is currently I have:
Code:
		switch (joystickType) {
			case PS3: buttons = axis[2] | ((uint16_t)axis[3] << 8); break;
			default:
				break;
		}
I was checking to see if the buttons were the same between plugged in BT. I think I need to play with this a little more to get these correct.

Now if you wish to see a lot of data spew on this, try plugging in the PS3 or PS4 and have the debug output enabled in USBHost_T36.h file...

Most of the support code is actually in hid.cpp, (Paul did a lot of the inital stuff here), where we get a HID report, and the report descriptor, which the top level Hid code decodes and calls off to us (joystick.cpp), with each of the Hid fields (hid_input_begin, hid_input_data, hid_input_end),

As for seeing lots of XBox code... Well they were one who did not implement their joystick using HID, so we try to process differently.

So it is interesting to figure out a valid mapping, which works for both normal plugged in USB versus the Bluetooth version.
 
Hi @mjs513 (and others),

Right now I am sort of torn on using part of your changes and part of mine...

That is with the Standard Axis (As defined by the Bluetooth HID stuff), things like I mentioned, that 0, 1, 2, 5 are the two joysticks, The buttons are not part of the axis data, That is for PS3, most if not all of the buttons are defined as bits in the current axis, that is currently I have:
Code:
		switch (joystickType) {
			case PS3: buttons = axis[2] | ((uint16_t)axis[3] << 8); break;
			default:
				break;
		}
I was checking to see if the buttons were the same between plugged in BT. I think I need to play with this a little more to get these correct.

Now if you wish to see a lot of data spew on this, try plugging in the PS3 or PS4 and have the debug output enabled in USBHost_T36.h file...

Most of the support code is actually in hid.cpp, (Paul did a lot of the inital stuff here), where we get a HID report, and the report descriptor, which the top level Hid code decodes and calls off to us (joystick.cpp), with each of the Hid fields (hid_input_begin, hid_input_data, hid_input_end),

As for seeing lots of XBox code... Well they were one who did not implement their joystick using HID, so we try to process differently.

So it is interesting to figure out a valid mapping, which works for both normal plugged in USB versus the Bluetooth version.

Kurt and others

I just did a PR up to your repository, Sorry I can close it.

As for ownership and mapping, think that's up in the air - which ever works better, probably a combo. I was concentrating on the BT. I have a feeling though, that you not going to get much commonality between the way BT and USB wired devices work from what I have been looking at in the code bases so far.

As for the xbox controller I just tested mine again, and while it tried to connect it had a problem, didn't really look at too hard but here it is for reference:
Code:
Write_Scan_enable Completed
tedBT rx_data(12): 4 a e9 a7 db 1b aa 9c 8 5 0 1 
    Event: Incoming Connect -  e9:a7:db:1b:aa:9c CL:508 LT:1
      Peripheral device
        Gamepad
BluetoothController::find_driver  driver 1fff49d8
JoystickController::claim_bluetooth TRUE
    *** Claimed ***
HCI_OP_REMOTE_NAME_REQ called (19 04 0a e9 a7 db 1b aa 9c 01 00 00 00 )
    Control callback (bluetooth): 0 : 19 4 a e9 a7 db 1b aa 9c 1 0 0 0 
BT rx_data(6): f 4 0 1 19 4 
    Command 419 Status 0
BT rx_data(16): 7 ff 0 e9 a7 db 1b aa 9c 58 62 6f 78 20 57 69 
BT rx_data(16): 72 65 6c 65 73 73 20 43 6f 6e 74 72 6f 6c 6c 65 
BT rx_data(16): 72 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
BT rx_data(1): 0 
[COLOR="#FF0000"]    Event: handle_hci_remote_name_complete(0)
    Remote Name: Xbox Wireless Controller
  JoystickController::remoteNameComplete Xbox Wireless Controller - Unknown[/COLOR]
HCI_OP_ACCEPT_CONN_REQ called (09 04 07 e9 a7 db 1b aa 9c 00 )
    Control callback (bluetooth): 0 : 9 4 7 e9 a7 db 1b aa 9c 0 
BT rx_data(6): f 4 0 1 9 4 
    Command 409 Status 0
BT rx_data(10): 12 8 0 e9 a7 db 1b aa 9c 0 
BT rx_data(13): 3 b 0 b 0 e9 a7 db 1b aa 9c 1 0 
    Connection Complete - ST:0 LH:b
BT rx_data(5): 1b 3 b 0 5 
BT rx_data(8): 17 6 e9 a7 db 1b aa 9c 
    Event: Link Key Request e9:a7:db:1b:aa:9c
HCI_LINK_KEY_NEG_REPLY called (0c 04 06 e9 a7 db 1b aa 9c )
    Control callback (bluetooth): 120 : c 4 6 e9 a7 db 1b aa 9c 
BT rx_data(12): e a 1 c 4 0 e9 a7 db 1b aa 9c 
    Command Completed! 
d! BT rx_data(6): 5 4 0 b 0 15 
[COLOR="#FF0000"]    Event: HCI Disconnect complete(0): handle: b, reason:15[/COLOR]
:15
 
Hi @mjs513 (and others),

Right now I am sort of torn on using part of your changes and part of mine...

That is with the Standard Axis (As defined by the Bluetooth HID stuff), things like I mentioned, that 0, 1, 2, 5 are the two joysticks, The buttons are not part of the axis data, That is for PS3, most if not all of the buttons are defined as bits in the current axis, that is currently I have:
Code:
		switch (joystickType) {
			case PS3: buttons = axis[2] | ((uint16_t)axis[3] << 8); break;
			default:
				break;
		}
@KurtE and @defragster,

I don't think our button axis bits are too far off. Let me explain what I am seeing:
Code:
[COLOR="#800080"]you are combing axis[2] and axis[3] into a int16, I think that what that is telling me.  What I am seeing is:

axis[2] => bits for Select, Start and Arrow buttons
axis[3] => bits for the button values of (L1,R1, L2,R2) Triggers,  L1 and R1 buttons, and the circle, square, triangle and X.  

I am just not combing axis[2] and axis[3].  I am remapping them to match what I have been using for the PS4.[/COLOR]
 
Hi Mike, Again we may want to sort of map out how all of them do it and either map them or make it easy for the user to do so...

And how best to handle Bluetooth versus HID inputs).

Again I believe the PS4 plugged in gives us the Axis as mentioned (0, 1, 2, 5) are the joysticks...

Now as for Buttons, I have not done all of the work yet... But with PS3, I have:
Code:
			case PS3: buttons = axis[2] | ((uint16_t)axis[3] << 8) | ((uint32_t)axis[4] << 16); break;

And the buttons match for USB and Bluetooth... Would not be hard to fix the Axis to match in this case...

As for PS4 controller:

I am seeing: button(USB button value, Bluetooth Byte:val hex) PS3 val
tri(8, 5:88) 1000
cir(4, 5:84) 2000
X(2,5:28) 4000
sq(1,5:18) 8000
select? 1
Start (200, 6:20)
PS (? missed in notes) 10000
HAT no button pressed (NO, 5:8)
HAT up(No button, 5:0) 10
Right(NO, 5:2) 20
down(NO, 5:4) 40
Left(NO, 4:6) 80
L1(10,6:1) 400
L2(40, 6:4) 100
L3(400, 6:40) 2
R1(20, 6:2) 800
R2(80, 6:08) 200
R3(800, 6:80) 4

So my guess again is not hard to map bytes 5,6 in extended report into button value?
But the question is, is it worth then mapping it such that PS3 button value is the same as PS4 button value?
 
@KurtE

Think it's your call if you want USB and BT mapping to be equivalent to be honest. I'm just not sure if it is really necessary to match HID and BT. Just thought on that point it would be more consistent in matching BT to BT controller axis format.

As for buttons can go either way but like the idea to keep the values consistent on the BT side. I would just prefer not to deal with a combined button 32bit value. That's just me though.

So my guess again is not hard to map bytes 5,6 in extended report into button value?
But the question is, is it worth then mapping it such that PS3 button value is the same as PS4 button value?

Mapping is not difficult as long as we agree on the map. Again, just not sure it worth it - but then again it might be for interchangeability of controllers.

On your mapping, that is pretty much what I got except I didn't see the PS3 button value.

Just on a side not - wish others would jump in here and provide us some feedback.
 
Just on a side not - wish others would jump in here and provide us some feedback.

I totally agree with this! Sometimes hard to know what works well for others without having an idea of their usage patterns...

Earlier I tried creating a thread talking about USB HOST and joysticks: https://forum.pjrc.com/threads/49099-T3-6-USB-Host-Joysticks

As you might notice got very little feedback from this one either.

Think it's your call if you want USB and BT mapping to be equivalent to be honest. I'm just not sure if it is really necessary to match HID and BT. Just thought on that point it would be more consistent in matching BT to BT controller axis format.

As for buttons can go either way but like the idea to keep the values consistent on the BT side. I would just prefer not to deal with a combined button 32bit value. That's just me though.

From my own personal usage stuff, with PS3/PS4 controllers and Robots, I personally would like come consistency between USB and BT version of data like from the PS3. That was running them using Linux (ROS) and sometimes the binding would become real flaky and/or user error, I forgot to plug it in and the controller kept losing connection, so I might plug it in USB both to power it, but still wanted to test or play with robot...

BUT, I also like and would have liked the idea of the data being consistent between controllers. That is the developer of the ROS Hexapod code base (https://github.com/KevinOchs/hexapod_ros), used a PS3 with his robot, but a few of us were having issues with getting the PS3 to work so we tried a PS4, which is why I had the one that died. But his code base was tied to the PS3 mapping, with the old Linux Joystick stream.... The ROS node: http://wiki.ros.org/joy to handle this on the ROS side, they have another package: http://wiki.ros.org/joystick_remapper
which was a python programmer, that took in one ROS message and remapped the keys into a new ROS message. So you would use this to intercept the messages before it was given to the program wanting the keyboard data and translate it... It sort of worked, but I hated it on the RPI as some simple Python function like this would eat a ton of CPU.....

Also hard to know what people want and needs. For example I think that you with the PS4, want it all, including all of the internal sensors like tilt... Where I may simply need the more basic things like the two joysticks and the buttons, including the L2/R2 ones that work analog...

So then the question is how much control to allow user to have to control how much data gets transferred...

Mapping is not difficult as long as we agree on the map. Again, just not sure it worth it - but then again it might be for interchangeability of controllers.

On your mapping, that is pretty much what I got except I didn't see the PS3 button value.
That is where axis[4] came in...

case PS3: buttons = axis[2] | ((uint16_t)axis[3] << 8) | ((uint32_t)axis[4] << 16); break;

Again my thoughts on mapping were to at least try to be consistent on the controller with the buttons between BT and USB... Although in PS4 case not sure if you would like it augmented by having the HAT information which is not included in their buttons on USB.

That maybe we try to preserve the Axis to be consistent for the first 10 elements to sort of follow the USB HID standard, but...

But that does not make this right or the best for different users... So again I don't know what is the proper thing to do.

Will be interesting to see how the XBox One data works with this.
 
@mjs513 and @defragster and others - Not sure if maybe asking for feedback in the Joystick thread might help?

Hopefully there is a simple solution, that makes us all happy.

Left to my own bad API stuff, I would probably end up with a kludge, that maybe did something like:

For Axes - Have two functions, could either be something like: getAxis and getRawAxis (axis, rawAxis) or getAxis and getMappedAxis(axis, rawAxis) - again I personally would like to get rid of the word get...

Where, then we could do something like: axis(AXIS_LX)
And it would know which controller is currently connected (use a static table to then find the raw index, and return that value). The user can still use the raw function to get the raw data to process a slight bit quicker...


Likewise for buttons, getButtons() still gives you the raw data probably 32 bits...could create a few helper functions, like:
button(is the logical button down)
buttonPressed(did the user just press it)
buttonReleased(did the user just release it)

With some of these, not sure if I would pass in the data from buttons and/or previous logical state of buttons (or if member call) is there to remember previous state, but then you could
then do something like: if (joystick1.buttonPressed(BUTTON_CROSS)) ...
And it hopefully works with all of the joysticks that we know...

But again this is probably all of a kludge... Also if we would to do something like this, again not sure how how best to pass in things like AXIS_LX,

Should they be just like that, and some #define or enum()...

Or part of JoystickController class? JoystickController::AXIS_LX or part of some name space like JOYSTICK_AXIS? So then something like: JOYSTICK_AXIS::LX
Obviously some thing for logical buttons?

But I know this is probably not the cleanest or most eloquent solution...
 
KurtE said:
That maybe we try to preserve the Axis to be consistent for the first 10 elements to sort of follow the USB HID standard

Think that the basic axis mapping (fist 10) should be consistent. When I using the controllers I was mainly using the Hats and triggers. But I can think of uses for the arrows and the other tri/sqr/circ/X buttons as well.
 
@KurtE and @defragster and others

Think before we start adding api calls we need to settle on the axes mappings and button values. If we do that then it will make the API simpler. If not we are going to wind up with a lot of getCalls for the buttons and axes.

Have a few ideas but we need to get the axes set first I think.

Would like to see what the XBOX BT values look like first then we will have the three controllers covered.

Oh, tried hooking the xbox controller wired but didn't get any spew from the HID stuff (yes I uncommented the debug statements in USBHost_t36);
 
@KurtE and @defragster and others

Think before we start adding api calls we need to settle on the axes mappings and button values. If we do that then it will make the API simpler. If not we are going to wind up with a lot of getCalls for the buttons and axes.

Have a few ideas but we need to get the axes set first I think.

Would like to see what the XBOX BT values look like first then we will have the three controllers covered.

Oh, tried hooking the xbox controller wired but didn't get any spew from the HID stuff (yes I uncommented the debug statements in USBHost_t36);

Yep - XBox did not implement HID stuff, so the code to handle it is directly in the Joystick.cpp:
functions like: the top level ::claim function, looks at things, like maybe the vid:pid...
And then gets the data on: ::rx_data

Where you will see that I was mapping the order of the data: static const uint8_t xbox_axis_order_mapping[] = {4, 5, 0, 1, 2, 3};

Again will be interesting to see what the Bluetooth stuff comes in as.

Mike I agree. It is an interesting question on what makes more sense, mapping the data when it is received, or if/when the user asks for it.

As for extra button functions, sometimes it is nice to have some of the ones anyway... Example
My version of JoystickBT.ino has in it stuff like:
Code:
  if ((buttons & 0x02) && !(buttons_prev & 0x02)) show_raw_data = !show_raw_data;
  if ((buttons & 0x04) && !(buttons_prev & 0x04)) show_changed_data = !show_changed_data;

Might look nicer and easier to read if you had something like:
Code:
  if (joystick1.buttonPressed(BUTTON_L3)) show_raw_data = !show_raw_data;
  if (joystick1.buttonPressed(BUTTON_R3)) show_changed_data = !show_changed_data;
But semi independent if the buttonPressed function maps the R3 or is hard coded to some specific bit.

Again more background... As I mentioned so far I have only used PS3/PS4 type controllers on later robots. Before that I used to use a lot of PS2 controllers on robots, by Lynxmotion (now part of RobotShop)... With the PS2, I used to use the Arduino library: https://github.com/madsci1016/Arduino-PS2X... Two reasons that came to mind (It also had functions to ask if a button was pressed another for released...). And last night I got a PM from the RobotShop forum with someone asking about an old Lynxmotion Robot and mentioned the PS2 library...
 
@KurtE

Would be nice have functions like getButtonPressed(CIRC) or getButtonPressed(UP), etc. But what I was thinking was that if things were consistently in the same location (i.e. axis index, axis[2] say for buttons) we could use single functions for getting the data back instead of constantly doing conversions or have case statement for controllers in the functions.

Just a thought.

Mike
 
@KurtE;


Would be nice have functions like getButtonPressed(CIRC) or getButtonPressed(UP), etc. But what I was thinking was that if things were consistently in the same location (i.e. axis index, axis[2] say for buttons) we could use single functions for getting the data back instead of constantly doing conversions or have case statement for controllers in the functions.
I would be very happy with that as well, especially if it same for both USB and BT...

But if they needed mapping, I would try to implement it somewhat like:
Code:
bool JoystickController::getButtonPressed(int button_index) {
    if (button_index >= current_button_mask_table_size_) return false; 
    return (buttons_ & current_button_mask_table[button_index]) &&  !(buttons_prev_ & current_button_mask_table[button_index])
}
Again something similar for axis... If I went that way, would probably have a mapping class that had both, but...

All wait to see what you come up with.

Currently playing with other stuff, like trying to get name on pair.

And probably more interesting would be to get PS3 pairing in place
 
Not having used joysticks much before learning one simple interface that was agnostic to the device would be best in my case. And nobody has used Bt USBHost T_3.6/T$ joysticks.

With minor differences - AFAIK - modern joysticks have the same core input signals/capabilities. Getting the xBox1 will confirm how true that is - and which ones are missing for mapping. Having USB/HID blend seamlessly where possible would be an important part of that.

So creating one uniform and complete set of api functions makes end user code clean and consistent in the case of alternate controllers or connect methods when say charging the battery or using USB cable in certain environments.

Ideally the MCU performance will make the translation and detect of changed input fast - faster than the end user might accomplish if trying to handle more than one device for sure.

Maybe having a Class::RawDevice and Class::MappedJoystick that is a friend of the Raw?
 
Back
Top