josiah47
Member
Good morning everyone,
Wondering what would be a better choice this one
or this one
I am guessing anyone would choose the first one since its Absolute, and it can talk over SPI where as the second is incremental so I would need to do the quadrature processing myself on the Maple, correct or am I wrong here? either way I would like some feedback on what you guys recommend and what one would be easier to code for. Any one currently using any SPI encoder feedback on the Maples?
Thanks
ridgebackred
Member
Hi josiah47,
Interesting encoders. The first I have seen of capacitive type.
I don't know the details of your application, so I can only generalize.
If you are using these as a feedback device for a high speed servo motor, the inherent delays in these encoders would preclude their use in that application for me.
If they are being used as feedback for say, a rotation counter of a manual or slow open loop motor driven system, they could be worth consideration.
Of course, the absolute positioning is only for one rotation of the encoder. You will still have to handle rollover and derive encoder (shaft) rotation speed in your code. The delay inherent in the SPI absolute position communications deserve a good analysis, so it does not turn into a 'gotcha' further into the project.
Isn't there a channel or two of quadrature decoding available on the STM32's?
ridgebackred
Member
Assuming that you choose this absolute encoder, I read the max position update capability as 20,833Hz disregarding any SPI communications overhead on the MCU side. A 1250rpm shaft rotation speed is 20.83 rev/sec or 7500 deg/sec. The max position update of the absolute encoder would be 2.78 samples per degree, below your 5 samples per degree requirement.
I don't know what encoder you will ultimately choose, but based on your samples per degree requirements it doesn't look like the absolute position one will meet your needs.
If the machine holds a well regulated speed when in operation, it may be simpler to pick off an interrupt once per shaft rotation and drop into the time domain inside the MCU for working your samples per degree.
gbulmer
Moderator
These may be too delicate for your purposes, but very popular encoders in the micromouse community are from Austria Microsystems:
http://www.austriamicrosystems.com/eng/Products/Magnetic-Encoders/Rotary-Encoders
They have some with 12 bit resolution and speeds upto 30,000rpm.
Each of the STM32F general (TIM2, TIM3 or TIM4) or advanced (TIM1) timers can implement a quadrature decoder in hardware, so it could interface more directly to the data stream, rather than via SPI. (Edit: The RET6 part has two more quadrature capable timers.)
A few of the Austria Microsystems parts expose the underlying sine/cosine analogue signals directly, so in theory you could run a digital to analogue conversion directly using a Maple.
I'd be concerned that an industrial environment (which I infer from "tool balancing machine") might be too electrically, and magnetically, noisy to get 12-bit resolution. Also, vibration on the driving shaft may cause too much distortion on the signal to be able to compensate.
Can you either use a gearbox to drive the tool, or a gearbox to drive the sensing mechanism? Assuming you want better than 5*360 degree resolution, i.e. 1800 position/revolution, direct sensing is a challenge, but by running the sensor at a much higher speed through a gearbox, that sort of resolution might become easier.
Tim Foden's micromouse uses a simple printed sensor (about a dozen black/white segments) attached directly to the wheel, and uses analogue sensing.
http://www.micromouseonline.com/blog/2010/12/05/robotic-2010
I believe it gets a resolution around a couple of degrees. A > 10x gearbox might get close to > 1800 steps/revolution resolution. A problem with optical approaches is ambient light pollution, but using infrared and some container or shield might be enough.
If you have facilities to rigidly mount multiple optical sensors, resolution can be increased by using more sensors.
josiah47
Member
I think I have found the encoder I would like to use, but would like some feedback on connecting it to the Maple
http://www.amtencoder.com/LinkClick.aspx?fileticket=Jat4EDtyVjw%3d&tabid=215
Anyone care to help?
gbulmer
Moderator
josiah47 - That looks like a very nifty solution.
What level of feedback do you want on connecting it to Maple?
Is there another datasheet?
I found plenty of mechanical data, but I all I could see about the electronics is:
output phase difference: 90° (A ch leads B ch in CW direction viewed from front)
output current: 5 mA max.
output waveform: TTL voltage square wave
output signals: A, B, Z1 phase (A, B, C line driver available with CUI-10XE-10)
current consumption: 6 mA typ., 10 mA max.
supply voltage: 3.6 ~ 5.5 V dc
and a "Pin-Out" with the key of the signals available on the connector. Is there some marking on the device to get an unambiguous pin mapping?
That datasheet is a bit sparse. For example, I'd like to see clear diagram about the timing of the index signal wrt. the quadrature signals.
I assume it means TTL level square wave will be at least 2.0V for high e.g. http://www.interfacebus.com/voltage_threshold.html
Have you got access to an oscilloscope? A TTL square wave should be okay to feed into a Maple, but I'd check it before I'd connect it. With a bit more detail on the electrical signals, I'd feel happier.
I'd be tempted to isolate it from a microcontroller using something like an optical isolator/optical coupler, e.g.
http://uk.rs-online.com/web/search/searchBrowseAction.html?method=retrieveTfg&binCount=973&Ne=4294957561&N=4294767559+4294571109
It sounds from your application like it will be in an industrial setting, so isolation seems like a good idea anyway.
I'd put a resistor (say 1K) into each signal line to reduce the chances of damaging anything by shorting connections (I can be clumsy some days :-)
Once you have 'friendly' signals, at a voltage level that can't harm a microcontroller, then you could feed them into a few pins.
You could be feed the two quadrature signals into input capture inputs of a timer. Use the timer to track the quadrature signal. The index could feed into another timer, or just use it as an interrupt.
For initial experiments, you could just use a loop which does digitalRead to check each pin state and micros() to time it.
ridgebackred
Member
josiah47,
It looks like drinkdhmo worked out the timer register settings for a 4x quadrature decode.
I would double check that timer4 is 5V tolerant on the Maple.
Hook up just the encoder to a 5V supply and check that the A and B channels are giving a square wave output when the encoder is rotated with an oscope.
It won't matter if the A and B channels are reversed during initial setup. The counter just counts down instead of up.
A quick and dirty program to set up a timer like drinkdhmo did. (Using the new timer naming convention if needed ?) drinkdhmo called out the pin numbers for timer4, so I would use that one. (5V tolerant on Maple?)
A serial print every 50mS of the value of 'cnt', should print the value of the encoder automatically when the encoder is rotated if the hardware quadrature capture/decoding is working OK.
Edit additions: Consider powering the encoder from a separate external 5V supply. Tie the encoder and Maple GND's together of course.
If 'CNT' isn't already declared in the timer code somewhere, use a large signed integer. You may not have to worry about counter rollover depending on how long it takes to balance the tool.
josiah47
Member
Here is the datasheet for the cable it give you the Pin outs
http://products.cui.com/getPDF.aspx?fileID=3753
I am emailing them for more info on the output
josiah47
Member
I haven't heard back from CUI yet but I look at the training module again and it looks to be like a 5V TTL signal, if its okay to interpret it like that since they show 0V to 5V still need a better answer.
I guess ing using D6,7,8 would be capable of taking the 5V anyway but is this recommended or should I use other pins? or step it down first?
http://dkc1.digikey.com/us/en/tod/CUI/AMTEncoders_NoAudio/AMTEncoders_NoAudio.html
trevden
Member
I've used one of these on the Maple, it works great with the 5V tolerant pins and a 5V supply, connected up directly.
I didn't know at the time that the STM32 has native quadrature decoders -- that is clearly the correct solution -- but here's the interrupt-driven code I was playing with:
https://github.com/trevyn/opencvtest4/blob/master/mapleocvt4/mapleocvt4.pde
It mostly works, though I suspect it has a small amount of drift due to missed steps.
josiah47
Member
Okay finally got my Maple in, also my encoder and the cable to go with it, well... the line driver cable, apparently it does something to the output signal? does anyone know if I should remove the line driver or keep it, apparently it helps remove noise, but is it then possible to hook directly up to the Maple or not? Any direction would be appreciated.
trevden: im guessing your code isn't using the built in quadrature decoders? you have any more info on using these including code?
Thanks
You must log in to post.