Collision Manager audio cues not working when the Gamepad is launched from startup script
Closed this issue · 2 comments
The new collision manager's audio cues is not heard when the stretch_gampepad_teleop.py script is launched through the start-up.
We are using print('\a') because other methods (aka chime.py) take too long within the collision loop. Undue latency can cause a collision event to be triggered too late.
It seems there isn't a good solution:
https://stackoverflow.com/questions/15003468/how-to-print-a-007-or-a-beep-in-idle-or-pydev
Perhaps the terminal ettings for launching in Startup can be modified?
@aedsinger @hello-binit I wasn't able to find a reliable and robust solution to make the print('\a') method work in every shell environment because it is an feature offered by terminal from which the robot process runs.
There is a way to run startup gamepad using the gnome terminal cli that might allow us to use the bell feaure in startup by actually opening a gnome terminal. (when the user plugs in HDMI the terminal would be running). But I don't think is is a viable solution for the users where this feature wouldn't work when the process is started from any other terminal or shell (vscode,xterminator, ssh portal, etc).
Chime.py uses subprocess.run() to execute an subprocess asyncronously in the background using aplay command playing a wav file.
I implemented this #299 PR which executes the chime.warning() in a thread instance making sure it isn't blocking the control loop. But might need revisit this and profile this more to see what overhead it might be causing. Let me know your thoughts on this implementation.