wolfwings

...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

From:

qdot.livejournal.com

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".

wolfwings.livejournal.com

...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.

From: (Anonymous)

You can only get a 6 degree of freedom pose from the sixaxis controller under very specific conditions:

The accelerometers, being near the earth, will always report acceleration due to gravity. If you hold the controller perfectly still, you can determine pitch and roll because you can find the direction straight down. You cannot determine yaw. So, Sony adds a rate gyro to tell you when you turn the controller around the vertical axis (yaw). As long as you hold the controller perfectly level (or otherwise keep the controller always in the same plane) -- forever -- you can determine an exact pose relative to wherever you started measuring. Integrate the rate gyro over time to get yaw. To get roll and pitch, we have to assume that the controller is level. Integrate them over time too. This assumption that the controller is level (or some other constant) lets us subtract gravity out of the accelerometer readings and find out how the controller is moving relative to us.

You cannot detect roll or pitch directly with the sixaxis. As soon as you tilt the controller, you will not be able to subtract gravity, and hence you will not be able to distinguish your movements from the effects of gravity. You cannot detect this tilt because you have no gyros for pitch or roll, so you will not know when this happens. Your accelerometers will register a tilt to the left exactly the same as a strafe to the right. You can only know when the controller stops moving that you have been wrong: Wait for the magnitude of the accelerometers to roughly equal the magnitude of gravity. This means that the controller is in some position (unknown yaw) but remaining still. Reset all your positions and assume that this is your starting point. You can know an exact relative position from this point as long as you only rotate in the plane of the rate gyro. This is effective enough for games that only care about gestures or small movements, but not 6DOF.

http://wiki.ps2dev.org/ps3:hardware:sixaxis
http://wiki.ps2dev.org/ps3:linux:sixaxis

Hope this helps you plan your project.

-twoeven

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...

6DOF pose

Style Credit

Profile