Go to Post This web site is a service by our team to the FIRST Community to foster interest and growth in Engineering, the FIRST Competition and Education of youth for the careers of tomorrow. - Mike Martus [more]
Home
Go Back   Chief Delphi > Technical > Electrical
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Closed Thread
Thread Tools Rating: Thread Rating: 2 votes, 5.00 average. Display Modes
  #1   Spotlight this post!  
Unread 16-01-2014, 14:06
mickztlin mickztlin is offline
Y_SO_CRIO
FRC #2637
Team Role: Electrical
 
Join Date: Feb 2012
Rookie Year: 2011
Location: Rancho palos verdes
Posts: 26
mickztlin can only hope to improve
Cool Accelerometers and speed

So we have had a few accelerometers laying around and I was thinking about what can we use them for. I was thinking about using them to do speed and distance readout for testing our drive train. Im currently in physics c so I understand it does not read off velocity but acceleration, but couldn't I use the kinematic: (at+v_i)=vf and as long as i know we are starting with no velocity find speed and distance final. Would this work and what are some challenges with doing this
__________________
To the victors go the swarf!
  #2   Spotlight this post!  
Unread 16-01-2014, 14:14
magnets's Avatar
magnets magnets is offline
Registered User
no team
 
Join Date: Jun 2013
Rookie Year: 2012
Location: United States
Posts: 748
magnets has a reputation beyond reputemagnets has a reputation beyond reputemagnets has a reputation beyond reputemagnets has a reputation beyond reputemagnets has a reputation beyond reputemagnets has a reputation beyond reputemagnets has a reputation beyond reputemagnets has a reputation beyond reputemagnets has a reputation beyond reputemagnets has a reputation beyond reputemagnets has a reputation beyond repute
Re: Accelerometers and speed

You are correct, you can take the integral of acceleration to get your changes in velocity, but the sensor is not really accurate enough to get a reliable velocity. The accuracy of your current velocity depends on how accurate you were a second ago, which depends on how accurate you were before that....

Just like when you integrate the angular rate given by a gyro, and drift is present over long periods of time, your velocity will drift, but a lot more. Getting an encoder on the shaft is one way to measure velocity, but they can be hard to work in if you've already started designing.

You can use an optical sensor and paint half a shaft white and the other half black, and measure velocity based of the frequency of the change from white to black.
  #3   Spotlight this post!  
Unread 16-01-2014, 14:18
Joe Ross's Avatar Unsung FIRST Hero
Joe Ross Joe Ross is offline
Registered User
FRC #0330 (Beachbots)
Team Role: Engineer
 
Join Date: Jun 2001
Rookie Year: 1997
Location: Los Angeles, CA
Posts: 8,599
Joe Ross has a reputation beyond reputeJoe Ross has a reputation beyond reputeJoe Ross has a reputation beyond reputeJoe Ross has a reputation beyond reputeJoe Ross has a reputation beyond reputeJoe Ross has a reputation beyond reputeJoe Ross has a reputation beyond reputeJoe Ross has a reputation beyond reputeJoe Ross has a reputation beyond reputeJoe Ross has a reputation beyond reputeJoe Ross has a reputation beyond repute
Re: Accelerometers and speed

While this is theoretically possible, in the real world, with cheap accelerometers, it isn't practical. Small errors in acceleration add up over time and produce poor velocities and even worse distances.

A similar process is used for the gyro (which gives angular rate) and to get angle. The cRIO FPGA does the calculation at a very high rate (1000s of samples per second), which wouldn't be possible in software. Even so, the gyro angle drifts by many degrees by the end of a match.

It's possible that you might get decent velocity results for a short period. If you wanted to experiment with this, I would look at how the gyro software was implemented and copy that.
  #4   Spotlight this post!  
Unread 16-01-2014, 14:35
mickztlin mickztlin is offline
Y_SO_CRIO
FRC #2637
Team Role: Electrical
 
Join Date: Feb 2012
Rookie Year: 2011
Location: Rancho palos verdes
Posts: 26
mickztlin can only hope to improve
Talking Re: Accelerometers and speed

Thanks for the advice, the idea was just something we were playing around with so we may try just for fun (if we have time)
__________________
To the victors go the swarf!
  #5   Spotlight this post!  
Unread 16-01-2014, 15:09
faust1706's Avatar
faust1706 faust1706 is offline
Registered User
FRC #1706 (Ratchet Rockers)
Team Role: College Student
 
Join Date: Apr 2012
Rookie Year: 2011
Location: St Louis
Posts: 498
faust1706 is infamous around these partsfaust1706 is infamous around these parts
Re: Accelerometers and speed

You should expect cheap hardware to not work perfectly, and a gyro and accelerometer is no exception to this rule. Some hardware you can get away with not being perfect, but not these two.

As someone else has mentioned, the gyro measures degrees/sec, so you must integrate it to get degrees. In a perfect world, the integration would be correct, but there is a delay in points on the graph, aka the "function" of degrees/sec is not continuous but rather just a collection of points.

