The Arduino only has I think 2 interrupt pins which you want to use for the encoder to get the best resolution out of it. Other micros like a Teensy would be a better option with more hardware acceleration. I think the STM32 black pill micro even has a hardware encoder module that keeps track of the position and can be enabled in ST Cube MX. And yes, control systems can be tough. With a motor you have nonlinear effects such as saturation (maximum speed/acceleration/jerk), backlash on the gearing, torque ripple, friction in bearings and brushes, etc. A permanently excited DC motor will have a linear torque to speed response when driven with a constant voltage supply. That is it will have a maximum stall torque (0 RPM) and maximum no-load speed (no torque) and a straight line connects the two. Analogous to a voltage source with a series resistance, if you compare speed/torque to voltage/current. You can use this fact to implement some feed-forward to compensate without need of feedback. Your job as the controls system engineer would be to model the system and develop a control system that can keep it stable. To do it right you would need to have some knowledge in control systems theory, digital signal processing, Laplace/Fourier domain, Z transforms (like the bi-linear transform), stability criteria (BIBO), phase and gain margins, nyquist stability criterion, etc. Really it is just black magic design.
Power Max! I couldn't agree more! Great comments, I've got to pin this somehow... I think we should definitely build a system and do our best to model it! Maybe I can show off a couple of the principles mentioned above!
I'm working on a project that requires more interrupts on the Arduino Nano, and it does have more! You can use pin change interrupts on any pin. They require extra work on the programmer's part, but there are libraries that do that for you. I'm using the EnableInterrupts library right now and it works great! It's letting me use 4 pins for two motor with encoders, and none of these are on pin 2 or 3, so I've got those left for something else.
@@evanbarnes9984 well not only that, but also added latency and jitter, hence there are additional CPU cycles and memory consumed by remembering the state of the pins prior to port intterupt and figuring out which pin caused said intterupt. It's not the end of the world, but these days most MCUs have per pin interupts that make this check unnessesary. And can enable much faster counting of pulses across all pins for things like encoder pulse counting and brushless mostor control.
Good work, its fun to the evolution! As you mentioned control loop times, i can relate to a similar realization when i was working as an electrician. There was a three phase motor with gearbox and mechanical break, whenever a button was pressed a contactor closed and the motor rotated until an inductive sensor signaled to the control system and the contactor opened, got called out that it was not behaving as it should, it was stopping a bit randomly, often past the sensor, or making more rotations. First thought was that the brake had failed, so without to much troubleshooting i said to the mechanics to replace it. After replacing the motor with a brand new one, it did exactly the same thing. so a bit embarressed, i was pondering the problem and with some doubt i checked the PLC application scan time, lo and behold it was 100ms IIRC. I concluded that we should try and reduce it, and i got met with some scepticism by the programmers who were sure that it should work and the problem was the motor/contactor. But we made the change after some back and forth, reduced it to 50ms or less and it worked perfectly every time. So yeah the problem was that either it scanned at the tail end of the sensor pulse, or missed it entirely, so a few MS make a big difference in motor control.
Thank you Ghoetic! What a great story! Yes, Timing is quite important for motor control. It's important to think about the real frequencies in the system and make sure to not violate Nyquist-Shannon rule of thumb. Nice attention to detail! I think we've all jumped to a conclusion in our work before. I wouldn't feel too bad about that!
Hey man ! Good vid, I have a project I'm struggling with where I need to control the exact same type of motor. Is there any way to get your code to do some testing ? Thanks.
Hi Bharani, of course! I've got something mostly up and running, I'll make sure to publish all my prototype code on GitHub soon. My guess is the code will be linked to our video in a week or two.
The Arduino only has I think 2 interrupt pins which you want to use for the encoder to get the best resolution out of it. Other micros like a Teensy would be a better option with more hardware acceleration. I think the STM32 black pill micro even has a hardware encoder module that keeps track of the position and can be enabled in ST Cube MX.
And yes, control systems can be tough. With a motor you have nonlinear effects such as saturation (maximum speed/acceleration/jerk), backlash on the gearing, torque ripple, friction in bearings and brushes, etc. A permanently excited DC motor will have a linear torque to speed response when driven with a constant voltage supply. That is it will have a maximum stall torque (0 RPM) and maximum no-load speed (no torque) and a straight line connects the two. Analogous to a voltage source with a series resistance, if you compare speed/torque to voltage/current. You can use this fact to implement some feed-forward to compensate without need of feedback.
Your job as the controls system engineer would be to model the system and develop a control system that can keep it stable. To do it right you would need to have some knowledge in control systems theory, digital signal processing, Laplace/Fourier domain, Z transforms (like the bi-linear transform), stability criteria (BIBO), phase and gain margins, nyquist stability criterion, etc. Really it is just black magic design.
Power Max! I couldn't agree more! Great comments, I've got to pin this somehow... I think we should definitely build a system and do our best to model it! Maybe I can show off a couple of the principles mentioned above!
I'm working on a project that requires more interrupts on the Arduino Nano, and it does have more! You can use pin change interrupts on any pin. They require extra work on the programmer's part, but there are libraries that do that for you. I'm using the EnableInterrupts library right now and it works great! It's letting me use 4 pins for two motor with encoders, and none of these are on pin 2 or 3, so I've got those left for something else.
@@evanbarnes9984 well not only that, but also added latency and jitter, hence there are additional CPU cycles and memory consumed by remembering the state of the pins prior to port intterupt and figuring out which pin caused said intterupt.
It's not the end of the world, but these days most MCUs have per pin interupts that make this check unnessesary. And can enable much faster counting of pulses across all pins for things like encoder pulse counting and brushless mostor control.
Your struggles brings me back to my industrial commissioning days... fine tuning control loops with really expensive hardware
Good work, its fun to the evolution!
As you mentioned control loop times, i can relate to a similar realization when i was working as an electrician.
There was a three phase motor with gearbox and mechanical break,
whenever a button was pressed a contactor closed and the motor rotated until an inductive sensor signaled to the control system and the contactor opened, got called out that it was not behaving as it should, it was stopping a bit randomly, often past the sensor, or making more rotations. First thought was that the brake had failed, so without to much troubleshooting i said to the mechanics to replace it.
After replacing the motor with a brand new one, it did exactly the same thing. so a bit embarressed, i was pondering the problem and with some doubt i checked the PLC application scan time, lo and behold it was 100ms IIRC. I concluded that we should try and reduce it, and i got met with some scepticism by the programmers who were sure that it should work and the problem was the motor/contactor.
But we made the change after some back and forth, reduced it to 50ms or less and it worked perfectly every time.
So yeah the problem was that either it scanned at the tail end of the sensor pulse, or missed it entirely, so a few MS make a big difference in motor control.
Thank you Ghoetic!
What a great story! Yes, Timing is quite important for motor control. It's important to think about the real frequencies in the system and make sure to not violate Nyquist-Shannon rule of thumb. Nice attention to detail! I think we've all jumped to a conclusion in our work before. I wouldn't feel too bad about that!
Great work dude ! could you share the code?
How to make that kind of graph from the Arduino.
Could I have the code and library?
is it possible to operate this motor with a speed of 0.3rpm?
Hey man ! Good vid, I have a project I'm struggling with where I need to control the exact same type of motor. Is there any way to get your code to do some testing ? Thanks.
And you haven't shown your code ...
I am using same kind of motor, can i get the code please? thank in advance
Hi Bharani, of course! I've got something mostly up and running, I'll make sure to publish all my prototype code on GitHub soon. My guess is the code will be linked to our video in a week or two.
@@EEforEveryone Thankyou for your reply. your code will be too needed to complete my project. Thank you again.
@@EEforEveryone Where's the code ?
😂 😂 😂 😂 😂 😂 😂 😂