acquaman/acquaman — comment on commit 791dbb40374c7a2f4de8d3d0bbea368fa3e88ab1
File:  line 0
By markboots:

Well, since some people in my group Eamo... have a reputation for crashing sample manipulators...

...and doing XES scans with our spectrometer requires getting the sample position extremely close to (but not crashing into) the delicate spectrometer entrance slit, I need a way for people to drive the sample around while looking directly through the vacuum chamber window (and preferably not looking away towards a computer to hit the wrong buttons.)

So I'm using a PS3 controller as an alternative to the sample manipulator buttons in the software. I've got it working in USB mode, and in bluetooth mode on modern linuxes, but there's always the the problem of Scientific Linux 5.4 being about 7 years behind in driver support ;)

Anyway, the Acquaman code works with any joystick that Linux supports, so you don't need to specifically use a PS3 controller... I just like it because it's tactile and you don't have to look down at your hands.

The implementation uses threads so that talking to the joystick driver doesn't fill up the Qt main-thread event loop, and so that button presses, etc. don't disappear when the event loop gets full. (The linux joystick event buffer only holds 256 past events before over-writing itself, so if you don't read them in time, you lose them. With a fast-reading multi-axis joystick like the PS3 controller, it's easy to fill that up quickly. And we know that our main event loops are currently blocking for hundreds of ms at a time, especially when doing some drawing, thumbnail, and database operations.)

I think the critical point of our philosophy on threads is to avoid forcing non-thread-aware programmers to deal with threads (since this is probably a recipe for disaster in the learning case, and even a challenge for experienced programmers.) In this case, the threading is buried inside the implementation; actually using an AMJoystick is all signal-based in the main thread, so you don't need to deal with threads or even know they exist to incorporate it into your programs. [This is exactly the same design we use for AMProcessVariable: threads are used by necessity, but only on the hidden side of the implementation; users of AMProcessVariable just get safe objects and signals in the main thread.]

I'll let you know once I get the driver stuff figured out on regular beamline OPIs... If you can think of an application on your beamline, it would be pretty quick to show you how to use it.