Make a Safer "Continuous Jog" for Game Controller Operation

[rocco8773]

Previously the motors would go into a continuous jog whenever operated by the joystick of a game controller. This presented a serious risk if the software would ever crash. The continuous jog will keep moving until it receives a stop signals, so if(when) the software crashes there can never be a signal to stop the motors. The user would have to run up and manually stop the motors.

The STM23X (or STM24X) has features to mitigate this issue: software limits (LM and LP) and network watchdogs (ZA). However, our motors do NOT have these features.

To mitigate this risk, the PR has created an artificial "continuous jog". How does this work...

• Whenever the game controller joystick is operated, a macro jog step is taken. This means the move starts with an eventual end point.
• If the joystick is still operated when the drive gets to the end of its macros step, then a new macro step will begin.
• If the joystick is release during a macro step, then the move will stop.
• The macros step is configurable in the "Game Controller" GUI.
• The user still needs to conscious of how large the macro step is when near the end of travel, especially if a limit switch is not properly set.

---

What has changed...

• The stop() method on Motor, Axis, Drive, and MotionGroup has been update to have a consistent signature across all.
• Drive.stop has been updated so a specific axis can be stopped or all axes can be stopped.
• MotionGroup.stop has been updated so a specific axis can be stopped or all axes can be stopped.
• AxisControlWidget has been updated to include a field for setting the joystick macro step. This field is hidden when AxisControlWidget is initialized in interactive mode, and made available with initialized in read-only mode.
• DriveGameController.stop_move will issue a QTimer at the end of its execution to double check if the motor has been properly stopped. I [@rocco8773] implemented this because when the joystick was just flicked the motor would just start moving, when it should not be moved at all.
• DriveGameController._handle_axis_move is re-written to perform the macro jog step, instead of the continuous jog.
• DriveGameController._handle_axis_move no longer tries to make decisions based on its own joystick dead-zone. Instead it relies on the PyGameJoystickRunner dead-zone handling.
• PyGameJoystickRunner: The signals attribute was changed from a class attribute to a instance attribute.
• PyGameJoystickRunner: created methods blockSignals and signalsBlocked
• PyGameJoystickRunner: put signal connections into dedicated method _connect_signals
• PyGameJoystickRunner: re-worked handling of the joystick behavior
  • handling is done by a dedicated method _handle_axis_move
  • when handling a joystick event the joystick value (position) is read instead of using the event payload value. (I [@rocco8773] was finding the payload value to be inconsistent with the current value.)
  • events corresponding to axis 0 and 2 get mapped to axis 1 and 3 respectively
  • if events do NOT occur of 500 ms (50 of the frame rate), then the joystick position swill be manually read and handled. (I [@rocco8773] did this since pygame do NOT consistently nor dependably pickup joystick motion.)
  • The joystick does NOT need to return to the dead-zone for a stop motion to be recognized. It just needs to display that it is returning to the dead-zone.
• MGWidget: made dedicated methods to handle motion start (_handle_movement_started) and motion stop (_handle_movement_stopped).
• MGWidget._handle_movement_stopped puts a callback to enabling the configuration controls into a QTimer set for 500 ms. This is done so every time the new "continuous jog" comes to a stop and starts up again the configuration controls are NOT enabled and disabled again. This enable-disable cycle would cause delays in the start of the next macro jog.