Rfc: Tilt/accelerometer - Would You Want One?

Do you want an accelerometer add on for the Pandora?

  • Yes please, I just want something for controlling games (a joystick replacement)

    Votes: 0 0.0%
  • Yes please, I want a 3-axes accelerometer for lots of other cool stuff apart from being a joystick r

    Votes: 1 100.0%
  • No thanks, I'd never use it

    Votes: 0 0.0%

  • Total voters
    1

I would definitely pay money for an accelerometer addon, as there are many uses beyond the realm of gaming. I really hope someone explores this further & puts something into production. Personally, I would like to see some kind of DIY kit, as that would be more cost-effective. Internal would also be much preferred, however we don't know if that would even be plausible yet since no one (save for a few) knows how much excess room there is in the pandora case. I2c also gets my top choice because I can honestly say that I will never use it for anything else, and I wouldn't want it to go to waste seeing as its already there. Second choice however would have to be an internal mini-usb based device. Third if nothing else would be a plain old external usb device. I would pay for any of them. I do like the idea of incorporating a hub into it if it was to be external. Also, form factor is a huge issue with external devices, that is my main issue with the idea in the first place, so it would be nice if it was as economical & form fitting to the pandora as possible. If possible, it should lay flat against the back of the pandora while plugged in without interfering with L/R, it should not add any thickness & should add as little as possible to the width.... but thats just me.
 
DAP said:
A USB solution would have to be externally mounted, or would require sacrificing one of the external USB ports (there are no internal USB ports, and USB allows only one device per port).
According to the OMAP3 datasheet (spruf98b, page 3175) the EHCI host interface has three USB ports but I'm not sure if it can be used easily. I guess you may need additional hardware (PHY chip?) for each additional port.

BTW, maybe plain serial port is enough too?
 
Last edited by a moderator:
I'm fairly sure that the other USB ports are not available unfortunately. But I also think using USB is overkill, and also that internal would be best, I'm sure we can find room! No one has mentioned SPI bus yet, which I'm pretty sure is available both internally and on the EXT connector. And also there are already tonnes of small, ready made boards that will do this for you. See these:

I2C/SPI 3 Axis accelerometer board: http://www.sparkfun.com/commerce/product_i...products_id=758

SPI Gyro: http://www.trossenrobotics.com/sparkfun-gy...ree.aspx?a=blog

I2C compass: http://www.sparkfun.com/commerce/product_i...roducts_id=7915

3 Axis compass and 3 axis accelerometer: http://www.sparkfun.com/commerce/product_i...roducts_id=8656

I could see it might be advantageous making a board with accelerometer and compass in one, just from a price point of view (that last one I linked was $149, the other 2 are about $40).

I think the gyros I've seen (e.g. the one above) are actually mems accelerometers. Not certain though, can anyone clear that up? I think proper gyros are very expensive, and quite bulky.

I'd be happy to write or help to write any drivers, though I expect there are some similar drivers around already.
 
I'm interested in this for head tracking. The best affordable option so far seems to be an extensive hardware mod of a USB PS3 sixaxis controller, although AFAIK that lacks a compass and so is not ideal.
 
DAP said:
QUOTE

Ah, speed of rotation - of course! But I don't plan to be doing inertial guidance of missiles ;)
Who said anything about missiles? I'd like it for tunnels, city canyons, and inside of buildings where GPS does not work well. It would allow continuous GPS tracks even if part of the path was not covered by GPS. As long as the resolution of the accelerometer and gyro were good data from them could be used to fill in the gaps of the GPS path.

Sorry, bad joke.

QUOTE

Look at www.SMSC.com for Hubs. I have not used their parts, but an off the shelf 7 port USB hub using an IC from SMSC did not have the same problems I ran into with the philips 7 port hub IC that I have used.
NEC makes USB parts, but it is difficult to get data sheets from them.
For USB slave devices, look at cypress. They have a USB High Speed micro-controller for about $10. It uses an 8051 micro-controller architecture that has some annoying quirks, and is very slow, but it can also be set up so the data transfers bypass the 8051, and in that mode can operate at the full USB High Speed 480 mb/s throughput.


Thanks for those links - I arrived at SMSC after a search on Mouser and they look like the front runner for hub chips. Prices start around $7 in single quantities. However, the enclosure becomes a bit more challenging if one were to create a two port hub.

