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.
Is it possible to change the interrupt on index pin from rising to falling ?
Hmm, can you elaborate a bit more as to why you need this? Is your index active low? Or do you just need to trigger on falling edge? Which ODrive are you using?
ODrive 3.6.
left/right will be rising/falling or swapped depending on rotation direction
Considering that a robot moving is a necessary step for Quad + Hall encoders, I would like to have control over the direction in which this calibration takes place and to make this maneuver safe. Changing the sign of odrv0.axis0.config.calibration_lockin.accel to negative results in the motor turning continuously and never finding an index.
What happens if you change the sign of odrv0.axis0.config.calibration_lockin.vel but leave accel positive?
