I have been trying to use the vex accelerometer 1.0 to find the position of the robot. I programed it to have a 1 millisecond sampling time to find "instantaneous" acceleration, then update the "instantaneous" velocity, then update the position. When I test this method by finding the position of the robot in the z-axis (the axis affected by gravity), it works pretty well. When I record the position at one second, it comes out to 4.2 meters. The calculated value is .5*a*t^2 = .5*9.8*1 = 4.9 meters. If I multiply by a constant to account for the error, it is fairly accurate when recording the position at most other times(I tested the position at 1 second to 9 seconds in increments of 500 milliseconds). So the accelerometer works for consistent accelerations like gravity. When I try it on other axis' however, the value is off by many meters. Does anyone know how to fix this? Here is my program:

The simplest way to help is to sample more frequently. It works well on the z axis for gravity because gravity is a constant acceleration. Sideways forces (driving, steering, etc) are almost never constant acceleration. Since the acceleration is constantly changing, you are missing however much it changes in 1ms.

Accelerometers are really not the greatest absolute positioning devices, especially if you can't have a very high sample rate. If I were to do the same project (absolute positioning)(different microcontroller) I would sample the accelerometer at the fastest speed possible, bare minimum once every 10us, and better closer to 1us (1Mhz.) To get that high a speed, I would seriously consider using a separate microcontroller that I would query for position information over a serial interface. Obviously, if you are doing the Vex competitions, that isn't an option, so all you can do is try to sample faster, and remember that RobotC introduces overhead for the task control and hardware interfaces.

You may also want to test over your code for finding the 0G value. I have a MMA7260QT accelerometer, and I don't remember the 0G value being the same on different axis.

Also, your "error" constant may simply be the conversion between what you measure and the distance in meters. The accelerometer doesn't read out in meters/sec^2, its just a proportional value.

I thought about using faster sampling rates, but robotC only lets you sample in 1 milliseconds. I suppose that I could find out how many while loops it take to go through in 1 microsecond, but I son't know it it's worth the trouble.



If you look at my code, that is what I'm doing. Since all the axis' look to be the same value for gravity, I take the difference between 0G and 1G and divide it by 9.8m/s^2 to get the conversion ratio.

Thanks for the input.

