wolfwings | Okay... the SixAxis/DS3 is a lot more sane now...

...but I need a little help, I just can't find any good way to pre-process the accelerometer/gyroscope data from the thing.

qdot, you have any math in your back pocket somewhere? Specifics:

10-bit X/Y/Z accelerometer, data returned unsigned. 4G range, centered on 512. Lowest 2-3 bits flicker madly at rest on a table.

10-bit gyroscope, no idea if that's the right term but it's what everything calls it. Indicates how much rotational velocity the controller has around the axis that goes straight up through the face of the controller if it's set down on a table. Unknown exact velocity mapping, approximately 180 degrees rotation in 0.9-1.1 seconds just barely pegs the meter. Clockwise is lower, counterclockwise is higher.

I'd like to return full six axis results, if it's possible from these values? If a reduced set of values is the best we can do, that's fine too. Right now I have the HID Descriptor coded for -128 to +127, if someone thinks raising the range is useful, I can and will.

Since the Linux-USB list ignored my e-mail asking if it was the appropriate place for HID discussion and if there was anything I should know to make this patch more likely to get accepted (likely due to my name not looking real enough, I'd imagine) I'll just drop a patch on them, see what they say then. But I'd like the patch to be damn high quality, so I don't want to screw up the accelerometer handling if I can avoid it. :-)

Flat | Top-Level Comments Only

First off, your assumptions are correct for the most part. What you've basically got there is an Inertial Measurement Unit, or IMU. That's the sensor made up of the combination of accelerometer and gyro. The sixaxis has one, and the wiimote will become one once the WiiMotionPlus comes out (which adds the gyro to the accelerometer in the wiimote).

However, in terms of getting a pose (the '6-axis result' you mention, which basically gives the pose in 3-space in [insert coordinate frame here] for the controller)... Unless I'm misunderstanding what you're wanting to do (which I may very well be), I think you're kinda falling out of the range of driver writing, at least for something that's going to be attached to the kernel. All you should be passing back are the raw sensor values; actual filtering should be kept as a user-implementation, due to the fact that this enters the realm of "different filtering methods for different outcomes".

...I was hoping to be able to return 'cooked' XYZ coordinates in 3d space, and the current rotation if that's possible, yes. I wasn't aware there were different situations that called for different sorts of filtering methods, nor was I aware that returning 'cooked' values that align better with the protocol and are more usable by software was frowned on these days.

At least, as far as I could find there's no 'proper' place to return raw inertial sensor readings that syntatically makes sense, but there is a proper place to return a 6-axis spatial translation/rotation dataset in the HID Usage Tables. Right on the main 'Generic Desktop' page no less. Or did I miss something in the HID tables where the raw sensor values would correctly go, versus V./Vbr. where I'd planned to return cooked values?

Ah, yeah, this is why I said I might be misunderstanding. Outside of working with the old xbox controller, I haven't done much proper work with the HID layer, so I wasn't really sure if there were going to be places to put raw sensor information with any real context.

And 'pose' = 'cooked', in the way it's being used here. Basically, pose the way I used it just means position and rotation as estimated by sensors (with some estimation of error, if you want to be nice :) ). For instance, with the novint falcon, all I get back is the pure encoder ticks from the motors. I then have to run that through a kinematics framework to get the relation of encoder values to arm angles to end effector position in cartesian coordinates. However, I provide access to both the raw encoder values and the kinematics system, and allow the user to snap in their own kinematics if they'd like. That's sort of the design position I was describing.

Have you checked out how the WiiMote deals with its HID reports in terms of accelerometer information? I've done a little bit of work with it (like, 2 years ago, so I don't remember much :) ) and was getting back what I thought was raw readings.

No direct relation, unfortunately. The WiiMote lacks a USB tethered mode, so it doesn't return a "HID Report Descriptor" as far as I've been able to find. The entire thing is low-level interfaces only, with various 'cooked' API's being returned.

PS3 SixAxis/Dual Shock 3? USB Tethered it "Just Works" once you send it one magic 'init message' as a normal USB HID Gamepad device. Thus why I was trying to stick to USB Gamepad mneumonics for interfacing the accelerometers. =^.^=

Off to do laundry, feel free to ring if you want to gap about this stuff over voice. Or SMS, I'll be off-line for about 2-3 hours.

Okay... the SixAxis/DS3 is a lot more sane now...

no subject

I lost your terminology at 'pose' but...

Re: I lost your terminology at 'pose' but...

Re: I lost your terminology at 'pose' but...