How often does encoder::update() gets called and where is it being called?
int16_t delta_enc_16 = (int16_t)hw_config_.timer->Instance->CNT - (int16_t)shadow_count_;
so the timer->CNT will get cleared somewhere? or the timer->CNT will keep all the encoder steps, what if it overflows?
And it seems like the fw4 branch doesn’t do the calibration at startup? I am using a mac and the odrivetool detects the odrv0 and disconnect very soon if it’s not being actively used.
All of the following pertains to the branch fw4. The closed loop control runs in a loop which is part of a function in axis.hpp called run_control_loop. This loop runs at about 10kHz right now and executes all control loops. It calls do_updates which is in axis.cpp, which in turn calls Encoder::update().
In the code timer->CNT will overflow and wrap around. This is why we have the shadow count and circular counts. The trick is that we compare to (int16_t)shadow_count_, so the subtraction will “unroll” the overflow and it works still when rolling around the overflow.
Yes fw4 is new and not released yet, sorry there is not much documentation. You must send odrv0.axis0.requested_state = 4, then = 7 then = 8. Have a look at axis.hpp to see the states.
It works! thanks for the help! One thing to know is the ADC reading on stm32 is convert to 0-3.3 float. but reads differently on the odrivetool.
motor i have is this one: https://store.dji.com/product/rm-m3508-p19-brushless-dc-gear-motor
i don’t know the specific model of the encoder but it outputs sin/cos signal.
Did you ever release any code for your sin/cos encoder interfacing?
Thanks.
Has somebody has used this type of encoder???
Hi Guys…
Wanna ask about the M3508 P19…
Since you guys have already figured out the sin/cos encoder mystery,
can you guys share the pin out for the 7-pin?
I emailed DJI and they said it is “confidential” stuff and refuse to provide further information.
1 x Hall sensor (I guess?)
1 x Sin Cos encoder (Tested by your guys)
But which wire is which wire???
Hi
Sin /cos encoders are normally used on professional systems like cnc milling machines etc.
The allow for interpolation of the waveform .
They give much greater accuracy than the quadrature phase type and work very well at low speeds.
For Instance I have one that has a nominal 10 micron accuracy and with 5 x interpolation it gives 2 microns .
Its probably worth quite a lot of money.
Peter
How much work would it take to create encoder linearization logic? It seems that with a multipole ring/tape this is the only difference between current sin/cos support and industrial level product like @gasmeter mentioned .
IMHO there is much benefit to support sin/cos encoder with greater precision:
- lower cost compared to ABZ/SPI encoders
- potentially better response time and better precision since there is more compute resource on ODrive board than a low power SoC
The challenges seem to be signal strength (most sin/cos chips don’t output to 3.3V which is what it takes to get the full 12 bit of ODrive ADC?) and reliable calibration source.
Is it possible to extend the anti-cogging code to solve for both harmonics in cogging torque and harmonics in encoder nonlinearity?
sin/cos encoders have a wiper, so they are much noiser and far less reliable than the common magnetic/optical encoders.
If it is moving, then the delay between reading the sin and cos A/D converters becomes a problem
so I would expect them to be less accurate, and more timing sensitive than ABZ encoders
What is a wiper?
For reference I was looking at these chip level sin/cos encoders:
Most of them have an amp and a driver between the bridge circuit and the output pin. The delay should be <<10us.
ok, my mistake, these are using magnetic sensors rather than resistive pots. These may be affected by stray magnetic fields (I don’t know how sensitive they are)
but how long does it take you do do the A/D conversion and then doing the math compared to counting pulses like you do with an ABZ encoder.
I do know from people who have used the magnetic rotation sensors that they are frequently not as linear as you would think. You ask if the anti-cogging code could be modified to correct for this error, but the first issue you have to answer is what you are correcting against? the current anti-cogging code compares the position reported by the encoder with the expected position based on the drive power phases, what do you compare the sin/cos encoder against to correct it?
All the magnetic encoders do lots of processing on the chip: analog signal conditioning, ADC, angle computation (arctan), error compensation, AGC etc. For reference see the processing flow graph on page 8 of A1335 datasheet: https://www.allegromicro.com/-/media/Files/Datasheets/A1335-Datasheet.ashx
The ADC delay is only a small part of the overall delay. If money is no object you can spend $50 on a 16bit 100Msps ADC chip and the delay will be less than a few ns. In contrast the A1335 chip mentioned above at $2.00 price point has a response time of 60us. The popular AS5048A at $9.00 has response time around 100us.
The limitation of the low cost magnetic encoder chips is processing power. Most of them have very small die size to work with. I am speculating that by taking the signal in sin/cos format and moving the processing to STM32F4 on ODrive board we can get better faster response and better accuracy.
that’s still a sensor that is trying to decode a rotating magnetic field
look at things like the $23 https://www.cuidevices.com/product/resource/amt10.pdf that just sends pulses. (with very low latency, 30ns)
That 30ns in the datasheet is rise/fall time of the CMOS output, not the delay from taking sample to output. They put that number in the datasheet to specify their CMOS output characteristics. It has nothing to do with the delay. For example another product AMT11 (https://www.cuidevices.com/product/resource/amt11.pdf) has two different types of outputs and has two different rise/fall time in the datasheet. The rise/fall time for AMT11 is better because a line driver is used internally to boost the output to RS422 specs. Its delay might actually be slightly worse than AMT10 due to the additional line driver used.
Using their max rpm specs you can see their max sampling rate is around 266Ksps, which gives sampling period of 3-4us. Their delay is likely to be 8-10us since most of the encoders take at least 2 samples to compute an average before sending the output. 10us response time is still a very good number compared to others.
What about using a sin/cos encoder directly, like one of these? https://www.rls.si/eng/products/rmb29-rotary-magnetic-module
I’ve been meaning to try one out but haven’t had the chance