Hi, my BLDC servo motor has both internal hall sensors and an incremental encoder (see info below)
Can I connect both sensors to Odrive? I need to connect two of these motors.
Is the firmware ready to handle the input from both sources? Or if not: Can I configure the firmware to use the hall information for initial positioning and then go with the more precise incremental encoder?
I must avoid an index search on startup as that would move a big robot without control.
Cheers
I don’t think you can implement both Hall sensors and encoders. I believe the encoder option is the better of the two.
The encoder does have higher resolution, but since it’s incremental the startup position is unknown. I can’t do an index search because this is the traction motor of a heavy robot. Wouldn’t that be a problem?
We actually made a feature to solve this exact situation for a client with the exact same situation. We haven’t had time to merge it back into the main codebase yet.
The idea is to use an arbitrary hall signal as the index pulse: the rising edge of the hall signal will be in a repeatable location, but you must find it with a known rotation direction (left/right will be rising/falling or swapped depending on rotation direction). So we do a small lock-in drive in a known direction, then look at the rising edge of this hall signal (plugged into the index input).
You can check out the feature branch here, and the script with the settings required.
I have incremental encoder (4096 CPR) and halls (96 CPR).
Is it possible to route the halls to the GPIO and then follow the “index search” procedure but interrupt on hall state change?
On a hall state change the electrical phase position is known and commutation can switch to use the incremental encoder. This technique is used in other sinusoidal motor amps such as Elmo and RoboteQ.
“do a small lock-in drive in a known direction”, that means the motor still need to spin a bit before actual use? I have the same problem as lalten, the motor is mounted on heavy load and calibration/search need to be avoided. Is it possible to use the GPIO to read the HALL at every startup instead?
Hi, is this feature, still available? The git branch link is throwing error. How can I use this feature?
I found a paper how to detect magent position by using hall sensor.
(a) The detection of magnetic pole position, that in which 60-degrees-sector the rotor is positioned, is performed by using six patterns of the Hall sensor signals.
(b) Assume that the initial magnetic pole position is the center of the 60-degrees-sector.
© Starting position control. With the assumption in (b) there is possibility that the assumed initial magnet position deviate by ±30 degree from its correct position, until a Hall interrupt occurs.
(d) Once an edge of hall sensor signal is detected, the angle used in the vector control is corrected to the actual position.
By using Hall sensors, position control can be started without alignment.
Is there some progress on this?
With the robot I work on we will have the same problem.
We cannot do an index search or even move the robot in a constant direction because of the steering system.
The motors have integrated hall sensor and high res encoder.
Hello Senna,
We have industrial encoders too. And we want to know how to connect them on the Odrive’s board.
Can you explain in more detail the problem you confronted?
Did you use hall sensor’s (UVW) or the encoder’s wires (ABZ) on your robot?
Hello TKx94,
I have not used it yet, but if I would I would have the same problem as lalten. The robot is too heavy to move without a problem in open loop,to much geared down, and calibrating in a predefined direction is not possible because of the robot steering system.
The motors do work with the ODrive but only either the encoder or hall sensor. ODrive can work better with the encoder.
I have not used it yet also. I want to know if it gonna work.
So, I will use the encoder. I have a question, what about the brake of the motor?
Has this feature been rolled into the main firmware? Seems really desirable, since you’d have to do a much shorter jog to find an absolute reference, rather than potentially having to do almost a complete revolution to find an index pulse.
No, but you can always use a hall sensor as a fake index pin.
Wouldn’t you get multiple pulses per revolution, and wouldn’t that be a problem?
Not really, since you get a pulse at the same spot per electrical revolution.
