1) Which would be a good buy? I am putting together an order at seeedstudio cause they seem to have all the stuff I need at good prices. I'm thinking of throwing in this accelerometer, but I don't know if it's any good? I also saw that polulo has this cheaper model. So which would be the better buy? Or perhaps a 3rd option?
2) Is it possible to use an accelerometers to measure the distance travelled (by a robot)? According to my logic it should be, because it measures acceleration which is speed squared. So as long as you know the initial speed it should be possible. However I remember reading somewhere that it was quite problematic. Anyone has experiences with this?
3) Any other info on these devices is welcome too :)
PS: For anyone else interested in these things I found this to be an excellent introduction.
It does have more potential and it can detect the minute gforce, but it’s tricky from what I understand to get accurate measurement on distance traveled alone from it.
As far as my own purposes, I’d use it for tilt, acceleration, and sudden deceration detection(hitting a wall or something similar that would stop the bot from moving).
I plan to use it in COMBINATION with a (wheel) encoder. Since both methods are prone to (accumulated) error I’m thinking a setup where the two are constantly double checking on each other.
Here are some interesting quotes from the sparkfun forum I linked to above:
"Integrating an accelerometer signal to get velocity is very practical, especially when you are considering relatively short time periods like a rocket flight or R/C car operation with limited duration. "
“The problem is the small errors. Leave your accel sitting for a few minutes, an hour, and come back. Your distance measurement will read a few miles, and the velocity will be at 0.6c (speed of light). Integrating even a small error leads to problems. To off set this, you need a second sensor - usually GPS. The two keep each other in check and you can actually get some pretty impressive readings when the loop is working”
But so far it’s just an idea I have. Though I intend to see where it might lead me
Added:
Or…since the problem is the accumulated error I could perhaps make sure the robot stops completely say every 10 seconds to “reset” the accelerometer (I may wanna do that anyway to make a range sensor sweep). Then perhaps double checking with the encoder wouldn’t even be necessary. Just a thought
Anyway I’m open to all thoughts and ideas on the matter…
Inertial Measurement Unit - IMU Getting accurate position information involves the use of both accelerometers and gyros. The accels are good for translational motion, but can be fooled by rotational motion that would appear as some type of translation. The gyros are good at detecting rotational motion to help correct the accels, but drift a bit so need the accels to read a stable orientation.
However I’m thinking a MUCH simpler setup to begin with. I’m planning to use it indoors and on a FLAT surface only. To further simplify things I plan to let the robot stop frequently (as mentioned above) and only turn 90 degrees at a time. But it would seem that even that (turning left/right 90 degrees) may “confuse” the accelerometer, and will read as a forward/backward motion?! Which may not be a problem since I will know that the robot is in fact turning…
I’m not sure where to go from here. Perhaps I should just forget about the accelerometer for now and concentrate on using encoders and get a compass instead (now that OddBot’s DIY compass didn’t work out as I had hoped). Or perhaps I should just get one (accelerometer) and start experimenting?! Unfortunately I can’t afford to buy all the things I want right away (bluetooth module, compass, accelerometer, gyroscope, etc…).
They can be virtual bumpers, take a look at the data when the bot hits something. They can give you readings on drift, such as when your bot is on carpet, transferring from carpet to short pile rug or vice versa, every bump causes a wheel or track to slip or slide and yes it will tell you the tilt on both or all 3-axis as well g-force exerted ie acceleration or -g-force as in deceleration.
As far HES compass goes, I’d suggest cranking it up on the op-amp. The magnetic field isn’t weak, but it’s not knock ya down strong either.
You sound like you talk from experience. So I wanna ask:
* What do the readings look like when the robot is turning 1) while staying in the same place 2) while moving forward/backward at the same time? Are these readings distinguishable from simple forward/backward movement?
* According to the statements in the discussions I linked to earlier it IS possible to calculate velocity based on accelerometer readings, allthough it is only useful for a short period of time before the accumulated error becomes to large. So what do you think of my ideas 1) To make the robot stop every ~10 sec to “reset” the accelerometer 2) To use it in combo with a wheel encoder so the two methods will be constantly double checking on each other?
HES compass:
* Since OddBot and CircuitBurn couldn’t come up with a circuit that did the trick between the two of them I don’t think I stand much of a chance, though I might try anyway.
On my 2 axis accelerometer, a Mesmic 2125, I get X and Y readings. Forward on Y-axis is positive, reverse negative, and left turn, creep, drift is positive going right on the X-axis and negative when those things happen when going left.
As far as turns go
1. Only the x axis changes drasticly, the y axis will change a little due to drift and such on an in place turn
2. Both change according to speed and sharpness of the turn
3. Yes they are quite distinguishable and so are bumps in the floor and wall strikes
I’d suggest using as many sensors are you can. You will get false readings, bad data and electronic hiccups, which all add in to the cumulative error. Only way to get rid of the cumulative error is to use different sensors to bring in more data and hope the majority of it is somewhat correct.
Compasses aren’t cheap that is for sure, you either pay for them with money or sweat
