Reliable way to detect disconnected controller

[heydowns]

We've been using the chicklet with great success for two different controllers.

We recently moved into using enough buttons that using the "digital buttons mapped into an analog channel" feature was necessary (> 4 buttons).

When programming to this, it became apparent that there wasn't an easy and reliable way to tell if the values you were decoding were actually the button presses versus "junk" when the controller is unplugged.

This stems from the fact that the OI puts analog channels at 127 when disconnected (this appears as button 1 always pressed). Likewise in autonomous.

With the chicklet connected, but the controller/peripheral disconnected, the value hovers around 126, 127, 128. In software this, of course, looks like alternating presses of button 1 and buttons 2, 3, 4 together.

Now... is this a big deal? Not really, but it is something to be aware of if you use the "digital buttons in an analog space" for potentially hazardous robot controls (drive train go really fast, for example). We've had cases where robot is on and enabled and a controller is loose/unplugged in the past.

Anyone come up with creative ways to detect if the controller is actually present?

[Mike Copioli]

Originally Posted by heydowns

We've been using the chicklet with great success for two different controllers.

We recently moved into using enough buttons that using the "digital buttons mapped into an analog channel" feature was necessary (> 4 buttons).

When programming to this, it became apparent that there wasn't an easy and reliable way to tell if the values you were decoding were actually the button presses versus "junk" when the controller is unplugged.

This stems from the fact that the OI puts analog channels at 127 when disconnected (this appears as button 1 always pressed). Likewise in autonomous.

With the chicklet connected, but the controller/peripheral disconnected, the value hovers around 126, 127, 128. In software this, of course, looks like alternating presses of button 1 and buttons 2, 3, 4 together.

Now... is this a big deal? Not really, but it is something to be aware of if you use the "digital buttons in an analog space" for potentially hazardous robot controls (drive train go really fast, for example). We've had cases where robot is on and enabled and a controller is loose/unplugged in the past.

Anyone come up with creative ways to detect if the controller is actually present?

You are correct. This will always be an issue when using the analog pins for digital data. The best approach is to ensure that your device is properly connected an has detected and connected your gamepad/joystick (green LED) Even with these precautions in place, a joystick can still be accidentally disconnected during match play. My advice is to not attach any dangerous or irreversible functionality such as ramp/lift deployment, to the high bit.

[Mike Copioli]

Ok, I have an update for you. There is a way to detect if the device is disconnected. .

Ok, The Chicklet stuffs digital data in the following format:

Only the High nibble is to be used, the lower nibble is assumed to be garbage. The MSB of the LOW Nibble is set (1). This is to create an allowable range of values.

ex:

1111 1000 = 248
1111 0000 = 240 this case should not occur due to the high bit of the low nibble being set.
1111 1111 = 255

When the user reads the high nibble, the value can be any where within that range of decimal values and still be valid.

The Chicklet uses inverted logic. So when no buttons are pressed we will see the following binary value:

1111 1000 = 248(decimal)

When the device is disconnected we will see 126-128. Or:

0111 1110 = 126
0111 1111 = 127
1000 0000 = 128

These conditions cannot occur during game play. You can validate this through dash board. But if the Chicklet is calibrated properly this condition should not happen. The closest normal value we have observed is:

0111 1010 = 122

If you check for the above values (126-128) and they are true then the device is not connected. Try it out and let me know how well it works.

[heydowns]

Mike,

You're right, that does make detection a bit more plausible.

The description was a little confusing at first, but makes more sense after re-reading.

Not sure if we'll have a chance to try this before ship, but we'll revisit after competition season; we've moved all functionality off the analog-in-digital space (we didn't need the extra buttons after doing a recalibration/reconfiguration).

Maybe someone else using this can post results.

Either way, it'd be nice to see this information (the summary of it, anyway) in a future rev of the user's manual.

Thanks for looking into this and sharing the details!

[Mike Copioli]

Originally Posted by heydowns

Mike,

You're right, that does make detection a bit more plausible.

The description was a little confusing at first, but makes more sense after re-reading.

Not sure if we'll have a chance to try this before ship, but we'll revisit after competition season; we've moved all functionality off the analog-in-digital space (we didn't need the extra buttons after doing a recalibration/reconfiguration).

Maybe someone else using this can post results.

Either way, it'd be nice to see this information (the summary of it, anyway) in a future rev of the user's manual.

Thanks for looking into this and sharing the details!

We have tested the code on our robot and it works great. It would be a good idea to make the ranges defines and adjust them based on the specific Chicklet you are using. Also you must ensure that the Chicklet is calibrated and verify the outputs with dashboard to ensure you are not excluding a valid state.