Timeline for Using hall sensors to calculate position
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 23, 2018 at 3:46 | comment | added | markshancock | @Kons, Note: We have found that the Hall Position sensor crosses the 360 point with V<5V and v>0V (what we call the "Hall Hole"). The way we handle that is: 1) During homing, we log the limit values and use those for calibration 2) We point out primary (forward) direction opposite the "Hall Hole" so we generally don't have to deal with it. There are likely more expensive sensors that don't have this issue; but, we are on a tight budget. | |
| Jan 22, 2018 at 16:42 | comment | added | markshancock | @Kons Good that you did the math to make sure you can handle max RPM. The problem I am mentioning occurs when the motor stops at an encoder transition point and the because of vibration it oscillates back-and-forth across it. If you are able to service all the edges, it will be a sequence of +1 and -1 that all cancel out, it not you will miss some and the result will be position creep. Also, your comment "12 poles and 2 sensors" sounds like you are using an resolver rather than an an optical encoder. I have primarily run into jitter on optical encoders which have much higher counts/rev. | |
| Jan 21, 2018 at 15:09 | comment | added | Konstantin Borisov | @markshancock The motor can do only 5000rpm. With 12 poles of the magnet and 2 sensors it will give 120 000 interrupts per minute, or 2000 interrupts per second. 500us for should be long enough to service my simple handlers. But you're right, the whole thing will be much easier with absolute position hall sensor. Will buy one for experiments. I need to have absolute position in any case. | |
| Jan 20, 2018 at 23:46 | comment | added | markshancock | @Kons You are going to have to deal with edge jitter of you are not going to get accurate results. The rate can sometimes be faster than the processor can service interrupts. Last time I did this, I did it in HW using an FPGA. You might be able to do it in SW by funneling all the interrupts into a single service routing, read both phases at the same time and put a filter in so that you treat interrupt bursts as a single event. | |
| Jan 20, 2018 at 5:37 | comment | added | Konstantin Borisov | @markshancock Yes, I decode a quadrature encoder. Now I understand how many glitches I can catch with this. Today, for example, one of my the sensor wires became a little bit loose and positioning became innacurate. The motor moved and stopped but in wrong positions. Fixed that with just putting wires deeper in my breadboard. And yes, I try to control position. | |
| Jan 19, 2018 at 4:45 | comment | added | markshancock | @Kons Are trying to decode a quadrature encoder yourself by capturing the edges using interrupts? If so, there are LOTS of things that can go wrong! One classic problem is edge jitter where the encoder produces a very fast chain of edges because the encoder stops right on one of the encoder transitions and ends up quickly going back-and-forth across it. Missing or mishandling the edges thus cause the position to appear to move even though it didn't. | |
| Jan 19, 2018 at 3:14 | comment | added | jsotola | @Kons, one produces some extra signals ... not "extra signals" .... you need to fully understand what you are dealing with if you want to have success | |
| Jan 17, 2018 at 20:43 | comment | added | markshancock | Note: A PID loop is pretty easy to do. One of the biggest questions would be whether you want the PID to control position or error. That is really dependent on your design. It sort of sounds like to me that you are looking for positional control. | |
| Jan 17, 2018 at 20:43 | comment | added | markshancock | Glad to hear you are making progress. | |
| Jan 17, 2018 at 19:03 | comment | added | Konstantin Borisov | Looks like my initial problem was had 2 root causes: 1) I should have used both interrupts of the motor hall sensors (one produces some extra signals). 2) Without PID loop it was too inaccurate. I decreased the motor speed and now it looks way much better. Thank you for your answers! | |
| Jan 16, 2018 at 19:15 | history | answered | markshancock | CC BY-SA 3.0 |