Hi Everybody,
We have more 775pro encoders in stock. These directly attach to the back of the 775pro motor. 12 counts per rev, quadrature encoding.
Best wishes for your robot builds!
**What do you mean by 12 “counts” per rev?
A quadrature encoder has 4 edge transitions per cycle.
Do you mean 12 cycles per rev, or 12 edge transitions per rev?**
Good question.
How many RISING edges per channel per rev?
Also, how well are the falling edges positioned wrt the rising edges (how close to 50% duty cycle is it?)
Finally how well are the two channels oriented (90 degree being optimal – thus quad in the name)?
Dr. Joe J.
P.S. Can you share a screen shot of an o-scope trace of the two signals?
P.P.S. Can you provide some photos of the sensor assembled on the motor?
Yes, that would be a very clear way to specify it.
Also, how well are the falling edges positioned wrt the rising edges (how close to 50% duty cycle is it?)
Finally how well are the two channels oriented (90 degree being optimal – thus quad in the name)?
In their datasheet for the E4P, US Digital calls the former “symmetry” and the latter “quadrature delay”. See attachment.
*
Interesting concept Andrew. Do you have any detailed photos of the design and how it functions on the motor? Does it work by placing something (magnet? optical disk?) on the backshaft of the 775Pro?
12 edge transitions per rev. I’ll get some pictures up tomorrow. Have a good evening!
Per Channel or Per BOTH Channels?
I suppose you must mean that each channel has 12 edges because this is possible with a 6 pole magnet (N-S-N-S-N-S) and you’d get an edge at each N>S or S>N transition.
I’m not sure how to even do the alternative.
Screen shots of O-scope traces of the two signals showing a full rev. would be great.
Dr. Joe J.
Exactly, each channel, the disk has six magnetic poles.
Attached are some pictures of the design.
Very noticable quadrature error.
Yes, and the duty is not very close to 50%, either.
The two channels will be useful for telling which direction the motor is turning. Using more than the rising (or falling) edges of one channel will add jitter to the speed measurement, making the speed loop either less effective, or increasing sensitivity of its stability on tuning.
In a shooter geared 2:1 per Ether’s recommendation, this gives maybe 7 or 8 useful speed samples during the loaded part of a shot. The speed regulator will be trying to boost voltage to compensate that ~ 8 millisecond load transient, with boost adjustments 16 times per millisecond (controller output modulation frequency). It will be interesting to see how well the 775pro, this encoder, and a Talon SRX can regulate wheel speed during a shot load. Factors to influence the regulation include shooter wheel moment of inertia, speed regulator tuning, supply voltage feed-forward, ball compression, wheel compression, wheel-to-ball friction, etc.
Are those “downward” spikes in the first Hi period on the left and the two High periods at the right of the blue trace real? Can you post a scope shot with the scope set up with long/infinite persistence?
I am an idiot some times. For Hall effect sensors, one pole, one edge*
12 edges would need 12 poles (N-S-N-S-N-S-N-S-N-S-N-S).
Joe J.
*unless it was one off those “reed switch replacement” Halls that go on based on the field strength being above a threshold in either the N or the S direction, this would be a terrible choice for this application so I think we can all agree that me being an idiot at times is the best answer and move on.
My one of my mentors wants to know if they can handle 19000rpm
Well, it was designed specifically for the 775Pro whose free speed is 18730 so I would hope the sensor can mechanically and electrically handle that speed. Andrew, can you post an oscope trace at full speed?
As for the FPGA, the new higher FPGA sampling speed should handle it, even with the quadrature errors shown on the oscope trace posted earlier in this thread:
19000 rpm
316.7 revs/sec
3 cycles per rev (assuming 6-pole magnet w Hall sensor)
4 edges per cycle (quadrature)
12 edges per rev (quadrature)
3800 edges/sec (quadrature)
40.7 quadrature error (degrees)
182.6% quadrature error (percent)
6937 edges/sec (with quadrature error)
If you are going to use this for speed control of a shooter wheel, follow the advice Richard gave in his earlier post and use rising edges only in one channel only, to give the cleanest (jitter-free) speed signal (especially if using bang-bang control).
*
Hi everyone,
Ether, here is a screen shot that we took at around 13 or 14 volts.
philso, I don’t know if the spikes are from the scope or the encoder. I would have to borrow the scope again to play with more settings.
As for shooter wheel design, from my experiences in 2012, having the wheel be designed to mechanically impart enough energy into the ball can lead to a very accurate shot. Our encoder was used for ensuring that a very accurate rotational velocity was achieved so that the wheel would impart the same energy each time. We added closed loop PID control helped bring the wheel back up to speed in a short amount of time for the next shot. Which in 2012 was important as you could hold 3 balls. This year the cycle times will be much longer.
Yeah, looks to be spinning about 22000 rpm:
**0.0009 seconds per cycle
3 cycles per rev
0.00270 seconds/rev
370.37 revs/sec
22,222 rpm**
These certainly aren’t the prettiest traces I’ve seen. However, given that these traces are directly on the motor, teams willing to invest a bit of time and a few cents on tiny capacitors will blow through these rough spots like they don’t exist.
We ordered a few of these and mechanically, they seem to be a very nice solution. Kudos on the design!
@Geetwo -
How would you utilize some baby capacitors to address the issues mentioned? What value and technology caps would I buy and how should I put them in the system? Thanks!
BTW, this also shows that there are 3 cycles per rev, aka:
-
3 rising edges per rev on each channel
-
6 edge transitions (rising+falling) per rev on each channel
-
12 edge transitions per rev in quadrature