For slaves I've been looking at the AVR micros. They have an 8 bit core with USB built in - but, what I've been mostly concentrating on is a software implementation of USB on an ATiny45 (or similar) - that's what this guy did: http://www.harbaum.org/till/tiltstick/index.shtml
 
Last edited by a moderator:
EdCa22 said:
I also think using USB is overkill,

How so? A USB solution can be done in two chips - an accelerometer that outputs analog voltages for each axes and a small microprocessor (e.g. ATiny45) to do A/D from the accel plus a software implementation of USB. These chips would cost about $6.5 and $2 respectively. An I2C solution would be just one chip but would cost about $14. The I2C would only likely need 2 or 4 additional components to complete the design and the USB version comes in at an additional 17 components (however it's still only a total cost of $12 for the complete solution).

So, the I2C is lower component count but more expensive. The USB is less expensive and also could have wider appeal.

QUOTE

and also that internal would be best, I'm sure we can find room!
But would void folks' warranties and would limit the availability to folks with enough practical skills to open the case and wire up the device.

QUOTE

No one has mentioned SPI bus yet, which I'm pretty sure is available both internally and on the EXT connector.


Yeah, SPI is a possibility as well. But I think it has the same characteristics as the I2C (more capable but more expensive)

QUOTE

And also there are already tonnes of small, ready made boards that will do this for you.


Yeah, these were my inspiration - but I wanted to create something that was a bit more finished off and ready for the end user. For an internal mod using I2C there's a sparkfun board for $20 that would be all that you needed.

QUOTE

I could see it might be advantageous making a board with accelerometer and compass in one, just from a price point of view (that last one I linked was $149, the other 2 are about $40).


Cost is the main constraint here. I'm not sure the benefit of additional features is "worth it".

QUOTE

I think the gyros I've seen (e.g. the one above) are actually mems accelerometers. Not certain though, can anyone clear that up? I think proper gyros are very expensive, and quite bulky.


Right, I was wondering the same thing - can't the gyroscopic effects be calculated from the accel data? That's what I'm a bit fuzzy about.

QUOTE

I'd be happy to write or help to write any drivers, though I expect there are some similar drivers around already.


It would be great to have your help with that. (DAP if you're still reading along it would be great to have your help too - it sounds like you've worked with the hardware side of things). I'm a noob at hardware design - which is why I'm interested in the project. So additional help is much appreciated. However we'll have to figure out what the overarching goal is. I envisioned a relatively cost effective, easy to use device to encourage "motion based" user interfaces - thus I'm not looking at high-resolution g-sensors and while internal IS better in a LOT of ways there's the warranty/ease of use issues that are difficult to overcome.
 
Last edited by a moderator:
jdh2550 said:
EdCa22 said:
I also think using USB is overkill,

How so? A USB solution can be done in two chips - an accelerometer that outputs analog voltages for each axes and a small microprocessor (e.g. ATiny45) to do A/D from the accel plus a software implementation of USB. These chips would cost about $6.5 and $2 respectively. An I2C solution would be just one chip but would cost about $14. The I2C would only likely need 2 or 4 additional components to complete the design and the USB version comes in at an additional 17 components (however it's still only a total cost of $12 for the complete solution).

So, the I2C is lower component count but more expensive. The USB is less expensive and also could have wider appeal.

I just find the USB bus overkill for a low speed sensor and don't want to have to add a hub. Add to this the effort of design (inc PCB layout) and adding and programming the extra micro (although, if I were to go that route then an AVR is what I'd choose :) ) and it's definently a turn off for me. I also suspect that by the time you've created the whole system (including PCB fabrication etc) and added a USB hub you will have cost more or less the same as buying one of those ready made $20 boards, as well as all that extra time.
QUOTE
QUOTE

and also that internal would be best, I'm sure we can find room!


But would void folks' warranties and would limit the availability to folks with enough practical skills to open the case and wire up the device.

I do conceed that most people would not be willing to do this, and that's fair enough. However, if you wanted to put one of the sparkfun boards externally using SPI/I2C then probably all you need is an EXT port connector and a case, assuming there is power available from the EXT port that is, and you've still got your USB free. You could also add a pass through connector so that you can still use the EXT for other things. I have to say that I will probably just get one of the sparkfun boards and put it inside though.

