Many people have been asking about support of magnetic encoders. I surveyed the magnetic encoder offering from ams, RLS (Renishaw), MagAlpha, US Digital, and Posital.
My finding was that the ams AS5047P is likely to be the best candidate.
From what I understand from the datasheet, without any SPI configuration, the ABI incremental interface will be active with a resolution of 4000 CPR. Therefore we can add the drivers and config later, and try it out immediately.
Looks like a nice encoder. Will definitely try it out.
Any idea of a good place to buy this in qty 1? Also, does the magnet come with it? (Sorry Iāve never used magnetic encoders before outside of motors thatās came with them pre-installed.)
Magnet will not come with it. Easy to find on somewhere like digikey. I also have been trying to find the ams in stock to try it out. No luck all back ordered. Any leads @madcowswe?
I used the development board from mouser which comes with a magnet and although it says the default CPR is 4096 mine were all 4000.
I wasted quite some time trying to figure out what the problem was as the ODrive was holding position correctly at 0 and close to that but as I increased the position it stopped working because the difference between the actual position and the reported position increased
Note that this almost surely needs to be a diametrically-magnetized magnet, not a standard axially-magnetized magnet! I canāt find in the datasheet anywhere that calls out using a diametrically-magnetized magnet, but it does state that āThe AS5047P uses 4 integrated Hall sensors which produce a voltage proportional to the orthogonal component of the magnetic field to the dieā. If a magnet is axially magnetized, the orthogonal magnetic field component will be near constant, and the sensor wouldnāt work well.
kjmagnetics is where I buy most of my magnets, and has a wide variety of diametrically magnetized magnets, including ones similar to the 8mmā and 3mm height N35H magnets used to characterize the sensor in the datasheet. Since they sell in low quantity, their prices are very reasonable, and Iāve never had an issue with them or their magnets, Iād recommend using them.
Edit: the devboard does include this diametrically-magnetized magnet, which confirms my suspicions.
first of all FYI the ams encoders chips are available on aliexpress with the magnets included for ~$10 ea. you will have to buy a breakout board for ~10 cents ea and just add 2 caps, thatās it. just know that TSSOP package requires skill to solder by hand. the 5048A is available as a ready-to-use module for $15 on aliexpress (used for brushless gimbals) it is a more expensive chip but it does not support ABIā¦ just SPI.
second - do you intend to support this in the firmware? I used ams encoders (the cheaper as5600) with arduino but it seems intimidating to me to try meddling with firmware code. i would like to know there is some example code availble before jumping in.
third - I heard there are latency issues with these encoders when using I2C/SPI? . perhaps the I2C / SPI protocol is the bottleneck here. also when using an I2C encoder beware these encoders have a fixed I2C address so you may need an I2C multiplexer to use more than one at a time.
great product and forumā¦ waiting for your comments!
Ah nice, thanks for the aliexpress link. My only worry is that the chips could be counterfeit, which does happen even with ICās. Though of course it could just be genuine chips resold through some low-margin channel.
Using the ABI interface, I think nothing has to change in the firmware, it should just work. Iām sure someone in the community will add the SPI drivers to retrieve the absolute position also at some point: these encoders seem fairly popular.
Yes I can imagine that there is latency over SPI. This is why we should use the ABI interface, which I think should have basically zero latency. There is some latency in the magnet to position determination, but they have a latency compensation filter on-board that uses the speed of the rotor to compensate. So hopefully it should work pretty well.
Hi Jake, thanks for the info I didnāt know infineon had such product.
Are you using the incremental interface (quadrature) with ODrive, or are you just using SPI interface without quadrature? I am asking cuz I thought serial type absolute encoders arenāt yet supported for commutation. thanks,
Yeah, i should probably have made clear I am using the IIF. due to the advantages stated above.
I think you are correct about odrive not supporting serial interfaces for commutation. In my opinion, we donāt even need it in the future. With the Infineon sensor, you dont even need to do an encoder alignment or index search at each start of the system. The sensor clocks out the āstarting positionā via the incremental interface after power-up. We might need some delays to turn on the sensor, so that the odrive is ready to receive signals.
Also, Infineon uses their SSC Interface, which is SPI-ish but turns out to be a major pain to use - at least for me.
Is there any interest for an odrive compatible breakout board for the TLE5012?
If so, I could adjust my current design to be more universal.
As the IIF and SSC interfaces can be used independently I assume we could hook up the Odrive to read the incremental IIF interface and use an arduino on the SSC interface at the same time. That would enable really high speed accurate readings of the angle and speed on the Arduino while the Odrive manages the commutation simoultaneously.
That sounds like a really nice use case. Just imagine, what you could do with position updates that fast and accurate
I will try my best. Will probably add some PCBs the next time I order anyways. Might take a few days/weeks.
Is there any GPIO on the odrive that we can use to āenableā the sensor with an easy change in the code? If we want to skip the encoder align at each start-up, we have to wait until the odrive is fully booted before we enable the encoder and it then clocks out its current position.
Hmm, according to the specifications I see only 4096 counts per rev? As a newbie on this subject I might be interpreting this wrongly though:
4.4.5 Incremental Interface (IIF)The Incremental Interface (IIF) emulates the operation of an optical quadrature encoder with a 50% dutycycle. It transmits a square pulse per angle step, where the width of the steps can be configured from 9 bit(512 steps per full rotation) to 12 bit (4096 steps per full rotation).
With SSC the resolution of the angle data is supposed to be 15 bit, and COS and SINE data is 16 bit though.
Yep, there are 4096 pulses per channel per revolution. I use the sensor in another application as well, this is the resolution I get there.
When using the odrive, I get 16384 pulses per revolution. I suppose odrive triggers on both edges on both channels, hence you get 4 times the resolution. Maybe @madcowswe or @Wetmelon could kindly confirm this?
The good News is: This is ārealā and āusableā resolution (not interpolated or anything!), which will dramatically increase your position and speed accuracy. If your RPM gets too high, you might want to reduce the resolution of the Encoder via the SSC Interface.
EDIT: Well, it will probably not increase speed accuracy dramaticallyā¦ Due to intertia, etc. less counts should be alright. But it will improve position accuracy.
