In order to better solve the issue described in ticket #334 a tab, or any other piece of python code, should be able to register itself as an 'input device'.
This requires to refactor a big part of the current input subsystem implementation. This work will hopefully make the code clearer and easier to maintain. There is a couple of goals that have been identified:
Group all joystick-related code in a joystick input handling module. Currently adding a new joystick flight mode requires to modify the client in multiple places
Implement a generic way to register an input device/subsystem. The joystick then will become just one input subsystem. ZMQ will be another one.
Define a generic way for the input subsystems to communicate the current setpoint to the rest of the client. Currently the flight tab has too much code related to the gamepad control, ideally this code should be generic and working with any type of setpoints.
The mapping of the button 'alt1' and 'alt2' of the gamepad are currently hardcoded. There should be a way in the new input subsystem to declare actions that could then be mapped to alt1 and alt2.
This change will most likely require to remove the 'input mux'. We could replace it later by an input switch to be able to switch between manual and autonomous mode.
In order to better solve the issue described in ticket #334 a tab, or any other piece of python code, should be able to register itself as an 'input device'.
This requires to refactor a big part of the current input subsystem implementation. This work will hopefully make the code clearer and easier to maintain. There is a couple of goals that have been identified:
This change will most likely require to remove the 'input mux'. We could replace it later by an input switch to be able to switch between manual and autonomous mode.