QUOTE
QUOTE

I could see it might be advantageous making a board with accelerometer and compass in one, just from a price point of view (that last one I linked was $149, the other 2 are about $40).


Cost is the main constraint here. I'm not sure the benefit of additional features is "worth it".

Depends entirely on whether you want a compass or not, surely? All I was saying here was that you could easily add a compass to any of these things we are talking about and still come to way less than the all-in-one chip solution I posted that costs $149. I am considering a small PCB based on SPI/I2C purely so that I don't have to fit 2 of those sparkfun boards (or similar) inside the pandora (one compass and one acc).

QUOTE

Right, I was wondering the same thing - can't the gyroscopic effects be calculated from the accel data? That's what I'm a bit fuzzy about.



Technically, yes. You have to integrate the data, however drift is a big problem so you have to reset your integration frequently; it cannot be used to accurately calculate velocity or distance changes over any large time lapse. However, for small changes (e.g. moving the device in your hands and the movement of an on-screen ball is immediately shown) it's no problem. What I'm saying is, you can't use it for navigation, for example, or even for really finding the position displacement of the sensor within a fairly small space - you will very quickly get errors. However, combining it with another sensor and/or using a clever algorithm (e.g. kalman filter) will help a lot - e.g. for the Wii they have optical sensors, so that they can cancel out the drift periodically.

QUOTE
QUOTE

I'd be happy to write or help to write any drivers, though I expect there are some similar drivers around already.


It would be great to have your help with that. (DAP if you're still reading along it would be great to have your help too - it sounds like you've worked with the hardware side of things). I'm a noob at hardware design - which is why I'm interested in the project. So additional help is much appreciated. However we'll have to figure out what the overarching goal is. I envisioned a relatively cost effective, easy to use device to encourage "motion based" user interfaces - thus I'm not looking at high-resolution g-sensors and while internal IS better in a LOT of ways there's the warranty/ease of use issues that are difficult to overcome.


Clearly the issue we have here is that we have different desires for similar aims, and I completely understand that a simple USB module has much greater mass appeal. I am coming at this from a 'how can I get an accelerometer into my pandora in the easiest and quickest way" perspective while you are thinking of a design or product for mass useage...I am also thinking about a compass, while it is likely many people wont need one. I do think you should consider using SPI or I2C on the EXT connector though...

What we should be careful of is to create, or use an existing, standard API for software to read from these types of devices, either in kernel space or in a userspace library. If we have a unified interface then implementation differences will not matter from a software developer or user perspective.
 
Last edited by a moderator:
EdCa22 said:
I just find the USB bus overkill for a low speed sensor and don't want to have to add a hub. Add to this the effort of design (inc PCB layout) and adding and programming the extra micro (although, if I were to go that route then an AVR is what I'd choose :) ) and it's definently a turn off for me. I also suspect that by the time you've created the whole system (including PCB fabrication etc) and added a USB hub you will have cost more or less the same as buying one of those ready made $20 boards, as well as all that extra time.

...

I do conceed that most people would not be willing to do this, and that's fair enough. However, if you wanted to put one of the sparkfun boards externally using SPI/I2C then probably all you need is an EXT port connector and a case, assuming there is power available from the EXT port that is, and you've still got your USB free. You could also add a pass through connector so that you can still use the EXT for other things. I have to say that I will probably just get one of the sparkfun boards and put it inside though.

...

QUOTE
Cost is the main constraint here. I'm not sure the benefit of additional features is "worth it".
Depends entirely on whether you want a compass or not, surely? All I was saying here was that you could easily add a compass to any of these things we are talking about and still come to way less than the all-in-one chip solution I posted that costs $149. I am considering a small PCB based on SPI/I2C purely so that I don't have to fit 2 of those sparkfun boards (or similar) inside the pandora (one compass and one acc).


I'm starting to lean back towards an I2C solution. Plugged into the "AV" port for the masses, hardwired internally for the brave (see the Developer thread for availability of I2C bus). The one thing that I'd like to figure out how to do is to auto detect the plugging or unplugging of the external sensor. Any ideas about that?


QUOTE

QUOTE

Right, I was wondering the same thing - can't the gyroscopic effects be calculated from the accel data? That's what I'm a bit fuzzy about.



