Go to Post So, you're saying there's a correlation between hard work and success? Who woulda thunk it?! - Tom Bottiglieri [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 Rate Thread Display Modes
  #16   Spotlight this post!  
Unread 12-02-2013, 12:35
AntiSleep AntiSleep is offline
Registered User
FRC #1444
Team Role: Mentor
 
Join Date: Jan 2007
Rookie Year: 2004
Location: St. Louis
Posts: 4
AntiSleep is an unknown quantity at this point
Re: Magnetic encoders? Anybody else having trouble?

We noticed the readout value jumps all over when using the encoders' analog output. This seems to be caused by the slow PWM it uses. Aliasing issues occur when the cRIO samples its analog inputs. I added a simple RC filter and that seems to have sorted it out. I just used a 4.7k in series and a 1uF after that. That seems to have smoothed it out, but as always some tweaking might be necessary depending on your application.

EDIT - For more info, just found the datasheet actually mentions this on page 18...

Last edited by AntiSleep : 12-02-2013 at 12:45.
  #17   Spotlight this post!  
Unread 13-02-2013, 08:07
Bryscus's Avatar
Bryscus Bryscus is offline
EE, CpE
AKA: Bryce B.
FRC #0180 (SPAM)
Team Role: Engineer
 
Join Date: Jan 2009
Rookie Year: 1999
Location: Jupiter, FL
Posts: 173
Bryscus has much to be proud ofBryscus has much to be proud ofBryscus has much to be proud ofBryscus has much to be proud ofBryscus has much to be proud ofBryscus has much to be proud ofBryscus has much to be proud ofBryscus has much to be proud ofBryscus has much to be proud of
Quote:
Originally Posted by velcro View Post
I'm a bit confused. In table 4, it says the max input frequency for the magnet is 153 rpm @4096 positions/rev. In table 7 it says that you can go up to 9766 rpm@ 64 samples/rev. Then in 9.6.3 it says it can go up to 30,000 rpm and refers to table 7. Maybe by going lower than 64 samples/rev?

In any case, I can't find where to change the samples/rev. Any ideas?
I believe it defaults to 4096 bit but can be changed through the digital interface.

We have tried this encoder on a shooter wheel and it can swamp the cRio pretty quickly. IMHO this encoder would probably best shine in a lower speed continuously rotating system or as a positional sensor.

- Bryce
__________________
The opulence of the front office decor varies inversely with the fundamental solvency of the firm.
  #18   Spotlight this post!  
Unread 13-02-2013, 09:12
Ether's Avatar
Ether Ether is offline
systems engineer (retired)
no team
 
Join Date: Nov 2009
Rookie Year: 1969
Location: US
Posts: 8,125
Ether has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond repute
Re: Magnetic encoders? Anybody else having trouble?

Quote:
Originally Posted by Bryscus View Post
Who names their pins Test* and then uses them in normal operation? Bizarre.
The datasheet is a bit unclear to me. Can pins 3 & 4 be configured to output a square wave quadrature signal or can they not?

Has anyone successfully done this with this sensor?


Quote:
Originally Posted by Bryscus View Post
We have tried this encoder on a shooter wheel and it can swamp the cRio pretty quickly.
I'm guessing your comment above is based on not using the A & B quadrature output?

The datasheet is unclear regarding the max rpm the sensor electronics can support in incremental quadrature mode and still produce a usable output.


  #19   Spotlight this post!  
Unread 17-02-2013, 09:30
Bryscus's Avatar
Bryscus Bryscus is offline
EE, CpE
AKA: Bryce B.
FRC #0180 (SPAM)
Team Role: Engineer
 
Join Date: Jan 2009
Rookie Year: 1999
Location: Jupiter, FL
Posts: 173
Bryscus has much to be proud ofBryscus has much to be proud ofBryscus has much to be proud ofBryscus has much to be proud ofBryscus has much to be proud ofBryscus has much to be proud ofBryscus has much to be proud ofBryscus has much to be proud ofBryscus has much to be proud of
Sorry to be unclear in my last post. Yes, we were using the magnetic sensor in encoder mode. Were did seem to be getting good feedback. I didn't scope it, but we were getting count rates that seemed consistent and direction was also detectable.

All this was possible only at slow speed though. We could hit the Nyquist frequency for the cRIO input at very low speeds - maybe 15% or less of a CIM motor output, I can't remember the exact figure. At around this speed the encoder rate sign would change. We also would get very quantized numbers for speed (e.g., always something like dancing between 20142.464 and 21439.264 that were repeated exactly).

Just a thought, is it possible that having 4096 bit resolution that could correspond to 4096 ticks on an optical encoder and that the transitions actually happen 4x that speed? That would make matters even worse for sure.

So we gave up pretty quickly using the magnetic sensor and went to US Digitals instead. In hind sight I probably should have just rotated the shooter wheel one revolution and checked how many clicks it produced...
__________________
The opulence of the front office decor varies inversely with the fundamental solvency of the firm.
  #20   Spotlight this post!  
Unread 17-02-2013, 09:34
RufflesRidge RufflesRidge is offline
Registered User
no team
 
Join Date: Jan 2012
Location: USA
Posts: 992
RufflesRidge has a brilliant futureRufflesRidge has a brilliant futureRufflesRidge has a brilliant futureRufflesRidge has a brilliant futureRufflesRidge has a brilliant futureRufflesRidge has a brilliant futureRufflesRidge has a brilliant futureRufflesRidge has a brilliant futureRufflesRidge has a brilliant futureRufflesRidge has a brilliant futureRufflesRidge has a brilliant future
Re: Magnetic encoders? Anybody else having trouble?

Quote:
Originally Posted by Bryscus View Post
Just a thought, is it possible that having 4096 bit resolution that could correspond to 4096 ticks on an optical encoder and that the transitions actually happen 4x that speed?
Pretty sure it's 1024 cpr equivalent. 4096 transitions per rev.
  #21   Spotlight this post!  
Unread 17-02-2013, 16:20
Ether's Avatar
Ether Ether is offline
systems engineer (retired)
no team
 
Join Date: Nov 2009
Rookie Year: 1969
Location: US
Posts: 8,125
Ether has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond repute
Re: Magnetic encoders? Anybody else having trouble?

Quote:
Originally Posted by Bryscus View Post
Just a thought, is it possible that having 4096 bit resolution that could correspond to 4096 ticks on an optical encoder and that the transitions actually happen 4x that speed?
quote from screenstepslive:
Quote:
The AS5145B is the equivalent of an optical encoder with a 1024 count disc, meaning it will output 1024 pulses per channel per revolution. In 4x decoding mode, this will yield 4096 ticks per revolution.

  #22   Spotlight this post!  
Unread 17-02-2013, 16:28
Ether's Avatar
Ether Ether is offline
systems engineer (retired)
no team
 
Join Date: Nov 2009
Rookie Year: 1969
Location: US
Posts: 8,125
Ether has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond repute
Re: Magnetic encoders? Anybody else having trouble?

Quote:
Originally Posted by Bryscus View Post
All this was possible only at slow speed though.
I'm guessing you were using the Encoder class and instantiating 4X decoding?

That's your problem. That's overkill for a shooter wheel speed sensor.

If instead you connected only one channel of the sensor, and made a Counter object that counts only the rising edge of that channel (with no direction control), the FPGA is capable of keeping up with 1024 rising edges per rev at well over 5,000 RPM (perhaps as high as 8,000 RPM).

Please note though: for high-CPR counters at high RPM, if you use the getPeriod() method, you must set FPGA samples much higher than the default 1. For your app, I'd use 127 (the maximum), which is about 1/8 of a revolution. Setting the size of the FPGA sample buffer is easy in LabVIEW. In C++ or Java, it requires a small edit to the WPILib code.

Or, at those high speeds with a high CPR (like 1024), you could get the counts (instead of the period), and divide by elapsed time. To get good results with this method, you need a good value of elapsed time. In C++ you can use the PPCtimer (low overhead and microsecond resolution). In LabVIEW you can use a Timed Structure and just divide by the period.



Last edited by Ether : 17-02-2013 at 17:36. Reason: added note
  #23   Spotlight this post!  
Unread 17-02-2013, 19:51
sg999 sg999 is offline
Programming Lead, Co-Captain 2013
AKA: Bella
FRC #0999 (Mecharams)
Team Role: Alumni
 
Join Date: Apr 2012
Rookie Year: 2012
Location: Connecticut
Posts: 44
sg999 is a splendid one to beholdsg999 is a splendid one to beholdsg999 is a splendid one to beholdsg999 is a splendid one to beholdsg999 is a splendid one to beholdsg999 is a splendid one to behold
Re: Magnetic encoders? Anybody else having trouble?

We're using the magnetic encoders in quadrature mode on our drive train. However, we're mounting them in such a way that they're spinning at the same speed as the CIM motors we're using on the drive train. We've got a lag of about 5 seconds (when reading the values from teleop.vi). Does anyone know how to fix this?
__________________
There is always time-whether or not you use it productively is up to you.

2012-WIWI 6th seed (Thanks for being awesome alliance partners, 1991 and 178)

2014-present College student at Caltech (math/CS)
  #24   Spotlight this post!  
Unread 17-02-2013, 19:53
Ether's Avatar
Ether Ether is offline
systems engineer (retired)
no team
 
Join Date: Nov 2009
Rookie Year: 1969
Location: US
Posts: 8,125
Ether has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond repute
Re: Magnetic encoders? Anybody else having trouble?

Quote:
Originally Posted by sg999 View Post
We've got a lag of about 5 seconds
How are you measuring this lag?


  #25   Spotlight this post!  
Unread 17-02-2013, 22:15
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: Magnetic encoders? Anybody else having trouble?

Quote:
Originally Posted by sg999 View Post
We're using the magnetic encoders in quadrature mode on our drive train. However, we're mounting them in such a way that they're spinning at the same speed as the CIM motors we're using on the drive train. We've got a lag of about 5 seconds (when reading the values from teleop.vi). Does anyone know how to fix this?
We have found that moving all but your driving code out of teleop in into periodic tasks seems to improve the lag issue considerably. Additionally, try making sure that your video coming from the camera is running at the minimum required frame rate and resolution with maximum acceptable compression.
__________________
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
  #26   Spotlight this post!  
Unread 17-02-2013, 23:59
sg999 sg999 is offline
Programming Lead, Co-Captain 2013
AKA: Bella
FRC #0999 (Mecharams)
Team Role: Alumni
 
Join Date: Apr 2012
Rookie Year: 2012
Location: Connecticut
Posts: 44
sg999 is a splendid one to beholdsg999 is a splendid one to beholdsg999 is a splendid one to beholdsg999 is a splendid one to beholdsg999 is a splendid one to beholdsg999 is a splendid one to behold
Re: Magnetic encoders? Anybody else having trouble?

Quote:
Originally Posted by Ether View Post
How are you measuring this lag?
I'll hit the joystick to move the drive motor and a stop watch at the same time. Once the value on the front panel of the encoder changes, I hit the stop watch again, to stop it.

Billbo911: We don't have a camera hooked up, and just about all of our code is in periodic tasks. Even when we moved the code to read the encoders to periodic tasks (10 ms delay), we still get the same lag. The potentiometers that we're also reading are updating rapidly. The code to read those were always in the same spot as the code to read the encoders.
__________________
There is always time-whether or not you use it productively is up to you.

2012-WIWI 6th seed (Thanks for being awesome alliance partners, 1991 and 178)

2014-present College student at Caltech (math/CS)
  #27   Spotlight this post!  
Unread 18-02-2013, 00:14
Ether's Avatar
Ether Ether is offline
systems engineer (retired)
no team
 
Join Date: Nov 2009
Rookie Year: 1969
Location: US
Posts: 8,125
Ether has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond repute
Re: Magnetic encoders? Anybody else having trouble?

Quote:
Originally Posted by sg999 View Post
We're using the magnetic encoders in quadrature mode on our drive train. However, we're mounting them in such a way that they're spinning at the same speed as the CIM motors we're using on the drive train.
Are you decoding at 4X, 2X, or 1X? The FPGA cannot read a 1024 CPR encoder at 4X at full CIM speeds.


  #28   Spotlight this post!  
Unread 18-02-2013, 01:48
sg999 sg999 is offline
Programming Lead, Co-Captain 2013
AKA: Bella
FRC #0999 (Mecharams)
Team Role: Alumni
 
Join Date: Apr 2012
Rookie Year: 2012
Location: Connecticut
Posts: 44
sg999 is a splendid one to beholdsg999 is a splendid one to beholdsg999 is a splendid one to beholdsg999 is a splendid one to beholdsg999 is a splendid one to beholdsg999 is a splendid one to behold
Re: Magnetic encoders? Anybody else having trouble?

Quote:
Originally Posted by Ether View Post
Are you decoding at 4X, 2X, or 1X? The FPGA cannot read a 1024 CPR encoder at 4X at full CIM speeds.

We tried both 1x and 4x, with no difference in lag.
__________________
There is always time-whether or not you use it productively is up to you.

2012-WIWI 6th seed (Thanks for being awesome alliance partners, 1991 and 178)

2014-present College student at Caltech (math/CS)
  #29   Spotlight this post!  
Unread 19-02-2013, 09:00
Bryscus's Avatar
Bryscus Bryscus is offline
EE, CpE
AKA: Bryce B.
FRC #0180 (SPAM)
Team Role: Engineer
 
Join Date: Jan 2009
Rookie Year: 1999
Location: Jupiter, FL
Posts: 173
Bryscus has much to be proud ofBryscus has much to be proud ofBryscus has much to be proud ofBryscus has much to be proud ofBryscus has much to be proud ofBryscus has much to be proud ofBryscus has much to be proud ofBryscus has much to be proud ofBryscus has much to be proud of
Quote:
Originally Posted by Ether View Post
I'm guessing you were using the Encoder class and instantiating 4X decoding?

That's your problem. That's overkill for a shooter wheel speed sensor.


I'm aware of the 1X / 4X setting and we tried both. At full speed our wheel spins at around 6000RPMs. We were using 1X almost exclusively.

As for changing to a counter class, that might work much better.

What are the changes between 1X and 4X under the hood between the cRIO and FPGA?

- Bryce
__________________
The opulence of the front office decor varies inversely with the fundamental solvency of the firm.
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 20:08.

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