Forum >FIT0487 Gearmotor with Encoder issues
FIT0487 Gearmotor with Encoder issues
andrew 2017-04-20 19:54:40 5945 Views8 Replies Hi,
I have a number of FIT0487 gearmotors with encoders and I am having reliability issues with the encoders.
Im using the A and B channels from the encoder connected to a Raspberry Pi.
The issue is that the I am getting what seems to be reliable ticks from the A channel, but when I monitor the actual movement, it is not consistent.
ie We have a laser pointer fitted to the output of the gearmotor and tell the motor to move clockwise for 100 ticks of channel A, then move 100 ticks back again.
The count that we are recording for the encoder is accurately getting to the appropriate number of ticks, but the motion doesnt match. ie when we move the motor 100 ticks clockwise and then 100 ticks counterclockwise, it doesnt go back to the same start position.
Now the real strange part is that if I read the B channel, it counts wildly differently.
ie if we move 100 ticks on the A channel, it might be something like 2000 on the B channel.
This is making it impossible to get an accurate repeatable movement.
Am I expecting too much out of a relatively cheap motor / encoder?
Or should it be able to read for repeatable movement?
Am I missing some specific additional components or hardware that would be needed to make it work?
cheers
Andrew
I have a number of FIT0487 gearmotors with encoders and I am having reliability issues with the encoders.
Im using the A and B channels from the encoder connected to a Raspberry Pi.
The issue is that the I am getting what seems to be reliable ticks from the A channel, but when I monitor the actual movement, it is not consistent.
ie We have a laser pointer fitted to the output of the gearmotor and tell the motor to move clockwise for 100 ticks of channel A, then move 100 ticks back again.
The count that we are recording for the encoder is accurately getting to the appropriate number of ticks, but the motion doesnt match. ie when we move the motor 100 ticks clockwise and then 100 ticks counterclockwise, it doesnt go back to the same start position.
Now the real strange part is that if I read the B channel, it counts wildly differently.
ie if we move 100 ticks on the A channel, it might be something like 2000 on the B channel.
This is making it impossible to get an accurate repeatable movement.
Am I expecting too much out of a relatively cheap motor / encoder?
Or should it be able to read for repeatable movement?
Am I missing some specific additional components or hardware that would be needed to make it work?
cheers
Andrew
2017-11-20 18:02:51 Answering my own question for the benefit of anyone else with the same issue.
You have to check the location of the two hall effect sensors.
If they are both at different distances from the spinning magnet, you will get different counts in each direction and varying levels of success.
We bent the hall effect sensors so that they were both equidistant and all works great. andrew
You have to check the location of the two hall effect sensors.
If they are both at different distances from the spinning magnet, you will get different counts in each direction and varying levels of success.
We bent the hall effect sensors so that they were both equidistant and all works great.
andrew 2017-11-16 18:26:13 I have since developed my own custom motor controller http://brocklesbyimages.com.au/wp/?p=206 and it uses solid state quadrature decoders, so none of that it done on the RPi any more.
This solved the issue with the fantom ticks, or at least made it not visible to me any more.
I have one of the gear motors working flawlessly in this configuration, so YAY!
BUT.... I have others that have strange behaviour.
What I am seeing is that if I move the motor in one direction, say 1000 ticks, and repeat that move, the moves are very consistent and perfectly great.
BUT.... If I move the motor in the other direction, it gets to the 1000 ticks no issue, but this distance is totally different to the first direction.
I calculated the difference, and it ended up being roughly 16% less ticks needed to be counted in the other direction.
So, if I move 1000 ticks in one direction, I need to move 840 ticks in the opposite direction to make the moves the same distance.
If that was consistent, that wouldn't be such hard issue to solve, but it is not consistent.
Has anyone had any issues with these gearmotors with encoders that they are giving different results depending on rotation direction?
If so, how do I track this down and rectify it?
Is it that the hall sensors are at different distances from the magnet that affects the directional reading?
thanks
Andrew andrew
This solved the issue with the fantom ticks, or at least made it not visible to me any more.
I have one of the gear motors working flawlessly in this configuration, so YAY!
BUT.... I have others that have strange behaviour.
What I am seeing is that if I move the motor in one direction, say 1000 ticks, and repeat that move, the moves are very consistent and perfectly great.
BUT.... If I move the motor in the other direction, it gets to the 1000 ticks no issue, but this distance is totally different to the first direction.
I calculated the difference, and it ended up being roughly 16% less ticks needed to be counted in the other direction.
So, if I move 1000 ticks in one direction, I need to move 840 ticks in the opposite direction to make the moves the same distance.
If that was consistent, that wouldn't be such hard issue to solve, but it is not consistent.
Has anyone had any issues with these gearmotors with encoders that they are giving different results depending on rotation direction?
If so, how do I track this down and rectify it?
Is it that the hall sensors are at different distances from the magnet that affects the directional reading?
thanks
Andrew
andrew 2017-06-11 09:00:29 Hi,
from the small testing I did it looks ok: encoder works great, speed and direction also and I can use a sensor nearby without getting weird values (this is a very dumb EMI test but it does say it is useable).
HTH manufwi
from the small testing I did it looks ok: encoder works great, speed and direction also and I can use a sensor nearby without getting weird values (this is a very dumb EMI test but it does say it is useable).
HTH
manufwi 2017-05-24 06:54:38 Well normally I'd say it is counting: 6 ticks for a motor shaft revolution (I think they use hall effect sensors and magnets). But as you have a 45:1 gearbox, it is 270 ticks per output shaft revolution, which is good for precision. I will test it more thouroughly next week and let you knwo (specially about EMI and interference with nearby electronics).
Bye manufwi
Bye
manufwi 2017-05-23 13:11:34 Thanks buddy that looks interesting.
I might give one a try, but I am not sure if it is just outputting ticks or a speed.
When I tried the other gearmotor with just the A channel, it was not accurate at all. it would say that it was moving 1000 ticks, but when you repeated it over and over it was drifting quite randomly.
thanks andrew
I might give one a try, but I am not sure if it is just outputting ticks or a speed.
When I tried the other gearmotor with just the A channel, it was not accurate at all. it would say that it was moving 1000 ticks, but when you repeated it over and over it was drifting quite randomly.
thanks
andrew 2017-05-23 09:12:42 B Channel ticks when the motor is not spinning, jeez, that sounds weird. Also you dont need A-B Channels, simpler encoder might do the trick.
The only ref I have is this: https://www.dfrobot.com/wiki/index.php/FIT0441_Brushless_DC_Motor_with_Encoder_12V_159RPM
I only briefly tested one and it seems promising: the driver and encoder are enclosed, so you only provide a Direction signal (LOW/HIGH) a PWM (weird: low speed for high duty cycle) and you get the encoder output that you plug directly to an input pin of your MCU.
Moreover as it as a gear box (you can select several ratio IIRC) the encoder is precise as one output shaft revolution corresponds to hundreds of motor revolution.
Might be of interest for you.
HTH
Bye
Manu manufwi
The only ref I have is this: https://www.dfrobot.com/wiki/index.php/FIT0441_Brushless_DC_Motor_with_Encoder_12V_159RPM
I only briefly tested one and it seems promising: the driver and encoder are enclosed, so you only provide a Direction signal (LOW/HIGH) a PWM (weird: low speed for high duty cycle) and you get the encoder output that you plug directly to an input pin of your MCU.
Moreover as it as a gear box (you can select several ratio IIRC) the encoder is precise as one output shaft revolution corresponds to hundreds of motor revolution.
Might be of interest for you.
HTH
Bye
Manu
manufwi 2017-05-22 13:37:55 It is worse that that, though.
The same result is from multiple encoders on multiple motors, always the same.
Without the motor spinning, the B channel increases ticks, with A standing still.
For this project, we have been using stepper motors, but I want something that is lighter, smaller, cooler and uses less power.
Geared DC motors with encoders seem like the perfect solution, but I just cant get these ones to work. andrew
The same result is from multiple encoders on multiple motors, always the same.
Without the motor spinning, the B channel increases ticks, with A standing still.
For this project, we have been using stepper motors, but I want something that is lighter, smaller, cooler and uses less power.
Geared DC motors with encoders seem like the perfect solution, but I just cant get these ones to work.
andrew 2017-05-22 13:01:24 product brief says:
Hall Feedback Resolution: 5320
So you should get 5320 ticks for a full revolution. So your A channel seems faulty.
But if you want something precise, isnt it better to use a stepper motor instead?
HTH
Bye
Manu manufwi
Hall Feedback Resolution: 5320
So you should get 5320 ticks for a full revolution. So your A channel seems faulty.
But if you want something precise, isnt it better to use a stepper motor instead?
HTH
Bye
Manu
manufwi 