Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ignore stray gamepad commands #188

Open
Achllle opened this issue Apr 7, 2024 · 2 comments
Open

Ignore stray gamepad commands #188

Achllle opened this issue Apr 7, 2024 · 2 comments
Labels
help wanted We're especially looking for input from the public on this one

Comments

@Achllle
Copy link
Collaborator

Achllle commented Apr 7, 2024

When I turn on the rover and wait until it fully launches, then turn on the my RC (Spektrum DCs) with the enable button switched to ON, it will send the rover crashing into the wall at full power. Likely the first few commands it sends are misinterpreted or garbled.

This can simply be avoided by making sure the enable switch is turned off when turning on the gamepad or making sure the gamepad is always on before launching the rover.

A hack solution would be to ignore the first few commands received in software.

@Achllle Achllle added the help wanted We're especially looking for input from the public on this one label Apr 7, 2024
@ericjunkins
Copy link
Collaborator

ericjunkins commented Apr 7, 2024

We've had similar issues at work, where we're using a controller that doesn't have functional safe hardware (as per the ISO standards). We're still able to achieve a functional safe implementation, which could also be used on this project. I'll put all the requirements of what we do, not necessarily all have to be implemented.

no commands can be sent to the drive system until

  • X number of packets have been received
  • the system trusts the controller inputs
  • the Deadman switch has been not active for Y number of packets

The trust is established by the axes (joysticks and any triggers) having a stable settled value that is within an acceptable band around the nominal value (0 for joysticks for instance). It needs to have a certain number of packets with very little variance, within that band In order to say the controller is okay. This helped us get rid of issues that are brought on by resistive-based joysticks instead of more expensive hall sensor ones, things like controller drift. It also made it so if a user was holding any input unexpectedly the robot wouldn't move.

Anyway I'm sure implementing all that is overkill from what's needed here, but that's one solution.

@Achllle
Copy link
Collaborator Author

Achllle commented Apr 7, 2024

That's super helpful, thanks for sharing! I hadn't thought about validating package contents before rejecting them. I think indeed we need to land on a solution that is robust since this is a safety hazard but also requires minimal or no configuration. I think it might be time to clone the joystick code and modify it to inject such features.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted We're especially looking for input from the public on this one
Projects
None yet
Development

No branches or pull requests

2 participants