We are still using a gyro this year. It runs through ardiuno and apparently is better than the KOP one. A clever method to combat this would be to calculate yaw from vision (yaw is heading on the field), then every once in awhile (once a second or so) replace the gyro reading with the solution vision gets. This is the method we are using.
__________________
"You're a gentleman," they used to say to him. "You shouldn't have gone murdering people with a hatchet; that's no occupation for a gentleman."
  #6   Spotlight this post!  
Unread 16-01-2014, 15:09
Michael Hill's Avatar
Michael Hill Michael Hill is offline
Registered User
FRC #3138 (Innovators Robotics)
Team Role: Mentor
 
Join Date: Jul 2004
Rookie Year: 2003
Location: Dayton, OH
Posts: 1,580
Michael Hill has a reputation beyond reputeMichael Hill has a reputation beyond reputeMichael Hill has a reputation beyond reputeMichael Hill has a reputation beyond reputeMichael Hill has a reputation beyond reputeMichael Hill has a reputation beyond reputeMichael Hill has a reputation beyond reputeMichael Hill has a reputation beyond reputeMichael Hill has a reputation beyond reputeMichael Hill has a reputation beyond reputeMichael Hill has a reputation beyond repute
Re: Accelerometers and speed

Quote:
Originally Posted by Joe Ross View Post
While this is theoretically possible, in the real world, with cheap accelerometers, it isn't practical. Small errors in acceleration add up over time and produce poor velocities and even worse distances.

A similar process is used for the gyro (which gives angular rate) and to get angle. The cRIO FPGA does the calculation at a very high rate (1000s of samples per second), which wouldn't be possible in software. Even so, the gyro angle drifts by many degrees by the end of a match.

It's possible that you might get decent velocity results for a short period. If you wanted to experiment with this, I would look at how the gyro software was implemented and copy that.
I always thought the drift of a gyro was predictable and you could correct the drift in code.
  #7   Spotlight this post!  
Unread 16-01-2014, 15:36
JohnGilb JohnGilb is offline
Programming Mentor, Drive Mentor
FRC #0488
 
Join Date: Mar 2011
Rookie Year: 2003
Location: Redmond, WA
Posts: 116
JohnGilb has a spectacular aura aboutJohnGilb has a spectacular aura aboutJohnGilb has a spectacular aura about
Re: Accelerometers and speed

Some drift may be predictable - you might notice that your gyro has a pretty constant 0.05 degree/second drift in one direction. You could compensate for that in software (and probably should!).

However, as you look closer and closer at the drift, trying to compensate more and more accurately (hmm, looks like it was 0.051, or maybe 0.05102...), you'll eventually hit a point where the drift is no longer predictable - the drift is essentially small and random in both directions.

Essentially, the more expensive / higher quality a gyro you have, the smaller that "noise" value is. Also, operating in ideal conditions (temperature-controlled, constant voltages) will reduce that noise further.

But it won't be totally eliminated, and these errors accumulate.
  #8   Spotlight this post!  
Unread 16-01-2014, 19:34
yash101 yash101 is offline
Curiosity | I have too much of it!
AKA: null
no team
 
Join Date: Oct 2012
Rookie Year: 2012
Location: devnull
Posts: 1,191
yash101 is an unknown quantity at this point
Re: Accelerometers and speed

If you have vision tracking, you could use processing to automatically recalibrate the gyro/accelerometer. For speed, as already mentioned before, encoders are your friends, not accelerometers!
  #9   Spotlight this post!  
Unread 16-01-2014, 21:14
mickztlin mickztlin is offline
Y_SO_CRIO
FRC #2637
Team Role: Electrical
 
Join Date: Feb 2012
Rookie Year: 2011
Location: Rancho palos verdes
Posts: 26
mickztlin can only hope to improve
Red face Re: Accelerometers and speed

My intention was something we could simply strap onto the robot instead of an encoder (what we used in previous years) but that ended up to be easier.
__________________
To the victors go the swarf!
  #10   Spotlight this post!  
Unread 17-01-2014, 17:19
otherguy's Avatar
otherguy otherguy is offline
sparkE
AKA: James
FRC #2168 (The Aluminum Falcons)
Team Role: Mentor
 
Join Date: Feb 2010
Rookie Year: 2009
Location: CT
Posts: 443
otherguy is a splendid one to beholdotherguy is a splendid one to beholdotherguy is a splendid one to beholdotherguy is a splendid one to beholdotherguy is a splendid one to beholdotherguy is a splendid one to beholdotherguy is a splendid one to behold
Re: Accelerometers and speed

You could look at using an IMU.

FRC 2465 is selling one they built: www.kauailabs.com/store

Some more info here: http://www.chiefdelphi.com/forums/sh...d.php?t=124379
__________________
http://team2168.org

Last edited by otherguy : 17-01-2014 at 17:21. Reason: added cd thread about nav6 imu
  #11   Spotlight this post!  
Unread 17-01-2014, 22:25
John's Avatar
John John is offline
Registered User
AKA: John Gillespie
FRC #1153 (Roborebels)
Team Role: Mechanical
 
Join Date: Sep 2011
Rookie Year: 2009
Location: Walpole MA
Posts: 71
John is just really niceJohn is just really niceJohn is just really niceJohn is just really niceJohn is just really nice
Re: Accelerometers and speed

Quote:
Originally Posted by otherguy View Post
You could look at using an IMU.
An IMU is a set of accelerometers and gyroscopes (in this three accelerometers and three gyros to detect all 6 degrees of freedom). The nav6 includes a magnetometer, which may help mitigate gyro drift, but won't do anything for linear acceleration.

In general, you may have success with an accelerometer (or an IMU containing one) if your margin for error is large enough (say, if you just want to drive forward ~8-12 feet in auto to pick up the 5 points, and want a sensor instead of timing). But if you want really accurate positioning you will probably need a different sensor (probably encoders).
  #12   Spotlight this post!  
Unread 18-01-2014, 01:35
slibert slibert is offline
Software Mentor
AKA: Scott Libert
FRC #2465 (Kauaibots)
Team Role: Mentor
 
Join Date: Oct 2011
Rookie Year: 2005
Location: Kauai, Hawaii
Posts: 359
slibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud of
Re: Accelerometers and speed

Quote:
Originally Posted by John View Post
An IMU is a set of accelerometers and gyroscopes (in this three accelerometers and three gyros to detect all 6 degrees of freedom). The nav6 includes a magnetometer, which may help mitigate gyro drift, but won't do anything for linear acceleration.

In general, you may have success with an accelerometer (or an IMU containing one) if your margin for error is large enough (say, if you just want to drive forward ~8-12 feet in auto to pick up the 5 points, and want a sensor instead of timing). But if you want really accurate positioning you will probably need a different sensor (probably encoders).
As we developed the nav6, we developed code to calculate linear acceleration. Given the digital motion processing that fuses the gyro/accellerometer and the sensor calibration that's automatically performed, a reasonably accurate estimate of the gravity vector is developed. This gravity vector, when adjusted to be relative to the world reference frame and then removed from the raw accelerometer data, yields linear acceleration, which in the X and Y axes is reasonably accurate.

As you've indicated, it really depends the level of accuracy that is required. I don't have nav6 linear acceleration accuracy measures yet, but will try to post them when we've measured them. The linear acceleration measures certainly won't be perfect, since an IMU uses estimation techniques during the gyro/accelerometer fusion.

Of course, wheel slip and encoder decode tracking error can also be introduce inaccuracies in certain cases, so encoders pose challenges, too.

One of the nice ideas I've seen discussed on Chief Delphi is fusing the encoder data from the drive wheels w/the linear acceleration (like that calculated by the nav6). These two data streams would be fused by a Kalman Filter (or perhaps more simply by a complementary filter approach) which would be tuned to use the encoder data - unless wheel slip was detected in which case the IMU-generated linear acceleration measures would be used until the slippage had subsided.

I'm curious as to others thoughts on this idea, as I'm thinking this would be a nice research and development project that we could work on during the off-season and make available to the community if there was interest.....

Last edited by slibert : 18-01-2014 at 01:43.
  #13   Spotlight this post!  
Unread 18-01-2014, 02:14
efoote868 efoote868 is offline
foote stepped in
AKA: E. Foote
FRC #0868
Team Role: Mentor
 
Join Date: Mar 2006
Rookie Year: 2005
Location: Noblesville, IN
Posts: 1,425
efoote868 has a reputation beyond reputeefoote868 has a reputation beyond reputeefoote868 has a reputation beyond reputeefoote868 has a reputation beyond reputeefoote868 has a reputation beyond reputeefoote868 has a reputation beyond reputeefoote868 has a reputation beyond reputeefoote868 has a reputation beyond reputeefoote868 has a reputation beyond reputeefoote868 has a reputation beyond reputeefoote868 has a reputation beyond repute
Re: Accelerometers and speed

As others have mentioned, you will get small errors in your measurements which can accumulate when you add them together for a long period of time.

There are things you can do to try and mitigate these errors. For an accelerometer, try to keep the vibrations hitting it as minimal as possible. This means mount it to a most rigid part of your robot (towards the center) with a damper material (such as a soft foam) in between. Also, handle the sensor with care. Every accelerometer I know of has a G tolerance, which will be on the order of 100s -1000s of Gs. Any jerk (think collision or bounce) more than this will ruin your sensor, and you won't be able to tell just by looking at it.

The last thing I'd suggest you do would be to thoroughly test your code and your setup to understand it's limitations - if the error becomes too large after 10 seconds then you probably won't want to use it for more than autonomous mode.
__________________

Be Healthy. Never Stop Learning. Say It Like It Is. Own It. Like our values? Flexware Innovation is hiring!. We're looking for Senior Automation, Software, and System Engineers. Check us out!
Closed Thread


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 19:25.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi