Wired SpaceMouse Pro Support
SpaceMouse Pro Controller
This is a driver for the 3dConnexion SpaceMouse Pro, I’ve only tested this with the wired version. Maybe not so useful for robots but if you have one of these controllers the library can now drive it properly! Note that because this is so very different from the other joypad style controllers it doesn’t have the same set of controls available. Check the source for the driver to see exactly what controls are supported.
- class approxeng.input.spacemousepro.SpaceMousePro(dead_zone=0.05, hot_zone=0.01, **kwargs)[source]
Driver for the wired SpaceMouse Pro from 3dConnexion. This controller has a single six-axis puck which can respond to motion in all available axes, as well as a set of buttons. Buttons 1-4 seem to act differently to the others, they don’t generate events on presses consistently so while they do work they should be used with caution. Other buttons respond instantly and do the right thing in terms of press detection and hold times. Details of the hardware can be found here
I’ve had to largely abandon the normal snames for axes for this controller, it’s sufficiently different from all the others that there’s not really any way to directly substitute it. The puck uses lx and ly for linear X and Y movement, but it then also uses lz for up and down, and pitch, roll, and yaw for the rotational axes. As such, it will ‘just work’ if your code only uses the left stick and the motion sensing axes, but there aren’t any trigger buttons or axes, and there’s no right joystick x and y. On the other hand, if you’ve got one of these you already know you’ll need to code specifically for it!
- __init__(dead_zone=0.05, hot_zone=0.01, **kwargs)[source]
Populate the controller name, button set and axis set.
- Parameters:
controls – A list of
Button,CentredAxis,TriggerAxisandBinaryAxisinstancesnode_mappings – A dict from device name to a prefix which will be applied to all events from nodes with a matching name before dispatching the corresponding events. This is used to handle controller types which create multiple nodes in /dev/input by keying on the device names reported to evdev for each node. Nodes are grouped by physical or unique ID first so should, in an ideal world at least, all correspond to the same physical controller. This is necessary to support some controllers on modern kernels, particularly 4.15. If not specified, or none, then no per-node renaming is applied. Device names which do not appear in this map are not assigned a prefix, so it’s legitimate to only assign prefixes for ‘new’ functionality which has magically appeared in a later kernel. Similarly, this is ignored if there is only one device node bound to the controller instance, so the best practice is to leave the older mappings named simply by their code, and only use this to handle secondary device nodes such as motion sensors.
dead_zone – If specified, this is applied to all axes
hot_zone – If specified, this is applied to all axes
ff_device – If specified, this is a force feedback compatible device node, defaults to None