PDA

View Full Version : Accelerometer



Patros
2007-10-31, 10:26
Hey all.

I've been looking into an accelerometer based plug-in, possibly with gesture recognition.

I've run into a couple of hitches related to gathering accelerometer data.

1st is that as far as I can see, accelerometer data can only be accessed through a motion event. It's a good thing to get these motion events, but for trying to glean how the remote is actually moving it's important to be able to poll at a regular interval.

I'd like to add (or have someone else add) the ability to poll for x,y,z values.

2nd is that there appears to be a sign bug in the motion events.
I created an app to log raw accelerometer data, and a lot of the values are in the 16k and 32k range. I think valid values are actually +-127. event.mouse_x and event.mouse_y are unsigned 16 bit ints , the ev[i] values are signed 16 bit ints, event.scroll_rel and last_x , y, z are regular ints.

kdf
2007-10-31, 13:27
On 31-Oct-07, at 10:26 AM, Patros wrote:

>
> I've been looking into an accelerometer based plug-in, possibly with
> gesture recognition.
>
good stuff.
> 1st is that as far as I can see, accelerometer data can only be
> accessed through a motion event.

so far, that's the initial aim. it can be refined later. I know the
event timing
limits gesture use, but Jive needs some constraints until the
performance
profile is better understood and optimised for the core ui needs.
>
> 2nd is that there appears to be a sign bug in the motion events.
> I created an app to log raw accelerometer data, and a lot of the
> values
> are in the 16k and 32k range. I think valid values are actually +-127.
> event.mouse_x and event.mouse_y are unsigned 16 bit ints , the ev[i]
> values are signed 16 bit ints, event.scroll_rel and last_x , y, z are
> regular ints.

all true. Richard is looking into it. Myself as well (I've already
brought up the
high negative value problem). I'm still waiting get the new kernel to
build on my setup again.
If you have a patch, feel free to post here if we don't get to it first.
-kdf

Patros
2007-10-31, 14:30
I'm attaching a patch that seems to work. My concern would be if there were specific reasons for selecting the current variable types, and that the changes may cause issues with the lua_tointeger calls in jive_event.c . Might be prudent to add explicit casting there.

kdf
2007-10-31, 18:03
Any chance you could redo this as a diff -upB against the latest code
(or svn diff)

-kdf

rtitmuss
2007-11-01, 03:18
Good spot, those variable types were wrong. As you can see the motion and switch events were fitted into the existing event structure, I did that before all the code was released and have always meant to clean it up. This is fixed correctly in r784. I have also added a ticks variable for events, so you can see when the event occurred.

I don't really want to add polling for motion events, polling is not really good for power consumption. The motion events are sent on movement, so it should be possible to remember the last x,y,z and use those values in a timer if necessary. Then just start the timer on motion for a limited time, so this code is not running all the time.

The code is structured so that where possible events are aggregated between frames. So for example with the wheel the event may be +5 if the wheel is moving quickly. This is to reduce the number of events processed per frame, there is little point to updating the selection position 5 times when these intermediate positions are not going to be drawn. This also helps keep the size of the event queue down. The same approach is used with motion events.

Ideally I think any gesture recognition should be implemented in jive_bsp.c (although prototyping in lua will probably be quicker for development). This would allow the gesture recognition code to see all the motion events. A lua applet should be able to define a gesture, and then get a gesture event when the gesture is made.

Patros
2007-11-01, 09:46
I was hoping to use the motion events as a form of trigger. It would keep polling if it has recieved an event in the past X ms.
Or even modify the events to simply give a flag that's motion_active or motion_stopped.

For waking up on motion, events are ideal. For things like gestures, polling at regular intervals makes the makes the math easier and more accurate.

I'm also concerned about the averaging of the motion event values. I'm not sure how well this will work if timing is not taken into consideration while averaging. I guess this depends on what's happening at the driver level. I don't know if jive_bsp is being notified at regular intervals during motion or if hysteresis is being used. *Edit* If it's done in jive_bsp.c, as you suggested this won't be an issue.

rtitmuss
2007-11-06, 16:50
I agree that the averaging of the motion events might make the data less useful to lua widgets/applets, but my main concern here is not to flood the system with too many events when you shake it :). As discussed any gesture recognition should be in the C code, and that is before the averaging.

The kernel gets interrupts from the motion sensor, the threshold can be set in /sys/bus/i2c/drivers/lis302dl/0-001c/threshold each unit is 18mg. An input event is generated when the motion interrupt is triggered. At the moment this has a 'fuzz factor' of 4, meaning that only events greater than 4 units in magnitude are sent to the device. You can see the raw events using 'evtest /dev/input/event3'. All this can be tuned as needed for gesture recognition, at the moment my focus has only been in using the accelerometer for pick-up detection.

Richard