Working on SpacePilot support, need help with rotation
Am 07.07.15 um 17:55 schrieb Bogdan Kecman:
otoh making "interface" in the openscad to allow external manipulation
of the 3d object would probably be a good thing irrelevant to the pilot
as then you can easily add support to rotate object controlled by
wiiiiii camera and ir markers on fingers or any other contraption we can
create
I thought about that too. I have some experience with DBus. Adding a
DBus RPC interface to control translation / rotation from outside should
not be that hard. (Once the SpaceNavigator stuff is done. Some parts of
the two problems overlap.) Then you'd need an extra program / process
that fills the gap between the 3dconnexion API and the DBus API of
OpenSCAD. You would have to distribute this as binary only. As it is a
separate process it would not infect OpenSCAD with any poisonous license.
But this would be overcomplicated, IMHO. Talking to the USB HID directly
proved to be simple and is much more efficient.
tschüß,
Jochen
On 7/7/2015 10:26 PM, Jochen Kunz wrote:
But this would be overcomplicated, IMHO. Talking to the USB HID
directly proved to be simple and is much more efficient.
Why I think it is a good idea is because it seems that different 3dconn.
devices have slightly different protocol so supporting them all is going
to be pita .. otoh with the interface supporting "any" device gets
pretty simple
Am 07.07.15 um 01:56 schrieb Gert Menke:
I also have an old Labtec Spaceball 4000 which still works fine with a
RS232/USB adapter and spacenavd.
Forgot to mention: I have an old SpaceBall 2003. I used it with my SGIs.
But I never run more then the SGI confidence tests. I should dig it out
and see if I can get it to work with spacenavd. But IIRC it didn't work
anymore when I tried it last time, several years ago... Ahhh, I also
have the buttons and dials boxes... :-)
Attached is my current state of the affair. I moved the event handling
into class QGLView and I handle translate / rotate in separate methods
like you. I switched from signals for event delivery to QEvent
subclasses. This makes it easy to deliver events to the in-focus window
only. See SpaceNav::Impl::operator()( void). It should be easy to modify
for spacenavd.
The button handling needs a bit work. I noticed that this is slightly
different on MacOS compared to Linux and NetBSD. Maybe because the
3Dconnexion driver reprograms the device on MacOS...
The rotation problem is still unresolved.
tschüß,
Jochen
On 07/09/2015 12:34 AM, Jochen Kunz wrote:
Attached is my current state of the affair. I moved the event handling
into class QGLView and I handle translate / rotate in separate methods
like you. I switched from signals for event delivery to QEvent
subclasses. This makes it easy to deliver events to the in-focus window
only. See SpaceNav::Impl::operator()( void). It should be easy to modify
for spacenavd.
Nice, I'll try to provide some simple framework allowing different
driver types. Maybe the events could be renamed to a more general
name to be used by other implementations too.
I've attached the hidapi.pri I'm using for testing. At least on
Debian, hidapi comes with pkg-config support. This should work on
Linux and MacOS (tested only on my Debian system so far). Windows
builds use the MXE cross build environment which does not seem to
have hidapi, but that should be easy to solve by either adding it
to MXE or including the two files directly. Good thing is MXE has
libusb already.
To use hidapi.pri, it needs to be added to (similar to harfbuzz)
openscad.pro:CONFIG += hidapi
common.pri:include(hidapi.pri)
ciao,
Torsten.
Am 09.07.15 um 00:57 schrieb Torsten Paul:
Nice, I'll try to provide some simple framework allowing different
driver types.
Realistically there are only two alternatives: Raw USB access (via
HIDAPI) or spacenavd. They can coexist and it seems there is no need for
runtime configuration to switch between those two. Detection can be
automatic. You probably wane compile time switches to disable one or
both options. I'll have a look at spacenavd later. The only Space
Navigator / HIDAPI specific parts are in SpaceNav::Impl::operator(). It
should be simple to add support for spacenavd.
There are more things to do. We want a configuration menu to assign
different functions to the buttons of the device. Probably we want a
local speed setting. I can't help much here as I have no clue about Qt
GUI programming. (And I am not much interested to gain that skill. I am
fine with "reconfiguration by recompilation". ;-) )
Depending how things work out it may be necessary to add some device
description. I.e. a way to determine the total number of buttons of the
currently connected device, nim. / max. axis scaling factor, ... For now
I avoided this, there are more basic things to do for now.
Maybe the events could be renamed to a more general
name to be used by other implementations too.
The SpaceNav classes could be renamed to e.g. SixDoFDev (Six Dimensions
of Freedom Device) or the like. They are not Space Navigator specific.
I've attached the hidapi.pri I'm using for testing. At least on
Debian, hidapi comes with pkg-config support. This should work on
Linux and MacOS (tested only on my Debian system so far).
Thanks for the help. I plan to do some testing on Debian. But I have to
install it on my old laptop first... This way I can build an interface
to spacenavd based on Gerts work.
Windows
I haven't used it since 1993 and don't plan to change this in the near
future. So I can't provide much help in that department. ;-)
tschüß,
Jochen
On 07/09/2015 10:39 PM, Jochen Kunz wrote:
Am 09.07.15 um 00:57 schrieb Torsten Paul:
Nice, I'll try to provide some simple framework allowing different
driver types.
Realistically there are only two alternatives: Raw USB access (via
HIDAPI) or spacenavd.
For the Space Navigator devices that's probably the case, but
there are other devices that could be used as well like joysticks,
the remote interface discussed lately or maybe there are other
3d mouse devices with more reasonable licensed SDKs.
No need for something hugely complicated, the event stuff you
wrote covers probably already quite a big part of it.
There are more things to do. We want a configuration menu to assign
different functions to the buttons of the device. Probably we want a
local speed setting. I can't help much here as I have no clue about Qt
GUI programming. (And I am not much interested to gain that skill. I am
fine with "reconfiguration by recompilation". ;-) )
I think it makes sense to first get things working with same
sane default settings and add config options in the next step.
Maybe the events could be renamed to a more general
name to be used by other implementations too.
The SpaceNav classes could be renamed to e.g. SixDoFDev (Six Dimensions
of Freedom Device) or the like. They are not Space Navigator specific.
Yep, something like that.
Windows
I haven't used it since 1993 and don't plan to change this in the near
future. So I can't provide much help in that department. ;-)
Well, I'm not using it either except for testing. The number of
OpenSCAD users running the Windows version is quite large though,
so it does matter a lot. No need to worry, I'll try to take care
of that part (even if a bit grumpily ;-).
ciao,
Torsten.
tp3 wrote
Well, I'm not using it either except for testing. The number of
OpenSCAD users running the Windows version is quite large though,
so it does matter a lot. No need to worry, I'll try to take care
of that part (even if a bit grumpily ;-).
Oh good, I was lurking while waiting for a Windows mention.
If there is a commitment (obviously no absolutes) to getting it working, I'm
happy to buy one and help with testing.
Unless specifically shown otherwise above, my contribution is in the Public Domain; To the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. This work is published globally via the internet. :) Inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/
View this message in context: http://forum.openscad.org/Working-on-SpacePilot-support-need-help-with-rotation-tp13057p13114.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
To join the fun, I now have a SpaceMouse Wireless :-)
It turns out Linux support via hidapi might not be the best
option as the receiver is detected as Joystick with 7 axis
already (hmm, not sure why 7, the last one seems dead, which
does fit the advertised 6 degrees of freedom). So just using
the joystick interface is probably the out-of-the-box solution.
The joystick driver I've toyed with before using an XBox
controller works quite nicely with the 3d mouse too. I don't
see any issues regarding the rotation.
The hidapi protocol does look different for my device compared
to what I figure from the 3Dtest program.
The button part is similar (3 byte packet, starting with 0x03),
but for the axis movement I'm getting a 13 byte packet with all
axis values.
But of cause it's possible the low-level joystick driver does
interfere here.
I've also added a simple prototype DBus driver using the Qt DBus
interface.
ciao,
Torsten.
Am 13.07.15 um 21:41 schrieb Torsten Paul:
To join the fun, I now have a SpaceMouse Wireless :-)
Congratulations. :-)
It turns out Linux support via hidapi might not be the best
option as the receiver is detected as Joystick with 7 axis
already (hmm, not sure why 7, the last one seems dead, which
does fit the advertised 6 degrees of freedom). So just using
the joystick interface is probably the out-of-the-box solution.
Probably this would be a worthwhile interface to add.
Have you tried spacenavd?
On Debian the libspnav-dev package comes with test and demo code. The
"cube" demo didn't work out of the box as it used the X11 protocol but
"simple_af_unix" did work.
I expect that we will go with spacenavd / libspnav on Linux. It seems
the best option there.
For MacOS it may be better to avoid HIDAPI and use the native MacOS
systemcalls.
The joystick driver I've toyed with before using an XBox
controller works quite nicely with the 3d mouse too. I don't
see any issues regarding the rotation.
The problem with rotation is gimbal lock. The "cube" example in libspnav
shows how to do the rotation and avoid this by using quaternions. I try
to understand this and port it to OpenSCAD. But my math-foo is a bit rusty.
The hidapi protocol does look different for my device compared
to what I figure from the 3Dtest program.
The button part is similar (3 byte packet, starting with 0x03),
but for the axis movement I'm getting a 13 byte packet with all
axis values.
Fits. The first byte is the report ID. What ID did you get? The
remaining 12 bytes are the six axes as int16_t. Can you determine how
this int16_t are mapped to the axes? And what is the USB vendor /
product ID? This information may be sufficient for me to add MacOS
support for this gadget.
But of cause it's possible the low-level joystick driver does
interfere here.
Probably. What does "lsusb -v" show? Look for "Report ID" 1, 2, 3.
tschüß,
Jochen
Hi everyone,
I finally managed to get the rotation right. :-)
Basically, I convert the euler/gimbal values to a rotation matrix, apply
the requested rotation and convert the matrix back to euler values.
Works like a charm and you don't have to worry about gimbal lock.
Also, I got multiple MainWindows to play nicely together. The currently
active window is the only one that interacts with the driver, and the
driver is opened/closed only by the first/last window.
Regards
Gert
PS: I tend to prefer the direct spnav connection over using X11 events,
because I hope Wayland will take over the world soon. (Which, in X11
terms, probably means in the next one or two decades, I guess...)