View unanswered posts | View active topics It is currently Mon May 21, 2018 4:59 pm

 Page 1 of 1 [ 15 posts ]
 Print view Previous topic | Next topic
Programming Vex Accelerometer 1.0
Author Message
Moderator

Joined: Tue Sep 14, 2010 9:19 pm
Posts: 496
Programming Vex Accelerometer 1.0
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:

 Code:#pragma config(Sensor, in1,    xAxis,               sensorAccelerometer)#pragma config(Sensor, in2,    yAxis,               sensorAccelerometer)#pragma config(Sensor, in3,    zAxis,               sensorAccelerometer)//*!!Code automatically generated by 'ROBOTC' configuration wizard               !!*//float accelRatio = 0;float yPos = 0;float yVel = 0;float yAccel = 0;float posAt1MSec = 0;float errorFactor = 1.1667;int zYDif = 0;int originalY = 0;task yPosition(){  while(true){    wait1Msec(1);//1 millisecond sampling time    yAccel = (abs(SensorValue[yAxis] - originalY)) > 2 ? (SensorValue[yAxis] - originalY) / accelRatio : 0;    //check if threshold is passed and set "instantanious" acceleration       yVel += (yAccel / 1000);//update "instantainious" velocity    yPos += (yVel / 1000);//update position  }}task main(){  wait1Msec(1000);//give sensor time to settle  originalY = SensorValue[yAxis];//record the y axis value at start  zYDif = SensorValue[zAxis] - originalY;//find the difference between 0G and 1G  accelRatio = zYDif / 9.801;//find sensor value of 1m/s^2  StartTask(yPosition);//start calculating position  wait1Msec(1000);  posAt1MSec = yPos * errorFactor;//record yPos at 1 millisecond, and account for error  while(true){    wait1Msec(1);  }}

_________________
sudo rm -rf /

Thu Jan 27, 2011 4:11 pm
Rookie

Joined: Sat Nov 22, 2008 8:06 pm
Posts: 48
Re: Programming Vex Accelerometer 1.0
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.

Fri Feb 04, 2011 4:00 am
Moderator

Joined: Tue Sep 14, 2010 9:19 pm
Posts: 496
Re: Programming Vex Accelerometer 1.0
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.

 Quote: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.

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.

_________________
sudo rm -rf /

Fri Feb 04, 2011 7:25 am
Rookie

Joined: Sat Nov 22, 2008 8:06 pm
Posts: 48
Re: Programming Vex Accelerometer 1.0
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.

Fri Feb 04, 2011 2:52 pm
Moderator

Joined: Tue Sep 14, 2010 9:19 pm
Posts: 496
Re: Programming Vex Accelerometer 1.0
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?

_________________
sudo rm -rf /

Sat Feb 05, 2011 2:07 pm
Rookie

Joined: Sat Nov 22, 2008 8:06 pm
Posts: 48
Re: Programming Vex Accelerometer 1.0
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.

Sat Feb 05, 2011 4:32 pm

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3654
Location: Rotterdam, The Netherlands
Re: Programming Vex Accelerometer 1.0
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

_________________
| Professional Conduit of Reasonableness
| (Title bestowed upon on the 8th day of November, 2013)
| My Blog: I'd Rather Be Building Robots
| ROBOTC 3rd Party Driver Suite: [Project Page]

Sun Feb 06, 2011 3:50 am
Moderator

Joined: Tue Sep 14, 2010 9:19 pm
Posts: 496
Re: Programming Vex Accelerometer 1.0
 Quote:Why are you not using normal encoder ticks and things like that to determine your position?

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.

_________________
sudo rm -rf /

Sun Feb 06, 2011 9:16 am
Rookie

Joined: Sat Jan 08, 2011 6:56 pm
Posts: 7
Re: Programming Vex Accelerometer 1.0
might we see some pics of the arm you have created cause that seems awesome.

Tue Feb 08, 2011 8:55 pm
Rookie

Joined: Sat Nov 22, 2008 8:06 pm
Posts: 48
Re: Programming Vex Accelerometer 1.0
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.

Thu Feb 10, 2011 1:37 am

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3654
Location: Rotterdam, The Netherlands
Re: Programming Vex Accelerometer 1.0
 Quote: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.

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

_________________
| Professional Conduit of Reasonableness
| (Title bestowed upon on the 8th day of November, 2013)
| My Blog: I'd Rather Be Building Robots
| ROBOTC 3rd Party Driver Suite: [Project Page]

Thu Feb 10, 2011 1:52 am
Moderator

Joined: Tue Sep 14, 2010 9:19 pm
Posts: 496
Re: Programming Vex Accelerometer 1.0
 Quote:might we see some pics of the arm you have created cause that seems awesome

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.

_________________
sudo rm -rf /

Mon Feb 14, 2011 1:09 am

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3654
Location: Rotterdam, The Netherlands
Re: Programming Vex Accelerometer 1.0
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

_________________
| Professional Conduit of Reasonableness
| (Title bestowed upon on the 8th day of November, 2013)
| My Blog: I'd Rather Be Building Robots
| ROBOTC 3rd Party Driver Suite: [Project Page]

Mon Feb 14, 2011 1:53 am
Moderator

Joined: Tue Sep 14, 2010 9:19 pm
Posts: 496
Re: Programming Vex Accelerometer 1.0
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

_________________
sudo rm -rf /

Mon Feb 14, 2011 9:01 pm
Rookie

Joined: Thu Apr 21, 2011 1:27 pm
Posts: 1
Re: Programming Vex Accelerometer 1.0
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.

Thu Apr 21, 2011 1:55 pm
Display posts from previous:  Sort by
 Page 1 of 1 [ 15 posts ]

#### Who is online

Users browsing this forum: No registered users and 2 guests

 You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum

Search for:
 Jump to:  Select a forum ------------------ ROBOTC Applications    ROBOTC for LEGO MINDSTORMS       Third-party sensors    ROBOTC for CORTEX & PIC    ROBOTC for VEX IQ    ROBOTC for Arduino    Robot Virtual Worlds    Multi-Robot Communications    Issues and Bugs Competitions & Partners    Mini Urban Challenge    CS2N Robot Virtual Worlds Competitions       VEX Skyrise Competition 2014-2015       VEX Toss Up 2013-2014       FTC Block Party! 2013-2014    Competitions using VEX - BEST, TSA, VEX, and RoboFest!    FTC Programming    RoboCup Junior and Other ROBOT Competitions Virtual Brick Robotics Discussions    General Discussions    Project Discussions Off-Topic ROBOTC Forum & ROBOTC.net Suggestions/Feedback    ROBOTC Forums Suggestions/Comments    ROBOTC.net Suggestions/Comments       NXT Programming: Tips for Beginning with ROBOTC       VEX Programming: Tips for Beginning with ROBOTC    2013 Robotics Summer Of Learning       VEX Toss Up Programming Challenge       FTC Ring It Up! Programming Challenge    International Forums       Spanish Forums          ROBOTC for MINDSTORMS          ROBOTC for VEX       French Forums          ROBOTC pour Mindstorms          ROBOTC pour IFI VEX       Japanese Forums （日本語のフォーラム）       German Forums    2015 Spring Carnival Event    PLTW (Project Lead The Way)    Robotics Merit Badge    2014 Robotics Academy Summer of Learning