View Full Version : Accelerometers
Hello,
yesterday appeared a page (http://wiki.maemo.org/Accelerometers) on the maemo wiki about the accelerometers features in fremantle. In this page is suggested a example application, and a deb file (compiled to arm) is provided.
How should we use it ? :p or it's just for internal use/future code example ?
Since I'm very interested in the accelerometer features of fremantle, I have a couple of harmless questions (if this information can be disclosed now).
Is possible to set/get the sample rate and threshold via sysfs ?
The accelerometers d-bus code is OSS or will be ?
Thanks.
interesting
i wonder if we could hack something together using the wiimote drivers to give similar results.
tape wiimote to bottom of 810 and see if it works, or plugin one of the mini usb ones ive seen knocking about.
i doubt we could replicate the dbus part, but the sysfs portion looks feasible for a fake driver to supply.
I have compiled the app for X86 to test it in the SDK, but it fails with a nice core dump:
ERROR:sand.c:285:main: assertion failed: (dbus_proxy)
/usr/bin/run-standalone.sh: line 11: 23643 Aborted (core dumped) "$@"
Might be best to look at the kernel code and see what the driver does (assuming we have the relevant bit), apparently the scaling, etc., to produce a value in milli-gs is done in there.
Might be best to look at the kernel code and see what the driver does (assuming we have the relevant bit), apparently the scaling, etc., to produce a value in milli-gs is done in there.
Yeah, the driver is there: /kernel-2.6.28/drivers/hwmon/lis3lv02d.c
But depends how the system use it :p
Lord Raiden
2009-05-21, 13:38
Ya know, if the next NIT has an accelerometer in it, I'm so gonna be stoked. That in itself has so many uses that I can't even name them all. :D
Hi, yes I published that page yesterday but then I went for other things and forgot to link it somewhere.
Basically is the best I could get to answer a question that was coming from the NumptyPhysics developer and others. Hopefully a better interface and documentation will come, but in the meantime you have the basics there.
About the little app, please contact marnanel directly. I'm sure he is willing to share his own findings but I don't expect him to be aware of this thread here. I have seen the app working but that's all I know about it.
I have seen the app working but that's all I know about it.
In a Fremantle prototype device right ?
Thanks.
But depends how the system use it
I was assuming the sysfs entry code would also be present. I can't look myself atm as I'm running on WinXP (can't apply the diff easily), but will have a look through later on.
Ah no worries, just looked in the patch. Take a look at the following file: /drivers/i2c/chips/lis302dl.c
I was assuming the sysfs entry code would also be present. I can't look myself atm as I'm running on WinXP (can't apply the diff easily), but will have a look through later on.
Yeah, is there. Didn't looked for it :D. thanks !!!
In a Fremantle prototype device right ?
In a development unit used to test Fremantle. Shaking my laptop with the Maemo 5 SDK installed won't work. ;)
So the answer is yes, you can alter the rate from the looks of it. See lis302dl_set_rate() and likewise the scaling with lis302dl_set_scale()
Ah no worries, just looked in the patch. Take a look at the following file: /drivers/i2c/chips/lis302dl.c
Humm, don't have that file, should have a different kernel, where did you grab yours ?
In a development unit used to test Fremantle. Shaking my laptop with the Maemo 5 SDK installed won't work. ;)
Ehehe, so we can't test it :)
I just grabbed the patch from the repo: http://repository.maemo.org/pool/fremantle/free/k/kernel/kernel_2.6.28-20091602+0m5.diff.gz
Ehehe, so we can't test it :)
I can give feedback if anybody tries and uploads the packages to extras-devel.
So the answer is yes, you can alter the rate from the looks of it. See lis302dl_set_rate() and likewise the scaling with lis302dl_set_scale()
Ah, almost everything is configurable, nice work.
I'm happy now :D
Master of Gizmo
2009-06-05, 11:20
In a development unit used to test Fremantle. Shaking my laptop with the Maemo 5 SDK installed won't work. ;)
That's actually not as a strange idea as it seems. The tiltstick e.g. just works inside the sdk and so would any other usb peripheral connected via usb and accessed via libusb.
That's actually not as a strange idea as it seems. The tiltstick e.g. just works inside the sdk and so would any other usb peripheral connected via usb and accessed via libusb.
does the tiltstick use the same format and sysfs entries as the built in commands?
if not, it would be nice if there was perhaps a small redirection app which could allow people to test using as you say a tiltstick, or using a bluetooth connected wiimote.
Perhaps the library version does this already and will accept input from any accel unit, maybe someone else will know.
Master of Gizmo
2009-06-15, 19:33
does the tiltstick use the same format and sysfs entries as the built in commands?
No, it doesn't. But the page now says that there'll perhaps be a library.
Master of Gizmo
2009-06-16, 12:19
The enigma game (http://www.nongnu.org/enigma/) is now in fremantle extras-devel (http://repository.maemo.org/extras-devel/pool/fremantle/free/e/enigma/) and includes accelerometer support.
The enigma game (http://www.nongnu.org/enigma/) is now in fremantle extras-devel (http://repository.maemo.org/extras-devel/pool/fremantle/free/e/enigma/) and includes accelerometer support.
And works in a real device with great precision! I benchmarked yesterday with a device and 2 users without NDA: my 2 and 4 year old kids. It was the first time they played anything like this and they did move the device naturally based on their knowledge on real gravity. They even got through the levels 1 and 2!
My big son asked me whether that was a real ball.
My big son asked me whether that was a real ball.
It amazing how kids perceive the world at that age, makes you wonder what we can learn from them :)
The enigma game (http://www.nongnu.org/enigma/) is now in fremantle extras-devel (http://repository.maemo.org/extras-devel/pool/fremantle/free/e/enigma/) and includes accelerometer support.
How enigma is using the accelerometer? Is it using it through libtiltstick?
Accelerometer really needs some documentation. The wiki page doesn't count as documentation atm :)
Indeed, I've got a great idea for a simple app using the accelerometers; but am unsure whether it's best to poll the sysfs interface (http://wiki.maemo.org/Accelerometers) directly, or some other mechanism.
Please file a bug for the lack of official documentation on how to use the accelerometers. I put together the wiki page as a temporary solution.
Please file a bug for the lack of official documentation on how to use the accelerometers. I put together the wiki page as a temporary solution.
https://bugs.maemo.org/show_bug.cgi?id=4724
Feel free to add more specific requests on the documentation that should be provided.
Thesandlord
2009-06-22, 19:39
It was the first time they played anything like this and they did move the device naturally based on their knowledge on real gravity.
Never played with an iPhone or Wii have they? My 3 year old cousin loves to play that ball game on his dad's iPhone...
Master of Gizmo
2009-06-30, 06:24
How enigma is using the accelerometer? Is it using it through libtiltstick?
Nope, i just polls the sysfs. I completely removed tiltstick support as only 2 or 3 devices ever had the necessary hardware.
But i agree that some generic tilt sensor solution is required which may then again include support for the tiltstick.
attila77
2009-06-30, 12:14
Apropos accm, I undestand this is a hardcore question but... will we have access to the inertial wakeup feature of the chip ? (this could be used to detect being picked up/flipping pages/etc without polling like crazy).
speculatrix
2009-06-30, 21:16
That's actually not as a strange idea as it seems. The tiltstick e.g. just works inside the sdk and so would any other usb peripheral connected via usb and accessed via libusb.
many laptop hard drives have accelerometers built in to sense falling/dropping.. maybe you could use that?
There is a new version of NumptyPhysics in Fremantle extras-devel. The game now starts with a new but provisional screen: "Accelerometers test".
Sadly the test fails. The objects in that screen and anthing else you draw follows the same gravity falling down the display... no matter in what position you have the device. Maybe someone can give a hand to Tim Edmonds?
I uploaded madbomber 0.2.5-3maemo5 to extras-devel, it has accelerometer based control now. Any feedback (does it work, direction ok, general feel) would be welcome so I could decide what do with it.
MadBomer doesn't seem to respond to accelerometers. The keys do work.
MadBomer doesn't seem to respond to accelerometers. The keys do work.
Doh! I left my acceleremoter test setup in the code (which is typing some numbers manually to a file and see what happens). You could try this
ln -s /sys/class/i2c-adapter/i2c-3/3-001d/coord /tmp/coord
Bringing this back from the dead...
I looked at sandcastle and there is the DBusGProxy callback. Ok, what amound of motion does it take to trigger such a callback?
Is there some documentation on the nature of the dbus accelerometer functionality?
hi,
i am also interested to know how one can access the accelerometer on the N900, especially if it is possible to do so via Python.
how about other sensors? or radio signal/base station/battery etc.?
thank you..
wahlau.
attila77
2009-11-13, 12:24
See http://wiki.maemo.org/Accelerometers, it even has a python example.
thanks. that answers my answer pretty well!
i wonder if there will be Sensor API-like on the S60 Platform interfaces on N900. that would make many things simpler... :)
Still curious about the dbus question a few posts up. Much obliged to anyone who can answer or point me in the right direction.
thanks. that answers my answer pretty well!
i wonder if there will be Sensor API-like on the S60 Platform interfaces on N900. that would make many things simpler... :)
We are working on this (it will be more advanced, but API for accelerometer will be there also) for C++ :) It goes really nicely with Qt.
attila77
2009-11-14, 23:11
Still curious about the dbus question a few posts up. Much obliged to anyone who can answer or point me in the right direction.
AFAIK official DBUS API/docs are not yet available (https://bugs.maemo.org/show_bug.cgi?id=4724#c3)
Does anyone know anything about the internal workings of the accelerometers used on the N900? My interest is professional - I know quite a lot about seismometers and full-size accelerometers.
I had assumed (perhaps foolishly) that it used piezo-electric accelerometers. These and all the other small motion sensors that I know about are only capable if giving an output in response to a change in position. They give no output at all if the device is not moving and so could not be used to determine the orientation of a static device.
The wiki page demonstrates that the N900 accelerometers do vary their output with orientation and so can be used to determine orientation.
For the life of me, I can't work out how they do it.
Pure Magic ® :)
Seriously, no idea. But I can confirm, that it is able to give you value of Earth g.
The wiki page demonstrates that the N900 accelerometers do vary their output with orientation and so can be used to determine orientation.
For the life of me, I can't work out how they do it.
An accelerometer _must_ vary its output depending on orientation, as we're constantly under the force of gravity. Turn the device upside-down, and the reading should go from (0,0,-1) to (0,0,1).
If you want to know how these kinds of accelerometers are made, and work, I seem to remember that Freescale Semiconductor had some interesting application notes on their website which included electron micrographs of the innards - wonderful structures. Nokia don't use FSL accelerometers, it's just that I previously worked at FSL and am more familiar with their sensors than any others. The n900's is an ST device, in fact, and the specs are publically available.
Ditto the kernel source - it is all open, so just take a peek at the lis302dl driver. There are some features that aren't utilised, but all the bread-and-butter stuff's supported. There's a trivial sysfs interface for reading the current value, so even shell scripts can use it!
In fact, the running and jumping code in Oliver McFadden's quake3 arena demo just uses that sysfs accelerometer interface. I know that, as I wrote it '-)
Nokia has used ST's accelerometers in the past (at least my 5800 XM that I accidentally drowned in beer had a digital ST accelerometer, pretty much the only component that Google told anything interesting about but can't remember the exact number now), so I wouldn't be surprised to find an ST accelerometer in the N900 as well. ST has done it quite elegantly: they sniff out the capacitance variations between micromachined or etched beams of coated silicon placed perpendicular to each other. Movement causes the masses at the ends of the beams to follow more "slowly", causing a measurable variation in capacitance due to bending of the structures. The datasheet tells you more, just see ST's web pages.
ST has done it quite elegantly: they sniff out the capacitance variations between micromachined or etched beams of coated silicon placed perpendicular to each other. Movement causes the masses at the ends of the beams to follow more "slowly", causing a measurable variation in capacitance due to bending of the structures. The datasheet tells you more, just see ST's web pages.
Yup, they're beautiful (to a geek!). Accelerometers designed for different numbers of axes can have different designs, but they all rely on the sprung pendulum you describe . On the whole the 3 axes ones are the most intricate, so my favourites.
Hi,
I'm porting a medical application which measures activity levels of seniors using the N900 accelerometer. It requires accurately timed accelerometer samples. I've looked at the accelerometer driver and it uses an interrupt to read the accelerometer which is likely to result in precise sample times, but that precision in timing is lost when accessing the accelerometer data via the DBUS or via it's file device interface because DBUS calls can be delayed by system events, as can reads from the file device. I've tried both and the jitter is unacceptable (4 milliseconds variation at best when no other apps are running and 50 milliseconds with an audio app running with a 100Hz sample rate). Perhaps the accelerometer data should include a timestamp from the driver?
Or maybe I can just assume a precise interval between readings if I read faster than the default sample rate of 100Hz (if I read data at 200Hz each reading should repeat twice so I'd be able to tell individual readings apart as long as they were changing)?
Ron
vBulletin® v3.8.8, Copyright ©2000-2024, vBulletin Solutions, Inc.