Ah, well done. I missed those two lines of code the first couple times I read though. (Notice the time stamp, and I'm eastern time (GWM - 5,) so 3:00 AM)

I would take a guess that the error is due to the different center values for the axes.

This question has to be directed to someone who know the RobotC firmware: Does calling SensorValue[accelerometer] actually perform the analog read? or is the analog updated in the background on a certain time interval?

If each call performs an analog read, then you can simply keep calling the reads with no delay between them. Call them sequentially and perform the math on them in that loop. If you want to be able to use delays in your main loop, then this is one situation where the RTOS will be useful. Until we/you get an answer from one of the firmware designers, you can just try running the loop without the delay. Your distance and position values will increase significantly faster, so you will need to make some changes to account for that.

If I don't have a delay in between the reads, then how will I know what sampling time to use? To find the position, I find the acceleration, and add 1/1000 of it to the velocity every millisecond ( because 1 millisecond is 1/1000 of a second), then I add 1/1000 of the velocity to the position every millisecond. If I don't have a delay, how will I know what part of the acceleration and velocity to add to the position?

Educated guess. The Vex Cortex runs at 90 MIPS (so 90Mhz instruction cycle,) and the ADC can sample and convert at least 1Mhz. Unless there is significant overhead from RobotC, you should be able to have a sample time between .5-1Mhz. So start with the appropriate value for .75Mhz, and adjust it up or down as needed to get the proper value at 1G.

While that might seem like a pain and a dumb answer, this is the limit of RobotC. They oversimplified it to the point where you can't even use the power of a Cortex processor. And all that might be in vain anyway if they don't update the analog sensors more than once every 1ms. You can test this by reading the same sensor with no delay and seeing if the value changes between reads, and if not, how long it take for the value to change. If you have the accelerometer connected, just keep it moving.

HINT HINT, RobotC developers! You need to actually use the power that a Cortex gives you! That was the point of having it! The first thing you guys need to add is microsecond timing and timers. I'd like you guys to prove me wrong on my assessment of RC. I used it on the PIC for two separate competitions and it worked well. But there is no good reason to spend $250 for a Cortex that you can't even use, when you can get a Leaflabs Maple for $50 and a free IDE/compiler that works better, and is open source.

If the ROBOTC firmware is anything like the one for the NXT, the sampling frequency is more likely to be in the ms range, rather than ns. For the NXT you're looking at 333Hz (due to the nature of the Atmega). My guess is that it's around 1ms, so at 1KHz.

Does the compiler suite and libraries you use with the Maple (gcc and friends) also do the motor and servo control, wireless remote control and run time debugging? Oh wait, no, I think it probably doesn't Serial printing over the USB cable doesn't count.

There are pros and cons to everything, including gcc and ROBOTC. While ROBOTC may not be the best way to get every last MIP out of your processor, it does make life a lot simpler when it comes to controlling your peripherals. Trust me when I tell you that you that without a butt-load of libraries or a firmware that does this for you, you will spend 80-90% of your time on getting all of those basic things right first before you can even begin to think about the actual programming logic of your robot. Debugging interrupt handlers is about as much fun as having a hairy mole removed with a rusty spoon.

Why are you not using normal encoder ticks and things like that to determine your position?

- Xander

That is what I was doing before I obtained the accelerometer. But I thought that using the accelerometer would free up clutter from the wheels, reduce error due to slippage of the wheels, and just be really, really cool . But it turns out that it's not really that accurate, so back to encoders and ultrasonics.

I've found another use for it though. I built a robotic arm that has the range of motion of a human arm. And if you hold the accelerometer, you can make the robotic arm mimic your arm.

might we see some pics of the arm you have created cause that seems awesome.

If you aren't building this robot for the Vex competition, then one of the best ways I've seen for absolute positioning is using a mouse sensor. I had the two quadrature encoders inside an old ball mouse connected to a PIC Vex MCU, and the mouse was mounted underneath robot such that it ran on the floor. It is very accurate, since you don't have to deal with any play in the wheel movement, and it reads exactly how it move across the ground.

Oh and mightor, the RobotC debugging works by sending serial over the USB, so saying that doesn't count means that RobotC doesn't have any debugging capability either. I would tend to say that both have quite capable debugging capability, although RobotC has it's wrapped up in a bit nicer interface. I'll stop here since this thread is probably not the appropriate place to continue this discussion.

Although, I though you were in on the dev work mightor? Or was that only for the NXT?

Good job getting an arm working, that's not a simple task.

There is a difference between using the serial port for debugging by printing "variable: %d" to it and being able to pause and step a program Unless gdb has been made to work with the Cortex, you will be stuck with doing the printing over serial lines and that can get pretty tedious but certainly not impossible!

I am not one of the devs, although I do do a lot of testing for them and I have a fair number of bugzilla entries on my name I maintain these forums and keep the young whipper snappers in line That and killing off the spammers and their v14gr4 and handbag/running shoes posts.

- Xander

This is our team's submission for the Future Foundation Design Challenge. It includes the arm and video of it moving according to the accelerometer.

http://www.youtube.com/user/campcookies ... 5tPkMS1_h8

That is a very cool robot. I like the video you guys made! Nice job

You should submit it to the "cool projects" thread!

- Xander

Thanks! I have submitted it to the cool projects thread now. By the way, here is a video description about it's internal workings: http://www.youtube.com/watch?v=gg-71oAIovs

I haven't tried this personally, but it seems like integrating from relatively low-frequency sensor readings using the simple assumption that the integral of acceleration over time interval t0 to t1 (assuming you measure acceleration a1 at time t1) is about

a1 * (t1 - t0)

is going to be numerically unstable anyway because your samples are so far apart in time (and as you pointed out, accel isn't particularly constant over a millisecond). But you can improve this situation by changing your code instead of using better hardware/microsecond timing/etc or going to shaft encoders.

Suppose we assume that the acceleration was a linear function of time over the time interval since your last reading instead of a constant and integrate that (technically, this is called the trapezoid rule). That would require you to remember your last acceleration value (let's say a0). So if you had readings a0 and a1 for acceleration at times t0 and t1, the integral of acceleration over the interval t0 to t1 would be approximated by

((a0 + a1)/2)*(t1 - t0).

Of course, it's even better to remember your last two acceleration readings (and times) and fit a quadratic equation to these three points and integrate THAT (Simpson's rule). The formula for that is sort of sticky if the samples occur at different times, but I'll include it for you here: If you have acceleration readings a0, a1, and a2 at times t0, t1, and t2, the integral of acceleration over the interval t1 to t2 turns out to be:

-(((a2 (t0 - t1) (3 t0 - t1 - 2 t2) + a1 (t0 - t2) (3 t0 - 2 t1 - t2) - a0 (t1 - t2)^2) (t1 - t2))/(6 (t0 - t1) (t0 - t2)))

This will be a lot more accurate than your current code, and it's not much harder to write. Of course, you can and should do something similar as you integrate velocity to obtain position. I'd be really interested to know if you try this to see how it works out.

Math: It is the robot-builder's friend.