Forum Rule: Always post complete source code & details to reproduce any issue!
Page 13 of 20 FirstFirst ... 3 11 12 13 14 15 ... LastLast
Results 301 to 325 of 480

Thread: T3.6 USB Host - Bluetooth

  1. #301
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    7,839
    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 9a 
    Rumbling: 0, 154
    ffffffff 1ffff:01 00 00 02 00 00 7f 7f 7f 7f 00 00 00 00 00 00 00 00 00 9c 
    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

  2. #302
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,205
    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 )

  3. #303
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,697
    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...

  4. #304
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    7,839
    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

  5. #305
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,697
    Quote Originally Posted by KurtE View Post
    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:rocess_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

  6. #306
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,205
    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

  7. #307
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,205
    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/fi.../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 by KurtE; 03-02-2019 at 02:20 PM.

  8. #308
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,697
    Quote Originally Posted by KurtE View Post
    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

  9. #309
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,697
    @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

  10. #310
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,205
    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...l=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),
        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),
        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,
        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),
        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

  11. #311
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,697
    @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:
    JoystickBTPS3.zip

    joystick.zip

    Now to go and take a few more advils.

  12. #312
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,205
    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.

  13. #313
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,697
    Quote Originally Posted by KurtE View Post
    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 
        Event: handle_hci_remote_name_complete(0)
        Remote Name: Xbox Wireless Controller
      JoystickController::remoteNameComplete Xbox Wireless Controller - Unknown
    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 
        Event: HCI Disconnect complete(0): handle: b, reason:15
    :15

  14. #314
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,697
    Quote Originally Posted by KurtE View Post
    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:
    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.

  15. #315
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,205
    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?

  16. #316
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,697
    @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.

  17. #317
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,205
    Quote Originally Posted by mjs513 View Post
    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...Host-Joysticks

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

    Quote Originally Posted by mjs513 View Post
    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...

    Quote Originally Posted by mjs513 View Post
    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.

  18. #318
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,205
    @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...

  19. #319
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,697
    Quote Originally Posted by KurtE
    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.

  20. #320
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,697
    @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);

  21. #321
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,205
    Quote Originally Posted by mjs513 View Post
    @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 vidid...
    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...

  22. #322
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,697
    @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

  23. #323
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,205
    Quote Originally Posted by mjs513 View Post
    @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

  24. #324
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,697
    @KurtE

    You know we could just create a common structure to hold the data?

  25. #325
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    7,839
    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?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •