Go to Post MR. KAMEN! TEAR DOWN THIS WALL! - Briansmithtown [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Closed Thread
Thread Tools Rate Thread Display Modes
  #1   Spotlight this post!  
Unread 25-01-2016, 17:11
akavoor13 akavoor13 is offline
Registered User
FRC #4856
 
Join Date: Feb 2013
Location: United States
Posts: 8
akavoor13 is an unknown quantity at this point
Speed Encoders or Gyros?

We are trying to determine whether to use a speed encoder or a gyro. Can someone explain the difference between the two in terms of what they accomplish? Also, any pointers to code samples would be greatly appreciated! Thanks!
  #2   Spotlight this post!  
Unread 25-01-2016, 17:27
billbo911's Avatar
billbo911 billbo911 is offline
I prefer you give a perfect effort.
AKA: That's "Mr. Bill"
FRC #2073 (EagleForce)
Team Role: Mentor
 
Join Date: Mar 2005
Rookie Year: 2005
Location: Elk Grove, Ca.
Posts: 2,384
billbo911 has a reputation beyond reputebillbo911 has a reputation beyond reputebillbo911 has a reputation beyond reputebillbo911 has a reputation beyond reputebillbo911 has a reputation beyond reputebillbo911 has a reputation beyond reputebillbo911 has a reputation beyond reputebillbo911 has a reputation beyond reputebillbo911 has a reputation beyond reputebillbo911 has a reputation beyond reputebillbo911 has a reputation beyond repute
Re: Speed Encoders or Gyros?

Gyro's give you a "Rate of Rotation". Directly reading it will only tell you how fast it is turning. If you integrate the reading over time, you can use it to tell you how far you have turned.

Encoders are typically used to determine how far a shaft has turned. You can figure out how fast it is turning by dividing the distance by an interval of time.

Both have advantages and disadvantages.

As for example code, many samples are available, but we will need to know what you are using to code: LabView, Java, or C++
__________________
CalGames 2009 Autonomous Champion Award winner
Sacramento 2010 Creativity in Design winner, Sacramento 2010 Quarter finalist
2011 Sacramento Finalist, 2011 Madtown Engineering Inspiration Award.
2012 Sacramento Semi-Finals, 2012 Sacramento Innovation in Control Award, 2012 SVR Judges Award.
2012 CalGames Autonomous Challenge Award winner ($$$).
2014 2X Rockwell Automation: Innovation in Control Award (CVR and SAC). Curie Division Gracious Professionalism Award.
2014 Capital City Classic Winner AND Runner Up. Madtown Throwdown: Runner up.
2015 Innovation in Control Award, Sacramento.
2016 Chezy Champs Finalist, 2016 MTTD Finalist
  #3   Spotlight this post!  
Unread 25-01-2016, 17:52
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: Speed Encoders or Gyros?

Quote:
Originally Posted by akavoor13 View Post
We are trying to determine whether to use a speed encoder or a gyro. Can someone explain the difference between the two in terms of what they accomplish? Also, any pointers to code samples would be greatly appreciated! Thanks!
One hopefully helpful way to think about this is to think about the driver joystick input commands and then the actual position (X/Y coordinates on the field - as if you were looking down at a google map of the field, this would indicate where the robot was currently positioned - as well as the angle of rotation of the robot chassis relative to the "head" of the field).

Assume a holonomic drive system (it's conceptually easier to understand). When a driver moves the joystick in the X, Y and Z (rotation) directions, these inputs are translated into commands to the wheels.

The drive system translates these inputs into outputs to the individual wheels using an "inverse kinematic" equation.

So in theory, the encoders will read the amount of actual rotation that occurs. And in theory, these values can then be fed backwards (through the "kinematic" equation) and this can be used to track how far the robot actually traveled. Sounds pretty great, right?

The problem is that in actual practice, the motion that the encoders measure is not the same as the amount of motion that you might expect. For example, the wheels can slip against the carpet when the robot moves. Or the robot could have a collision that would actually cause the robot to lose contact with the floor.

So in actual practice this means:

- you can't use "time" and "motor rates" that are output to the drive system to *accurately* track the position of the robot over time. Some additional feedback (often referred to as "closed loop" processing) is needed.
- if you also use the encoder readings fed back through the kinematics equation to track position change, over time there will be errors.

So, now on to the gyro:

Integrating gyros like the navX-MXP will keep track of the angle of rotation. These values will drift over time, on average approximately 1 degree/minute (less if the robot is still, more if the robot is traveling over bumpy terrain).

So you can use this to keep track of your orientation relative to the field.

And some teams (our team 2465 - Kauaibots - is doing this this year) use both together.

However, since each of these can have issues (encoders due to wheel slip and collisions, and gyros due to drift), we are augmenting that with a camera.

The big idea is that the camera with vision processing can set a target (in relative distance and angle) for the robot to travel to. And then based upon that, the encoder data and the gyro data can be used to track the motion of the robot over a short period of time until it reaches the target.

Cameras are relatively slow updating, wheel encoders and gyros are relatively fast updating, so that works out pretty well.

If it sounds like a bit of work, it is. But this is not that different from the type of processing that goes on in today's advanced driving vehicles like Google Car and the Tesla Model S. So it's a good thing to learn. I'd recommend assessing which of that work your team can handle this year, and then if there's anything beyond that, set it as a stretch goal that you can focus on in the upcoming off-season. Having these skills and experience under your belt will likely be very important if you pursue a career in robotics or other control software development.
  #4   Spotlight this post!  
Unread 25-01-2016, 17:58
akavoor13 akavoor13 is offline
Registered User
FRC #4856
 
Join Date: Feb 2013
Location: United States
Posts: 8
akavoor13 is an unknown quantity at this point
Re: Speed Encoders or Gyros?

Thanks, guys! I am using Java, by the way. If you can tell me where to look for sample code, that would be great!
  #5   Spotlight this post!  
Unread 25-01-2016, 18:08
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: Speed Encoders or Gyros?

Quote:
Originally Posted by akavoor13 View Post
Thanks, guys! I am using Java, by the way. If you can tell me where to look for sample code, that would be great!
It'd help the community to help you if you could indicate what kind of drive system you are using (arcade, omniwheel, mecnaum), how many motors you are using, etc.

As noted in my previous post, you will likely need to understand the "kinematics equation" and the "inverse kinematics equation" for your drive system if you want to use the encoders to track position. These equations are different for each type of drive system, and can take into account your wheel diameter and the distance between your two front wheels and your back and front wheels.

I also highly recommend doing some experimentation on your own (by displaying the values from the encoders on all your wheels on the drive station dashboard). This will help you get a conceptual "feel" for the encoder data and how it relates to the motion of your robot.
  #6   Spotlight this post!  
Unread 25-01-2016, 18:31
BradAMiller BradAMiller is offline
Registered User
AKA: Brad
#0190 ( Gompei and the Herd)
Team Role: Mentor
 
Join Date: Mar 2004
Location: Worcester, MA
Posts: 592
BradAMiller has a brilliant futureBradAMiller has a brilliant futureBradAMiller has a brilliant futureBradAMiller has a brilliant futureBradAMiller has a brilliant futureBradAMiller has a brilliant futureBradAMiller has a brilliant futureBradAMiller has a brilliant futureBradAMiller has a brilliant futureBradAMiller has a brilliant futureBradAMiller has a brilliant future
Re: Speed Encoders or Gyros?

All the information presented has been good. Another resource that might help is the set of videos here: http://wp.wpi.edu/wpilib/robotics-videos/

You should look at the sensors play list which has a bunch of short (about 10 minutes each) videos that talk about the relative advantages of each of those sensors.

Brad
__________________
Brad Miller
Robotics Resource Center
Worcester Polytechnic Institute
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 03:15.

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