Technically, yes. You have to integrate the data, however drift is a big problem so you have to reset your integration frequently; it cannot be used to accurately calculate velocity or distance changes over any large time lapse. However, for small changes (e.g. moving the device in your hands and the movement of an on-screen ball is immediately shown) it's no problem. What I'm saying is, you can't use it for navigation, for example, or even for really finding the position displacement of the sensor within a fairly small space - you will very quickly get errors. However, combining it with another sensor and/or using a clever algorithm (e.g. kalman filter) will help a lot - e.g. for the Wii they have optical sensors, so that they can cancel out the drift periodically.


Ahh, now I get it! Thanks for that explanation - it clarifies things for me.


QUOTE
QUOTE
QUOTE

I'd be happy to write or help to write any drivers, though I expect there are some similar drivers around already.


It would be great to have your help with that. (DAP if you're still reading along it would be great to have your help too - it sounds like you've worked with the hardware side of things). I'm a noob at hardware design - which is why I'm interested in the project. So additional help is much appreciated. However we'll have to figure out what the overarching goal is. I envisioned a relatively cost effective, easy to use device to encourage "motion based" user interfaces - thus I'm not looking at high-resolution g-sensors and while internal IS better in a LOT of ways there's the warranty/ease of use issues that are difficult to overcome.


Clearly the issue we have here is that we have different desires for similar aims, and I completely understand that a simple USB module has much greater mass appeal. I am coming at this from a 'how can I get an accelerometer into my pandora in the easiest and quickest way" perspective while you are thinking of a design or product for mass useage...I am also thinking about a compass, while it is likely many people wont need one. I do think you should consider using SPI or I2C on the EXT connector though...



Absolutely - this thread started with a poll meant to highlight I'm looking at a "mass market" (well, not really mass just greater than you can count on your fingers and toes). If it's only applicable to the pandora (because of the custom AV connector) then that's probably not such a bad thing. I really don't think a device such as this would take the PC world by storm.

It's really a case of KISS isn't it? I guess I was veering away from simple into stupid. :)

QUOTE

What we should be careful of is to create, or use an existing, standard API for software to read from these types of devices, either in kernel space or in a userspace library. If we have a unified interface then implementation differences will not matter from a software developer or user perspective.



Agreed.

Here's my current thinking (not an attempt at a spec just a collection of thoughts)

(1) A device plugged into the external port using an I2C chip. For ease of use it should be auto-detecting. For convenience it might offer a pass through connection.
(2) the sparkfun board (or similar) for anyone who wants to put one internal
(3) driver (kernel space) to make the device look like a joystick for easiest integration into games
(4) additional space on the pcb to add one or two additional I2C sensors (compass, gyro, coffee maker...) - a convenience for hobbyists and likely not difficult to allow for in the design.
(5) separate drivers for each individual I2C sensor

So, I'm off to read up on the linux i2c implementation.

Thanks to everyone for their input. Keep it coming. And of course I might still change my mind again (which is the whole point of getting input early on in a project, right?).

As I get closer to settling on a solution I'll likely do another poll to check some of my assumptions.

This is fun :)
 
Last edited by a moderator:
The USB extension could also act as a USB hub (with one or more ports).
 
jdh2550 said:
Here's my current thinking (not an attempt at a spec just a collection of thoughts)

(1) A device plugged into the external port using an I2C chip. For ease of use it should be auto-detecting. For convenience it might offer a pass through connection.
(2) the sparkfun board (or similar) for anyone who wants to put one internal
(3) driver (kernel space) to make the device look like a joystick for easiest integration into games
(4) additional space on the pcb to add one or two additional I2C sensors (compass, gyro, coffee maker...) - a convenience for hobbyists and likely not difficult to allow for in the design.
(5) separate drivers for each individual I2C sensor
That sounds reasonable, I think you covered what most people'd want. I'm leaning towards internal myself, assuming there's enough room in the pandora's case.
 
Last edited by a moderator:
I2C does not have any defined protocol for plug & play. Each device has a 7 bit address, and since these devices are usually hardwired to the motherboard, there is no detection, the devices are just assumed to be there.

I don't believe that there is I2C on the expansion port, though there should be a means of implementing I2C through the expansion port. There is no protocol defined yet to recognize a device plugged into the expansion port. So far, it looks like the old ISA bus where you installed drivers, and set interrupt jumpers on the card.

I2C is certainly the best choice for your first project. You won't need to worry about voltage regulators, transmission lines, or trying to probe 480 MHz signals. With I2C you have a much higher probability of getting the project to work the first time.
 
jdh2550 said:
Adding that stuff would likely push up the price by another $20 or $30. What does a gyro give you that an accelerometer doesn't (sorry if that's dumb question)
Quite a bit if you don't have some other means to compensate for angular momentum- how can you tell the linear accelerations are due to movement in a direction or rotation in a given direction (which the accelerometer would see the same way...)?

QUOTE

I2C for internal would be easier because it would take less space. But until we get our units we won't know how small it needs to be.


I2C would have to be integrated directly onto the Pandora... Not for the faint of heart to say the least. ;)
 
Last edited by a moderator:
DAP said:
I don't believe that there is I2C on the expansion port, though there should be a means of implementing I2C through the expansion port. There is no protocol defined yet to recognize a device plugged into the expansion port. So far, it looks like the old ISA bus where you installed drivers, and set interrupt jumpers on the card.
A software based implementation of I2C will be available via UART3 which is 2 pins on the external connector (per MWeston).
 
Last edited by a moderator:
Svartalf said:
I2C would have to be integrated directly onto the Pandora... Not for the faint of heart to say the least. ;)
Actually, it's available on the external connector (see above). There is also an internal I2C bus that could be "tapped into" internally - and you're right that would take a steady hand with a soldering iron!
 
Last edited by a moderator:
FYI after very much googling it seems the device I want already exists. It's a little more expensive than I was hoping but Linux software is available. I know you guys are looking at internal solutions, but the info might be useful for some reading this thread :)
 
EdCa22 said:
jdh2550 said:
QUOTE

I think the gyros I've seen (e.g. the one above) are actually mems accelerometers. Not certain though, can anyone clear that up? I think proper gyros are very expensive, and quite bulky.
Right, I was wondering the same thing - can't the gyroscopic effects be calculated from the accel data? That's what I'm a bit fuzzy about.


Technically, yes. You have to integrate the data, however drift is a big problem so you have to reset your integration frequently; it cannot be used to accurately calculate velocity or distance changes over any large time lapse. However, for small changes (e.g. moving the device in your hands and the movement of an on-screen ball is immediately shown) it's no problem. What I'm saying is, you can't use it for navigation, for example, or even for really finding the position displacement of the sensor within a fairly small space - you will very quickly get errors. However, combining it with another sensor and/or using a clever algorithm (e.g. kalman filter) will help a lot - e.g. for the Wii they have optical sensors, so that they can cancel out the drift periodically.


I've been thinking a bit more about this and realised I misinterpreted your question. Everything I said above is true, but relates specifically to deriving velocity or position (either rotational or linear) from acceleration data. This is a valid issue, but what we both really wanted to know is how we can get 6 axis acceleration data. After some research it turns out that what we are after is a 3 axis linear accelerometer and a 3 axis rate sensor/gyroscope, as we were first discussing. The rate sensor turns out to be much more difficult to find...


(yeah I haven't quite got quotes figured out yet on here:)
QUOTE

Svartalf Posted Yesterday, 09:19 PM

jdh2550 said:
*

Adding that stuff would likely push up the price by another $20 or $30. What does a gyro give you that an accelerometer doesn't (sorry if that's dumb question)


Quite a bit if you don't have some other means to compensate for angular momentum- how can you tell the linear accelerations are due to movement in a direction or rotation in a given direction (which the accelerometer would see the same way...)?
...and now we've come full circle...so we need an gyro as well...

I've been doing a lot of reading on this and we are going to have a tough time if we really need 6 axis...those integration problems and drift I spoke of above will cause a massive headache, and as Svartalf says accelerometers are always to some extent affected by the angular movement even though they are designed to measure linear acceleration...stability and repeatability are a big problem which is why you need to keep recalibrating for the zero G bias...which drifts with temperature..does the pandora have a temperature sensor? I guess we first need to have access to the sensor data and then we can try and build some sort of filter, perhaps using a kalman to try to remove the effects of changes in orientation on the linear accelerometer and vice versa for the gyros. The DSP in the OMAP will be useful for this. The big advantage we have is that we aren't looking for a really accurate device...maybe we will get away with it for that reason because it is not like we are building a missile or a plane!

We still need to find suitable gyros though...

EDIT:

Okay, I think maybe if you use a 3 axis accelerometer you can sense any of the 6 axis (linear or angular) but your software can only use 3 of these axis at a time...and you just assume the user is not using more than that. I suspect this is how the Wii and playstation etc do it. Maybe a single gyro or a 2 axis gyro (which I have seen) can then also be used to determine if someone rotates the screen from landscape to portrait etc, or maybe it's just semi-clever software I'm not sure... but I am now obsessed with finding an easy way to get 6 axis sensing... currently researching magneto-impedance sensors...

Man I really have to do some work today...
 
Last edited by a moderator:
Dunny said:
Couldn't vote, as although I chose "not interested", I still have to choose how I'd like it implemented!

How are you going to get a good idea of how many people *don't* want this if they're gonna have to vote that they do?
What I love is that out of the 41 people who don't want it, at least 17 have said they'll pay $25 or more for it. :D
 
Last edited by a moderator:
DAP said:
Who said anything about missiles? I'd like it for tunnels, city canyons, and inside of buildings where GPS does not work well. It would allow continuous GPS tracks even if part of the path was not covered by GPS. As long as the resolution of the accelerometer and gyro were good data from them could be used to fill in the gaps of the GPS path.
Not reliably. You'd need a compass for that. The problem is that accellerometer and gyro error when tracking a path rapidly extends with time so you need a way to compensate for that. GPS for position and compass for direction.

With a gyro, it's very important where on the Pandora the device is placed because that will be the middle point of the rotation axis. I think at the top (under the hinge) would work. Where are the relevant ports placed in the final hardware design?

I love the idea of including a USB hub in it. A device that exposes two or three USB ports supporting all speeds from the powered USB port and includes accellerometer/compass/maybe gyro could be very awesome. It could also be useful for other devices than the Pandora. While we're at it, maybe include an IR LED for remote controlling TVs and talking to Palms and Game Boy Colors? Anything else we are missing? :D

I think compass would be more useful than gyro because rotating the Pandora quickly for gaming isn't really practical. (Around one axis maybe...) A compass could provide rotation information as well (though probably slower and less precise) and would work well with a GPS.
 
Last edited by a moderator:
Klepto said:
FYI after very much googling it seems the device I want already exists. It's a little more expensive than I was hoping but Linux software is available. I know you guys are looking at internal solutions, but the info might be useful for some reading this thread :)


Hi Klepto,

Yep, there are other devices out there for almost all of this stuff. Primarily I'm looking at a low cost solution mostly for driving games and to satisfy my desire to do a hardware project that's useful for the community.



OrR said:
I love the idea of including a USB hub in it. .... Anything else we are missing? :D
I know you were joking but that's actually why I've decided to steer clear of a USB hub + accelerometer + other stuff. Because it's next to impossible to decide which is the right set of stuff to include in such a device. That's one of the reasons I'm leaning towards the KISS solution - an I2C solution plugged into the external port. This will likely be able to work in tandem with folks who want to do internal solutions and also folks who want higher capabilities than just gaming controls.

So, to folks discussing gyro's and compasses - thanks for the info and the education (and feel free to use this post to keep it coming!) but I'm back to an accelerometer only I2C solution. I plan to make the I2C solution expandable in some way for folks who want gyro's, compasses and coffee makers.

DAP (and everyone else) - I know I2C doesn't have plug and play as a core feature. However, is there a reasonably efficient way we could fake it? Having a linux driver that polls and looks for the arrival or departure of devices? See this article for the basis of such a driver: http://www.linuxjournal.com/article/7136 Or is there a better hardware based solution that we could do?

Maybe we don't need true plug and play? Maybe we can probe for the device before first usage? If so, how would we set that up to work with "legacy" software (i.e. all software written to date!)
 
Last edited by a moderator:
Just out of interest, how complex would an external I2C solution be? I know pretty much zero about electronics, but I do know how to solder (I used to work in a factory soldering PCBs all day long). Assuming I'm using an I2C module like this would it just be a case of soldering the wires to the relevant pads on the board and mounting it in an enclosure? How would multiple modules be connected?
 
Back
Top